この記事では、 移行のために Azure ランディング ゾーン を準備する方法について説明します。 また、移行プロジェクトの構成が確実に行われるようにするために実行する必要がある主要なタスクも一覧表示されます。
使用した Azure ランディング ゾーン参照の実装 に関係なく、移行プロジェクトを成功させるためにランディング ゾーンを準備するためにいくつかのタスクを実行する必要があります。
Azure ランディング ゾーン参照の実装を使用していない場合でも、この記事の手順を実行する必要があります。 ただし、最初に実行する前提条件タスクがある場合や、特定の推奨事項を設計に合わせる必要がある場合があります。
この記事では、デプロイ後に既存の Azure ランディング ゾーンに対して実行する必要があるタスクについて説明します。 一部のタスクは、自動デプロイに重点を置くものです。 タスクが手動でデプロイおよび管理された環境に関連しない場合は、この問題が発生します。
ハイブリッド接続を確立する
Azure ランディング ゾーンのデプロイ中に、ハブ仮想ネットワークとネットワーク ゲートウェイ (Azure VPN ゲートウェイ、Azure ExpressRoute ゲートウェイ、またはその両方) を使用して接続サブスクリプションをデプロイできます。 Azure ランディング ゾーンのデプロイ後も、既存のデータセンター アプライアンスまたは ExpressRoute 回線に接続するために、これらのゲートウェイからのハイブリッド接続を構成する必要があります。
準備フェーズでは、 Azure への接続を計画しました。 このプランを使用して、組み込む必要がある接続を決定します。 たとえば、ExpressRoute を使用する場合は、プロバイダーと連携して ExpressRoute 回線を確立する必要があります。
特定のシナリオに関する技術的なガイダンスを取得するには、次を参照してください。
- Azure VPN ゲートウェイから VPN 接続を作成します。
- ExpressRoute 回線を作成します。
- ExpressRoute ゲートウェイから回線への ExpressRoute 接続を作成します。
- Azure Virtual WAN ゲートウェイの設定を管理します。
注
追加のガイダンスについては、プロバイダーの特定のドキュメントも参照してください。
仮想ネットワークにデプロイされているサードパーティのネットワーク仮想アプライアンス (NVA) を介して Azure へのハイブリッド接続を確立する場合は、その特定のガイダンスと 高可用性 NVA に関する一般的なガイダンスを確認してください。
ID を準備する
Azure ランディング ゾーンのデプロイ時には、ID プラットフォームのサポート アーキテクチャもデプロイする必要があります。 専用の ID サブスクリプションまたはリソース グループと、ID に使用する仮想マシン (VM) の仮想ネットワークまたはサブネットがある場合があります。 ただし、Azure ランディング ゾーンのデプロイ後に ID リソースをデプロイする必要があります。
次のセクションでは、Active Directory に関連するガイダンスを提供します。 認証と承認に別の ID プロバイダーを使用する場合は、AZURE への ID の拡張に関するガイダンスに従う必要があります。
このガイダンスを実装する前に、ランディング ゾーンを計画したときに行った Active Directory とハイブリッド ID の決定を確認します。
また、ガバナンス フェーズから ID ベースライン を確認して、Microsoft Entra ID を変更する必要があるかどうかを判断する必要があります。
Active Directory ドメイン コントローラーの拡張
ほとんどの移行シナリオでは、Azure に移行するワークロードは既に既存の Active Directory ドメインに参加しています。 Microsoft Entra ID には、VM ワークロードに対しても ID 管理を最新化するためのソリューションが用意されていますが、移行が中断される可能性があります。 ワークロードの ID 使用の再設計は、多くの場合、最新化またはイノベーションの取り組み中に実行されます。
その結果、デプロイした ID ネットワーク領域内の Azure にドメイン コントローラーをデプロイする必要があります。 VM をデプロイしたら、通常のドメイン コントローラー昇格プロセスに従って、それらをドメインに追加する必要があります。 このプロセスには、レプリケーション トポロジをサポートする追加のサイトの作成が含まれる場合があります。
これらのリソースをデプロイするための一般的なアーキテクチャ パターンについては、 Azure 仮想ネットワークへの Active Directory Domain Services (AD DS) のデプロイに関するページを参照してください。
小規模企業向けにエンタープライズ規模のアーキテクチャを実装する場合、多くの場合、AD DS サーバーはハブ内のサブネット内にあります。 エンタープライズ規模のハブ アンド スポーク アーキテクチャまたはエンタープライズ規模のVirtual WAN アーキテクチャを実装する場合、多くの場合、サーバーは専用の仮想ネットワークに存在します。
Microsoft Entra Connect
多くの組織では、既に Microsoft Entra Connect を使用して、Exchange Online などの Microsoft 365 サービスを設定しています。 組織に Microsoft Entra Connect がない場合は、ID をレプリケートできるように、ランディング ゾーンのデプロイ後 にインストール してデプロイすることが必要になる場合があります。
ハイブリッド DNS を有効にする
ほとんどの組織は、既存の環境の一部である名前空間に対するドメイン ネーム システム (DNS) 要求を解決できる必要があります。 多くの場合、これらの名前空間には Active Directory サーバーとの統合が必要です。 また、既存の環境のリソースは、Azure のリソースを解決できる必要があります。
これらの機能を有効にするには、一般的なフローをサポートするように DNS サービスを構成する必要があります。 Azure ランディング ゾーンを使用して、必要なリソースの多くをデプロイできます。 確認して準備するその他のタスクについては、 Azure での DNS 解決に関するページを参照してください。
カスタム DNS 解決
DNS リゾルバーに Active Directory を使用する場合、またはサードパーティのソリューションをデプロイする場合は、VM をデプロイする必要があります。 ドメイン コントローラーが ID サブスクリプションとネットワーク スポークにデプロイされている場合は、これらの VM を DNS サーバーとして使用できます。 それ以外の場合は、これらのサービスを収容するように VM をデプロイおよび構成する必要があります。
VM をデプロイした後、既存の名前空間に対して検索を実行できるように、VM を既存の DNS プラットフォームに統合する必要があります。 Active Directory DNS サーバーの場合、この統合は自動的に行われます。
Azure DNS プライベート リゾルバーを使用することもできますが、このサービスは 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) 規則を有効にした場合の構成変更が軽減されます。
カスタム仮想ネットワーク DNS サーバーを構成する
上記のアクティビティを完了したら、Azure 仮想ネットワークの DNS サーバーを、使用するカスタム サーバーに構成できます。
詳細については、「Azure Firewall の DNS 設定」を参照してください。
ハブ ファイアウォールを構成する
ハブ ネットワークにファイアウォールをデプロイした場合は、ワークロードを移行する準備を整えるために対処する必要がある考慮事項がいくつかあります。 デプロイの初期段階でこれらの考慮事項に対処しないと、ルーティングとネットワーク アクセスの問題が発生する可能性があります。
これらのアクティビティの実行の一環として、 ネットワーク設計領域、特に ネットワーク セキュリティ ガイダンスを確認します。
サードパーティの NVA をファイアウォールとして展開する場合は、ベンダーのガイダンスと 高可用性 NVA に関する一般的なガイダンスを確認してください。
標準ルール セットを展開する
Azure ファイアウォールを使用する場合、明示的な許可規則を追加するまで、すべてのファイアウォール トラフィックがブロックされます。 他の多くの NVA ファイアウォールも同様に動作します。 許可されるトラフィックを指定するルールを定義するまで、トラフィックは拒否されます。
ワークロードのニーズに基づいて、個々のルールとルール コレクションを追加する必要があります。 ただし、Active Directory やその他の ID および管理ソリューションへのアクセスなど、すべての有効なワークロードに適用される標準的なルールも用意する必要があります。
経路選択
Azure では、追加の構成なしで、次のシナリオのルーティングが提供されます。
- 同じ仮想ネットワーク内のリソース間のルーティング
- ピアリングされた仮想ネットワーク内のリソース間のルーティング
- リソースと仮想ネットワーク ゲートウェイの間のルーティング (独自の仮想ネットワーク内、またはゲートウェイを使用するように構成されたピアリングされた仮想ネットワーク内)
2 つの一般的なルーティング シナリオでは、追加の構成が必要です。 どちらのシナリオでも、ルート テーブルがサブネットに割り当てられ、ルーティングが構成されます。 Azure ルーティングとカスタム ルートの詳細については、「 仮想ネットワーク トラフィック ルーティング」を参照してください。
スポーク間ルーティング
ネットワーク設計領域では、多くの組織がハブスポーク ネットワーク トポロジを使用します。
スポーク間でトラフィックを転送するルートが必要です。 効率とわかりやすくするために、ファイアウォールへの既定のルート (0.0.0.0/0) を使用します。 このルートを設定すると、不明な場所へのトラフィックがファイアウォールに送信され、トラフィックが検査され、ファイアウォール規則が適用されます。
インターネットエグレスを許可する場合は、プライベート IP 空間の別のルートをファイアウォールに割り当てることもできます ( 10.0.0.0/8など)。 この構成では、より具体的なルートはオーバーライドされません。 ただし、これを単純なルートとして使用して、スポーク間トラフィックが適切にルーティングされるようにすることができます。
スポーク間ネットワークに関する詳細については、「スポーク間通信のパターンとトポロジ」を参照してください。
ゲートウェイ サブネットからのルーティング
ハブに仮想ネットワークを使用する場合は、ゲートウェイから送信されるトラフィックの検査を処理する方法を計画する必要があります。
トラフィックを検査する場合は、次の 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 へのリソースの移行を開始するときは、移行の最適化の一環として セキュリティの強化を実装 する準備が整う必要があります。
関連リソース
移行の準備には、次の追加のリソースを検討してください。