次の方法で共有

ゼロ トラストの原則を使用してアプリケーションのセキュリティを強化する

  • [アーティクル]

開発されたアプリケーションの周囲にセキュリティで保護された安全なネットワーク境界があるとは想定できません。 開発されたほとんどすべてのアプリケーションには、設計上、ネットワーク境界の外部からのアクセスがあります。 アプリケーションは、開発されるとき、セキュリティで保護されて安全であるとは保証できず、またデプロイされた後でもそれは同じです。 アプリケーションのセキュリティを最大限に高めるだけでなく、アプリケーションが侵害された場合に発生する可能性のある損害を最小限に抑えることもアプリケーション開発者の責任です。

さらに、この責任には、アプリケーションがゼロ トラスト セキュリティ要件を満たしていることを期待する顧客およびユーザーの変化するニーズをサポートすることも含まれます。 ゼロ トラスト モデルの原則について学習し、実施項目を採用してください。 この原則を学習して採用することで、より安全で、かつセキュリティが侵害された場合に発生する可能性のある損害を最小限に抑えることができるアプリケーションを開発できます。

ゼロ トラスト モデルでは、暗黙的な信頼ではなく、明示的な検証の文化を規定します。 このモデルは、3 つの主要な基本原則に支えられています。

  • 明示的に検証する
  • 最小限の特権アクセスを使用する
  • 侵害を想定する

ゼロ トラストのベスト プラクティス

これらのベスト プラクティスに従って、Microsoft ID プラットフォームとそのツールを使用して、ゼロ トラスト対応アプリケーションを構築します。

明示的に検証する

Microsoft ID プラットフォームには、リソースにアクセスするユーザーまたはサービスの ID を確認するための認証メカニズムが用意されています。 以下に示すベスト プラクティスを適用して、データまたはリソースへのアクセスが必要なエンティティを "明示的に検証" します。

ベスト プラクティス アプリケーションのセキュリティに対する利点
Microsoft 認証ライブラリ (MSAL) を使用します。 MSAL は、開発者向けの Microsoft 認証ライブラリのセットです。 MSAL を使用すると、ユーザーとアプリケーションを認証でき、数行のコードを使用するだけで企業のリソースにアクセスするためのトークンを取得できます。 MSAL では、最新のプロトコル (OpenID Connect と OAuth 2.0) が使用されます。これにより、アプリケーションでユーザーの資格情報を直接処理する必要がなくなります。 この資格情報の処理により、ID プロバイダーがセキュリティ境界になるため、ユーザーとアプリケーションの両方のセキュリティが大幅に向上します。 また、これらのプロトコルは、ID セキュリティの新しいパラダイム、機会、課題に対応するために継続的に進化します。
必要に応じて、継続的アクセス評価 (CAE) や条件付きアクセス認証コンテキストなどの強化されたセキュリティ拡張機能を導入します。 Microsoft Entra ID で最も使用される拡張機能には、条件付きアクセス、条件付きアクセス認証コンテキスト、CAE が含まれます。 CAE や条件付きアクセス認証コンテキストなどの強化されたセキュリティ機能を使用するアプリケーションは、クレーム チャレンジを処理するようにコーディングする必要があります。 オープン プロトコルにより、追加のクライアント機能を呼び出すために、クレーム チャレンジとクレーム要求を使用できます。 これらの機能は、異常が発生した場合や、ユーザー認証条件が変更された場合などでも、Microsoft Entra ID との対話を続行できます。 これらの拡張機能は、認証のプライマリ コード フローを妨げることなく、アプリケーションにコード化できます。
アプリケーションの種類別に正しい認証フローを使用します。 Web アプリケーションの場合は、機密クライアント フローを常に使用するようにします。 モバイル アプリケーションの場合は、認証にブローカーまたはシステム ブラウザーを使用するようにします。 シークレット (機密クライアント) を保持できる Web アプリケーションのフローは、パブリック クライアント (デスクトップやコンソールのアプリケーションなど) よりも安全性が高いと見なされます。 システム Web ブラウザーを使用してモバイル アプリケーションを認証する場合、セキュリティで保護されたシングル サインオン (SSO) エクスペリエンスを使用すると、アプリケーション保護ポリシーを使用できます。

最小限の特権アクセスを使用する

開発者は、Microsoft ID プラットフォームを使用して、アクセス許可 (スコープ) を付与し、アクセスを許可する前に呼び出し元に適切なアクセス許可が付与されていることを確認します。 必要最小限のアクセス権を付与できるきめ細かなアクセス許可を有効にして、アプリケーションで最小限の特権アクセスを適用します。 最小特権の原則を確実に遵守するために、以下を実施することを検討してください。

  • 要求されたアクセス許可を評価して、ジョブを実行するために絶対的に必要となる最小限の特権が設定されるようにします。 API サーフェス全体へのアクセス権を持つ "キャッチオール" アクセス許可は作成しないでください。
  • API を設計する際は、最小限の特権アクセスを許可する粒度の細かいアクセス許可を与えます。 最初に、機能とデータ アクセスを、スコープとアプリ ロールを使用して制御できるセクションに分割します。 アクセス許可のセマンティクスを変更する方法で、既存のアクセス許可に API を追加しないでください。
  • 読み取り専用アクセス許可を与えます。 Write アクセスには、作成、更新、削除操作の権限が含まれます。 クライアントは、データを読み取るだけのために書き込みアクセスを要求してはなりません。
  • 委任されたアクセス許可とアプリケーションのアクセス許可の両方を与えます。 アプリケーションのアクセス許可を省略すると、自動化、マイクロサービスなどの一般的なシナリオを実現するために、クライアントに対して厳しい要件が発生する可能性があります。
  • 機密データを処理する場合は、"標準" と "フル" のアクセス許可を検討します。 機密プロパティを制限し、"標準" アクセス許可 (たとえば、Resource.Read) を使用してそれらにアクセスできないようにします。 次に、"フル" アクセス許可 (たとえば、機密情報を含むすべての使用可能なプロパティを返す Resource.ReadFull) を実装します。

侵害を想定する

Microsoft ID プラットフォームのアプリケーション登録ポータルは、プラットフォームを認証と関連ニーズのために使用するアプリケーションのプライマリ エントリ ポイントです。 アプリケーションを登録して構成するとき、セキュリティが侵害された場合に発生する可能性がある損害を最小限に抑えるために、以下に示す実施項目に従います。 詳細については、Microsoft Entra アプリケーションの登録に関するセキュリティのベスト プラクティスに関するページを参照してください。

セキュリティ侵害を防止する次のアクションを検討してください。

  • アプリケーションのリダイレクト URI を適切に定義します。 複数のアプリケーションに同じアプリケーション登録を使用しないでください。
  • 所有権のため、およびドメインの乗っ取りの回避のために、アプリケーション登録で使用されるリダイレクト URI を確認します。 アプリケーションをマルチテナントにする目的がない限り、アプリケーションはマルチテナントとして作成しないでください。 |
  • アプリケーションとサービス プリンシパルの所有者が、テナントに登録されているアプリケーションに対して常に定義され管理されていることを確認します。

関連項目