应用 Azure 存储安全最佳做法
我们回顾了如何创建和使用共享访问签名 (SAS) 以及它可以为你的存储安全解决方案带来的好处。
请务必了解,在应用程序中使用 SAS 时,可能存在潜在风险。
如果 SAS 遭到入侵,获得 SAS 的任何人都可以访问存储。
如果提供给客户端应用程序的 SAS 到期并且应用程序无法从你的服务检索新 SAS,则可能会影响该应用程序的功能。
观看此视频,了解有关如何保护存储的更多想法。 此视频基于 Azure 提示和技巧 #272 Azure 安全最佳做法。
管理风险的建议
让我们来看看一些建议,这些建议可以帮助缓解使用 SAS 时产生的风险。
建议 | 说明 |
---|---|
始终使用 HTTPS 创建和分发 | 如果 SAS 通过 HTTP 传递且被截获,攻击者可能会截获并使用 SAS。 这些“中间人”攻击可能会危害敏感数据或容许恶意用户损坏数据。 |
尽可能引用存储访问策略 | 存储访问策略使你可以选择撤消权限,而不必重新生成 Azure 存储帐户密钥。 将存储帐户密钥到期日期设置为较远的未来时间。 |
为计划外的 SAS 设置近期的到期时间 | 如果 SAS 遭到入侵,可以通过将 SAS 有效性限制为较短时间来缓解攻击。 如果你无法引用存储访问策略,此做法非常重要。 临时到期时间还通过限制可用于上传到它的时间来限制可以写入 Blob 的数据量。 |
让客户端自动续订 SAS | 让客户端在到期日期之前续订 SAS。 如果提供 SAS 的服务不可用,则提前续订,留出时间进行重试。 |
仔细计划 SAS 开始时间 | 如果你将 SAS 的开始时间设置为“现在”,则由于时钟偏移(根据不同计算机,当前时间中的差异),在前几分钟将会暂时观察到失败。 通常,将开始时间至少设置为 15 分钟前。 或者,不要设置特定的开始时间,这会导致 SAS 在所有情况下立即有效。 相同的条件通常适用于到期时间。 对于任何请求,在任一方向你可能会观察到最多 15 分钟的时钟偏移。 对于使用 2012-02-12 之前的 REST API 版本的客户端,未参照某一存储访问策略的 SAS 的最大持续时间是 1 小时。 任何指定了更长期限的策略都将失败。 |
定义资源的最大访问权限 | 一种安全性最佳做法是向用户提供所需最小权限。 如果某一用户仅需要对单个实体的读取访问权限,则向该用户授予对该单个实体的读取访问权限,而不要授予针对所有实体的读取/写入/删除访问权限。 如果 SAS 泄露,此做法也有助于降低损失,因为攻击者手中掌握的 SAS 的权限较为有限。 |
了解帐户使用情况计费,包括 SAS | 提供有限的权限以帮助减少可能的恶意用户行为。 读取和写入权限可能会导致计取费用。 使用生存期较短的 SAS 来减少此风险。 |
验证使用 SAS 写入的数据 | 在某一客户端应用程序将数据写入你的 Azure 存储帐户时,请记住对于这些数据可能存在问题。 如果应用程序需要经过验证或授权的数据,请在写入数据后且使用数据前验证数据。 这一实践还有助于防止损坏的数据或恶意数据写入帐户,这些数据可能是正常要求 SAS 的用户写入的,也可能是利用泄露的 SAS 的用户写入的。 |
不要假设 SAS 始终是正确的选择 | 在某些场景下,针对 Azure 存储帐户执行特定操作所带来的风险超过了 SAS 所带来的好处。 对于此类操作,应创建一个中间层服务,该服务在执行业务规则验证、身份验证和审核后写入存储帐户。 此外,有时候以其他方式管理访问会更简单。 如果想要使某一容器中的所有 blob 都可以公开读取,则可以使该容器成为公共的,而不是为每个客户端都提供 SAS 来进行访问。 |
使用 Azure 存储分析监视应用程序 | 可以使用日志记录和指标来观察身份验证失败中的任何峰值情形。 可能会遇到由于你的 SAS 提供程序服务中的中断或者某一存储访问策略的无意中删除而导致的任何峰值情形。 |