ゼロ トラストの基本原則に従ったアプリケーションの設計と実装を目指す開発者は、最小限の特権でアプリケーションのセキュリティを強化したいと考えています。 アプリケーションの攻撃対象領域とセキュリティ侵害の影響を減らすことが不可欠です。
この記事では、アプリケーションが必要以上のアクセス許可を要求すべきではない理由について説明します。 overprivilege という用語について学習します。 アプリケーションの特権を制限し、アクセスを管理し、セキュリティを強化するための推奨事項とベスト プラクティスを見つけ出します。
「overprivilege」とは、システムで通常より多くのアクセス権限を持つ状態を指します。
Overprivilege は、アプリケーションが適切に機能するために必要以上のアクセス許可を要求または受信したときに発生します。 この記事の残りの部分では、使用されていないアクセス許可と軽減可能なアクセス許可の例を使用して、過剰な特権に対する理解を深めます。
未使用のアクセス許可
この未使用のキーの例では、次の図に示すように、3 つのロックされたドア (青、黄、緑) があるとします。
資産はドアの後ろにあります。 対応するドアを開くことができる 3 つのキー (青、黄、緑) があります。 たとえば、青いキーで青いドアを開くことができます。 黄色のドアにのみアクセスする必要がある場合は、黄色のキーのみを持ち歩きます。
資産を最適に保護するには、必要なときに必要なキーのみを保持し、未使用のキーを安全な場所に保管します。
削減可能なアクセス許可
縮小可能なキーの例は、次の図に示すように、2 つの特殊なキーを追加する未使用のキーの例よりも複雑です。
最初の黒いキーは、すべてのドアを開くことができるパスキーです。 2 番目の黒いキーは、黄色と緑のドアを開くことができます。 黄色と緑のドアにのみアクセスする必要がある場合は、2 番目の黒いキーのみを持ち歩きます。 パス キーは、冗長な緑色のキーを使用して安全な場所に保持します。
Microsoft ID プラットフォームでは、キーはアクセス許可です。 あなたとリソース、そしてあなたがキー保持者であることはアプリケーションです。 不要なキーを保持するリスクを理解している場合は、不要なアクセス許可を持つアプリケーションのリスクを認識している必要があります。
アクセス許可のギャップとリスク
ドアとキーは、オーバープライビレジがどのように発生するかを理解するのにどのように役立ちますか? アプリケーションにタスクを実行するための適切なアクセス許可があるのに、引き続き過剰に特権が与えられるのはなぜですか? 次の図で、不一致の原因となる可能性があるアクセス許可のギャップを見てみましょう。
X 軸は 時間 を表し、Y 軸は権限を表 します。 測定された 時間の開始時に、アプリケーションのアクセス許可を要求して受け取ります。 ビジネスが成長し、時間の経過とともに変化するにつれて、ニーズをサポートする新しいアクセス許可を追加し、 付与されたアクセス許可 の傾きが増加します。 不要な アクセス許可 (アプリケーションが中断しない場合など) を削除し忘れた場合、使用されるアクセス許可が [ 許可された アクセス許可] よりも低い場合、 アクセス許可ギャップが発生する可能性があります。
Microsoft ID プラットフォームの興味深い観察を次に示します。
- Microsoft Graph には 4,000 を超える API があります。
- Microsoft ID プラットフォームでは、200 を超える Microsoft Graph アクセス許可を使用できます。
- 開発者は幅広いデータにアクセスでき、アプリが要求するアクセス許可に細分性を適用できます。
- 調査の結果、アプリはシナリオに対して 10% のアクセス許可のみを完全に利用していることがわかりました。
アプリに必要なアクセス許可について慎重に検討してください。 アクセス許可のギャップに注意し、アプリケーションのアクセス許可を定期的に確認します。
過剰な権限を持つユーザーのセキュリティが欠如していた
たとえば、アクセス許可のギャップによって生じるリスクについて詳しく説明します。 この妥協のシナリオは、IT 管理者と開発者の 2 つの役割で構成されます。
- IT 管理者: Jeff は、Microsoft Entra ID 内のアプリケーションが信頼でき、安全であることを保証するテナント管理者です。 Jeff の仕事の一部は、アプリ開発者が必要とするアクセス許可に同意を付与することです。
- 開発者: Kelly は、Microsoft ID プラットフォームを使用し、アプリを所有するアプリ開発者です。 Kelly の仕事は、アプリケーションが必要なタスクを実行するための適切なアクセス許可を持っていることを確認することです。
次の一般的なオーバープライビレジ セキュリティ侵害シナリオには、通常、4 つの段階があります。
- 開発者は、アプリケーションの構成と必要なアクセス許可の追加を開始します。
- IT 管理者は、必要なアクセス許可を確認し、同意を付与します。
- 悪意のあるアクターがユーザー情報の解読を開始し、ユーザーのアイデンティティを正常にハッキングします。
- ユーザーが複数のアプリケーションを所有している場合、そのユーザーも特権が過剰になっています。 無効なアクターは、許可されたアクセス許可のトークンをすばやく使用して機密データを取得できます。
特権を超えるアプリケーション
エンティティは、必要以上のアクセス許可を要求または受信すると、過剰に特権を与えられます。 Microsoft ID プラットフォームでの 特権を超えるアプリケーション の定義は、 使用されていないアクセス許可または軽減可能なアクセス許可を持つ任意のアプリケーションです。
実際の例で Microsoft ID プラットフォームの一部として Microsoft Graph を使用して、使用されていないアクセス許可と減らされたアクセス許可について理解を深めましょう。
使用されていないアクセス許可は、アプリケーションが目的のタスクに必要のないアクセス許可を受け取ったときに発生します。 たとえば、予定表アプリを構築しているとします。 カレンダーアプリはFiles.ReadWrite.Allアクセス許可を要求して受け取ります。 アプリは、ファイルの API と統合されません。 そのため、アプリケーションには未使用の Files.ReadWrite.All アクセス許可があります。
削減可能な権限は発見が困難です。 これは、アプリケーションが少数のアクセス許可を受け取るが、必要なタスクに十分なアクセスを提供する低い特権の代替手段を持っている場合に発生します。 カレンダー アプリの例では、アプリはアクセス許可 Files.ReadWrite.All 要求して受け取ります。 ただし、サインインしているユーザーの OneDrive からファイルを読み取るだけで、新しいファイルを作成したり、既存のファイルを変更したりする必要はありません。 この場合、アプリケーションは Files.ReadWrite.All を部分的にしか利用しないため、 Files.Read.Allにダウングレードする必要があります。
特権を超えるシナリオを減らすための推奨事項
セキュリティは旅であり、目的地ではありません。 セキュリティ ライフサイクルには、次の 3 つの異なるフェーズがあります。
- 予防
- 監査
- Remediation
次の図は、特権を超えるシナリオを減らすための推奨事項を示しています。
- 禁止: アプリケーションをビルドするときに、アプリケーションで実行する必要がある API 呼び出しに必要なアクセス許可を完全に理解します。 シナリオを有効にするために必要なものだけを要求します。 Microsoft Graph のドキュメントには、すべてのエンドポイントのほとんどの特権アクセス許可に対する最小限の特権アクセス許可に関する明確な参照があります。 必要なアクセス許可を決定するときは、過剰な特権を持つシナリオに注意してください。
- 監査: あなたと IT 管理者は、以前に付与された既存のアプリケーションの特権を定期的に確認する必要があります。
- 修復: お客様または IT 管理者が、エコシステム内で過剰に特権を持つアプリケーションに気付いた場合は、特権を超えるアクセス許可のトークンの要求を停止します。 IT 管理者は、許可された同意を取り消す必要があります。 通常、この手順ではコードを変更する必要があります。
最小限の特権アクセス許可を維持するためのベスト プラクティス
アプリケーションで最小限の特権のアクセス許可を維持するための 2 つの主要なインセンティブは、アプリケーションの導入を促進し、普及を停止することです。
- 過剰なアクセス許可要求を回避する信頼できるアプリを構築することで、導入を促進します。 アプリケーションのアクセス許可を、タスクを完了するために必要なもののみに制限します。 この方法により、攻撃の影響範囲が限定され、アプリの利用者数が増加します。 アプリケーションが要求するアクセス許可を確認し、アプリのアクセス許可を付与するかどうかを決定するときに、さらに詳しい調査を適用します。
- 不正なアクターが過剰な特権を使用してさらにアクセスできないようにすることで、拡散を停止します。 不要なアクセス許可を要求するアプリを作成すると、承認を受けたり、完全に拒否されたりする可能性が最も低くなります。 損害を制御する最善の方法は、不正なアクターが昇格された特権を取得して侵害の範囲を広げることを防ぐことです。 たとえば、アプリケーションがユーザーの基本情報を読み取る
User.ReadBasic.Allしかない場合、アプリが侵害された場合、OneDrive、Outlook、Teams、および機密データは安全です。
次のステップ
- 「リソースにアクセスするための承認の取得」は、アプリケーション用にリソースのアクセス許可を取得するときにゼロ トラストを確保する最善の方法を理解するのに役立ちます。
- ID に対するゼロ トラスト アプローチを使用してアプリを構築すると 、アクセス許可とアクセスのベスト プラクティスの概要が提供されます。
- 「トークンのカスタマイズ」では、Microsoft Entra トークンで受け取ることができる情報について説明しています。 最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御を向上させるためにトークンをカスタマイズする方法について説明します。
- 「トークンでのグループ要求とアプリ ロールの構成」は、アプリ ロール定義を使用してアプリを構成し、セキュリティ グループをアプリ ロールに割り当てる方法を説明しています。 これらの方法は、最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御を向上するのに役立ちます。
- アプリでゼロ トラストの準備を実現する: 最小特権の設計 は、Microsoft ID プラットフォームでの最小特権アクセスの原則を使用してアプリを設計するのに役立ちます。
- 最小限の特権の原則を使用してアプリケーションのセキュリティを強化 すると、アプリケーションの攻撃対象領域を減らし、セキュリティ侵害 (爆発半径) が Microsoft ID プラットフォーム統合アプリケーションで発生する場合の影響を軽減できます。
- Graph Explorer と Microsoft Graph のアクセス許可リファレンス を使用すると、Microsoft Graph API 呼び出しを選択してアプリ のシナリオを有効にし、対応するアクセス許可を最小限から最も高い特権で検索できます。