次の方法で共有


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

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

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

権限が過剰とは

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

未使用のアクセス許可

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

図は、未使用のアクセス許可を示すために、対応するキーを持つ 3 つのドアを示しています。

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

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

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

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

図は、再割り当て可能なアクセス許可を示すために、対応するキーを持つ 3 つのドアを示しています。

1 つ目の黒い鍵は、すべてのドアを開くことができる親鍵です。 2 つ目の黒い鍵は、黄色のドアと緑のドアを開くことができます。 黄色のドアと緑のドアのみを使用する必要がある場合は、2 つ目の黒い鍵のみを持ち歩きます。 親鍵は、冗長な緑色の鍵を使用して安全な場所に保管します。

Microsoft ID の世界では、鍵はアクセス許可です。 リソースと鍵の所有者はアプリケーションです。 不要な鍵を持ち歩くリスクがわかれば、不要なアクセス許可を持つアプリケーションのリスクもわかります。

アクセス許可のギャップとリスク

ドアと鍵は、権限が過剰な状態がどのように発生するかを理解するのにどのように役立つでしょうか。 アプリケーションにタスクを実行するための適切なアクセス許可があるのに、それでも権限が過剰になるのはなぜでしょうか。 次の図で不一致の原因となる可能性があるアクセス許可のギャップを見てみましょう。

右のグラフ: Y 軸 - アクセス許可、X 軸 - 時間。上の曲線 - 付与されたアクセス許可、下の曲線 - 使われたアクセス許可。右の統計は記事の内容に記載されています。

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 つの段階があります。

記事のコンテンツで説明されている図 - セキュリティ侵害シナリオの 4 つの段階。

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

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

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

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

左の列: 未使用 - 行われる API 呼び出しにはまったく必要のない 1 つ以上のアクセス許可が付与されています。右の列: 縮小可能 - 必要なタスクへのアクセスを提供する、より低い特権の代替を持つアクセス許可。

使用されていないアクセス許可は、アプリケーションが目的のタスクに必要のないアクセス許可を受け取ったときに発生します。 たとえば、カレンダー アプリを構築しているとします。 カレンダー アプリが 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、および機密データは安全です。

次のステップ