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

2025-06-30

ПРИМЕНЯЕТСЯ К: База данных Azure для PostgreSQL — гибкий сервер

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

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

Защита и шифрование информации

Гибкий сервер базы данных Azure для PostgreSQL шифрует данные двумя способами:

Передаваемые данные: гибкий сервер Базы данных Azure для PostgreSQL шифрует передаваемые данные с помощью уровня Secure Sockets и транспортного уровня безопасности (SSL/TLS). Шифрование применяется по умолчанию. Дополнительные сведения о безопасности подключения с помощью SSL\TLS см. в этой документации. Для повышения безопасности можно включить проверку подлинности SCRAM в гибком сервере Базы данных Azure для PostgreSQL.

Хотя это не рекомендуется, при необходимости из-за несовместимости устаревшего клиента можно разрешить подключения TLS\SSL и не TLS/SSL к гибкому серверу Базы данных Azure для PostgreSQL, обновив require_secure_transport параметр сервера до OFF. Кроме того, можно задать версию TLS, задав ssl_max_protocol_version параметры сервера.
Данные в состоянии покоя: Для шифрования хранилища сервер Azure Database для PostgreSQL использует проверенный модуль шифрования FIPS 140-2. Все данные, включая резервные копии и временные файлы, создаваемые при выполнении запросов, шифруются на диске.

Служба использует режим Galois/Counter Mode (GCM) с 256-разрядным шифром AES, включенным в шифрование хранилища Azure, и ключи управляются системой. Это похоже на другие технологии шифрования неактивных данных, такие как прозрачное шифрование данных в базах данных SQL Server или Oracle. Шифрование хранилища всегда включено, и его нельзя отключить.

Безопасность сети

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

Частный доступ. Сервер можно развернуть в виртуальной сети Azure. Виртуальные сети Azure используют частное и безопасное сетевое подключение. Это позволит ресурсам в виртуальной сети взаимодействовать через частные IP-адреса. Дополнительные сведения см. в обзоре сетевых возможностей гибкого сервера Базы Данных Azure для PostgreSQL.

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

Правила брандмауэра для IP-адресов предоставляют доступ к серверам на основе исходного IP-адреса каждого запроса. Дополнительные сведения см. в обзоре правил брандмауэра.

Поддержка Microsoft Defender для облака

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

Эти оповещения отображаются на странице оповещений системы безопасности Defender для облака и включают:

Сведения о подозрительном действии, активировав их
Связанная тактика MITRE ATT&CK
Рекомендуемые действия по изучению и устранению угрозы
Варианты продолжения расследований с помощью Microsoft Sentinel

Microsoft Defender для облака и атаки методом подбора

Атака методом подбора является одним из самых распространенных и довольно успешных, хотя и одним из наиболее простых, методов взлома. Теория такой атаки заключается в том, что если вы принимаете бесконечное количество попыток угадать пароль, вы привязаны к правому в конечном итоге. Когда Microsoft Defender для Облака обнаруживает атаку методом подбора, он активирует оповещение о том, что произошла атака подбора. Он также способен отличать простую атаку методом подбора от атаки методом подбора в отношении допустимого пользователя или от успешной атаки методом подбора.

Чтобы получить оповещения из плана Microsoft Defender, сначала необходимо включить его , как показано в следующем разделе.

Включение расширенной безопасности с помощью Microsoft Defender для облака

На портале Azure перейдите в меню "Безопасность" в левой области.
Выберите Microsoft Defender для Облака.
В правой области выберите Включить.

Примечание.

Если в плане Microsoft Defender включена функция "реляционные базы данных с открытым исходным кодом", вы увидите, что Microsoft Defender автоматически включается по умолчанию для ресурса гибкого сервера База данных Azure для PostgreSQL.

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

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

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

SELECT rolname FROM pg_roles;

Ниже перечислены роли.

Azure_pg_admin
Азуресу
Роль администратора

При создании гибкого экземпляра сервера Базы данных 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

Внимание

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

Гибкий сервер Базы данных Azure для PostgreSQL поддерживает только команды CAST с помощью параметров WITH FUNCTION и WITH INOUT. Параметр "БЕЗ ФУНКЦИИ" не поддерживается.

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

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

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

Чтобы запретить пользователям базы данных приложений создавать объекты в общедоступной схеме, отмените разрешения на схему 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'
```
Назначьте роль с полномочиями на подключение и выбор пользователю.
```
GRANT Test_db_user TO user1;
```

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

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

С Postgres версии 15 владение общедоступной схемой было изменено на новую роль pg_database_owner. Он позволяет каждому владельцу базы данных принадлежать общедоступной схеме базы данных.
Дополнительные сведения см. в заметках о выпуске PostgreSQL.

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

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

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

Внимание

Гибкий сервер базы данных Azure для PostgreSQL не позволяет предоставлять пользователям атрибут pg_write_all_data, который дает возможность пользователю записывать все данные (таблицы, представления, последовательности), как если бы у него были права INSERT, UPDATE и DELETE на эти объекты, а также права USAGE на все схемы, даже без явного предоставления. В качестве обходного решения рекомендуется предоставить аналогичные разрешения на более конечный уровень для каждой базы данных и объекта.

Улучшенное управление для 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, INSERT, UPDATE и DELETE, указать его для команд ALL. Варианты использования безопасности на уровне строк включают реализации, совместимые с PCI, классифицированные среды и общие приложения размещения или мультитенантные приложения.

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

Приведен пример, демонстрирующий, как создать политику, которая гарантирует, что доступ к строкам для определенной учетной записи имеют только участники специально созданной роли "manager"role. Код, приведенный в следующем примере, был представлен в документации 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 предложение, гарантируя, что члены роли руководителя не могут выполнять SELECTDELETEоперации UPDATE с строками, принадлежащими другим менеджерам, и не INSERT могут создавать новые строки, принадлежащие другому руководителю. Вы можете удалить политику безопасности строк с помощью команды DROP POLICY, как в своем примере:



DROP POLICY account_managers ON accounts;

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

ALTER TABLE accounts DISABLE ROW LEVEL SECURITY;

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

PostgreSQL имеет разрешения BYPASSRLS и NOBYPASSRLS, которые могут быть назначены роли; NOBYPASSRLS назначается по умолчанию. При использовании новых подготовленных серверов в Azure Database for PostgreSQL Flexible Server обход привилегий безопасности на уровне строк (BYPASSRLS) реализуется следующим образом:

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

Обновление паролей

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

Использование SCRAM

Механизм аутентификации с соленым обменом вызовами (SCRAM) значительно повышает безопасность аутентификации пользователей на основе паролей, добавляя несколько ключевых функций безопасности. Эти функции препятствуют атакам через радужные таблицы, атакам типа «человек посередине» и атакам на сохраненные пароли, а также обеспечивают поддержку нескольких алгоритмов хеширования и паролей, содержащих символы, отличные от ASCII.

При проверке подлинности SCRAM клиент участвует в выполнении работы шифрования, чтобы получить подтверждение удостоверения. Поэтому проверка подлинности SCRAM выгружает некоторые вычислительные затраты на своих клиентов, которые в большинстве случаев являются серверами приложений. Внедрение SCRAM в дополнение к более строгому хэш-алгоритму обеспечивает также защиту от распределенных атак типа "отказ в обслуживании" (DDoS) против PostgreSQL, предотвращая перегрузку ЦП сервера для вычисления хэшей паролей.

Если драйвер клиента поддерживает SCRAM , вы можете настроить доступ к гибкому серверу Базы данных Azure для PostgreSQL с помощью SCRAM как scram-sha-256 и по умолчанию md5.

Сброс пароля администратора

Следуйте инструкциям по сбросу пароля администратора.

Обновление пароля пользователя базы данных

Для обновления паролей пользователей базы данных можно использовать клиентские средства.
Например,

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Поддержка службы "Политика Azure"

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

Встроенные определения политик

Встроенные политики разрабатываются и тестируются корпорацией Майкрософт, обеспечивая соответствие стандартным стандартам и рекомендациям, быстро развертывать их без необходимости дополнительной настройки, что делает их идеальными для стандартных требований к соответствию. Встроенные политики часто охватывают широко признанные стандарты и платформы соответствия.

В приведенном ниже разделе приведен индекс встроенных определений политик Azure для гибкого сервера Базы данных Azure для PostgreSQL. Чтобы просмотреть исходный репозиторий GitHub для службы "Политика Azure", перейдите по ссылке в столбце Источник.

Имя (портал Azure)	Описание	Эффекты	Версия(GitHub)
Администратор Microsoft Entra должен быть подготовлен для гибких серверов PostgreSQL	Аудит подготовки администратора Microsoft Entra для гибкого сервера PostgreSQL, чтобы включить проверку подлинности Microsoft Entra. Проверка подлинности Microsoft Entra позволяет упростить управление разрешениями и централизованное управление удостоверениями пользователей базы данных и других службы Майкрософт	AuditIfNotExists, отключено	1.0.0
Аудит с помощью PgAudit должен быть включен для гибких серверов PostgreSQL	Эта политика помогает проверять все гибкие серверы PostgreSQL в вашей среде, которые не включены для использования pgaudit.	AuditIfNotExists, отключено	1.0.0
Регулирование подключений должно быть включено для гибких серверов PostgreSQL	Эта политика помогает проверять все гибкие серверы PostgreSQL в вашей среде без включения регулирования подключений. Этот параметр позволяет регулировать временное подключение для каждого IP-адреса для слишком большого количества ошибок входа в пароль	AuditIfNotExists, отключено	1.0.0
Развертывание параметров диагностики для гибких серверов PostgreSQL в рабочей области Log Analytics	Развертывает параметры диагностики для гибких серверов PostgreSQL для потоковой передачи в региональную рабочую область Log Analytics при создании или обновлении любого гибкого сервера PostgreSQL, который отсутствует этот параметр диагностики.	РазвернутьЕслиНеСуществует, Отключено	1.0.0
Отключение должно быть зарегистрировано для гибких серверов PostgreSQL	Эта политика помогает проверять гибкие серверы PostgreSQL в вашей среде без log_disconnections	AuditIfNotExists, отключено	1.0.0
Принудительное подключение SSL должно быть включено для гибких серверов PostgreSQL	База данных Azure для PostgreSQL поддерживает подключение гибкого сервера База данных Azure для PostgreSQL к клиентским приложениям с помощью протокола SSL. Применение SSL-подключений между гибким сервером базы данных и клиентскими приложениями помогает защитить от атак "человек в середине", зашифровав поток данных между сервером и приложением. Эта конфигурация применяет, что SSL всегда включен для доступа к гибкому серверу PostgreSQL	AuditIfNotExists, отключено	1.0.0
Геоизбыточное резервное копирование должно быть включено для гибких серверов Базы данных Azure для PostgreSQL	База данных Azure для PostgreSQL гибкие серверы позволяют выбрать вариант избыточности для сервера базы данных. Можно задать геоизбыточное хранилище резервных копий, в котором данные хранятся не только в том регионе, в котором размещен сервер, — они также реплицированы в парный регион для обеспечения восстановления в случае сбоя в регионе. Настройка геоизбыточного хранилища для резервного копирования разрешена только во время создания сервера.	Аудит, отключено	1.0.0
Контрольные точки журнала должны быть включены для гибких серверов PostgreSQL	Эта политика помогает проверять все гибкие серверы PostgreSQL в вашей среде без log_checkpoints настройки	AuditIfNotExists, отключено	1.0.0
Подключения к журналам должны быть включены для гибких серверов PostgreSQL	Эта политика помогает проверять все гибкие серверы PostgreSQL в вашей среде без log_connections параметров	AuditIfNotExists, отключено	1.0.0
Серверы PostgreSQL FlexIble должны использовать ключи, управляемые клиентом, для шифрования неактивных данных	Используйте управляемые клиентом ключи для управления шифрованием неактивных гибких серверов PostgreSQL. По умолчанию неактивные данные шифруются с помощью ключей, управляемых службой, но для соблюдения нормативных требований обычно требуются ключи, управляемые клиентом. Ключи, управляемые клиентом, позволяют шифровать данные с помощью ключа Azure Key Vault, создателем и владельцем которого являетесь вы. У вас есть полный контроль и ответственность за жизненный цикл ключа, включая смену и управление	Аудит, отказ в доступе, отключено	1.0.0
Гибкие серверы PostgreSQL должны работать под управлением TLS версии 1.2 или более поздней	Эта политика помогает проверять все гибкие серверы PostgreSQL в вашей среде, которая работает с версией TLS меньше 1.2.	AuditIfNotExists, отключено	1.0.0
Частная конечная точка должна быть включена для гибких серверов PostgreSQL	Подключения к частной конечной точке обеспечивают защищенный обмен данными, предоставляя возможность частного доступа к Базе данных Azure для PostgreSQL. Настройте подключение к частной конечной точке, чтобы обеспечить доступ к трафику, исходящему только из известных сетей, и запретить доступ ко всем другим IP-адресам, включая Azure.	AuditIfNotExists, отключено	1.0.0

Пользовательские определения политик

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