Какой из способов безопасного хранения критически важных переменных оптимален?
Доброго утра всем.
В связи с недавними событиями вокруг всем известного сайта и его кода задался вопросом, как тогда правильнее и предпочтительнее хранить такие значения, как секретные ключи, платежную информацию и т.п.?
БД не подходит, т.к. она более уязвима, чем хардкод. Пока нашел лишь два варианта:
- Собирать в php.ini (тут, судя по всему, потребуется собрать php со своими параметрами)
- Хранить в конфигах сервера. Но если потребуется поменять, сервер придется перезапускать
Поймите, все утечки которые происходят - в 99% это не exploit, а тупо человеческий фактор.
Все решения с конфигами сервера, ORM и прочим - абсолютно бессмысленны когда вашему сисадмину подарят новый X6 и он сольет дамп сервера целиком.
Единственное что можно сделать - на уровне архитектуры проекта минимизировать количество людей имеющих доступ к действительно критическим данным, ну и проверять этих людей как следует.
В идеале создать ситуацию когда утечка любых данных невозможна без сговора нескольких таких проверенных людей и опять же регулярно допроверять этих людей СБ.
Могу пример из личного опыта рассказать:
Ваша компания пишет известный мульти-мессенджер работающий по некому протоколу с внешними сервисами.
Что бы к ним подключаться, вы вынуждены где то хранить логины-пароли от внешки в не зашифрованном виде.
Понятно что если просто положить их в базу - утечет все сразу же.
Решение 1:
Пишем хранимку которая отдает связанные логины-пароли от внешнего сервиса по логину-паролю от нашего мульти-мессенджера.
Доступ к изменению хранимки и к базе в которой лежат все пароли есть у 1 человека в компании. Остальные тупо ходят через хранимку. Способа получить полный список логинов-паролей сервиса не существует.
Первое решение в принципе хорошо, но человек имеющий доступ - bigboss и слегка устал лично заниматься этим волшебным сервером.
Решение 2:
Разделяем каждый пароль от внешнего сервиса на N частей (N >= 3)
Дублируем решение 1 на N серверов, каждый пароль получается размазан на N серверов.
Первоначальная хранимка занимается тем что собирает данные из N хранимок с N серверов.
У каждого сервера - свой ответственный человек. Доступ к каждому серверу есть только у ответственного и у bigboss (на случай внештатных ситуаций).
Решение достаточно дорогое и по людям и по железу и по скорости работы - но я за всю свою трудовую деятельность, так и не увидел ничего лучше.
Дмитрий Энтелис: о! я даже не слышал. Спасибо за наводку!
А тут 2 домена ru.hetzner.com и просто hetzner.com инфа на них разная. Какой для РФ подойдет и можно ли внешний IP выбрать например в USA?
xmoonlight: все слышали про хецнер как мне кажется)
Надо понимать у них "дата центры" в стиле "пацаны в гараже построили", но с учетом цены ...
Контора одна, просто на .de цены с VAT по умолчанию.
Сервера в германии и вроде бы нидерландах.
1. Храним пароль к базе в .htaccess
2. Запросы к базе (ORM) через функцию-шаблонизатор (используем sprintf) с цифровой подписью, в которую при необходимости, передаются параметры. Это позволит контролировать "свои/чужие" запросы и автоматически создаст "белый" список (исключая все неожидаемые).
Простой
