移行のためのランディング ゾーンの準備

  • [アーティクル]

この記事では、移行のために Azure ランディング ゾーンを準備する方法について説明します。 また、移行プロジェクトの構成が確実に行われるようにするために実行する必要がある主要なタスクも一覧表示されます。

使用したAzure ランディング ゾーン参照の実装に関係なく、移行プロジェクトを成功させるためにランディング ゾーンを準備するためにいくつかのタスクを実行する必要があります。

Azure ランディング ゾーン参照の実装を使用していない場合でも、この記事の手順を実行する必要があります。 ただし、最初に実行する必要があるタスクがある場合や、特定の推奨事項を設計に適応させる必要がある場合があります。

この記事では、デプロイ後に既存の Azure ランディング ゾーンに対して実行する必要があるタスクについて説明します。 一部のタスクは、自動デプロイに重点を置くものです。 タスクが手動でデプロイおよびマネージド環境に関連しない場合は、この問題が発生します。

ハイブリッド接続の確立

Azure ランディング ゾーンのデプロイ中に、ハブ仮想ネットワークとネットワーク ゲートウェイ (Azure VPN ゲートウェイ、Azure ExpressRoute ゲートウェイ、またはその両方) を使用して接続サブスクリプションをデプロイできます。 Azure ランディング ゾーン デプロイ後も、これらのゲートウェイからのハイブリッド接続を構成して、既存のデータ センター アプライアンスまたは ExpressRoute 回線に接続する必要があります。

準備完了フェーズでは、Azure への接続の計画が完了しています。 このプランを使用して、組み込む必要がある接続を決定します。 たとえば、ExpressRoute を使用する場合は、プロバイダーと連携して ExpressRoute 回線を確立する必要があります。

特定のシナリオに関する技術的なガイダンスを取得するには、次を参照してください。

Note

追加のガイダンスについては、プロバイダーの特定のドキュメントも参照してください。

仮想ネットワークにデプロイされたサードパーティのネットワーク仮想アプライアンス (NVA) を介して Azure へのハイブリッド接続を確立する場合は、それに固有のガイダンスと Microsoft の NVA の可用性を高くするための一般的なガイダンスを確認してください。

ID を準備する

Azure ランディング ゾーンのデプロイ時には、ID プラットフォームのサポート アーキテクチャもデプロイする必要があります。 これには、専用の ID サブスクリプションまたはリソース グループ、および ID に使用する仮想マシン (VM) 用の仮想ネットワークまたはサブネットが含まれます。 ただし、Azure ランディング ゾーンのデプロイ後に ID リソースをデプロイする必要があります。

次のセクションでは、Active Directory に関連するガイダンスを提供します。 認証と承認に別の ID プロバイダーを使用する場合は、ID を Azure に拡張する際のガイダンスに従う必要があります。

このガイダンスを実装する前に、ランディング ゾーンを計画時に行った Active Directory とハイブリッド ID に関して行われた決定を確認します。

また、ガバナンス フェーズから ID ベースラインを確認して、Microsoft Entra ID に何らかの変更が必要かどうかを判断する必要があります。

Active Directory ドメイン コントローラーの拡張

ほとんどの移行シナリオでは、Azure に移行中のワークロードは既存の Active Directory ドメインに参加済みです。 Microsoft Entra ID は、VM ワークロードに対しても ID 管理を最新化するソリューションを提供しますが、移行が中断される可能性があります。 ワークロードの ID 使用方法の再設計は、多くの場合、現代化やイノベーションのイニシアチブの下で行われています。

その結果、ドメイン コントローラーは、デプロイした ID ネットワーク領域内の Azure にデプロイする必要があります。 VM をデプロイした後、通常のドメイン コントローラーの昇格プロセスに従って、VM をドメインに追加する必要があります。 このプロセスには、レプリケーション トポロジをサポートする追加のサイトの作成が含まれる場合があります。

これらのリソースをデプロイするための一般的なアーキテクチャ パターンについては、「Azure Virtual Network に Active Directory Domain Services (AD DS) をデプロイする」を参照してください。

小規模企業向けにエンタープライズ規模のアーキテクチャを実装する場合、多くの場合、AD DS サーバーはハブ内のサブネット内にあります。 エンタープライズ規模のハブ アンド スポーク アーキテクチャまたはエンタープライズ規模の Virtual WAN アーキテクチャを実装する場合、多くの場合、サーバーは専用の仮想ネットワークに存在します。

Microsoft Entra Connect

多くの組織は、Exchange Online などの Microsoft 365 サービスを設定するための Microsoft Entra Connect を既に持っています。 組織に Microsoft Entra Connect がない場合は、ID をレプリケートできるように、ランディング ゾーンのデプロイ後にインストールしてデプロイすることが必要になる場合があります。

ハイブリッド DNS を有効にする

ほとんどの組織は、既存の環境の一部である名前空間の ドメイン ネーム システム (DNS) 要求を解決できる必要があります。 多くの場合、これらの名前空間には Active Directory サーバーとの統合が必要です。 そして、既存の環境のリソースは、Azure のリソースを解決できる必要があります。

これらの機能を有効にするには、一般的なフローをサポートするように DNS サービスを構成する必要があります。 Azure ランディング ゾーンを使用して、必要なリソースの多くをデプロイできます。 確認して準備するその他のタスクについては、「Azure での DNS 解決」に関するページを参照してください。

カスタム DNS 解決

DNS リゾルバーに Active Directory を使用する場合、またはサードパーティのソリューションをデプロイする場合は、VM をデプロイする必要があります。 ドメイン コントローラーが Identity サブスクリプションとネットワーク スポークにデプロイされている場合は、これらの VM を DNS サーバーとして使用できます。 それ以外の場合は、これらのサービスを収容するように VM をデプロイおよび構成する必要があります。

VM をデプロイした後、既存の名前空間に対して検索を実行できるように、VM を既存の DNS プラットフォームに統合する必要があります。 Active Directory DNS サーバーの場合、この統合は自動的に行われます。

Azure DNS Private Resolver を使用することもできますが、このサービスは Azure ランディング ゾーン デプロイの一部としてはデプロイされません。

設計でプライベート DNS ゾーンを使用する場合は、それに応じて計画します。 たとえば、プライベート エンドポイントでプライベート DNS ゾーンを使用する場合は、「DNS サーバーの指定」を参照してください。 プライベート DNS ゾーンは、ランディング ゾーンの一部としてデプロイされます。 プライベート エンドポイントを使用して現代化作業を実行する場合は、それらに対して追加の構成が必要です。

Azure Firewall DNS プロキシ

Azure Firewall が DNS プロキシとして機能するように構成できます。 Azure Firewall はトラフィックを受信し、それを Azure リゾルバーまたは DNS サーバーに転送できます。 この構成では、オンプレミスから Azure への検索を実行できますが、条件付きでオンプレミスの DNS サーバーに転送して戻すことはできません。

ハイブリッド DNS 解決が必要な場合は、ドメイン コントローラーなどのカスタム DNS サーバーにトラフィックを転送するように Azure Firewall DNS プロキシを構成できます。

この手順は省略可能ですが、いくつかの利点があります。 DNS サービスを変更し、Azure Firewall で完全修飾ドメイン名 (FQDN) ルールを有効にする場合に、後の構成の変更が軽減されます。

カスタムの Virtual Network の DNS サーバーを構成する

前述のアクティビティを完了すると、Azure 仮想ネットワークの DNS サーバーを、使用するカスタム サーバーに構成できます。

詳細については、「Azure Firewall の DNS 設定」を参照してください。

ハブ ファイアウォールを構成する

ハブ ネットワークにファイアウォールをデプロイした場合は、ワークロードを移行する準備をするために対応を考える必要があるいくつかの考慮事項があります。 デプロイの初期段階でこれらの考慮事項に対処しない場合、ルーティングとネットワーク アクセスの問題が発生する可能性があります。

これらのアクティビティの実行の一環として、特にネットワーク セキュリティのガイダンスについて、ネットワーク設計領域を確認してください。

サードパーティの NVA をファイアウォールとしてデプロイする場合は、ベンダーのガイダンスと Microsoft の NVA の可用性を高くするための一般的なガイダンスを確認してください。

標準ルール セットをデプロイする

Azure Firewall を使用する場合、明示的な許可ルールが追加されるまで、すべてのファイアウォール トラフィックがブロックされます。 他の多くの NVA ファイアウォールも同様に動作します。 許可されるトラフィックを指定するルールを定義するまで、トラフィックは拒否されます。

ワークロードのニーズに基づいて、個々のルールとルール コレクションを追加する必要があります。 ただし、有効なすべてのワークロードに適用される、Active Directory やその他の ID および管理ソリューションへのアクセスなどの標準ルールも計画する必要があります。

ルーティング

Azure は、追加の構成なしで次のシナリオのルーティングを提供します。

  • 同じ仮想ネットワーク内のリソース間のルーティング
  • ピアリングされた仮想ネットワーク内のリソース間のルーティング
  • リソースと仮想ネットワーク ゲートウェイ間のルーティング (独自の仮想ネットワーク内、またはゲートウェイを使用するように構成されたピアリングされた仮想ネットワーク内)

2 つの一般的なルーティング シナリオでは、追加の構成が必要です。 どちらのシナリオでも、ルート テーブルがサブネットに割り当てられ、シェイプ ルーティングに割り当てられます。 Azure ルーティングおよびカスタムのルートの詳細については、「仮想ネットワーク トラフィックのルーティング」を参照してください。

スポーク間ルーティング

多くの組織はネットワーク設計領域として、ハブスポーク ネットワーク トポロジを使用しています。

スポーク間でトラフィックを転送するルートが必要です。 効率とわかりやすくするために、ファイアウォールへの既定のルート (0.0.0.0/0) を使用します。 このルートが設定されていると、未知の場所へのトラフィックはファイアウォールに送られ、そこでトラフィックが検査され、ファイアウォール ルールが適用されます。

インターネット エグレスを許可したい場合は、10.0.0.0/8 などのプライベート IP 空間のための別のルートをファイアウォールに割り当てることもできます。 この構成では、より具体的なルートはオーバーライドされません。 ただし、これを単純なルートとして使用して、スポーク間トラフィックが適切にルーティングされるようにすることができます。

スポーク間ネットワークの詳細については、「スポーク間通信のパターンとトポロジ」を参照してください

ゲートウェイ サブネットからのルーティング

ハブに仮想ネットワークを使用する場合は、ゲートウェイからのトラフィックの検査を処理する方法を計画する必要があります。

トラフィックを検査する場合は、次の 2 つの構成が必要です。

  • 接続サブスクリプションで、ルート テーブルを作成し、それをゲートウェイ サブネットにリンクする必要があります。 ゲートウェイ サブネットは、アタッチするつもりのすべてのスポーク ネットワークごとの、次ホップをファイアウォールの IP アドレスにしたルートが必要になります。

  • 各ランディング ゾーン サブスクリプションでは、ルート テーブルを作成し、各サブネットにリンクする必要があります。 ルート テーブルで Border Gateway Protocol (BGP) の伝達を無効にします。

カスタム ルートと Azure 定義のルートの詳細については、「Azure 仮想ネットワーク トラフィック ルーティング」を参照してください。

プライベート エンドポイントへのトラフィックを検査する場合は、プライベート エンドポイントがホストされているサブネット上で適切なルーティング ネットワーク ポリシーを有効にします。 詳細については、「プライベート エンドポイントのネットワーク ポリシーを管理する」を参照してください。

トラフィックを検査する予定がない場合は、変更は必要ありません。 ただし、ルート テーブルをスポーク ネットワーク サブネットに追加する場合は、BGP 伝播を有効にして、トラフィックをゲートウェイにルーティングできるようにします。

監視と管理を構成する

ランディング ゾーンのデプロイの一環として、リソースを Azure Monitor ログに登録するポリシーがプロビジョニングされます。 ただし、ランディング ゾーン リソースのアラートも作成する必要があります。

アラートを実装するには、ランディング ゾーンの Azure Monitor ベースラインをデプロイできます。 このデプロイを使用して、接続リソースやサービス正常性など、ランディング ゾーン管理の一般的なシナリオに基づいてアラートを取得します。

また、自分のニーズがベースラインの内容から逸脱している場合は、リソースに対する独自のカスタム アラートをデプロイすることもできます。

ソブリン ワークロードの移行用にランディング ゾーンを準備する

主権要件に対処する必要がある場合は、Microsoft Cloud for Sovereignty が要件に適合するかどうかを評価できます。 Microsoft Cloud for Sovereignty には、個々の公共部門と官公庁系顧客のニーズに対応する追加のポリシーと監査機能が用意されています。

これらの機能を有効にするには、ソブリン ランディング ゾーンをデプロイします。 ソブリン ランディング ゾーンのアーキテクチャは、推奨される Azure ランディング ゾーン の設計と一致します。

Microsoft Cloud for Sovereignty ポリシー ポートフォリオ

Azure ポリシーを使用すると、Azure リソース全体で一元的な制御を有効にして、特定の構成を適用できます。 Microsoft Cloud for Sovereignty ポリシー イニシアチブをランディング ゾーンに割り当てて、お住まいの国/地域のローカル ポリシーと規制要件に確実に準拠させることができます。

これらのポリシー イニシアチブがまだソブリン ランディング ゾーンのデプロイに割り当てられていない場合は、規制要件に対応するイニシアチブを割り当てることを検討してください。

サブスクリプション サービスを有効化する

このセクションは、サブスクリプションのプロビジョニング プロセスを自動化したい組織向けのものです。 ランディング ゾーンとサブスクリプションの作成を手動で管理する場合は、サブスクリプションを作成するための独自のプロセスを確立する必要があります。

移行を開始する際、ワークロード用のサブスクリプションを作成する必要があります。 このプロセスを自動化して高速化するにはサブスクリプション サービスを有効にします。 サブスクリプション サービスが確立されると、サブスクリプションをすばやく作成できるようになるはずです。

Microsoft Defender for Cloud の準備

ランディング ゾーンをデプロイするときに、Azure サブスクリプションに対して Defender for Cloud を有効にするポリシーも設定します。 Defender for Cloud はセキュア スコアを通じてセキュリティ態勢に関する推奨事項を提供します。これは Microsoft Security ベースラインに基づいてデプロイされたリソースを評価します。

追加の技術的な構成を実装する必要はありませんが、リソースを移行する際には、推奨事項を確認し、セキュリティ態勢を改善する計画を立てる必要があります。 Azure へのリソースの移行を開始する際、移行の最適化の一環としてセキュリティの強化を実装する準備が整っている必要があります。

移行の準備をするには、次の追加のリソースを検討してください。

次のステップ

ツールと初期移行バックログの準備