Comments 24
TDE не запрещает root "сдампись"/прочитать память процесса OS где все прочитанные данные уже расшифрованы....
Да, не запрещает, я это в статье явно указал.
СУБД как приложение, выполняющееся в среде ОС, имеет ограниченные возможности по такой защите. Можем шифровать данные и в памяти, что будет иметь большое влияние на производительность, и прятать ключи шифрования в памяти сложным образом. А можем указать на этот аспект безопасникам эксплуатации, чтобы они поставили такие операции на контроль.
Защита информации задача комплексная, и не решается какой-то одной серебряной пулей. TDE решает задачу защиты от утечки данных через кражу файлов.
Чем "изобретать свой велосипед" с TDE (наверно для кого то круто и доходно это делать) можно просто использовать шифрованную фс практически с тем же эффектом но без лишних затрат(максимум монтирование с получением ключей из HSM)? Хранить любые ключи в самописных софтовых хранилищах примерно из этой же серии, хотя HSM это делают надежнее (надеюсь что это не требует аргументов и доказательств).
Доброе утро!
Шифрование ФС это один из вариантов, который, действительно, рассматривался в самом начале.
Шифрование ФС требует ввода секрета, что категорически не соответствовало изначально сформированным требованиям.
Так же подобный подход увеличил бы комплексность решения в целом и потребовал бы либо покупки такого инструмента (являлся бы внешними/сторонними/вендорскими), либо потребовал бы использование open-source, который бы потребовалось бы дорабатывать и тюнить.
Подход же с реализацией TDE избавил нас от внешних зависимостей, прозрачное шифрование защищает данные не только на диске, но и передаваемые по реплекации и сохраняемые в систему резервного копирования.
Да и в целом это инвестиции в экспертизу, что для нас являлось одной из ключевых целей - создание собственного центра разработки/экспертизы для реализации/развития решения на базе postgresql.
Ключи хранятся в централизованной системе хранения секретов, которая используется не только для ключей шифрования для Pangolin, но и для хранения других секретов
1) Описываемая вами реализация TDE по затратам/трудоемкости (и багам реализации) не сравнима с "допиливанием" шифрованной FS для взаимодействия с HSM для шифрованных файлов или файловых систем.
2) Сетевой обмен и его защита - "отдельная песня" и готовых "не самопальных" решений в данной области хватает (у вас же не только репликация по сети идет но и прикладной обмен с БД).
3) Чем же плох backup/реплика БД на шифрованной FS?
4) Какая бы система хранения ключей у вас не использовалась, ключи для дешифровки TDE/репликации/backup root извлечет из памяти сервера. Ну а после этими же ключами дешифрует данные, так от кого тогда TDE? Только от админа БД. :-) Который впрочем dump памяти "своих" процессов скорее всего сделать сможет (вместе с "чистыми данными в пользовательских процессах БД" и "чистыми ключами") что так же ему даст доступ к TDE данным.
В сбере уже столько этих "центров экспертиз и разработок" было и будет, а "где карту получали - туда и идите!" не истребимо... Разработчикам может и не плохо "деньги мыть" при таком подходе нанимателя (оплата работы "для интереса"), но "оплачивают то банкет" клиенты самого банка...
PCI DSS требует шифрования на уровне приложения. И запрещает полагаться на внешние механизмы типа шифрованной ФС.
PCI DSS -
1. Сейчас как бы "не в моде"
2. Меняется/развивается регулярно
3. Довольствуется "компенсационными мерами"
4. TDE конечно "принимает", но "требует шифрования на уровне приложения" - что дико влияет на производительность БД.
Влияние на потребление ресурсов, при включении TDE, в худшем случае, при помещении под защиту 100% данных, составляет +5%.
Виталий, смелю вас заверить, что прежде чем приступать к реализации мы прошли не один архитектурный совет. А сам подход, с учетом требований всех заинтересованных подразделений, был проработан экспертами их нескольких подразделений (безопасность, сопровождение, архитектура и т.д.).
Я и не сомневаюсь что все архитектурные и технологические выборы сбера проходили "архитектурные и экспертные советы во всех подразделениях", но есть факты того что сбер каждые 5-7 лет "меняет направление развития своих технологических платформ". Я понимаю что часть данных изменений реально связаны с изменением внешних технологических условий, но так же и вижу что основная их часть это просто бездумное и не обоснованное ничем (исключая реальную материальную выгоду отдельных персон) "следование за новыми и модными течениями в IT", и не более. :-)
Про +5% - вполне возможно, но вот вопрос, что взамен получили? И "стоит ли полученное" этих процентов? Или у вас есть возражения что TDE (в вашей реализации) не защищает чистые данные базы (и ключи криптации) от OS пользователей с правами root и "владельца базы"? Тогда готов выслушать возражения вас или ваших экспертов... :-)
Привет!
В shared memory данные не шифруются, Владимир чуть ранее отвечал - "Да, не запрещает, я это в статье явно указал.".
Тут защита идет уже внешними организационно-техническими средствами, с помощью аудита и т.п.
Я как бы и пытаюсь объяснять, что TDE проблемы защиты утечки базы "чистых данных" глобально не решает, тогда казалось бы "зачем упираться и тратить ресурсы на реализацию + производительность" (если что с TDE, что без него "защита идет уже внешними организационно-техническими средствами, с помощью аудита и т.п. "). Поскольку "внешние средства защиты" и без TDE работают "как с TDE", и использование шифрованной FS (с правильной раздачей прав в OS) "по факту" дает ровно такую же "защиту" как и TDE (без "гемороя" с собственным изобретением велосипеда). :-)
Видимо лавры изобретателей собственного велосипеда кому то "щекочут самолюбие" и приносят неплохой доход.... :-)
А если сравнить с TDE от Cybertec, что лучше получилось? что изящнее?
Спасибо, что решились написать статью в хабр - хотя явно понимали, что оно не для широкой аудитории. Было интересно ознакомиться.
Как вы верно заметили в начале статьи - это не единственный способ решения потребности в шифровании, поэтому ваше решение наравне конкурирует с другими подходами. В связи с чем, у меня не технические вопросы:
Как существующие проекты экосистемы Сбера уже использующих Postgres вы намерены затаскивать на Pangolin ? (репликацией ведь не получится?)
Хорошо ли продается Pangolin среди внутренних клиентов? Или используется административный ресурс, чтобы форсировать переход с Postgres -> Pangolin?
Ставили ли цель поддерживать связь с upstream-ом Postgres-a или теперь Pangolin уже полностью полностью самостоятельный движок?
1 и 2: компаниям нужен кто-то, кто возьмёт на себя ответственность за сопровождение БД. В случае PostgreSQL это либо Postgres Professional, либо СберТех. PostgresPro, конечно, больше на слуху, но в связи с известными событиями спрос такой, что они не справляются. Так что продаётся, конечно.
3: Связь поддерживается, конечно. Задача «сделать собственный движок» никогда не ставилась – в ней нет смысла, да и ресурсы можно потратить на что-то более полезное.
Привет!
Меня зовут Михаил. Я являюсь владельцем продукта Pangolin (в терминологии agile).
В настоящий момент мы готовим не техническую статью, в которой расскажем про продукт в целом :)
Ответы на вопросы:
С оригинального PostgreSQL переход осуществляется через логическую репликацию или через дамп.
Мы обратную совместимость по интерфейсам сохраняем. Для нас это ключевое требование.
Переход с оригинального PostgreSQL на Pangolin не такая горячая тема, как переход с СУБД крупных иностранных вендоров.
План по переходу есть, но он готовится с учетом специфики и планов каждой конкретной прикладной команды и с учетом нашего roadmap.Так же есть ряд команд, которые развивают инструменты миграции и сопровождения, призванные облегчить процесс перехода.
В данной статье говорится о безопасности, но помимо TDE мы реализовали ряд фичей упрощающих процесс сопровождения и расширяющих функциональные возможности в интересах разработчиков приклада.
Добавлю, что Pangolin является целевой реляционной СУБД в Банке.
Связь с сообществом поддерживаем, но пока одностороннюю.
Стараемся оперативно подтягивать к себе патчи и исправления.
Новые мажорные версии оригинального PostgreSQL, тоже подтягиваем, но тут уже с учетом приоритетов задач из backlog.
А можете "открыть секрет" сколько "целевых реляционных СУБД" сменилось в банке с 2000 года? :-)
Тут не в курсе :)
Уверен, что решения были обоснованными на момент их принятия.
Про обоснованность есть хороший анекдот, заканчивающийся словами - "Жаль, а у меня было еще столько идей!"
mssql -> oracle -> pangolin.
Итого - две.
Оба решения о смене целевой СУБД, для меня, выглядят разумными.
Про Tarantool и InMemory забыли?
Тарантула в банке не видел, также он не является реляционной СУБД.
InMemory это что?
Не является, но "прикручивали" типа "вместо" ...
InMemory это и https://www.tadviser.ru/index.php/Продукт:GridGain_In-Memory_Data_Fabric и Apache Ignite
Я и говорю "идей много"... :-)
Пилят и "на крипте", и на "биг дата", и на "микросервисах", не говорю уже наверно о давно забытой IBM MQ...
Самое "грандиозное" решение Сбера в области БД - это Единая фронтальная система, связанное с заменой реляционных БД на Hadoop и Apatch Ignite
Опыт доработки PostgreSQL: как мы добавили TDE в Platform V Pangolin