Windows Server 2025 / Fungsi AD CS dan perencanaan PKI internal

Active Directory Certificate Services (AD CS), layanan sertifikat Active Directory, menerbitkan dan mengelola sertifikat organisasi. Sebelum memasangnya, tentukan pihak yang dipercaya, siapa yang boleh meminta dan menyetujui sertifikat, serta penanggung jawab pencabutan, perpanjangan, dan pemulihan.

Menilai kebutuhan CA internal

AD CS memungkinkan organisasi menjalankan otoritas sertifikat (Certificate Authority, CA) dalam infrastruktur kunci publik (Public Key Infrastructure, PKI). CA menandatangani sertifikat yang mengaitkan identitas dengan kunci publik; PKI juga mencakup kebijakan, perlindungan kunci, distribusi kepercayaan, dan prosedur operasional. Klien harus memercayai penerbit dan memvalidasi nama, tujuan penggunaan, masa berlaku, serta kondisi lain yang relevan. Keberadaan berkas sertifikat saja belum cukup.

Kebutuhan memperpanjang sertifikat layanan internal secara berulang atau mengautentikasi perangkat terkelola dapat menjadi alasan membangun PKI organisasi. Namun, CA internal tidak otomatis dipercaya semua peramban atau perangkat luar. Untuk layanan publik dengan klien yang tidak dikelola, sertifikat yang dipercaya secara publik bagi nama yang dikuasai mungkin lebih sesuai. Bandingkan kebutuhan dengan kemampuan operasional; sertifikat bertanda tangan sendiri untuk laboratorium tidak membentuk PKI produksi.

Gambaran umum AD CS menjelaskan fungsinya. Sebelum membuat CA baru, inventarisasi PKI yang sudah ada, tim penanggung jawab, dan layanan penerbitan yang disetujui. Misalnya, untuk mengembangkan uji HTTPS pada WEB1 menjadi layanan internal, catat nama DNS, klien pengguna, pemilik layanan, batas waktu perpanjangan, dan penerbit lama yang dapat melayaninya. Satu situs web tidak otomatis memerlukan CA baru.

Merancang hierarki dan batas kepercayaan

CA akar luring dengan CA penerbit daring merupakan salah satu pilihan desain, bukan aturan universal. CA akar menjadi jangkar kepercayaan tertinggi, sedangkan CA bawahan menerbitkan sertifikat yang direncanakan. Memisahkan akar dari jaringan mengurangi paparan sehari-hari, tetapi memerlukan prosedur aktivasi terkendali, publikasi, perpanjangan, dan pemulihan. Tingkat tambahan juga menambah dependensi dan pekerjaan. Nilailah berdasarkan skala, ancaman, dan kemampuan nyata untuk mengoperasikannya.

Pertimbangan desain PKI membantu menetapkan nama CA dan server, penyedia kriptografi yang kompatibel, perlindungan kunci, masa berlaku, dan alamat publikasi sebelum pemasangan. Nama server berbeda dengan nama CA; mengganti nama server CA yang sudah dipasang bukan perubahan rutin. Tinjau batas administrasi dan perlindungan kunci sebelum menggabungkan CA dengan pengontrol domain, karena penggabungan itu menyatukan cakupan hak istimewa dan pemulihan.

Membatasi templat dan izin pendaftaran

Templat menentukan tujuan, kebijakan kunci, masa berlaku, dan syarat pendaftaran. Extended Key Usage (EKU), penggunaan kunci yang diperluas, mengidentifikasi tujuan seperti autentikasi server atau klien. Menurut panduan pengelolaan templat AD CS, CA perusahaan menggunakan templat yang tersimpan dalam Active Directory Domain Services (AD DS), layanan domain Active Directory; CA mandiri tidak menggunakannya. Membuat templat, memublikasikannya agar diterbitkan oleh CA, dan memberi izin pendaftaran adalah keputusan berbeda. Penerbitan sertifikat autentikasi dengan cakupan terlalu luas dapat memungkinkan penyamaran identitas.

• Pisahkan pemohon dari pihak yang menyetujui dan menerbitkan. Tentukan kelompok khusus dan siapa yang boleh mengubah kebijakan; jangan memakai satu akun bersama untuk seluruh fungsi.
• Tentukan apakah pemohon boleh memasukkan nama sendiri dan siapa yang memeriksa haknya atas nama itu. Pada sertifikat web, nama yang disetujui harus sesuai layanan yang dituju, bukan sembarang identitas yang dimasukkan bebas.
• Batasi penggunaan kunci privat dan jelaskan alasan jika kunci harus dapat diekspor. Bedakan kunci server, kunci CA, dan materi pemulihan; dokumentasikan penerima dan pengamanannya sebelum mengizinkan ekspor.
• Batasi pendaftaran otomatis pada kelompok dan tujuan yang disetujui. Rencanakan uji terbatas bagi pemohon yang diizinkan maupun ditolak, lengkap dengan catatan galat, sertifikat terbitan, dan peringatan sebelum memperluas cakupan.

Tinjau risikonya sebelum memberi izin luas kepada Authenticated Users atau kelompok besar lainnya. Dokumentasikan pemohon, administrator templat, administrator CA, pengelola sertifikat yang menyetujui atau mencabut, dan auditor; pisahkan tugas sesuai risiko. Panduan keamanan, delegasi, dan audit CA membedakan pengendalian tersebut. Membaca bukti tidak memerlukan hak administrasi penuh. Tentukan operasi yang harus diizinkan dan ditolak dalam pengujian, serta perubahan atau penerbitan yang harus memicu peringatan untuk ditinjau.

Mengoperasikan publikasi pencabutan dan perpanjangan

Rencanakan pencabutan ketika kunci bocor, pengguna keluar, atau server dihentikan. Certificate Revocation List (CRL), daftar pencabutan sertifikat, memublikasikan sertifikat yang dicabut. Authority Information Access (AIA), akses informasi otoritas, membantu menemukan informasi penerbit seperti sertifikat CA; CRL Distribution Points (CDP) menunjukkan lokasi pengambilan CRL. Validasi rantai dan status pencabutan merupakan pemeriksaan berbeda. Tentukan jalur yang nyata, penerbit informasi, interval publikasi, kedaluwarsa daftar, dan klien yang harus dapat mengaksesnya.

DNS atau publikasi LDAP yang hanya tersedia di jaringan internal mungkin tidak menjangkau klien eksternal atau perangkat di luar domain. Periksa akses menggunakan perangkat dan konteks sebenarnya, termasuk proksi dan pembatasan jaringan. Menghentikan CA tidak langsung mencabut semua sertifikat terbitan, tetapi mengganggu fungsi berbeda seperti penerbitan, perpanjangan, atau pembaruan informasi pencabutan. Masa berlaku CRL, cache, dan kebijakan aplikasi memengaruhi hasilnya; sertifikat yang belum kedaluwarsa tidak menjamin layanan tetap berjalan. Perubahan URL publikasi berlaku pada sertifikat baru, sedangkan sertifikat lama mungkin tetap memerlukan lokasi sebelumnya.

Koordinasikan perpanjangan CA akar, CA penerbit, dan sertifikat layanan. Meminta masa berlaku panjang tidak mengesampingkan sisa masa berlaku penerbit atau kebijakan yang diterapkan. Catat dependensi, pemilik, waktu tindakan, dan cara memvalidasi rantai baru. Setelah memperpanjang layanan, periksa sertifikat yang benar-benar disajikan dan pengikatannya, bukan hanya objek baru dalam penyimpanan sertifikat. Jika kunci atau rantai CA berubah, rencanakan distribusi dan kompatibilitas klien sebelum menghapus yang lama.

Mendokumentasikan perlindungan kunci dan pemulihan

Kebocoran kunci privat CA memengaruhi seluruh cakupan kepercayaannya. Pertimbangkan Hardware Security Module (HSM), perangkat khusus untuk perlindungan dan operasi kunci, bersama pembatasan akses administratif dan pemisahan tanggung jawab. HSM tidak menggantikan prosedur atau cadangan yang dapat dipulihkan. Panduan pencadangan dan migrasi CA mencakup basis data, kunci privat, konfigurasi registri, CAPolicy.inf jika digunakan, serta daftar templat yang ditugaskan pada CA perusahaan. Templat dan asosiasinya dalam AD DS tidak tercakup hanya oleh cadangan basis data CA. Rancang cadangan terlindungi, penyimpanan kata sandi, dan pemulihan terisolasi; untuk kunci HSM ikuti pula metode yang didukung vendornya. Salinan sertifikat publik bukan cadangan kunci privat.

1. Inventarisasi pengguna sertifikat, tujuan, dan perkiraan permintaan. Untuk setiap layanan, catat nama, perangkat serta pengguna klien, penerbit saat ini, penanggung jawab, dependensi jaringan, dan kebutuhan kesinambungan.
2. Tetapkan pemilik dan bandingkan penggunaan PKI atau penerbitan resmi yang ada dengan pembangunan baru. Dokumentasikan alasan, sumber daya operasional, dan keputusan tertunda, bukan sekadar pilihan di pemasang.
3. Rancang akar dan penerbit, perlindungan kunci, templat jika berlaku, izin, serta distribusi kepercayaan. Jelaskan siapa yang dapat meminta, menyetujui, mengubah, dan mengaudit, serta cara menarik kepercayaan saat layanan berakhir.
4. Tentukan publikasi CRL/AIA, pemilik perpanjangan, peringatan, cadangan, dan pemulihan terisolasi. Catat lokasi serta bukti yang perlu diperiksa, termasuk keberlanjutan URL lama dan pemulihan materi terlindungi.
5. Validasi dalam lingkungan terpisah permintaan yang sah dan tidak sah, nama yang diterima dan ditolak, perpanjangan, pencabutan menurut aplikasi, serta pemulihan cadangan. Dokumentasikan hasil harapan, hasil pengamatan, dan tindakan jika gagal; satu penerbitan berhasil tidak membuktikan seluruh kondisi lain.

Hasil latihan ini berupa dokumen desain yang dapat ditinjau, bukan CA yang terpasang. Jangan memasang AD CS di DC1 atau membagikan akar uji ke perangkat nyata sebagai bagian latihan. Sebelum memutuskan penerapan, pastikan penanggung jawab, prosedur yang dapat dipelihara, bukti penerimaan, dan rencana pencabutan kepercayaan atau transisi layanan telah jelas. Jika belum diketahui siapa yang memublikasikan CRL, memulihkan kunci, atau menangani perpanjangan gagal, catat keputusan yang masih terbuka sebelum menyetujui pemasangan.