Безопасность в Базе данных Azure для PostgreSQL — гибкий сервер
ОБЛАСТЬ ПРИМЕНЕНИЯ: 
База данных 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. Все данные, включая резервные копии и временные файлы, создаваемые при выполнении запросов, шифруются на диске.
Служба использует режим 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
- 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
Внимание
Недавно возможность создания команд CAST была включена в База данных Azure для PostgreSQL гибком сервере. Чтобы запустить инструкцию CREATE CAST, пользователь должен быть членом группы azure_pg_admin . Обратите внимание, что в настоящее время невозможно удалить cast после его создания.
Ведение журнала аудита в База данных 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 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 на этих объектах, а также права ИСПОЛЬЗОВАНИЯ на всех схемах, даже без явного предоставления. В качестве обходного решения рекомендуется предоставить аналогичные разрешения на более конечный уровень для каждой базы данных и объекта.
Безопасность на уровне строк
Безопасность на уровне строк (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 клиент участвует в выполнении работы шифрования, чтобы получить подтверждение удостоверения. Поэтому проверка подлинности 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) | Description | Эффекты | Version(GitHub) |
|---|---|---|---|
| Администратор Microsoft Entra должен быть подготовлен для гибких серверов PostgreSQL | Аудит подготовки администратора Microsoft Entra для гибкого сервера PostgreSQL, чтобы включить проверку подлинности Microsoft Entra. Проверка подлинности Microsoft Entra позволяет упростить управление разрешениями и централизованное управление удостоверениями пользователей базы данных и других службы Майкрософт | AuditIfNotExists, Disabled | 1.0.0 |
| Аудит с помощью PgAudit должен быть включен для гибких серверов PostgreSQL | Эта политика помогает проверять все гибкие серверы PostgreSQL в вашей среде, которые не включены для использования pgaudit. | AuditIfNotExists, Disabled | 1.0.0 |
| Регулирование подключений должно быть включено для гибких серверов PostgreSQL | Эта политика помогает проверять все гибкие серверы PostgreSQL в вашей среде без включения регулирования подключений. Этот параметр позволяет регулировать временное подключение для каждого IP-адреса для слишком большого количества ошибок входа в пароль | AuditIfNotExists, Disabled | 1.0.0 |
| Развертывание параметров диагностики для гибких серверов PostgreSQL в рабочей области Log Analytics | Развертывает параметры диагностики для гибких серверов PostgreSQL для потоковой передачи в региональную рабочую область Log Analytics при создании или обновлении любого гибкого сервера PostgreSQL, который отсутствует этот параметр диагностики. | DeployIfNotExists, Disabled | 1.0.0 |
| Отключение должно быть зарегистрировано для гибких серверов PostgreSQL | Эта политика помогает проверять гибкие серверы PostgreSQL в вашей среде без log_disconnections | AuditIfNotExists, Disabled | 1.0.0 |
| Принудительное подключение SSL должно быть включено для гибких серверов PostgreSQL | База данных Azure для PostgreSQL поддерживает подключение гибкого сервера База данных Azure для PostgreSQL к клиентским приложениям с помощью протокола SSL. Применение SSL-подключений между гибким сервером базы данных и клиентскими приложениями помогает защитить от атак "человек в середине", зашифровав поток данных между сервером и приложением. Эта конфигурация применяет, что SSL всегда включен для доступа к гибкому серверу PostgreSQL | AuditIfNotExists, Disabled | 1.0.0 |
| Геоизбыточное резервное копирование должно быть включено для гибких серверов База данных Azure для PostgreSQL | База данных Azure для PostgreSQL гибкие серверы позволяют выбрать вариант избыточности для сервера базы данных. Можно задать геоизбыточное хранилище резервных копий, в котором данные хранятся не только в том регионе, в котором размещен сервер, — они также реплицированы в парный регион для обеспечения восстановления в случае сбоя в регионе. Настройка геоизбыточного хранилища для резервного копирования разрешена только во время создания сервера. | Audit, Disabled | 1.0.0 |
| Контрольные точки журнала должны быть включены для гибких серверов PostgreSQL | Эта политика помогает проверять все гибкие серверы PostgreSQL в вашей среде без log_checkpoints настройки | AuditIfNotExists, Disabled | 1.0.0 |
| Подключения к журналам должны быть включены для гибких серверов PostgreSQL | Эта политика помогает проверять все гибкие серверы PostgreSQL в вашей среде без log_connections параметров | AuditIfNotExists, Disabled | 1.0.0 |
| Серверы PostgreSQL FlexIble должны использовать ключи, управляемые клиентом, для шифрования неактивных данных | Используйте управляемые клиентом ключи для управления шифрованием неактивных гибких серверов PostgreSQL. По умолчанию неактивные данные шифруются с помощью ключей, управляемых службой, но для соблюдения нормативных требований обычно требуются ключи, управляемые клиентом. Ключи, управляемые клиентом, позволяют шифровать данные с помощью ключа Azure Key Vault, создателем и владельцем которого являетесь вы. У вас есть полный контроль и ответственность за жизненный цикл ключа, включая смену и управление | Audit, Deny, Disabled | 1.0.0 |
| Гибкие серверы PostgreSQL должны работать под управлением TLS версии 1.2 или более поздней | Эта политика помогает проверять все гибкие серверы PostgreSQL в вашей среде, которая работает с версией TLS меньше 1.2. | AuditIfNotExists, Disabled | 1.0.0 |
| Частная конечная точка должна быть включена для гибких серверов PostgreSQL | Подключения к частной конечной точке обеспечивают защищенный обмен данными, предоставляя возможность частного доступа к Базе данных Azure для PostgreSQL. Настройте подключение к частной конечной точке, чтобы обеспечить доступ к трафику, исходящему только из известных сетей, и запретить доступ ко всем другим IP-адресам, включая Azure. | AuditIfNotExists, Disabled | 1.0.0 |
Пользовательские определения политик
Пользовательские политики можно точно адаптировать в соответствии с конкретными требованиями вашей организации, включая уникальные политики безопасности или мандаты соответствия требованиям. Благодаря пользовательским политикам вы полностью управляете логикой и параметрами политики, что позволяет создавать сложные и подробные определения политик.