安全框架：身份验证 | 缓解措施Security Frame: Authentication | Mitigations

• 考虑使用标准身份验证机制向 Web 应用程序进行身份验证Consider using a standard authentication mechanism to authenticate to Web Application
• 应用程序必须安全处理失败的身份验证方案Applications must handle failed authentication scenarios securely
• 启用升级或自适应的身份验证Enable step up or adaptive authentication
• 确保适当锁定管理界面Ensure that administrative interfaces are appropriately locked down
• 安全实施忘记密码功能Implement forgot password functionalities securely
• 确保实施密码和帐户策略Ensure that password and account policy are implemented
• 实施控制来防止用户名枚举Implement controls to prevent username enumeration

• 尽可能使用 Windows 身份验证连接到 SQL ServerWhen possible, use Windows Authentication for connecting to SQL Server
• 尽可能使用 Azure Active Directory 身份验证连接到 SQL 数据库When possible use Azure Active Directory Authentication for Connecting to SQL Database
• 使用 SQL 身份验证模式时，确保对 SQL Server 实施帐户和密码策略When SQL authentication mode is used, ensure that account and password policy are enforced on SQL server
• 不要在包含的数据库中使用 SQL 身份验证Do not use SQL Authentication in contained databases

• 结合 SaS 令牌使用每个设备的身份验证凭据Use per device authentication credentials using SaS tokens

• 启用面向 Azure 管理员的多重身份验证Enable Azure Multi-Factor Authentication for Azure Administrators

• 限制对 Service Fabric 群集的匿名访问Restrict anonymous access to Service Fabric Cluster
• 确保 Service Fabric 的客户端到节点证书不同于节点到节点证书Ensure that Service Fabric client-to-node certificate is different from node-to-node certificate
• 使用 AAD 在 Service Fabric 群集中对客户端进行身份验证Use AAD to authenticate clients to service fabric clusters
• 确保从批准的证书颁发机构 (CA) 获取 Service Fabric 证书Ensure that service fabric certificates are obtained from an approved Certificate Authority (CA)

• 使用标识服务器支持的标准身份验证方案Use standard authentication scenarios supported by Identity Server
• 使用可缩放的替代方案覆盖默认的标识服务器令牌缓存Override the default Identity Server token cache with a scalable alternative

• 确保部署的应用程序的二进制文件经过数字签名Ensure that deployed application's binaries are digitally signed

• 连接到 WCF 中的 MSMQ 队列时启用身份验证Enable authentication when connecting to MSMQ queues in WCF
• WCF - 不要将消息 clientCredentialType 设置为 noneWCF-Do not set Message clientCredentialType to none
• WCF - 不要将传输 clientCredentialType 设置为 noneWCF-Do not set Transport clientCredentialType to none

• 确保使用标准身份验证技术保护 Web APIEnsure that standard authentication techniques are used to secure Web APIs

• 使用 Azure Active Directory 支持的标准身份验证方案Use standard authentication scenarios supported by Azure Active Directory
• 使用可缩放的替代方案覆盖默认的 ADAL 令牌缓存Override the default ADAL token cache with a scalable alternative
• 确保使用 TokenReplayCache 防止 ADAL 身份验证令牌重放Ensure that TokenReplayCache is used to prevent the replay of ADAL authentication tokens
• 使用 ADAL 库来管理从 OAuth2 客户端发往 AAD（或本地 AD）的令牌请求Use ADAL libraries to manage token requests from OAuth2 clients to AAD (or on-premises AD)

• 对连接到现场网关的设备进行身份验证Authenticate devices connecting to the Field Gateway

• 确保对连接到云网关的设备进行身份验证Ensure that devices connecting to Cloud gateway are authenticated
• 使用每个设备的身份验证凭据Use per-device authentication credentials

• 确保只对所需的容器和 Blob 授予匿名读取访问权限Ensure that only the required containers and blobs are given anonymous read access
• 使用 SAS 或 SAP 对 Azure 存储中的对象授予受限的访问权限Grant limited access to objects in Azure storage using SAS or SAP

身份验证是某个实体证明其身份的过程，这通常是通过用户名和密码等凭据完成的。Authentication is the process where an entity proves its identity, typically through credentials, such as a user name and password. 可以考虑使用多种身份验证协议。There are multiple authentication protocols available which may be considered. 下面列出了其中一些协议：Some of them are listed below:

• 客户端证书Client certificates
• 基于 WindowsWindows based
• 基于窗体Forms based
• 联合身份验证 - ADFSFederation - ADFS
• 联合身份验证 - Azure ADFederation - Azure AD
• 联合身份验证 - 标识服务器Federation - Identity Server

考虑使用标准身份验证机制来识别源进程Consider using a standard authentication mechanism to identify the source process

显式执行用户身份验证的应用程序必须安全处理失败的身份验证方案。身份验证机制必须：Applications that explicitly authenticate users must handle failed authentication scenarios securely.The authentication mechanism must:

• 在身份验证失败时拒绝访问特权资源Deny access to privileged resources when authentication fails
• 身份验证失败并且发生访问被拒绝后，显示常规错误消息Display a generic error message after failed authentication and access denied occurs

测试：Test for:

• 登录失败后保护特权资源Protection of privileged resources after failed logins
• 身份验证失败并且发生访问被拒绝事件后，显示常规错误消息A generic error message is displayed on failed authentication and access denied event(s)
• 尝试失败的次数过多后禁用帐户Accounts are disabled after an excessive number of failed attempts

验证应用程序是否有附加的授权（例如，通过多重身份验证（在短信中发送 OTP，等等）执行升级或自适应的身份验证，或者提示重新身份验证），以便在向用户授予对敏感信息的访问权限之前向其提出质询。Verify the application has additional authorization (such as step up or adaptive authentication, via multi-factor authentication such as sending OTP in SMS, email etc. or prompting for re-authentication) so the user is challenged before being granted access to sensitive information. 对帐户或操作进行重大更改时，也可以应用此规则This rule also applies for making critical changes to an account or action

这也意味着，必须以适当的方式实施身份验证的调适，以便应用程序能够正确实施区分上下文的授权，阻止通过参数篡改等方式执行未经授权的操作This also means that the adaptation of authentication has to be implemented in such a manner that the application correctly enforces context-sensitive authorization so as to not allow unauthorized manipulation by means of in example, parameter tampering

首先，验证“忘记密码”和其他恢复路径是否发送包含限时激活令牌而不是密码本身的链接。The first thing is to verify that forgot password and other recovery paths send a link including a time-limited activation token rather than the password itself. 在发送链接之前，还可能需要实施基于软令牌（例如 SMS 令牌、本机移动应用程序等）的其他身份验证。Additional authentication based on soft-tokens (e.g. SMS token, native mobile applications, etc.) can be required as well before the link is sent over. 第二，在获取新密码的过程正在进行时，不应锁定用户帐户。Second, you should not lock out the users account whilst the process of getting a new password is in progress.

否则，每当攻击者决定使用自动攻击来有意锁定用户时，可能会导致拒绝服务攻击。This could lead to a Denial of service attack whenever an attacker decides to intentionally lock out the users with an automated attack. 第三，在新密码请求正在设置时，显示的消息应该普通化，防止用户名枚举。Third, whenever the new password request was set in progress, the message you display should be generalized in order to prevent username enumeration. 第四，始终禁止使用旧密码并实施强密码策略。Fourth, always disallow the use of old passwords and implement a strong password policy.

应该实施与组织策略和最佳做法相符的密码与帐户策略。Password and account policy in compliance with organizational policy and best practices should be implemented.

为了防范暴力破解和基于字典的猜测：必须实现强密码策略，确保用户创建复杂密码（例如，最小长度为 12 个字符，必须包含字母数字和特殊字符）。To defend against brute-force and dictionary based guessing: Strong password policy must be implemented to ensure that users create complex password (e.g., 12 characters minimum length, alphanumeric and special characters).

可按以下方式实施帐户锁定策略：Account lockout policies may be implemented in the following manner:

• 软锁定： 这可能是防止用户遭受暴力破解攻击的不错选项。Soft lock-out: This can be a good option for protecting your users against brute force attacks. 例如，每当用户输入错误的密码三次，应用程序都会将其帐户锁定一分钟，以减慢暴力破解密码的过程，使攻击者更难以继续入侵。For example, whenever the user enters a wrong password three times the application could lock down the account for a minute in order to slow down the process of brute forcing their password making it less profitable for the attacker to proceed. 对于本示例，如果想要实施硬锁定对策，可以通过永久锁定帐户来实现“DoS”。If you were to implement hard lock-out countermeasures for this example you would achieve a "DoS" by permanently locking out accounts. 或者，应用程序可以生成 OTP（一次性密码），并将其以带外方式（通过电子邮件、短信等）发送给用户。Alternatively, application may generate an OTP (One Time Password) and send it out-of-band (through email, sms etc.) to the user. 另一种做法是在达到失败尝试次数的阈值后实施 CAPTCHA。Another approach may be to implement CAPTCHA after a threshold number of failed attempts is reached.
• 硬锁定： 每当检测到某个用户攻击应用程序时，都应该应用这种类型的锁定并对其采取对策：永久锁定其帐户，直到响应团队对其取证。Hard lock-out: This type of lockout should be applied whenever you detect a user attacking your application and counter them by means of permanently locking out their account until a response team had time to do their forensics. 完成此过程后，可以决定是要恢复该用户的帐户，还是采取进一步的法律措施。After this process you can decide to give the user back their account or take further legal actions against them. 这种方式可以防止攻击者进一步侵入应用程序和基础结构。This type of approach prevents the attacker from further penetrating your application and infrastructure.

为了防范针对默认与可预测帐户的攻击，请验证所有密钥和密码是否可替换，并且是否是在安装后生成或替换的。To defend against attacks on default and predictable accounts, verify that all keys and passwords are replaceable, and are generated or replaced after installation time.

如果应用程序必须自动生成密码，请确保生成的密码是随机的并具有高熵。If the application has to auto-generate passwords, ensure that the generated passwords are random and have high entropy.

事件中心安全模型基于共享访问签名 (SAS) 令牌与事件发布者的组合。The Event Hubs security model is based on a combination of Shared Access Signature (SAS) tokens and event publishers. 发布者名称表示接收令牌的 DeviceID。The publisher name represents the DeviceID that receives the token. 它可以帮助将生成的令牌与相应的设备相关联。This would help associate the tokens generated with the respective devices.

所有消息在服务端标记为发起方，用于检测有效负载中原点欺骗的企图。All messages are tagged with originator on service side allowing detection of in-payload origin spoofing attempts. 对设备进行身份验证时，将生成一个对应于唯一发布者的基于设备的 SaS 令牌。When authenticating devices, generate a per device SaS token scoped to a unique publisher.

多重身份验证 (MFA) 是要求使用多种验证方法的身份验证方法，为用户登录和事务额外提供一层重要的安全保障。Multi-factor authentication (MFA) is a method of authentication that requires more than one verification method and adds a critical second layer of security to user sign-ins and transactions. 它的工作原理是需要以下两种或多种验证方法：It works by requiring any two or more of the following verification methods:

• 用户知道的某样东西（通常为密码）Something you know (typically a password)
• 用户具有的某样东西（无法轻易复制的可信设备，如电话）Something you have (a trusted device that is not easily duplicated, like a phone)
• 自身的特征（生物辨识系统）Something you are (biometrics)

始终都应该保护群集，防止未经授权的用户连接到群集，特别是群集上正在运行生产工作负荷时。Clusters should always be secured to prevent unauthorized users from connecting to your cluster, especially when it has production workloads running on it.

创建 Service Fabric 群集时，请确保安全模式设置为“安全”，并配置所需的 X.509 服务器证书。While creating a service fabric cluster, ensure that the security mode is set to "secure" and configure the required X.509 server certificate. 如果创建“不安全”的群集，当这种群集在公共 Internet 上公开管理终结点时，任何匿名用户都可与它建立连接。Creating an "insecure" cluster will allow any anonymous user to connect to it if it exposes management endpoints to the public Internet.

客户端到节点的证书安全性通过指定管理员客户端证书和/或用户客户端证书在使用 Azure 门户、Resource Manager 模板或独立的 JSON 模板创建群集时配置。Client-to-node certificate security is configured while creating the cluster either through the Azure portal, Resource Manager templates or a standalone JSON template by specifying an admin client certificate and/or a user client certificate.

指定的管理员客户端证书和用户客户端证书应该不同于为节点到节点安全性指定的主证书和辅助证书。The admin client and user client certificates you specify should be different than the primary and secondary certificates you specify for Node-to-node security.

Service Fabric 使用 X.509 服务器证书对节点和客户端进行身份验证。Service Fabric uses X.509 server certificates for authenticating nodes and clients.

在 Service Fabric 中使用证书时，需考虑一些重要事项：Some important things to consider while using certificates in service fabrics:

• 运行生产工作负荷的群集中使用的证书应使用正确配置的 Windows Server 证书服务进行创建，或者从已批准的证书颁发机构 (CA) 获取。Certificates used in clusters running production workloads should be created by using a correctly configured Windows Server certificate service or obtained from an approved Certificate Authority (CA). CA 可以是批准的外部 CA，也可以是适当管理的内部公钥基础结构 (PKI)The CA can be an approved external CA or a properly managed internal Public Key Infrastructure (PKI)
• 切勿在生产环境中使用通过 MakeCert.exe 等工具创建的临时或测试证书Never use any temporary or test certificates in production that are created with tools such as MakeCert.exe
• 可以使用自签名证书，但只应使用它来测试群集，而不应在生产环境中使用You can use a self-signed certificate, but should only do so for test clusters and not in production

下面是标识服务器支持的典型交互：Below are the typical interactions supported by Identity Server:

• 浏览器与 Web 应用程序通信Browsers communicate with web applications
• Web 应用程序与 Web API 通信（有时是代表自身，有时代表用户）Web applications communicate with web APIs (sometimes on their own, sometimes on behalf of a user)
• 基于浏览器的应用程序与 Web API 通信Browser-based applications communicate with web APIs
• 本机应用程序与 Web API 通信Native applications communicate with web APIs
• 基于服务器的应用程序与 Web API 通信Server-based applications communicate with web APIs
• Web API 与 Web API 通信（有时是代表自身，有时代表用户）Web APIs communicate with web APIs (sometimes on their own, sometimes on behalf of a user)

IdentityServer 具有简单的内置内存中缓存。IdentityServer has a simple built-in in-memory cache. 尽管对于小规模本机应用而言这很合适，但是，出于以下原因，它无法根据中间层和后端应用程序缩放：While this is good for small scale native apps, it does not scale for mid tier and backend applications for the following reasons:

• 这些应用程序同时由许多用户访问。These applications are accessed by many users at once. 在同一个存储中保存所有访问令牌会产生隔离问题，并且在大规模运行时会带来难题：如果用户数目众多，并且每个用户的令牌数与应用代表他们访问的资源数相当，则可能意味着需要执行极大量的开销极高的查找操作Saving all access tokens in the same store creates isolation issues and presents challenges when operating at scale: many users, each with as many tokens as the resources the app accesses on their behalf, can mean huge numbers and very expensive lookup operations
• 这些应用程序通常部署在分布式拓扑中，其中的多个节点必须能够访问同一个缓存These applications are typically deployed on distributed topologies, where multiple nodes must have access to the same cache
• 在进程回收和停用后，缓存的令牌必须能够幸存Cached tokens must survive process recycles and deactivations
• 出于上述所有原因，在实施 Web 应用程序时，建议使用 Azure Redis 缓存等可缩放的替代方案来覆盖标识服务器的默认令牌缓存For all the above reasons, while implementing web apps, it is recommended to override the default Identity Server's token cache with a scalable alternative such as Azure Cache for Redis

身份验证是某个实体证明其身份的过程，这通常是通过用户名和密码等凭据完成的。Authentication is the process where an entity proves its identity, typically through credentials, such as a user name and password. 可以考虑使用多种身份验证协议。There are multiple authentication protocols available which may be considered. 下面列出了其中一些协议：Some of them are listed below:

• 客户端证书Client certificates
• 基于 WindowsWindows based
• 基于窗体Forms based
• 联合身份验证 - ADFSFederation - ADFS
• 联合身份验证 - Azure ADFederation - Azure AD
• 联合身份验证 - 标识服务器Federation - Identity Server

参考部分中的链接提供了有关如何实施每种身份验证方案来保护 Web API 的低级别详细信息。Links in the references section provide low-level details on how each of the authentication schemes can be implemented to secure a Web API.

Azure Active Directory (Azure AD) 通过提供标识即服务并支持 OAuth 2.0 和 OpenID Connect 等行业标准协议，简化了对开发人员的身份验证。Azure Active Directory (Azure AD) simplifies authentication for developers by providing identity as a service, with support for industry-standard protocols such as OAuth 2.0 and OpenID Connect. 下面是 Azure AD 支持的五种主要应用程序方案：Below are the five primary application scenarios supported by Azure AD:

• Web 浏览器到 Web 应用程序：用户需要登录到受 Azure AD 保护的 Web 应用程序Web Browser to Web Application: A user needs to sign in to a web application that is secured by Azure AD
• 单页面应用程序 (SPA)：用户需要登录到受 Azure AD 保护的单页面应用程序Single Page Application (SPA): A user needs to sign in to a single page application that is secured by Azure AD
• 本机应用程序到 Web API：在手机、平板电脑或电脑上运行的本机应用程序需要对用户进行身份验证以通过受 Azure AD 保护的 Web API 获取资源Native Application to Web API: A native application that runs on a phone, tablet, or PC needs to authenticate a user to get resources from a web API that is secured by Azure AD
• Web 应用程序到 Web API：Web 应用程序需要通过受 Azure AD 保护的 Web API 获取资源Web Application to Web API: A web application needs to get resources from a web API secured by Azure AD
• 守护程序或服务器应用程序到 Web API：没有 Web 用户界面的守护程序应用程序或服务器应用程序需要通过受 Azure AD 保护的 Web API 获取资源Daemon or Server Application to Web API: A daemon application or a server application with no web user interface needs to get resources from a web API secured by Azure AD

请参阅参考部分中的链接，了解低级别实施详细信息Please refer to the links in the references section for low-level implementation details

ADAL（Active Directory 身份验证库）使用的默认缓存是依赖于静态存储、可在进程范围内使用的内存中缓存。The default cache that ADAL (Active Directory Authentication Library) uses is an in-memory cache that relies on a static store, available process-wide. 尽管这很适合用于本机应用程序，但是，出于以下原因，它无法根据中间层和后端应用程序缩放：While this works for native applications, it does not scale for mid tier and backend applications for the following reasons:

• 这些应用程序同时由许多用户访问。These applications are accessed by many users at once. 在同一个存储中保存所有访问令牌会产生隔离问题，并且在大规模运行时会带来难题：如果用户数目众多，并且每个用户的令牌数与应用代表他们访问的资源数相当，则可能意味着需要执行极大量的开销极高的查找操作Saving all access tokens in the same store creates isolation issues and presents challenges when operating at scale: many users, each with as many tokens as the resources the app accesses on their behalf, can mean huge numbers and very expensive lookup operations
• 这些应用程序通常部署在分布式拓扑中，其中的多个节点必须能够访问同一个缓存These applications are typically deployed on distributed topologies, where multiple nodes must have access to the same cache
• 在进程回收和停用后，缓存的令牌必须能够幸存Cached tokens must survive process recycles and deactivations

出于上述所有原因，在实施 Web 应用程序时，建议使用 Azure Redis 缓存等可缩放的替代方案来覆盖默认的 ADAL 令牌缓存。For all the above reasons, while implementing web apps, it is recommended to override the default ADAL token cache with a scalable alternative such as Azure Cache for Redis.

开发人员可以使用 TokenReplayCache 属性来定义令牌重放缓存，这是一个可以用来保存令牌的存储，用途是验证没有多次使用某个令牌。The TokenReplayCache property allows developers to define a token replay cache, a store that can be used for saving tokens for the purpose of verifying that no token can be used more than once.

这是针对一种所谓的令牌重放攻击的常见攻击采取的措施：截获登录时发送的令牌的攻击者可能会尝试再次将该令牌发送到应用（“重放”它），以求建立新的会话。This is a measure against a common attack, the aptly called token replay attack: an attacker intercepting the token sent at sign-in might try to send it to the app again (“replay” it) for establishing a new session. 例如，在 OIDC 代码授予流中，用户身份验证成功后，向信赖方的“/signin-oidc”终结点发出的请求包含“id_token”、“code”和“state”参数。E.g., In OIDC code-grant flow, after successful user authentication, a request to "/signin-oidc" endpoint of the relying party is made with "id_token", "code" and "state" parameters.

信赖方会验证此请求并建立新的会话。The relying party validates this request and establishes a new session. 如果攻击者捕获到此请求并重放它，就可以建立成功的会话并欺骗用户。If an adversary captures this request and replays it, he/she can establish a successful session and spoof the user. 在 OpenID Connect 中使用 nonce 可以限制但不能完全消除攻击成功得手的结果。The presence of the nonce in OpenID Connect can limit but not fully eliminate the circumstances in which the attack can be successfully enacted. 为了保护应用程序，开发人员可以提供 ITokenReplayCache 的实现，并向 TokenReplayCache 分配一个实例。To protect their applications, developers can provide an implementation of ITokenReplayCache and assign an instance to TokenReplayCache.

通过 Azure AD 身份验证库 (ADAL)，客户端应用程序开发人员能够轻松利用云或本地 Active Directory (AD) 对用户进行身份验证，然后获取访问令牌，进行安全的 API 调用。The Azure AD authentication Library (ADAL) enables client application developers to easily authenticate users to cloud or on-premises Active Directory (AD), and then obtain access tokens for securing API calls.

ADAL 提供许多可以方便开发人员进行身份验证的功能，例如，异步支持、用于存储访问令牌和刷新令牌的可配置令牌缓存、访问令牌过期且刷新令牌可用时自动刷新令牌，等等。ADAL has many features that make authentication easier for developers, such as asynchronous support, a configurable token cache that stores access tokens and refresh tokens, automatic token refresh when an access token expires and a refresh token is available, and more.

ADAL 可以应对大部分复杂情况，因而可以帮助开发人员集中处理其应用程序中的业务逻辑，并可轻松保护资源而不必成为安全方面的专家。By handling most of the complexity, ADAL can help a developer focus on business logic in their application and easily secure resources without being an expert on security. .NET、JavaScript（客户端和 Node.js）、Python、iOS、Android 和 Java 有单独的库。Separate libraries are available for .NET, JavaScript (client and Node.js), Python, iOS, Android and Java.

• 泛型： 使用传输层安全性 (TLS) 或 IPSec 对设备进行身份验证。Generic: Authenticate the device using Transport Layer Security (TLS) or IPSec. 如果设备无法处理完全非对称加密，则基础结构应该支持在这些设备上使用预共享密钥 (PSK)。Infrastructure should support using pre-shared key (PSK) on those devices that cannot handle full asymmetric cryptography. 利用 Azure AD、Oauth。Leverage Azure AD, Oauth.
• C#： 创建 DeviceClient 实例时，Create 方法默认创建使用 AMQP 协议来与 IoT 中心通信的 DeviceClient 实例。C#: When creating a DeviceClient instance, by default, the Create method creates a DeviceClient instance that uses the AMQP protocol to communicate with IoT Hub. 要使用 HTTPS 协议，请使用 Create 方法的重写，它可以让你指定协议。To use the HTTPS protocol, use the override of the Create method that enables you to specify the protocol. 如果使用 HTTPS 协议，则还应在项目中添加 Microsoft.AspNet.WebApi.Client NuGet 包，以包含 System.Net.Http.Formatting 命名空间。If you use the HTTPS protocol, you should also add the Microsoft.AspNet.WebApi.Client NuGet package to your project to include the System.Net.Http.Formatting namespace.

默认情况下，仅存储帐户的所有者能够访问容器以及其中的所有 Blob。By default, a container and any blobs within it may be accessed only by the owner of the storage account. 若要授予匿名用户对容器及其 Blob 的读取权限，可以设置容器权限以允许公共访问。To give anonymous users read permissions to a container and its blobs, one can set the container permissions to allow public access. 匿名用户可以读取可公开访问的容器中的 Blob，而无需对请求进行身份验证。Anonymous users can read blobs within a publicly accessible container without authenticating the request.

容器提供了下列用于管理容器访问的选项：Containers provide the following options for managing container access:

• 完全公共读取访问：可以通过匿名请求读取容器和 Blob 数据。Full public read access: Container and blob data can be read via anonymous request. 客户端可以通过匿名请求枚举容器中的 Blob，但无法枚举存储帐户中的容器。Clients can enumerate blobs within the container via anonymous request, but cannot enumerate containers within the storage account.
• 仅限 Blob 的公共读取访问权限：可以通过匿名请求读取此容器中的 Blob 数据，但容器数据不可用。Public read access for blobs only: Blob data within this container can be read via anonymous request, but container data is not available. 客户端无法通过匿名请求枚举容器中的 BlobClients cannot enumerate blobs within the container via anonymous request
• 无公共读取访问：仅帐户所有者可读取容器和 Blob 数据No public read access: Container and blob data can be read by the account owner only

如果想要始终允许对某些 Blob 进行匿名读取访问，最好是启用匿名访问。Anonymous access is best for scenarios where certain blobs should always be available for anonymous read access. 若要进行更精细的控制，可以创建一个共享访问签名，这样便可使用不同的权限在指定时间间隔内委派受限访问。For finer-grained control, one can create a shared access signature, which enables to delegate restricted access using different permissions and over a specified time interval. 确保不要意外地授予对可能包含敏感数据的容器和 Blob 的匿名访问权限Ensure that containers and blobs, which may potentially contain sensitive data, are not given anonymous access accidentally

使用共享访问签名 (SAS) 是将对存储帐户中对象的受限访问权限授予其他客户端且不必公开帐户访问密钥的一种高度有效的方法。Using a shared access signature (SAS) is a powerful way to grant limited access to objects in a storage account to other clients, without having to expose account access key. SAS 是在其查询参数中包含对存储资源进行验证了身份的访问所需的所有信息的 URI。The SAS is a URI that encompasses in its query parameters all of the information necessary for authenticated access to a storage resource. 要使用 SAS 访问存储资源，客户端只需将 SAS 传入到相应的构造函数或方法。To access storage resources with the SAS, the client only needs to pass in the SAS to the appropriate constructor or method.

需要将存储帐户中资源的访问权限提供给不能使用帐户密钥进行信任的客户端时，可以使用 SAS。You can use a SAS when you want to provide access to resources in your storage account to a client that can't be trusted with the account key. 存储帐户密钥包括主密钥和辅助密钥，这两种密钥都授予对帐户以及其中所有资源的管理访问权限。Your storage account keys include both a primary and secondary key, both of which grant administrative access to your account and all of the resources in it. 公开这两种帐户密钥的任何一种都会向可能的恶意或负面使用开放帐户。Exposing either of your account keys opens your account to the possibility of malicious or negligent use. 共享访问签名提供一种安全的方法，允许其他客户端根据你授予的权限读取、写入和删除存储帐户中的数据，而无需帐户密钥。Shared access signatures provide a safe alternative that allows other clients to read, write, and delete data in your storage account according to the permissions you've granted, and without need for the account key.

如果每次都有一组类似的逻辑参数，使用存储访问策略 (SAP) 是个不错的想法。If you have a logical set of parameters that are similar each time, using a Stored Access Policy (SAP) is a better idea. 由于使用派生自存储访问策略的 SAS 可以立即撤销该 SAS，因此建议的最佳做法是尽可能使用存储访问策略。Because using a SAS derived from a Stored Access Policy gives you the ability to revoke that SAS immediately, it is the recommended best practice to always use Stored Access Policies when possible.