Menerapkan Model Administratif dengan Hak Istimewa Paling Sedikit

Berlaku untuk: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Kutipan berikut berasal dari Panduan Perencanaan Keamanan Akun Administrator, pertama kali diterbitkan pada 1 April 1999:

"Sebagian besar kursus dan dokumentasi pelatihan terkait keamanan membahas implementasi prinsip hak istimewa paling sedikit, namun organisasi jarang mengikutinya. Prinsipnya sederhana, dan dampak menerapkannya dengan benar sangat meningkatkan keamanan Anda dan mengurangi risiko Anda. Prinsip menyatakan bahwa semua pengguna harus masuk dengan akun pengguna yang memiliki izin minimum absolut yang diperlukan untuk menyelesaikan tugas saat ini dan tidak lebih. Melakukannya memberikan perlindungan terhadap kode berbahaya, di antara serangan lainnya. Prinsip ini berlaku untuk komputer dan pengguna komputer tersebut. "Salah satu alasan prinsip ini bekerja dengan sangat baik adalah bahwa itu memaksa Anda untuk melakukan beberapa penelitian internal. Misalnya, Anda harus menentukan hak istimewa akses yang benar-benar dibutuhkan komputer atau pengguna, lalu menerapkannya. Untuk banyak organisasi, tugas ini awalnya mungkin tampak seperti banyak pekerjaan; namun, ini adalah langkah penting untuk berhasil mengamankan lingkungan jaringan Anda. "Anda harus memberi semua pengguna administrator domain hak istimewa domain mereka di bawah konsep hak istimewa paling sedikit. Misalnya, jika administrator masuk dengan akun istimewa dan secara tidak sengaja menjalankan program virus, virus memiliki akses administratif ke komputer lokal dan ke seluruh domain. Jika administrator telah masuk dengan akun nonprivileged (nonadministrative), cakupan kerusakan virus hanya akan menjadi komputer lokal karena berjalan sebagai pengguna komputer lokal. "Dalam contoh lain, akun yang Anda berikan hak administrator tingkat domain tidak boleh memiliki hak yang ditinggikan di forest lain, bahkan jika ada hubungan kepercayaan antara forest. Taktik ini membantu mencegah kerusakan yang meluas jika penyerang berhasil membahayakan satu forest terkelola. Organisasi harus secara teratur mengaudit jaringan mereka untuk melindungi dari eskalasi hak istimewa yang tidak sah."

Kutipan berikut berasal dari Microsoft Keamanan Windows Resource Kit, pertama kali diterbitkan pada tahun 2005:

"Selalu pikirkan keamanan dalam hal memberikan jumlah hak istimewa paling sedikit yang diperlukan untuk melaksanakan tugas. Jika aplikasi yang memiliki terlalu banyak hak istimewa harus disusupi, penyerang mungkin dapat memperluas serangan melebihi apa yang terjadi jika aplikasi berada di bawah jumlah hak istimewa sekecil mungkin. Misalnya, periksa konsekuensi administrator jaringan tanpa disadari membuka lampiran email yang meluncurkan virus. Jika administrator masuk menggunakan akun Administrator domain, virus akan memiliki hak istimewa Administrator pada semua komputer di domain dan dengan demikian akses tidak terbatas ke hampir semua data di jaringan. Jika administrator masuk menggunakan akun Administrator lokal, virus akan memiliki hak istimewa Administrator di komputer lokal dan dengan demikian akan dapat mengakses data apa pun di komputer dan menginstal perangkat lunak berbahaya seperti perangkat lunak pengelogan key-stroke di komputer. Jika administrator masuk menggunakan akun pengguna normal, virus hanya akan memiliki akses ke data administrator dan tidak akan dapat menginstal perangkat lunak berbahaya. Dengan menggunakan hak istimewa paling sedikit yang diperlukan untuk membaca email, dalam contoh ini, cakupan potensial kompromi sangat berkurang."

Masalah Hak Istimewa

Prinsip-prinsip yang dijelaskan dalam kutipan sebelumnya tidak berubah, tetapi dalam menilai penginstalan Direktori Aktif, kami selalu menemukan jumlah akun berlebihan yang telah diberikan hak dan izin jauh melebihi yang diperlukan untuk melakukan pekerjaan sehari-hari. Ukuran lingkungan memengaruhi jumlah mentah akun yang terlalu istimewa, tetapi tidak direktori berukuran menengah proporsi mungkin memiliki puluhan akun dalam grup yang paling istimewa, sementara instalasi besar mungkin memiliki ratusan atau bahkan ribuan. Dengan beberapa pengecualian, terlepas dari kecanggihan keterampilan penyerang dan gudang senjata, penyerang biasanya mengikuti jalur perlawanan paling sedikit. Mereka meningkatkan kompleksitas alat dan pendekatan mereka hanya jika dan ketika mekanisme yang lebih sederhana gagal atau digagalkan oleh pembela.

Sayangnya, jalur ketahanan paling sedikit di banyak lingkungan telah terbukti menjadi penggunaan akun yang berlebihan dengan hak istimewa yang luas dan mendalam. Hak istimewa yang luas adalah hak dan izin yang memungkinkan akun melakukan aktivitas tertentu di seluruh penampang besar lingkungan- misalnya, staf Help Desk dapat diberikan izin yang memungkinkan mereka untuk mengatur ulang kata sandi pada banyak akun pengguna.

Hak istimewa mendalam adalah hak istimewa yang kuat yang diterapkan pada segmen populasi yang sempit, seperti memberikan hak Administrator insinyur pada server sehingga mereka dapat melakukan perbaikan. Hak istimewa luas atau hak istimewa mendalam tidak selalu berbahaya, tetapi ketika banyak akun di domain diberikan hak istimewa yang luas dan mendalam secara permanen, jika hanya salah satu akun yang disusupi, itu dapat dengan cepat digunakan untuk mengonfigurasi ulang lingkungan ke tujuan penyerang atau bahkan untuk menghancurkan segmen besar infrastruktur.

Serangan pass-the-hash, yang merupakan jenis serangan pencurian kredensial, di mana-mana karena alat untuk melakukannya tersedia secara bebas dan mudah digunakan, dan karena banyak lingkungan rentan terhadap serangan. Serangan pass-the-hash, bagaimanapun, bukan masalah nyata. Crux masalahnya adalah dua kali lipat:

1. Biasanya mudah bagi penyerang untuk mendapatkan hak istimewa mendalam pada satu komputer dan kemudian menyebarluaskan hak istimewa itu secara luas ke komputer lain.
2. Biasanya ada terlalu banyak akun permanen dengan tingkat hak istimewa yang tinggi di seluruh lanskap komputasi.

Bahkan jika serangan pass-the-hash dihilangkan, penyerang hanya akan menggunakan taktik yang berbeda, bukan strategi yang berbeda. Daripada menanam malware yang berisi alat pencurian info masuk, mereka mungkin menanam malware yang mencatat penekanan kunci, atau memanfaatkan sejumlah pendekatan lain untuk menangkap kredensial yang kuat di seluruh lingkungan. Terlepas dari taktiknya, targetnya tetap sama: akun dengan hak istimewa yang luas dan mendalam.

Pemberian hak istimewa yang berlebihan tidak hanya ditemukan di Direktori Aktif di lingkungan yang disusupi. Ketika organisasi telah mengembangkan kebiasaan memberikan lebih banyak hak istimewa daripada yang diperlukan, biasanya ditemukan di seluruh infrastruktur seperti yang dibahas di bagian berikut.

Di Direktori Aktif

Di Direktori Aktif, adalah umum untuk menemukan bahwa grup EA, DA, dan BA berisi jumlah akun yang berlebihan. Paling umum, grup EA organisasi berisi anggota terkecil, grup DA biasanya berisi pengali jumlah pengguna dalam grup EA, dan grup Administrator biasanya berisi lebih banyak anggota daripada populasi grup lain yang digabungkan. Ini sering disebabkan oleh keyakinan bahwa Administrator entah bagaimana "kurang istimewa" daripada EA atau EA. Meskipun hak dan izin yang diberikan kepada masing-masing grup ini berbeda, mereka harus secara efektif dianggap sebagai kelompok yang sama kuatnya karena anggota seseorang dapat menjadikan dirinya sebagai anggota dari dua lainnya.

Di Server Anggota

Ketika kami mengambil keanggotaan grup Administrator lokal di server anggota di banyak lingkungan, kami menemukan keanggotaan mulai dari beberapa akun lokal dan domain, hingga puluhan grup berlapis yang, ketika diperluas, mengungkapkan ratusan, bahkan ribuan, akun dengan hak istimewa Administrator lokal di server. Dalam banyak kasus, grup domain dengan keanggotaan besar disarangkan dalam grup Administrator lokal server anggota, tanpa mempertimbangkan fakta bahwa setiap pengguna yang dapat memodifikasi keanggotaan grup tersebut di domain dapat memperoleh kontrol administratif dari semua sistem tempat grup telah disarangkan dalam grup Administrator lokal.

Di Stasiun Kerja

Meskipun stasiun kerja biasanya memiliki anggota yang jauh lebih sedikit di grup Administrator lokal mereka daripada server anggota, di banyak lingkungan, pengguna diberikan keanggotaan di grup Administrator lokal di komputer pribadi mereka. Ketika ini terjadi, bahkan jika UAC diaktifkan, pengguna tersebut memberikan risiko yang ditingkatkan terhadap integritas stasiun kerja mereka.

Penting

Anda harus mempertimbangkan dengan cermat apakah pengguna memerlukan hak administratif di stasiun kerja mereka, dan jika mereka melakukannya, pendekatan yang lebih baik mungkin adalah membuat akun lokal terpisah di komputer yang merupakan anggota grup Administrator. Ketika pengguna memerlukan elevasi, mereka dapat menyajikan kredensial akun lokal tersebut untuk elevasi, tetapi karena akun bersifat lokal, akun tersebut tidak dapat digunakan untuk membahayakan komputer lain atau mengakses sumber daya domain. Namun, seperti halnya akun lokal apa pun, kredensial untuk akun istimewa lokal harus unik; jika Anda membuat akun lokal dengan kredensial yang sama di beberapa stasiun kerja, Anda mengekspos komputer untuk serangan pass-the-hash.

Dalam Aplikasi

Dalam serangan di mana target adalah kekayaan intelektual organisasi, akun yang telah diberikan hak istimewa yang kuat dalam aplikasi dapat ditargetkan untuk memungkinkan penyelundupan data. Meskipun akun yang memiliki akses ke data sensitif mungkin telah diberikan tidak ada hak istimewa yang ditingkatkan di domain atau sistem operasi, akun yang dapat memanipulasi konfigurasi aplikasi atau akses ke informasi yang diberikan aplikasi berisiko.

Di Repositori Data

Seperti halnya dengan target lain, penyerang yang mencari akses ke kekayaan intelektual dalam bentuk dokumen dan file lain dapat menargetkan akun yang mengontrol akses ke penyimpanan file, akun yang memiliki akses langsung ke file, atau bahkan grup atau peran yang memiliki akses ke file. Misalnya, jika server file digunakan untuk menyimpan dokumen kontrak dan akses diberikan ke dokumen dengan menggunakan grup Direktori Aktif, penyerang yang dapat memodifikasi keanggotaan grup dapat menambahkan akun yang disusupi ke grup dan mengakses dokumen kontrak. Dalam kasus di mana akses ke dokumen disediakan oleh aplikasi seperti SharePoint, penyerang dapat menargetkan aplikasi seperti yang dijelaskan sebelumnya.

Mengurangi Hak Istimewa

Semakin besar dan lebih kompleks lingkungan, semakin sulit untuk mengelola dan mengamankan. Dalam organisasi kecil, meninjau dan mengurangi hak istimewa mungkin merupakan proposisi yang relatif sederhana, tetapi setiap server tambahan, stasiun kerja, akun pengguna, dan aplikasi yang digunakan dalam organisasi menambahkan objek lain yang harus diamankan. Karena mungkin sulit atau bahkan tidak mungkin untuk mengamankan setiap aspek infrastruktur TI organisasi dengan benar, Anda harus memfokuskan upaya terlebih dahulu pada akun yang hak istimewanya menciptakan risiko terbesar, yang biasanya merupakan akun dan grup istimewa bawaan di Direktori Aktif, dan akun lokal istimewa di stasiun kerja dan server anggota.

Mengamankan Akun Administrator Lokal di Stasiun Kerja dan Server Anggota

Meskipun dokumen ini berfokus pada pengamanan Direktori Aktif, seperti yang telah dibahas sebelumnya, sebagian besar serangan terhadap direktori dimulai sebagai serangan terhadap masing-masing host. Panduan lengkap untuk mengamankan grup lokal pada sistem anggota tidak dapat disediakan, tetapi rekomendasi berikut dapat digunakan untuk membantu Anda mengamankan akun Administrator lokal di stasiun kerja dan server anggota.

Mengamankan Akun Administrator Lokal

Pada semua versi Windows yang saat ini dalam dukungan mainstream, akun Administrator lokal dinonaktifkan secara default, yang membuat akun tidak dapat digunakan untuk serangan pencurian pass-the-hash dan kredensial lainnya. Namun, di domain yang berisi sistem operasi warisan atau di mana akun Administrator lokal telah diaktifkan, akun-akun ini dapat digunakan seperti yang dijelaskan sebelumnya untuk menyebarkan kompromi di seluruh server anggota dan stasiun kerja. Untuk alasan ini, kontrol berikut direkomendasikan untuk semua akun Administrator lokal pada sistem yang bergabung dengan domain.

Instruksi terperinci untuk menerapkan kontrol ini disediakan di Lampiran H: Mengamankan Akun dan Grup Administrator Lokal. Namun, sebelum menerapkan pengaturan ini, pastikan bahwa akun Administrator lokal saat ini tidak digunakan di lingkungan untuk menjalankan layanan di komputer atau melakukan aktivitas lain yang akun-akun ini tidak boleh digunakan. Uji pengaturan ini secara menyeluruh sebelum menerapkannya di lingkungan produksi.

Kontrol untuk Akun Administrator Lokal

Akun Administrator bawaan tidak boleh digunakan sebagai akun layanan di server anggota, juga tidak boleh digunakan untuk masuk ke komputer lokal (kecuali dalam Mode Brankas, yang diizinkan bahkan jika akun dinonaktifkan). Tujuan penerapan pengaturan yang dijelaskan di sini adalah untuk mencegah akun Administrator lokal setiap komputer dapat digunakan kecuali kontrol pelindung terlebih dahulu dibalik. Dengan menerapkan kontrol ini dan memantau akun Administrator untuk perubahan, Anda dapat secara signifikan mengurangi kemungkinan keberhasilan serangan yang menargetkan akun Administrator lokal.

Mengonfigurasi GPO untuk Membatasi Akun Administrator pada Sistem yang Bergabung dengan Domain

Dalam satu atau beberapa GPO yang Anda buat dan tautkan ke stasiun kerja dan OU server anggota di setiap domain, tambahkan akun Administrator ke hak pengguna berikut di Computer Configuration\Policies\Windows Pengaturan\Security Pengaturan\Local Policies\User Rights Assignments:

• Tolak akses ke komputer ini dari jaringan
• Tolak masuk sebagai pekerjaan batch
• Menolak masuk sebagai layanan
• Tolak masuk melalui Layanan Desktop Jarak Jauh

Saat Anda menambahkan akun Administrator ke hak pengguna ini, tentukan apakah Anda menambahkan akun Administrator lokal atau akun Administrator domain dengan cara Anda memberi label akun. Misalnya, untuk menambahkan akun Administrator domain NWTRADERS ke hak tolak ini, Anda akan mengetik akun sebagai NWTRADERS\Administrator, atau menelusuri ke akun Administrator untuk domain NWTRADERS. Untuk memastikan bahwa Anda membatasi akun Administrator lokal, ketik Administrator di pengaturan hak pengguna ini di Editor Objek Kebijakan Grup.

Catatan

Bahkan jika akun Administrator lokal diganti namanya, kebijakan akan tetap berlaku.

Pengaturan ini akan memastikan bahwa akun Administrator komputer tidak dapat digunakan untuk menyambungkan ke komputer lain, meskipun tidak difungsikan secara tidak sengaja atau berbahaya. Logon lokal yang menggunakan akun Administrator lokal tidak dapat sepenuhnya dinonaktifkan, anda juga tidak boleh mencoba melakukannya, karena akun Administrator lokal komputer dirancang untuk digunakan dalam skenario pemulihan bencana.

Jika server anggota atau stasiun kerja menjadi terputus dari domain tanpa akun lokal lain yang diberikan hak istimewa administratif, komputer dapat di-boot ke mode aman, akun Administrator dapat diaktifkan, dan akun kemudian dapat digunakan untuk memengaruhi perbaikan pada komputer. Ketika perbaikan selesai, akun Administrator harus dinonaktifkan lagi.

Mengamankan Akun dan Grup Istimewa Lokal di Direktori Aktif

Undang-Undang Nomor Enam: Komputer hanya seaman administrator yang dapat dipercaya. - Sepuluh Hukum Keamanan yang Tidak Dapat Diubah (Versi 2.0)

Informasi yang diberikan di sini dimaksudkan untuk memberikan pedoman umum untuk mengamankan akun dan grup bawaan hak istimewa tertinggi di Direktori Aktif. Instruksi langkah demi langkah terperinci juga disediakan dalam Lampiran D: Mengamankan Akun Administrator Bawaan di Direktori Aktif, Lampiran E: Mengamankan Grup Admin Perusahaan di Direktori Aktif, Lampiran F: Mengamankan Grup Admin Domain di Direktori Aktif, dan di Lampiran G: Mengamankan Grup Administrator di Direktori Aktif.

Sebelum menerapkan salah satu pengaturan ini, Anda juga harus menguji semua pengaturan secara menyeluruh untuk menentukan apakah pengaturan tersebut sesuai untuk lingkungan Anda. Tidak semua organisasi akan dapat menerapkan pengaturan ini.

Mengamankan Akun Administrator Bawaan di Direktori Aktif

Di setiap domain di Direktori Aktif, akun Administrator dibuat sebagai bagian dari pembuatan domain. Akun ini secara default adalah anggota grup Admin dan Administrator Domain di domain, dan jika domain adalah domain akar forest, akun tersebut juga merupakan anggota grup Admin Perusahaan. Penggunaan akun Administrator lokal domain harus dicadangkan hanya untuk aktivitas build awal dan, mungkin, skenario pemulihan bencana. Untuk memastikan bahwa akun Administrator bawaan dapat digunakan untuk memengaruhi perbaikan jika tidak ada akun lain yang dapat digunakan, Anda tidak boleh mengubah keanggotaan default akun Administrator di domain mana pun di forest. Sebagai gantinya, Anda harus mengikuti panduan untuk membantu mengamankan akun Administrator di setiap domain di forest. Instruksi terperinci untuk menerapkan kontrol ini disediakan di Lampiran D: Mengamankan Akun Administrator Bawaan di Direktori Aktif.

Kontrol untuk Akun Administrator Bawaan

Tujuan penerapan pengaturan yang dijelaskan di sini adalah untuk mencegah akun Administrator setiap domain (bukan grup) tidak dapat digunakan kecuali sejumlah kontrol dibalik. Dengan menerapkan kontrol ini dan memantau akun Administrator untuk perubahan, Anda dapat secara signifikan mengurangi kemungkinan serangan yang berhasil dengan memanfaatkan akun Administrator domain. Untuk akun Administrator di setiap domain di forest Anda, Anda harus mengonfigurasi pengaturan berikut.

Aktifkan bendera "Akun sensitif dan tidak dapat didelegasikan" pada akun

Secara default, semua akun di Direktori Aktif dapat didelegasikan. Delegasi memungkinkan komputer atau layanan menyajikan kredensial untuk akun yang telah diautentikasi ke komputer atau layanan ke komputer lain untuk mendapatkan layanan atas nama akun. Saat Anda mengaktifkan Akun sensitif dan tidak dapat didelegasikan atribut pada akun berbasis domain, kredensial akun tidak dapat disajikan ke komputer atau layanan lain di jaringan, yang membatasi serangan yang memanfaatkan delegasi untuk menggunakan kredensial akun pada sistem lain.

Aktifkan bendera "Kartu pintar diperlukan untuk masuk interaktif" pada akun

Saat Anda mengaktifkan Kartu pintar diperlukan untuk atribut masuk interaktif pada akun, Windows mengatur ulang kata sandi akun ke nilai acak 120 karakter. Dengan mengatur bendera ini pada akun Administrator bawaan, Anda memastikan bahwa kata sandi untuk akun tidak hanya panjang dan kompleks, tetapi tidak diketahui oleh pengguna mana pun. Secara teknis tidak perlu membuat kartu pintar untuk akun sebelum mengaktifkan atribut ini, tetapi jika memungkinkan, kartu pintar harus dibuat untuk setiap akun Administrator sebelum mengonfigurasi pembatasan akun dan kartu pintar harus disimpan di lokasi yang aman.

Meskipun mengatur Kartu pintar diperlukan untuk bendera masuk interaktif mengatur ulang kata sandi akun, itu tidak mencegah pengguna dengan hak untuk mengatur ulang kata sandi akun agar tidak mengatur akun ke nilai yang diketahui dan menggunakan nama akun dan kata sandi baru untuk mengakses sumber daya di jaringan. Karena itu, Anda harus menerapkan kontrol tambahan berikut pada akun.

Mengonfigurasi GPO untuk Membatasi Akun Administrator Domain pada Sistem yang Bergabung dengan Domain

Meskipun menonaktifkan akun Administrator di domain membuat akun tidak dapat digunakan secara efektif, Anda harus menerapkan pembatasan tambahan pada akun jika akun tersebut diaktifkan secara tidak sengaja atau berbahaya. Meskipun kontrol ini pada akhirnya dapat dibalik oleh akun Administrator, tujuannya adalah untuk membuat kontrol yang memperlambat kemajuan penyerang dan membatasi kerusakan yang dapat dialami akun.

Dalam satu atau beberapa GPO yang Anda buat dan tautkan ke stasiun kerja dan OU server anggota di setiap domain, tambahkan akun Administrator setiap domain ke hak pengguna berikut di Konfigurasi Komputer\Kebijakan\Windows Pengaturan\Keamanan Pengaturan\Kebijakan Lokal\Penetapan Hak Pengguna:

• Tolak akses ke komputer ini dari jaringan
• Tolak masuk sebagai pekerjaan batch
• Menolak masuk sebagai layanan
• Tolak masuk melalui Layanan Desktop Jarak Jauh

Catatan

Saat menambahkan akun Administrator lokal ke pengaturan ini, Anda harus menentukan apakah Anda mengonfigurasi akun Administrator lokal atau akun Administrator domain. Misalnya, untuk menambahkan akun Administrator lokal domain NWTRADERS ke hak tolak ini, Anda harus mengetik akun sebagai NWTRADERS\Administrator, atau menelusuri ke akun Administrator lokal untuk domain NWTRADERS. Jika Anda mengetik Administrator di pengaturan hak pengguna ini di Editor Objek Kebijakan Grup, Anda akan membatasi akun Administrator lokal di setiap komputer tempat GPO diterapkan.

Sebaiknya batasi akun Administrator lokal di server anggota dan stasiun kerja dengan cara yang sama seperti akun Administrator berbasis domain. Oleh karena itu, Anda umumnya harus menambahkan akun Administrator untuk setiap domain di forest dan akun Administrator untuk komputer lokal ke pengaturan hak pengguna ini.

Mengonfigurasi GPO untuk Membatasi Akun Administrator pada Pengendali Domain

Di setiap domain di forest, kebijakan Pengendali Domain Default atau kebijakan yang ditautkan ke Unit Organisasi Pengendali Domain harus dimodifikasi untuk menambahkan akun Administrator setiap domain ke hak pengguna berikut di Konfigurasi Komputer\Kebijakan\Windows Pengaturan\Keamanan Pengaturan\Kebijakan Lokal\Penetapan Hak Pengguna:

• Tolak akses ke komputer ini dari jaringan
• Tolak masuk sebagai pekerjaan batch
• Menolak masuk sebagai layanan
• Tolak masuk melalui Layanan Desktop Jarak Jauh

Catatan

Pengaturan ini akan memastikan bahwa akun Administrator lokal tidak dapat digunakan untuk menyambungkan ke pengendali domain, meskipun akun, jika diaktifkan, dapat masuk secara lokal ke pengendali domain. Karena akun ini hanya boleh diaktifkan dan digunakan dalam skenario pemulihan bencana, diantisipasi bahwa akses fisik ke setidaknya satu pengendali domain akan tersedia, atau bahwa akun lain dengan izin untuk mengakses pengendali domain dari jarak jauh dapat digunakan.

Mengonfigurasi Audit Akun Administrator Bawaan

Ketika Anda telah mengamankan setiap akun Administrator domain dan menonaktifkannya, Anda harus mengonfigurasi audit untuk memantau perubahan pada akun. Jika akun diaktifkan, kata sandinya diatur ulang, atau modifikasi lain dilakukan ke akun, pemberitahuan harus dikirimkan kepada pengguna atau tim yang bertanggung jawab atas administrasi AD DS, selain tim respons insiden di organisasi Anda.

Mengamankan Administrator, Admin Domain, dan Grup Admin Perusahaan

Mengamankan Grup Admin Perusahaan

Grup Admin Perusahaan, yang ditempatkan di domain akar hutan, tidak boleh berisi pengguna setiap hari, dengan kemungkinan pengecualian akun Administrator lokal domain, asalkan diamankan seperti yang dijelaskan sebelumnya dan di Lampiran D: Mengamankan Akun Administrator Bawaan di Direktori Aktif.

Ketika akses EA diperlukan, pengguna yang akunnya memerlukan hak dan izin EA harus ditempatkan sementara ke dalam grup Admin Perusahaan. Meskipun pengguna menggunakan akun yang sangat istimewa, aktivitas mereka harus diaudit dan sebaiknya dilakukan dengan satu pengguna yang melakukan perubahan dan pengguna lain mengamati perubahan untuk meminimalkan kemungkinan penyalahgunaan atau kesalahan konfigurasi yang tidak disengaja. Ketika aktivitas telah selesai, akun harus dihapus dari grup EA. Hal ini dapat dicapai melalui prosedur manual dan proses yang didokumentasikan, perangkat lunak privileged identity/access management (PIM/PAM) pihak ketiga, atau kombinasi keduanya. Panduan untuk membuat akun yang dapat digunakan untuk mengontrol keanggotaan grup istimewa di Direktori Aktif disediakan di Akun Menarik untuk Pencurian Kredensial dan instruksi terperinci disediakan dalam Lampiran I: Membuat Akun Manajemen untuk Akun dan Grup yang Dilindungi di Direktori Aktif.

Admin Perusahaan adalah, secara default, anggota grup Administrator bawaan di setiap domain di forest. Menghapus grup Admin Perusahaan dari grup Administrator di setiap domain adalah modifikasi yang tidak pantas karena jika terjadi skenario pemulihan bencana hutan, hak EA kemungkinan akan diperlukan. Jika grup Admin Perusahaan telah dihapus dari grup Administrator di forest, grup Admin harus ditambahkan ke grup Administrator di setiap domain dan kontrol tambahan berikut harus diimplementasikan:

• Seperti yang dijelaskan sebelumnya, grup Admin Perusahaan tidak boleh berisi pengguna setiap hari, dengan kemungkinan pengecualian akun Administrator domain akar hutan, yang harus diamankan seperti yang dijelaskan dalam Lampiran D: Mengamankan Akun Administrator Bawaan di Direktori Aktif.
• Di GPO yang ditautkan ke OU yang berisi server anggota dan stasiun kerja di setiap domain, grup EA harus ditambahkan ke hak pengguna berikut:
  • Tolak akses ke komputer ini dari jaringan
  • Tolak masuk sebagai pekerjaan batch
  • Menolak masuk sebagai layanan
  • Tolak masuk secara lokal
  • Tolak masuk melalui Layanan Desktop Jarak Jauh.

Ini akan mencegah anggota grup EA masuk ke server anggota dan stasiun kerja. Jika jump server digunakan untuk mengelola pengontrol domain dan Direktori Aktif, pastikan bahwa server jump terletak di OU tempat GPO pembatasan tidak ditautkan.

• Audit harus dikonfigurasi untuk mengirim pemberitahuan jika ada modifikasi yang dilakukan pada properti atau keanggotaan grup EA. Pemberitahuan ini harus dikirim, minimal, kepada pengguna atau tim yang bertanggung jawab atas administrasi Direktori Aktif dan respons insiden. Anda juga harus menentukan proses dan prosedur untuk mengisi grup EA untuk sementara waktu, termasuk prosedur pemberitahuan ketika populasi grup yang sah dilakukan.

Mengamankan Grup Admin Domain

Seperti halnya dengan grup Admin Perusahaan, keanggotaan dalam grup Admin Domain harus hanya diperlukan dalam skenario build atau pemulihan bencana. Seharusnya tidak ada akun pengguna sehari-hari di grup DA dengan pengecualian akun Administrator lokal untuk domain, jika telah diamankan seperti yang dijelaskan dalam Lampiran D: Mengamankan Akun Administrator Bawaan di Direktori Aktif.

Ketika akses DA diperlukan, akun yang memerlukan tingkat akses ini harus ditempatkan sementara di grup DA untuk domain yang dimaksud. Meskipun pengguna menggunakan akun yang sangat istimewa, aktivitas harus diaudit dan sebaiknya dilakukan dengan satu pengguna yang melakukan perubahan dan pengguna lain mengamati perubahan untuk meminimalkan kemungkinan penyalahgunaan atau kesalahan konfigurasi yang tidak disengaja. Setelah aktivitas selesai, akun harus dihapus dari grup Admin Domain. Hal ini dapat dicapai melalui prosedur manual dan proses yang didokumentasikan, melalui perangkat lunak privileged identity/access management (PIM/PAM) pihak ketiga, atau kombinasi keduanya. Panduan untuk membuat akun yang dapat digunakan untuk mengontrol keanggotaan grup istimewa di Direktori Aktif disediakan di Lampiran I: Membuat Akun Manajemen untuk Akun dan Grup yang Dilindungi di Direktori Aktif.

Admin Domain adalah, secara default, anggota grup Administrator lokal di semua server anggota dan stasiun kerja di domain masing-masing. Bersarang default ini tidak boleh dimodifikasi karena memengaruhi opsi dukungan dan pemulihan bencana. Jika grup Admin Domain telah dihapus dari grup Administrator lokal di server anggota, grup tersebut harus ditambahkan ke grup Administrator di setiap server anggota dan stasiun kerja di domain melalui pengaturan grup terbatas di GPO tertaut. Kontrol umum berikut, yang dijelaskan secara mendalam dalam Lampiran F: Mengamankan Grup Admin Domain di Direktori Aktif juga harus diimplementasikan.

Untuk grup Admin Domain di setiap domain di forest:

1. Hapus semua anggota dari grup DA, dengan kemungkinan pengecualian akun Administrator bawaan untuk domain, asalkan telah diamankan seperti yang dijelaskan dalam Lampiran D: Mengamankan Akun Administrator Bawaan di Direktori Aktif.

2. Di GPO yang ditautkan ke OU yang berisi server anggota dan stasiun kerja di setiap domain, grup DA harus ditambahkan ke hak pengguna berikut:

   • Tolak akses ke komputer ini dari jaringan
   • Tolak masuk sebagai pekerjaan batch
   • Menolak masuk sebagai layanan
   • Tolak masuk secara lokal
   • Tolak masuk melalui Layanan Desktop Jarak Jauh

   Ini akan mencegah anggota grup DA masuk ke server anggota dan stasiun kerja. Jika jump server digunakan untuk mengelola pengontrol domain dan Direktori Aktif, pastikan bahwa server jump terletak di OU tempat GPO pembatasan tidak ditautkan.

3. Audit harus dikonfigurasi untuk mengirim pemberitahuan jika ada modifikasi yang dilakukan pada properti atau keanggotaan grup DA. Pemberitahuan ini harus dikirim, minimal, kepada pengguna atau tim yang bertanggung jawab atas administrasi AD DS dan respons insiden. Anda juga harus menentukan proses dan prosedur untuk mengisi grup DA untuk sementara waktu, termasuk prosedur pemberitahuan saat populasi grup yang sah dilakukan.

Mengamankan Grup Administrator di Direktori Aktif

Seperti halnya dengan grup EA dan DA, keanggotaan dalam grup Administrator (BA) harus diperlukan hanya dalam skenario build atau pemulihan bencana. Seharusnya tidak ada akun pengguna sehari-hari di grup Administrator dengan pengecualian akun Administrator lokal untuk domain, jika telah diamankan seperti yang dijelaskan dalam Lampiran D: Mengamankan Akun Administrator Bawaan di Direktori Aktif.

Ketika akses Administrator diperlukan, akun yang memerlukan tingkat akses ini harus ditempatkan sementara di grup Administrator untuk domain yang dimaksud. Meskipun pengguna menggunakan akun yang sangat istimewa, aktivitas harus diaudit dan, sebaiknya, dilakukan dengan pengguna yang melakukan perubahan dan pengguna lain mengamati perubahan untuk meminimalkan kemungkinan penyalahgunaan atau kesalahan konfigurasi yang tidak disengaja. Ketika aktivitas telah selesai, akun harus segera dihapus dari grup Administrator. Hal ini dapat dicapai melalui prosedur manual dan proses yang didokumentasikan, melalui perangkat lunak privileged identity/access management (PIM/PAM) pihak ketiga, atau kombinasi keduanya.

Administrator, secara default, pemilik sebagian besar objek AD DS di domain masing-masing. Keanggotaan dalam grup ini mungkin diperlukan dalam skenario build dan pemulihan bencana di mana kepemilikan atau kemampuan untuk mengambil kepemilikan objek diperlukan. Selain itu, EA dan EA mewarisi sejumlah hak dan izin mereka berdasarkan keanggotaan default mereka di grup Administrator. Grup default yang berlapis untuk grup istimewa di Direktori Aktif tidak boleh dimodifikasi, dan setiap grup Administrator domain harus diamankan seperti yang dijelaskan dalam Lampiran G: Mengamankan Grup Administrator di Direktori Aktif, dan dalam instruksi umum di bawah ini.

1. Hapus semua anggota dari grup Administrator, dengan kemungkinan pengecualian akun Administrator lokal untuk domain, asalkan telah diamankan seperti yang dijelaskan dalam Lampiran D: Mengamankan Akun Administrator Bawaan di Direktori Aktif.

2. Anggota grup Administrator domain tidak perlu masuk ke server anggota atau stasiun kerja. Dalam satu atau beberapa GPO yang ditautkan ke stasiun kerja dan OU server anggota di setiap domain, grup Administrator harus ditambahkan ke hak pengguna berikut:

   • Tolak akses ke komputer ini dari jaringan
   • Tolak masuk sebagai pekerjaan batch,
   • Menolak masuk sebagai layanan
   • Ini akan mencegah anggota grup Administrator digunakan untuk masuk atau terhubung ke server anggota atau stasiun kerja (kecuali beberapa kontrol pertama kali dilanggar), di mana kredensial mereka dapat di-cache dan dengan demikian disusupi. Akun istimewa tidak boleh digunakan untuk masuk ke sistem yang kurang istimewa, dan memberlakukan kontrol ini memberikan perlindungan terhadap sejumlah serangan.

3. Di OU pengendali domain di setiap domain di forest, grup Administrator harus diberikan hak pengguna berikut (jika mereka belum memiliki hak ini), yang akan memungkinkan anggota grup Administrator untuk melakukan fungsi yang diperlukan untuk skenario pemulihan bencana di seluruh hutan:

   • Akses komputer ini dari jaringan
   • Perbolehkan masuk secara lokal
   • Perbolehkan masuk melalui Layanan Desktop Jarak Jauh

4. Audit harus dikonfigurasi untuk mengirim pemberitahuan jika ada modifikasi yang dilakukan pada properti atau keanggotaan grup Administrator. Pemberitahuan ini harus dikirim, minimal, kepada anggota tim yang bertanggung jawab atas administrasi AD DS. Pemberitahuan juga harus dikirim ke anggota tim keamanan, dan prosedur harus didefinisikan untuk memodifikasi keanggotaan grup Administrator. Secara khusus, proses ini harus mencakup prosedur di mana tim keamanan diberi tahu ketika grup Administrator akan dimodifikasi sehingga ketika pemberitahuan dikirim, mereka diharapkan dan alarm tidak dinaikkan. Selain itu, proses untuk memberi tahu tim keamanan ketika penggunaan grup Administrator telah selesai dan akun yang digunakan telah dihapus dari grup harus diimplementasikan.

Catatan

Saat Anda menerapkan pembatasan pada grup Administrator di GPO, Windows menerapkan pengaturan untuk anggota grup Administrator lokal komputer selain grup Administrator domain. Oleh karena itu, Anda harus berhati-hati saat menerapkan pembatasan pada grup Administrator. Meskipun melarang masuk jaringan, batch, dan layanan untuk anggota grup Administrator disarankan di mana pun diizinkan untuk menerapkan, jangan membatasi logon atau logon lokal melalui Layanan Desktop Jarak Jauh. Memblokir jenis log masuk ini dapat memblokir administrasi komputer yang sah oleh anggota grup Administrator lokal. Cuplikan layar berikut menunjukkan pengaturan konfigurasi yang memblokir penyalahgunaan akun Administrator lokal dan domain bawaan, selain penyalahgunaan grup Administrator lokal atau domain bawaan. Perhatikan bahwa hak pengguna Tolak masuk melalui Layanan Desktop Jauh tidak menyertakan grup Administrator, karena menyertakannya dalam pengaturan ini juga akan memblokir logon ini untuk akun yang merupakan anggota grup Administrator komputer lokal. Jika layanan di komputer dikonfigurasi untuk berjalan dalam konteks salah satu grup istimewa yang dijelaskan di bagian ini, menerapkan pengaturan ini dapat menyebabkan layanan dan aplikasi gagal. Oleh karena itu, seperti semua rekomendasi di bagian ini, Anda harus menguji pengaturan secara menyeluruh untuk penerapan di lingkungan Anda.

Kontrol Akses Berbasis Peran (RBAC) untuk Direktori Aktif

Secara umum, kontrol akses berbasis peran (RBAC) adalah mekanisme untuk mengelompokkan pengguna dan menyediakan akses ke sumber daya berdasarkan aturan bisnis. Dalam kasus Direktori Aktif, menerapkan RBAC untuk AD DS adalah proses pembuatan peran di mana hak dan izin didelegasikan untuk memungkinkan anggota peran melakukan tugas administratif sehari-hari tanpa memberi mereka hak istimewa yang berlebihan. RBAC untuk Direktori Aktif dapat dirancang dan diimplementasikan melalui alat dan antarmuka asli, dengan memanfaatkan perangkat lunak yang mungkin sudah Anda miliki, dengan membeli produk pihak ketiga, atau kombinasi pendekatan ini. Bagian ini tidak memberikan instruksi langkah demi langkah untuk menerapkan RBAC untuk Direktori Aktif, tetapi sebaliknya membahas faktor yang harus Anda pertimbangkan dalam memilih pendekatan untuk menerapkan RBAC dalam penginstalan AD DS Anda.

Pendekatan Asli untuk RBAC untuk Direktori Aktif

Dalam implementasi RBAC yang paling sederhana, Anda dapat menerapkan peran sebagai grup AD DS dan mendelegasikan hak dan izin ke grup yang memungkinkan mereka melakukan administrasi harian dalam cakupan peran yang ditentukan.

Dalam beberapa kasus, grup keamanan yang ada di Direktori Aktif dapat digunakan untuk memberikan hak dan izin yang sesuai dengan fungsi pekerjaan. Misalnya, jika karyawan tertentu di organisasi TI Anda bertanggung jawab atas manajemen dan pemeliharaan zona dan catatan DNS, mendelegasikan tanggung jawab tersebut bisa sesingkat membuat akun untuk setiap administrator DNS dan menambahkannya ke grup Admin DNS di Direktori Aktif. Grup Admin DNS, tidak seperti grup dengan hak istimewa yang lebih tinggi, memiliki beberapa hak kuat di seluruh Direktori Aktif, meskipun anggota grup ini telah didelegasikan izin yang memungkinkan mereka mengelola DNS dan masih tunduk pada penyusupan dan penyalahgunaan dapat mengakibatkan peningkatan hak istimewa.

Dalam kasus lain, Anda mungkin perlu membuat grup keamanan dan mendelegasikan hak dan izin ke objek Direktori Aktif, objek sistem file, dan objek registri untuk memungkinkan anggota grup melakukan tugas administratif yang ditunjuk. Misalnya, jika operator Help Desk Anda bertanggung jawab untuk mengatur ulang kata sandi yang terlupakan, membantu pengguna dengan masalah konektivitas, dan memecahkan masalah pengaturan aplikasi, Anda mungkin perlu menggabungkan pengaturan delegasi pada objek pengguna di Direktori Aktif dengan hak istimewa yang memungkinkan pengguna Help Desk untuk terhubung dari jarak jauh ke komputer pengguna untuk melihat atau mengubah pengaturan konfigurasi pengguna. Untuk setiap peran yang Anda tentukan, Anda harus mengidentifikasi:

1. Tugas mana yang dilakukan anggota peran setiap hari dan tugas mana yang lebih jarang dilakukan.
2. Pada sistem mana dan di mana anggota aplikasi dari peran harus diberikan hak dan izin.
3. Pengguna mana yang harus diberikan keanggotaan dalam peran.
4. Bagaimana manajemen keanggotaan peran akan dilakukan.

Di banyak lingkungan, membuat kontrol akses berbasis peran secara manual untuk administrasi lingkungan Direktori Aktif dapat menjadi tantangan untuk diterapkan dan dikelola. Jika Anda memiliki peran dan tanggung jawab yang ditentukan dengan jelas untuk administrasi infrastruktur TI Anda, Anda mungkin ingin memanfaatkan alat tambahan untuk membantu Anda dalam membuat penyebaran RBAC asli yang dapat dikelola. Misalnya, jika Forefront Identity Manager (FIM) digunakan di lingkungan Anda, Anda dapat menggunakan FIM untuk mengotomatiskan pembuatan dan populasi peran administratif, yang dapat memudahkan administrasi yang sedang berlangsung. Jika Anda menggunakan Microsoft Endpoint Configuration Manager dan System Center Operations Manager (SCOM), Anda dapat menggunakan peran khusus aplikasi untuk mendelegasikan fungsi manajemen dan pemantauan, dan juga menerapkan konfigurasi dan audit yang konsisten di seluruh sistem di domain. Jika Anda telah menerapkan infrastruktur kunci umum (PKI), Anda dapat mengeluarkan dan mewajibkan kartu pintar untuk staf IT yang bertanggung jawab untuk mengelola lingkungan. Dengan FIM Credential Management (FIM CM), Anda bahkan dapat menggabungkan manajemen peran dan kredensial untuk staf administratif Anda.

Dalam kasus lain, mungkin lebih baik bagi organisasi untuk mempertimbangkan untuk menyebarkan perangkat lunak RBAC pihak ketiga yang menyediakan fungsionalitas "di luar kotak". Solusi komersial, off-the-shelf (COTS) untuk RBAC untuk direktori Active Directory, Windows, dan non-Windows dan sistem operasi ditawarkan oleh sejumlah vendor. Saat memilih antara solusi asli dan produk pihak ketiga, Anda harus mempertimbangkan faktor-faktor berikut:

1. Anggaran: Dengan berinvestasi dalam pengembangan RBAC menggunakan perangkat lunak dan alat yang mungkin sudah Anda miliki, Anda dapat mengurangi biaya perangkat lunak yang terlibat dalam penyebaran solusi. Namun, kecuali Anda memiliki staf yang berpengalaman dalam membuat dan menyebarkan solusi RBAC asli, Anda mungkin perlu melibatkan sumber daya konsultasi untuk mengembangkan solusi Anda. Anda harus dengan hati-hati menimbang biaya yang diantisipasi untuk solusi yang dikembangkan khusus dengan biaya untuk menyebarkan solusi "siap pakai", terutama jika anggaran Anda terbatas.
2. Komposisi lingkungan TI: Jika lingkungan Anda terdiri terutama dari sistem Windows, atau jika Anda sudah memanfaatkan Direktori Aktif untuk manajemen sistem dan akun non-Windows, solusi asli kustom dapat memberikan solusi optimal untuk kebutuhan Anda. Jika infrastruktur Anda berisi banyak sistem yang tidak menjalankan Windows dan tidak dikelola oleh Direktori Aktif, Anda mungkin perlu mempertimbangkan opsi untuk manajemen sistem non-Windows secara terpisah dari lingkungan Direktori Aktif.
3. Model hak istimewa dalam solusi: Jika produk bergantung pada penempatan akun layanannya ke dalam grup yang sangat istimewa di Direktori Aktif dan tidak menawarkan opsi yang tidak memerlukan hak istimewa yang berlebihan diberikan ke perangkat lunak RBAC, Anda belum benar-benar mengurangi permukaan serangan Direktori Aktif Anda, Anda hanya mengubah komposisi grup yang paling istimewa dalam direktori. Kecuali vendor aplikasi dapat memberikan kontrol untuk akun layanan yang meminimalkan probabilitas akun yang disusupi dan digunakan secara berbahaya, Anda mungkin ingin mempertimbangkan opsi lain.

Privileged Identity Management

Privileged identity management (PIM), terkadang disebut sebagai privileged account management (PAM) atau privileged credential management (PCM) adalah desain, konstruksi, dan implementasi pendekatan untuk mengelola akun istimewa dalam infrastruktur Anda. Secara umum, PIM menyediakan mekanisme di mana akun diberikan hak sementara dan izin yang diperlukan untuk melakukan fungsi perbaikan build atau pemutusan, daripada meninggalkan hak istimewa yang dilampirkan secara permanen ke akun. Apakah fungsionalitas PIM dibuat secara manual atau diimplementasikan melalui penyebaran perangkat lunak pihak ketiga satu atau beberapa fitur berikut mungkin tersedia:

• Kredensial "vault", di mana kata sandi untuk akun istimewa "dicek keluar" dan menetapkan kata sandi awal, lalu "dicek masuk" ketika aktivitas telah selesai, di mana kata sandi kembali diatur ulang pada akun.
• Pembatasan terikat waktu pada penggunaan kredensial istimewa
• Kredensial sekali pakai
• Pemberian hak istimewa yang dihasilkan alur kerja dengan pemantauan dan pelaporan aktivitas yang dilakukan dan penghapusan hak istimewa otomatis ketika aktivitas selesai atau waktu yang dialokasikan telah kedaluwarsa
• Penggantian kredensial yang dikodekan secara permanen seperti nama pengguna dan kata sandi dalam skrip dengan antarmuka pemrograman aplikasi (API) yang memungkinkan kredensial diambil dari vault sesuai kebutuhan
• Manajemen otomatis kredensial akun layanan

Membuat Akun Tanpa Hak Istimewa untuk Mengelola Akun Istimewa

Salah satu tantangan dalam mengelola akun istimewa adalah bahwa, secara default, akun yang dapat mengelola akun dan grup istimewa dan terlindungi adalah akun istimewa dan dilindungi. Jika Anda menerapkan solusi RBAC dan PIM yang sesuai untuk penginstalan Direktori Aktif Anda, solusinya mungkin mencakup pendekatan yang memungkinkan Anda untuk secara efektif mendepopulasi keanggotaan grup yang paling istimewa di direktori, mengisi grup hanya untuk sementara dan ketika diperlukan.

Namun, jika Anda menerapkan RBAC dan PIM asli, Anda harus mempertimbangkan untuk membuat akun yang tidak memiliki hak istimewa dan dengan satu-satunya fungsi mengisi dan mendepolegasikan grup istimewa di Direktori Aktif saat diperlukan. Lampiran I: Membuat Akun Manajemen untuk Akun dan Grup yang Dilindungi di Direktori Aktif menyediakan instruksi langkah demi langkah yang dapat Anda gunakan untuk membuat akun untuk tujuan ini.

Menerapkan Kontrol Autentikasi yang Kuat

Hukum Nomor Enam: Benar-benar ada seseorang di luar sana yang mencoba menebak kata sandi Anda. - 10 Hukum Administrasi Keamanan yang Tidak Dapat Diubah

Serangan pencurian pass-the-hash dan kredensial lainnya tidak spesifik untuk sistem operasi Windows, juga bukan yang baru. Serangan pass-the-hash pertama dibuat pada tahun 1997. Namun, secara historis, serangan ini membutuhkan alat yang disesuaikan, hit-or-miss dalam keberhasilan mereka, dan penyerang yang diperlukan untuk memiliki tingkat keterampilan yang relatif tinggi. Pengenalan alat yang tersedia dan mudah digunakan secara bebas yang secara asli mengekstrak kredensial telah mengakibatkan peningkatan eksponensial dalam jumlah dan keberhasilan serangan pencurian info masuk dalam beberapa tahun terakhir. Namun, serangan pencurian kredensial tidak berarti satu-satunya mekanisme di mana kredensial ditargetkan dan disusupi.

Meskipun Anda harus menerapkan kontrol untuk membantu melindungi Anda dari serangan pencurian info masuk, Anda juga harus mengidentifikasi akun di lingkungan Anda yang kemungkinan besar ditargetkan oleh penyerang, dan menerapkan kontrol autentikasi yang kuat untuk akun tersebut. Jika akun Anda yang paling istimewa menggunakan autentikasi faktor tunggal seperti nama pengguna dan kata sandi (keduanya adalah "sesuatu yang Anda ketahui," yang merupakan salah satu faktor autentikasi), akun tersebut dilindungi dengan lemah. Semua yang dibutuhkan penyerang adalah pengetahuan tentang nama pengguna dan pengetahuan tentang kata sandi yang terkait dengan akun, dan serangan pass-the-hash tidak diperlukan penyerang dapat mengautentikasi sebagai pengguna ke sistem apa pun yang menerima kredensial faktor tunggal.

Meskipun menerapkan autentikasi multifaktor tidak melindungi Anda dari serangan pass-the-hash, menerapkan autentikasi multifaktor dalam kombinasi dengan sistem yang dilindungi dapat. Informasi selengkapnya tentang menerapkan sistem yang dilindungi disediakan dalam Menerapkan Host Administratif Aman, dan opsi autentikasi dibahas di bagian berikut.

Kontrol Autentikasi Umum

Jika Anda belum menerapkan autentikasi multifaktor seperti kartu pintar, pertimbangkan untuk melakukannya. Kartu pintar menerapkan perlindungan kunci privat yang diberlakukan perangkat keras dalam pasangan kunci publik-privat, mencegah kunci privat pengguna diakses atau digunakan kecuali pengguna menyajikan PIN, kode sandi, atau pengidentifikasi biometrik yang tepat ke kartu pintar. Bahkan jika PIN atau kode sandi pengguna dicegat oleh pencatat penekanan kunci di komputer yang disusupi, agar penyerang menggunakan kembali PIN atau kode sandi, kartu juga harus ada secara fisik.

Dalam kasus di mana kata sandi yang panjang dan kompleks terbukti sulit diimplementasikan karena ketahanan pengguna, kartu pintar menyediakan mekanisme di mana pengguna dapat menerapkan VPN atau kode sandi yang relatif sederhana tanpa kredensial rentan terhadap serangan brute force atau tabel pelangi. PIN kartu pintar tidak disimpan di Direktori Aktif atau dalam database SAM lokal, meskipun hash kredensial mungkin masih disimpan dalam memori yang dilindungi LSASS di komputer tempat kartu pintar telah digunakan untuk autentikasi.

Kontrol Tambahan untuk Akun VIP

Manfaat lain dari penerapan kartu pintar atau mekanisme autentikasi berbasis sertifikat lainnya adalah kemampuan untuk memanfaatkan Jaminan Mekanisme Autentikasi untuk melindungi data sensitif yang dapat diakses oleh pengguna VIP. Jaminan Mekanisme Autentikasi tersedia di domain tempat tingkat fungsi disetel ke Windows Server 2012 atau Windows Server 2008 R2. Ketika diaktifkan, Jaminan Mekanisme Autentikasi menambahkan keanggotaan grup global yang ditunjuk administrator ke token Kerberos pengguna saat kredensial pengguna diautentikasi selama masuk menggunakan metode masuk berbasis sertifikat.

Hal ini memungkinkan administrator sumber daya mengontrol akses ke sumber daya, seperti file, folder, dan printer, berdasarkan apakah pengguna masuk menggunakan metode masuk berbasis sertifikat, selain jenis sertifikat yang digunakan. Misalnya, ketika pengguna masuk dengan menggunakan kartu pintar, akses pengguna ke sumber daya di jaringan dapat ditentukan berbeda dari apa aksesnya adalah ketika pengguna tidak menggunakan kartu pintar (yaitu, ketika pengguna masuk dengan memasukkan nama pengguna dan kata sandi). Untuk informasi selengkapnya tentang Jaminan Mekanisme Autentikasi, lihat Jaminan Mekanisme Autentikasi untuk AD DS di Panduan Langkah demi Langkah Windows Server 2008 R2.

Mengonfigurasi Autentikasi Akun Istimewa

Di Direktori Aktif untuk semua akun administratif, aktifkan wajibkan kartu pintar untuk atribut masuk interaktif, dan audit untuk perubahan pada (minimal), salah satu atribut pada tab Akun untuk akun (misalnya, cn, nama, sAMAccountName, userPrincipalName, dan userAccountControl) objek pengguna administratif.

Meskipun mengatur Memerlukan kartu pintar untuk masuk interaktif pada akun mengatur ulang kata sandi akun ke nilai acak 120 karakter dan memerlukan kartu pintar untuk masuk interaktif, atribut masih dapat ditimpa oleh pengguna dengan izin yang memungkinkan mereka mengubah kata sandi pada akun, dan akun kemudian dapat digunakan untuk membuat logon non-interaktif hanya dengan nama pengguna dan kata sandi.

Dalam kasus lain, tergantung pada konfigurasi akun di Direktori Aktif dan pengaturan sertifikat di Active Directory Certificate Services (AD CS) atau atribut PKI pihak ketiga, Nama Prinsipal Pengguna (UPN) untuk akun administratif atau VIP dapat ditargetkan untuk jenis serangan tertentu, seperti yang dijelaskan di sini.

Pembajakan UPN untuk Spoofing Sertifikat

Meskipun diskusi menyeluruh tentang serangan terhadap infrastruktur kunci publik (PSI) berada di luar cakupan dokumen ini, serangan terhadap PSI publik dan privat telah meningkat secara eksponensial sejak 2008. Pelanggaran PKI publik telah dipublikasikan secara luas, tetapi serangan terhadap PKI internal organisasi mungkin bahkan lebih lancar. Salah satu serangan tersebut memanfaatkan Direktori Aktif dan sertifikat untuk memungkinkan penyerang memalsukan kredensial akun lain dengan cara yang dapat sulit dideteksi.

Ketika sertifikat disajikan untuk autentikasi ke sistem yang bergabung dengan domain, konten atribut Subjek atau Nama Alternatif Subjek (SAN) dalam sertifikat digunakan untuk memetakan sertifikat ke objek pengguna di Direktori Aktif. Bergantung pada jenis sertifikat dan bagaimana sertifikat dibuat, atribut Subjek dalam sertifikat biasanya berisi nama umum (CN) pengguna, seperti yang ditunjukkan pada cuplikan layar berikut.

Secara default, Active Directory membangun CN pengguna dengan menggabungkan nama depan akun + " "+ nama belakang. Namun, komponen CN objek pengguna di Direktori Aktif tidak diperlukan atau dijamin unik, dan memindahkan akun pengguna ke lokasi yang berbeda di direktori mengubah nama khusus akun (DN), yang merupakan jalur lengkap ke objek di direktori, seperti yang ditunjukkan di panel bawah cuplikan layar sebelumnya.

Karena nama subjek sertifikat tidak dijamin statis atau unik, konten Nama Alternatif Subjek sering digunakan untuk menemukan objek pengguna di Direktori Aktif. Atribut SAN untuk sertifikat yang dikeluarkan untuk pengguna dari otoritas sertifikasi perusahaan (CA terintegrasi Direktori Aktif) biasanya berisi UPN atau alamat email pengguna. Karena UPN dijamin unik di forest AD DS, menemukan objek pengguna oleh UPN biasanya dilakukan sebagai bagian dari autentikasi, dengan atau tanpa sertifikat yang terlibat dalam proses autentikasi.

Penggunaan UPN dalam atribut SAN dalam sertifikat autentikasi dapat dimanfaatkan oleh penyerang untuk mendapatkan sertifikat penipuan. Jika penyerang telah mengorbankan akun yang memiliki kemampuan untuk membaca dan menulis UPN pada objek pengguna, serangan diimplementasikan sebagai berikut:

Atribut UPN pada objek pengguna (seperti pengguna VIP) untuk sementara diubah ke nilai yang berbeda. Atribut nama akun SAM dan CN juga dapat diubah saat ini, meskipun ini biasanya tidak diperlukan karena alasan yang dijelaskan sebelumnya.

Ketika atribut UPN pada akun target telah diubah, akun pengguna kedaluwarsa yang diaktifkan, atau atribut UPN akun pengguna yang baru dibuat diubah ke nilai yang awalnya ditetapkan ke akun target. Akun pengguna kedaluarsa dan diaktifkan adalah akun yang belum masuk untuk jangka waktu yang lama, tetapi belum dinonaktifkan. Mereka ditargetkan oleh penyerang yang berniat "bersembunyi di depan mata" karena alasan berikut:

1. Karena akun diaktifkan, tetapi belum digunakan baru-baru ini, menggunakan akun tidak mungkin memicu pemberitahuan cara mengaktifkan akun pengguna yang dinonaktifkan mungkin.
2. Penggunaan akun yang ada tidak memerlukan pembuatan akun pengguna baru yang mungkin diperhatikan oleh staf administratif.
3. Akun pengguna kedaluarsa yang masih diaktifkan biasanya merupakan anggota dari berbagai grup keamanan dan diberikan akses ke sumber daya di jaringan, menyederhanakan akses dan "memadukan" ke populasi pengguna yang ada.

Akun pengguna tempat UPN target sekarang telah dikonfigurasi digunakan untuk meminta satu atau beberapa sertifikat dari Layanan Sertifikat Direktori Aktif.

Ketika sertifikat telah diperoleh untuk akun penyerang, UPN pada akun "baru" dan akun target dikembalikan ke nilai aslinya.

Penyerang sekarang memiliki satu atau beberapa sertifikat yang dapat disajikan untuk autentikasi ke sumber daya dan aplikasi seolah-olah pengguna adalah pengguna VIP yang akunnya dimodifikasi sementara. Meskipun diskusi lengkap tentang semua cara di mana sertifikat dan PKI dapat ditargetkan oleh penyerang berada di luar cakupan dokumen ini, mekanisme serangan ini disediakan untuk menggambarkan mengapa Anda harus memantau akun istimewa dan VIP di AD DS untuk perubahan, terutama untuk perubahan pada salah satu atribut pada tab Akun untuk akun (misalnya, cn, name, sAMAccountName, userPrincipalName, dan userAccountControl). Selain memantau akun, Anda harus membatasi siapa yang dapat memodifikasi akun menjadi sekumpulan pengguna administratif sekecil mungkin. Demikian juga, akun pengguna administratif harus dilindungi dan dipantau untuk perubahan yang tidak sah.