Какой из способов безопасного хранения критически важных переменных оптимален?

Доброго утра всем.
В связи с недавними событиями вокруг всем известного сайта и его кода задался вопросом, как тогда правильнее и предпочтительнее хранить такие значения, как секретные ключи, платежную информацию и т.п.?

БД не подходит, т.к. она более уязвима, чем хардкод. Пока нашел лишь два варианта:
- Собирать в php.ini (тут, судя по всему, потребуется собрать php со своими параметрами)
- Хранить в конфигах сервера. Но если потребуется поменять, сервер придется перезапускать
  • Вопрос задан
  • 770 просмотров
Решения вопроса 2
DmitriyEntelis
@DmitriyEntelis
Думаю за деньги
Поймите, все утечки которые происходят - в 99% это не exploit, а тупо человеческий фактор.
Все решения с конфигами сервера, ORM и прочим - абсолютно бессмысленны когда вашему сисадмину подарят новый X6 и он сольет дамп сервера целиком.

Единственное что можно сделать - на уровне архитектуры проекта минимизировать количество людей имеющих доступ к действительно критическим данным, ну и проверять этих людей как следует.
В идеале создать ситуацию когда утечка любых данных невозможна без сговора нескольких таких проверенных людей и опять же регулярно допроверять этих людей СБ.

Могу пример из личного опыта рассказать:
Ваша компания пишет известный мульти-мессенджер работающий по некому протоколу с внешними сервисами.
Что бы к ним подключаться, вы вынуждены где то хранить логины-пароли от внешки в не зашифрованном виде.
Понятно что если просто положить их в базу - утечет все сразу же.

Решение 1:
Пишем хранимку которая отдает связанные логины-пароли от внешнего сервиса по логину-паролю от нашего мульти-мессенджера.
Доступ к изменению хранимки и к базе в которой лежат все пароли есть у 1 человека в компании. Остальные тупо ходят через хранимку. Способа получить полный список логинов-паролей сервиса не существует.

Первое решение в принципе хорошо, но человек имеющий доступ - bigboss и слегка устал лично заниматься этим волшебным сервером.

Решение 2:
Разделяем каждый пароль от внешнего сервиса на N частей (N >= 3)
Дублируем решение 1 на N серверов, каждый пароль получается размазан на N серверов.
Первоначальная хранимка занимается тем что собирает данные из N хранимок с N серверов.
У каждого сервера - свой ответственный человек. Доступ к каждому серверу есть только у ответственного и у bigboss (на случай внештатных ситуаций).

Решение достаточно дорогое и по людям и по железу и по скорости работы - но я за всю свою трудовую деятельность, так и не увидел ничего лучше.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
1. Храним пароль к базе в .htaccess
2. Запросы к базе (ORM) через функцию-шаблонизатор (используем sprintf) с цифровой подписью, в которую при необходимости, передаются параметры. Это позволит контролировать "свои/чужие" запросы и автоматически создаст "белый" список (исключая все неожидаемые).
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы