Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可するGrant limited access to Azure Storage resources using shared access signatures (SAS)

Shared Access Signature (SAS) により、データのセキュリティを損なうことなく、ストレージ アカウント内のリソースへのセキュリティ保護された委任アクセスが提供されます。A shared access signature (SAS) provides secure delegated access to resources in your storage account without compromising the security of your data. SAS を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できます。With a SAS, you have granular control over how a client can access your data. パラメーターの中でも、クライアントがアクセスできるリソース、それらのリソースに対して持つアクセス許可、SAS の有効期間などを制御できます。You can control what resources the client may access, what permissions they have on those resources, and how long the SAS is valid, among other parameters.

共有アクセス署名の種類Types of shared access signatures

Azure Storage では、次の 3 種類の Shared Access Signature がサポートされています。Azure Storage supports three types of shared access signatures:

  • ユーザー委任 SAS (プレビュー)。User delegation SAS (preview). ユーザー委任 SAS は、Azure Active Directory (Azure AD) 資格情報と、SAS に指定されたアクセス許可によっても保護されます。A user delegation SAS is secured with Azure Active Directory (Azure AD) credentials and also by the permissions specified for the SAS. ユーザー委任 SAS は、BLOB ストレージにのみ適用されます。A user delegation SAS applies to Blob storage only. ユーザー委任 SAS を作成するには、まず、SAS への署名に使用されるユーザー委任キーを要求する必要があります。To create a user delegation SAS, you must first request a user delegation key, which is used to sign the SAS. ユーザー委任 SAS の詳細については、ユーザー委任 SAS の作成 (REST API) に関するページを参照してください。For more information about the user delegation SAS, see Create a user delegation SAS (REST API).
  • サービス SAS。Service SAS. サービス SAS は、ストレージ アカウント キーで保護されます。A service SAS is secured with the storage account key. サービス SAS は、次のうち 1 つだけの Azure Storage サービスのリソースへのアクセスを委任します。Blob storage、Queue storage、Table storage、または Azure Files。A service SAS delegates access to a resource in only one of the Azure Storage services: Blob storage, Queue storage, Table storage, or Azure Files. サービス SAS の詳細については、 サービス SAS の作成 (REST API) に関するページを参照してください。For more information about the service SAS, see Create a service SAS (REST API).
  • アカウント SAS。Account SAS. アカウント SAS は、ストレージアカウント キーで保護されます。An account SAS is secured with the storage account key. アカウント SAS は、1 つ以上のストレージ サービスのリソースへのアクセスを委任します。An account SAS delegates access to resources in one or more of the storage services. サービスまたはユーザー委任 SAS を介して実行できるすべての操作は、アカウント SAS を介しても実行できます。All of the operations available via a service or user delegation SAS are also available via an account SAS. さらに、アカウント SAS を使用して、Get/Set Service PropertiesGet Service Stats など、サービスのレベルで適用される操作へのアクセスを委任できます。Additionally, with the account SAS, you can delegate access to operations that apply at the level of the service, such as Get/Set Service Properties and Get Service Stats operations. サービス SAS で許可されていない BLOB コンテナー、テーブル、キューおよびファイル共有の読み取り、書き込みおよび削除操作へのアクセスも委任できます。You can also delegate access to read, write, and delete operations on blob containers, tables, queues, and file shares that are not permitted with a service SAS. アカウント SAS の詳細については、アカウント SAS の作成 (REST API) に関するページを参照してください。For more information about the account SAS, Create an account SAS (REST API).

注意

セキュリティのベスト プラクティスとして、より侵害されやすいアカウント キーを使用するのではなく、可能な限り Azure AD 資格情報を使用することをお勧めします。Microsoft recommends that you use Azure AD credentials when possible as a security best practice, rather than using the account key, which can be more easily compromised. アプリケーション設計で、BLOB ストレージへのアクセスのため、Shared Access Signature が必要な場合は、セキュリティを強化するために、可能な限り、Azure AD 資格情報を使用してユーザー委任 SAS を作成してください。When your application design requires shared access signatures for access to Blob storage, use Azure AD credentials to create a user delegation SAS when possible for superior security.

Shared Access Signature の形式は、次の 2 つのいずれかです。A shared access signature can take one of two forms:

  • アドホック SAS: アドホック SAS を作成すると、開始時刻、有効期限、および SAS へのアクセス許可がすべて、SAS URI で指定されます (または、開始時刻を省略した場合は、暗黙で指定されます)。Ad hoc SAS: When you create an ad hoc SAS, the start time, expiry time, and permissions for the SAS are all specified in the SAS URI (or implied, if start time is omitted). 任意の種類の SAS を、アドホック SAS にできます。Any type of SAS can be an ad hoc SAS.
  • 保存されているアクセス ポリシーによるサービス SAS: 保存されているアクセス ポリシーは、リソース コンテナー (BLOB コンテナー、テーブル、キュー、ファイル共有など) で定義されています。Service SAS with stored access policy: A stored access policy is defined on a resource container, which can be a blob container, table, queue, or file share. 保存されているアクセス ポリシーを使用して、1 つ以上の Shared Access Signature の制約を管理できます。The stored access policy can be used to manage constraints for one or more service shared access signatures. 保存されているアクセス ポリシーにサービスの SAS を関連付けると、SAS は、保存されているアクセス ポリシーに定義されている制約 — 開始時刻、有効期限、およびアクセス許可 — を継承します。When you associate a service SAS with a stored access policy, the SAS inherits the constraints—the start time, expiry time, and permissions—defined for the stored access policy.

注意

ユーザー委任 SAS またはアカウント SAS はアドホック SAS である必要があります。A user delegation SAS or an account SAS must be an ad hoc SAS. 保存されているアクセス ポリシーは、ユーザー委任 SAS またはアカウント SAS ではサポートされていません。Stored access policies are not supported for the user delegation SAS or the account SAS.

Shared Access Signature の機能How a shared access signature works

Shared Access Signature とは、特殊なクエリ パラメーターのセットを含むトークンを含む、1 つ以上のストレージ リソースをポイントする署名済み URI です。A shared access signature is a signed URI that points to one or more storage resources and includes a token that contains a special set of query parameters. このトークンは、リソースへのクライアントのアクセス方法を示します。The token indicates how the resources may be accessed by the client. クエリ パラメーターの 1 つである署名は、SAS パラメーターで作成されており、SAS の作成に使用されたキーで署名されています。One of the query parameters, the signature, is constructed from the SAS parameters and signed with the key that was used to create the SAS. この署名は、ストレージ リソースへのアクセスを承認するために、Azure Storage によって使用されます。This signature is used by Azure Storage to authorize access to the storage resource.

SAS の署名SAS signature

SAS に署名するには、次の 2 つの方法があります。You can sign a SAS in one of two ways:

  • Azure Active Directory (Azure AD) 資格情報を使用して作成されたユーザー委任キーを使用する。With a user delegation key that was created using Azure Active Directory (Azure AD) credentials. ユーザー委任 SAS は、ユーザー委任キーで署名されます。A user delegation SAS is signed with the user delegation key.

    ユーザー委任キーを取得して SAS を作成するには、Azure AD セキュリティ プリンシパルに Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey アクションを含むロールベースのアクセス制御 (RBAC) ロールが割り当てられている必要があります。To get the user delegation key and create the SAS, an Azure AD security principal must be assigned a role-based access control (RBAC) role that includes the Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey action. ユーザー委任キーを取得するアクセス許可を持つ RBAC ロールの詳細については、ユーザー委任 SAS の作成 (REST API) に関するページを参照してください。For detailed information about RBAC roles with permissions to get the user delegation key, see Create a user delegation SAS (REST API).

  • ストレージ アカウント キーを使用する。With the storage account key. サービス SAS とアカウント SAS は、どちらもストレージ アカウント キーを使用して署名されます。Both a service SAS and an account SAS are signed with the storage account key. アカウント キーで署名された SAS を作成するには、アプリケーションがアカウント キーにアクセスできる必要があります。To create a SAS that is signed with the account key, an application must have access to the account key.

SAS トークンSAS token

SAS トークンは、クライアント側で生成する文字列であり、たとえば、Azure Storage クライアント ライブラリのいずれかを使用します。The SAS token is a string that you generate on the client side, for example by using one of the Azure Storage client libraries. SAS トークンは、Azure Storage によって追跡されません。The SAS token is not tracked by Azure Storage in any way. クライアント側では、数に制限なく SAS トークンを作成できます。You can create an unlimited number of SAS tokens on the client side. SAS を作成したら、ストレージ アカウント内のリソースへのアクセスを必要とするクライアント アプリケーションに配布できます。After you create a SAS, you can distribute it to client applications that require access to resources in your storage account.

クライアント アプリケーションが要求の一部として Azure Storage に SAS URI を提供するときに、サービスでは、SAS パラメーターと、要求の認証に対して有効であることを確認する署名が確認されます。When a client application provides a SAS URI to Azure Storage as part of a request, the service checks the SAS parameters and signature to verify that it is valid for authorizing the request. サービスによって署名が有効であることが確認されると、要求が承認されます。If the service verifies that the signature is valid, then the request is authorized. それ以外の場合、要求はエラー コード 403 (Forbidden) で拒否されます。Otherwise, the request is declined with error code 403 (Forbidden).

リソース URI と その SAS トークンを示すサービス SAS URI の例は以下のようになります。Here's an example of a service SAS URI, showing the resource URI and the SAS token:

サービス SAS URI のコンポーネント

Shared Access Signature を使用するタイミングWhen to use a shared access signature

SAS は、他の方法では、ストレージ アカウント内のリソースへのアクセス許可を持たないクライアントに、それらのリソースへのセキュリティで保護されたアクセスを提供する場合に使用します。Use a SAS when you want to provide secure access to resources in your storage account to any client who does not otherwise have permissions to those resources.

SAS が役立つ一般的なシナリオは、ストレージ アカウント内でユーザーが自分のデータの読み取りや書き込みを行うサービスです。A common scenario where a SAS is useful is a service where users read and write their own data to your storage account. ストレージ アカウントにユーザー データが格納されるシナリオには、2 種類の典型的な設計パターンがあります。In a scenario where a storage account stores user data, there are two typical design patterns:

  1. 認証を実行するフロントエンド プロキシ サービス経由で、クライアントがデータのアップロードとダウンロードを行います。Clients upload and download data via a front-end proxy service, which performs authentication. このフロントエンド プロキシ サービスには、ビジネス ルールの検証が可能であるという利点がありますが、データやトランザクションが大量である場合は、需要に応じて拡張可能なサービスの作成にコストがかかったり、困難が生じたりする可能性があります。This front-end proxy service has the advantage of allowing validation of business rules, but for large amounts of data or high-volume transactions, creating a service that can scale to match demand may be expensive or difficult.

    シナリオ図:フロント エンド プロキシ サービス

  2. 軽量サービスが、必要に応じてクライアントを認証してから、SAS を生成します。A lightweight service authenticates the client as needed and then generates a SAS. クライアント アプリケーションは、SAS を受信すると、SAS で定義されたアクセス許可と SAS で許可された期間で、ストレージ アカウントのリソースに直接アクセスできるようになります。Once the client application receives the SAS, they can access storage account resources directly with the permissions defined by the SAS and for the interval allowed by the SAS. SAS によって、すべてのデータをフロントエンド プロキシ サービス経由でルーティングする必要性が減少します。The SAS mitigates the need for routing all data through the front-end proxy service.

    シナリオ図:SAS プロバイダー サービス

多くの実際のサービスでは、これら 2 つのアプローチを組み合わせて使用している場合があります。Many real-world services may use a hybrid of these two approaches. たとえば、一部のデータはフロントエンド プロキシで処理して検証し、その他のデータは SAS を使用して直接保存または読み取ります。For example, some data might be processed and validated via the front-end proxy, while other data is saved and/or read directly using SAS.

また、特定のシナリオにおけるコピー操作でソース オブジェクトへのアクセスを承認するために、SAS が必要です。Additionally, a SAS is required to authorize access to the source object in a copy operation in certain scenarios:

  • BLOB を別のストレージ アカウント内にある他の BLOB にコピーする場合、コピー元 BLOB へのアクセスの承認には SAS を使用する必要があります。When you copy a blob to another blob that resides in a different storage account, you must use a SAS to authorize access to the source blob. コピー先 BLOB へのアクセスの承認にも、任意で SAS を使用できます。You can optionally use a SAS to authorize access to the destination blob as well.
  • ファイルを別のストレージ アカウント内にある他のファイルにコピーする場合、コピー元ファイルへのアクセスの承認には SAS を使用する必要があります。When you copy a file to another file that resides in a different storage account, you must use a SAS to authorize access to the source file. コピー先 BLOB へのアクセスの承認にも、任意で SAS を使用できます。コピー先ファイルへのアクセスの承認にも、任意で SAS を使用できます。You can optionally use a SAS to authorize access to the destination file as well.
  • BLOB をファイルにコピーしたり、ファイルを BLOB にコピーしたりする場合、同じストレージ アカウント内にコピー先とコピー元のオブジェクトがある場合でも、SAS を使用してソース オブジェクトへのアクセスを承認する必要があります。When you copy a blob to a file, or a file to a blob, you must use a SAS to authorize access to the source object, even if the source and destination objects reside within the same storage account.

SAS を使用する際のベスト プラクティスBest practices when using SAS

アプリケーションで Shared Access Signature を使用する場合は、次の 2 つの潜在的なリスクに注意する必要があります。When you use shared access signatures in your applications, you need to be aware of two potential risks:

  • SAS が漏えいすると、取得した人はだれでも使用できるため、ストレージ アカウントの安全性が損なわれるおそれがあります。If a SAS is leaked, it can be used by anyone who obtains it, which can potentially compromise your storage account.
  • クライアント アプリケーションに提供された SAS が期限切れになり、アプリケーションがサービスから新しい SAS を取得できない場合は、アプリケーションの機能が損なわれる可能性があります。If a SAS provided to a client application expires and the application is unable to retrieve a new SAS from your service, then the application's functionality may be hindered.

Shared Access Signature の使用に関する次の推奨事項に従うと、これらのリスクの軽減に役立ちます。The following recommendations for using shared access signatures can help mitigate these risks:

  • 常に HTTPS を使用して SAS を作成または配布します。Always use HTTPS to create or distribute a SAS. SAS が HTTP で渡され、傍受された場合、中間者攻撃を実行している攻撃者は、SAS を読み取って、宛先のユーザーと同様に使用することができます。このため、機密データの安全性が損なわれたり、悪意のあるユーザーによるデータ破損が発生したりする可能性があります。If a SAS is passed over HTTP and intercepted, an attacker performing a man-in-the-middle attack is able to read the SAS and then use it just as the intended user could have, potentially compromising sensitive data or allowing for data corruption by the malicious user.
  • 可能な限り、ユーザー委任 SAS を使用します。Use a user delegation SAS when possible. ユーザー委任 SAS は、サービス SAS またはアカウント SAS に優れたセキュリティを提供します。A user delegation SAS provides superior security to a service SAS or an account SAS. ユーザー委任 SAS は Azure AD 資格情報で保護されているため、コードでアカウントキーを保存する必要はありません。A user delegation SAS is secured with Azure AD credentials, so that you do not need to store your account key with your code.
  • SAS の失効計画を立てます。Have a revocation plan in place for a SAS. SAS が侵害された場合に対応する準備ができていることを確認します。Make sure you are prepared to respond if a SAS is compromised.
  • サービス SAS の保存されているアクセス ポリシーを定義します。Define a stored access policy for a service SAS. 保存されているアクセス ポリシーを使用すると、ストレージ アカウント キーを再生成せずに、サービス SAS のアクセス許可を失効させることが可能になります。Stored access policies give you the option to revoke permissions for a service SAS without having to regenerate the storage account keys. これらの有効期限をきわめて遠い将来 (または無期限) に設定し、それがさらに将来へ移動するように、定期的に更新されるようにします。Set the expiration on these very far in the future (or infinite) and make sure it's regularly updated to move it farther into the future.
  • アドホック SAS サービスまたはアカウント SAS には、短期間の有効期限を使用します。Use near-term expiration times on an ad hoc SAS service SAS or account SAS. こうすると、SAS が侵害された場合でも、有効である期間はほんの短い期間になります。In this way, even if a SAS is compromised, it's valid only for a short time. この方法は、保存されているアクセス ポリシーを参照できない場合に特に重要です。This practice is especially important if you cannot reference a stored access policy. また、短期間の有効期限は、BLOB にアップロード可能な時間が制限されるので、BLOB に書き込むことのできるデータの量も制限します。Near-term expiration times also limit the amount of data that can be written to a blob by limiting the time available to upload to it.
  • 必要に応じて、クライアントに SAS を自動更新させます。Have clients automatically renew the SAS if necessary. クライアントは、SAS を提供するサービスが利用不可である場合に再試行する時間を考慮して、有効期限までに余裕を持って SAS を更新する必要があります。Clients should renew the SAS well before the expiration, in order to allow time for retries if the service providing the SAS is unavailable. 使用する SAS が、すぐに実行する短期間の少数の操作用であり、操作が、指定された有効期限の前に完了する予定である場合は、SAS が更新されないため、この方法は必要ありません。If your SAS is meant to be used for a small number of immediate, short-lived operations that are expected to be completed within the expiration period, then this may be unnecessary as the SAS is not expected to be renewed. ただし、クライアントが SAS 経由で日常的に要求を実行する場合は、有効期限に注意が必要になる可能性があります。However, if you have client that is routinely making requests via SAS, then the possibility of expiration comes into play. 重要な考慮事項は、SAS の有効期限を短くする必要性 (前述のように) と、更新の完了前に SAS の期限が切れることによる中断を避けるためにクライアントが早めに更新を要求する必要性とのバランスです。The key consideration is to balance the need for the SAS to be short-lived (as previously stated) with the need to ensure that the client is requesting renewal early enough (to avoid disruption due to the SAS expiring prior to successful renewal).
  • SAS の開始時刻に注意します。Be careful with SAS start time. SAS の開始時刻を [現在] に設定すると、クロック スキュー (さまざまなコンピューター間での現在時刻の差) により、最初の数分間にエラーが断続的に表示される場合があります。If you set the start time for a SAS to now, then due to clock skew (differences in current time according to different machines), failures may be observed intermittently for the first few minutes. 一般に、開始時刻は 15 分以上前になるように設定します。In general, set the start time to be at least 15 minutes in the past. または、まったく設定せず、すべての場合ですぐに有効になるようにします。Or, don't set it at all, which will make it valid immediately in all cases. 同じことが、一般的には有効期限にも適用されます。どの要求でも、前後 15 分以内のクロック スキューが発生する可能性があることを憶えておいてください。The same generally applies to expiry time as well--remember that you may observe up to 15 minutes of clock skew in either direction on any request. 2012-02-12 より前の REST バージョンを使用するクライアントの場合、保存されているアクセス ポリシーを参照しない SAS の最長期間は 1 時間であり、それより長い期間を指定するポリシーはすべて失敗します。For clients using a REST version prior to 2012-02-12, the maximum duration for a SAS that does not reference a stored access policy is 1 hour, and any policies specifying longer term than that will fail.
  • アクセス先のリソースを具体的に指定します。Be specific with the resource to be accessed. セキュリティのベスト プラクティスは、必要最小限の権限をユーザーに付与することです。A security best practice is to provide a user with the minimum required privileges. ユーザーに必要なのは、1 つのエンティティへの読み取りアクセスだけの場合は、すべてのエンティティへの読み取り/書き込み/削除アクセスではなく、その 1 つのエンティティへの読み取りアクセスだけをユーザーに許可します。If a user only needs read access to a single entity, then grant them read access to that single entity, and not read/write/delete access to all entities. これは、攻撃者の管理下での SAS の機能を低下させるため、SAS が侵害された場合に損害を抑えるためにも役立ちます。This also helps lessen the damage if a SAS is compromised because the SAS has less power in the hands of an attacker.
  • アカウントは、SAS によるものも含め、すべての使用について課金されることを理解します。Understand that your account will be billed for any usage, including via a SAS. BLOB への書き込みアクセスを許可した場合は、ユーザーが 200 GB の BLOB をアップロードする可能性があります。If you provide write access to a blob, a user may choose to upload a 200 GB blob. ユーザーに読み取りアクセスも許可すると、この BLOB を 10 回ダウンロードする可能性があり、2 TB (テラバイト) の送信料金が発生します。If you've given them read access as well, they may choose to download it 10 times, incurring 2 TB in egress costs for you. したがって、悪意のあるユーザーによるリスクが軽減されるように、制限付きアクセス許可を付与してください。Again, provide limited permissions to help mitigate the potential actions of malicious users. このような脅威が軽減されるように、短期間の SAS を使用してください (ただし、終了時刻のクロック スキューには注意してください)。Use short-lived SAS to reduce this threat (but be mindful of clock skew on the end time).
  • SAS を使用して書き込まれたデータを検証します。Validate data written using a SAS. クライアント アプリケーションがストレージ アカウントにデータを書き込む場合は、そのデータに問題がある可能性に注意してください。When a client application writes data to your storage account, keep in mind that there can be problems with that data. データが検証後または認証後に使用可能になることをアプリケーションが要求する場合は、書き込まれたデータをアプリケーションが使用する前に、この検証を実行する必要があります。If your application requires that data be validated or authorized before it is ready to use, you should perform this validation after the data is written and before it is used by your application. これを実行すると、ユーザーが SAS を正当に入手している場合でも、漏えいした SAS を利用している場合でも、破損データまたは悪意によるデータの書き込みからアカウントが保護されます。This practice also protects against corrupt or malicious data being written to your account, either by a user who properly acquired the SAS, or by a user exploiting a leaked SAS.
  • SAS を使用しない場合を認識します。Know when not to use a SAS. ストレージ アカウントに対する特定の操作に関連するリスクが、SAS を使用する利点より重大である場合もあります。Sometimes the risks associated with a particular operation against your storage account outweigh the benefits of using a SAS. このような操作については、ビジネス ルールの検証、認証、および監査を実行した後にストレージ アカウントに書き込む中間層サービスを作成します。For such operations, create a middle-tier service that writes to your storage account after performing business rule validation, authentication, and auditing. また、別の方法でアクセスを管理した方が容易である場合もあります。Also, sometimes it's simpler to manage access in other ways. たとえば、コンテナー内のすべての BLOB が一般ユーザーに読み取り可能である場合は、すべてのクライアントにアクセス用の SAS を提供するのではなく、コンテナーをパブリックにします。For example, if you want to make all blobs in a container publicly readable, you can make the container Public, rather than providing a SAS to every client for access.
  • Azure Monitor と Azure Storage ログを使用してアプリケーションを監視します。Use Azure Monitor and Azure Storage logs to monitor your application. Azure Monitor や Storage Analytics ログを使用して、SAS プロバイダー サービスが中断したり、保存されているアクセス ポリシーを不注意で削除したりしたために発生する認証失敗の急増を監視できます。You can use Azure Monitor and storage analytics logging to observe any spike in authorization failures due to an outage in your SAS provider service or to the inadvertent removal of a stored access policy. 詳細については、「Azure Monitor の Azure Storage メトリック」および「Azure Storage Analytics のログ」を参照してください。For more information, see Azure Storage metrics in Azure Monitor and Azure Storage Analytics logging.

SAS の概要Get started with SAS

Shared Access Signature の使用を開始するには、SAS の各種類に関する次の記事を参照してください。To get started with shared access signatures, see the following articles for each SAS type.

ユーザー委任 SASUser delegation SAS

サービス SASService SAS

アカウント SASAccount SAS

次の手順Next steps