Где вы храните секретный ключ в веб-приложении Java?

Криптография является широко принятой технологией для обеспечения конфиденциальности. Не рассматривая недостатки реализации, он имеет одну критическую точку: хранилище секретных ключей. Если секретный ключ украден, вся система будет скомпрометирована.

EDIT:

Позвольте мне указать контекст, чтобы сделать вопрос менее широким:

  • здесь адресовано веб-приложение java
  • более конкретно используется фреймворк версии spring 3
  • spring security 3.1 используется для защиты приложения
  • доступна база данных mysql5
  • сервер приложений - tomcat6 или tomcat7
  • серверный сервер не под моим контролем

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

Здесь я должен защитить пароль электронной почты (который будет храниться в db). Я считаю эту информацию средней критичной.

То, что я ищу здесь, - лучшее решение с разумными усилиями.

Итак, вопрос очень ясен: , где вы будете хранить эту информацию?

  • Вы сохраняете его в базе данных? Поэтому он должен быть зашифрован, и для этого требуется другой ключ (и где вы храните этот второй ключ?)
  • Вы сохраняете его внутри пакета .war? Как предотвратить несанкционированный доступ к источникам?
  • Вы принимаете другую стратегию?

мотивы вашей стратегии будут оценены. спасибо

ОТВЕТЫ

Ответ 1

Я беру на себя смелость написать ответ, даже если это не имеет никакого отношения к веб-приложению Java. Я думаю, что проблема существует только в незначительной дисперсии со всеми платформами.

В основном есть 3 кандидата для хранения ключей, первые 2 из которых вы упомянули:

  • БД
  • Приложение ( "hardcoded" )
  • Где-то еще на сервере, который запускает WebApp, чаще всего файл

Вы уже положили палец на слабые места первых 2, так что не нужно повторять, я полностью согласен.

Это также мотивация для меня использовать третьего кандидата. Обоснование таково:

  • Различные экземпляры одного и того же приложения могут легко иметь разные ключи, поэтому компромисс одного из них не будет автоматически распространяться на все остальные
  • Если сервер скомпрометирован таким образом, что позволяет злоумышленнику читать любой файл, это все равно игра: вы не сможете остановить его от чтения двоичного файла приложения или DB
  • Защита файловой системы на веб-сервере - это довольно понятный субъект.
  • Прерывания, обеспечивающие полный доступ к файловой системе, статистически намного реже, чем разрывы приложений или баз данных.

Ответ 2

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

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

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

Таким образом, предполагая следующие сценарии:

  • Ваше приложение взломано: злоумышленник имеет те же права, что и у вас. Можно попытаться использовать ваш API для получения конфиденциальной информации, не играя вообще с шифрованием. Ваш код сделает это за них. Следующий вариант: она может попытаться получить ваш файл войны или файлы классов и декомпилировать их, чтобы узнать жесткий код или узнать, какой механизм шифрования вы использовали.
  • Только база данных взломана: вам должно быть хорошо, что данные зашифрованы с помощью ключа, который не находится в самой базе данных.

Сделать это сложнее для злоумышленника. Вы можете поместить файл в файловую систему. Как описано в другом ответе, добавьте к нему соответствующие разрешения FS. Но дополнительно используйте java Security Manager для ограничения доступа для всех классов Java, кроме тех, которые действительно нужно прочитать. Также было бы полезно ограничить модификацию ваших файлов jar и class.

Чем больше блокировок у вас, тем более безопасными вы. Как и стандартный дверной замок. Блокировки должны быть от разных поставщиков и с различными механизмами. Но в конце концов опытный грабитель все равно войдет.

Ответ 3

Файловая система в порядке, выберите права пользователя и используйте разрешение на войну. Было много дыр в безопасности, которые открывали доступ только к базе данных или военному контенту.