Shared Access Signatures (SAS) を使用して Azure Storage リソースへの制限付きアクセスを許可する

  • [アーティクル]

Shared Access Signature (SAS) を使用すると、ストレージ アカウント内のリソースへのセキュリティで保護された委任アクセスが可能になります。 SAS を使用すると、クライアントがデータにアクセスする方法をきめ細かく制御できます。 次に例を示します。

  • クライアントがアクセスできるリソース。

  • それらのリソースに対するアクセス許可。

  • SAS が有効である期間。

共有アクセス署名の種類

Azure Storage では、次の 3 種類の Shared Access Signature がサポートされています。

  • ユーザー委任 SAS

  • サービス SAS

  • アカウント SAS

重要

Shared Access Signature を使うシナリオには、ユーザー委任 SAS を使うことをお勧めします。 ユーザー委任 SAS は、アカウント キーの代わりに Microsoft Entra 資格情報で保護されており、優れたセキュリティを提供します。 データ アクセスの認可について詳しくは、「Azure Storage 内のデータへのアクセスを承認する」をご覧ください。

ユーザー委任 SAS

ユーザー委任 SAS は、Microsoft Entra 資格情報によって保護されるだけではなく、SAS に指定されたアクセス許可によっても保護されます。 ユーザー委任 SAS は、BLOB ストレージにのみ適用されます。

ユーザー委任 SAS の詳細については、ユーザー委任 SAS の作成 (REST API) に関するページを参照してください。

サービス SAS

サービス SAS は、ストレージ アカウント キーで保護されます。 サービス SAS は、次のうち 1 つだけの Azure Storage サービスのリソースへのアクセスを委任します。Blob storage、Queue storage、Table storage、または Azure Files。

サービス SAS の詳細については、 サービス SAS の作成 (REST API) に関するページを参照してください。

アカウント SAS

アカウント SAS は、ストレージアカウント キーで保護されます。 アカウント SAS は、1 つ以上のストレージ サービスのリソースへのアクセスを委任します。 サービスまたはユーザー委任 SAS を介して実行できるすべての操作は、アカウント SAS を介しても実行できます。

以下へのアクセスを委任することもできます。

  • サービスレベルの操作 (Get/Set Service Properties および Get Service Stats 操作など)。

  • サービス SAS で許可されていない読み取り、書き込み、削除の各操作。

アカウント SAS の詳細については、アカウント SAS の作成 (REST API) に関するページを参照してください。

Shared Access Signature の形式は、次の 2 つのいずれかです。

  • アドホック SAS。 アドホック SAS を作成すると、開始時刻、有効期限、およびアクセス許可が SAS URI で指定されます。 任意の種類の SAS を、アドホック SAS にできます。

  • 保存されているアクセス ポリシーによるサービス SAS。 保存されているアクセス ポリシーは、リソース コンテナー (BLOB コンテナー、テーブル、キュー、ファイル共有など) で定義されています。 保存されているアクセス ポリシーを使用して、1 つ以上の Shared Access Signature の制約を管理できます。 保存されているアクセス ポリシーにサービス SAS を関連付けると、SAS が、保存されているアクセス ポリシーに定義されている制約 (開始時刻、有効期限、およびアクセス許可) を継承します。

Note

ユーザー委任 SAS またはアカウント SAS はアドホック SAS である必要があります。 保存されているアクセス ポリシーは、ユーザー委任 SAS またはアカウント SAS ではサポートされていません。

Shared Access Signature の機能

Shared Access Signature は、Azure Storage リソースの URI に追加されるトークンです。 トークンは、クライアントからリソースへのアクセス方法を示す特殊なクエリ パラメーター一式を含んでいます。 クエリ パラメーターの 1 つである署名は、SAS パラメーターで作成されており、SAS の作成に使用されたキーで署名されています。 この署名は、ストレージ リソースへのアクセスを承認するために、Azure Storage によって使用されます。

Note

SAS トークンの生成は監査できません。 この作業は、SAS トークンを生成する特権を持つすべてのユーザーが、アカウント キーを使用するか Azure ロールの割り当てを使用して、ストレージ アカウントの所有者の知識なしで行うことができます。 SAS トークンの生成をユーザーに許可するアクセス許可は慎重に制限してください。 BLOB およびキューのワークロードのアカウント キーで署名された SAS をユーザーが生成できないようにするには、ストレージ アカウントへの共有キーによるアクセスを禁止します。 詳細については、「共有キーによる承認の防止」を参照してください。

SAS の署名と承認

SAS トークンには、ユーザー委任キーまたはストレージ アカウント キー (共有キー) を使用して署名できます。

ユーザー委任キーを使用して SAS トークンに署名する

SAS トークンには、Microsoft Entra 資格情報を使用して作成された "ユーザー委任キー" を使用して署名できます。 ユーザー委任 SAS は、ユーザー委任キーで署名されます。

キーを取得してから SAS を作成するには、Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey アクションを含む Azure ロールが Azure AD セキュリティ プリンシパルに割り当てられている必要があります。 詳細については、ユーザーの委任 SAS の作成 (REST API) に関するページを参照してください。

アカウント キーを使用して SAS トークンに署名する

サービス SAS とアカウント SAS は、どちらもストレージ アカウント キーを使用して署名されます。 アカウント キーで署名された SAS を作成するには、アプリケーションがアカウント キーにアクセスできる必要があります。

要求に SAS トークンが含まれている場合、その要求は、その SAS トークンがどのように署名されているかに基づいて承認されます。 SAS トークンの作成に使用するアクセス キーまたは資格情報は、SAS を所有するクライアントへのアクセスを付与するために Azure Storage でも使用されます。

次の表は、各種の SAS トークンを承認する方法についてまとめたものです。

SAS の種類 承認の種類
ユーザー委任 SAS(BLOB ストレージのみ) Microsoft Entra ID
サービス SAS 共有キー
アカウント SAS 共有キー

Microsoft では、セキュリティ向上のため、可能な限りユーザー委任 SAS を使用することを推奨しています。

SAS トークン

SAS トークンは、クライアント側で生成する文字列であり、たとえば、Azure Storage クライアント ライブラリのいずれかを使用します。 SAS トークンは、Azure Storage によって追跡されません。 クライアント側では、数に制限なく SAS トークンを作成できます。 SAS を作成したら、ストレージ アカウント内のリソースへのアクセスを必要とするクライアント アプリケーションに配布できます。

クライアント アプリケーションから、要求の一部として SAS URI が Azure Storage に提供されます。 次に、サービスによって SAS パラメーターと署名がチェックされ、それが有効であることが確認されます。 サービスによって署名が有効であることが確認されると、要求が承認されます。 それ以外の場合、要求はエラー コード 403 (Forbidden) で拒否されます。

以下に示したのは、サービス SAS URI の例です。リソース URI、区切り文字 ("?")、そして SAS トークンが示されています。

SAS トークンが含まれているリソース URI の構成要素を示している図。

注意

クエリ文字列の区切り文字 ("?") は SAS トークンには含まれません。 ポータル、PowerShell、Azure CLI、またはいずれかの Azure Storage SDK から SAS トークンを生成する場合は、リソース URL に区切り文字を追加する必要があります。

Shared Access Signature を使用するタイミング

SAS は、他の方法では、ストレージ アカウント内のリソースへのアクセス許可を持たないクライアントに、それらのリソースへのアクセスをセキュリティで保護する場合に使用します。

SAS が役立つ一般的なシナリオは、ストレージ アカウント内でユーザーが自分のデータの読み取りや書き込みを行うサービスです。 ストレージ アカウントにユーザー データが格納されるシナリオには、2 種類の典型的な設計パターンがあります。

  1. 認証を実行するフロントエンド プロキシ サービス経由で、クライアントがデータのアップロードとダウンロードを行います。 このフロントエンド プロキシ サービスにより、ビジネス ルールの検証が可能になります。 しかし、データやトランザクションが大量である場合は、需要に応じて拡張可能なサービスの作成にコストがかかったり、困難が生じたりする可能性があります。

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

  2. 軽量サービスが、必要に応じてクライアントを認証してから、SAS を生成します。 クライアント アプリケーションに SAS が届くと、ストレージ アカウント リソースに直接アクセスできるようになります。 アクセス許可は、SAS によって定義され、間隔は SAS によって許可されたものになります。 SAS によって、すべてのデータをフロントエンド プロキシ サービス経由でルーティングする必要性が減少します。

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

多くの実際のサービスでは、これら 2 つのアプローチを組み合わせて使用している場合があります。 たとえば、一部のデータは、フロントエンド プロキシを介して処理および検証される場合があります。 その他のデータは、SAS を使用して保存、読み取りが直接行われます。

また、特定のシナリオにおけるコピー操作でソース オブジェクトへのアクセスを承認するために、SAS が必要です。

  • BLOB を別のストレージ アカウント内にある他の BLOB にコピーする場合。

    コピー先 BLOB へのアクセスの承認にも、任意で SAS を使用できます。

  • ファイルを別のストレージ アカウント内にある他のファイルにコピーする場合。

    コピー先 BLOB へのアクセスの承認にも、任意で SAS を使用できます。コピー先ファイルへのアクセスの承認にも、任意で SAS を使用できます。

  • BLOB をファイルにコピーする場合、またはファイルを BLOB にコピーする場合。

    ソースおよびターゲットのオブジェクトが同じストレージ アカウント内に存在する場合でも、SAS を使用する必要があります。

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

アプリケーションで Shared Access Signature を使用する場合は、次の 2 つの潜在的なリスクに注意する必要があります。

  • SAS が漏洩すると、取得した人はだれでも使用できるため、ストレージ アカウントの安全性が損なわれるおそれがあります。

  • クライアント アプリケーションに提供された SAS が期限切れになり、アプリケーションがサービスから新しい SAS を取得できない場合は、アプリケーションの機能が損なわれる可能性があります。

Shared Access Signature の使用に関する次の推奨事項に従うと、これらのリスクの軽減に役立ちます。

  • 常に HTTPS を使用して SAS を作成または配布します。 SAS が HTTP 経由で渡され、傍受された場合、中間者攻撃を実行する攻撃者は SAS を読み取ることができます。 その後、彼らは意図したユーザーと同じようにその SAS を使用できます。 これにより、機密データが漏洩したり、悪意のあるユーザーによるデータの破損が発生したりする可能性があります。

  • 可能な限り、ユーザー委任 SAS を使用します。 ユーザー委任 SAS は、サービス SAS またはアカウント SAS に優れたセキュリティを提供します。 ユーザー委任 SAS は Microsoft Entra 資格情報で保護されているため、コードを使ってアカウント キーを保存する必要はありません。

  • SAS の失効計画を立てます。 SAS が侵害された場合に対応する準備ができていることを確認します。

  • ストレージ アカウントの SAS 有効期限ポリシーを構成します。 SAS 有効期限ポリシーには、SAS が有効である推奨間隔を指定します。 SAS 有効期限ポリシーは、サービス SAS またはアカウント SAS に適用されます。 推奨間隔よりも有効間隔が長いサービス SAS またはアカウント SAS をユーザーが生成すると、警告が表示されます。 Azure Monitor による Azure Storage のログ記録が有効な場合、Azure Storage のログにエントリが書き込まれます。 詳細については、「共有アクセス署名の有効期限ポリシーを作成する」を参照してください。

  • サービス SAS の保存されているアクセス ポリシーを作成します。 保存されているアクセス ポリシーを使用すると、ストレージ アカウント キーを再生成せずに、サービス SAS のアクセス許可を失効させることが可能になります。 これらの有効期限をきわめて遠い将来 (または無期限) に設定し、それがさらに将来へ移動するように、定期的に更新されるようにします。 保存されているアクセス ポリシーは、コンテナーごとに 5 つに制限されています。

  • アドホック SAS サービスまたはアカウント SAS には、短期間の有効期限を使用します。 こうすると、SAS が侵害された場合でも、有効である期間はほんの短い期間になります。 この方法は、保存されているアクセス ポリシーを参照できない場合に特に重要です。 また、短期間の有効期限は、BLOB にアップロード可能な時間が制限されるので、BLOB に書き込むことのできるデータの量も制限します。

  • 必要に応じて、クライアントに SAS を自動更新させます。 クライアントは、SAS を提供するサービスが利用不可である場合に再試行する時間を考慮して、有効期限までに余裕を持って SAS を更新する必要があります。 これは、場合によっては不要なことがあります。 たとえば、短時間で数の少ない即時操作に SAS を使用することを意図している場合がそれに該当します。 これらの操作は、有効期限内に完了することが想定されています。 そのため、SAS を更新する必要はありません。 ただし、クライアントが SAS 経由で日常的に要求を実行する場合は、有効期限に注意が必要になる可能性があります。

  • SAS の開始時刻に注意します。 SAS の開始時刻を現在の時刻に設定した場合は、最初の数分間に断続的なエラーが発生する場合があります。 これは、コンピューターごとに現在の時刻がそれぞれ若干異なるためです (時刻のずれと呼ばれます)。 一般に、開始時刻は 15 分以上前になるように設定します。 または、まったく設定せず、すべての場合ですぐに有効になるようにします。 同じことが、一般的には有効期限にも適用されます。どの要求でも、前後 15 分以内のクロック スキューが発生する可能性があることを憶えておいてください。 2012-02-12 より前の REST バージョンを使用するクライアントの場合、保存されているアクセス ポリシーを参照しない SAS の最長期間は 1 時間です。 1 時間より長い期間を指定するポリシーはいずれも失敗します。

  • SAS の datetime 形式に注意してください。 一部のユーティリティ (AzCopy など) では、日時の値を '+%Y-%m-%dT%H:%M:%SZ' という書式にする必要があります。 この形式には秒を明示的に含めます。

  • SAS を使用して、可能な限り最小限の特権を付与します。 セキュリティのベスト プラクティスは、可能な限り少ないリソースへの必要最小限の権限をユーザーに付与することです。 できれば読み取り専用の SAS を使用します。 ユーザーに必要なのが 1 つのオブジェクトへの読み取りアクセスだけの場合は、すべてのオブジェクトへの読み取り/書き込み/削除アクセスではなく、その 1 つのオブジェクトへの読み取りアクセスだけをユーザーに許可します。 これは、攻撃者の管理下での SAS の機能を低下させるため、SAS が侵害された場合に損害を抑えるためにも役立ちます。

    リソースにアクセスしたクライアントを特定する直接的な方法はありません。 ただし、SAS 内の一意のフィールドである、署名済み IP (sip)、署名済み開始 (st)、署名済み有効期限 (se) の各フィールドを使用してアクセスを追跡できます。 たとえば、一意の有効期限を持つ SAS トークンを生成して、その発行先のクライアントと関連付けることができます。

  • アカウントは、SAS によるものも含め、すべての使用について課金されることを理解します。 BLOB への書き込みアクセスを許可した場合は、ユーザーが 200 GB の BLOB をアップロードする可能性があります。 ユーザーに読み取りアクセスも許可すると、この BLOB を 10 回ダウンロードする可能性があり、2 TB (テラバイト) の送信料金が発生します。 したがって、悪意のあるユーザーによるリスクが軽減されるように、制限付きアクセス許可を付与してください。 このような脅威が軽減されるように、短期間の SAS を使用してください (ただし、終了時刻のクロック スキューには注意してください)。

  • SAS を使用して書き込まれたデータを検証します。 クライアント アプリケーションがストレージ アカウントにデータを書き込む場合は、そのデータに問題がある可能性に注意してください。 データの検証を計画している場合は、データが書き込まれてからアプリケーションで使用されるまでにその検証を実行します。 これを実行すると、ユーザーが SAS を正当に入手している場合でも、漏えいした SAS を利用している場合でも、破損データまたは悪意によるデータの書き込みからアカウントが保護されます。

  • SAS を使用しない場合を認識します。 ストレージ アカウントに対する特定の操作に関連するリスクが、SAS を使用する利点より重大である場合もあります。 このような操作については、ビジネス ルールの検証、認証、および監査を実行した後にストレージ アカウントに書き込む中間層サービスを作成します。 また、別の方法でアクセスを管理した方が容易である場合もあります。 たとえば、コンテナー内のすべての BLOB が一般ユーザーに読み取り可能である場合は、すべてのクライアントにアクセス用の SAS を提供するのではなく、コンテナーをパブリックにします。

  • Azure Monitor と Azure Storage ログを使用してアプリケーションを監視します。 承認エラーは、ご利用の SAS プロバイダー サービスが停止したことが原因で発生する可能性があります。 また、保存されているアクセス ポリシーを誤って削除した場合にも発生する可能性があります。 Azure Monitor とストレージ分析のログを使用すれば、このような種類の承認エラーの急増を観察することができます。 詳細については、「Azure Monitor の Azure Storage メトリック」および「Azure Storage Analytics のログ」を参照してください。

  • ストレージ アカウントの SAS 有効期限ポリシーを構成します。 ベスト プラクティスとして、SAS が侵害された場合に備えて、その間隔を制限することをお勧めします。 ストレージ アカウントに SAS の有効期限ポリシーを設定することで、ユーザーがサービス SAS またはアカウント SAS を作成するときに推奨される有効期限の上限を指定できます。 詳細については、共有アクセス署名の有効期限ポリシーの作成に関する記事を参照してください。

Note

ストレージは、ストレージ アカウント用に生成された共有アクセス署名の数を追跡しません。また、この詳細を提供する API はありません。 ストレージ アカウントに対して生成された共有アクセス署名の数を知る必要がある場合は、手動で数を追跡する必要があります。

SAS の概要

Shared Access Signature の使用を開始するには、SAS の各種類に関する次の記事を参照してください。

ユーザー委任 SAS

サービス SAS

アカウント SAS

次のステップ