Лучший способ зашифровать конфиденциальные данные на сервере с помощью HSM и симметричных ключей

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

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

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

Будет ли достаточно безопасно генерировать случайные симметричные ключи для каждого файла, который мы шифруем, затем шифровать симметричный ключ с помощью открытого ключа HSM и хранить как зашифрованные данные, так и зашифрованный символьный ключ? И если да, то как лучше хранить? Строка pkcs7 base64?

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

1. Почему ваши актеры? Простым подходом будет рассмотрение этих трех действующих лиц: сервер, база данных, HSM. Вы также можете рассмотреть больше актеров, например. принимая во внимание www пользователь, на котором работает ваш сервер, и корень пользователь, вы можете сделать то же самое с базой данных и т. д.
2. Как эти актеры связаны друг с другом. Конечно, в вашем случае я думаю, что это так

   HSM <-> Сервер <-> База данных

4. К каким из них может получить доступ злоумышленник? Будет ли злоумышленник иметь доступ к серверу, базе данных, аппаратному модулю безопасности или к каким-либо их сочетаниям?
5. Теперь давайте рассмотрим наихудший случай, когда ваш сервер поврежден злоумышленником, что означает, что и HSM, и база данных также могут (теоретически) быть повреждены. Тогда, на мой взгляд, вам лучше всего зашифровать ваши данные на стороне клиента.Кроме того, вам, вероятно, понадобится симметричный или несимметричный ключ, полученный из личного ввода вашего пользователя (например, это зависит от его пароля), чтобы только он мог их расшифровать. Protonmail использует похожую инфраструктуру, вы можете посмотреть здесь в их официальном документе.

Несколько других заметок. Даже если вы используете HSM для шифрования/дешифрования ваших файлов, в случае поврежденного сервера все равно не существует безопасного канала связи от HSM к клиенту.

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