Menyiapkan zona pendaratan Anda untuk migrasi

  • Artikel

Artikel ini menjelaskan cara menyiapkan zona pendaratan Azure Anda untuk migrasi. Ini juga mencantumkan tugas utama yang harus Anda lakukan untuk memastikan bahwa konfigurasi tersedia untuk proyek migrasi Anda.

Terlepas dari implementasi referensi zona pendaratan Azure mana yang Anda gunakan, Anda harus melakukan beberapa tugas untuk menyiapkan zona pendaratan Anda untuk proyek migrasi yang berhasil.

Jika Anda tidak menggunakan implementasi referensi zona arahan Azure, Anda masih perlu melakukan langkah-langkah dalam artikel ini. Namun, Anda mungkin memiliki tugas prasyarat untuk dilakukan terlebih dahulu, atau Anda mungkin harus menyesuaikan rekomendasi tertentu dengan desain Anda.

Artikel ini menjelaskan tugas yang harus Anda lakukan untuk zona pendaratan Azure yang ada setelah disebarkan. Beberapa tugas berfokus pada penyebaran otomatis. Ini dicatat jika tugas tidak relevan untuk lingkungan yang disebarkan dan dikelola secara manual.

Membangun konektivitas hibrid

Selama penyebaran zona pendaratan Azure, Anda dapat menyebarkan langganan Koneksi ivity dengan jaringan virtual hub dan gateway jaringan, seperti gateway Vpn Azure, gateway Azure ExpressRoute, atau keduanya. Setelah penyebaran zona pendaratan Azure, Anda masih harus mengonfigurasi konektivitas hibrid dari gateway ini untuk menyambungkan ke appliance pusat data yang ada atau sirkuit ExpressRoute Anda.

Dalam fase siap, Anda merencanakan konektivitas Anda ke Azure. Gunakan rencana ini untuk menentukan koneksi yang perlu Anda masukkan. Misalnya, jika Anda menggunakan ExpressRoute, Anda harus bekerja dengan penyedia Anda untuk membuat sirkuit ExpressRoute Anda.

Untuk mendapatkan panduan teknis untuk skenario tertentu, lihat:

Catatan

Untuk panduan tambahan, lihat juga dokumentasi spesifik penyedia Anda.

Jika Anda membuat konektivitas hibrid ke Azure melalui appliance virtual jaringan (NVA) pihak ketiga yang disebarkan di jaringan virtual Anda, tinjau panduan spesifik mereka dan panduan umum kami untuk NVA yang sangat tersedia.

Menyiapkan identitas

Selama penyebaran zona pendaratan Azure, Anda juga harus menyebarkan arsitektur pendukung untuk platform identitas Anda. Anda mungkin memiliki langganan identitas khusus atau grup sumber daya dan jaringan virtual atau subnet untuk komputer virtual (VM) yang Anda gunakan untuk identitas. Namun, Anda harus menyebarkan sumber daya identitas setelah penyebaran zona pendaratan Azure.

Bagian berikut ini menyediakan panduan yang terkait dengan Direktori Aktif. Jika Anda menggunakan penyedia identitas yang berbeda untuk autentikasi dan otorisasi, Anda harus mengikuti panduan mereka tentang memperluas identitas Anda ke Azure.

Sebelum Anda menerapkan panduan ini, tinjau Direktori Aktif dan keputusan identitas hibrid yang Anda buat saat merencanakan zona pendaratan Anda.

Anda juga harus meninjau garis besar identitas dari fase tata kelola untuk menentukan apakah Anda perlu membuat perubahan di ID Microsoft Entra.

Memperluas pengontrol domain Active Directory

Dalam sebagian besar skenario migrasi, beban kerja yang Anda migrasikan ke Azure sudah bergabung ke domain Direktori Aktif yang sudah ada. MICROSOFT Entra ID menawarkan solusi untuk memodernisasi manajemen identitas, bahkan untuk beban kerja VM, tetapi dapat mengganggu migrasi. Merancang ulang penggunaan identitas untuk beban kerja sering dilakukan selama modernisasi atau inisiatif inovasi.

Akibatnya, Anda perlu menyebarkan pengontrol domain ke Azure di dalam area jaringan identitas yang Anda sebarkan. Setelah menyebarkan VM, Anda harus mengikuti proses promosi pengendali domain normal untuk menambahkannya ke domain. Proses ini mungkin termasuk membuat situs tambahan untuk mendukung topologi replikasi Anda.

Untuk pola arsitektur umum untuk menyebarkan sumber daya ini, lihat Menyebarkan Active Directory Domain Services (AD DS) di jaringan virtual Azure.

Jika Anda menerapkan arsitektur skala perusahaan untuk perusahaan kecil, server AD DS sering berada di subnet di hub. Jika Anda menerapkan arsitektur hub-and-spoke skala perusahaan atau arsitektur Virtual WAN skala perusahaan, server sering berada di jaringan virtual khusus mereka.

Microsoft Entra Connect

Banyak organisasi sudah memiliki Microsoft Entra Koneksi untuk mengisi layanan Microsoft 365, seperti Exchange Online. Jika organisasi Anda tidak memiliki Microsoft Entra Koneksi, Anda mungkin perlu menginstalnya dan menyebarkannya setelah penyebaran zona pendaratan sehingga Anda dapat mereplikasi identitas.

Aktifkan DNS hibrid

Sebagian besar organisasi harus dapat menyelesaikan permintaan Domain Name System (DNS) untuk namespace layanan yang merupakan bagian dari lingkungan yang ada. Namespace layanan ini sering memerlukan integrasi dengan server Direktori Aktif. Dan sumber daya di lingkungan yang ada harus dapat menyelesaikan sumber daya di Azure.

Untuk mengaktifkan fungsi-fungsi ini, Anda perlu mengonfigurasi layanan DNS untuk mendukung alur umum. Anda dapat menggunakan zona pendaratan Azure untuk menyebarkan banyak sumber daya yang Anda butuhkan. Untuk tugas tambahan yang akan ditinjau dan disiapkan, lihat Resolusi DNS di Azure.

Resolusi DNS Kustom

Jika Anda menggunakan Direktori Aktif untuk pemecah masalah DNS atau jika Anda menyebarkan solusi pihak ketiga, Anda harus menyebarkan VM. Anda dapat menggunakan VM ini sebagai server DNS Anda jika pengontrol domain Anda disebarkan ke langganan Identitas dan spoke jaringan Anda. Jika tidak, Anda harus menyebarkan dan mengonfigurasi VM untuk menampung layanan ini.

Setelah menyebarkan VM, Anda harus mengintegrasikannya ke platform DNS yang ada sehingga mereka dapat melakukan pencarian terhadap namespace yang ada. Untuk server DNS Direktori Aktif, integrasi ini otomatis.

Anda juga dapat menggunakan Azure DNS Private Resolver, tetapi layanan ini tidak disebarkan sebagai bagian dari penyebaran zona pendaratan Azure Anda.

Jika desain Anda menggunakan zona DNS privat, rencanakan dengan sesuai. Misalnya, jika Anda menggunakan zona DNS privat dengan titik akhir privat, lihat Menentukan server DNS. Zona DNS privat disebarkan sebagai bagian dari zona pendaratan Anda. Jika Anda juga menggunakan titik akhir privat untuk melakukan upaya modernisasi, Anda harus memiliki konfigurasi tambahan untuk mereka.

Proksi DNS Azure Firewall

Anda dapat mengonfigurasi Azure Firewall sebagai proksi DNS. Azure Firewall dapat menerima lalu lintas dan meneruskannya ke pemecah masalah Azure atau server DNS Anda. Konfigurasi ini dapat memungkinkan pencarian dilakukan dari lokal ke Azure, tetapi tidak dapat diteruskan kembali secara kondisional ke server DNS lokal.

Jika Anda memerlukan resolusi DNS hibrid, Anda dapat mengonfigurasi proksi DNS Azure Firewall untuk meneruskan lalu lintas ke server DNS kustom Anda, seperti pengontrol domain Anda.

Langkah ini bersifat opsional, tetapi memiliki beberapa manfaat. Ini mengurangi perubahan konfigurasi nanti jika Anda mengubah layanan DNS dan mengaktifkan aturan nama domain yang sepenuhnya memenuhi syarat (FQDN) di Azure Firewall.

Mengonfigurasi server DNS jaringan virtual kustom

Setelah menyelesaikan aktivitas sebelumnya, Anda dapat mengonfigurasi server DNS untuk jaringan virtual Azure Anda ke server kustom yang Anda gunakan.

Untuk informasi selengkapnya, lihat Pengaturan DNS Azure Firewall.

Mengonfigurasi firewall hub

Jika Anda menyebarkan firewall di jaringan hub, ada beberapa pertimbangan yang harus Anda atasi sehingga Anda siap untuk memigrasikan beban kerja. Jika Anda tidak mengatasi pertimbangan ini di awal penyebaran, Anda mungkin mengalami masalah perutean dan akses jaringan.

Sebagai bagian dari melakukan aktivitas ini, tinjau area desain jaringan, terutama panduan keamanan jaringan.

Jika Anda menyebarkan NVA pihak ketiga sebagai firewall Anda, tinjau panduan vendor dan panduan umum kami untuk NVA yang sangat tersedia.

Menyebarkan seperangkat aturan standar

Jika Anda menggunakan firewall Azure, semua lalu lintas firewall diblokir hingga Anda menambahkan aturan izin eksplisit. Banyak firewall NVA lainnya bekerja sama. Lalu lintas ditolak hingga Anda menentukan aturan yang menentukan lalu lintas yang diizinkan.

Anda harus menambahkan aturan individual dan kumpulan aturan berdasarkan kebutuhan beban kerja. Tetapi Anda juga harus berencana untuk memiliki aturan standar, seperti akses ke Direktori Aktif atau solusi identitas dan manajemen lainnya, yang berlaku untuk semua beban kerja yang diaktifkan.

Perutean

Azure menyediakan perutean untuk skenario berikut tanpa konfigurasi tambahan:

  • Perutean antar sumber daya dalam jaringan virtual yang sama
  • Perutean antara sumber daya di jaringan virtual yang di-peering
  • Perutean antara sumber daya dan gateway jaringan virtual, baik di jaringan virtualnya sendiri atau di jaringan virtual yang di-peering yang dikonfigurasi untuk menggunakan gateway

Dua skenario perutean umum memerlukan konfigurasi tambahan. Kedua skenario memiliki tabel rute yang ditetapkan ke subnet untuk perutean bentuk. Untuk informasi selengkapnya tentang perutean Azure dan rute kustom, lihat Perutean lalu lintas jaringan virtual.

Perutean antar-spoke

Untuk area desain jaringan, banyak organisasi menggunakan topologi jaringan hub-spoke.

Anda memerlukan rute yang mentransfer lalu lintas dari satu spoke ke spoke lainnya. Untuk efisiensi dan kesederhanaan, gunakan rute default (0.0.0.0/0) ke firewall Anda. Dengan rute ini di tempat, lalu lintas ke lokasi yang tidak diketahui masuk ke firewall, yang memeriksa lalu lintas dan menerapkan aturan firewall Anda.

Jika Anda ingin mengizinkan keluarnya internet, Anda juga dapat menetapkan rute lain untuk ruang IP privat Anda ke firewall, seperti 10.0.0.0/8. Konfigurasi ini tidak mengambil alih rute yang lebih spesifik. Tetapi Anda dapat menggunakannya sebagai rute sederhana sehingga lalu lintas antar-spoke dapat dirutekan dengan benar.

Untuk informasi selengkapnya tentang jaringan spoke-to-spoke, lihat Pola dan topologi untuk komunikasi antar-spoke.

Perutean dari subnet gateway

Jika Anda menggunakan jaringan virtual untuk hub, Anda perlu merencanakan cara menangani inspeksi lalu lintas yang berasal dari gateway Anda.

Jika Anda ingin memeriksa lalu lintas, Anda memerlukan dua konfigurasi:

  • Dalam langganan Koneksi ivity, Anda perlu membuat tabel rute dan menautkannya ke subnet gateway. Subnet gateway memerlukan rute untuk setiap jaringan spoke yang ingin Anda lampirkan, dengan hop berikutnya dari alamat IP firewall Anda.

  • Di setiap langganan zona pendaratan, Anda perlu membuat tabel rute dan menautkannya ke setiap subnet. Nonaktifkan penyebaran Border Gateway Protocol (BGP) pada tabel rute.

Untuk informasi selengkapnya tentang rute kustom dan yang ditentukan Azure, lihat Perutean lalu lintas jaringan virtual Azure.

Jika Anda ingin memeriksa lalu lintas ke titik akhir privat, aktifkan kebijakan jaringan perutean yang sesuai pada subnet tempat titik akhir privat dihosting. Untuk informasi selengkapnya, lihat Mengelola kebijakan jaringan untuk titik akhir privat.

Jika Anda tidak berniat memeriksa lalu lintas, tidak diperlukan perubahan. Namun, jika Anda menambahkan tabel rute ke subnet jaringan spoke Anda, aktifkan penyebaran BGP sehingga lalu lintas dapat merutekan kembali ke gateway Anda.

Mengonfigurasi pemantauan dan manajemen

Sebagai bagian dari penyebaran zona pendaratan, Anda telah menyediakan kebijakan yang mendaftarkan sumber daya Anda di Log Azure Monitor. Tetapi Anda juga harus membuat pemberitahuan untuk sumber daya zona pendaratan Anda.

Untuk menerapkan pemberitahuan, Anda dapat menyebarkan garis besar Azure Monitor untuk zona pendaratan. Gunakan penyebaran ini untuk mendapatkan pemberitahuan berdasarkan skenario umum untuk manajemen zona pendaratan, seperti sumber daya konektivitas dan kesehatan layanan.

Anda juga dapat menyebarkan pemberitahuan kustom Anda sendiri untuk sumber daya jika kebutuhan Anda menyimpang dari apa yang ada di garis besar.

Menyiapkan zona pendaratan Anda untuk migrasi beban kerja berdaulat

Jika Anda perlu mengatasi persyaratan kedaulatan, Anda dapat mengevaluasi apakah Microsoft Cloud for Sovereignty sesuai dengan kebutuhan Anda. Microsoft Cloud for Sovereignty menyediakan lapisan kemampuan kebijakan dan audit tambahan yang memenuhi kebutuhan masing-masing sektor publik dan pelanggan pemerintah.

Anda dapat mengaktifkan kemampuan ini dengan menyebarkan zona pendaratan berdaulat. Arsitektur zona pendaratan berdaulat selaras dengan desain zona pendaratan Azure yang direkomendasikan.

Portofolio kebijakan Microsoft Cloud for Sovereignty

Dengan menggunakan kebijakan Azure, Anda dapat mengaktifkan kontrol terpusat di seluruh sumber daya Azure untuk menerapkan konfigurasi tertentu. Anda dapat menetapkan inisiatif kebijakan Microsoft Cloud for Sovereignty ke zona pendaratan Anda untuk memastikan Anda mematuhi kebijakan lokal dan persyaratan peraturan di negara/wilayah Anda.

Jika inisiatif kebijakan tersebut belum ditetapkan ke penyebaran zona pendaratan berdaulat Anda, pertimbangkan untuk menetapkan inisiatif yang sesuai dengan persyaratan peraturan Anda.

Mengaktifkan langganan vending

Bagian ini berlaku untuk organisasi yang ingin mengotomatiskan proses provisi langganan mereka. Jika Anda mengelola zona pendaratan dan pembuatan langganan secara manual, Anda harus membuat proses Anda sendiri untuk membuat langganan.

Saat mulai bermigrasi, Anda harus membuat langganan untuk beban kerja Anda. Aktifkan langganan vending untuk mengotomatiskan dan mempercepat proses ini. Saat langganan dibuat, Anda harus dapat membuat langganan dengan cepat.

Bersiap untuk Microsoft Defender untuk Cloud

Saat menyebarkan zona pendaratan, Anda juga menetapkan kebijakan untuk mengaktifkan Defender untuk Cloud untuk langganan Azure Anda. Defender untuk Cloud memberikan rekomendasi postur keamanan dalam skor amannya, yang mengevaluasi sumber daya yang disebarkan terhadap garis besar keamanan Microsoft.

Anda tidak perlu menerapkan konfigurasi teknis tambahan, tetapi Anda harus meninjau rekomendasi dan merancang rencana untuk meningkatkan postur keamanan saat Anda memigrasikan sumber daya. Saat Anda mulai memigrasikan sumber daya ke Azure, Anda harus siap untuk menerapkan peningkatan keamanan sebagai bagian dari pengoptimalan migrasi Anda.

Pertimbangkan sumber daya tambahan ini untuk mempersiapkan migrasi:

Langkah berikutnya

Menyiapkan alat dan backlog migrasi awal