本ブログは、Best practices regarding Azure Storage Keys, Azure Functions, and Azure Role Based Access の抄訳版です。最新の情報は原文を参照してください。
概要
Azure は、開発者とセキュリティ運用スタッフに、組織のニーズを満たすために構成可能なさまざまなセキュリティ オプションを提供します。ソフトウェア開発ライフサイクル全体を通じて、お客様が共有責任モデルを理解し、さまざまなセキュリティのベスト プラクティスに精通していることが重要です。これは、Azure Functions のデプロイと Azure ロールベースのアクセス制御のプロビジョニングにおいて、お客様がアプリケーション、ID、およびデータの構成と管理を担当するため、特に重要です。時に、お客様が過度に広範囲なアクセス許可を付与する場合があります。この場合、これらの権限が悪用され、お客様のテナント内の追加リソースにアクセスされる危険性があります。最近 Orca Security によって、そのような問題が報告されました。マイクロソフト セキュリティ レスポンスセンターは、調査の上、セキュリティの問題ではないと判断しました。しかし、この状況は、お客様がより効果的に最小限の特権と多層防御を導入し、攻撃者に対してより強くなるように、議論と改善が必要であると考えました。
継続的なエクスペリエンスの改善の一環として、Azure Functions チームは、Functions クライアント ツールとストレージ アカウントとの連携方法を更新する予定です。これには、ID を使用したシナリオをより適切にサポートするための変更が含まれます。AzureWebJobsStorage の ID ベースの接続が一般提供され、新しいエクスペリエンスが検証されると、ID が AzureWebJobsStorage の既定のモードになり、共有キーの承認から移行することを目的としています。 さらに、お客様は以下のガイダンスを確認して、最小限の特権で組織のニーズに合わせて環境が構成されていることを確認する必要があります。
Azure Functions と Azure Storage Authorization の多層防御
Azure Functions では、いくつかの目的でストレージが使用されます。AzureWebJobsStorage 接続は、トリガーのチェックポイント データの処理や分散ロック管理など、一般的なランタイム動作に使用されます。Azure Function のコードは、AzureWebJobsStorage 接続で指定されたアカウントに格納できますが、これは選択したデプロイ方法によって異なります。これはほとんどのセットアップの既定値ではなく、Functions には、別の BLOB ストアに格納されているコンテンツの参照など、アプリケーション コードに対して複数のデプロイ オプションが用意されています。AzureWebJobsStorage 接続では、既定でストレージ アカウントの接続文字列が使用されますが、AzureWebJobsStorage の ID ベースの接続のプレビューがあります。
既定のストレージ アカウントの接続文字列を利用することに加えて、お客様は環境内のユーザーにアクセスをプロビジョニングすることもできます。共有責任モデル に従って、アクセス管理はクラウドを使用するお客様の責任であり、ロールの割り当てを作成する際の重要な側面は、最小特権のセキュリティ原則に準拠した正しいスコープの割り当てを選択することです。アプリとユーザーには、厳密に必要以上に広範なアクセス権を付与しないでください。Azure には、Privileged Identity Management を通じて制限付きアクセスを許可する機能も用意されています。
既定では、listKeys にアクセスできるのは、ストレージ アカウントを作成した個人と継承された所有者のみです。マイクロソフトでは、ストレージ BLOB データ閲覧者やストレージ ファイル データ SMB 共有閲覧者などの組み込みロールを使用して、ストレージ アカウントの内容を読み取るアクセス許可を付与する、きめ細かいアクセスをユーザーに提供することをお勧めします。これらのロールには、ストレージ アカウント キーを一覧表示したり、コンテンツを変更したりするアクセス許可は含まれていません。ストレージ アカウント キーは、ストレージ アカウントの構成とそのすべてのデータへのフル アクセスを提供し、アクセス資格情報と同様に慎重に保護する必要があります。他の組み込みロールは、読み取りアクセスのみを必要とするユーザーには過剰なアクセス許可を Microsoft.Storage/storageAccounts/listKeys/action に付与する場合があります。
過剰な特権が付与され、その後使用された場合でも、お客様は Azure Monitor を介してそのストレージ アカウントに対して実行されたデータ プレーン アクションに関する分析情報を得ることができます。アクティビティ ログは、コントロール プレーンの操作を記述し、共有ストレージ キーにアクセスしたユーザーを監視するために使用できます。アクティビティ ログは、すべてのストレージ アカウントに対して既定で有効になっています。お客様は、Azure Function が格納されているストレージ アカウントで “listKeys” を検索することで、これを行うことができます。リソース ログを Azure Monitor で有効にして構成し、ストレージ アカウントの内容に対する変更を識別することもできます。お客様は、ストレージ アカウントにアクティビティ ログとリソース ログを構成し、疑わしいアクティビティがないかログを一貫して確認することを強くお勧めします。また、クライアントがストレージ アカウントへのアクセスを承認する方法を監視したり、共有キーまたは共有アクセス署名 (SAS) を使用してストレージ要求を承認しているクライアントを特定したりすることもできます。
継続的なエクスペリエンスの改善の一環として、Azure Functions チームは、Functions クライアント ツールとストレージ アカウントとの連携方法を更新する予定です。これには、ID を使用したシナリオをより適切にサポートするための変更が含まれます。AzureWebJobsStorage の ID ベースの接続が一般提供され、新しいエクスペリエンスが検証されると、ID が AzureWebJobsStorage の既定のモードになります。今後、Azure Functions クライアントは、ユーザーがこれらのエクスペリエンスで作成されたストレージ アカウントに対して “StorageWrite” リソース ログを有効にするのにも役立ちます。さらに、Azure Functions のドキュメントを更新して、最小限の特権を持つユーザーのストレージ アカウント アクセスを構成するためのベスト プラクティスをより明確にしました。
Azure Storage は、ID ベースの承認の包括的なサポートなど、セキュリティへの投資も継続しています。BLOB ストレージでは、Azure ABAC でのロール割り当て条件など、ロールベースのアクセス制御 (RBAC)が完全にサポートされています。最小限の特権でアクセスを簡単に制限するための組み込みロールの包括的なセットを提供します。Azure Files には、SMB 経由の Azure AD Kerberos のサポートが含まれるようになり、OAuth over REST のサポートが追加されています。これにより、Azure portal でファイルにアクセスするための ID ベースの承認のサポートも有効になります。また、新しいストレージ アカウントで共有キーと共有アクセス署名 (SAS) の承認を既定で無効にして、ロールベースのアクセスの使用を促進できるように、ガイダンスとサポートを計画しています。暫定的に、組織は Azure Policy を使用してストレージの ID ベースの承認の使用を強制できます。
Microsoft Defender for Cloud (MDC) では、セキュリティ アラートを強化するための機密データの自動検出、マルウェア スキャン、異常なアクセス パターンの検出、侵害された認証トークンの使用、データ流出など、ストレージ アカウントの監視も強化されています。
お客様への推奨アクション
悪用リスクを最小限に抑えるために、ストレージ アカウントへのユーザー アクセスに関して次のプラクティスを採用することをお勧めします。
- ユーザーのアクセス許可を確認して、ストレージ アカウントへの最小特権アクセスを確認します。さらに、アクセス許可の付与を必要最小限のスコープ (ストレージ アカウントやリソース グループなど) に制限できます。
- アカウント キーにアクセスするためのアクティビティ ログを監視します。
- ライフサイクル ポリシーと共に Azure Functions をホストするストレージ アカウントの StorageWrite リソース ログを有効にして、選択した期間のログの保有期間を管理します。
- アプリケーション コードを BLOB ストレージに格納する場合は、アクセスを制限できるように、その目的専用のストレージ アカウントを使用することを検討してください。
- ストレージ アカウントの MDC を有効にします。 上記の推奨アクションに加えて、既存のドキュメントを更新しました。お客様は、更新されたドキュメントを確認することをお勧めします。
まとめ
まとめとして、Orca Security によって報告された調査結果を調査する機会に感謝します。すべての研究者は、協調脆弱性開示(CVD)の下でベンダーと協力し、セキュリティ調査を実施している間に顧客データに影響を与えないように、侵入テストの契約規則を遵守することをお勧めします。セキュリティの問題を Microsoft セキュリティ レスポンス センターに報告した研究者は、Microsoft のバグ報奨金プログラムに参加する資格もあります。
Orca のレポートでは、お客様が最小限の特権で環境を正しく構成できるように、私たちが引き続き改善を続けることが強調されています。これらのシナリオのリスクは、適切な RBAC 管理を適用し、ユーザーに必要最低レベルのアクセス許可が委任されるようにすることで最小限に抑えることができます。現時点ではプレビュー段階ですが、AzureWebJobsStorage への ID ベース接続を使用すると、過剰な特権を持つアクセス許可の使用を防ぎます。Azure Storage には、ストレージ リソースに対する異常な変更や承認されていない変更を検出するための堅牢な監視機能も用意されています。同時に、ストレージ アカウント アクセスのユーザー特権を適切に構成することに関するお客様向けのガイダンスをさらに明確にできると考えているため、既存のドキュメントを更新しました。いつものように、セキュリティのベストプラクティスに従って、脆弱性やその他の種類のセキュリティイベントにさらされる可能性を制限することをお勧めします。