Azure PaaS サービスへのプライベート アクセス

この記事では、パブリック インターネットではなく、プライベート ネットワーク接続経由でサービスとしてのプラットフォーム (PaaS) リソースAzure接続する方法について説明します。 セキュリティと接続の要件に合ったアプローチを選択できるように、サービス エンドポイント、プライベート エンドポイント、Private Linkの違いについて学習します。

この記事の内容

プライベート PaaS アクセスは、Azure仮想ネットワークと、Azure Storage、Azure SQL Database、Azure Key Vaultなどの PaaS サービスAzure間のデータ パスからパブリック インターネットを削除します。 この記事では、接続オプション、そのトレードオフ、および各ワークロードに使用する方法を決定する方法について説明します。

Note

プライベート エンドポイントでは、サービス FQDN をプライベート IP アドレスに解決するために DNS 統合が必要です。 この記事では、DNS の要件をインラインで説明しますが、ハイブリッド転送、Azure DNS プライベート リゾルバー、DNS セキュリティなど、完全な DNS アーキテクチャについては、DNS セキュリティとプライベート名解決に関する記事を参照してください。

この記事が必要なユーザー

これらの条件の 1 つ以上が該当する場合は、この記事をお読みください。

  • ワークロードは、パブリック エンドポイントではなく、プライベート ネットワーク パス経由Azure PaaS サービスに到達する必要があります。
  • セキュリティ、コスト、管理容易性に基づいて、サービス エンドポイントとプライベート エンドポイントを決定する必要があります。
  • データ流出リスクを軽減するには、特定の PaaS リソースへのアクセスを制限する必要があります。
  • プライベート PaaS 接続の DNS、サブネット容量、またはハイブリッド到達可能性を計画する必要があります。

Tip

シナリオパスに従っていますか? カスタマイズされたガイダンスについては、ページの上部にあるシナリオを選択してください。 以下の主要なガイダンスは、すべての読者に適用されます。

リフトアンドシフトフォーカス:移行されたアプリの一部で既に PaaS サービスAzure使用していない限り、この記事はスキップしてください。 ほとんどのリフト アンド シフト ワークロードは IaaS (VM、マネージド ディスク、標準ネットワーク) にとどまり、初期移行フェーズではPrivate Link必要ありません。 後で個々のワークロード コンポーネントに PaaS サービスの導入を開始するときに、この記事に戻ります。

次の場合は、この記事をお読みください。

  • Azure PaaS サービス (Azure SQL DatabaseやAzure Storageなど) を既に使用しているワークロードを移行しました。
  • リフトアンドシフト後の段階的なモダン化の一環として、Private Linkの使用を開始するタイミングを理解したいと考えています。
  • 将来のプライベート エンドポイント導入のためにサブネット容量を計画する必要があります。

モダナイゼーションの重点: 各スポーク VNet 内の Private Link サブネットは不可欠です。 AKS、App Service Environment (ASE)、およびマネージド データベース ワークロードには、コンプライアンス要件を満たし、パブリック インターネット経由でのデータ流出を防ぐために、プライベート PaaS 接続が必要です。

次の場合は、この記事をお読みください。

  • 機密性の高いデータまたは規制対象のデータAzure PaaS サービスに格納し、プライベート ネットワーク パスへのアクセスを制限する必要があります。
  • アプリ チームで使用するために、各スポーク VNet に専用のPrivate Link サブネットを作成する必要があります。
  • 特定のリソース インスタンスへの PaaS 接続スコープを確保して、データ流出を防ぐ必要があります。
  • Vpn または ExpressRoute 経由でオンプレミス ネットワークから PaaS サービスに到達できる必要がある運用ワークロードを設計しています。
  • サービス エンドポイントとプライベート エンドポイントの間のコスト、DNS、およびセキュリティのトレードオフを理解する必要があります。

クラウド間のフォーカス:この記事は、ターゲット アーキテクチャにプライベート エンドポイントを持つ PaaS Azureが既に含まれている場合を除き、クラウド間のトランジットと接続を確立した後に関連します。 PaaS アクセス パスをセキュリティで保護する準備ができたら、最適化中にこの記事に戻ります。

次の場合は、この記事をお読みください。

  • 移行プロセス中にプライベート エンドポイントのサポートでAzure Migrateを使用しています。
  • 移行後のターゲット アーキテクチャの一部として、Azure PaaS サービスの導入を計画します。
  • プライベート エンドポイントをクロスクラウド設計と統合する前に、プライベート エンドポイントのしくみを理解する必要があります。

Azureサービスと機能

次の表では、Azureのプライベート PaaS 接続で使用できるサービスと機能について説明します。

サービスまたは機能 提供される内容 いつ使用するか
パブリック エンドポイント (既定) 各 Azure PaaS サービスのパブリックな完全修飾ドメイン名（FQDN）を使用して、インターネット経由でアクセスします。 追加の構成は必要ありません。 開発/テスト環境のみ。 機密データを含む運用環境のワークロードには推奨されません。
サービス エンドポイント 仮想ネットワーク ID を Azure PaaS サービスに拡張します。 トラフィックはMicrosoftバックボーンに残ります。 PaaS サービスは、VNet をトラフィック ソースと見なします。 プライベート IP アドレスは作成しません。 流出リスクが低い。 Private Linkよりもセットアップが簡単です。 特定のサービスPrivate Link使用できない場合に便利です。 フリー。
プライベート エンドポイント/Azure Private Link 仮想ネットワーク内に、特定の PaaS リソース インスタンスにマップされるプライベート IP アドレスを持つネットワーク インターフェイスを作成します。 トラフィックはMicrosoftバックボーンにとどまり、パブリック インターネットを経由することはありません。 DNS 統合が必要です。 プロダクションワークロード。 機密データ。 法令順守。 データ流出防止。 新しい設計では、サービス エンドポイントよりも優先されます。
Private Link サービス 他の仮想ネットワークまたはMicrosoft Entra テナント内のコンシューマーに独自のサービスをプライベートに公開します。 コンシューマーは、VNet ピアリングを必要とせずに、サービスに到達するために独自の VNet にプライベート エンドポイントを作成します。 ホスト仮想ネットワークへのネットワーク レベルのアクセス権を持つべきではないコンシューマーにサービスを公開する ISV または内部プラットフォーム チーム。
VNet 統合 (App Service、Functions) App Service またはAzure Functionsが仮想ネットワーク経由で送信トラフィックをルーティングできるようにします。 送信専用: 受信プライベート接続を提供しません。 App Service またはAzure Functionsが、プライベート エンドポイントを介してデータベースや内部 API などの VNet プライベート リソースに到達する必要がある場合。

選択する方法

パブリック エンドポイント、バックボーン経由のサービス エンドポイント、プライベート IP を使用したプライベート エンドポイントの 3 つの PaaS アクセス方法を比較した図。

このセクションのデシジョン テーブルを使用して、ワークロードに適した接続方法を選択します。

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

次の表は、PaaS アクセスをプライベート ネットワーク パスに制限するための最も一般的な 2 つの方法を比較しています。

要因 サービス エンドポイント プライベート エンドポイント
トラフィック パス Microsoftバックボーン。 宛先は引き続きパブリック IP アドレスを使用します。 Microsoftバックボーン。 宛先では、VNet 内のプライベート IP アドレスが使用されます。
VNet のプライベート IP No. ソース IP はプライベート (VNet アドレス) になりますが、サービスはそのパブリック IP に解決されます。 Yes. サブネットからのプライベート IP を持つネットワーク インターフェイスは、特定のリソースにマップされます。
DNS の変更が必要 No. DNS 解決は変更されません。 Yes. サービス FQDN がプライベート IP に解決されるように、プライベート DNS ゾーンが必要です。
データ流出防止 制限付き。 VNet レベルでサービスの種類のすべてのインスタンス (たとえば、すべてのAzure Storage アカウント) に適用されます。 強い。 アクセスのスコープは、特定のリソース インスタンスです。 そのエンドポイントを介して到達できるのは、マップされたリソースだけです。
オンプレミス アクセス オンプレミス ネットワークから到達できません。 回避策: パブリック IP アドレスまたは NAT IP アドレスを Azure サービスの IP ファイアウォール規則に追加します。 エンドポイントにルーティング可能なプライベート IP アドレスがあるため、VPN または ExpressRoute 経由でオンプレミスから到達可能。
Cost フリー。 追加料金はかかりません。 エンドポイントごとの時間単位の料金とデータ処理料金。

どの方法を使用するか

シナリオ 推奨される方法 なぜでしょうか
開発/テスト、データの感度が低い サービス ファイアウォールを使用するパブリック エンドポイント 最も簡単なセットアップ。 IP 許可リストによるアクセスを制限します。 追加コストや DNS の変更はありません。
単純な VNet 制限、流出リスクが低い サービス エンドポイント フリー。 すばやく有効にします。 リソース レベルのアクセス スコープが必要ない場合に適しています。
運用環境のワークロード、機密データ、コンプライアンス プライベート エンドポイント 最強のデータ持ち出し防止。 オンプレミスから動作します。 接続されている任意のネットワークからの DNS ベースの解決をサポートします。
独自のサービスを他のテナントにプライベートに発行する Private Link サービス コンシューマーは、VNet にプライベート エンドポイントを作成します。 VNet ピアリングは必要ありません。 承認ワークフローと可視性コントロールをサポートします。
App Service または Functions が VNet リソースに到達する必要がある VNet 統合 外向き通信のみ。 Microsoft.Web/serverFarmsにサブネットの委任が必要です。 プライベート エンドポイントと組み合わせて、PaaS サービスへのセキュリティで保護されたデータ アクセスを実現します。

Azure Front Door Premium では、プライベート接続経由で Front Door をバックエンド サービス (App Service、Storage、または内部ロード バランサー) に接続するために使用する、Private Linkオリジンがサポートされます。 Front Door と配信元の間のトラフィックは Microsoft バックボーンに残り、配信元のパブリック アクセスを完全にオフにすることができます。 このパターンは、Azure ネットワーク サービス全体のPrivate Linkの最も広く文書化された統合です。

Private Link オリジンで Front Door Premium を使用する必要があるのは、次のような場合です:

  • Web アプリケーション ファイアウォール (WAF) 保護によるグローバル負荷分散。
  • オリジンサーバーを公開インターネットに公開せずに実現するプライベート接続。
  • プライベート パス経由のバックエンド トラフィックによる一元的な TLS 終了。

アウトバウンド アクセスのための VNet 統合

VNet 統合では、受信プライベート接続は提供されません。 これにより、App Service またはAzure Functionsは、仮想ネットワーク経由で発信呼び出しをルーティングできます。 つまり、アプリはプライベート エンドポイントの背後にあるリソースにアクセスしたり、VNet プライベート サービスにアクセスしたりできます。 VNet 統合には、 Microsoft.Web/serverFarmsに委任された専用サブネットが必要です。

アプリケーションで次の作業が必要な場合に、VNet 統合とプライベート エンドポイントを組み合わせます。

  • プライベート IP を介してAzure SQL DatabaseまたはAzure Storageを呼び出します。
  • スポーク仮想ネットワークにデプロイされた内部 API またはサービスにアクセスします。
  • 検査のために、ネットワーク仮想アプライアンス (NVA) を介して送信トラフィックをルーティングします。

設計上の考慮事項

ほとんどのリフト アンド シフト プロジェクトでは、Private Link導入が後のフェーズに延期されます。 VM の移行と基本的な接続の確立が優先されます。 次の場合Private Link検討してください。

  • 個々のワークロード コンポーネントでは、PaaS が既に使用されています。リフトされたアプリケーションがAzure SQL DatabaseまたはAzure Storageに接続する場合は、その特定のサービスのプライベート エンドポイントを追加します。 すべての PaaS アクセスを一度に変換する必要はありません。
  • コンプライアンスでは、プライベート接続が義務付けられています。 規制対象のワークロードの中には、1 日目からのプライベート データ パスが必要なものもあります。 この場合は、移行時ではなく、移行中にプライベート エンドポイントを作成します。
  • 今すぐサブネット容量を計画する:Private Link延期した場合でも、将来のプライベート エンドポイント用に各スポークに /27 または /28 サブネットを予約します。 後でサブネット領域をリフォームすることは、事前に予約するよりも困難です。

ほとんどのリフト アンド シフト移行では、詳細なPrivate Link実装をスキップし、PaaS の導入が開始されたときにこの記事に戻ります。

各スポーク VNet に専用のPrivate Link サブネットを作成します。 アプリ チームは、このサブネットを使用して、アプリケーションが使用する PaaS サービスのプライベート エンドポイントを作成します。

  • スポークあたりの専用Private Link サブネット: スポーク ワークロードに必要な PaaS サービスの数に基づいて各サブネットのサイズを設定します (プライベート エンドポイントごとに 1 つの IP)。 /27 (32 個のアドレス) では、Azureが 5 個のアドレスを予約した後、最大 27 個のプライベート エンドポイントがサポートされます。
  • アプリ管理者は PaaS 接続を決定します。 IT チームは、サブネットと DNS インフラストラクチャを提供します。 アプリ チームは、アプリケーションの要件に基づいて、特定の PaaS リソース (Azure SQL、Key Vault、ストレージ) のプライベート エンドポイントを作成します。
  • ハブで DNS ゾーンを一元化する: プライベート DNS ゾーン (たとえば privatelink.database.windows.net) は接続サブスクリプションに配置され、すべてのスポーク VNet にリンクされます。 このアプローチにより、一貫性のある名前解決が保証され、スプリット ブレイン DNS が回避されます。
  • PaaS リソースのパブリック アクセスを無効にする: プライベート エンドポイントを作成した後、ターゲット PaaS リソースのパブリック ネットワーク アクセスをオフにします。 それ以外の場合でも、トラフィックはインターネット経由でサービスに到達し、プライベート接続の目的を破ることができます。
  • VNet 統合と組み合わせる:App Service とAzure Functionsは、VNet 統合を使用してスポーク VNet 経由で発信呼び出しをルーティングし、同じ VNet またはピアリングされた VNet 内のプライベート エンドポイントを介して PaaS サービスに到達します。

Azure Migrate アプライアンスでは、移行コントロール プレーントラフィックをセキュリティで保護するプライベート エンドポイント接続がサポートされています。 そのうえで、Private Link の計画は移行後の最適化に先送りします。

  • プライベート エンドポイントを使用したAzure Migrate: 移行プロセス中、Azure Migrate アプライアンスはプライベート エンドポイントを使用してAzure Migrate プロジェクトと通信できます。 このアプローチでは、移行制御トラフィックをパブリック インターネットから切り離した状態に保てます。
  • 広範なPrivate Link導入を延期する: 最初にクラウド間のトランジット接続に焦点を当てます。 Azureでワークロードを移行して安定化したら、個別の最適化パスとして PaaS サービスのプライベート エンドポイントを計画します。
  • サブネット領域を予約する:ここでPrivate Linkスキップした場合でも、今後のプライベート エンドポイント用に各スポークのサブネットを予約します。 後で PaaS サービスAzure採用するクラウド間ワークロードには、この容量が必要です。

Prerequisites

プライベート PaaS アクセスを実装する前に、次のリソースと知識があることを確認します。

  • 少なくとも 1 つのサブネットを持つデプロイされた仮想ネットワーク。 プライベート エンドポイントには、使用可能な IP アドレスを持つサブネットが必要です。 仮想ネットワークの設計については、「 仮想ネットワークとサブネット」を参照してください。
  • プライベートに接続するための Azure PaaS サービス。 サービスは、サービス エンドポイントまたはPrivate Linkをサポートする必要があります。 サービスのAzure Private Link可用性に関するドキュメントを確認します。
  • DNS インフラストラクチャの理解。 プライベート エンドポイントにはプライベート DNS ゾーンが必要です。 カスタム DNS サーバーを使用する場合は、Azure DNS (168.63.129.16) を指す条件付きフォワーダーが必要です。 DNS 設計パターンについては、 関連リソースのプライベート エンドポイントの DNS 統合に関する記事を参照してください。
  • IP アドレスの計画。 各プライベート エンドポイントは、サブネットから 1 つのプライベート IP アドレスを使用します。 それに応じてサブネット のサイズを計画します。 ガイダンスについては 、IP アドレスの計画 を参照してください。

セキュリティに関する考慮事項

プライベート PaaS 接続は、データ流出の状態、DNS の信頼性、ネットワーク ポリシーの適用に直接影響します。 実装を設計するときは、次のガイダンスを検討してください。

データの流出防止

プライベート エンドポイントは、各エンドポイントが 1 つのリソース インスタンスにマップされるため、最も強力な流出保護を提供します。 VNet 内のユーザーまたはアプリケーションは、プライベート エンドポイントが構成されている特定のストレージ アカウントまたはデータベースにのみ到達できます。 同じサービスの種類の別のインスタンスにデータをリダイレクトすることはできません。

これに対し、サービス エンドポイントは VNet レベルでアクセスを制限しますが、サービスの種類のすべてのインスタンスに適用されます。 たとえば、Azure Storageのサービス エンドポイントは、VNet が、目的のアカウントだけでなく、アクセスを許可する任意のAzure Storage アカウントに到達できることを意味します。 このギャップにより、データ流出がコンプライアンス上の問題となる環境では、サービス エンドポイントが不十分になります。

DNS ゾーンの構成

クライアントからAzure DNSとプライベート DNS ゾーンからストレージ アカウントへのプライベート エンドポイント DNS 解決フローを示す図。

プライベート エンドポイントは、正しく機能する DNS 解決に依存します。 プライベート エンドポイントを作成するときは、プライベート DNS ゾーン (たとえば、Azure Blob Storageのprivatelink.blob.core.windows.net) を構成して、サービス FQDN がパブリック IP ではなくプライベート IP に解決されるようにします。

DNS ゾーンが正しく構成されていないと、次の原因が発生する可能性があります。

  • アプリケーションがパブリック IP に解決され、プライベート エンドポイント全体がバイパスされます。
  • 条件付きフォワーダーが構成されていないため、オンプレミスのクライアントはプライベート IP に到達できません。
  • 一部のクライアントがプライベートで解決し、他のクライアントがパブリックに解決するスプリットブレイン DNS の問題。

共有サービスまたは接続サブスクリプション内のプライベート DNS ゾーンを一元化し、解決が必要なすべての仮想ネットワークにリンクします。 Azure Policyを使用して、プライベート エンドポイントの作成時にプライベート DNS ゾーン統合を適用します。

プライベート エンドポイント サブネットのネットワーク ポリシー

ネットワーク セキュリティ グループ (NSG) とユーザー定義ルート (UDR) がプライベート エンドポイント サブネットでサポートされるようになりました。 このサポートは既定で無効になっており、サブネットごとに明示的に有効にする必要があります。 ネットワーク ポリシーを有効にした後:

  • NSG ルールを適用して、プライベート エンドポイントに到達できるソースを制御できます。
  • UDR を使用して、検査のためにネットワーク仮想アプライアンスを介してプライベート エンドポイント トラフィックをルーティングできます。
  • アプリケーション セキュリティ グループ (ASG) 規則でプライベート エンドポイントを参照できます。

運用環境のプライベート エンドポイント サブネットでネットワーク ポリシーを有効にして、仮想ネットワーク内のすべてのサブネットで一貫したセキュリティ体制を維持します。

Important

PaaS サービスのプライベート エンドポイントを構成したら、そのサービスのパブリック ネットワーク アクセスをオフにします。 パブリック アクセスが有効なままの場合でも、トラフィックはインターネット経由でサービスに到達できるため、プライベート接続の目的は無効になります。

一般的なサービスのプライベート DNS ゾーン

次の表に、一般的に使用される Azure PaaS サービスに必要なプライベート DNS ゾーンを示します。

Azure サービス プライベート DNS ゾーン
Azure Blob Storage privatelink.blob.core.windows.net
Azure SQL Database privatelink.database.windows.net
Azure Key Vault privatelink.vaultcore.azure.net
Azure Cosmos DB privatelink.documents.azure.com
Azure App Service privatelink.azurewebsites.net

Tip

Azure ポータルでプライベート エンドポイントを作成すると、多くの場合、関連付けられているプライベート DNS ゾーンが自動的に作成されます。 プライベート エンドポイントを削除しても、ゾーンまたはその仮想ネットワーク リンクが削除されるわけではありません。 孤立したプライベート エンドポイントとプライベート DNS ゾーンを定期的に監査します。 名前解決の構成にコストと煩雑さが追加されます。

PaaS アクセスのネットワーク セキュリティ境界

Private Linkは、トラフィックがプライベート IP アドレスを介して PaaS サービスに到達する方法を制御します。 ネットワーク セキュリティ境界 (NSP) は、 その サービスとの通信を許可されるネットワークとリソースを制御します。 NSP は、Azure Storage、Azure SQL Database、Azure Key Vault などの PaaS リソースの周囲に明示的な境界を追加します。境界内のリソースは自由に通信しますが、外部からのアクセスは、アクセス規則で許可されていない限り、既定では拒否されます。 高セキュリティ設計で PaaS レベルのデータ流出保護が必要な場合は、プライベート エンドポイントと共に NSP を使用します。 NSP が複数のセキュリティ レベルに適合する場合は、概要の セキュリティ体制マトリックス を参照してください。

詳細情報

次のステップ

Tip

あなた自身で探検? 概要ナビゲーターに戻り、機能別に次の記事を見つけます。

リフトアンドシフト体験の次の手順:

送信インターネット アクセス: 移行されたワークロードが一元化されたエグレス パスを介してインターネットに到達する方法を制御します。

次に、最新化の取り組みを行います。

送信インターネット アクセス: すべてのスポークエグレスをハブ ファイアウォール経由でルーティングし、一貫性のある IT 管理の制御を実現します。

マルチクラウドへの移行における次のステップ:

ネットワークの監視と診断: クラウド間トラフィックとプライベート エンドポイント接続を可視化します。

クラウド間の設計に一元化されたインターネット エグレスが含まれている場合は、最初に 送信インターネット アクセス をお読みください。

  • Last updated on