編集

サービス間の通信を制限する

Azure
Microsoft Entra ID
Azure App Service

このシナリオ例では、アプリケーション層とネットワーク層の両方で、2 つの Azure バックエンド サービス間の通信を制限します。 通信は、最小限の特権の原則に従って、それが明示的に許可されているサービス間でのみフローできます。 この例では、Azure App Service を使用してサービスをホストしますが、Azure Functions アプリにも同様の手法を使用できます。

サービス間通信の制限は、慎重な計画、脅威モデリング、セキュリティ開発ライフサイクルに基づく全体的なセキュリティ戦略の一部にすぎません。 全体的なセキュリティ計画には、ビジネス、コンプライアンス、規制、その他の機能以外の要件を組み込む必要があります。

考えられるユース ケース

現在のシナリオで注目しているのはネットワークの制限ですが、多くの組織では、侵害を想定したゼロ トラスト セキュリティ モデルが採用されているため、ネットワーク層の重要性は二次的です。

アーキテクチャ

Diagram showing both network layer and application layer communications restrictions between two Azure App Service backend services.

このアーキテクチャの Visio ファイルをダウンロードします。

データフロー

この図は、サービス A からサービス B への制限された通信を示したものです。アプリケーション層ではトークンベースの承認によってアクセスが制限され、ネットワーク層ではサービス エンドポイントによってアクセスが制限されます。

トークンベースの承認

このトークンベースのクライアントの資格情報フローは、Microsoft Authentication Library (MSAL) のような OpenID Connect (OIDC) 互換ライブラリによってサポートされています。 詳細については、「シナリオ: Web API を呼び出すデーモン アプリケーション」とデーモン シナリオのサンプル アプリケーションを参照してください。

  1. サービス A とサービス B の両方が Microsoft Entra ID に登録されます。 サービス A のクライアント資格情報は、共有シークレットまたは証明書の形式で保持されています。
  2. サービス A は、独自のクライアント資格情報を使用して、サービス B のアクセス トークンを要求できます。
  3. Microsoft Entra ID により、サービス B の対象ユーザーまたは aud クレームにアクセス トークンが提供されます。
  4. OAuth 2.0 ベアラー トークン使用法の仕様に従って、サービス A により、サービス B への要求の HTTP Authorization ヘッダーにトークンが "ベアラー トークン" として挿入されます。
  5. サービス B によりトークンの検証が行われ、aud クレームがサービス B のアプリケーションと一致することが確認されます。

サービス B で次のいずれかの方法を使用することにより、明示的に許可されているクライアント (この場合はサービス A) のみがアクセスできるようになります。

  • トークン appid クレームを検証する。 サービス B では、トークン appid クレームを検証できます。これにより、どの Microsoft Entra 登録済みアプリケーションによってトークンが要求されたかが識別されます。 サービス B により、既知のアクセス制御呼び出し元リストに照らしてクレームが明示的に確認されます。

  • トークン内の roles を調べる。 同様に、サービス B では、受信トークン内の特定の roles クレームを調べて、サービス A に明示的なアクセス許可があることを確認できます。

  • ユーザー割り当てを要求する。 または、サービス B の所有者または管理者は、"ユーザー割り当て" を要求するように Microsoft Entra ID を構成し、サービス B のアプリケーションへの明示的なアクセス許可を持つアプリケーションのみが、サービス B に対するトークンを取得できるようにすることもできます。その後は、ビジネス ロジックで必要な場合を除き、サービス B で特定の roles をチェックする必要はありません。

    サービス B にアクセスするためのユーザー割り当て要件を設定するには:

    1. Microsoft Entra ID で、サービス B のユーザー割り当てを有効にします。
    2. サービス B で、サービス A がアクセス許可を要求できるアプリ ロールを少なくとも 1 つ公開します。 このロールの AllowedMemberTypes には、Application が含まれている必要があります。
    3. 公開されたサービス B のロールに対するサービス A のアプリのアクセス許可を要求します。
      1. サービス A のアプリ登録の [API のアクセス許可] セクションで、 [アクセス許可の追加] を選択し、一覧からサービス B のアプリケーションを選択します。
      2. このバックエンド アプリケーションはサインイン ユーザーなしで実行されるため、 [API アクセス許可の要求] 画面で、[アプリケーションのアクセス許可] を選択します。 公開されているサービス B のロールを選択し、 [アクセス許可の追加] を選択します。
    4. サービス A のアプリケーションのアクセス許可要求に、管理者の同意を付与します。 サービス A のアクセス許可要求に同意できるのは、サービス B の所有者または管理者だけです。

サービス エンドポイント

アーキテクチャの図の下半分には、ネットワーク層でサービス間通信を制限する方法が示されています。

  1. サービス A の Web アプリにより、リージョン VNet 統合を使用して、すべての送信通信が、統合サブネットの IP 範囲内のプライベート IP アドレスを通るようにルーティングされます。
  2. サービス B にはサービス エンドポイントがあり、サービス B の統合サブネット上の Web アプリからの受信通信のみが許可されます。

詳細については、「Azure App Service のアクセス制限を設定する」を参照してください。

Components

このシナリオでは、次の Azure サービスを使用します。

  • Azure App Service によりサービス A とサービス B の両方がホストされており、自動スケーリングと高可用性が有効になります。インフラストラクチャの管理は不要です。
  • Microsoft Entra ID は、クラウドベースの ID およびアクセス管理サービスであり、サービスの認証が行われ、OAuth 2.0 トークンベースの認可が有効にされます。
  • Azure Virtual Network は、Azure 内のプライベート ネットワークの基本的な構成ブロックです。 Azure Virtual Network により、Azure Virtual Machines (VM) などの Azure リソースは、相互に、およびインターネットやオンプレミス ネットワークと、安全に通信できるようになります。
  • Azure サービス エンドポイントにより、Azure バックボーン ネットワーク上の最適化されたルート経由で Azure サービスへの安全な直接接続が提供され、統合サブネットのプライベート ソース IP の範囲からのアクセスのみが許可されます。
  • Microsoft Authentication Library (MSAL) は、OIDC と互換性のあるライブラリであり、サービスでそれを使うことにより、クライアント資格情報フローを使って Microsoft Entra ID からアクセス トークンをフェッチできます。

代替

この例のシナリオにはいくつかの代替手段があります。

マネージド ID

Microsoft Entra ID にアプリケーションとして登録する代わりに、サービス A でマネージド ID を使ってアクセス トークンをフェッチすることができます。 マネージド ID を使用すると、オペレーターはアプリの登録のために資格情報を管理する必要がなくなります。

マネージド ID を使うと、サービス A でトークンをフェッチすることはできますが、Microsoft Entra のアプリ登録は提供されません。 他のサービスでサービス A 自体のアクセス トークンを要求する場合は、サービス A において Microsoft Entra のアプリ登録がやはり必要です。

Azure portal でアプリ ロールにマネージド ID を割り当てることはできません。Azure PowerShell のコマンド ラインを使用する必要があります。 詳細については、「PowerShell を使用してマネージド ID アクセスをアプリケーション ロールに割り当てる」を参照してください。

Azure Functions

App Service ではなく Azure Functions でサービスをホストできます。 リージョン VNet 統合を使用してネットワーク層でアクセスを制限するには、App Service プランまたは Premium プランで Functions アプリをホストする必要があります。 詳細については、「Azure Functions のネットワーク オプション」をご覧ください。

App Service 組み込みの認証と承認

仕様により、このシナリオを使用すると、アプリケーション コードの一部としてトークン検証を実行することにより、承認のコードがビジネス ロジックの残りの部分と併置されます。 App Service 組み込みの認証と承認 (Easy Auth) を使用すると、サービスに要求を送信する前に、トークンの基本的な検証を実行することもできます。 その後、サービスでの承認されていない要求の拒否は、ホスト インフラストラクチャに依存して行われます。

App Service の認証と認可を構成するには、認可動作を [Microsoft Entra ID でのログイン] に設定します。 これを設定すると、トークンが検証され、有効なトークンのみにアクセスが制限されます。

Easy Auth を使用する場合の欠点は、サービスを別の場所に移動すると、認証と承認の保護が失われることです。 App Service の認証と承認は単純なシナリオでは動作しますが、複雑な承認要件には、アプリケーション コード内のロジックを使用する必要があります。

サービス エンドポイントとプライベート エンドポイント

特定のサブネットからの Web アプリへのアクセスを制限できるのはサービス エンドポイントだけなので、このシナリオには、プライベート エンドポイントではなくサービス エンドポイントを使用します。 プライベート エンドポイントでの受信トラフィックのフィルター処理は、ネットワーク セキュリティ グループ (NSG) または App Service のアクセス制限を使用した場合はサポートされません。 ネットワークの通信経路があるサービスはすべて、Web アプリケーションのプライベート エンドポイントと通信できます。 これにより、ネットワーク層でのトラフィックのロックダウンに関するプライベート エンドポイントの有用性が制限されます。

考慮事項

  • App Service のリージョン VNet 統合を使用すると、App Service プランごとに 1 つの統合サブネットが提供されます。 同じプランのすべての Web アプリが同じサブネットと統合され、同じプライベート送信 IP アドレスのセットを共有します。 受信側のサービスで、トラフィックの送信元の Web アプリを区別することはできません。 送信元の Web アプリを特定する必要がある場合は、それぞれが独自の統合サブネットを持つ個別の App Service プランに、Web アプリをデプロイする必要があります。

  • App Service プラン内のすべての worker インスタンスにより、統合サブネット内の独立したプライベート IP アドレスが占有されます。 スケールを計画するには、統合サブネットに、予想されるスケールに対応できる十分な大きさがあることを確認します。

コストの最適化

このシナリオの価格は、特定のインフラストラクチャと要件によって異なります。 Free レベルから Premium レベルまで、ニーズに応じた Microsoft Entra ID を利用できます。 Azure App Service または他のホストのコストは、特定のスケールとセキュリティの要件によって異なります。詳細については、「代替」と「考慮事項」を参照してください。

シナリオのコストを計算するには、Azure 料金計算ツールを参照してください。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

次のステップ