База данных H2: как защитить с помощью шифрования, не раскрывая ключ шифрования файла

Question

Мы используем базу данных Java + H2 в режиме сервера, потому что мы не хотим, чтобы пользователи обращались к файлу базы данных.

Чтобы обеспечить дополнительную защиту файла базы данных, мы планируем использовать шифрование AES (добавьте CIPHER = AES к URL-адресу базы данных) в случае кражи хранилища.

Однако при подключении каждому пользователю также потребуется указать пароль защиты файла ([пароль файла] [пробел] [пароль пользователя]).

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

Есть идеи, как сохранить файл базы данных безопасным (зашифрованным) без предоставления ключа шифрования файла пользователям?

Спасибо.

Answer 1

В настоящее время нет способа сделать это в H2.

Одним из решений является использование шифрования файловой системы, независимой от H2.

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

Answer 2

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

Этот веб-сервис предоставляет ключ шифрования.

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

Если ваша модель риска позволяет это сделать, вы даже можете запустить этот веб-сервис ната же коробка, что и в вашем веб-приложении.

Answer 3

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

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

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