Это подобно любому другому проектному решению. В конечном счете это зависит. Необходимо изучить те шаблоны, которые полезны на языке (много шаблонов GoF не необходимы в Lisp, или Smalltalk, например), изучите их преимущества и недостатки, поймите ограничения системы и сделайте выбор что лучшие соответствия потребности.
лучший совет, который я могу дать, состоит в том, чтобы учиться, учиться, учиться.
Все зависит от уровня вашей паранойи и чувствительности ключа / данных. В крайних случаях, как только у вас есть незашифрованный ключ в памяти, его можно получить с помощью методов холодной загрузки . В frozencache есть интересная разработка, чтобы попытаться победить это. Я просто случайно прочитал это, не пробовал это на практике, но это кажется интересным подходом, который стоит попробовать.
Однако без фольги - (1), (2), (3) кажутся разумными. (4) не будет резать именно по той причине, которую вы упомянули. (Это не только медленно, но и при условии, что вы читаете данные в стек, при разной глубине стека ключ может стать видимым более одного раза).
Предполагая, что дешифрованные данные того стоят, и они будут в заменяемой памяти, вы определенно следует зашифровать и сам своп. Также, корневые разделы / tmp также должны быть зашифрованы. Это довольно стандартная установка, которая доступна в большинстве руководств для операционных систем.
И, конечно же, вы хотите обеспечить высокий уровень физической безопасности для самой машины и минимизировать функции что он выполняет - чем меньше выполняется кода, тем меньше воздействие. Вы также можете захотеть увидеть, как вы можете полностью минимизировать возможности удаленного доступа к этой машине, то есть использовать ssh на основе RSA-ключей, который будет заблокирован другим ACL, управляемым с другого хоста. Блокировка портов может использоваться как один из дополнительных векторов аутентификации перед возможностью входа на этот второй хост. Чтобы гарантировать, что в случае взлома хоста будет сложнее получить данные, В общем, чем более болезненным вы сделаете доступ к конфиденциальным данным, тем меньше шансов, что кто-то попадет к ним, однако это также сделает жизнь обычных пользователей болезненной - так что должна быть баланс.
В случае, если приложение является серьезным и количество вещей, поставленных на карту, велико, лучше всего построить более четкую общую модель угроз и посмотреть, какие возможные векторы атаки вы можете предвидеть, и убедиться, что ваши настройки эффективно справляется с ними. (и не забудьте включить человеческий фактор : -)
Обновление: и действительно, вы можете использовать специализированное оборудование для шифрования / дешифрования. Тогда вам не придется заниматься хранением ключей - см. Ответ Хэмиша.
Если вы серьезно относитесь к безопасности, вы можете рассмотреть возможность создания отдельной криптографической подсистемы. Предпочтительно тот, который сертифицирован FIPS 140-2 / 3 ( список сертифицированных модулей ).
Затем ключ хранится в защищенной от взлома памяти (неизвлекаемой), и все криптографические операции выполняются внутри криптографической границы.
Дорого, но для некоторых приложений необходимо.
Большая проблема в том, что программа должна читать ключ из где-то . Если вы не принимаете прямой ввод с клавиатуры каждый раз при перезагрузке сервера, он в значительной степени должен где-то существовать на диске.
В общем, вы должны предположить, что злоумышленник не имеет доступа к операционной системе или оборудованию корневого уровня, как когда в случае, если в конечном итоге им удастся получить ключ, даже если он находится только в ОЗУ.
Итак, вы предполагаете, что ОС сервера безопасна. Но предположим, что кто-то может прийти и украсть жесткий диск, поэтому запуск сервера даст им ключ. Затем позвольте серверу запросить у другого сервера половину ключа, удаленный сервер проверяет запрос (используя IP, пары закрытый / открытый ключ) и предоставляет половину ключа. Тогда у вашего сервера будет полный ключ, а на удаленном сервере никогда не будет больше половины.
Я бы посмотрел, что
делают это при обработке ключей. Они достаточно параноики в отношении таких вопросов безопасности ...
Также не забывайте об угрозе дампов ядра и выгрузки вашей памяти!
Как в системах POSIX (например, Linux), так и в Windows, существуют методы предотвращения этого, если вы имеете дело с языком C - см. Этот раздел в CERT Secure Coding Standards:
MEM06-C. Убедитесь, что конфиденциальные данные не записываются на диск