Compartir a través de

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 地址授予对服务器的访问权限。 有关详细信息,请参阅防火墙规则概述

访问管理

大规模管理 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 灵活服务器中创建 CAST 命令的功能。 请注意,目前该功能按预期运行,但 DROP 语句除外。 换句话说,创建 CAST 后,当前无法将其删除。 我们正在积极努力添加此功能,预计它在不久的将来便可使用。

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 并拥有对该数据库的所有权限,但不包括服务器上任何其他数据库的权限。 建议提供更具选择性的权限,例如 SELECTINSERTEXECUTE 等权限,而不是授予此用户\角色对数据库及其对象的所有权限。有关 PostgreSQL 数据库中的权限的详细信息,请参阅 PostgreSQL 文档中的 GRANTREVOKE 命令。

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 角色允许超级用户创建订阅。

重要

Azure Database for PostgreSQL - 灵活服务器不允许向用户授予 pg_write_all_data 属性,该属性允许用户写入所有数据(表、视图、序列),就好像对这些对象拥有 INSERT、UPDATE 和 DELETE 权限,以及对所有架构拥有 USAGE 权限,即使并未显式向其授权。 作为一种解决方法,建议对每个数据库和对象授予更有限的级别的类似权限。

行级别安全性

行级别安全性 (RLS) 是 Azure Database for PostgreSQL 灵活服务器安全功能,它使数据库管理员能够定义策略来控制控制特定数据行如何针对一个或多个角色显示和操作。 行级别安全性是可应用于 Azure Database for PostgreSQL 灵活服务器数据库表的其他筛选器。 当用户尝试对表执行操作时,此筛选器会在查询条件或其他筛选之前应用,并且根据安全策略缩小数据范围或拒绝数据。 可以为 SELECTINSERTUPDATEDELETE 等特定命令创建行级别安全策略,并为所有命令指定该策略。 行级别安全性的用例包括符合 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 子句,确保管理员角色的成员不能对属于其他管理员的行执行 SELECTDELETEUPDATE 操作,并且不能对属于另一个管理员的新行执行 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 存储库上的源。

名称(Azure 门户) 描述 效果 版本 (GitHub)
应为 PostgreSQL 灵活服务器预配 Microsoft Entra 管理员 对 PostgreSQL 灵活服务器的 Microsoft Entra 管理员预配进行审核来启用 Microsoft Entra 身份验证。 使用 Microsoft Entra 身份验证可简化权限管理,还可集中进行数据库用户和其他 Microsoft 服务的标识管理 AuditIfNotExists、Disabled 1.0.0
应为 PostgreSQL 灵活服务器启用 PgAudit 审核 此策略有助于审核环境中任何未启用使用 pgaudit 的 PostgreSQL 灵活服务器。 AuditIfNotExists、Disabled 1.0.0
应为 PostgreSQL 灵活服务器启用连接限制 此策略帮助审核环境中任何未启用连接限制的 PostgreSQL 灵活服务器。 无效密码登录失败次数过多时,可以使用此设置来按 IP 限制临时连接 AuditIfNotExists、Disabled 1.0.0
将 PostgreSQL 灵活服务器的诊断设置部署到 Log Analytics 工作区 在创建或更新缺少此诊断设置的任何 PostgreSQL 灵活服务器时,将 PostgreSQL 灵活服务器的诊断设置流式部署到区域 Log Analytics 工作区 DeployIfNotExists、Disabled 1.0.0
应为 PostgreSQL 灵活服务器记录断开连接 此策略帮助审核环境中任何未启用 log_disconnections 的 PostgreSQL 灵活服务器 AuditIfNotExists、Disabled 1.0.0
应为 PostgreSQL 灵活服务器启用“强制 SSL 连接” Azure Database for PostgreSQL 支持使用安全套接字层 (SSL) 将 Azure Database for PostgreSQL 灵活服务器连接到客户端应用程序。 通过在数据库灵活服务器与客户端应用程序之间强制实施 SSL 连接,可以加密服务器与应用程序之间的数据流,有助于防止“中间人”攻击。 此配置强制始终启用 SSL 以访问 PostgreSQL 灵活服务器 AuditIfNotExists、Disabled 1.0.0
应为 Azure Database for PostgreSQL 灵活服务器启用异地冗余备份 通过 Azure Database for PostgreSQL 灵活服务器,可以为数据库服务器选择冗余选项。 它可以设置为异地冗余备份存储,其中数据不仅存储在托管服务器的区域内,还可以复制到配对区域,以便在区域发生故障时提供恢复选项。 只能在服务器创建期间为备份配置异地冗余存储 Audit、Disabled 1.0.0
应为 PostgreSQL 灵活服务器启用“记录检查点” 此策略帮助审核环境中任何未启用 log_checkpoints 设置的 PostgreSQL 灵活服务器 AuditIfNotExists、Disabled 1.0.0
应为 PostgreSQL 灵活服务器启用“记录连接” 此策略可帮助审核环境中的 PostgreSQL 灵活服务器,而无需启用 log_connections 设置 AuditIfNotExists、Disabled 1.0.0
PostgreSQL 灵活服务器应使用客户管理的密钥进行静态数据加密 使用客户管理的密钥来管理 PostgreSQL 灵活服务器的静态加密。 默认情况下,使用服务管理的密钥对数据进行静态加密,但为了满足法规符合性标准,通常需要使用客户管理的密钥。 客户管理的密钥允许使用由你创建并拥有的 Azure Key Vault 密钥对数据进行加密。 你可以完全控制并负责关键生命周期,包括轮换和管理 Audit、Deny、Disabled 1.0.0
PostgreSQL 灵活服务器应运行 TLS 版本 1.2 或更高版本 此策略有助于审核环境中运行低于 1.2 的 TLS 版本的任何 PostgreSQL 灵活服务器 AuditIfNotExists、Disabled 1.0.0
应为 PostgreSQL 灵活服务器启用专用终结点 专用终结点连接通过启用到 Azure Database for PostgreSQL 的专用连接来加强安全通信。 配置专用终结点连接,以启用对仅来自已知网络的流量的访问,并防止访问所有其他 IP 地址,包括 Azure 内的地址 AuditIfNotExists、Disabled 1.0.0

自定义策略定义

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