保护 Azure 队列存储

Azure 队列存储提供应用组件之间的消息排队。由于消息通常包含敏感资源的引用——对象标识符、回调URL和应用状态——你必须同时保护队列授权和消息内容处理。

Note

本文介绍了针对 Azure 队列存储的特定安全实践。关于账户级别的安全指导，请参见“保护您的 Azure 存储账户”。

身份和访问管理

将 Microsoft Entra ID 与托管标识结合使用，以用于队列生产者和消费者：向每个与队列交互的服务的托管标识分配内置的 存储队列数据消息发送者、存储队列数据消息处理器 和 存储队列数据读取者 角色。选择与行动相匹配的角色。消息发送服务不应持有处理器权限。更多信息请参见“授权使用 Microsoft Entra ID 访问队列。
将基于角色的访问控制 (RBAC) 角色分配限定到特定队列：内置队列数据角色支持队列级别范围。当某个服务只需访问某个包含多个队列的账户中的一个队列时，应在队列级别而非存储账户级别授予其访问权限。
将SAS令牌范围限制在单一队列和特定消息操作：队列共享访问签名（SAS）分别支持add、updateprocess和read权限。仅授予调用方所需的权限。将事件加入队列的 webhook 接收器应仅接收add，而不是process。有关详细信息，请参阅使用共享访问签名委托访问权限。

消息在静态存储和传输过程中均受帐户的加密和 TLS 设置保护，但除队列级授权外，不会对单条消息单独实施访问控制。设计消息内容以避免敏感数据集中在队列中。

不要在队列消息中放置秘密或凭证：将秘密存储在 Azure 密钥保管库中，并在消息中放入引用（秘密标识符）。使用方在处理过程中使用各自的身份检索机密。放入消息中的任何内容，对在该队列上具有 process 或 read 的每个主体都是可见的，并且会被写入存储日志。
在应用层加密敏感消息负载：对于必须携带敏感数据的消息，在排队前用密钥保管库中的密钥加密负载。这增加了一层独立于存储端加密的层，并限制了消费者被攻破的风险暴露。欲了解更多信息，请参见 Azure 存储的客户端加密。
设置合理的消息存活时间（TTL）：消息会持续存在，直到它们被处理、过期或队列被排空。较长的TTL会增加可检索过期敏感数据的时间窗口。将TTL与预期处理延迟加上安全裕度匹配。

启用队列操作的诊断设置：将 StorageWrite、StorageDelete 和 StorageRead 类别发送到 Log Analytics，以便单个队列操作可供审计。追踪授权方法（Entra ID、共享密钥、SAS、匿名）以检测滥用。欲了解更多信息，请参见 Monitoring Azure 队列存储。
将有害消息移至专用有害消息队列：配置您的使用者以检测出队次数超过阈值的消息，并将其移至 <queue-name>-poison 队列，以便离线排查。毒性队列的积压是一种安全信号，而不仅仅是运维信号。更多信息请参见 “处理队列触发函数中的毒消息”。
针对死信队列增长发出警报：针对每个死信队列中的消息数配置 Azure Monitor 警报，以便在消息数异常增长时触发调查。
异常出队和删除模式警报：来自非预期身份的 DeleteMessage 操作突然激增，或大量仅有出队而无下游处理的活动，可能表明攻击者正在排空队列以掩盖其活动。针对队列正常流量模式的偏差发出警报。