Comments 10
но и повышаем уровень защищенности (подделка сертификата немножко сложнее угадывания любимого пароля, который у меня - "qwerty").
Ну если честно, то это далеко не очевидно. У вас же много пользователей, правда? Представим что в какой-то момент вы их всех решили тоже аутентифицировать по сертификатам. Бац - и у вас в компании появился свой Удостоверяющий Центр (это перевод CA, если что). И у вас вместо записанных там и сям на бумажке паролей - валяющиеся там и сям на дисках пользовательские сертификаты. Много. В непонятном состоянии. Непонятно когда протухнут.
А уж тихая и незаметная утечка корневого сертификата, которым можно подписать пользовательский, точно такой же, под которым у вас ходит в базу DBA... это вообще.
Ну я надеюсь вы поняли. Перевод на сертификаты - это куча дополнительного высокоуровневого гемора на голову админов. В каком-то смысле уровень защищенности может и растет, но схема усложняется, в ней появляются новые неочевидные дыры в безопасности. Станет ли в итоге лучше - совсем не факт. А вот сложнее для всех - станет точно.
Вы ведь не забыли себе в календарь записать, что нужно перевыпустить сертификат через годик, да? :)
Я в самом начале упомянул
при локальной разработке
намеренно, чтобы сгладить некоторые углы, которые вы подсветили =)
Пользователей то много, да. Но вот если всем нужен доступ до прода, то, кажется, это больше про характеристику компании / процесса разработки будет, нежели про проблематику валяющихся пользовательских сертификатов.
Опять же, если будет утечка корневого сертификата да еще из абстрактного УЦ с СКЗИ класса защиты КС3, то это будет новость интереснее свежей новости про xz.
Вы ведь не забыли себе в календарь записать, что нужно перевыпустить сертификат через годик, да? :)
Без шуток - да.
Ну и говоря про проблематику ротации сертификатов, есть же уже действующие решения. Vault + agent / импортозамещенный вариант под названием SecMan
Опять же, если хочется говорить про применимость к prod environment, там можно и скомбинировать полную взаимную проверку сертификатов с проверкой пароля. Добавим конфигурацию проверки по IP (все та же строчка в pg_hba.conf). Плюсом кажется сетевая инфраструктура организации должна быть настроена правильным образом ;)
Опять же, если будет утечка корневого сертификата да еще из абстрактного УЦ с СКЗИ класса защиты КС3, то это будет новость интереснее свежей новости про
xz.
Да не то слово.
Я знаю про vault, мы как раз в процессе внедрения. Поэтому и решил позадавать вопросы в том числе.
Для локальной разработки вам хватит файла .pgpass
Но почему не GSSAPI?
У автора лапки, macOS и в домашней сети не оказалось нужной инфраструктуры.
Поднять хотя бы Samba DC можно и в контейнере. Зато это будет масштабируемо.
LDAP с Kerberos можно запускать даже в той же вируталке, что и PostgreSQL. Раньше так и делал.
Зато это будет масштабируемо.
Оставив за скобками момент, что я в первых же строчках писал про локальную разработку, в какой момент у сертификатов пропало масштабирование?
LDAP с Kerberos можно запускать даже в той же вируталке, что и PostgreSQL. Раньше так и делал.
Где-то я пропустил в тексте, что запускаю это все на виртуалке. Как обнаружу - дам более развернутый комментарий.
В любом случае, получаем дополнительный сервис, а хочется побриться бритвой Оккама.
Ну и просто вопрос. А GSSAPI точно удовлетворяет требованию 4? Я его, конечно, сформулировал в слишком фривольной манере, но подразумевалось что непосредственный канал связи с сервером БД должен быть mTLS.
в какой момент у сертификатов пропало масштабирование?
Как только появляются реальные пользователи, которым все равно необходимо будет получать билетики, механизм сертификатов для них окажется пятой ногой. Ведь механизм сертификатов потребует разработки целой инфраструктуры. Ведь в целях безопасности, эти сертификаты все равно нужно будет выдавать пользователям всего на несколько часов, так же, как и билетики. Последние выдаются, обычно, на 8-12 часов.
Но главная проблема масштабирования - доверительность по отношению ко всем сервисам, а не только к KDC. Билетики выдаются пользователям всегда на конкретный сервис, тогда как сертификаты пользователей к сервисам не привязаны. Когда у Вас лишь один сервис (PostgreSQL) - это значения не имеет. Но когда у Вас сотни сервисов - это уже дыра в безопасности.
Где-то я пропустил в тексте, что запускаю это все на виртуалке
Вы пропустили слова даже и раньше. Я указал, что Kerberos я использовал еще до появления в природе докера. Лет 25 назад.
В любом случае, получаем дополнительный сервис
В подавляющем большинстве случаев, как только решение будет масштабировано за пределы локального хоста, Kerberos будет доступен. Более того, в моей практике, Kerberos всегда был доступен, пусть даже и через VPN. То, что из-за бюрократии не всегда оперативно добавлялись SPN для сервисов моего локального хоста - это уже другой вопрос.
подразумевалось что непосредственный канал связи с сервером БД должен быть mTLS.
Kerberos иначе и не умеет. Разница в том, как я указал выше, что сертификат (билетик) клиенту выдается KDC на конкретный сервис, а не на всё скопом.
П.0 - я как пользователь _не хочу_ трогать pgAdmin даже ОЧЕНЬ длинной палкой. Можно? Ну позя-зя-зя?!
PostgreSQL + pgAdmin + mTLS + certificate-based authentication + docker-compose в одном флаконе