次の方法で共有


最小限の特権の原則でセキュリティを高める

最小限の特権の情報セキュリティ原則では、ジョブの実行に必要なデータと操作へのアクセス権のみをユーザーとアプリケーションに付与する必要があることをアサートします。 ここでのガイダンスに従って、アプリケーションの攻撃面を縮小し、Microsoft ID プラットフォーム統合アプリケーションでセキュリティ侵害が発生した場合には、その影響 (影響範囲) を軽減します。

推奨事項の一覧

  • 未使用のアクセス許可と再割り当て可能なアクセス許可を取り消して、過剰な特権が与えられているアプリケーションを防止する。
  • ID プラットフォームの同意フレームワークを使用して、保護されたデータへのアクセスを求めるアプリケーションからの要求に対して人間の同意が必要になるようにする。
  • 開発のすべての段階で、最低限の特権に留意してアプリケーションを構築する。
  • デプロイされたアプリケーションを定期的に監査して、過剰な特権を持つものを特定する。

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

未使用または再割り当て可能なアクセス許可が付与されているアプリケーションは、過剰な特権が与えられていると見なされます。 未使用および再割り当て可能なアクセス許可により、アプリケーションまたはそのユーザーがジョブの実行に必要としないデータまたは操作に対して、未承認または意図されていないアクセスが行われる可能性があります。 適切なアクセス許可のみを付与することで、未使用および再割り当て可能なアクセス許可によって発生するセキュリティ リスクを回避します。 適切なアクセス許可は、アプリケーションまたはユーザーが必要なタスクを実行するために必要になる最小限のアクセス権を持つものです。

未使用のアクセス許可

未使用のアクセス許可とは、アプリケーションに付与されているが、そのアクセス許可によって公開される API や操作が、意図どおりに使用されたときにそのアプリケーションによって呼び出されることがないアクセス許可のことです。

  • : アプリケーションは、Files.Read アクセス許可を使用して Microsoft Graph API を呼び出して、サインインしたユーザーの OneDrive に保存されたファイルの一覧を表示します。 ただし、このアプリケーションは、Calendars.Read アクセス許可も付与されていますが、カレンダー機能は提供しておらず、Calendars API は呼び出しません。

  • セキュリティ リスク: 未使用のアクセス許可では、水平方向の特権エスカレーションのセキュリティ リスクが発生します。 アプリケーションのセキュリティの脆弱性を悪用するエンティティは、未使用のアクセス許可を使用して、意図どおりに使用されれば通常はアプリケーションでサポートも許可もされていない API または操作へのアクセスを取得できます。

  • 軽減策: アプリケーションで行われた API 呼び出しで使用されていないアクセス許可をすべて削除します。

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

再割り当て可能なアクセス許可とは、必要なタスクを実行するために必要とするアクセス権をアプリケーションとそのユーザーに提供し続ける特権を低めた対応物を持つアクセス許可です。

  • : アプリケーションでは、Microsoft Graph API を呼び出して、サインインしたユーザーのプロファイル情報を表示しますが、プロファイルの編集はサポートしていません。 しかし、アプリケーションには User.ReadWrite.All アクセス許可が付与されています。 制限の厳しい User.Read.All アクセス許可によってユーザー プロファイル データへの十分な読み取り専用アクセス権が付与されるので、User.ReadWrite.All アクセス許可はここでは再割り当て可能と見なされます。

  • セキュリティ リスク: 再割り当て可能なアクセス許可では、垂直方向の特権エスカレーションのセキュリティ リスクが発生します。 アプリケーションのセキュリティの脆弱性を悪用するエンティティは、再割り当て可能なアクセス許可を使用して、データに不正アクセスしたり、通常ならばそのエンティティのロールでは許可されない操作を実行したりできます。

  • 軽減策: アプリケーションの再割り当て可能なアクセス許可のそれぞれを、アプリケーションの目的の機能を引き続き可能にする特権の最も少ないアクセス許可に置き換えます。

ほとんどのアプリケーションでは、保護されたデータへのアクセスが必要であり、そのデータの所有者は、そのアクセスに同意する必要があります。 同意は、Microsoft Entra テナントのすべてのユーザーに代わって同意できるテナント管理者による方法や、アクセス権を付与できるアプリケーション ユーザー自身による方法など、複数の方法で付与できます。

デバイスで実行されるアプリケーションでは、保護されたデータへのアクセスを要求するたびに、その保護されたデータへのアクセスを許可する前にユーザーの同意を求める必要があります。 アプリケーションが処理を進めるには、まずユーザーが、要求されたアクセス許可に対する同意を与える (または拒否する) 必要があります。

アプリケーション開発中の最小限の特権

アプリケーションおよびそれがアクセスするユーザー データのセキュリティは、開発者の責任です。

アプリケーションの開発中に以下のガイドラインに従うと、過剰な特権が付与されないようにすることができます。

  • アプリケーションで行う必要がある API 呼び出しに必要なアクセス許可について完全に理解する。
  • Graph Explorer を使用して、アプリケーションで行う必要がある各 API 呼び出しの最小特権のアクセス許可について理解する。
  • 最小から最大特権までの対応するアクセス許可を見つける。
  • アプリケーションが重複するアクセス許可を持つ API 呼び出しを行う場合に、重複するアクセス許可のセットを削除する。
  • アクセス許可の一覧で最小特権のアクセス許可を選択することで、最小特権のアクセス許可セットのみをアプリケーションに適用する。

デプロイされたアプリケーションの最小限の特権

組織では多くの場合、通常の業務が影響されないように、実行中のアプリケーションを変更したくありません。 ただし、組織では、過剰な特権アクセスを使用してセキュリティ インシデントが発生したり、より深刻になったりするというリスクを軽減するために、アプリケーションのスケジュールされた更新を行う価値があると考える必要があります。

以下のような標準的な慣行を組織で行うことで、デプロイされたアプリケーションに過剰な特権が付与されず、時間が経過しても過剰な特権が与えられることがなくなります。

  • アプリケーションから行われている API 呼び出しを評価する。
  • Graph Explorer および Microsoft Graph ドキュメントを使用して、必須および最小特権アクセス許可について確認する。
  • ユーザーまたはアプリケーションに付与される特権を監査する。
  • 最小特権のアクセス許可セットでアプリケーションを更新する。
  • アクセス許可を定期的に見直して、すべての承認されたアクセス許可が引き続き関連していることを確認する。

次のステップ