Я могу поделиться тем, что мы делаем и что я видел.Мы делаем A и используем B там, где это просто.
A) Стандартные пользователи Для всех баз данных у нас есть 3 стандартных пользователя со следующими суффиксами (_dba, _rw, _ro).Все они имеют свои собственные пароли с использованием генератора надежных паролей.
_dba используется для развертывания схемы и имеет все права
_rw используется приложением (CRUD для всехтаблицы, но не может изменить схему)
_ro имеет только R для всех таблиц и обычно предоставляется разработчикам
Примечание : разработчики имеют доступ к бастионуиспользуется для переадресации портов и проксикап.Они могут запрашивать конечные точки RDS со своих собственных компьютеров (DB Tools) через прокси и бастион socks.
Это ленивый метод - поскольку создание пользователей выполняется программно, и мы чувствуем себя комфортно, предоставляя некоторым разработчикам доступ только для чтения.Они могли бы написать неверный запрос и замедлить работу системы, но они могли бы сделать это с конкретным пользователем, который не сильно отличался бы, и журналы бастионов сообщали мне, кто действительно был, если мне пришлось расследовать.
B) UI
Простое веб-приложение с входом в систему (в идеале MFA) - предоставляет способ запуска запросов.Если только для отчетности, в идеале против R / O копии системы.Stackoverflow предлагает один (https://data.stackexchange.com/).
) Было бы неплохо, если бы RDS предложил это самостоятельно (в зависимости от ваших ролей IAM). Они предлагают это на RDS Serverless (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/query-editor.html) иможет быть функцией в других версиях RDS, которая обеспечивает точное управление или даже ленивое управление (группы IAM).