次の方法で共有

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

  • [アーティクル]

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

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

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

  • リダイレクト URI
  • アクセス トークン (暗黙的なフローに使用されます)
  • 証明書とシークレット
  • アプリケーション ID URI
  • アプリケーションの所有権

リダイレクト URI

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

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

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

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

アクセス トークン (暗黙的なフローに使用されます)

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

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

暗黙的なフローに関連する次のガイダンスを検討してください。

  • 暗黙的なフローが必要かどうかを理解します。 明示的に必要な場合を除き、暗黙的なフローを使用しないでください。
  • 暗黙的なフローを使用してアクセス トークンを受け取るようにアプリケーションが構成されていても、アクティブに使用していない場合は、誤用から保護するために設定をオフにします。
  • 有効な暗黙的フローのシナリオでは、個別のアプリケーションを使用します。

証明書とシークレット

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

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

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

  • 可能な場合は常に証明書の資格情報を使用し、パスワード資格情報 ("シークレット" とも呼ばれます) は使用しないでください。 資格情報としてパスワード シークレットを使用すると便利ですが、可能な場合は、アプリケーションのトークンを取得するための唯一の資格情報の種類として x509 証明書を使用してください。
  • Key Vault とマネージド ID を使用して、アプリケーションの資格情報を管理します。
  • アプリケーションがパブリック クライアント アプリとしてのみ使用されている場合 (ユーザーはパブリック エンドポイントを使用してサインインできます)、アプリケーション オブジェクトに資格情報が指定されていないことを確認します。
  • アプリケーションで使用されている資格情報について、使用状況と有効期限を確認します。 使用されていない資格情報がアプリケーションにあると、セキュリティ侵害が発生する可能性があります。 資格情報を頻繁にロールオーバーし、アプリケーション間で資格情報を共有しないでください。 1 つのアプリケーションに対して多くの資格情報を設定しないでください。
  • 運用環境のパイプラインを監視して、任意の種類の資格情報がコード リポジトリにコミットされないようにします。
  • Credential Scanner は、ソース コードおよびビルド出力内の資格情報 (およびその他の機密コンテンツ) を検出するために使用できる静的分析ツールです。

アプリケーション ID URI

アプリケーションのアプリケーション ID URI プロパティは、Web API を識別するために使用されるグローバルに一意の URI を指定します。 これは、スコープとアクセス トークンのプレフィックスであり、対象ユーザー クレームの値でもあります。また、検証済みの顧客所有ドメインを使用する必要があります。 マルチテナント アプリケーションの場合、値もグローバルで一意にする必要があります。 識別子 URI とも呼ばれます。 Azure portal のアプリケーションの [API の公開] で、アプリケーション ID URI プロパティを定義できます。

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

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

  • API または https URI スキームが推奨されます。 組織内の URI の競合を回避するために、サポートされている形式でプロパティを設定します。 ワイルドカードは使用しないでください。
  • 基幹業務 (LoB) アプリケーションで検証済みドメインを使用します。
  • セキュリティを維持するために、組織内の URI のインベントリを保持します。
  • アプリケーション ID URI を使用し、組織内の WebApi を公開します。 アプリケーションを識別する目的ではアプリケーション ID URI を使用しないでください。代わりに、アプリケーション (クライアント) ID プロパティを使用してください。

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

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

Note

api:// スキームを使用している場合は、"api://" の直後に文字列値を追加します。 たとえば、api://<string> です。 その文字列値には、GUID または任意の文字列を指定できます。 GUID 値を追加する場合は、アプリ ID またはテナント ID と一致する必要があります。 アプリケーション ID URI の値は、テナントに対して一意である必要があります。 アプリケーション ID URI として api://<tenantId> を追加すると、他の誰も他のアプリでその URI を使用できなくなります。 代わりに api://<appId>、または HTTP スキームを使用することをお勧めします。

重要

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

アプリの所有権の構成

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

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

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

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

統合アシスタント

Azure portal の統合アシスタントを使用して、アプリケーションが高品質の基準を満たしていることを確認し、安全な統合を実現できます。 統合アシスタントは、Microsoft ID プラットフォームと統合する際の一般的なミスを回避するのに役立つベスト プラクティスと推奨事項を明確に示します。

統合アシスタントの場所を示すスクリーンショット。

次のステップ