次の方法で共有

Microsoft Entra ID でのアプリケーション プロパティのセキュリティに関するベスト プラクティス

セキュリティは、Microsoft Entra ID にアプリケーションを登録する際の重要な概念であり、組織でのそのビジネス利用における重要な部分です。 アプリケーションの構成ミスは、ダウンタイムや侵害につながる可能性があります。 アプリケーションに追加されるアクセス許可によっては、組織全体に影響が及ぶことがあります。

セキュリティで保護されたアプリケーションは組織にとって不可欠であるため、セキュリティの問題が原因でダウンタイムが発生すると、ビジネス、またはビジネスが依存するいくつかの重要なサービスに影響が及ぶ可能性があります。 したがって、アプリケーションが常に正常で安全な状態に保たれるように時間とリソースを割り当てることが重要です。 コードのセキュリティ脅威モデルの評価と同様に、アプリケーションのセキュリティと正常性の評価を定期的に実施します。 組織のセキュリティに関するより広い観点については、セキュリティ開発ライフサイクル (SDL) を参照してください。

この記事では、次のアプリケーションのプロパティとシナリオに関するセキュリティのベスト プラクティスについて説明します。

  • IDの種類
  • 資格情報
  • リダイレクト URI
  • 暗黙的なフロー構成
  • アプリケーション ID URI (識別子 URI とも呼ばれます)
  • アクセス トークンのバージョン
  • アプリケーション インスタンスのロック
  • アプリケーションの所有権

IDの種類

Microsoft Entra アプリケーションのセキュリティのベスト プラクティス (アプリの登録またはアプリ オブジェクトとも呼ばれます) について学習する場合があります。 ただし、Entra で保護されたリソース (Azure リソースのマネージド ID と呼ばれる) にアクセスするために使用できる別 の ID の種類があります。

Azure マネージド ID は既定でセキュリティで保護されており、継続的なメンテナンスやオーバーヘッドはほとんど必要ありません。 次のすべてが当てはまる場合は、アプリ ID に Microsoft Entra アプリケーションの代わりにマネージド ID を使用することを検討してください。

  • サービスは Azure クラウドで実行されます
  • アプリでユーザーをサインインさせる必要はありません
  • アプリはトークン フロー内のリソースとして機能する必要はありません (Web API ではありません)
  • アプリは複数のテナントで動作する必要はありません

注

マネージド ID を使用して、 Microsoft Graph を含む Azure 外部のリソースにアクセスできます。

この記事の残りの部分では、Entra アプリ登録のプロパティのセキュリティのベスト プラクティスについて説明します。

資格情報 (証明書とシークレットを含む)

資格情報は、機密クライアントとして使用されるアプリケーションの重要な部分です。 Azure portal のアプリケーション の [証明書とシークレット ] ページで、資格情報を追加または削除できます。

[証明書とシークレット] の場所を示すスクリーンショット。

証明書とシークレットに関連する次のガイダンスを検討してください。

  • 可能な限り 、マネージド ID を 資格情報として使用します。 マネージド ID はどちらも最も安全なオプションであり、継続的な資格情報管理を必要としないため、これを強くお勧めします。 このガイダンスに従って、資格情報としてマネージド ID を構成します。 ただし、このオプションは、アプリが使用されているサービスが Azure で実行されている場合にのみ可能です。
  • アプリが使用されているサービスが Azure で実行されておらず、資格情報の自動管理を提供する別のプラットフォームで実行される場合は、 そのプラットフォームの ID を資格情報として使用することを検討してください。 たとえば、 GitHub アクション ワークフローを資格情報として構成できるため、GitHub アクション パイプラインの資格情報を管理してセキュリティで保護する必要がなくなります。 この方法には注意を払い、信頼できるプラットフォームからのフェデレーション資格情報のみを構成してください。 アプリは、資格情報として構成した ID プラットフォームと同じくらい安全です。
  • マネージド ID またはその他のセキュリティで保護された外部 ID プロバイダーを使用できない場合は、 証明書の資格情報を使用します。 パスワード資格情報 (シークレットとも呼ばれます) は使用しないでください。 パスワード シークレットを資格情報として使用すると便利ですが、パスワード資格情報は誤って管理され、簡単に侵害される可能性があります。
  • マネージド ID の代わりに証明書を使用する必要がある場合は、その証明書を Azure Key Vault などのセキュリティで保護されたキー コンテナーに格納します。
  • マネージド ID の代わりに証明書を使用する必要がある場合は、自己署名証明書ではなく、信頼された証明機関 (CA) の証明書を使用します。 信頼された発行者からの証明書を適用するようにポリシーを構成します。 ただし、信頼された CA を使用できない場合でも、自己署名証明書はパスワードよりも優先されます。
  • アプリケーション管理ポリシーを構成して、シークレットの有効期間を制限したり、使用を完全にブロックしたりして、シークレットの使用を管理します。
  • アプリケーションがパブリック クライアントまたはインストール済みクライアント (エンド ユーザー コンピューターにインストールされているモバイル アプリやデスクトップ アプリなど) としてのみ使用される場合は、アプリケーション オブジェクトに資格情報が指定されていないことを確認します。
  • アプリケーションで使用されている資格情報について、使用状況と有効期限を確認します。 使用されていない資格情報がアプリケーションにあると、セキュリティ侵害が発生する可能性があります。 資格情報を頻繁にロールオーバーし、アプリケーション間で資格情報を共有しないでください。 1 つのアプリケーションに対して多くの資格情報を設定しないでください。
  • 運用環境のパイプラインを監視して、任意の種類の資格情報がコード リポジトリにコミットされないようにします。 Credential Scanner は、ソース コードおよびビルド出力内の資格情報 (およびその他の機密コンテンツ) を検出するために使用できる静的分析ツールです。

リダイレクト URI

アプリケーションのリダイレクト URI を最新の状態に保つことが重要です。 Azure portal のアプリケーションの [認証] で、アプリケーションのプラットフォームを選択する必要があります。その後、[リダイレクト URI] プロパティを定義できます。

リダイレクト URI プロパティの場所を示すスクリーンショット。

リダイレクト URI に関する次のガイダンスを検討してください。

  • すべての URI の所有権を保持します。 いずれかのリダイレクト URI の所有権が失効すると、アプリケーションの侵害につながる可能性があります。
  • すべての DNS レコードが定期的に更新され、変更の有無が監視されていることを確認してください。
  • ワルドカード応答 URL や、http または URN などのセキュリティ保護されていない URI スキームは使用しないでください。
  • リストを小さく保ちます。 不要な URI をすべてトリミングします。 可能な場合は、URL を Http から Https に更新します。

暗黙的なフロー構成

暗黙的なフローを必要とするシナリオで、承認コード フローを使用して、暗黙的なフローの誤用に関連する侵害のリスクを軽減できるようになりました。 Azure portal のアプリケーションの [認証] で、アプリケーションのプラットフォームを選択する必要があります。その後、[アクセス トークン (暗黙的なフローに使用)] プロパティを設定できます。

暗黙的なフロー プロパティがある場所を示すスクリーンショット。

アプリケーション ID URI (識別子 URI とも呼ばれます)

アプリケーションのアプリケーション ID URI プロパティは、Web API を識別するために使用されるグローバルに一意の URI を指定します。 これは、Microsoft Entra への要求のスコープ値のプレフィックスです。 これは、v1.0 アクセス トークンの対象ユーザー (aud) 要求の値でもあります。 マルチテナント アプリケーションの場合、値はグローバルに一意である必要もあります。 識別子 URI とも呼ばれます。 Azure portal のアプリケーションの [API の公開] で、アプリケーション ID URI プロパティを定義できます。

アプリケーション ID URI の場所を示すスクリーンショット。

アプリケーション ID URI を定義するためのベスト プラクティスは、アプリが v1.0 または v2.0 のアクセス トークンを発行するかどうかによって変わります。 アプリが v1.0 アクセス トークンを発行されているかどうかわからない場合は、アプリ マニフェストの requestedAccessTokenVersion を確認。 null または 1 の値は、アプリが v1.0 アクセス トークンを受け取っていることを示します。 2 の値は、アプリが v2.0 アクセス トークンを受け取っていることを示します。

v1.0 アクセス トークンが発行されたアプリケーションでは、既定の URI のみを使用する必要があります。 既定の URI は api://<appId> と api://<tenantId>/<appId>です。 - nonDefaultUriAdditionの制限を構成して、組織内のアプリケーションに対する今後の更新に対してこのベスト プラクティスを適用します。

v2.0 アクセス トークンが発行されるアプリケーションの場合は、アプリ ID URI を定義するときに次のガイドラインを使用します。

  • api または https URI スキームをお勧めします。 組織内の URI の競合を回避するために、サポートされている形式でプロパティを設定します。 ワイルドカードは使用しないでください。
  • 組織の検証済みドメインを使用します。
  • セキュリティを維持するために、組織内の URI のインベントリを保持します。

次の API および HTTP スキームベースのアプリケーション ID URI 形式がサポートされます。 表の後の一覧の説明に従って、プレースホルダーの値を置き換えてください。

サポートされるアプリケーション ID
URI 形式		 アプリ ID URI の例
api://<appId> api://aaaabbbb-0000-cccc-1111-dddd2222eeee
api://<tenantId>/<appId> api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<string> api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://<string>/<appId> api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://<tenantInitialDomain>.onmicrosoft.com/<string> https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string> https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain> https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string> https://product.contoso.com/productsapi
api://<string>.<verifiedCustomDomainOrInitialDomain>/<string> api://contoso.com/productsapi
  • <appId> - アプリケーション オブジェクトのアプリケーション ID (appId) プロパティ。
  • <string> - ホストまたは API パスのセグメントの文字列値。
  • <tenantId> - Azure 内のテナントを表すために Azure によって生成された GUID。
  • <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com。<tenantInitialDomain> は、テナント作成時にテナント作成者が指定した初期ドメイン名です。
  • <verifiedCustomDomain> - Microsoft Entra テナント用に構成された検証済みのカスタム ドメイン。

注

api:// スキームを使用している場合は、"api://" の直後に文字列値を追加します。 たとえば、api://<string> です。 その文字列値には、GUID または任意の文字列を指定できます。 GUID 値を追加する場合は、アプリ ID またはテナント ID と一致する必要があります。 文字列値を使用する場合は、テナントの検証済みのカスタム ドメインまたは初期ドメインを使用する必要があります。 api://<appId> を使用することをお勧めします。

重要

アプリケーション ID URI の値は、スラッシュ "/" 文字で終わる必要があります。

重要

アプリケーション ID URI の値は、テナント内で一意である必要があります。

アクセス トークンのバージョン

このセクションは、リソース アプリケーション (アクセス トークンの対象ユーザーとして機能するアプリケーション) にのみ適用されます。 通常、リソース アプリケーションは Web API です。 アプリケーションがクライアントとしてのみ機能する場合 (つまり、Microsoft Graph などのリソースに送信するトークンを取得します)、このセクションは適用されません。

カスタム 識別子 URI を 構成したリソース アプリケーションでは、v2.0 アクセス トークン形式を使用する必要があります。 アプリで v2.0 アクセス トークンを使用する必要があるかどうかを確認するには、アプリのアプリidentifierUrisの プロパティを確認します。

マニフェスト エディターでの識別子 URI 変更エクスペリエンスのスクリーンショット。

api://{appId}またはapi://{tenantId}/{appId}の形式で構成されていない値がある場合、アプリは v2.0 アクセス トークンを使用する必要があります。

v2.0 アクセス トークンにアップグレードするには、まずアプリが v2.0 トークン要求を処理できることを確認します。 次に、マニフェスト エディターを使用して、アプリケーションが発行するアクセス トークンのバージョンを更新します。

更新トークンのバージョン エクスペリエンスのスクリーンショット。

v2.0 トークンを使用するようにアプリケーション構成が更新されたら、アプリケーションの対象ユーザー検証ロジックがそのappId受け入れるように変更されていることを確認します。

アプリケーション インスタンスプロパティロック

アプリケーションにテナントにプロビジョニングされたサービス プリンシパルがある場合、そのサービス プリンシパルはテナント管理者がカスタマイズできます。これは、そのテナントがアプリケーションのホーム テナントか外部テナントかに関係なく当てはまります。 これらのカスタマイズ機能を使用すると、アプリ所有者が予期していなかった変更を行うことができるため、セキュリティ 上のリスクが生じる可能性があります。 たとえば、資格情報は通常アプリの開発者や所有者が管理すべきですが、サービス プリンシパルに追加することもできます。

このリスクを軽減するには、アプリケーションで アプリ インスタンスロックを構成する必要があります。 アプリ インスタンスのロックを構成する場合は、使用できるすべての機密性の高いプロパティを常にロックします。 このプロパティの構成は、マルチテナント アプリケーション (複数のテナントまたは組織で使用されるアプリケーション) にとって特に重要ですが、すべてのアプリケーションで設定でき、設定する必要があります。

権限

保護されたリソースまたは API にアクセスするためのアクセス許可をアプリケーションに付与する必要がある場合があります。 アクセス許可を要求するときは、常に次のことを確認してください。

  • 最小限の特権の原則に従います。 アプリが実行する必要があるアクションを実行するために必要な最小限のアクセス許可を付与するアクセス許可のみを要求します。 Microsoft Graph を呼び出す場合は、 API ドキュメント を使用して、特定の API 呼び出しに対する最も制限の少ないアクセス許可を特定します。 アプリのアクセス許可を定期的に確認して、特権の低いオプションが使用可能かどうかを確認します。 アプリにアクセス許可が不要になった場合は、削除します。
  • 可能な限り、アプリ専用アクセスではなく、委任されたアクセスを使用します。
  • アクセス許可と同意に関するドキュメントを確認して、アクセス許可の基礎を理解していることを確認します。

アプリの所有権の構成

所有者は、登録されているアプリケーションのすべての側面を管理できます。 組織内のすべてのアプリケーションの所有権を定期的に確認することが重要です。 詳細については、「Microsoft Entra のアクセス レビュー」をご覧ください。 Azure portal のアプリケーションの [所有者] で、アプリケーションの所有者を管理できます。

アプリケーションの所有者が管理される場所を示すスクリーンショット。

アプリケーションの所有者の指定に関連する次のガイダンスを検討してください。

  • アプリケーションの所有権が、組織内のユーザーの最小セットに保たれている必要があります。
  • 管理者は、所有者リストを数か月ごとに 1 回確認し、所有者がまだ組織に属しており、アプリケーションを引き続き所有する必要があることを確認する必要があります。

Entra の推奨事項を確認する

Microsoft Entra の推奨事項機能は、テナントの状態を監視するのに役立ちます。そうする必要はありません。 これらのレコメンデーションは、テナントが安全で正常な状態であることを確認するのに役立ち、また、Microsoft Entra ID で使用できる機能の価値を最大限に高めることができます。 アプリのエコシステムを正常な状態に保つために、アプリのプロパティまたはアプリ構成に関連するアクティブな Microsoft Entra の推奨事項を定期的に確認します。

  • Last updated on