Как создать пользовательские (только для чтения и чтения) и административные роли для существующей базы данных postgres? - PullRequest
Новая
       29

Как создать пользовательские (только для чтения и чтения) и административные роли для существующей базы данных postgres?

1 голос
/ 20 января 2020

У нас есть действующая база данных postgres с суперпользователем adm, который используется для всего. Наше веб-приложение подключается к базе данных, используя того же пользователя, а также администраторы (для исправления / обновления и т. Д. c.) Используют те же учетные данные.

Мы должны исправить это, чтобы иметь роли, чтобы мы могли иметь read-write, readonly и admin ролей. Мы не хотим, чтобы наше веб-приложение и администратор подключались к базе данных как superuser.

С учетом сказанного я создал следующий скрипт sql для выполнения соответствующих ролей. Я не эксперт по базам данных (пока), поэтому хотел бы узнать о проблемах или найти более эффективные способы их решения. 

ALTER ROLE adm NOLOGIN;

CREATE role user_role NOINHERIT;
CREATE role readonlyuser_role NOINHERIT;
CREATE role admin_role CREATEDB CREATEROLE NOINHERIT;
CREATE ROLE u_service LOGIN PASSWORD '<some password>' INHERIT;
CREATE ROLE u_admin LOGIN PASSWORD '<some password>' INHERIT;
CREATE ROLE u_reader LOGIN PASSWORD '<some password>' INHERIT;

GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonlyuser_role;
GRANT ALL PRIVILEGES ON SCHEMA public TO admin_role;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO user_role, admin_role;
GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA public TO user_role, admin_role;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO user_role, admin_role;
GRANT ALL PRIVILEGES ON ALL PROCEDURES IN SCHEMA public TO user_role, admin_role;
GRANT ALL PRIVILEGES ON ALL ROUTINES IN SCHEMA public TO user_role, admin_role;

GRANT ALL PRIVILEGES ON SCHEMA audit TO admin_role;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA audit TO admin_role;
GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA audit TO admin_role;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA audit TO admin_role;
GRANT ALL PRIVILEGES ON ALL PROCEDURES IN SCHEMA audit TO admin_role;
GRANT ALL PRIVILEGES ON ALL ROUTINES IN SCHEMA audit TO admin_role;

GRANT admin_role TO u_admin;
GRANT user_role TO u_service;
GRANT readonlyuser_role TO u_reader;

1 Ответ

2 голосов
/ 21 января 2020

Несколько вещей для рассмотрения.

Объясните, что могут делать user_role и readonlyuser_role

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

REVOKE ALL ON SCHEMA public FROM public;  --only authorized roles can do anything here.
REVOKE ALL ON SCHEMA public FROM user_role;
REVOKE ALL ON SCHEMA public FROM readonlyuser_role;


GRANT ...

Владельцем базы данных является локальный суперпользователь

Мы обычно делаем владельца БД дополнительной ролью; тот, кто только входит в систему, чтобы создать или изменить схему, а затем грациозно выходит. Если ваш admin_role делает больше, чем это, рассмотрите возможность добавления owner_role.

Требуется ли подключение роли publi c?

Рассмотрите возможность добавления 

 REVOKE CONNECT ON DATABASE yourdb FROM public;

Это блокирует лазейку, в которой любая роль , созданная на том же сервере БД, может войти в эту базу данных.

Сделать все это в блоке транзакции

Остановить назначение привилегий наполовину. Выполнение этой работы может привести к всевозможным неприятностям, очень похожим на запирание ключей в автомобиле. По возможности делайте назначения привилегий в одной транзакции, чтобы пропущенная точка с запятой не блокировала вас.

...