Azure 托管 Redis 提供基于 Redis Enterprise 软件的全托管内存数据存储。 部署此服务时，请务必遵循安全最佳做法来保护缓存的数据、配置和基础结构。
本文中的安全建议实施Zero Trust原则：“显式验证”、“使用最小特权访问”和“假设违规”。 有关全面的Zero Trust指南，请参阅 Zero Trust 指导中心。
本文提供安全建议来帮助保护Azure托管 Redis 部署。
数据保护
保护静态和传输中的数据对于保持缓存的机密性和完整性至关重要。
保持禁用非 TLS 访问：Azure托管 Redis 默认要求对所有连接使用 TLS 1.2 或 1.3，确保传输中的数据已加密。 保持禁用非 TLS 访问，以防止未加密的通信。 如果为旧版应用程序启用非 TLS 访问，请计划将这些应用程序迁移到已启用 TLS 的客户端。 请参阅 Azure 托管 Redis 的 TLS 配置。
使用客户管理的密钥进行磁盘加密：默认情况下，Azure托管 Redis 使用Microsoft托管密钥（MMK）加密持久性数据和 OS 磁盘。 若要进行其他控制，请将客户管理的密钥（CMK）配置为使用Azure Key Vault包装加密密钥。 CMK 需要一个用户分配的托管身份以及一个启用了清除保护和软删除功能的 Azure 密钥保管库实例。 请参阅 使用客户托管密钥为 Azure 托管 Redis 实例配置磁盘加密。
启用数据暂留以实现恢复：配置 RDB 或 AOF 持久性以防止数据丢失，避免意外故障。 持久性将数据写入静态加密的托管磁盘。 数据持久性不是备份或时间点恢复（PITR）功能，如果损坏的数据写入 Redis，它也会被持久化。 对于真正的备份，请使用导出功能。 请参阅 配置Azure托管 Redis 实例的数据持久性。
使用导出的数据备份：利用导出功能将您的 Redis 数据定期备份到 Azure Storage 帐户。 导出提供时间点数据副本，这些副本可以导入到新的缓存实例进行灾难恢复。 有关 Azure 托管 Redis 中导入和导出数据的详细信息，请参阅导入和导出数据。
网络安全
将Azure托管 Redis 实例与公共 Internet 隔离并控制网络访问。
使用专用终结点：部署Azure Private Link以通过虚拟网络中的专用 IP 地址连接到Azure托管 Redis 实例。 专用终结点可消除对公共 Internet 的暴露，并保留Microsoft主干网络上的流量。 建议使用专用终结点来保护网络层Azure托管 Redis 资源。 请参阅 Azure 托管 Redis 和 Azure Private Link。
禁用公用网络访问：使用专用终结点时，使用
publicNetworkAccess属性禁用公共网络访问，以确保所有流量都流经虚拟网络。 此配置可防止从 Internet 进行未经授权的访问。 禁用publicNetworkAccess并通过使用 VNet、专用终结点和专用链接保护缓存，这是一种最安全的选择。 请参阅 “启用公用网络访问”。
身份和访问管理
正确配置身份验证和授权，以控制对 Azure 托管 Redis 实例的访问。
使用Microsoft Entra ID身份验证：为无密码身份验证配置Microsoft Entra ID，而不是访问密钥。 Microsoft Entra身份验证提供增强的安全性、集中式标识管理和自动令牌刷新。 Azure托管 Redis 在创建新缓存时默认启用托管标识。 不支持Microsoft Entra组，因此请将单个用户或服务主体添加到 Redis 用户列表中。 请参阅 使用 Microsoft Entra ID 进行 Azure 托管 Redis 的缓存身份验证。
禁用访问密钥身份验证：配置Microsoft Entra ID身份验证后，禁用访问密钥身份验证，以降低凭据泄露的风险。 访问密钥是静态凭据，如果泄露，可能会导致泄密风险。 更改此设置时，无论身份验证方法如何，所有现有客户端连接都会终止，因此请实现正确的重新连接重试机制。 请参阅 在缓存上禁用访问密钥身份验证。
添加授权用户或服务主体：配置哪些Microsoft Entra用户或服务主体可以通过在Azure门户中将其添加到 Redis 用户列表来访问缓存。 仅为需要的身份授予访问权限，以遵循最小特权原则。 请参阅 向缓存添加用户或服务主体。
应用基于 RBAC 的最小特权访问：使用 Azure 基于角色的访问控制（RBAC）来管理可以通过 Azure 门户和 API 管理 Azure 管理的 Redis 资源的用户。 在适当的范围内分配角色，以将权限限制为必要的最低限度。 请参阅访问控制（IAM）。
使用托管标识进行Azure资源访问：当Azure托管 Redis 实例需要访问其他Azure资源（例如客户管理的密钥Azure Key Vault）时，请使用托管标识。 使用托管身份，则无需管理凭据。 请参阅 “配置磁盘加密”。
定期重新生成访问密钥：如果必须使用访问密钥，请定期重新生成它们以限制潜在密钥公开的影响。 Azure托管 Redis 支持两个访问密钥，因此无需停机即可轮换密钥。 请参阅身份验证。
日志记录和监控
实施全面的日志记录和监视，以检测安全威胁并解决问题。
启用连接日志：配置Azure诊断设置，以记录到缓存的客户端连接。 连接记录谁正在连接，以及这些连接的时间戳，使你能够识别安全漏洞的范围并执行安全审核。 请参阅 Azure Monitor 诊断设置。
活动日志：查看Azure活动日志以跟踪对 Azure 托管 Redis 资源执行的管理操作。 活动日志可帮助你确定执行了哪些操作、谁启动了这些操作，以及出于安全审核目的而发生的操作的时间。 请参阅 活动日志。
创建安全警报：设置Azure Monitor警报，以通知异常使用模式、连接异常或影响缓存的潜在安全漏洞。 根据连接计数峰值、身份验证失败或异常数据传输模式配置警报。 请参阅 警报。
Integrate with Azure Monitor：配置 Azure Monitor 以从 Azure 托管 Redis 实例中的日志和指标进行收集和分析。 使用Log Analytics工作区对连接日志运行查询并识别安全模式。 请参阅 监视。
合规性和治理
实施治理控制，以确保Azure托管 Redis 部署满足组织和法规要求。
使用 Azure Policy 确保合规：部署 Azure Policy 以强制实施组织标准，并在大规模上评估合规性。 使用内置策略定义审核和强制实施安全配置。
可用资源锁：应用资源锁以防止意外删除或修改关键Azure托管 Redis 资源。 使用 CanNotDelete 锁可以防止删除，同时允许修改；或者，使用 ReadOnly 锁可以实现完全保护。 请参阅 锁。
为资源组织使用标记：将标记应用于Azure托管 Redis 资源，以支持安全治理、成本跟踪和合规性报告。 标记可帮助你按安全分类、环境或合规性要求组织资源。 请参阅 标记。
备份和恢复
实施备份和恢复机制，确保业务连续性和数据保护。
配置数据持久性：启用 RDB 或 AOF 暂留，以便在意外失败后自动恢复数据。 RDB 持久性会保存定期快照，但性能影响最小，适用于大多数方案。 AOF 持久性记录每个写入操作，以尽量减少数据丢失，但可能会影响吞吐量。 请参阅 配置Azure托管 Redis 实例的数据持久性。
使用活动异地复制进行灾难恢复：对于关键工作负荷，启用活动异地复制以跨多个Azure区域复制数据。 如果整个区域不可用，异地复制可提供业务连续性。 主动异地复制与数据持久化不兼容，因此请选择异地复制以实现跨区域弹性或选择持久化以实现单区域持久性。 请参阅 设置主动异地复制。
基于导出的备份策略：使用 PowerShell 或Azure CLI创建自动化脚本，以便定期导出数据以进行备份。 导出的数据可以导入到新的缓存实例，以便进行灾难恢复。 有关 Azure 托管 Redis 中导入和导出数据的详细信息，请参阅导入和导出数据。
特定于服务的安全性
Azure 托管 Redis 由于其内存架构而具有独特的安全注意事项。
Azure 托管 Redis 架构
- 选择适当的安全要求层：不同的Azure托管 Redis 层提供不同的功能。 所有层都支持专用终结点、TLS 加密和Microsoft Entra身份验证。 Flash Optimized 层将某些数据存储在使用Microsoft托管密钥加密的 NVMe 磁盘上。 Azure 托管 Redis 提供的内置高可用性通过在两个节点之间分布主分片和副本分片实现；在多个可用性区域（Availability Zone）的区域中，服务具备区域冗余功能。 请参阅 功能比较。
适当使用 Azure 托管 Redis
如果不进行适当的加密，则不要存储敏感数据：虽然Azure托管 Redis 加密暂留磁盘上的静态数据，但服务不会加密内存中的数据。 在将数据写入缓存之前，为高度敏感数据实现应用程序级加密，或者仅对非敏感缓存数据使用服务。 请参阅 数据保护。
不要在应用程序代码中公开访问密钥：将访问密钥存储在Azure Key Vault中或使用Microsoft Entra身份验证，而不是在应用程序代码或配置文件中嵌入访问密钥。 公开的访问密钥可能会导致未经授权的缓存访问。 请参阅 使用Microsoft Entra ID进行缓存身份验证。
不要将Azure托管 Redis 用作主数据存储：Azure托管 Redis 设计为缓存和临时数据存储，而不是永久性主数据库。 始终在持久性数据存储（如Azure SQL Database或Azure Cosmos DB）中维护权威数据。 请参阅 关键方案。