Хранение ключа AES_ENCRYPT

Ну, у тебя не так много вариантов. Куда бы вы ни поместили этот ключ (базу данных, код, файл), его легко найти, если другие люди имеют доступ к машине.

Что вы можете сделать, так это зашифровать этот ключ другим ключом на основе некоторого пароля (который нигде не хранится, по крайней мере, локально) и запрашивать этот пароль при запуске приложения. Таким образом, вы можете сохранить зашифрованный ключ AES_ENCRYPT в своей базе данных, расшифровать его после входа в систему с вашим паролем и начать использовать его.

Безопасность неизвестностью!

Если ваш веб-сервер скомпрометирован, злоумышленник может получить доступ к ключу, независимо от того, где он хранится, поскольку код должен быть в состоянии найти ключ для выполнения шифрования/дешифрования, и код объясняет, где он находит ключ. Единственный сценарий, в котором это имеет реальную ценность, — это защита данных вне приложения (например, на резервной ленте). Однако, поскольку вы ставите под угрозу способность DBM оптимизировать запросы и создаете гораздо больший объем данных для такой цели, как резервное копирование, имеет смысл шифровать резервную копию или файловую систему, а не отдельные элементы данных.

Даже если вы используете ключи, которые не хранятся в вашем приложении постоянно (например, пароль базовой аутентификации HTTP, передаваемый через SSL), все равно существует много рисков, что данные будут скомпрометированы, и у вас есть проблемы с обменом данными между разными пользователями. .

Чтобы дать разумный ответ, нам нужно знать, какова модель угроз и есть ли у вас внешние ограничения, такие как PCI-DSS.

Проблемы безопасного хранения на сервере ключей и паролей, используемых в вашем PHP/Python/другом приложении, связаны не только с сокрытием ключей от злоумышленника, получившего права суперпользователя на вашем сервере, хотя вы можете злоумышленнику, получившему root, сложнее получить к ним доступ, в конце концов это можно сделать.

Однако ключи/пароли могут быть утеряны многими другими способами и поэтому должны быть защищены. Например, если ваше программное обеспечение обновляется из среды разработки, т. е. загружается и извлекается через git сервер, вы не хотите, чтобы ключи включались в виде обычного текста в исходный код. Это даст любому члену вашей команды разработчиков доступ к ним.

Один из вариантов «более безопасного» хранения ключей — настроить их как переменные среды, а затем включить их в свое приложение, обратившись к этой переменной среды вместо того, чтобы иметь ключ в «обычном тексте» в вашем приложении. .

Однако это требует, чтобы вы установили переменную среды как постоянную, чтобы при перезагрузке сервера она автоматически устанавливалась снова, иначе вы должны устанавливать ее каждый раз при перезагрузке.

Если вы используете веб-сервер Apache, вы также можете установить переменные среды Apache для конфиденциальных ключей/паролей в файле httpd.conf, а затем получить к ним доступ из своего PHP-скрипта. Вы также можете ограничить права доступа к файлу httpd.conf, чтобы только root мог читать/записывать.

// Example use of getenv()
$sensitive_key = getenv("VERY_SENSITIVE_KEY");

// Example use of apache_getenv()
$sensitive_key = apache_getenv("VERY_SENSITIVE_KEY");

Это означает, что ключ/пароль не включен в исходный код самого приложения и с меньшей вероятностью ускользнет от сервера.