Dokumen ini membahas persyaratan yang harus dipertimbangkan jika Anda akan men-deploy Active Directory ke Google Cloud serta 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 campuran), 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 untuk menggunakan Active Directory untuk mengelola server Windows di Google Cloud atau jika Anda mengandalkan protokol yang tidak didukung oleh Google Cloud.
Sebelum Anda men-deploy Active Directory ke Google Cloud, pertama-tama Anda harus menentukan manakah domain dan arsitektur forest yang akan digunakan dan cara Anda mengintegrasikannya dengan forest Active Directory yang sudah ada.
Menilai kebutuhan
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 dengan resource 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 di dalam batas kepercayaan tersebut harus dianggap sebagai 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 pilihan 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.
Pada tingkat jaringan, Anda dapat menerapkan model zero-trust dengan menggunakan aturan firewall untuk membatasi traffic dan log aliran 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 berhasil disusupi, penyerang mungkin dapat mencuri sandi, hash sandi, atau token Kerberos dari pengguna domain lain yang login di 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 perluasan Active Directory terhadap Google Cloud
Saat Anda merencanakan deployment ke Google Cloud yang membutuhkan Active Directory, Anda harus menentukan antara dua opsi untuk menyelaraskan deployment dengan zona keamanan Anda yang sudah 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 dengan zona yang sudah ada menggunakan Cloud VPN atau Cloud Interconnect.
Resource yang di-deploy di lokal dan di Google Cloud yang memiliki zona yang sama juga dapat memiliki forest Active Directory yang sama, sehingga tidak perlu men-deploy forest terpisah ke Google Cloud.
Sebagai contoh, pertimbangkan jaringan lama yang memiliki pengembangan jaringan perimeter dan jaringan perimeter produksi sebagai zona keamanan dengan forest Active Directory terpisah di setiap zona keamanan. Jika Anda memperluas zona keamanan ke Google Cloud, kemudian semua deployment di Google Cloud juga merupakan bagian dari salah satu dari dua zona keamanan ini, serta dapat menggunakan forest Active Directory yang sama.
Memperkenalkan zona keamanan baru. Memperluas zona keamanan bisa jadi tidak berlaku—baik karena Anda tidak ingin memperluas zona lebih lanjut, atau karena kebutuhan keamanan zona keamanan lama Anda tidak cocok dengan kebutuhan deployment Google Cloud Anda. Anda dapat memperlakukan Google Cloud sebagai zona keamanan tambahan.
Sebagai contoh, anggap lingkungan lokal yang memiliki jaringan perimeter, tetapi tidak membedakan antara workload pengembangan dan produksi. Untuk memisahkan workload ini di Google Cloud, Anda dapat membuat dua VPC Bersama dan menganggapnya sebagai zona keamanan baru. Kemudian, 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 dengan resource Google Cloud
Faktor kedua yang perlu dipertimbangkan ketika Anda memperluas Active Directory Anda ke Google Cloud adalah interaksi pengguna dan resource antara lokasi lokal dengan 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 menggunakan Active Directory di Google Cloud adalah untuk mengelola perangkat server Windows dan memungkinkan administrator login ke server ini, tingkat interaksi antar-lingkungan bersifat ringan:
- Kumpulan karyawan yang berinteraksi dengan resource di Google Cloud dibatasi hanya untuk staf administratif saja.
- Aplikasi yang di-deploy ke Google Cloud mungkin tidak berinteraksi dengan aplikasi lokal sama sekali atau mungkin melakukannya tanpa mengandalkan fasilitas autentikasi Windows seperti Kerberos dan NTLM.
Dalam skenario ringan, pertimbangkan untuk mengintegrasikan lokasi lokal dengan lingkungan Google Cloud dalam salah satu cara 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 mengelola kumpulan akun pengguna terpisah bagi administrator di forest 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 Anda disediakan oleh Sistem Informasi Sumber Daya Manusia (HRIS), Anda mungkin dapat menggunakan mekanisme serupa untuk menyediakan dan mengelola akun pengguna di forest Google Cloud. 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 antar lingkungan dapat dianggap lebih lemah, dengan menggunakan forest terpisah memungkinkan Anda untuk mengelola batas kepercayaan antara lingkungan lokal dengan Google Cloud 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 dihostingkan lokal.
- Aplikasi dapat menggunakan Kerberos atau NTLM untuk mengautentikasi dan berkomunikasi di batas lingkungan.
- Anda mungkin ingin mengizinkan karyawan menggunakan Integrated Windows Authentication (IWA) untuk mengautentikasi ke aplikasi web yang di-deploy di Google Cloud.
Dalam skenario sedang, mengoperasikan dua forest Active Directory yang tidak terhubung mungkin terlalu membatasi: Anda tidak dapat menggunakan Kerberos untuk mengautentikasi di kedua forest, serta menggunakan NTLM autentikasi pass-through yang mengharuskan Anda mempertahankan agar akun pengguna dan kata sandi agar tetap tersinkronisasi.
Dalam kasus ini, sebaiknya gunakan dua forest Active Directory dengan kepercayaan lintas forest.
Interaksi intensif
Workload tertentu meliputi deployment Infrastruktur Desktop Virtual (VDI), mungkin mewajibkan interaksi intensif antara resource lokal dengan 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 adalah untuk mempertimbangkan Anda memperluas Active Directory Anda ke Google Cloud merupakan otonomi administratif.
Jika Anda berencana untuk mendistribusikan workload di lokal dan Google Cloud, workload yang akan Anda jalankan di Google Cloud mungkin dapat sangat berbeda daripada workload yang Anda simpan di 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 otoritas untuk mengelola resource kepada tim dengan menggunakan administrasi delegasi 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 Anda pertimbangkan ketika Anda memperluas Active Directory ke Google 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, workload yang Anda deploy ke Google Cloud kemungkinan besar bergantung pada infrastruktur lainnya atau aplikasi yang berjalan secara lokal sehingga menjadikan konektivitas hybrid yang menjadikannya sangat tersedia.
Jika Anda men-deploy forest atau domain Active Directory terpisah ke Google Cloud dan Anda menggunakan kepercayaan untuk menghubungkannya ke Active Directory lokal, Anda menambahkan dependensi antara lingkungan Google Cloud dengan lokal Anda. Dependensi ini memiliki efek minimum pada ketersediaan.
Workload redundan
Apabila Anda menggunakan Google Cloud untuk memastikan keberlangsungan bisnis Anda, workload Anda di Google Cloud mencerminkan beberapa workload dalam lingkungan lingkungan lokal. 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 Cloud dan menggunakan kepercayaan untuk menghubungkannya dengan lokasi lokal Active Directory, Anda mungkin dapat membuat file dependensi yang menggugurkan tujuan dari penyiapan. Jika Active Directory lokal tidak tersedia, semua workload yang di-deploy di Google Cloud yang mengandalkan autentikasi lintas domain atau lintas forest juga dapat 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 lama ke Google Cloud. Dengan men-deploy pengontrol domain tambahan ke Google Cloud dan mereplikasi konten direktori antarlingkungan, Anda memastikan bahwa lingkungan tersebut 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 forest yang disinkronkan, Anda men-deploy forest Active Directory terpisah ke Google Cloud. Anda menggunakan forest ini untuk mengelola setiap resource yang di-deploy di Google Cloud serta akun pengguna yang dibutuhkan untuk mengelola resource ini.
Daripada membuat kepercayaan di antara forest baru dengan forest lama, forest lokal, Anda mensinkronkan akun. Jika Anda menggunakan HRIS sebagai sistem pemandu untuk mengelola akun pengguna, Anda dapat mengonfigurasi HRIS untuk menyediakan akun pengguna di forest Active Directory yang dihostingkan 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:
- Tujuan utama penggunaan Google Cloud Anda sesuai dengan salah satu pola deployment redundan, dan Anda ingin menghindari dependensi runtime antara lingkungan lokal dengan Google Cloud.
- Anda ingin mempertahankan batas kepercayaan antara lingkungan Active Directory lokal dengan lingkungan Active Directory yang dihostingkan Google Cloud—baik sebagai tindakan defense-in-depth atau karena Anda memberikan kepercayaan pada satu lingkungan lebih dari lingkungan lainnya.
- Anda memperkirakan adanya sedikit hingga tidak adanya interaksi antara Active Directory–resource terkelola lokal dan di Google Cloud.
- Jumlah akun pengguna yang Anda butuhkan dalam lingkungan Active Directory yang dihostingkan di Google Cloud sedikit.
Kelebihan:
- Dengan pola forest yang disinkron, 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 di antara jaringan lokal dan Google Cloud untuk mengoperasikan Active Directory.
- Active Directory yang dihosting ke Google Cloud tidak terpengaruh oleh pemadaman layanan di lingkungan lokal Anda Active Directory. 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 dihostingkan ke 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 forest resource, Anda men-deploy forest Active Directory terpisah ke Google Cloud. Anda memanfaatkan forest ini untuk mengelola setiap resource yang di-deploy ke Google Cloud serta kumpulan minimum akun pengguna administratif yang dibutuhkan untuk mengelola forest. Dengan menetapkan kepercayaan forest ke forest Active Directory lokal, Anda dapat memungkinkan pengguna dari forest lama Anda untuk mengautentikasi dan mengakses resource yang dikelola forest Active Directory yang dihostingkan di Google Cloud.
Jika perlu, Anda dapat mengembangkan pola ini menjadi topologi hub dan spoke dengan forest Active Directory Anda yang sudah ada di pusat, dan terhubung dengan banyak forest resource.
Pertimbangkan menggunakan pola forest resource jika satu atau beberapa hal berikut berlaku bagi Anda:
- Tujuan utama penggunaan Google Cloud Anda sesuai dengan salah satu pola pengembangan terdistribusi, dan dependensi antara lingkungan lokal Anda dengan Google Cloud tidak masalah.
- Anda ingin mempertahankan batas kepercayaan di antara lingkungan Active Directory lokal dengan forest Active Directory yang dihostingkan di Google Cloud baik bagi tindakan defense-in-depth atau karena Anda menganggap bahwa satu lingkungan lebih tepercaya daripada yang lain.
- Anda memperkirakan adanya interaksi tingkat menengah antara resource yang dikelola Active Directory di lokal, dan dengan yang ada di Google Cloud
- Anda memiliki banyak pengguna yang resource aksesnya di-deploy di Google Cloud—misalnya, ke aplikasi web yang menggunakan IWA untuk autentikasi.
Kelebihan:
- Pola forest resource memungkinkan Anda mempertahankan batas kepercayaan di 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 dihostingkan ke Google Cloud.
Praktik terbaik:
- Hubungkan dua forest Active Directory menggunakan kepercayaan searah sehingga Active Directory yang dihostingkan di Google Cloud mempercayai Active Directory Anda yang sudah ada, tidak berlaku sebaliknya.
- Gunakan autentikasi selektif untuk membatasi resource di Active Directory yang dihosting di Google Cloud sehingga pengguna dari Active Directory lokal diizinkan mengakses.
- Gunakan sambungan Dedicated Interconnect, Partner Interconnect, atau Cloud VPN redundan untuk memastikan konektivitas jaringan yang tersedia dengan baik antara jaringan lokal Anda dengan Google Cloud.
Domain yang diperluas
Pada pola Domain yang diperluas, Anda memperluas satu atau beberapa domain Active Directory Anda yang sudah ada di Google Cloud. Untuk setiap domain, Anda men-deploy satu atau lebih pengontrol domain di Google Cloud, yang dapat menyebabkan semua data domain serta katalog global direplikasi dan tersedia di Google Cloud. Dengan menggunakan lokasi terpisah Active Directory untuk subnet lokal dengan Google Cloud Anda, Anda memastikan bahwa klien berkomunikasi dengan pengontrol domain yang paling dekat dengan mereka.
Pertimbangkan untuk menggunakan pola domain yang diperluas jika satu atau beberapa hal berikut berlaku bagi Anda:
- Tujuan utama penggunaan Google CLoud Anda sesuai dengan salah satu pola deployment redundan, dan Anda ingin menghindari dependensi runtime antara lingkungan lokal dengan Google Cloud Anda.
- Anda memperkirakan adanya interaksi intensif antara resource Active Directory—terkelola di infrastruktur lokal dan di Google Cloud.
- Anda ingin mempercepat autentikasi untuk aplikasi yang mengandalkan LDAP untuk autentikasi.
Kelebihan:
- Active Directory yang dihosting ke Google Cloud tidak terpengaruh oleh pemadaman layanan di lingkungan lokal Anda Active Directory. Pola ini sangat cocok untuk kasus penggunaan kelangsungan bisnis atau skenario lain yang memerlukan ketersediaan tinggi.
- Anda dapat membatasi komunikasi antara jaringan lokal Anda dengan Google Cloud. Tindakan ini berpotensi menghemat bandwidth dan memperbaiki latensi.
- Semua konten katalog global direplikasi dengan Active Directory dan dapat diakses secara efisien dari resource yang dihosting di Google Cloud.
Praktik terbaik:
- Jika Anda mereplikasi semua domain, komunikasi antara jaringan lokal Anda dengan jaringan Google Cloud dibatasi terhadap replikasi Active Directory antar pengontrol domain. Jika Anda hanya mereplikasi subset domain forest Anda, server gabungan domain yang berjalan di Google Cloud mungkin masih perlu berkomunikasi dengan pengontrol domain dari domain non-replikasi. Pastikan aturan firewall yang berlaku pada komunikasi antara lokasi lokal dengan Google Cloud mempertimbangkan semua kasus yang relevan.
- Perlu diketahui bahwa replikasi di lokasi terjadi pada interval tertentu saja, sehingga pembaruan yang dilakukan pada platform pengontrol domain lokal ke Google Cloud hanya terjadi setelah penundaan (berlaku sebaliknya).
- Pertimbangkan untuk menggunakan pengontrol domain hanya baca (RODC) untuk mempertahankan salinan hanya baca dari data domain di Google Cloud, tetapi perhatikan bahwa ada pertukaran yang terkait dengan caching kata sandi pengguna. Jika Anda mengizinkan RODC untuk menyimpan kata sandi Anda dalam cache dan mengisi otomatis cache kata sandi, resource yang di-deploy di Google Cloud dapat tetap tidak terkena dampak oleh pemadaman layanan pengontrol domain lokal. Namun, manfaat keamanan dari penggunaan RODC pada pengontrol domain biasa terbatas. Jika Anda menonaktifkan caching kata sandi, RODC yang telah disusupi mungkin hanya akan menimbulkan risiko terbatas terhadap Active Directory Anda, yang lain, tetapi Anda akan kehilangan manfaat bahwa Google Cloud tetap tidak terkena dampak oleh pemadaman layanan pengontrol domain lokal.
Forest yang diperluas
Dalam pola forest yang diperluas, Anda men-deploy domain Active Directory baru di Google Cloud, tetapi mengintegrasikannya ke dalam forest Anda yang sudah ada. Anda menggunakan domain baru untuk mengelola setiap resource yang di-deploy di Google Cloud dan untuk mempertahankan kumpulan akun pengguna administratif minimum untuk mengelola domain.
Dengan memperluas hubungan kepercayaan implisit ke domain lain dalam suatu forest, Anda mengaktifkan pengguna lama Anda dari domain lain untuk mengautentikasi dan mengakses resource yang dikelola oleh domain Active Directory yang dihosting di Google Cloud.
Pertimbangkan menggunakan pola forest yang diperluas jika satu atau lebih hal berikut berlaku bagi Anda:
- Tujuan penggunaan utama Google Cloud Anda sesuai dengan salah satu pola deployment terdistribusi, dan dependensi antara lingkungan lokal Anda dan Google Cloud dapat diterima.
- Resource yang akan di-deploy ke Google Cloud membutuhkan konfigurasi atau struktur domain yang berbeda dari yang diberikan oleh domain yang ada, atau Anda ingin memberikan otonomi administratif level tinggi bagi tim yang mengelola domain yang dihostingkan di Google Cloud .
- Anda memperkirakan adanya interaksi sedang hingga intensif antara resource yang dikelola Active Directory secara lokal dengan 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:
- Semua konten katalog global akan direplikasi ke Active Directory dan dapat diakses dari resource yang dihosting di Google Cloud secara efektif.
- Traffic replikasi antara jaringan lokal Anda dengan Google Cloud terbatas pada 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 di Google Cloud.
Praktik terbaik:
- Gunakan sambungan Dedicated Interconnect, Partner Interconnect, atau Cloud VPN untuk memastikan konektivitas jaringan tersedia dengan baik antara jaringan lokal Anda dengan Google Cloud.
Resource forest dengan domain yang diperluas
Pola forest resource dengan domain yang diperluas merupakan ekstensi dari pola forest resource. Pola forest resource memungkinkan Anda mempertahankan batas kepercayaan di antara lingkungan dan menyediakan 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 diletakkan di Google Cloud, sehingga Anda dapat memastikan bahwa pengguna dapat mengautentikasi ke resource yang dihosting di Google Cloud bahkan jika pengontrol domain lokal tidak tersedia atau konektivitas jaringan terputus.
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 pemadaman layanan pengontrol domain lokal atau terputusnya konektivitas jaringan ke lingkungan lokal Anda agar tidak memengaruhi workload Anda yang dihosting di Google Cloud
- Anda memperkirakan adanya interaksi sedang di antara resource lokal yang dikelola Active Directory dengan Google Cloud.
- Anda memiliki banyak pengguna dari satu domain Active Directory yang membutuhkan akses ke resource yang di-deploy di Google Cloud–misalnya, ke aplikasi web yang menggunakan IWA untuk autentikasi.
Kelebihan:
- Resource yang dihosting di Google Cloud tidak terkena dampak dari pemadaman layanan Active Directory lokal Anda. Pola ini sangat sesuai untuk kasus penggunaan keberlangsungan bisnis atau skenario lain yang membutuhkan ketersediaan tinggi.
- Pola ini memungkinkan Anda mempertahankan batas kepercayaan di 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 di antara jaringan lokal Anda dengan jaringan Google Cloud dibatasi dengan replikasi Active Directory di 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 dihostingkan ke Google Cloud.
- Anda dapat menggunakan Microsoft AD Terkelola untuk forest resource.
Praktik terbaik:
- Deploy pengontrol domain untuk domain yang diperluas ke dalam project Google Cloud dan VPC terpisah untuk memisahkan komponen ini dari komponen resource forest.
- Gunakan VPC peering 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 dua forest Active Directory menggunakan kepercayaan searah sehingga Active Directory yang dihostingkan di Google Cloud mempercayai forest Active Directory Anda yang sudah ada, tetapi tidak berlaku sebaliknya.
- Gunakan autentikasi selektif untuk membatasi resource dalam forest resource di mana pengguna dari forest lain diizinkan untuk mengakses.
- Perlu diketahui bahwa replikasi di lokasi terjadi pada interval tertentu saja, sehingga pembaruan yang dilakukan pada platform pengontrol domain lokal ke Google Cloud hanya terjadi setelah penundaan(berlaku 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 men-deploy forest resource Active Directory di Google Cloud.
- Pelajari cara men-deploy lingkungan Active Directory yang bersifat 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.