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

Статья
04/03/2024

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

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

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

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

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

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

Служба использует 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 — экземпляр гибкого сервера создается с тремя ролями по умолчанию. Эти роли можно просмотреть, выполнив команду:

SELECT rolname FROM pg_roles;

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

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

postgres=> CREATE USER demouser PASSWORD 'password123';

Роль администратора никогда не должна использоваться приложением.

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

Примечание.

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

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

postgres=> \x
Expanded display is on.
postgres=> 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 . Гибкий сервер также доступен с помощью База данных 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, но не любую другую базу данных на сервере. Рекомендуется дополнительно вместо предоставления этому пользователю всех привилегий в этой базе данных и его объектах, чтобы предоставить более выборочные разрешения, такие как SELECT,INSERT,EXECUTE и т. д. Дополнительные сведения о привилегиях в базах данных PostgreSQL см. в командах GRANT и REVOKE в документации 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 позволяет суперпользователям создавать подписки.

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

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

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

Ниже приведен пример, показывающий, как создать политику, которая гарантирует доступ только к строкам для определенной учетной записи только члены созданной роли "manager". Код, приведенный в следующем примере, был предоставлен общий доступ в документации 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 для PostgreSQL — гибкий сервер, обходя привилегии безопасности на уровне строк (BYPASSRLS), реализуется следующим образом:

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

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

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

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

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

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

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

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

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

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

postgres=> ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE