Управление доступом на гибком сервере База данных Azure для PostgreSQL

Управление доступом к База данных Azure для PostgreSQL гибким ресурсам сервера является важной частью обеспечения безопасности и соответствия требованиям. В этой статье объясняется, как использовать роли PostgreSQL и функции Azure для управления разрешениями и реализации рекомендаций по управлению доступом.

Управление ролями

Лучший способ управления База данных Azure для PostgreSQL гибкими разрешениями доступа к серверу в масштабе — использовать концепцию ролей. Роль может представлять собой пользователя базы данных или группу пользователей базы данных. Роли могут принадлежать объектам базы данных и назначать привилегии для этих объектов другим ролям для управления доступом к каким объектам. Вы можете предоставить членство в роли другой роли, что позволяет участнику использовать привилегии, назначенные другой роли. База данных Azure для PostgreSQL гибкий сервер позволяет предоставлять разрешения непосредственно пользователям базы данных. В целях обеспечения безопасности создавайте роли с определёнными наборами разрешений исходя из минимально необходимых требований приложения и доступа. Назначьте соответствующие роли каждому пользователю. Используйте роли для принудительного применения модели наименьших привилегий для доступа к объектам базы данных.

Помимо встроенных ролей, создаваемых PostgreSQL, гибкий сервер База данных Azure для PostgreSQL включает три роли по умолчанию. Эти роли можно просмотреть, выполнив следующую команду:

SELECT rolname FROM pg_roles;

Вот эти роли:

  • azure_pg_admin
  • azuresu
  • Роль администратора

При создании гибкого сервера База данных Azure для PostgreSQL вы предоставляете учетные данные для роли администратора. Используйте эту роль администратора для создания дополнительных ролей PostgreSQL.

Например, можно создать пользователя или роль с именем demouser.

CREATE USER demouser PASSWORD password123;

Не используйте роль администратора для приложения.

В облачных средах PaaS доступ к учетной записи суперпользователя База данных Azure для PostgreSQL предоставляется только облачным операторам и только для операций плоскости управления. Таким образом, учетная запись azure_pg_admin представляет собой псевдоучетную запись суперпользователя. Ваша роль администратора входит в роль azure_pg_admin. Однако учетная запись администратора сервера не является частью azuresu роли, которая имеет права суперпользователя и используется для выполнения операций уровня управления. Так как эта служба является управляемой службой PaaS, только корпорация Майкрософт является частью роли суперпользователя.

Вы можете периодически проверять список ролей на сервере.

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

select * from pg_roles where rolname='demouser';
-[ RECORD 1 ]--+---------
rolname        | demouser
rolsuper       | f
rolinherit     | t
rolcreaterole  | f
rolcreatedb    | f
rolcanlogin    | f
rolreplication | f
rolconnlimit   | -1
rolpassword    | ********
rolvaliduntil  |
rolbypassrls   | f
rolconfig      |
oid            | 24827

Это важно

Недавно база данных Azure для PostgreSQL включила возможность создания команд CAST. Чтобы запустить инструкцию CREATE CAST, пользователь должен быть членом группы azure_pg_admin . Сейчас вы не можете удалить CAST после создания.

База данных Azure для PostgreSQL поддерживает только команды CAST с параметрами WITH FUNCTION и WITH INOUT. Параметр WITHOUT FUNCTION не поддерживается.

Ведение журнала аудита в Базе данных Azure для PostgreSQL также доступно в Базе данных Azure для PostgreSQL для отслеживания действий в базах данных.

Управление доступом к схеме

Недавно созданные базы данных в Базе данных Azure для PostgreSQL включают набор привилегий по умолчанию в общедоступной схеме базы данных, которая предоставляет всем пользователям базы данных и ролям возможность создавать объекты. Чтобы лучше ограничить доступ пользователей приложения к базам данных, создаваемым на База данных Azure для PostgreSQL гибком сервере, рассмотрите возможность отзыва этих общедоступных привилегий по умолчанию. После отзыва этих привилегий предоставьте пользователям базы данных определенные привилегии более детально. Рассмотрим пример.

  • Отзовите привилегию CREATE для схемы public у роли public, чтобы пользователи базы данных приложения не могли создавать объекты в схеме public.

    REVOKE CREATE ON SCHEMA public FROM PUBLIC;

  • Создайте новую базу данных .

    CREATE DATABASE Test_db;

  • Отмените все привилегии из схемы PUBLIC в этой новой базе данных.

    REVOKE ALL ON DATABASE Test_db FROM PUBLIC;

  • Создайте пользовательскую роль для пользователей базы данных приложения.

    CREATE ROLE Test_db_user;

  • Предоставьте пользователям базы данных с этой ролью возможность подключаться к базе данных.

    GRANT CONNECT ON DATABASE Test_db TO Test_db_user;
GRANT ALL PRIVILEGES ON DATABASE Test_db TO Test_db_user;

  • Создание пользователя базы данных.

    CREATE USER user1 PASSWORD 'Password_to_change'

  • Назначьте пользователю роль с привилегиями CONNECT и SELECT.

    GRANT Test_db_user TO user1;

В этом примере пользователь user1 может подключаться и имеет все привилегии в тестовой базе данных Test_db, но не любую другую базу данных на сервере. Вместо предоставления этому пользователю или роли ALL PRIVILEGES в этой базе данных и его объектах рекомендуется предоставлять более выборочные разрешения, такие как SELECT, INSERTEXECUTEи другие. Дополнительные сведения о привилегиях в базах данных PostgreSQL см. в командах GRANT и REVOKE в документации PostgreSQL.

Изменения владения общедоступной схемой в Базе данных Azure для PostgreSQL

В PostgreSQL 15 и более поздних версиях владение общедоступной схемой изменилось на новую pg_database_owner роль, которая позволяет владельцам баз данных контролировать ее. Дополнительные сведения см. в заметках о выпуске PostgreSQL. Однако в Базе данных Azure для PostgreSQL это изменение не применяется. Схема public принадлежит роли azure_pg_admin во всех поддерживаемых версиях PostgreSQL. Это управляемое поведение службы обеспечивает безопасность и согласованность.

Изменения в PostgreSQL 16: ролевая безопасность

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

В PostgreSQL 16 пользователи с атрибутом CREATEROLE больше не могут передавать членство в любой роли любому пользователю. Вместо этого, как и другие пользователи без этого атрибута, они могут назначать членство только в тех ролях, для которых у них есть ADMIN OPTION. Кроме того, в PostgreSQL 16 атрибут CREATEROLE по-прежнему позволяет пользователю, не являющемуся суперпользователем, создавать новых пользователей. Однако они могут удалять только созданных пользователей. Попытки удалить пользователей приводят к ошибке, когда пользователь не был создан пользователем с атрибутом CREATEROLE .

PostgreSQL 16 также представляет новую и улучшенную встроенную роль. Роль pg_create_subscription позволяет суперпользователям создавать подписки.

В База данных Azure для PostgreSQL гибком сервере роль azure_pg_admin — это управляемая системой, ограниченная роль и не может быть изменена пользователями. Попытки изменить его, например, назначить ему другую роль, приводят к ошибке вида:


  GRANT <db_user> TO azure_pg_admin;
ERROR: permission denied to alter restricted role "azure_pg_admin"

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

Улучшенное управление azure_pg_admin

В PostgreSQL 16 структура строгой иерархии ролей реализуется для пользователей с привилегией CREATEROLE , в частности связанной с ролями предоставления. Чтобы повысить гибкость администрирования и устранить ограничение, введенное в PostgreSQL 16, База данных Azure для PostgreSQL расширяет возможности роли azure_pg_admin во всех версиях PostgreSQL. С этим обновлением участники роли azure_pg_admin могут управлять ролями и получать доступ к объектам, принадлежащим любой нерестриктированной роли, даже если эти роли также входят в azure_pg_admin. Это улучшение гарантирует, что административные пользователи поддерживают согласованный и комплексный контроль над ролью и управлением разрешениями, обеспечивая простой и надежный интерфейс без необходимости доступа суперпользователя.

Безопасность на уровне строк

Безопасность на уровне строк (RLS) — это функция безопасности Базы данных Azure для PostgreSQL, которая позволяет администраторам баз данных определять политики, управляющие отображением определенных строк данных и управлением для одной или нескольких ролей. Безопасность на уровне строк добавляет дополнительный фильтр в таблицу базы данных Базы данных Azure для PostgreSQL. Когда пользователь пытается выполнить действие в таблице, этот фильтр применяется перед критериями запроса или другими фильтрами, а данные сужают или отклоняют в соответствии с политикой безопасности. Вы можете создать политики безопасности на уровне строк для определенных команд, таких как SELECT, INSERTUPDATEи , или DELETEуказать их для всех команд. Варианты использования безопасности на уровне строк включают реализации, совместимые с PCI, классифицированные среды и общие хостинги или мультитенантные приложения.

Только пользователи с SET ROW SECURITY правами могут применять права безопасности строк к таблице. Владелец таблицы может задать безопасность строк в таблице. Подобно OVERRIDE ROW SECURITY, в настоящее время это право является подразумеваемым. Защита на уровне строк не переопределяет существующие разрешения GRANT. Он добавляет более точный уровень управления. Например, настройка ROW SECURITY FOR SELECT, разрешающая данному пользователю доступ только к строкам, предоставляет этому пользователю доступ только в том случае, если у него также есть привилегии SELECT для соответствующего столбца или таблицы.

В следующем примере показано, как создать политику, которая гарантирует доступ только к строкам для определенной учетной записи только для членов настраиваемой ролируководителя. Код в следующем примере используется в документации PostgreSQL.

CREATE TABLE accounts (manager text, company text, contact_email text);

ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;

CREATE POLICY account_managers ON accounts TO managers
  USING (manager = current_user);

Выражение USING неявно добавляет выражение WITH CHECK, гарантируя, что участники роли manager не могут выполнять операции SELECT, DELETE или UPDATE над строками, принадлежащими другим manager’ам, а также не могут INSERT новые строки, принадлежащие другому manager’у.

Политику безопасности строк можно удалить с помощью DROP POLICY команды, как показано в следующем примере:

DROP POLICY account_managers ON accounts;

Хотя вы можете удалить политику, диспетчер ролей по-прежнему не может просматривать данные, принадлежащие любому другому менеджеру. Это ограничение существует, так как политика безопасности на уровне строк по-прежнему включена в таблице учетных записей. Если безопасность на уровне строк включена по умолчанию, PostgreSQL использует политику запрета по умолчанию.

Вы можете отключить безопасность на уровне строк, как показано в следующем примере:

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

Обход безопасности на уровне строк

PostgreSQL поддерживает разрешения BYPASSRLS и NOBYPASSRLS, которые можно назначать ролям. NOBYPASSRLS назначается по умолчанию. Для вновь подготовленных серверов в База данных Azure для PostgreSQL привилегия обхода защиты на уровне строк (BYPASSRLS) реализована следующим образом:

  • Для серверов с версиями Postgres 16 и более поздних версий мы следуйте стандартному поведению PostgreSQL 16. Неадминистративные пользователи, созданные ролью администратора azure_pg_admin, могут при необходимости создавать роли с атрибутом или привилегией BYPASSRLS.

  • Для серверов Postgres 15 и более ранних версий можно использовать azure_pg_admin пользователя для выполнения административных задач, требующих привилегии BYPASSRLS. Однако вы не можете создавать пользователей безадминистратора с привилегией BypassRLS, так как роль администратора не имеет привилегий суперпользователя, как обычно в облачных службах PaaS PostgreSQL.

Связанный контент

  • Last updated on