Shared Access Signature を作成する
Shared Access Signature (SAS) は、Azure Storage リソースへの制限付きアクセス権を付与する URI (Uniform Resource Identifier) です。 SAS を使用すると、アカウント キーを侵害されることなくストレージ リソースを共有できます。
ストレージ アカウント キーへのアクセス権を持ってはならないクライアントには、SAS を提供できます。 これらのクライアントに SAS URI を配布して、指定した期間だけリソースへのアクセスを許可します。 通常、SAS は、自分のストレージ アカウントに対して他のユーザーがデータの読み取りや書き込みを行うサービスに対して使用します。
ユーザー委任 SAS は、Microsoft Entra 資格情報と、SAS に指定されたアクセス許可によって保護されます。 ユーザー委任 SAS は、Blob Storage と Data Lake Storage でサポートされています。
サービス レベルの SAS で許可できるあらゆるものに加えて、その他のリソースや機能へのアクセスを許可するアカウント レベルの SAS。 たとえば、アカウント レベルの SAS を使用すると、ファイル システムの作成を許可できます。
ストレージ アカウント内の特定のリソースへのアクセスを許可する サービス レベルの SAS 。 たとえば、ファイル システム内のファイルのリストの取得や、ファイルのダウンロードをアプリに許可するには、この種の SAS を使います。
サーバー側でサービス レベルの SAS を使っている場合、保存されているアクセス ポリシーで別のレベルの制御を提供できます。 SAS をグループ化し、保存されているアクセス ポリシーを使って他の制限を指定できます。
リスク管理に関する推奨事項
SAS を使用する際のリスクを軽減するのに役立つ推奨事項をいくつか見てみましょう。
| 勧告 | 説明 |
|---|---|
| 作成と配布には常に HTTPS を使用する | SAS が HTTP で渡されてインターセプトされた場合、攻撃者は SAS をインターセプトして使用できます。 このような "中間者攻撃" により、機密データが侵害されたり、悪意のあるユーザーによってデータが損壊されたりするおそれがあります。 |
| 保存されているアクセス ポリシーを可能な限り参照する | 保存されているアクセス ポリシーを使うと、Azure ストレージ アカウント キーを再生成せずに、アクセス許可を失効させることができます。 ストレージ アカウント キーの有効期限の日付は、遠い将来に設定します。 |
| 計画外の SAS の有効期限の近い期間を設定する | SAS の有効性を短時間に制限することで、SAS が侵害された場合の攻撃を軽減できます。 この方法は、保存されているアクセス ポリシーを参照できない場合に重要です。 また、短期間の有効期限は、BLOB にアップロード可能な時間が制限されるので、BLOB に書き込むことのできるデータの量も制限します。 |
| クライアントに SAS の自動更新を要求する | クライアントに、有効期限が切れるかなり前に SAS を更新するよう要求します。 早く更新すると、SAS を提供するサービスが使用できない場合に再試行する時間があります。 |
| SAS の開始時刻を慎重に計画する | SAS の開始時刻を "今すぐ" に設定すると、クロック スキュー (さまざまなコンピューター間での現在時刻の差) により、最初の数分間にエラーが間欠的に発生する場合があります。 一般に、開始時刻は 15 分以上過去に設定します。 または、特定の開始時刻を設定しないようにします。このようにすると、SAS はすべてのケースですぐに有効になります。 通常、有効期限についても同じことがいえます。 どの要求でも、前後に最大 15 分のクロック スキューが発生する可能性があります。 2012 年 2 月 12 日より前の REST API バージョンを使っているクライアントの場合、保存されているアクセス ポリシーを参照しない SAS の最長期間は 1 時間です。 長い期間を指定するポリシーはいずれも失敗します。 |
| リソースの最小アクセス許可を定義する | セキュリティのベスト プラクティスは、必要最小限の権限をユーザーに付与することです。 ユーザーに必要なのは、1 つのエンティティへの読み取りアクセスだけの場合は、すべてのエンティティへの読み取り/書き込み/削除アクセスではなく、その 1 つのエンティティへの読み取りアクセスだけをユーザーに許可します。 この方法は、攻撃者の管理下での SAS の機能を低下させるため、SAS が侵害された場合に損害を抑えるためにも役立ちます。 |
| SAS を使用して書き込まれたデータを検証する | クライアント アプリケーションが Azure ストレージ アカウントにデータを書き込む場合は、そのデータに問題がある可能性に注意してください。 アプリケーションで検証済みまたは認可済みのデータが必要な場合は、データを使用する前に、書き込んだ後に検証します。 これを実行すると、ユーザーが SAS を正当に入手している場合でも、漏えいした SAS を利用している場合でも、破損データまたは悪意によるデータの書き込みからアカウントが保護されます。 |
| SAS が常に正しい選択であると想定しないでください | Azure ストレージ アカウントに対する特定の操作に関連するリスクが、SAS を使用する利点より重大である場合があります。 このような操作については、ビジネス ルールの検証、認証、および監査を実行した後にストレージ アカウントに書き込む中間層サービスを作成します。 また、別の方法でアクセスを管理する方が容易な場合もあります。 コンテナー内のすべての BLOB を一般ユーザーが読み取れるようにする場合は、すべてのクライアントにアクセス用の SAS を提供するのではなく、コンテナーをパブリックにします。 |