過剰特権のアクセス許可とアプリを減らす

ゼロ トラストの基本原則に従ったアプリケーションの設計と実装を目指す開発者は、最小限の権限によりアプリケーションのセキュリティを強化したいと考えます。 アプリケーションの攻撃面とセキュリティ違反の影響を減らすことが不可欠です。

この記事では、アプリケーションが必要以上のアクセス許可を要求すべきではない理由について説明します。 "過剰特権" という用語を理解し、アクセスを管理し、セキュリティを向上させるためにアプリケーションの特権を制限するための推奨事項とベスト プラクティスを見つけます。

権限が過剰とは

権限が過剰な状態は、アプリケーションが適切に機能するために必要なアクセス許可より多くを要求した場合または受け取った場合に発生します。 この記事の残りの部分では、未使用のアクセス許可と再割り当て可能なアクセス許可の例を使用して、過剰特権に関する理解を深めます。

未使用のアクセス許可

この未使用のキーの例では、次の図に示すように、3 つのロックされたドア (青、黄、緑) があるとします。

資産はドアの向こうにあります。 対応するドアを開くことができる 3 つの鍵 (青、黄、緑) を持っています。 たとえば、青い鍵は青いドアを開くことができます。 黄色のドアのみを使用する必要がある場合は、黄色の鍵のみを持ち歩きます。

資産を最適に保護するには、必要なときに必要な鍵のみを持ち歩き、使用しない鍵は安全な場所に保管します。

再割り当て可能なアクセス許可

再割り当て可能なキーの例は、未使用のキーの例よりも複雑であり、次の図に示すように、2 つの特殊なキーが追加されています。

1 つ目の黒い鍵は、すべてのドアを開くことができる親鍵です。 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 つの段階があります。

1. 1 つ目では、開発者がアプリケーションの構成と必要なアクセス許可の追加を開始します。
2. 2 つ目では、IT 管理者が必要なアクセス許可を確認し、同意を付与します。
3. 3 つ目では、不正を行う者がユーザー資格情報の解読を開始し、ユーザー ID のハッキングに成功します。
4. ユーザーが複数のアプリケーションを所有している場合は、そのアプリケーションも権限が過剰になります。 不正を行う者は、付与されたアクセス許可のトークンをすばやく使用して機密データを取得できます。

過剰な特権を持つアプリケーション

必要以上のアクセス許可を要求または受け取ると、エンティティの特権は過剰になります。 Microsoft ID プラットフォームにおける "過剰な特権が与えられているアプリケーション" の定義は、"未使用のアクセス許可または再割り当て可能なアクセス許可を持つすべてのアプリケーション" です。

実際の例の Microsoft ID プラットフォームの一部として Microsoft Graph を使用して、使用されていないアクセス許可と削減可能なアクセス許可について理解を深めましょう。

使用されていないアクセス許可は、アプリケーションが目的のタスクに必要のないアクセス許可を受け取ったときに発生します。 たとえば、カレンダー アプリを構築しているとします。 カレンダー アプリが Files.ReadWrite.All アクセス許可を要求して受け取ります。 アプリはファイルの API と統合されていません。 そのため、アプリケーションには使用されていない Files.ReadWrite.All アクセス許可があります。

削減可能なアクセス許可は検出がより困難です。 これは、アプリケーションが少数のアクセス許可を受け取っても、必要なタスクへの十分なアクセスを提供するより低い権限の代替手段を持っている場合に発生します。 カレンダー アプリの例では、アプリが Files.ReadWrite.All アクセス許可を要求して受け取ります。 しかし、サインインしているユーザーの OneDrive からファイルを読み取るだけでよく、新しいファイルを作成したり、既存のファイルを変更したりする必要はありません。 この場合、アプリケーションは部分的にしか Files.ReadWrite.All を利用しないため、Files.Read.All にダウングレードする必要があります。

権限が過剰なシナリオの削減に関する推奨事項

セキュリティは長い行程であって、目的地ではありません。 セキュリティのライフサイクルには、次の 3 つの異なるフェーズがあります。

• 防止
• 監査
• 修復

次の図は、過剰な特権が与えられたシナリオを減らすための推奨事項を示しています。

• Prevent (阻止): アプリケーションのビルド時は、アプリケーションが行う必要がある API 呼び出しに必要なアクセス許可を完全に理解し、シナリオを実現するのに必要なものだけを要求する必要があります。 Microsoft Graph のドキュメントには、すべてのエンドポイントに対し権限が付与されたほとんどのアクセス許可に対する最小権限のアクセス許可に関する明確な参照があります。 必要なアクセス許可を決定するときには、権限が過剰なシナリオに注意してください。
• Audit (監査): ユーザーと IT 管理者は、既存のアプリケーションの以前に付与された権限を定期的に確認する必要があります。
• Remediate (修復): ユーザーまたは IT 管理者がエコシステム内の権限が過剰なアプリケーションに気付いた場合は、権限が過剰なアクセス許可に対するトークンの要求を停止する必要があります。 IT 管理者は、付与された同意を取り消す必要があります。 通常このステップではコードを変更する必要があります。

最小権限のアクセス許可を維持するためのベスト プラクティス

アプリケーションで最小特権のアクセス許可を維持するための 2 つの主要なインセンティブは、アプリケーション導入の促進と拡散の阻止です。

• 過剰なアクセス許可要求を回避する、顧客にとって信頼できるアプリを構築することで、導入を促進します。 アプリケーションのアクセス許可を、タスクを完了するのに必要なもののみに制限します。 このプラクティスにより、攻撃の潜在的な被害範囲が減少し、顧客のアプリ導入が増加します。 アプリケーションが要求するアクセス許可を確認し、アプリのアクセス許可を付与するかどうかを決定するときに、さらに詳しく調査してください。
• 攻撃者が過剰な権限を使用してさらなるアクセスを獲得できないようにすることで、拡散を阻止します。 不要なアクセス許可を要求するアプリを作成すると、承認を受ける可能性が最も低くなるか、完全に拒否されます。 損害を抑制する最善の方法は、攻撃者が侵害の範囲を広げる昇格された特権を取得するのを防ぐことです。 たとえば、ユーザーの基本情報を読み取るためにアプリケーションに User.ReadBasic.All のみがある状態で、アプリが侵害された場合、OneDrive、Outlook、Teams、および機密データは安全です。

次のステップ

• 「リソースにアクセスするための承認を取得する」は、アプリケーションのリソース アクセス許可を取得するときにゼロ トラストを保証する最善の方法を理解するのに役立ちます。
• 「ID に対するゼロ トラストアプローチを使用したアプリの構築」では、アクセス許可とアクセスのベスト プラクティスの概要について説明しています。
• 「トークンのカスタマイズ」は、Microsoft Entra トークンで受け取ることができる情報について説明します。 最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御を向上させるようにトークンをカスタマイズする方法について説明します。
• 「トークンでのグループ要求とアプリ ロールの構成」では、アプリ ロール定義を使用してアプリを構成し、セキュリティ グループをアプリ ロールに割り当てる方法を示します。 これらの方法は、最小限の特権でアプリケーションのゼロ トラスト セキュリティを強化しながら、柔軟性と制御を向上させるのに役立ちます。
• 「アプリのゼロ トラスト対応性を実現する: 最小権限の設計」は、Microsoft ID プラットフォームでの最低特権アクセスの原則を使用してアプリを設計するのに役立ちます。
• 「最小限の特権の原則でアプリケーションのセキュリティを高める」は、アプリケーションの攻撃面を縮小し、Microsoft ID プラットフォーム統合アプリケーションでセキュリティ侵害が発生した場合のセキュリティ違反 (被害範囲) を軽減するのに役立ちます。
• Graph エクスプローラーと Microsoft Graph のアクセス許可リファレンスを使用すると、Microsoft Graph API 呼び出しを選択してアプリのシナリオを有効にし、対応するアクセス許可を最小権限のものから最大権限のものまで検索できます。