Azure 存储 在单个存储帐户中为 Blob、文件、队列和表提供可扩展且持久的云存储。 由于存储账户可能保存不同敏感度的数据，且常成为数据外泄和勒索软件攻击的目标，因此应采取有意识的措施保护账户、其持有的数据以及访问账户的身份。
本文提供安全建议，帮助保护您的Azure 存储账户。 这些建议适用于该帐户中的所有数据服务（Blob、文件、队列和表）。 关于各项数据服务的具体指导，请参见本文末尾的 相关安全条目 。
本文中的安全建议实施零信任原则：“显式验证”、“使用最低特权访问”和“假设违规”。 有关全面的零信任指南，请参阅 零信任指南中心。
特定于服务的安全性
Azure 存储 具有架构特性，这些特性决定了如何安全部署。 你创建账户时所做的选择——部署模型、类型、冗余和端点配置——以后很难更改，且会影响使用该账户的每个工作负载的安全态势。
存储账户架构
使用 Azure 资源管理器 部署模型：通过使用 Azure 资源管理器 部署模型创建新存储账户。 资源管理器账户支持Azure基于角色的访问控制（RBAC）、托管身份、Microsoft Entra ID数据授权、资源锁定、标签和策略——这些功能在经典部署模型中均不具备。 迁移所有剩余的经典账户。 欲了解更多信息，请参见将经典存储账户迁移至Azure 资源管理器。
按工作负载、环境和敏感度分别创建独立存储账户：为开发、预生产和生产创建独立账户，并为不同敏感性分类的数据创建独立账户。 存储账户既是共享密钥的信任边界，也是策略边界——在同一账户中混合工作负载会增加入侵的范围，并使最小权限访问更难建模。
每个区域使用一个账户以实现区域隔离：将账户置于其消耗负载所在的区域，减少跨区域的数据流动，简化合规边界。 对于多区域设计，应将区域账户与地理冗余存储或对象复制结合，而不是从单一账户服务所有区域。 有关详细信息，请参阅 Azure 存储冗余。
Azure 存储的适当使用
不要将 Azure 存储 账户密钥作为长期应用凭证：Storage 账户密钥赋予账户的完全控制权，且无法被范围限制。 应用程序应使用带托管标识的 Microsoft Entra ID；如果无法使用 Microsoft Entra ID，则应使用短期有效的用户委派共享访问签名（SAS）令牌。 有关详细信息，请参阅 授权访问 Azure 存储中的数据。
不要将Azure 存储用作常规用途机密存储：机密、连接字符串和证书属于Azure 密钥保管库，提供轮换、访问策略和审核线索。 有关详细信息，请参阅 Azure 密钥保管库 概述。
网络安全
存储账户默认是可通过互联网访问的。 减少网络攻击面是保护账户免受未经授权访问、数据泄露和侦查的最有效改变。
禁用对存储账户的公共网络访问：当客户端完全在Azure中或可通过专用链接访问时，将账户的公共网络访问设置为禁用，这样只有通过私有端点的请求才被接受。 有关详细信息，请参阅配置 Azure 存储防火墙和虚拟网络。
使用私有端点访问虚拟网络：私有端点会从你的虚拟网络分配一个私有IP地址到存储账户，并通过Microsoft骨干网路由流量。 结合禁用的公共网络访问，私有终端消除了互联网暴露。 有关详细信息，请参阅对 Azure 存储使用专用端点。
当私有端点不切实际时，用存储防火墙限制公共访问：如果客户端必须通过公共网络访问账户，设置防火墙默认操作为 拒绝 ，只允许特定的IP范围、虚拟网络子网（通过服务端点）或需要访问的资源实例。 有关详细信息，请参阅配置 Azure 存储防火墙和虚拟网络。
在需要访问该帐户时允许受信任的 Microsoft 服务：默认拒绝的防火墙规则会阻止来自其他 Azure 服务（例如 Azure 备份 和 Log Analytics）以及 Azure 门户和诊断管道的请求。 在可信服务列表中添加允许 Azure 服务以访问该存储账户例外，这样你依赖的第一方服务就能访问该账户而无需公开互联网。 有关详细信息，请参阅 授予访问受信任的 Azure 服务的权限。
应向特定资源实例授予访问权限，而不是宽泛地信任受信任的服务：应优先使用资源实例规则，即授权指定的 Azure 资源及其托管标识，而不是采用通用的“允许受信任的 Microsoft 服务”例外设置。 资源实例规则会产生更小的信任表面积。 有关详细信息，请参阅 从 Azure 资源实例授予访问权限。
将存储账户与网络安全边界关联：网络安全边界定义了平台作为服务资源之间的逻辑边界，并默认阻断边界外的流量，提供超越每个账户防火墙规则的深度防御。 欲了解更多信息，请参见 Azure 存储 的网络安全边界。
强制执行最低TLS版本1.2或更高版本：配置存储账户的最低TLS版本，以拒绝协商较旧、已弃用版本的客户端。 更多信息请参见 “配置存储账户的最低所需传输层安全（TLS）版本”。
要求安全传输（HTTPS）：启用 安全传输要求 属性以拒绝任何通过HTTP发出的请求。 这一要求适用于 REST 端点以及 SMB 对 Azure 文件存储 的访问。 更多信息请参见 “存储账户要求安全转移”。
- 某些场景，如较旧的SMB客户端或遗留工具，需要HTTP。 在这种情况下，将这些客户端隔离在受控的网络段中，并尽快将其从HTTP迁移。
限制跨租户对象复制和复制操作：将存储帐户配置为仅允许来自同一租户中的源帐户的复制和对象复制操作，或仅允许来自列入允许列表的源帐户的复制和对象复制操作。 这种配置防止持有数据平面权限的用户跨租户边界传输数据。 更多信息请参见“允许的复制操作范围”和“防止跨 Microsoft Entra 租户的对象复制”。
使用 VNet 服务标签来处理向 Azure 存储 的出站规则：当你限制虚拟网络向 Azure 存储 的出站流量时，使用
Storage服务标签（或区域特定变体），而不是硬编码的 IP 范围。 随着IP领域的发展，Microsoft会维护服务标签。 有关详细信息，请参阅 Azure 服务标记概述。
身份和访问管理
存储账户支持两种授权模式：Microsoft Entra ID（基于身份、可审计、可撤销）和共享密钥（一个对称秘密，具备完整账户访问权限）。 尽可能将工作负载迁移到 Microsoft Entra ID，并将共享密钥视为遗留的备用。
使用 Microsoft Entra ID 授权数据访问：Microsoft Entra ID 授权使用 OAuth 2.0 令牌，并集成条件访问、管理身份和 RBAC 审计轨迹。 在数据平面访问方面，它在各方面都优于共享密钥。 有关详细信息，请参阅 授权访问 Azure 存储中的数据。
禁止共享密钥授权：将属性
allowSharedKeyAccess设置为 ，false使账户拒绝任何使用账户密钥签署的请求。 仅接受 Microsoft Entra ID 以及在适用情况下的用户委派 SAS 请求。 有关详细信息，请参阅阻止对 Azure 存储帐户进行共享密钥授权。在最小合理的范围内分配 RBAC 角色：尽可能在容器、共享、队列或表层面分配内置的存储数据平面角色（例如， 存储 Blob 数据阅读器、 存储队列数据贡献者），而非账户或订阅层。 有关详细信息，请参阅 使用 Azure 基于角色的访问控制对 Blob 的访问进行授权。
- 添加ABAC条件以进一步限制数据平面访问：Azure基于属性的访问控制（ABAC）允许您为角色分配附加条件——例如，限制访问带有特定索引标签或特定路径前缀下的blob。 有关详细信息，请参阅 使用带 ABAC 条件的 Azure 角色分配来授权访问 Blob 数据。
当需要 SAS 时，请使用用户委派 SAS 代替服务或账户 SAS：用户委派 SAS 是用 Microsoft Entra 凭证而非账户密钥签名的，因此撤销用户委派密钥会立即使该密钥发出的所有 SAS 失效。 用账户密钥签名的服务和账户SAS令牌不能单独撤销。 有关详细信息，请参阅使用共享访问签名 (SAS) 授予对 Azure 存储资源的有限访问权限。
将每个SAS的权限范围限制为最低权限和最短寿命：只授予特定操作（例如
read，但不授予write），并将无存储访问策略支持的服务SAS的有效期设为一小时或更短。 更多信息请参见 使用 SAS 的最佳实践。在账户上配置SAS过期策略：设定账户发行的SAS代币有效期上限。 违规会被记录下来，这样你就能在代码库中找到并修复长期存在的SAS。 有关详细信息，请参阅为共享访问签名创建过期策略。
将 SAS 令牌限制为仅使用 HTTPS：当您必须签发 SAS 时，请在 SAS 签名中仅允许使用 HTTPS，以防止令牌以明文形式暴露。 有关详细信息，请参阅使用共享访问签名 (SAS) 授予对 Azure 存储资源的有限访问权限。
如果必须使用账户密钥，请保护并轮换它们：将账户密钥存储在 Azure 密钥保管库，运行时取用，而不是嵌入配置中，并按固定节奏轮换。 制定成文的密钥轮换流程，在轮换过渡期间同时使用两个密钥，以避免停机。 有关详细信息，请参阅管理存储帐户访问密钥。
使用 Microsoft Entra Privileged Identity Management (PIM) 按需分配特权存储角色：对于授予对存储进行管理平面更改权限的角色（例如 Storage Account Contributor 或 Owner），应要求通过审批和多重身份验证来激活 PIM，而不是进行永久分配。 有关详细信息，请参阅 什么是Microsoft Entra Privileged Identity Management？。
数据保护
Azure 存储默认用Microsoft管理的密钥加密所有静态数据。 本节建议增加了客户控制权，防止意外或恶意修改，并减少数据传输和静止时的暴露。
将客户管理的密钥（CMK）配置为静态加密：使用在Azure 密钥保管库中管理的密钥作为帐户加密密钥。 CMK 使你能够独立于 Microsoft 管理的密钥，对加密密钥进行轮换、审计和吊销。 它支持强制客户密钥控制的合规要求。 有关详细信息，请参阅用于 Azure 存储加密的客户管理的密钥。
启用基础设施加密以实现防御纵深双重加密：基础设施加密在主加密层之上再加一层服务管理加密。 你必须在账户创建时启用它。 更多信息请参见 “启用基础设施加密以实现数据双重加密”。
使用加密范围来隔离特定容器或blob的加密：加密范围允许你在单个账户内以容器级或blob级的粒度应用不同的密钥或密钥轮换策略。 该功能适用于共享账户但需要每个租户密钥控制的多租户工作负载。 更多信息请参见 Blob 存储 的加密范围。
为所有传输数据启用 Azure 存储 加密：与最低 TLS 版本 1.2 或更高版本合并
Secure transfer required = enabled（参见网络安全）。 它们共同确保账户拒绝未加密和弱加密连接。对于最敏感的数据使用客户端加密：对于明文绝不能出现在服务器上的数据，上传前在客户端加密。 客户端加密是服务端加密的补充，可以与CMK一起使用以实现分层保护。 关于各服务SDK的支持和模式，请参见 相关安全文章。
用资源锁保护存储账户：应用 不可删除 或 只读 锁，以防止账户本身被意外或恶意删除或重新配置。 锁作用于账户资源，而非其内部数据，因此它们补充而非替代软删除和不可篡改性。 有关详细信息，请参阅将 Azure 资源管理器锁定应用于存储帐户。
关于数据服务特定的数据保护特性（blob 不可变性和 WORM 策略、blob 加密范围），请参见 相关安全条目中的相应子条目。
日志记录和监控
存储账户经常成为凭证盗窃、窃取尝试和配置错误的目标。 你需要持续的日志记录和威胁检测，以快速检测和响应攻击。
将诊断设置发送到 Log Analytics 工作区：在帐户和每个数据服务（Blob、文件、队列、表）上配置诊断设置，将
StorageWrite、StorageDelete和StorageRead日志以及所有指标发送到 Log Analytics。 按照您的合规义务要求的期限保留日志。 有关详细信息，请参阅监视 Azure 存储。审计每个请求的授权方式：存储日志记录每个请求是否通过 Microsoft Entra ID、共享密钥、SAS 或匿名授权。 定期查询日志，以检测是否存在非预期的授权方法，尤其是在禁用共享密钥后仍使用共享密钥，或在禁用匿名访问后仍出现匿名访问。 欲了解更多信息，请参见针对Azure 存储的监控请求。
针对高信号安全事件的警报：在应禁用密钥的帐户上配置Azure Monitor警报，例如密钥重新生成、防火墙规则更改、公用网络访问更改和共享密钥使用情况。 有关详细信息，请参阅 Azure Monitor 中的日志警报。
将日志转发到中央SIEM：对于企业级响应，将存储日志从Log Analytics转发到Microsoft Sentinel或其他SIEM，使存储事件与身份、网络和终端信号相关联。 欲了解更多信息，请参见Connect Azure 存储 to Microsoft Sentinel。
合规性和治理
治理控制使安全配置成为默认配置，并自动检测漂移。 对于超过少数账户的存储资产，基于政策的执行是保持基线一致性的唯一可持续方式。
应用 Azure Policy 以强制执行基础存储安全：分配内置策略，在部署时阻止不安全的配置，并审计现有账户。 高价值内置功能包括：要求安全传输，要求最低TLS 1.2，拒绝公共网络访问，拒绝公共blob访问，要求基础设施加密，以及要求CMK。 完整列表請參見 Azure Policy 內建定義 for Azure 存储 和 Azure Policy Regulatory Compliance controls for Azure 存储。
以 Microsoft 云安全基准（MCSB）为基础：将存储控制与 MCSB v2 域对齐，以确保各服务间的安全态势一致。 更多信息请参见 Microsoft 云安全基准概述。
带有所有者、数据分类和环境的存储标签：治理策略、成本管理和事件响应都依赖于一致的标签。 通过 Azure Policy 应用标签，这样创建时就不能被遗漏。
在存储受监管数据前，请先审查合规产品：Azure 存储持有通用监管框架（如HIPAA、PCI DSS、FedRAMP、ISO 27001等）的认证。 在部署前确认您的工作负载覆盖情况。
备份和恢复
跨区域冗余及验证的故障转移程序为存储账户本身提供了区域弹性。 关于数据服务特定的删除保护（blob软删除、blob版本控制、变更订阅、点点恢复、文件共享软删除和快照），请参见 相关安全条目中的相应子条目。
根据你的恢复需求选择合适的冗余选项：地理冗余存储（GRS/RA-GRS/GZRS/RA-GZRS）将数据复制到配对区域，并支持客户发起的故障切换以实现区域韧性。 区域冗余存储（ZRS/GZRS）用于防止区域层级故障。 有关详细信息，请参阅 Azure 存储冗余。
不要依赖地理冗余来保护勒索软件：地理冗余复制会将数据——以及任何损坏或恶意删除——镜像到配对区域。 将GRS与不可变性策略、软删除和版本控制配合，以防勒索软件和防篡改。 欲了解更多信息，请参见 Azure 存储 中的数据保护功能。
演练客户发起的故障转移和故障回复：对于具有 RA-GRS 或 RA-GZRS 的账户，请执行一次计划内的故障转移演练，以便在实际需要之前验证恢复流程是否有效。 有关详细信息，请参阅灾难恢复和存储帐户故障转移。
相关安全文章
关于针对每个 Azure 存储 数据服务的特定安全指导，请参见：
- 保护您的 Azure Blob 存储 - 针对 Blob 的专用安全，包括 Azure Data Lake Storage、不可变性、版本管理和匿名访问。
- 保护您的 Azure 文件存储——基于身份的文件共享认证、SMB/NFS 协议安全以及共享层访问控制。
- 保护你的 Azure 队列存储 - 队列专用授权与监控。
- 保护您的 Azure 表存储 - 表特定授权和 Cosmos DB Table API 的考虑因素。