Azure Database for PostgreSQL（灵活服务器）中的安全性

适用于： Azure Database for PostgreSQL 灵活服务器

可通过多层安全性来帮助保护 Azure Database for PostgreSQL 灵活服务器实例上的数据。 本文概述了这些安全选项。

随着组织越来越依赖数据库中存储的数据来推动关键决策活动以提高竞争优势，因此对坚实数据库安全措施的需求从未如此重要。 安全失误可能会引发灾难性后果，包括公开机密数据，导致组织声誉受损。

信息保护和加密

Azure Database for PostgreSQL 灵活服务器通过两种方式加密数据：

• 传输中的数据：Azure Database for PostgreSQL 灵活服务器使用安全套接字层和传输层安全性 (SSL/TLS) 加密传输中的数据。 默认情况下，强制实施加密。 有关使用 SSL\TLS 的连接安全性的详细信息，请参阅本文档。 为了提高安全性，可以选择启用 Azure Database for PostgreSQL - 灵活服务器中的 SCRAM 身份验证。

  尽管非常不建议这样做，但如果需要，由于旧客户端的不兼容性，可以选择通过将require_secure_transport服务器参数更新为 OFF，来对 Azure Database for PostgreSQL 灵活服务器连接禁用 TLS\SSL。 还可以通过设置 ssl_max_protocol_version 服务器参数来设置 TLS 版本。

• 静态数据：对于存储加密，Azure Database for PostgreSQL 灵活服务器使用 FIPS 140-2 验证的加密模块。 数据（包括备份和运行查询时创建的临时文件）在磁盘上进行加密。

  该服务使用 Galois/Counter Mode (GCM) 模式和 Azure 存储加密中包含的 AES 256 位密码，并且密钥是由系统管理的。 这类似于其他静态加密技术，如 SQL Server 或 Oracle 数据库中的透明数据加密。 存储加密始终处于启用状态，无法禁用。

网络安全性

运行 Azure Database for PostgreSQL 灵活服务器时，有两个主要的网络选项：

• 专用访问：可将服务器部署到 Azure 虚拟网络中。 Azure 虚拟网络帮助提供专用的安全网络通信。 虚拟网络中的各个资源可通过专用 IP 地址进行通信。 有关详细信息，请参阅 Azure Database for PostgreSQL 灵活服务器网络概述。

  通过网络安全组中的安全规则，可以筛选可流入和流出虚拟网络子网和网络接口的流量类型。 有关详细信息，请参阅网络安全组概述。

• 公共访问：可通过公共终结点访问服务器。 公共终结点是可公开解析的 DNS 地址。 通过防火墙访问它是安全的，默认情况下，防火墙会阻止所有连接。

  IP 防火墙规则基于每个请求的起始 IP 地址授予对服务器的访问权限。 有关详细信息，请参阅防火墙规则概述。

Microsoft Defender for Cloud 支持

适用于开源关系数据库的 Microsoft Defender 可以检测异常活动，这些活动指示有人企图以非寻常或可能有害的方式访问或恶意利用数据库。 Defender for Cloud 提供针对异常活动的安全警报，以便检测潜在威胁，并在发生威胁时做出响应。 启用此计划时，Defender for Cloud 会在检测到异常的数据库访问和查询模式以及可疑的数据库活动时发出警报。

这些警报显示在 Defender for Cloud 的“安全警报”页面中，并包括：

• 触发警报的可疑活动的详细信息
• 关联的 MITRE ATT&CK 技巧
• 有关如何调查和缓解威胁的建议操作
• 继续使用 Microsoft Sentinel 进行调查的选项

Microsoft Defender for Cloud 和暴力攻击

尽管暴力攻击是最不复杂的黑客方法，但它是最常见且相当成功的黑客方法之一。 这种攻击背后的理论是，如果你尝试无限次猜测密码，最终一定会猜对。 Microsoft Defender for Cloud 检测到暴力攻击时，会触发警报，让你意识到发生了暴力攻击。 它还可以将简单的暴力攻击与对有效用户的暴力攻击或成功的暴力攻击分开。

若要从 Microsoft Defender 计划获取警报，首先需要启用它，如以下部分所示。

启用 Microsoft Defender for Cloud 的增强安全性

1. 在 Azure 门户中，导航到左侧窗格中的“安全性”菜单
2. 选择 Microsoft Defender for Cloud
3. 从右窗格中，选择“启用”。

访问管理

大规模管理 Azure Database for PostgreSQL 灵活服务器数据库访问权限的最佳方式是使用角色的概念。 角色可以是一个数据库用户，也可以是一组数据库用户。 角色可以拥有数据库对象，并将对这些对象的特权分配给其他角色，以控制谁有权访问哪些对象。 还可以将某个角色中的成员身份授予另一个角色，从而允许该成员角色使用分配给另一个角色的特权。 通过 Azure Database for PostgreSQL 灵活服务器，可直接向数据库用户授予权限。 作为一种良好的安全做法，建议根据最低应用程序和访问权限要求创建具有特定权限集的角色。 然后，可以将相应的角色分配给每个用户。 角色用于强制实施访问数据库对象所需的最低特权模型。

除 PostgreSQL 创建的内置角色外，还使用定义的三个默认角色创建 Azure Database for PostgreSQL 灵活服务器实例。 可以运行以下命令来查看这些角色：

SELECT rolname FROM pg_roles;

下面列出了这些角色：

• azure_pg_admin
• azuresu
• 管理员角色

创建 Azure Database for PostgreSQL 灵活服务器实例时，为管理员角色提供凭据。 可以通过此管理员角色创建更多 PostgreSQL 角色。

例如，下面我们可以创建一个名为“demouser”的示例用户/角色

 CREATE USER demouser PASSWORD password123;

应用程序绝不应使用管理员角色。

在基于云的 PaaS 环境中，对 Azure Database for PostgreSQL 灵活服务器超级用户帐户的访问仅限于云操作员控制平面操作。 因此，azure_pg_admin 帐户作为伪超级用户帐户存在。 管理员角色是 azure_pg_admin 角色的成员。
但是，服务器管理员帐户不属于 azuresu 角色，该角色具有超级用户特权且用于执行控制平面操作。 由于此服务是托管的 PaaS 服务，因此只有 Microsoft 是超级用户角色的一部分。

可以定期审核服务器中的角色列表。 例如，可以使用 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 Database for PostgreSQL - 灵活服务器中的审核日志记录也适用于 Azure Database for PostgreSQL - 灵活服务器以跟踪数据库中的活动。

控制架构访问

在 Azure Database for PostgreSQL 灵活服务器中新建的数据库在数据库的公共架构中具有一组默认特权，允许所有数据库用户和角色创建对象。 为了更好地限制对在 Azure Database for 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 数据库中的权限的详细信息，请参阅 PostgreSQL 文档中的 GRANT 和 REVOKE 命令。

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 还引入了新的和改进的内置角色。 PostgreSQL 16 中的新 pg_use_reserved_connections 角色允许使用通过 reserved_connections 保留的连接槽。pg_create_subscription 角色允许超级用户创建订阅。

行级别安全性

行级别安全性 (RLS) 是 Azure Database for PostgreSQL 灵活服务器安全功能，它使数据库管理员能够定义策略来控制控制特定数据行如何针对一个或多个角色显示和操作。 行级别安全性是可应用于 Azure Database for PostgreSQL 灵活服务器数据库表的其他筛选器。 当用户尝试对表执行操作时，此筛选器会在查询条件或其他筛选之前应用，并且根据安全策略缩小数据范围或拒绝数据。 可以为 SELECT、INSERT、UPDATE 和 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 子句，确保管理员角色的成员不能对属于其他管理员的行执行 SELECT、DELETE 或 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 灵活服务器中新预配的服务器，实现绕过行级别安全权限 (BYPASSRLS) 的方式如下所示：

• 对于 Postgres 16 及更高版本的服务器，我们遵循标准 PostgreSQL 16 行为。 通过由 azure_pg_admin 管理员角色创建的非管理用户，可根据需要创建具有 BYPASSRLS 属性\特权的角色。
• 对于 Postgres 15 及更低版本的服务器， ，可以使用 azure_pg_admin 用户执行需要 BYPASSRLS 特权的管理任务，但无法创建具有 BypassRLS 特权的非管理员用户，因为管理员角色没有超级用户权限，这在基于云的 PaaS PostgreSQL 服务中很常见。

更新密码

为了提高安全性，最好是定期轮换管理员密码和数据库用户密码。 建议使用采用大小写、数字和特殊字符的强密码。

使用 SCRAM

加盐质询响应身份验证机制 (SCRAM) 添加了几项用于抵御彩虹表攻击、中间人攻击和存储密码攻击的关键安全功能，同时还增加了对多种哈希算法和包含非 ASCII 字符的密码的支持，从而显著提高了基于密码的用户身份验证的安全性。

在 SCRAM 身份验证中，客户端会参与执行加密工作，以便生成标识证明。 因此，SCRAM 身份验证会将其客户端的某些计算成本卸载，在大多数情况下卸载的是应用程序服务器。 除了更强大的哈希算法外，采用 SCRAM 还通过阻止服务器的 CPU 重载来计算密码哈希，从而防范针对 PostgreSQL 的分布式拒绝服务 (DDoS) 攻击。

如果你的客户端驱动程序支持 SCRAM，则可以使用 SCRAM 设置对 Azure Database for PostgreSQL 灵活服务器的访问（scram-sha-256 与默认值 md5）。

重置管理员密码

请按操作指南重置管理员密码。

更新数据库用户密码

可以使用客户端工具来更新数据库用户密码。
例如，

ALTER ROLE demouser PASSWORD 'Password123!';
ALTER ROLE

Azure Policy 支持

Azure Policy 可帮助实施组织标准并大规模评估合规性。 Azure Policy 通过其合规性仪表板提供一个聚合视图来评估环境的整体状态，并允许用户按资源、按策略粒度向下钻取。 它还通过对现有资源的批量修正以及对新资源的自动修正，帮助资源符合规范。

内置策略定义

内置策略由 Microsoft 开发和测试，以确保它们符合常见标准和最佳做法，无需额外配置即可快速部署，因此非常适合标准合规性要求。 内置策略通常涵盖广为认可的标准和合规性框架。

以下部分提供了 Azure Database for PostgreSQL - 灵活服务器的 Azure Policy 内置策略定义的索引。 使用“源”列中的链接查看 Azure Policy GitHub 存储库上的源。

自定义策略定义

可以精确定制自定义策略，以满足组织的特定要求，包括独特的安全策略或合规性要求。 借助自定义策略，你可以完全控制策略逻辑和参数，从而实现复杂和细化的策略定义。

相关内容

• IP 地址的防火墙规则
• 使用 Azure Database for PostgreSQL - 灵活服务器专用访问网络
• Microsoft Entra 身份验证