Panduan ini menyajikan praktik terbaik untuk menjalankan Active Directory di Google Cloud. Panduan ini berfokus pada praktik yang spesifik untuk Google Cloud atau yang sangat penting saat men-deploy Active Directory di Google Cloud. Pertimbangkan panduan ini sebagai pelengkap praktik terbaik umum untuk mengamankan Active Directory yang dipublikasikan oleh Microsoft.
Arsitektur
Bagian berikut menjelaskan praktik terbaik terkait arsitektur.
Menggunakan pola arsitektur yang paling sesuai dengan kebutuhan Anda
Untuk men-deploy Active Directory di Google Cloud, Anda harus terlebih dahulu memutuskan domain dan arsitektur forest mana yang akan digunakan. Jika sudah menggunakan Active Directory, Anda juga harus memutuskan apakah akan mengintegrasikan kedua lingkungan tersebut dan caranya.
Penentuan desain mana yang paling sesuai dengan situasi Anda bergantung pada sejumlah faktor, termasuk desain jaringan lokal Anda, cara resource Google Cloud dan lokal berinteraksi, serta persyaratan untuk ketersediaan dan otonomi administratif. Lihat pola kami dalam menggunakan Active Directory di lingkungan hybrid untuk melihat bagaimana faktor-faktor ini akan menentukan desain Anda.
Jika Anda ingin mempertahankan batas kepercayaan antara Google Cloud dan lingkungan lokal Anda, pertimbangkan untuk menerapkan pola forest resource. Dalam pola ini, Anda akan men-deploy forest terpisah di Google Cloud dan menggunakan kepercayaan forest satu arah untuk mengintegrasikan forest Google Cloud dengan forest Active Directory lokal Anda yang sudah ada.
Pengujian dan produksi terpisah
Bergantung pada penggunaan Active Directory, Anda mungkin perlu sering melakukan perubahan pada Active Directory selama pengembangan dan pengujian aplikasi. Developer mungkin perlu dapat membuat dan mengubah akun Active Directory, mengubah keanggotaan grup jika aplikasi menggunakan grup untuk menangani otorisasi, atau bergabung dan menghapus komputer.
Agar tugas pengembangan dan pengujian tidak memengaruhi workload produksi atau menghambat keamanan deployment Anda, coba deploy domain atau forest Active Directory terpisah untuk pengembangan dan pengujian.
Dengan memiliki domain atau forest pengujian dan pengembangan terpisah, Anda dapat memverifikasi perubahan administratif sebelum menerapkannya pada produksi. Contoh perubahan tersebut mencakup eksperimen dengan kebijakan grup, pengujian skrip otomatisasi, atau tindakan yang berpotensi berisiko seperti memperbesar tingkat fungsional forest.
Menyiapkan penggabungan Cloud Identity selain men-deploy Active Directory di Google Cloud
Dengan men-deploy Active Directory di Google Cloud, Anda dapat mengelola VM Windows di Google Cloud, sehingga pengguna dapat login ke VM Windows menggunakan akun pengguna yang ada, dan mendukungaplikasi yang bergantung pada Kerberos, NTLM, atau LDAP untuk autentikasi.
Namun, untuk menggunakan konsol Google Cloud, alat command line gcloud, atau alat Google dan Google Cloud lainnya, Anda harus melakukan autentikasi dengan identitas Google. Oleh karena itu, men-deploy Active Directory di Google Cloud bukanlah pengganti untuk menggabungkan Active Directory yang ada dengan Google Cloud jika Anda ingin menggunakan Active Directory sebagai sistem terdepan untuk mengelola pengguna.
Misalnya, jika men-deploy forest terpisah di Google Cloud, Anda dapat menyiapkan penggabungan dengan Active Directory lokal seperti yang ditunjukkan oleh diagram berikut. Lalu, pengguna yang memiliki akun di Active Directory lokal dapat menggunakan alat yang memerlukan identitas Google serta aplikasi yang mengandalkan Active Directory untuk autentikasi.
Jika memutuskan untuk memperluas forest yang ada atau domain ke Google Cloud, Anda juga memiliki opsi untuk menggunakan pengontrol domain dan server AD FS yang di-deploy di Google Cloud untuk menyiapkan penggabungan.
Penggabungan juga memungkinkan Anda menerapkan siklus proses umum untuk Akun Google dan Akun Active Directory, sehingga saat Anda menonaktifkan akun pengguna di Active Directory lokal, pengguna Google terkait juga ditangguhkan.
Networking
Bagian berikut menjelaskan praktik terbaik terkait jejaring.
Men-deploy Active Directory ke jaringan VPC Bersama
Agar Active Directory dapat digunakan di beberapa project, deploy pengontrol domain ke dalam jaringan VPC Bersama. Penggunaan jaringan VPC Bersama memiliki beberapa keuntungan:
Setiap aplikasi yang mungkin memerlukan akses Active Directory berpotensi di-deploy ke project terpisah. Dengan menggunakan project terpisah membantu memisahkan resource dan memungkinkan Anda mengelola akses satu per satu.
Anda dapat menggunakan project khusus untuk pengontrol domain Active Directory, sehingga Anda dapat mengontrol pengguna mana yang dapat mengakses resource Google Cloud terkait secara terperinci.
Dengan jaringan VPC bersama, Anda dapat memusatkan pengelolaan alamat IP dan konfigurasi firewall, sehingga membantu memastikan konsistensi di berbagai project.
Karena VPC merupakan resource global, Anda dapat menggunakan jaringan VPC Bersama yang sama di beberapa region.
Jangan mengekspos pengontrol domain secara eksternal
Untuk mengurangi permukaan serangan Active Directory, hindari menetapkan alamat IP eksternal ke pengontrol domain.
Karena instance VM tanpa alamat IP eksternal tidak memiliki akses internet secara default, Anda perlu mengambil langkah tambahan untuk memastikan bahwa aktivasi Windows dan update Windows tidak terganggu pada pengontrol domain.
Untuk mendukung aktivasi Windows, aktifkan Akses Google Pribadi di subnet tempat Anda akan men-deploy pengontrol domain, dan pastikan instance VM dapat mengakses kms.windows.googlecloud.com. Langkah ini memungkinkan aktivasi terjadi tanpa akses internet langsung.
Ada beberapa opsi untuk mendukung update Windows:
Jika memiliki server WSUS lokal, Anda dapat mengonfigurasi konektivitas hybrid dan mengonfigurasi pengontrol domain untuk menggunakan server WSUS sebagai sumber update.
Anda dapat mengaktifkan akses internet melalui gateway NAT dengan men-deploy Cloud NAT.
Jika telah menyiapkan konektivitas campuran, Anda juga dapat mengarahkan traffic keluar melalui gateway NAT lokal atau server proxy.
Mereservasi alamat IP statis untuk pengontrol domain terlebih dahulu
Karena pengontrol domain berfungsi sebagai server DNS, pengontrol domain tersebut perlu diberikan alamat IP yang tidak berubah. Untuk mencapainya, konfigurasikan alamat IP internal statis untuk VM pengontrol domain.
Saat Anda mereservasi alamat IP, perilaku defaultnya adalah alamat yang tidak digunakan akan dipilih secara otomatis. Untuk memastikan alamat IP pengontrol domain mudah diingat, reservasi alamat IP statis internal.
Di pengontrol domain, tetapkan alamat IP adaptor jaringan ke alamat yang sama. Meskipun bersifat opsional, langkah ini mencegah Active Directory memunculkan pesan peringatan yang menunjukkan bahwa alamat IP mesin mungkin masih ditetapkan secara dinamis.
Men-deploy pengontrol domain di beberapa zona
Untuk meningkatkan ketersediaan, deploy minimal dua pengontrol domain dan distribusikan di beberapa zona. Karena subnet dan alamat IP tidak terikat dengan zona, Anda dapat men-deploy semua pengontrol domain ke dalam satu subnet.
Jika Anda berencana untuk men-deploy workload di beberapa region, pertimbangkan untuk men-deploy pengontrol domain di setiap region yang relevan. Karena subnet merupakan resource regional, deployment ke region tambahan akan memerlukan subnet tambahan.
Membuat satu situs per region
Saat klien mencoba menemukan pengontrol domain, pertama-tama klien akan mencari pengontrol domain di situs Active Directory yang sesuai dengan alamat IP klien. Jika tidak ada pengontrol domain yang tersedia di situs ini, klien akan melanjutkan dan mencoba menemukan pengontrol domain di situs yang berbeda.
Anda dapat memanfaatkan perilaku ini dengan membuat situs terpisah untuk setiap region tempat Anda men-deploy pengontrol domain atau klien domain. Selanjutnya, klien akan otomatis lebih memilih menggunakan pengontrol domain yang terletak di region yang sama, yang dapat membantu mengurangi latensi dan biaya transfer data keluar antar-region.
Jika memiliki klien di region yang tidak memiliki pengontrol domain, Anda dapat memengaruhi pengontrol domain mana yang dipilih klien ini dengan menyesuaikan biaya link situs untuk mencerminkan kedekatan geografis region dan mengaktifkan setelan Try Next Closest Site.
Penggunaan beberapa situs akan memengaruhi perilaku replikasi di antara pengontrol domain. Satu kelemahan dari penggunaan beberapa situs adalah replikasi antar-situs lebih jarang terjadi daripada replikasi intra-situs.
Namun, Anda tidak dapat membuat situs Active Directory di Microsoft AD yang Terkelola karena Microsoft AD yang Terkelola tidak mendukung fitur Situs dan Layanan Active Directory.
Menggunakan zona penerusan pribadi Cloud DNS
Saat Anda membuat instance VM baru di Compute Engine, sistem operasi akan dikonfigurasi terlebih dahulu untuk menggunakan server DNS default yang menyediakan akses ke DNS internal dan DNS publik.
Sebelum dapat menggabungkan mesin ke domain Active Directory, Anda harus memastikan bahwa mesin tersebut dapat me-resolve data DNS yang dikelola oleh Active Directory. Server DNS default yang dikonfigurasi Compute Engine untuk instance VM menyediakan akses ke DNS internal dan DNS publik, tetapi tidak akan dapat me-resolve nama DNS yang dikelola oleh Active Directory.
Buat zona penerusan DNS pribadi di Cloud DNS sehingga klien dapat me-resolve data DNS yang dikelola oleh Active Directory. Konfigurasikan zona untuk meneruskan kueri yang cocok dengan domain Active Directory ke pengontrol domain Anda.
Penggunaan zona penerusan DNS pribadi memiliki beberapa keuntungan dibandingkan mengonfigurasi klien untuk menggunakan pengontrol domain Active Directory sebagai server DNS secara langsung:
Anda tidak perlu menyesuaikan konfigurasi jejaring instance VM. Langkah ini akan menyederhanakan proses pembuatan VM baru.
Saat mempromosikan atau mendemosikan pengontrol domain, Anda hanya perlu memperbarui konfigurasi zona penerusan DNS pribadi dan tidak perlu mengubah setelan klien apa pun.
Instance VM masih memiliki akses ke DNS internal.
Semua data DNS yang tidak cocok dengan domain Active Directory Anda akan ditangani oleh Cloud DNS, sehingga mengurangi beban pada pengontrol domain Anda.
Jika Anda menggunakan beberapa domain, buat zona penerusan DNS pribadi yang terpisah untuk setiap domain Active Directory.
Zona penerusan pribadi Cloud DNS tercakup dalam satu VPC. Jika menggunakan beberapa VPC yang terhubung melalui peering, Anda dapat mengekspos zona penerusan pribadi ke VPC lain dengan mengonfigurasi peering DNS.
Anda masih harus mengonfigurasi setelan DNS pada pengontrol domain secara manual. Gunakan 127.0.0.1 sebagai server DNS utama dan, secara opsional, gunakan alamat IP pengontrol domain lain sebagai server DNS sekunder. Untuk mengetahui informasi selengkapnya, lihat Setelan DNS dan opsi alternatif yang direkomendasikan.
Konektivitas Hybrid
Bagian berikut menjelaskan praktik terbaik terkait konektivitas hybrid.
Menggunakan penerusan masuk DNS untuk me-resolve nama Google Cloud DNS dari infrastruktur lokal
Klien di jaringan lokal Anda mungkin harus me-resolve nama DNS dari resource yang di-deploy di Google Cloud. Jika Anda memperluas forest atau men-deploy forest resource di Google Cloud, gunakan penerusan masuk DNS agar klien lokal dapat mencari data DNS untuk resource yang di-deploy di Google Cloud. Untuk menggunakan penerusan masuk, buat kebijakan server DNS untuk mengalokasikan alamat IP penerusan masuk dan buat alamat ini dapat diakses oleh jaringan lokal.
Jika domain DNS yang digunakan di Google Cloud (misalnya, cloud.example.com) adalah subdomain dari domain DNS yang digunakan di infrastruktur lokal (misalnya, example.com), siapkan delegasi DNS. Buat data NS di domain lokal yang mengarah ke alamat IP penerusan masuk. Data NS menyebabkan klien yang mencoba mencari nama DNS di domain yang dihosting Google Cloud dialihkan ke alamat IP penerusan masuk.
Jika domain DNS yang digunakan di Google Cloud dan Active Directory lokal Anda berbeda (misalnya, cloud.example.com dan corp.example.com), konfigurasi penerusan DNS bersyarat di server lokal Anda domain lokal dan menggunakan alamat IP penerusan masuk sebagai target. Saat diminta untuk me-resolve nama DNS di domain yang dihosting Google Cloud, pengontrol domain lokal akan meneruskan quest ke alamat IP penerusan masuk.
Saat menggunakan penerusan DNS masuk, pastikan firewall Anda dikonfigurasi dengan tepat.
Penerusan masuk DNS tidak diperlukan jika Anda memperluas domain yang ada ke Active Directory. Dalam skenario ini, semua data DNS domain akan otomatis direplikasi di Google Cloud dan lingkungan lokal Anda, serta dapat dicari di kedua lingkungan tersebut.
Menggunakan penerusan keluar DNS untuk me-resolve nama DNS lokal dari Google Cloud
Klien yang berjalan di Google Cloud mungkin perlu me-resolve nama resource yang di-deploy secara lokal. Jika Anda memperluas forest atau men-deploy forest resource di Google Cloud, buat zona penerusan pribadi di Cloud DNS untuk meneruskan kueri DNS pada domain lokal ke server DNS lokal Anda.
Saat menggunakan penerusan DNS keluar, pastikan firewall Anda dikonfigurasi dengan benar.
Penerusan keluar DNS tidak diperlukan jika Anda memperluas domain yang ada ke Active Directory. Dalam skenario ini, semua data DNS domain akan otomatis direplikasi di seluruh Google Cloud dan lingkungan lokal Anda, dan dapat dicari di kedua lingkungan tersebut.
Menggunakan tunnel VPN untuk mengamankan traffic LDAP
Active Directory memanfaatkan protokol LDAP secara ekstensif. Tidak seperti kebanyakan protokol lain yang digunakan oleh Active Directory, LDAP tidak dienkripsi secara default.
Google Cloud memastikan bahwa traffic antara virtual machine dienkripsi, sehingga Anda dapat menggunakan LDAP yang tidak dienkripsi dalam VPC. Jika Anda menghubungkan VPC ke jaringan lokal, pastikan traffic LDAP hanya ditukarkan melalui saluran tepercaya.
Jika Anda menggunakan Cloud VPN untuk menghubungkan Google Cloud dan jaringan lokal Anda, traffic akan otomatis dienkripsi menggunakan IPsec antara Google Cloud dan endpoint VPN lokal Anda.
Cloud Interconnect dan Partner Interconnect tidak menyediakan enkripsi. Untuk memastikan komunikasi yang aman, buat tunnel VPN melalui koneksi Interconnect dengan menggunakan perangkat VPN dari Google Cloud Marketplace.
Menggunakan autentikasi selektif dan AES untuk kepercayaan forest
Saat menciptakan hubungan kepercayaan antara forest Active Directory, pilih kepercayaan forest daripada kepercayaan eksternal dan manfaatkan fitur berikut untuk meningkatkan keamanan:
Aktifkan autentikasi selektif pada kepercayaan eksternal di forest resource. Autentikasi selektif memastikan bahwa pengguna dari forest organisasi tidak dapat mengakses resource di forest resource kecuali jika izin diberikan secara eksplisit.
Aktifkan penerapan batas forest untuk delegasi penuh Kerberos pada kepercayaan internal di forest organisasi. Fitur ini membantu mencegah serangan eskalasi akses dengan melarang resource di forest resource untuk meminta Tiket Autentikasi (TGT) dari pengguna di forest organisasi.
Aktifkan opsi Domain lain mendukung enkripsi AES Kerberos saat menciptakan kepercayaan. Opsi ini memastikan tiket yang digunakan untuk autentikasi lintas forest dienkripsi menggunakan AES, alih-alih algoritma RC4 yang kurang aman.
Keamanan
Bagian berikut menjelaskan praktik terbaik terkait keamanan.
Menghindari keamanan Google Cloud mengganggu keamanan Active Directory
Active Directory memberi Anda kontrol terperinci atas pengguna mana yang diizinkan untuk mengakses resource tertentu. Saat mesin di-deploy sebagai instance VM di Compute Engine dan pengguna memiliki akses ke project Google Cloud pokok, Anda harus mempertimbangkan jalur tambahan yang mungkin mengizinkan pengguna mengakses mesin:
Anggota project yang telah diberi peran Compute Instance Admin di project Google Cloud dapat menggunakan fungsi reset sandi untuk membuat akun administrator lokal. Akun administrator lokal menimbulkan ancaman bagi keamanan domain Active Directory karena dapat digunakan untuk merusak kebijakan grup atau menginstal software berbahaya yang mungkin mengambil kredensial domain pengguna lain.
Dengan menambahkan skrip startup, anggota project yang memiliki hak istimewa dapat memasukkan kode berbahaya ke dalam VM yang dijalankan sebagai
nt authority\systemsaat mesin dimulai ulang.Dengan menggunakan konsol serial, anggota project yang memiliki hak istimewa juga dapat mengakses Windows Special Administration Console (SAC). Windows menganggap login melalui SAC sebagai login lokal. Oleh karena itu, SAC dapat disalahgunakan untuk menghindari kebijakan yang menolak login melalui RDP, tetapi melewatkan penolakan login lokal.
Anggota project yang memiliki hak istimewa dapat menggunakan SAC untuk memberikan perintah
crashdump, yang dapat menyebabkan dump memori ditulis ke disk. Dump memori tersebut mungkin mencakup informasi sensitif dan kredensial.Dengan memasang persistent disk ke VM lain atau menggunakan snapshot, anggota project yang memiliki hak istimewa mungkin dapat mengakses isi disk, yang berpotensi menyertakan dump memori, dari mesin yang tidak mengizinkan login dari pengguna yang tidak memiliki izin.
Saat menggunakan Microsoft AD yang Terkelola, Anda secara default lebih terlindungi terhadap jalur akses tambahan ini. Layanan ini tidak mengizinkan pengguna dengan hak istimewa di project Anda untuk mereset sandi Administrator Domain, menjalankan skrip startup, atau mengakses konsol serial di VM pengontrol domain AD.
Untuk mengurangi risiko ini lebih lanjut, pastikan izin IAM project yang berisi instance VM yang bergabung dengan domain dikelola berdasarkan hak istimewa terendah. Anda dapat mengurangi risiko lebih lanjut berdasarkan pengguna kebijakan organisasi, kebijakan grup, dan shielded VM:
Gunakan kebijakan organisasi untuk menonaktifkan akses port serial.
Terapkan kebijakan grup yang mencegah pembuatan akun administrator lokal dengan menonaktifkan pengelola akun. Tentukan preferensi IN I Files di kebijakan grup Anda (Computer Configuration > Preferences > Windows Settings > Ini Files) untuk menerapkan setelan berikut:
- Tindakan: Memperbarui
- Jalur File:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - Nama Bagian:
accountManager - Nama Properti:
disable - Nilai Properti:
true
Terapkan kebijakan grup yang menghapus akun administrator lokal dari instance VM. Gunakan fungsi Local Users and Groups (Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups) untuk menghapus keanggotaan grup dari grup Administrators dan grup sensitif lainnya.
Pertimbangkan untuk menggunakan shielded VM yang dipadukan dengan enkripsi disk BitLocker agar persistent disk atau snapshot tidak dapat dibaca oleh pengguna yang tidak sah.
Menghindari keamanan Active Directory mengganggu keamanan Google Cloud
Dalam domain Active Directory, mesin memercayai pengontrol domain untuk menangani autentikasi dan otorisasi atas namanya. Kecuali jika dibatasi oleh kebijakan grup, kebijakan keamanan lokal mesin, atau autentikasi selektif, pengguna yang telah berhasil membuktikan identitasnya ke salah satu pengontrol domain diizinkan untuk login ke mesin mana pun di domain tersebut.
Kemampuan pengguna Active Directory untuk login ke mesin apa pun mungkin membuat penyerang melakukan gerakan lateral dalam domain. Gerakan lateral tersebut dapat menyebabkan eskalasi hak istimewa jika beberapa instance VM dikecualikan dari pembatasan firewall atau menggunakan akun layanan Google Cloud: Kredensial akun layanan dapat diakses oleh semua proses dan pengguna pada instance VM. Oleh karena itu, setiap pengguna yang dapat menggunakan Active Directory untuk login ke suatu mesin bisa mengakses kredensial akun layanan ini untuk memperoleh akses ke resource Google Cloud apa pun yang aksesnya diberikan kepada akun layanan.
Saat menyiapkan Microsoft AD yang Terkelola, layanan tersebut akan membuat grup untuk memudahkan pengguna tertentu dalam mengizinkan RDP ke VM yang bergabung dengan domain.
Untuk mengurangi risiko gerakan lateral, atur pengguna menjadi tingkat administratif dan gunakan opsi Deny access to this computer from the network dan Deny logon through Remote Desktop Services untuk membatasi akses ke VM Anda berdasarkan level tingkat.
Dalam topologi forest resource, manfaatkan autentikasi selektif tambahan untuk lebih membatasi sekumpulan pengguna dari forest lain yang diizinkan untuk login ke VM Anda. Anda dapat menyederhanakan pengelolaan izin autentikasi selektif dengan menyelaraskan struktur resource Google Cloud dan Active Directory: Jika unit organisasi Active Directory dipetakan ke project Google Cloud, Anda dapat memberi pengguna hak untuk melakukan autentikasi di tingkat yang cocok dengan project Google Cloud.
Jika autentikasi selektif atau kebijakan grup tidak berlaku, buat akun layanan terpisah, ekspor kunci akun layanan, simpan kunci tersebut ke disk lokal instance VM atau fitur berbagi file, dan lindungi file tersebut menggunakan NTFS ACL, sehingga hanya pengguna Active Directory yang diizinkan yang dapat membaca dan menggunakan kunci tersebut.
Menggunakan project khusus untuk pengontrol domain
Pengontrol domain memainkan peran penting dalam keamanan domain Active Directory dan penyusupan pengontrol domain tunggal dapat menimbulkan seluruh forest Active Directory Anda disusupi.
Untuk membatasi risiko akses yang tidak sah, gunakan project Google Cloud terpisah untuk men-deploy pengontrol domain dan memberikan akses ke project ini berdasarkan hak istimewa terendah. Saat membuat project, perhatikan bahwa beberapa izin mungkin diwarisi dari folder induk. Untuk menghindari pemberian akses secara tidak sengaja melalui pewarisan, sebaiknya buat project di luar hierarki folder Anda yang biasa.
Saat mengonfigurasi kebijakan IAM untuk project, perhatikan dengan saksama pembatasan akses ke instance VM, persistent disk yang berisi database ntds.dit, serta lokasi penyimpanan apa pun yang mungkin berisi cadangan.
Selain menggunakan kebijakan IAM untuk membatasi akses ke project, lindungi project dari penghapusan yang tidak disengaja.
Menggunakan VM dan project terpisah untuk mengelola Active Directory
Untuk mengelola Active Directory, Anda harus dapat menggunakan alat seperti Active Directory Users and Computers atau Active Directory Administrative Center. Alat ini mengharuskan Anda login menggunakan akun domain dengan hak istimewa, yang membuat mesin tempat Anda menjalankan alat ini menjadi sasaran empuk untuk pencurian kredensial atau keylogging.
Untuk meminimalkan risiko penyerang mendapatkan kredensial domain yang memiliki hak istimewa, gunakan instance VM khusus untuk administrasi domain dan tangani VM pengelolaan tersebut, seperti workstation akses dengan hak istimewa:
Gunakan kebijakan grup untuk memastikan bahwa hanya sebagian pengguna tertentu yang berhak login ke VM pengelolaan. Jika Anda menerapkan administrasi bertingkat, grup pengguna ini akan sesuai dengan Tingkat 0.
Sama halnya dengan pengontrol domain, VM administratif dapat berisiko menimbulkan pembuatan akun administrator lokal, login melalui konsol serial, atau penyalahgunaan persistent disk mereka oleh anggota project. Untuk membatasi risiko akses yang tidak sah, gunakan project Google Cloud terpisah untuk VM administratif dan berikan akses ke project ini berdasarkan hak istimewa terendah.
Jika Anda berencana untuk mengakses VM administratif dari jaringan lokal dengan menggunakan konektivitas hybrid, deploy VM administratif ke dalam subnet VPC khusus. Dengan subnet yang khusus menangani pengelolaan VM, Anda dapat membedakan antara VM administratif dan VM lain saat mengonfigurasi firewall lokal dengan lebih baik. Jika Anda menggunakan VPC Bersama, gunakan izin tingkat subnet untuk memastikan bahwa hanya administrator dengan hak istimewa yang diizinkan untuk men-deploy instance VM ke dalam subnet pengelolaan. Praktik ini membantu memastikan bahwa jika firewall lokal menerapkan aturan yang berbeda untuk VM pengelolaan dibandingkan dengan VM lain, pengguna tidak dapat menghindari aturan firewall dengan menempatkan VM non-pengelolaan ke dalam subnet pengelolaan.
Selain itu, pertimbangkan untuk membatasi kebijakan grup yang mengelola pembatasan login untuk VM pengelolaan ke subnet pengelolaan. Praktik ini menerapkan penyelarasan antara pembatasan login (berdasarkan kebijakan grup) dan aturan firewall (berdasarkan subnet/alamat IP).
Selain menggunakan kebijakan IAM untuk membatasi akses ke project, lindungi project dari penghapusan yang tidak disengaja.
Menggunakan aturan firewall untuk mengamankan pengontrol dan server domain
Pengontrol domain menampilkan sejumlah layanan, termasuk LDAP, DNS, Kerberos, dan RPC. Bergantung pada kasus penggunaan Anda, VM yang di-deploy di Google Cloud, serta mesin yang berjalan secara lokal, mungkin memerlukan akses ke sebagian layanan yang berbeda ini untuk memanfaatkan Active Directory.
Saat menggunakan Microsoft AD yang Terkelola, pengontrol domain AD di-deploy dalam project tenant khusus. Jaringan yang menghosting pengontrol domain AD otomatis dilindungi dengan aturan firewall khusus AD yang telah melalui proses hardening.
Untuk mengurangi permukaan serangan pengontrol domain dan VM Anda, gunakan firewall untuk melarang komunikasi jaringan apa pun yang tidak terlalu dibutuhkan. Baca panduan kami tentang cara menggunakan Active Directory di seluruh firewall untuk mengetahui detail tentang konfigurasi firewall yang diperlukan untuk mengakses Active Directory dari dalam VPC Anda atau dari jaringan lokal.
Mengelola resource dan pengguna Active Directory ke dalam tingkat administratif
Beberapa mesin di forest Active Directory lebih penting untuk keamanan keseluruhan Active Directory dibandingkan mesin lain. Pengontrol domain dan VM administratif adalah dua contoh mesin yang sangat penting, sehingga sangat sensitif terhadap potensi serangan.
Untuk mengidentifikasi seberapa penting setiap mesin, gunakan taksonomi tingkat. Meskipun jumlah tingkat yang tepat bergantung pada konfigurasi spesifik, Anda dapat memulai dengan membedakan tiga tingkat:
Tingkat 0 (Sangat penting): Tingkat ini mencakup semua mesin yang sangat penting bagi keamanan forest Active Directory Anda. Setelah satu mesin tingkat 0 disusupi, Anda harus mengasumsikan seluruh forest Anda telah disusupi.
Tingkat 1 (Penting): Tingkat ini mencakup sebagian besar server di lingkungan Anda, termasuk server aplikasi dan server database. Server tingkat 1 yang disusupi mungkin memiliki dampak bisnis yang signifikan, tetapi tidak menimbulkan ancaman langsung bagi seluruh forest.
Tingkat 2 (Normal): Tingkat ini mencakup workstation atau mesin tujuan umum lainnya. Penyusupan mesin tingkat 2 diperkirakan akan memiliki dampak terbatas pada bisnis dan keamanan secara keseluruhan.
Meskipun dampak langsung dari mesin tingkat 2 yang disusupi mungkin tampak terbatas, ada risiko efek akses: Saat pengguna yang memiliki akses administratif ke mesin tingkat 0 atau tingkat 1 dipancing untuk login ke komputer tingkat 2 yang disusupi, pengguna tersebut mungkin menjadi korban keylogger atau bentuk pencurian kredensial lainnya. Kredensial yang diambil kemudian dapat digunakan untuk menyerang mesin tingkat tinggi, yang menyebabkan dampak keseluruhan meningkat.
Untuk menghindari efek kumulatif tersebut, pastikan untuk tidak hanya mengategorikan mesin, tetapi juga akun pengguna, dan membatasi sekumpulan mesin mana yang dapat diakses oleh pengguna tersebut:
Tingkat 0 (Sangat penting): Pengguna yang memiliki akses ke mesin tingkat 0.
Tingkat 1 (Penting): Pengguna yang memiliki akses ke mesin tingkat 1.
Tingkat 2 (Normal): Pengguna yang memiliki akses ke komputer tingkat 2.
Gunakan tabel berikut sebagai panduan agar pengguna dapat mengakses resource:
| Grup | Tingkat | Akses domain | Akses komputer tingkat 0 | Akses komputer Tingkat 1 | Akses komputer Tingkat 2 |
|---|---|---|---|---|---|
| Administrator Active Directory | 0 | Administrator | Pengguna terbatas | Diblokir | Diblokir |
| Administrator server pengelolaan | 0 | Pengguna terbatas | Administrator | Diblokir | Diblokir |
| Administrator server | 1 | Pengguna terbatas | Diblokir | Administrator | Diblokir |
| Administrator workstation VDI | 2 | Pengguna terbatas | Diblokir | Diblokir | Administrator |
| Pengguna workstation VDI | 2 | Pengguna terbatas | Diblokir | Diblokir | Pengguna terbatas |
Baca dokumentasi Microsoft untuk mengetahui detail lebih lanjut dan praktik terbaik tentang cara menerapkan model tingkat administratif di Active Directory.
Saat Anda menggunakan model tingkat administratif di forest Active Directory, pastikan integritasnya tidak terganggu oleh hubungan kepercayaan forest. Jika forest tepercaya juga menerapkan model administrasi bertingkat, gunakan autentikasi selektif untuk memastikan bahwa pengguna dari forest tepercaya hanya diizinkan untuk mengakses resource dalam tingkat yang sama:
Jika forest tepercaya tidak mengimplementasikan administrasi bertingkat, petakan forest tepercaya ke tingkat tertentu dan gunakan autentikasi selektif untuk memastikan bahwa pengguna dari forest tepercaya hanya diizinkan untuk mengakses resource dari tingkat tertentu itu.
Menggunakan Kontrol Layanan VPC dan Akses Google Pribadi untuk host lokal
API Microsoft AD yang Terkelola mengizinkan reset sandi administrator dan eksekusi operasi sensitif lainnya. Untuk deployment produksi yang penting, sebaiknya aktifkan Kontrol Layanan VPC dan gunakan Akses Google Pribadi untuk host lokal guna meningkatkan keamanan.
Pengelolaan
Bagian berikut menjelaskan praktik terbaik terkait pengelolaan Active Directory.
Menyelaraskan struktur resource Google Cloud dan Active Directory
Saat men-deploy domain Active Directory atau forest baru di Google Cloud, Anda harus menentukan struktur unit organisasi (OU) untuk mengelola resource dengan domain Active Directory Anda. Alih-alih mendesain struktur yang sama sekali baru atau menerapkan struktur yang Anda gunakan di lingkungan lokal, buat struktur OU yang selaras dengan hierarki resource Google Cloud Anda:
Jika Anda menggunakan model administrasi bertingkat, OU tingkat teratas harus mencerminkan tingkat administratif Anda.
Untuk setiap tingkat, buat OU untuk pengguna dan grup. Jika Anda berencana untuk mengelola pengguna dan grup dalam jumlah besar, buat sub-OU yang sesuai.
Untuk setiap tingkat, buat OU
Projectsdan buat sub-OU untuk setiap project Google Cloud yang berisi resource Active Directory. Gunakan sub-OU khusus project untuk mengelola akun komputer, akun layanan, atau resource Active Directory lainnya yang sesuai dengan resource Google Cloud di project masing-masing. Pastikan ada pemetaan 1:1 antara OU dan project.
Diagram berikut menunjukkan contoh hierarki yang mengikuti prinsip-prinsip berikut:
Jika jumlah project yang berisi resource Active Directory dalam taraf sedang, Anda dapat membuat struktur OU tetap di bawah Projects OU. Jika Anda ingin mengelola sejumlah besar project dan telah merancang hierarki resource Google Cloud agar menggunakan beberapa tingkat folder, pertimbangkan untuk mencerminkan struktur folder ini di bawah OU Projects.
Penyelarasan struktur OU Active Directory dan hierarki resource Google Cloud memiliki beberapa keuntungan:
Saat mendelegasikan izin administratif ke project Google Cloud dengan menggunakan kebijakan IAM, Anda mungkin juga perlu memberikan hak istimewa tertentu kepada pengguna project di Active Directory. Misalnya, administrator Compute Engine mungkin perlu menggabungkan beberapa mesin ke domain berdasarkan OU tertentu. Dengan menyelaraskan OU dan project Google Cloud, Anda dapat memberikan izin tersebut pada tingkat perincian yang sama di Active Directory seperti di Google Cloud.
Jika Anda berencana menggunakan objek kebijakan grup (GPO) untuk mengelola komputer, struktur OU yang mencerminkan hierarki resource Google Cloud akan membantu Anda memastikan bahwa GPO diterapkan secara konsisten ke semua VM dari project tertentu atau folder.
Jika menggunakan kepercayaan lintas forest dengan autentikasi bersyarat, Anda dapat menggunakan OU yang sesuai dengan project Google Cloud untuk memberikan izin Allowed to authenticate berdasarkan per project.
Saat menghapus project di Google Cloud, Anda dapat menghapus OU terkait, sehingga mengurangi risiko meninggalkan resource yang tidak berlaku di direktori Anda.
Jika Anda merasa struktur OU harus berbeda dengan struktur project Anda, hal ini mungkin menunjukkan bahwa struktur project Anda terlalu detail atau terlalu samar.
Menggunakan server waktu Google
Autentikasi Kerberos mengandalkan stempel waktu sebagai bagian dari protokolnya. Agar autentikasi berhasil, jam klien dan mesin server harus disinkronkan dalam margin tertentu. Secara default, Active Directory mengizinkan selisih tidak lebih dari 5 menit.
Dalam lingkungan Active Directory lokal, berikut konfigurasi default untuk menyinkronkan waktu:
- Mesin yang bergabung dengan domain menyinkronkan waktu mereka dengan pengontrol domain.
- Pengontrol domain menyinkronkan waktu mereka dengan emulator PDC domain.
- Emulator PDC dari semua domain menyinkronkan waktu mereka dengan emulator PDC domain root forest.
Dalam konfigurasi ini, emulator PDC domain root forest adalah sumber waktu utama untuk Active Directory, dan biasanya mesin ini dikonfigurasi untuk menggunakan server NTP eksternal sebagai sumber waktu.
Di Compute Engine, konfigurasi default untuk VM Windows adalah menggunakan server metadata (metadata.google.internal) sebagai server NTP, yang nantinya akan mengandalkan server NTP Google untuk memperoleh waktu yang tepat. Penggabungan VM ke domain Active Directory tidak mengubah konfigurasi default ini.
Terus gunakan konfigurasi default Compute Engine, kecuali jika emulator PDC domain root forest Anda di-deploy di luar Google Cloud.
Jika emulator PDC Anda di-deploy di luar Google Cloud, konfigurasi emulator itu untuk digunakan time.google.com sebagai sumber NTP.
Atau, Anda dapat memulihkan perilaku Active Directory default untuk menyinkronkan waktu dengan emulator PDC dengan mengonfigurasi ulang VM Compute Engine agar menggunakan sumber DOMHIER NTP dan mengonfigurasi aturan firewall untuk mengizinkan traffic NTP masuk (UDP/123) ke pengontrol domain Anda.
Menggabungkan dan memantau log audit
Saat Anda men-deploy Active Directory di Google Cloud, keamanan forest Active Directory dan project Google Cloud Anda akan saling terkait: Aktivitas mencurigakan di Active Directory dan Windows mungkin membahayakan keamanan beberapa resource lain. Demikian pula, aktivitas mencurigakan di Google Cloud mungkin membahayakan Active Directory Anda.
Log audit yang konsisten merupakan alat penting untuk mengidentifikasi ancaman atau kesalahan konfigurasi lebih awal, serta memungkinkan Anda merekonstruksi dan memeriksa aktivitas sebelumnya. Cloud Audit Logging memungkinkan Anda mengambil dan menganalisis log aktivitas admin dan log akses data. Demikian pula, Anda dapat menggunakan logging aturan firewall dan log aliran VPC untuk menganalisis traffic jaringan. Namun, layanan platform ini tidak mengetahui adanya peristiwa terkait keamanan yang terjadi di Active Directory. Untuk membangun jejak audit yang konsisten dan mencakup peristiwa audit terkait platform dan peristiwa audit terkait Active Directory, instal agen Cloud Logging di pengontrol domain dan mesin yang bergabung dengan domain untuk mengekspor log peristiwa keamanan Windows ke Cloud Logging.
Secara default, log peristiwa keamanan Windows mungkin tidak mencatat semua peristiwa yang Anda butuhkan untuk tujuan audit. Lihat rekomendasi Microsoft tentang cara mengonfigurasi kebijakan audit dan memantau Active Directory untuk menemukan tanda-tanda penyusupan guna memastikan Anda mencatat semua peristiwa audit yang relevan.
Saat menangani peristiwa dalam jumlah besar, peristiwa penting bisa dengan mudah terlewatkan. Agar peristiwa penting tidak terlewat, buat metrik berbasis log untuk peristiwa yang mungkin sangat penting atau mencurigakan dan pertimbangkan untuk mengonfigurasi pemberitahuan guna memberi tahu Anda saat laju peristiwa berubah atau melebihi batas yang dapat diterima.
Langkah selanjutnya
Cari tahu pola dalam menggunakan Active Directory di lingkungan hybrid yang paling sesuai dengan situasi Anda.
Pelajari cara mengonfigurasi Active Directory agar VM dapat bergabung ke domain secara otomatis.
Coba sendiri fitur Google Cloud lainnya. Lihat tutorial kami.