Comments 25
Спасибо за внимание, ждите следующих статей.
Peer/ident аутентификация в действительности полезна в довольно узком круге окружений. Например сейчас, при развитии контейнерезации, в контейнере с СУБД будет только один пользователь. Да и просто в облачных СУБД у вас нет возможности настраивать пользователей сервера СУБД.
Да и безопасность, в случае с ident, становится ниже, как вы и сами говорите.
И масштабируется такой подход не очень хорошо: что будете делать с сотнями тысяч пользователей — каждому создавать пользователя?
А разделение данных пользователей по разным физическим серверам?
А всем остальным и так пользуются.
В части облачных СУБД вы правы, там доступ только к БД и от ОС вы отделены.
Касаемо безопасности внутри защищённого периметра — спорно. Если к вам во внутреннюю сеть влезли враги, то у вас уже всё плохо и наличие/отсутствие ident там погоды не сделает.
Относительно масштабируемости я честно не знаю откуда сотни тысяч пользователей. Если у вас собственная инсталляция, то реальных пользователей БД (не веб-приложения) будет штук 5: для веб-приложения, для фоновых задач, для деплоя, для разработчиков, ридонли и ещё чего-нибудь. Поэтому вполне реально им права настроить.
В случае шардирования по разным физическим серверам в PG, обычно, используют FDW и там свои особенности. А на аутентификацию к основному серверу БД это никак не влияет.
А зачем тогда вообще peer/ident аутентификация, если пользователей всего 5 и это не столько пользователи, сколько роли?
Для разработчиков: уж если и иметь аккаунт на машине, то лучше каждому свой чтобы можно было лишать доступа прицельно. При этом доступ к БД у вас получается всё равно групповой.
Я про то что реальной пользы от peer/ident аутентификации сейчас нет.
И где-то тут мы плавно перешли от ситуации "одна учётка на проде и 1 пользователь на всех" к ситуации "каждому свой аккаунт". Давайте будем последовательны и хотя бы на группы пользователей разобьём. Так же, в случае peer вполне себе можно иметь много пользователей с разными ssh ключами, которые ведут на одного юникс-пользователя. Там и логирование нормально настраивается на уровне системы, и групповые политики доступа к БД работать не перестают. Лично видел и работал с такими инсталляцими.
Тут все зависит от проекта. Если это соцсеточка, то можно надеяться на периметр, все равно безопасность никого не волнует. А вот если это финтех или приличный энтерпрайз, то уже неплохо бы защищаться и от собственных админов (и тут разделение паролей сильно помогает).
Все дело в том, что реализация описанных (и безусловно полезных) механизмов значительно отличается для разных СУБД.
Да, в разных СУБД разные реализации и для ORM это не подходит, там свой дивный мир. Но по личному опыту, привязка к типу БД происходит почти всегда и смена БД в проекте — это скорее исключение, нежели правило. Поэтому, почему бы не воспользоваться доступными инструментами?
Значит у нас с вами просто разный опыт. Я, чаще всего, наблюдаю как разработчики хотят сохранить независимость от БД и громоздят абстракции на уровне веб-приложения, хотя нет никаких предпосылок или требований со стороны бизнеса к независимости от БД.
Если кто-то чего-то не хочет, а Вы считаете что ему это нужно — посоветуйте один раз, предложите позже еще раз при удобном случае. И если это не принесло желаемого результата — оставьте. В конце концов для каждого не только свои грабли, но и время, когда он на них должен наступать.
Ограничение целостности...
Достаточно спорно нынче стало все это.
1. Проверка бизнес целостности на уровне БД при eventually consistent подходе невозможна, да и ссылочная тоже.
2. При миграции большого кол-ва данных все constraints отключают для скорости и непрерывности процесса. А проверку проводят при подготовке данных.
3. Тут как всегда панацеи нет — что-то должно быть реализовано на уровне БД, что-то на уровне контроллера. Но и размазывать логику тоже не хочется, поэтому все чаще и чаще логика переносится на котроллер
Но, согласитесь, мигрировать данные так, что после миграции приложение их прожевать не сможет — глупое занятие. Поэтому и написал, что основа бизнес-логики должна быть прибита констрейнтами. Остальное — по вкусу. Эта же штука простимулирует правильную расстановку транзакций в приложении и хранение нецелостных данных в промежуточном месте. Например, последовательность шагов визарда складывать в редиску и только на последнем шаге всё сохранять, а не держать в базе неконсистентные данные, надеясь что визард успешно завершится и его не дропнут.
Так что не ведитесь на удобство конфигурирования, аукнется.
Не думаю, что механизм FDW принципиально отличается от DB-линков, так что, скорее всего, вышесказанное применимо и к Postgres
В любом случае аффектятся обе базы, всё зависит от пропорциональности аффекта и плана выполнения. Для начала, коннект внешней БД занимается, а он кушает ресурсы, которые всегда ограничены. Так же, например, с FreeTDS для MSSQL всё не очень и pushdown для многих вещей не работает, что влечёт выборку всей внешней таблицы там, где по здоровой голове 1 строка в результате должна быть. Так что волков бояться — в лес не ходить. В итоге мы приходим либо к комбинации DSL-команд, которые не работают физически, либо к запросам, которые съедают все ресурсы. Хрен редьки не слаще и тут уж локально выбор делается и панацеи нет.
Вместо конфигов с координатами нескольких БД в веб-приложении несравнимо проще оставить одно подключение к БД и разрулить всё на уровне самой БД.Прочитал, как почти призыв использовать линки везде, где можно. Ибо (в том числе) это упрощает конфигурирование.
С другой стороны, чаще всего запросы не требуют данных более чем одной базы. В противном случае это попахивает не очень хорошим проектированием этих самых БД.
Потому утверждение
В любом случае аффектятся обе базынемного преувеличено.
Если приложение будет ходить в БД отдельно, то в большинстве случаев напрягаться будет только одна из них.
БД — это не только хранилище данных