共有access署名 (SAS) を使用してAzure Storageリソースに制限付きaccessを付与する

共有アクセス署名 (SAS) は、ストレージアカウント内のリソースへのセキュリティで保護された委任アクセスを提供します。 SAS を使用すると、クライアントがデータをaccessする方法をきめ細かく制御できます。 次に例を示します。

• クライアントがaccessするリソース。
• それらのリソースに対するアクセス許可。
• SAS が有効である期間。

共有アクセス署名の種類

Azure Storageでは、次の 3 種類の共有access署名がサポートされています。

• ユーザー委任 SAS
• Service SAS (サービス SAS)
• アカウント SAS

ユーザー委任 SAS

ユーザー委任 SAS は、Microsoft Entra 資格情報によって保護されるだけではなく、SAS に指定されたアクセス許可によっても保護されます。 ユーザー委任 SAS は、Blob Storage (Data Lake Storage および dfs エンドポイントを含む)、Queue Storage、Table Storage、またはAzure Filesでサポートされます。

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

サービス SAS

サービス SAS は、storage アカウント キーを使用してセキュリティで保護されます。 サービス SAS は、Azure Storage サービスの1つのリソース、具体的には、Blob Storage (Data Lake Storageおよびdfsエンドポイントを含む)、Queue Storage、Table Storage、またはAzure Files へのアクセスを委任します。

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

アカウント SAS

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

アクセス権を以下の対象に委任することもできます。

• サービスレベルの操作 (Get/Set Service Properties および Get Service Stats 操作など)。
• サービス SAS で許可されていない読み取り、書き込み、削除の各操作。

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

共有アクセス署名は、次の2つの形式のいずれかを選択できます。

• アドホック SAS。 アドホック SAS を作成すると、開始時刻、有効期限、およびアクセス許可が SAS URI で指定されます。 任意の種類の SAS を、アドホック SAS にできます。
• 保存されたアクセス ポリシーを持つサービス SAS。 格納されているaccess ポリシーは、BLOB コンテナー、テーブル、キュー、またはファイル共有であるリソース コンテナーで定義されます。 格納されているaccess ポリシーを使用して、1 つ以上のサービス共有access署名の制約を管理できます。 サービス SAS を保存されたaccess ポリシーに関連付けると、SAS は、保存されているaccess ポリシーに対して定義された制約 (開始時刻、有効期限、アクセス許可) を継承します。

共有アクセス署名の仕組み

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

SAS の署名と承認

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

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

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

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

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

サービス SAS とアカウント SAS の両方が、storage アカウント キーを使用して署名されます。 アカウント キーで署名された SAS を作成するには、アプリケーションがアカウント キーにaccessする必要があります。

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

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

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

SAS トークン

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

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

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

共有アクセス署名を使用するタイミング

SAS を使用して、ストレージ アカウント内のリソースにアクセス許可を持たないクライアントに、セキュリティで保護されたアクセスを付与します。

SAS が役立つ一般的なシナリオは、ユーザーが自分のデータをstorage アカウントに読み書きするサービスです。 storage アカウントがユーザー データを格納するシナリオでは、次の 2 つの一般的な設計パターンがあります。

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

   

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

   

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

さらに、特定のシナリオでは、コピー操作でソース オブジェクトへのaccessを承認するために SAS が必要です。

• 別のstorage アカウントに存在する別の BLOB に BLOB をコピーする場合。 必要に応じて、SAS を使用して、宛先 BLOB へのaccessを承認することもできます。
• 別のstorage アカウントに存在する別のファイルにファイルをコピーする場合。 必要に応じて、SAS を使用して、宛先ファイルへのaccessを承認することもできます。
• BLOB をファイルにコピーする場合、またはファイルを BLOB にコピーする場合。 ソース オブジェクトとコピー先オブジェクトが同じstorage アカウント内に存在する場合でも、SAS を使用する必要があります。

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

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

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

共有access署名を使用するための次の推奨事項は、これらのリスクを軽減するのに役立ちます。

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

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

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

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

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

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

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

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

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

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

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

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

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

• SAS を使用しないほうがよい場合を見極める。 storage アカウントに対する特定の操作に関連するリスクが、SAS を使用する利点を上回る場合があります。 このような操作の場合は、ビジネス ルールの検証、認証、監査を実行した後、storage アカウントに書き込む中間層サービスを作成します。 また、他の方法でaccessを管理する方が簡単な場合もあります。 たとえば、コンテナー内のすべての BLOB をパブリックに読み取り可能にする場合は、accessのすべてのクライアントに SAS を提供するのではなく、コンテナーをパブリックにすることができます。

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

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

SASを始めよう

共有アクセス署名を使用して始めるには、SAS の種類ごとに次の記事を参照してください。

ユーザー委任 SAS

• PowerShell を使用してコンテナーまたは BLOB のユーザー委任 SAS を作成します
• Azure CLI を使用してコンテナーまたは BLOB のユーザー委任 SAS を作成する
• .NET を使用してコンテナーまたは BLOB のユーザー委任 SAS を作成します
• Python を使用してコンテナーまたは BLOB のユーザー委任 SAS を作成します
• JavaScript を使用してコンテナーまたは BLOB のユーザー委任 SAS を作成します
• Java を使用してコンテナーまたは BLOB のユーザー委任 SAS を作成する

サービス SAS

• .NET を使用してコンテナーまたはブロブのサービス SAS を作成します
• Python を使用してコンテナーまたは BLOB のサービス SAS を作成する
• JavaScript を使用してコンテナーまたは BLOB のサービス SAS を作成する
• Java を使用してコンテナーまたは BLOB のサービス SAS を作成する

アカウント SAS

• .NET
• Python を使用してアカウント SAS を作成します
• JavaScript を使用してアカウント SAS を作成します
• Javaを使用してアカウントSASを作成します

次のステップ

• 共有アクセス署名 (REST API)を使用してアクセス権を委譲します
• ユーザー委任 SAS (REST API) を作成する
• サービス SAS を作成する (REST API)
• アカウント SAS を作成する (REST API)