Как хранить ключ для шифрованной mysql базы (MariaDB)?

Question

[hostadmin]

Хочу шифровать чувствительные данные в некоторых таблицах БД (в моем случае MariaDB). Но появились вопросы:
1. Как хранить ключи шифрования, например, в файлах?
Т.е. понятно что можно кинуть на диск, но в случае компрометации доступа вместе с базой утекает ключ.
Думаю, что наверно правильнее перед запуском БД подключать к системе какой-то удаленный сетевой ресурс (папку), на котором лежит ключ, запускать БД и после запуска отключать этот ресурс. Правильно мыслю?

2. Вроде в мануале пишут, что можно использовать AWS KMS, но здесь тоже не ясно как обстоит дело с доступом к ключу злоумышленников, получивших доступ к серверу. Или у AWS KMS есть какая-то защита на количество запросов ключа и/или ограничение по времени? К сожалению никогда не работал с KMS.

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

PS. Речь именно про стандартное шифрование средствами самой БД, а не использование шифрования при sql-запросах.

Answer 1

[Александр Аксентьев]

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

Почти в любом случае серьезной компрометации будут доступны способы залезть например в исходники сайта/еще куда-то и достать ключ, поэтому все шифрования ничего толком не дают в плане защищённости как по мне.
То ли дело хеширование, но в случае с данными которые надо читать это не подходит :)

Comments

[hostadmin]

Ну я представлял, что sql-сервер при запуске считывает ключ и дальше хранит его в памяти, т.е. дальше ключ не нужен, до перезапуска сервера. В этом и есть кардинальное отличие от использования шифрования средствами приложения, где ключ нужен при каждом запросе к БД.

[Александр Аксентьев]

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

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

Отсюда вытекает вопрос поддержки - упал сервер ночью и лежит пока кто-то руками не поднял.
Упал от перегрузки днём - аналогично.
и т.д.

[hostadmin]

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

Подключение, видимо, должно быть инициировано только человеком, иначе, смысла в шифровании не много.

Собственно поэтому я вопрос и задаю - интересно как у людей эти ситуации разруливаются.

Answer 2

[Александр Черных]

согласен с Александр Аксентьев

Защита будет только при отсутствии возможности это сделать с сервера

лучше заткнуть подходы к серваку от любопытных

Comments

[hostadmin]

Ну тут затыкай, не затыкай, а идеального в мире не бывает.

А вот, например, в каком-то мануале прям так и пишут:

Еще один заслуживающий внимания фактор — защита главного ключа внутри ключевого файла. Если главный ключ является составным, то механизм безопасности данных открыт для утечек. Решить проблему можно поместив файл ключа в раздел, который может быть отключен при запуске MySQL (каталог, подключаемый только во время запуска базы данных). Важно не потерять ключевой файл вместе с главным ключом, так как не будут осуществлено шифрование базы данных MySQL.

Т.е. схема правильная, но мне интересны практические отзывы.

[Александр Черных]

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

это тоже знаете не вариант