Azure Storage セキュリティのベスト プラクティスを適用する
Shared Access Signature (SAS) を作成して使用する方法と、ストレージ セキュリティ ソリューションに対してそれが提供できる利点を確認しました。
アプリケーションで SAS を使用すると、潜在的なリスクの可能性があることを理解しておくことが重要です。
SAS が侵害された場合、それを取得した人はだれでも (悪意のあるユーザーも含めて) それを使用できます。
クライアント アプリケーションに提供された SAS の有効期限が切れた場合、アプリケーションがサービスから新しい SAS を取得できないと、アプリケーションの機能が損なわれる可能性があります。
ストレージをセキュリティで保護する方法の詳細については、このビデオをご覧ください。 このビデオは、「Azure のヒントとコツ #272 Azure セキュリティのベスト プラクティス」に基づいています。
リスク管理に関する推奨事項
SAS を使用する際のリスクを軽減するのに役立つ推奨事項をいくつか見てみましょう。
| 推奨 | Description |
|---|---|
| 作成と配布には常に 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 を含む使用量に対するアカウントの課金について理解する | BLOB への書き込みアクセスを許可した場合、ユーザーが 200 GB の BLOB をアップロードする可能性があります。 ユーザーに読み取りアクセスも許可すると、その BLOB を 10 回ダウンロードする可能性があり、2 TB のエグレス料金が発生します。 したがって、悪意のあるユーザーによるリスクが軽減されるように、制限付きアクセス許可を付与してください。 このような脅威を軽減するには、短期間の SAS を使います。ただし、終了時刻のクロック スキューに注意してください。 |
| SAS を使って書き込まれたデータを検証する | クライアント アプリケーションが Azure ストレージ アカウントにデータを書き込む場合は、そのデータに問題がある可能性に注意してください。 アプリケーションで検証済みまたは認可済みのデータが必要な場合は、書き込まれてから使われるまでの間にデータを検証します。 これを実行すると、SAS を正当に入手しているユーザーでも、漏えいした SAS を悪用しているユーザーに対しても、破損データまたは悪意によるデータの書き込みからアカウントが保護されます。 |
| SAS が常に正しい選択であると思い込まないようにする | Azure ストレージ アカウントに対する特定の操作に関連するリスクが、SAS を使用する利点より重大である場合があります。 このような操作については、ビジネス ルールの検証、認証、および監査を実行した後にストレージ アカウントに書き込む中間層サービスを作成します。 また、別の方法でアクセスを管理する方が容易な場合もあります。 コンテナー内のすべての BLOB を一般ユーザーが読み取れるようにする場合は、すべてのクライアントにアクセス用の SAS を提供するのではなく、コンテナーをパブリックにします。 |
| Azure Storage Analytics でアプリケーションを監視する | ログとメトリックを使って、認証エラーの急増を観察できます。 そのような急増は、SAS プロバイダー サービスの停止や、保存されているアクセス ポリシーの不注意による削除によって、発生する可能性があります。 |