Всем привет. Прилетело требование от безопасников шифровать данные, лежащие в

pgsql, на уровне базы данных (так называемое «шифрование в покое»), для БД, содержащих персональные данные. Если с MySQL все просто, из коробки, то всё, что я нашел про Postgre - это шифрование файловой системы целиком, там, где лежат базы. Всё так плохо? Нет нативной поддержки шифрования?

>Если с MySQL все просто, из коробки Как интересно. Вы там ужэ Oracle mysql Cluster купили или я что-то пропустил?

Кто мы?) нет

а это требование для защиты от чего? кражи файлов данных прямо с накопителя? или от дампа данных через соединение с бд?

Да, на случай неавторизованного доступа к файлам на диске. Кража сервера из ЦОД :) Еще раз почитал, нашел Encryption For Specific Columns / pgcrypto. Может это поможет частично.

то есть потенциальный взломщик не будет иметь доступ к логину в ос и настройке субд?

Ну, это очень сложно поддержывать и имеет ограничения по индэксацыи. Шыфрованный диск куда проще.

В принцыпе, ничего плохого в том, чтобы зашыфровать только файлы БД я не вижу И в том, чтобы СУБД могла часть своих файлов шыфровать, а часть — нет. И чтобы она запускалась дажэ без ключа расшыфроки — но толково возмущалась про это в логи и не давала ничего сделать. Но да, чего нет — того нет.

Есть еще вот это, но не пойму, про то ли. https://wiki.postgresql.org/wiki/Transparent_Data_Encryption

> Всё так плохо? По крайней мере, всё так. > Нет нативной поддержки шифрования? Нет. > про Postgre СУБД называется postgres. ;)

Модель угроз в студию. Разные решения дают защиту от разных способов утащить данные

This page describes the transparent data encryption feature proposed in pgsql-hackers. Ничего подобного "из коробки" нет (не тратьте время на поиски, в смысле). Всех расширений на эту тему я не знаю, конечно — но, по идее, их для этого не может быть достаточно (а если Вас устраивает какой-то fork PostgreSQL, то это, всё-таки, скорее не к нам). Если нужно подобное, стоит посмотреть на шифрование FS, в самом деле, IMHO.

Спасибо. Тогда действительно надо пробовать шифрование ФС пока.

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

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

Если у них там благие пожэлания, а не реалистичная архитектура реализацыи — то это не "приняли решэние", это "выработли список благих пожэланий".

Они в такие детали не погружаются. Они пишут: 1. Encryption at rest and in transit must be implemented А дальше уже аудит проверит, соблюдено ли требование в должной мере

Хмм... из того, что писал @LebedevDmitry, я так понял, что они ответили? Проблема в том, что PostgreSQL именно этого (пока?) не умеет, я так понял.

А стоит погрузиться, потому что это важно для результата

Тогда я понял неправильно. ;) Вот это — в самом деле всего лишь https://t.me/pgsql/492155

Кража сервера из ЦОД звучит как крайне маловероятный кейс, по сравнению с сетевым взломом, например через уязвимости в приложении, в конфигурирования сети