Dokumen ini membahas persyaratan yang perlu dipertimbangkan saat Anda men-deploy Active Directory ke Google Cloud dan membantu Anda memilih arsitektur yang tepat.
Dengan menggabungkan Active Directory dengan Cloud Identity atau Google Workspace (lihat Pola untuk mengautentikasi pengguna tenaga kerja di lingkungan hybrid), Anda dapat memungkinkan pengguna dari domain Active Directory yang ada untuk mengautentikasi dan mengakses resource di Google Cloud. Anda juga dapat men-deploy Active Directory ke Google Cloud jika Anda berencana menggunakan Active Directory untuk mengelola server Windows di Google Cloud atau jika Anda mengandalkan protokol yang tidak didukung oleh Google Cloud.
Sebelum men-deploy Active Directory ke Google Cloud, Anda harus terlebih dahulu memutuskan domain dan arsitektur forest yang akan digunakan, serta cara berintegrasi dengan forest Active Directory yang ada.
Menilai persyaratan
Active Directory mendukung berbagai arsitektur domain dan forest. Dalam lingkungan hybrid, salah satu opsinya adalah dengan memperluas domain Active Directory tunggal di beberapa lingkungan. Jika tidak, Anda dapat menggunakan domain atau forest terpisah dan menghubungkannya menggunakan kepercayaan. Arsitektur mana yang paling tepat bergantung pada kebutuhan Anda.
Untuk memilih arsitektur terbaik, perhatikan faktor-faktor berikut:
- Keselarasan dengan zona keamanan lama
- Interaksi antara resource lokal dan Google Cloud
- Otonomi administratif
- Ketersediaan
Bagian berikut akan membahas faktor-faktor tersebut.
Keselarasan dengan zona keamanan lama
Mulailah dengan meninjau desain jaringan lokal Anda.
Di lingkungan lokal Anda, Anda mungkin telah melakukan segmentasi pada jaringan menjadi beberapa zona keamanan—misalnya, dengan menggunakan VLAN atau subnet terpisah. Pada jaringan yang telah disegmentasi menjadi zona keamanan, komunikasi di dalam zona keamanan antara lain tidak dibatasi atau dibatasi hanya dengan firewall ringan dan kebijakan audit. Sebaliknya, setiap komunikasi di seluruh zona keamanan dibatasi oleh firewall ketat, kebijakan audit atau kebijakan penyelidikan traffic.
Tujuan zona keamanan lebih luas daripada sekadar membatasi dan mengaudit komunikasi jaringan, akan tetapi—zona keamanan harus menjalankan batas kepercayaan.
Batas kepercayaan
Setiap mesin dalam jaringan menjalankan beberapa proses. Proses-proses ini dapat berkomunikasi satu sama lain secara lokal dengan menggunakan komunikasi antar-proses, dan proses tersebut mungkin berkomunikasi di seluruh mesin dengan menggunakan protokol seperti HTTP. Dalam komunikasi web ini, peering tidak harus mempercayai satu sama lain untuk menggunakan tingkat yang sama. Misalnya, proses mungkin mempercayai proses yang berjalan pada mesin yang sama lebih dari proses yang berjalan di komputer lain. Dan beberapa komputer mungkin dianggap lebih tepercaya daripada yang lain.
Batasan kepercayaan menerapkan aturan diskriminatif antara pihak yang berkomunikasi—dengan mempercayai satu kumpulan pihak komunikasi yang jumlahnya lebih dari kumpulan para pihak.
Batas kepercayaan sangat penting untuk membatasi dampak dari serangan. Serangan jarang selesai setelah satu sistem berhasil disusupi–baik sistem itu memiliki proses tunggal atau seluruh komputer. Sebaliknya, penyerang kemungkinan untuk berupaya memperluas serangannya ke sistem lainnya. Karena sistem dalam batas kepercayaan tidak mendiskriminasi satu sama lain, serangan yang menyebar di dalam batas kepercayaan tersebut lebih mudah daripada menyerang sistem di seluruh batas kepercayaan.
Setelah sistem dalam batas kepercayaan disusupi, semua sistem lain dalam batas kepercayaan tersebut harus diasumsikan telah disusupi. Asumsi ini dapat membantu Anda mengidentifikasi batas kepercayaan atau memvalidasi apakah batas sistem tertentu merupakan batas kepercayaan, misalnya:
Misalkan penyerang telah mencapai tingkat akses paling tinggi untuk menargetkan pada A (misalnya, akses Administrator atau Root ke suatu mesin atau aplikasi). Apabila penyerang dapat memanfaatkan hak istimewa ini untuk memperoleh tingkat akses yang sama untuk menargetkan pada target B, maka A dan B secara definisi, berada di dalam batas kepercayaan yang sama. Jika tidak, batas kepercayaan berada di antara A dengan B.
Dengan membatasi jaringan komunikasi, zona keamanan dapat membantu melaksanakan batas kepercayaan. Untuk zona keamanan untuk menjadi batas kepercayaan maksimum, workload di seluruh masing-masing sisi batasan harus mendiskriminasi antara permintaan yang berasal dari berbagai zona keamanan. dari zona keamanan yang berbeda-beda, .
Model zero-trust
Model zero-trust adalah model jaringan yang lebih disukai di Google Cloud.
Dengan mempertimbangkan sistem tunggal yang disusupi dalam batas kepercayaan, Anda dapat mengasumsikan bahwa semua sistem dalam batas tersebut disusupi. Asumsi ini menyarankan bahwa semakin kecil batas kepercayaan, semakin baik. Semakin kecil batas kepercayaan, semakin kecil sistem yang disusupi dan semakin banyak batasan yang harus ditembus penyerang agar suatu serangan dapat menyebar.
Model zero-trust memanfaatkan gagasan ini untuk kesimpulan logikanya: Setiap mesin di jaringan dianggap sebagai zona keamanan dan batas kepercayaan yang unik. Semua komunikasi antar komputer tunduk pada pemeriksaan dan aturan firewall yang sama, dan semua permintaan jaringan dianggap berasal dari sumber yang tidak tepercaya.
Di tingkat jaringan, Anda dapat menerapkan model zero-trust dengan menggunakan aturan firewall untuk membatasi traffic dan Log aliran traffic VPC serta logging aturan firewall untuk menganalisis traffic. Pada tingkat aplikasi, Anda harus memastikan bahwa semua aplikasi menangani autentikasi, otorisasi, dan audit secara konsisten dan aman.
Batas kepercayaan pada Active Directory
Dalam domain Active Directory, mesin memercayai pengontrol domain untuk menangani autentikasi dan otorisasi atas namanya. Setelah pengguna telah membuktikan identitas mereka ke salah satu pengontrol domain, mereka dapat login ke semua komputer dengan domain yang sama secara default. Setiap hak akses yang didapatkan pengguna dari pengontrol domain (dalam bentuk hak istimewa dan keanggotaan grup) berlaku untuk sebagian besar komputer pada domain tersebut.
Dengan menggunakan kebijakan grup, Anda dapat mencegah pengguna dari mengakses komputer tertentu atau membatasi hak mereka pada komputer tertentu. Namun, setelah komputer disusupi, penyerang mungkin dapat mencuri sandi, hash sandi, atau token Kerberos dari pengguna domain lain yang login ke komputer yang sama. Penyerang kemudian dapat memanfaatkan kredensial ini untuk menyebarkan serangan ke domain lain di dalam forest.
Dengan mempertimbangkan faktor-faktor ini, sebaiknya asumsikan bahwa semua komputer di dalam forest berada dalam batas keamanan kepercayaan.
Dibandingkan dengan batas domain yang tujuannya untuk mengontrol replikasi dan memberikan otonomi administratif ke berbagai bagian organisasi, batas forest dapat memberikan isolasi yang lebih kuat. Forests dapat berfungsi sebagai batas kepercayaan.
Menyelaraskan forest dan zona keamanan Active Directory
Mengasumsikan forest sebagai batas kepercayaan yang memengaruhi desain zona keamanan. Apabila forest diperluas hingga dua zona keamanan, mudah bagi penyerang untuk menembus batas antara zona keamanan ini. Akibatnya, dua zona keamanan secara efektif menjadi satu dan membentuk satu batas kepercayaan.
Dalam model zero-trust, setiap komputer dalam jaringan dapat dianggap sebagai zona keamanan terpisah. Men-deploy Active Directory pada jaringan tersebut akan mengacaukan konsep ini dan memperluas batas keamanan yang ada untuk mencakup semua komputer dari forest Active Directory.
Agar zona keamanan berfungsi sebagai batas kepercayaan, Anda harus memastikan bahwa seluruh forest Active Directory berada dalam zona keamanan.
Dampak terhadap perluasan Active Directory ke Google Cloud
Saat merencanakan deployment ke Google Cloud yang memerlukan Active Directory, Anda harus memilih antara dua opsi untuk menyelaraskan deployment dengan zona keamanan yang ada:
Memperluas zona keamanan yang ada ke Google Cloud. Anda dapat memperluas satu atau beberapa zona keamanan yang ada ke Google Cloud dengan menyediakan VPC Bersama di Google Cloud dan menghubungkannya ke zona yang ada menggunakan Cloud VPN atau Cloud Interconnect.
Resource yang di-deploy secara lokal dan di Google Cloud yang menggunakan zona bersama juga dapat berbagi forest Active Directory yang sama, sehingga tidak perlu men-deploy forest terpisah ke Google Cloud.
Sebagai contoh, pertimbangkan jaringan yang ada yang memiliki jaringan perimeter pengembangan dan jaringan perimeter produksi sebagai zona keamanan dengan hutan Active Directory terpisah di setiap zona keamanan. Jika Anda memperluas zona keamanan keGoogle Cloud, semua deployment di Google Cloud juga merupakan bagian dari salah satu dari dua zona keamanan ini, dan dapat menggunakan forest Active Directory yang sama.
Memperkenalkan zona keamanan baru. Memperluas zona keamanan mungkin tidak berlaku—baik karena Anda tidak ingin memperluas zona lebih lanjut, atau karena persyaratan keamanan zona keamanan yang ada tidak sesuai dengan persyaratan deployment Google CloudAnda. Anda dapat memperlakukan Google Cloud sebagai zona keamanan tambahan.
Sebagai contoh, pertimbangkan lingkungan lokal yang memiliki jaringan perimeter, tetapi tidak membedakan antara beban kerja pengembangan dan produksi. Untuk memisahkan workload ini di Google Cloud, Anda dapat membuat dua VPC Bersama dan menganggapnya sebagai zona keamanan baru. Kemudian, Anda men-deploy dua forest Active Directory tambahan ke Google Cloud, satu per zona keamanan. Jika perlu, Anda dapat membuat hubungan kepercayaan antar forest guna memungkinkan autentikasi di seluruh zona keamanan.
Interaksi antara resource lokal dan Google Cloud
Faktor kedua yang perlu dipertimbangkan saat Anda memperluas Active Directory keGoogle Cloud adalah interaksi pengguna dan resource antara infrastruktur lokal dan Google Cloud. Bergantung pada kasus penggunaan Anda, interaksi ini dapat terjadi di mana pun mulai dari interaksi ringan hingga berat.
Interaksi ringan
Jika satu-satunya tujuan penggunaan Active Directory di Google Cloud adalah untuk mengelola armada server Windows dan memungkinkan administrator login ke server ini, tingkat interaksi antar-lingkungan akan ringan:
- Kumpulan karyawan yang berinteraksi dengan resource di Google Cloud terbatas pada staf administratif.
- Aplikasi yang di-deploy ke Google Cloud mungkin tidak berinteraksi dengan aplikasi lokal sama sekali atau dapat melakukannya tanpa mengandalkan fasilitas autentikasi Windows seperti Kerberos dan NTLM.
Dalam skenario ringan, pertimbangkan untuk mengintegrasikan lingkungan lokal dan Google Cloud lingkungan Anda dengan salah satu dari dua cara berikut:
Dua forest aktif yang belum terhubung: Anda dapat mengisolasikan dua lingkungan dengan menggunakan dua Active Directory forest yang terpisah yang tidak memiliki kepercayaan yang sama. Agar administrator dapat melakukan autentikasi, Anda dapat mengelola kumpulan akun pengguna secara terpisah untuk mereka di hutan Google Cloud.
Mengelola kumpulan duplikat akun pengguna menambah upaya administratif dan menimbulkan risiko melewatkan penonaktifan akun ketika karyawan keluar dari perusahaan. Pendekatan yang lebih baik adalah dengan menyediakan akun ini secara otomatis.
Jika akun pengguna di Active Directory lokal disediakan oleh Sistem Informasi Sumber Daya Manusia (HRIS), Anda mungkin dapat menggunakan mekanisme serupa untuk menyediakan dan mengelola akun pengguna di Google Cloud hutan. Jika tidak, Anda dapat menggunakan alat seperti Microsoft Identity Manager untuk mensinkronkan akun pengguna antar lingkungan.
Dua forest Active Directory dengan kepercayaan lintas forest: Dengan menggunakan dua forest Active Directory dan menghubungkannya dengan kepercayaan lintas forest, Anda dapat menghindari kebutuhan untuk mengelola akun duplikat. Administrator menggunakan akun pengguna yang sama untuk mengautentikasi kedua lingkungan. Meskipun tingkat isolasi antarlingkungan dapat dianggap lebih lemah, penggunaan hutan terpisah memungkinkan Anda mempertahankan batas kepercayaan antara lingkungan lokal dan Google Cloud lingkungan Anda.
Interaksi sedang
Kasus penggunaan Anda mungkin lebih kompleks. Contoh:
- Administrator yang login ke server Windows yang di-deploy di Google Cloud mungkin perlu mengakses fitur berbagi file yang dihosting di infrastruktur lokal.
- Aplikasi dapat menggunakan Kerberos atau NTLM untuk mengautentikasi dan berkomunikasi di batas lingkungan.
- Anda mungkin ingin memungkinkan karyawan menggunakan Integrated Windows Authentication (IWA) untuk mengautentikasi ke aplikasi web yang di-deploy di Google Cloud.
Dalam skenario yang sedang, pengoperasian dua forest Active Directory yang terpisah mungkin terlalu membatasi: Anda tidak dapat menggunakan Kerberos untuk melakukan autentikasi di kedua forest, dan menggunakan autentikasi pass-through NTLM mengharuskan Anda menjaga akun dan sandi pengguna tetap sinkron.
Dalam kasus ini, sebaiknya gunakan dua forest Active Directory dengan kepercayaan lintas forest.
Interaksi intensif
Workload tertentu, termasuk deployment Infrastruktur Desktop Virtual (VDI), mungkin memerlukan interaksi yang berat antara resource lokal dan resource yang di-deploy di Google Cloud. Ketika resource di seluruh lingkungan saling terkait upaya untuk mempertahankan batas kepercayaan antar lingkungan mungkin dianggap tidak praktis dan menggunakan dua forest dengan kepercayaan lintas forest dapat dianggap terlalu membatasi.
Dalam kasus ini, sebaiknya gunakan forest Active Directory tunggal dan membagikannya di seluruh lingkungan.
Otonomi administratif
Faktor ketiga yang perlu dipertimbangkan saat Anda memperluas Active Directory keGoogle Cloud adalah otonomi administratif.
Jika Anda berencana untuk mendistribusikan workload di infrastruktur lokal dan Google Cloud, beban kerja yang akan Anda jalankan Google Cloud mungkin sangat berbeda dengan workload yang Anda simpan di infrastruktur lokal. Bahkan, Anda mungkin menentukan bahwa dua lingkungan yang berbeda harus dikelola oleh dua tim yang berbeda pula.
Memisahkan tanggung jawab di antara tim mengharuskan agar masing-masing tim diberikan otonomi administratif. Di Active Directory, Anda dapat memberikan wewenang kepada tim untuk mengelola resource menggunakan administrasi yang didelegasikan atau dengan menggunakan domain terpisah.
Administrasi delegasi adalah cara mudah untuk mendelegasikan tugas administratif dan memberikan sedikit otonomi kepada tim. Mempertahankan domain tunggal mungkin juga membantu Anda memastikan konsistensi di lingkungan dan tim Anda.
Namun, Anda tidak dapat mendelegasikan semua kemampuan administratif, dan membagikan domain tunggal mungkin menambah beban administratif terkait koordinasi antar tim. Dalam kasus semacam itu, sebaiknya gunakan domain terpisah.
Ketersediaan
Faktor terakhir yang perlu dipertimbangkan saat Anda memperluas Active Directory keGoogle Cloud adalah ketersediaan. Untuk setiap domain di forest Active Directory, pengontrol domain berfungsi sebagai penyedia identitas bagi pengguna dalam domain tersebut.
Ketika menggunakan Kerberos untuk autentikasi, pengguna harus berinteraksi dengan pengontrol domain Active Directory di berbagai titik:
- Autentikasi awal (memperoleh tiket pemberian tiket).
- Autentikasi berkala (menyegarkan tiket pemberian tiket).
- Mengautentikasi menggunakan resource (memperoleh tiket layanan).
Menjalankan autentikasi awal dan autentikasi ulang berkala membutuhkan komunikasi dengan pengontrol domain tunggal hanya–satu pengontrol domain dari domain tempat pengguna menjadi anggotanya.
Saat mengautentikasi dengan resource, mungkin diperlukan untuk berinteraksi dengan beberapa pengontrol domain, bergantung pada domain tempat resource berada:
- Apabila resource berada di domain yang sama dengan pengguna, pengguna dapat menggunakan pengontrol domain yang sama (atau pengontrol domain yang berbeda dari domain yang sama) untuk menyelesaikan proses autentikasi.
- Jika resource berada di domain yang berbeda, tetapi ada hubungan kepercayaan langsung dengan domain pengguna, pengguna harus berinteraksi dengan paling tidak dua pengontrol domain: Satu di domain resource dan satu lagi di domain pengguna.
- Jika resource dan pengguna merupakan bagian dari domain yang berbeda dan hanya ada hubungan kepercayaan tidak langsung antara domain ini, lalu autentikasi berhasil mengharuskan adanya komunikasi dengan pengontrol domain atau setiap domain dalam jalur kepercayaan.
Menemukan pengguna dan resource di domain atau forest Active Directory dapat menghambat ketersediaan keseluruhan. Karena mengautentikasi membutuhkan interaksi dengan beberapa domain, pemadaman layanan dari salah satu domain dapat berdampak bagi ketersediaan resource di domain lainnya.
Dengan mempertimbangkan potensi dampak topologi Active Directory terkait ketersediaan, sebaiknya menyelaraskan topologi Active Directory dengan strategi hybrid Anda.
Workload terdistribusi
Untuk memanfaatkan kemampuan unik dari masing-masing lingkungan komputasi, Anda mungkin menggunakan pendekatan distribusi workload di seluruh lingkungan tersebut. Dalam penyiapan semacam itu, beban kerja yang Anda deploy ke Google Cloud kemungkinan besar akan bergantung pada infrastruktur atau aplikasi lain yang berjalan di infrastruktur lokal, yang menjadikan konektivitas hybrid yang sangat tersedia sebagai persyaratan penting.
Jika Anda men-deploy forest atau domain Active Directory terpisah ke Google Clouddan menggunakan kepercayaan untuk menghubungkannya ke Active Directory lokal, Anda menambahkan dependensi lain antara Google Cloud dan lingkungan lokal Anda. Dependensi ini memiliki efek minimum pada ketersediaan.
Workload redundan
Jika Anda menggunakan Google Cloud untuk memastikan kelangsungan bisnis, workload di Google Cloud mencerminkan sebagian workload di lingkungan lokal Anda. Penyiapan ini memungkinkan satu lingkungan untuk mengambil alih peran dari lingkungan jika terjadi kegagalan. Jadi, Anda perlu memperhatikan setiap dependensi di antara lingkungan ini.
Jika Anda men-deploy forest atau domain Active Directory terpisah ke Google Clouddan menggunakan kepercayaan untuk menghubungkannya ke Active Directory lokal, Anda mungkin akan membuat dependensi yang mengganggu tujuan penyiapan. Jika Active Directory lokal menjadi tidak tersedia, semua workload yang di-deploy diGoogle Cloud yang mengandalkan autentikasi lintas domain atau lintas hutan mungkin juga menjadi tidak tersedia.
Jika tujuan Anda adalah untuk memastikan keberlangsungan bisnis, Anda dapat menggunakan forest Active Directory terpisah di setiap lingkungan yang tidak terhubung satu sama lain. Atau, Anda dapat memperluas domain Active Directory yang ada ke Google Cloud. Dengan men-deploy pengontrol domain tambahan keGoogle Cloud dan mereplikasi konten direktori antarlingkungan, Anda memastikan bahwa lingkungan beroperasi secara terpisah.
Pola integrasi
Setelah Anda menilai persyaratan Anda, gunakan pohon keputusan berikut untuk membantu mengidentifikasi arsitektur forest dan domain.
Bagian berikut menjelaskan setiap pola.
Forests yang disinkronkan
Pada pola synchronized forest, Anda men-deploy hutan Active Directory terpisah ke Google Cloud. Anda menggunakan forest ini untuk mengelola resource yang di-deploy pada Google Cloud serta akun pengguna yang diperlukan untuk mengelola resource tersebut.
Daripada membuat kepercayaan di antara forest baru dengan forest lama, forest lokal, Anda mensinkronkan akun. Jika menggunakan HRIS sebagai sistem terdepan untuk mengelola akun pengguna, Anda dapat mengonfigurasi HRIS untuk menyediakan akun pengguna di forest Active Directory yang dihosting Google Cloud. Atau, jika Anda dapat menggunakan alat seperti Microsoft Identity Manager untuk disinkronkan. environment.
Pertimbangkan untuk menggunakan pola forest yang disinkronkan jika satu atau beberapa hal berikut berlaku:
- Penggunaan Google Cloud yang Anda maksudkan sesuai dengan salah satu pola deployment yang redundan, dan Anda ingin menghindari dependensi runtime antara lingkungan lokal dan Google Cloud.
- Anda ingin mempertahankan batas kepercayaan antara lingkungan Active Directory lokal dan lingkungan Active Directory yang dihosting Google Cloud, baik sebagai tindakan defense in depth, atau karena Anda lebih memercayai satu lingkungan daripada lingkungan lainnya.
- Anda memperkirakan tidak ada interaksi antara resource yang dikelola Active Directory di infrastruktur lokal dan lokal Google Cloud.
- Jumlah akun pengguna yang Anda butuhkan di lingkungan Active Directory yang dihosting Google Cloudtidak banyak.
Kelebihan:
- Dengan pola forest yang disinkronkan, Anda dapat mempertahankan isolasi yang kuat antara dua lingkungan Active Directory. Penyerang yang menyusupi lingkungan mungkin memperoleh keuntungan kecil ketika menyerang lingkungan kedua.
- Anda tidak perlu menyiapkan konektivitas hybrid antara jaringan lokal dan Google Cloud jaringan Anda untuk mengoperasikan Active Directory.
- Active Directory yang dihosting Google Cloudtidak terpengaruh oleh pemadaman Active Directory lokal Anda. Polanya adalah sangat sesuai untuk keberlangsungan bisnis kasus penggunaan, atau skenario lainnya yang mengharuskan adanya ketersediaan besar.
- Anda dapat memberikan otonomi administratif tingkat tinggi kepada tim yang mengelola forest Active Directory yang dihosting Google Cloud.
- Pola ini didukung oleh Layanan Terkelola untuk Microsoft Active Directory.
Praktik terbaik:
- Jangan sinkronkan sandi akun pengguna di antara dua forest Active Directory hutan Active Directory. Tindakan tersebut akan mengurangi isolasi di antara lingkungan.
- Jangan mengandalkan autentikasi pass-through, karena autentikasi itu membutuhkan sinkronisasi kata sandi akun pengguna.
- Pastikan bahwa ketika karyawan keluar dari perusahaan, akun mereka di kedua lingkungan Active Directory dinonaktifkan atau dihapus.
Forest sumber daya
Dalam pola resource forest, Anda men-deploy forest Active Directory terpisah untuk Google Cloud. Anda menggunakan forest ini untuk mengelola resource apa pun yang di-deploy ke Google Cloud serta kumpulan akun pengguna administratif minimal yang diperlukan untuk mengelola hutan. Dengan menetapkan forest trust ke forest Active Directory lokal yang sudah ada, Anda memungkinkan pengguna dari forest yang ada untuk mengautentikasi dan mengakses resource yang dikelola oleh forest Active Directory yang dihostingGoogle Cloud.
Jika perlu, Anda dapat mengembangkan pola ini menjadi hub dan berbicara topologi dengan forest Active Directory yang ada di tengah, yang terhubung ke banyak forest resource.
Pertimbangkan menggunakan pola forest resource jika satu atau beberapa hal berikut berlaku bagi Anda:
- Penggunaan Google Cloud yang Anda maksudkan sesuai dengan salah satu pola deployment terdistribusi, dan dependensi antara lingkungan lokal dan Google Clouddapat diterima.
- Anda ingin mempertahankan batas kepercayaan antara lingkungan Active Directory lokal dan lingkungan Active Directory yang dihosting Google Cloud, baik sebagai langkah defense in depth atau karena Anda menganggap satu lingkungan lebih tepercaya daripada yang lain.
- Anda mengharapkan tingkat interaksi sedang antara resource yang dikelola di Direktori Aktif lokal dan di Google Cloud.
- Anda memiliki banyak pengguna yang perlu mengakses resource yang di-deploy di Google Cloud—misalnya, ke aplikasi web yang menggunakan IWA untuk autentikasi.
Kelebihan:
- Dengan pola forest resource, Anda dapat mempertahankan batas kepercayaan antara dua lingkungan Active Directory. Tergantung pada cara hubungan kepercayaan dikonfigurasi, penyerang yang menyusup ke salah satu lingkungan kemungkinan mendapatkan akses terbatas hingga tidak mendapatkan akses ke lingkungan lain.
- Pola ini sepenuhnya didukung oleh Microsoft AD Terkelola.
- Anda dapat memberikan otonomi administratif tingkat tinggi kepada tim yang mengelola forest Active Directory yang dihosting Google Cloud.
Praktik terbaik:
- Hubungkan kedua forest Active Directory menggunakan kepercayaan satu arah sehingga Active Directory yang dihosting Google Cloudmemercayai Active Directory Anda yang sudah ada, tetapi tidak sebaliknya.
- Gunakan autentikasi selektif untuk membatasi resource di Active Directory yang dihosting Google Cloud yang diizinkan untuk diakses oleh pengguna dari Active Directory lokal.
- Gunakan koneksi Dedicated Interconnect, Partner Interconnect, atau Cloud VPN redundan untuk memastikan konektivitas jaringan dengan ketersediaan tinggi antara jaringan lokal Anda dan Google Cloud.
Domain yang diperluas
Pada pola domain yang diperluas, Anda memperluas satu atau beberapa domain Active Directory yang ada ke Google Cloud. Untuk setiap domain, Anda men-deploy satu atau beberapa pengontrol domain di Google Cloud, yang menyebabkan semua data domain serta katalog global direplikasi dan tersedia di Google Cloud. Dengan menggunakan situs Active Directory terpisah untuk jaringan lokal dan Google Cloud , Anda memastikan bahwa klien berkomunikasi dengan pengontrol domain yang terdekat dengannya.
Pertimbangkan untuk menggunakan pola domain yang diperluas jika satu atau beberapa hal berikut berlaku bagi Anda:
- Penggunaan Google Cloud yang Anda maksudkan sesuai dengan salah satu pola deployment yang redundan, dan Anda ingin menghindari dependensi runtime antara lingkungan lokal dan Google Cloud.
- Anda memperkirakan interaksi berat antara Active Directory—resource terkelola di infrastruktur lokal dan di Google Cloud.
- Anda ingin mempercepat autentikasi untuk aplikasi yang mengandalkan LDAP untuk autentikasi.
Kelebihan:
- Active Directory yang dihosting Google Cloudtidak terpengaruh oleh pemadaman Active Directory lokal Anda. Pola ini sangat cocok untuk kasus penggunaan kelangsungan bisnis atau skenario lain yang memerlukan ketersediaan tinggi.
- Anda dapat membatasi komunikasi antara jaringan lokal dan Google Cloud. Tindakan ini berpotensi menghemat bandwidth dan memperbaiki latensi.
- Semua konten katalog global direplikasi ke Active Directory dan dapat diakses secara efisien dari resource yang dihosting Google Cloud.
Praktik terbaik:
- Jika Anda mereplikasi semua domain, komunikasi antara jaringan lokal dan Google Cloud jaringan Anda terbatas pada replikasi Active Directory antar-pengontrol domain. Jika Anda hanya mereplikasi sebagian domain forest, server gabungan dengan domain yang berjalan di Google Cloud mungkin masih perlu berkomunikasi dengan pengontrol domain dari domain yang tidak direplikasi. Pastikan aturan firewall yang berlaku untuk komunikasi antara infrastruktur lokal dan Google Cloud mempertimbangkan semua kasus yang relevan.
- Perlu diketahui bahwa replikasi di seluruh situs hanya terjadi pada interval tertentu, sehingga pembaruan dilakukan di platform pengontrol domain lokal menjadi Google Cloud hanya setelah penundaan (dan sebaliknya).
- Pertimbangkan untuk menggunakan pengontrol domain hanya baca (RODC) guna mempertahankan salinan hanya baca data domain di Google Cloud, tetapi perhatikan bahwa ada konsekuensi terkait penyimpanan sandi pengguna ke dalam cache. Jika Anda mengizinkan RODC untuk meng-cache sandi dan mengisi otomatis cache sandi, resource yang di-deploy di Google Cloud dapat tetap tidak terpengaruh oleh pemadaman pengontrol domain lokal. Namun, manfaat keamanan dari penggunaan RODC pada pengontrol domain biasa terbatas. Jika Anda menonaktifkan cache sandi, RODC yang disusupi mungkin hanya menimbulkan risiko terbatas bagi Active Directory Anda lainnya, tetapi Anda akan kehilangan manfaat dari Google Cloud tetap tidak terpengaruh oleh pemadaman pengontrol domain lokal.
Forest yang diperluas
Pada pola extended forest, Anda men-deploy domain Active Directory baru di Google Cloud, tetapi mengintegrasikannya ke dalam forest yang sudah ada. Anda menggunakan domain baru untuk mengelola resource yang di-deploy di Google Cloud dan mempertahankan sekumpulan akun pengguna administratif minimal untuk mengelola domain.
Dengan memperluas hubungan kepercayaan implisit ke domain forest lainnya, Anda memungkinkan pengguna yang ada dari domain lain untuk mengautentikasi dan mengakses resource yang dikelola oleh domain Active Directory yang dihosting Google Cloud.
Pertimbangkan menggunakan pola forest yang diperluas jika satu atau lebih hal berikut berlaku bagi Anda:
- Penggunaan Google Cloud yang Anda maksudkan sesuai dengan salah satu pola deployment terdistribusi, dan dependensi antara lingkungan lokal Anda dan Google Cloud dapat diterima.
- Resource yang ingin Anda deploy Google Cloud memerlukan konfigurasi atau struktur domain yang berbeda dengan yang disediakan oleh domain yang ada, atau Anda ingin memberikan otonomi administratif tingkat tinggi kepada tim yang mengelola domain yang dihosting Google Cloud.
- Anda memperkirakan interaksi sedang hingga berat antara resource yang dikelola Direktori Aktif di infrastruktur lokal dan di Google Cloud.
- Anda memiliki banyak pengguna yang perlu mengakses resource yang di-deploy ke Google Cloud—misalnya, ke aplikasi web yang menggunakan IWA untuk autentikasi.
Kelebihan:
- Semua konten katalog global akan direplikasi ke Active Directory dan dapat diakses secara efisien dari resource yang dihosting Google Cloud.
- Traffic replikasi antara jaringan lokal Anda dan Google Cloud dibatasi untuk replikasi katalog global. Hal ini dapat membantu Anda dalam membatasi konsumsi bandwidth keseluruhan.
- Anda dapat memberikan otonomi administratif tingkat tinggi kepada tim yang mengelola domain Active Directory yang dihosting Google Cloud.
Praktik terbaik:
- Gunakan koneksi Dedicated Interconnect, Partner Interconnect, atau Cloud VPN redundan untuk memastikan konektivitas jaringan dengan ketersediaan tinggi antara jaringan lokal Anda dan Google Cloud.
Resource forest dengan domain yang diperluas
Pola forest resource dengan extended domain adalah ekstensi dari pola forest resource. Dengan pola forest resource, Anda dapat mempertahankan batas kepercayaan antar-lingkungan dan memberikan otonomi administratif. Batasan forest resource adalah ketersediaannya secara keseluruhan bergantung pada ketersediaan dari pengontrol domain lokal dan bergantung pada konektivitas jaringan di pusat data lokal Anda.
Anda dapat mengatasi batasan ini dengan menggabungkan pola forest resource dengan pola domain yang diperluas. Dengan mereplikasi domain, akun pengguna Anda berada di Google Cloud, dan Anda dapat memastikan bahwa pengguna dapat melakukan autentikasi ke resource yang dihosting Google Cloud meskipun pengontrol domain lokal tidak tersedia atau konektivitas jaringan hilang.
Pertimbangkan untuk menggunakan forest resource dengan pola domain yang diperluas jika satu atau beberapa hal berikut berlaku bagi Anda:
- Anda ingin mempertahankan batas kepercayaan di antara forest Active Directory utama Anda dengan forest resource.
- Anda ingin mencegah gangguan pengontrol domain lokal atau hilangnya konektivitas jaringan ke lingkungan lokal agar tidak memengaruhi beban kerja yang dihostingGoogle Cloud.
- Anda memperkirakan interaksi moderat antara resource yang dikelola Active Directory di infrastruktur lokal dan di Google Cloud.
- Anda memiliki banyak pengguna dari satu domain Active Directory yang perlu mengakses resource yang di-deploy di Google Cloud—misalnya, ke aplikasi web yang menggunakan IWA untuk autentikasi.
Kelebihan:
- Resource yang dihostingGoogle Cloudtidak terpengaruh oleh pemadaman Active Directory lokal. Pola ini sangat sesuai untuk kasus penggunaan keberlangsungan bisnis atau skenario lain yang membutuhkan ketersediaan tinggi.
- Pola ini memungkinkan Anda mempertahankan batas kepercayaan antara dua forest Active Directory. Tergantung pada cara hubungan kepercayaan dikonfigurasi, penyerang yang menyusup ke satu lingkungan kemungkinan mendapatkan akses terbatas hingga tidak mendapatkan akses ke lingkungan lain.
- Komunikasi antara jaringan lokal dan jaringan Google Cloud terbatas pada replikasi Active Directory antara pengontrol domain. Anda dapat menerapkan aturan firewall untuk menolak semua komunikasi lain, memperkuat isolasi di antara lingkungan
- Anda dapat memberikan otonomi administratif tingkat tinggi kepada tim yang mengelola forest Active Directory yang dihosting Google Cloud.
- Anda dapat menggunakan Microsoft AD Terkelola untuk forest resource.
Praktik terbaik:
- Deploy pengontrol domain untuk domain yang diperluas ke projectGoogle Cloud dan VPC terpisah untuk memisahkan komponen ini dari komponen hutan resource.
- Gunakan peering VPC untuk menghubungkan VPC ke VPC Bersama atau ke VPC yang digunakan oleh forest resource dan konfigurasi firewall untuk membatasi komunikasi ke autentikasi pengguna Kerberos dan pembuatan kepercayaan forest.
- Hubungkan kedua forest Active Directory menggunakan kepercayaan satu arah sehingga Active Directory yang dihosting Google Cloudmemercayai forest Active Directory Anda yang ada, tetapi tidak sebaliknya.
- Gunakan autentikasi selektif untuk membatasi resource dalam forest resource di mana pengguna dari forest lain diizinkan untuk mengakses.
- Perlu diketahui bahwa replikasi di berbagai situs hanya terjadi pada interval tertentu, sehingga update dilakukan di platform pengontrol domain lokal ke Google Cloud hanya setelah penundaan (dan sebaliknya).
- Pertimbangkan untuk menggunakan RODC untuk domain yang diperluas, tetapi pastikan untuk mengizinkan caching kata sandi guna mempertahankan keuntungan ketersediaan dibandingkan dengan pola forest resource.
Langkah berikutnya
- Cari tahu selengkapnya tentang Microsoft AD Terkelola.
- Tinjau praktik terbaik untuk men-deploy forest resource Active Directory di Google Cloud.
- Pelajari cara men-deploy lingkungan Active Directory fault-tolerant ke Google Cloud.
- Tinjau praktik terbaik tentang desain VPC kami.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.