Halaman ini diterjemahkan oleh Cloud Translation API.

Praktik terbaik untuk Certificate Manager

Halaman ini menjelaskan berbagai praktik terbaik untuk mengonfigurasi dan mengelola sertifikat di Google Cloud dengan menggunakan Certificate Manager dan Certificate Authority Service (CA Service). Halaman ini menjelaskan cara mendesain arsitektur pengelolaan sertifikat Anda.

Sebelum membaca halaman ini, pastikan Anda sudah memahami halaman Ringkasan Certificate Manager dan Ringkasan Certificate Authority Service.

Mendesain arsitektur pengelolaan sertifikat Anda

Saat merancang strategi pengelolaan sertifikat perusahaan, Anda harus mempertimbangkan kasus penggunaan utama organisasi Anda dan seluruh siklus proses sertifikat Anda. Keputusan ini memengaruhi biaya, biaya operasional, dan kemudahan penerapan kemampuan pengelolaan sertifikat seperti penerbitan, pencabutan, dan rotasi.

Bagian berikut menjelaskan rekomendasi kami untuk setiap pilihan desain.

Pilih jenis sertifikat

Saat membuat sertifikat, Anda harus memastikan untuk memilih jenis sertifikat yang sesuai untuk kasus penggunaan Anda, bergantung pada persyaratan aplikasi dan kebijakan keamanan organisasi Anda.

Untuk menganalisis jenis sertifikat yang mungkin paling cocok untuk Anda, lihat diagram alur berikut:

Menilai jenis sertifikat yang akan dipilih. — Menilai jenis sertifikat yang akan dipilih (klik untuk memperbesar).

Berikut beberapa link dokumentasi bermanfaat untuk topik yang disebutkan dalam diagram alur:

Menyederhanakan hierarki Layanan CA pribadi Anda

Sebaiknya Anda menjaga hierarki Layanan CA Anda sesederhana mungkin untuk memastikan kelancaran operasi dan pemecahan masalah. Anda harus menyimpan certificate authority (CA) root Anda di project Google-nya sendiri. CA root menandatangani beberapa CA perantara, dan CA tersebut kemudian menerbitkan sertifikat akhir.

Struktur hierarkis datar ini meningkatkan transparansi, menyederhanakan proses pencabutan sertifikat, dan mengurangi kemungkinan kesalahan konfigurasi. Meskipun CA Service adalah layanan regional, CA root di satu region dapat menandatangani CA subordinat yang berada di region lain.

Ikuti praktik terbaik berikut dalam hierarki Layanan CA Anda seperti yang ditunjukkan dalam diagram:

Isolasi root CA Anda dalam Google Cloud project-nya sendiri untuk menandatangani CA penerbit.
Buat CA penerbit di kumpulan CA yang dihosting di project terpisah. Hosting kumpulan ini dalam project terpisah dan segmenkan berdasarkan lokasi geografis (region), siklus proses pengembangan software (pengembangan, produksi, pengujian), atau kasus penggunaan tertentu.
Konfigurasi Pengelola Sertifikat untuk menggunakan kumpulan CA penerbit yang dapat menerbitkan sertifikat tepercaya secara pribadi untuk resource yang didukung.

Desain hierarki CA yang direkomendasikan. — Desain yang direkomendasikan untuk hierarki CA Anda (klik untuk memperbesar).

Menggunakan cakupan nama host yang komprehensif

Sebaiknya pastikan sertifikat Anda memberikan cakupan nama host yang memadai untuk semua domain dan subdomain yang perlu dilindungi oleh layanan Anda. Cakupan nama host yang tidak memadai dapat menyebabkan peringatan keamanan bagi pengguna, gangguan layanan, dan pengalaman pengguna yang negatif.

Hindari penggunaan satu sertifikat untuk beberapa domain. Jika sertifikat tunggal gagal diperpanjang atau terhapus secara tidak sengaja, semua domain yang dicakupnya akan menjadi tidak aman. Sebaiknya buat sertifikat yang berbeda untuk domain yang berbeda.

Jika Anda berencana menambahkan subdomain atau layanan baru nanti, gunakan karakter wildcard untuk menyertakan subdomain atau layanan dalam sertifikat Anda sejak awal. Misalnya, sertifikat karakter pengganti untuk *.myorg.example.com hanya mengamankan tingkat subdomain pertama, tetapi tidak mengamankan tingkat subdomain yang lebih dalam seperti sub.subdomain.myorg.example.com.

Menggunakan sertifikat yang dikelola Google

Untuk pengelolaan sertifikat publik yang efisien dan kemudahan penggunaan, sebaiknya gunakan sertifikat yang dikelola Google. Pendekatan ini secara signifikan mengurangi overhead operasional, mengotomatiskan tugas seperti rotasi sertifikat dan menghilangkan risiko yang terkait dengan perpanjangan manual.

Selain itu, sertifikat yang dikelola Google menawarkan integrasi yang lancar dengan layananGoogle Cloud lainnya. Sertifikat yang dikelola Google berlaku selama 90 hari, dan proses perpanjangan dimulai sekitar satu bulan sebelum masa berlakunya berakhir.

Menskalakan dan meningkatkan performa sertifikat Anda

Bagian berikut menjelaskan praktik terbaik untuk menskalakan sertifikat dan meningkatkan performa tindakan terkait sertifikat, seperti penyediaan dan perpanjangan.

Menerapkan deployment terdesentralisasi untuk Certificate Manager

Gunakan Pengelola Sertifikat berdasarkan per project dan per lokasi, yang berarti bahwa sertifikat Anda disimpan di project yang sama dengan resource terkaitnya di region yang sama. Strategi ini meningkatkan keandalan dengan mencegah penggunaan ulang sertifikat di berbagai region dan secara efektif meminimalkan dampak jika terjadi pemadaman listrik regional.

Selain itu, karena kuota dan batas diterapkan di level project, men-deploy Certificate Manager di beberapa project akan meningkatkan kuota keseluruhan Anda. Google Cloud Hal ini karena penggunaan resource dalam satu project tidak memengaruhi kuota yang tersedia di project lain.

Menggunakan sertifikat dengan kunci ECDSA

Bagian ini membahas alasan kami merekomendasikan ECDSA daripada RSA sebagai praktik terbaik untuk kunci penandatanganan sertifikat.

Jenis kunci yang akan digunakan

ECDSA P-256 adalah pilihan jenis kunci yang direkomendasikan untuk sebagian besar sertifikat TLS karena ECDSA P-256 menawarkan keamanan kriptografi yang kuat, performa yang sangat baik untuk operasi penandatanganan, dan penggunaan bandwidth jaringan yang efisien.

Beberapa kemungkinan alasan untuk menggunakan jenis kunci sertifikat lain adalah sebagai berikut:

Jika Anda perlu mendukung klien lama yang tidak mendukung sertifikat ECDSA, Anda dapat memberikan sertifikat RSA-2048 selain sertifikat ECDSA P-256.
Jika Anda memiliki persyaratan kepatuhan khusus yang mengharuskan Anda menggunakan ukuran kunci yang lebih besar atau jenis kunci tertentu, Anda dapat menggunakan kunci ECDSA P-384, RSA-2048, RSA-3072, dan RSA-4096.

Alasan memilih ECDSA daripada RSA

Keunggulan utama ECDSA terletak pada kemampuannya untuk memberikan tingkat keamanan kriptografi yang setara dengan kunci yang jauh lebih kecil dibandingkan dengan RSA. Efisiensi ini menghasilkan manfaat performa dan resource yang nyata. Kunci yang lebih kecil tidak berarti keamanan yang lebih lemah—ECDSA didasarkan pada masalah logaritma diskrit kurva elips, yang memberikan keamanan yang lebih kuat per unit kunci, dan dalam beberapa kasus efisiensi komputasi yang lebih baik dibandingkan dengan RSA.

Contoh:

Kunci ECDSA 256-bit memberikan tingkat keamanan yang serupa dengan kunci RSA-3072.
Kunci ECDSA 384-bit memberikan tingkat keamanan yang lebih tinggi daripada ukuran kunci RSA yang didukung secara luas.

Manfaat utama ECDSA:

Performa: Operasi penandatanganan ECDSA jauh lebih intensif secara komputasi daripada operasi RSA yang memberikan tingkat keamanan yang setara. Hal ini mengurangi beban dan latensi CPU, yang sangat penting untuk sistem ber-throughput tinggi atau yang sensitif terhadap latensi.
Efisiensi: kunci dan tanda tangan yang lebih kecil memerlukan lebih sedikit bandwidth dan penyimpanan, yang sangat bermanfaat untuk lingkungan dengan keterbatasan resource seperti perangkat seluler dan IoT.

Anda dapat membuat kebijakan organisasi kustom berikut untuk mewajibkan penggunaan jenis kunci tertentu dalam sertifikat Anda. Hal ini hanya berlaku untuk sertifikat yang dikelola Google dari CA Service (sertifikat yang dikelola kepercayaan pribadi), bukan untuk sertifikat yang dikelola sendiri dan sertifikat yang dikelola Google dengan kepercayaan publik.

    name: organizations/ORGANIZATION_ID/customConstraints/custom.restrictAlgorithm \
    resourceTypes: \
    - certificatemanager.googleapis.com/CertificateIssuanceConfig \
    methodTypes: \
    - CREATE \
    - UPDATE \
    condition: "resource.keyAlgorithm == 'ECDSA_P256'" \
    actionType: ALLOW \
    displayName: Allow only ECDSA_P256 in Certificate Issuance configs \
    description: Only ECDSA_P256 certificates are allowed from CA Service.

Menggunakan kumpulan CA untuk menerbitkan sertifikat dari CA pribadi

Sebaiknya gunakan kumpulan CA untuk CA penerbit Anda. Kumpulan CA adalah kumpulan beberapa CA dengan kebijakan penerbitan sertifikat dan kebijakan Identity and Access Management (IAM) yang sama. Menggunakan kumpulan CA akan meningkatkan total kueri per detik (QPS) efektif dengan menyeimbangkan beban dan mendistribusikan permintaan sertifikat masuk ke semua CA yang diaktifkan dalam kumpulan. Hal ini meningkatkan performa tanpa memengaruhi workload atau perubahan sisi klien.

Kumpulan CA menyediakan satu endpoint untuk penerbitan dan pengambilan sertifikat. Anda dapat menggunakan kumpulan CA untuk merotasi CA Anda secara aman tanpa menyebabkan periode nonaktif karena masa berlaku sertifikat berakhir atau sertifikat disusupi.

Menggunakan peta sertifikat

Untuk memastikan skalabilitas yang optimal, sebaiknya gunakan peta sertifikat dengan resource yang didukung. Peta sertifikat dirancang agar dapat diskalakan, mendukung ribuan entri sertifikat secara default dan mampu menangani jutaan sertifikat. Jika digunakan oleh load balancer, entri peta sertifikat akan lebih diprioritaskan daripada sertifikat lain, seperti sertifikat SSL Compute Engine.

Peta sertifikat juga memungkinkan Anda mengonfigurasi logika pemilihan sertifikat. Misalnya, selama handshake, jika nama host klien tidak cocok dengan entri apa pun dalam peta sertifikat yang disediakan, load balancer akan menampilkan sertifikat utama.

Memilih jenis otorisasi domain yang benar

Untuk menerbitkan sertifikat yang dikelola Google, Anda dapat membuktikan kepemilikan domain dengan menggunakan otorisasi load balancer atau otorisasi DNS.

Tabel berikut menjelaskan pertimbangan untuk setiap pendekatan:

Fitur	Otorisasi load balancer	Otorisasi DNS
Kompleksitas penyiapan	Tidak memerlukan langkah konfigurasi tambahan atau perubahan pada konfigurasi DNS Anda.	Memerlukan Anda untuk membuat otorisasi DNS dan menambahkan data CNAME yang sesuai ke konfigurasi DNS Anda.
Keamanan jaringan	Load balancer harus dapat diakses sepenuhnya menggunakan internet di port `443`, termasuk konfigurasi DNS untuk semua domain yang ditayangkan oleh sertifikat. Otorisasi load balancer tidak berfungsi dengan konfigurasi lain.	Otorisasi DNS berfungsi dengan konfigurasi yang sangat kompleks, seperti port selain 443, dan lapisan CDN di depan proxy target.
Kecepatan penyediaan	Kecepatan penyediaan yang lebih cepat. Anda dapat menyediakan sertifikat hanya setelah load balancer disiapkan sepenuhnya dan melayani traffic jaringan.	Anda dapat menyediakan sertifikat terlebih dahulu, sebelum proxy target siap melayani traffic jaringan.
Sertifikat karakter pengganti	Tidak didukung.	Didukung.

Mengotomatiskan rotasi sertifikat yang dikelola sendiri

Tidak seperti sertifikat yang dikelola Google, sertifikat yang dikelola sendiri harus diganti secara manual sebelum masa berlakunya habis. Sebaiknya otomatiskan proses ini dengan menggunakan penawaran Pengelolaan Siklus Proses Sertifikat (CLM) pilihan Anda. Hal ini membantu mengurangi kesalahan, waktu henti, dan memastikan efisiensi operasional.

Anda juga dapat menggunakan peta sertifikat untuk mengatur rotasi sertifikat yang lancar. Proses ini mencakup langkah-langkah berikut:

Pantau masa berlaku sertifikat menggunakan Cloud Monitoring dan pemberitahuan. Sebaiknya buat pemberitahuan untuk sertifikat yang akan berakhir dalam 15 hingga 30 hari ke depan.
Buat permintaan penandatanganan sertifikat (CSR) dan kunci pribadi untuk dikirimkan ke CA Anda.
Kirim CSR dan kunci pribadi Anda ke CA, lalu ambil sertifikat baru.
Upload sertifikat baru ke Certificate Manager ke peta sertifikat yang sesuai.
- Jika nama domain dalam sertifikat baru cocok dengan sertifikat yang akan segera berakhir, gunakan metode UpdateCertificate pada resource sertifikat yang ada.
- Jika sertifikat baru memiliki nama domain yang berbeda, gunakan terlebih dahulu metode CreateCertificateRequest dengan file PEM (privacy-enhanced mail) baru untuk membuatnya. Kemudian, gunakan metode UpdateCertificateMapEntry untuk mengganti referensi sertifikat lama di peta sertifikat dengan sertifikat baru.
Penting: Anda harus menyelesaikan proses ini dalam satu panggilan API tanpa menyebabkan periode nonaktif.

Menerapkan kontrol akses yang sesuai

Sebaiknya pertimbangkan prinsip hak istimewa terendah dan pemisahan tugas saat mengonfigurasi kontrol akses Anda. Bagian berikut menjelaskan rekomendasi ini secara lebih mendetail.

Menerapkan prinsip hak istimewa terendah

Saat menetapkan izin untuk mengelola sertifikat, pertimbangkan prinsip hak istimewa terendah dan berikan izin minimum yang diperlukan untuk melakukan tugas. Sebaiknya hindari penggunaan peran IAM dasar. Sebagai gantinya, berikan peran bawaan atau peran khusus Certificate Manager dan CA Service untuk memitigasi risiko insiden keamanan yang terkait dengan akses yang memiliki terlalu banyak hak istimewa.

Merencanakan pemisahan tugas

Sebaiknya Anda mempertahankan identitas dan izin yang berbeda untuk administrator sertifikat dan mereka yang memiliki peran penerbit sertifikat atau pemohon sertifikat. Untuk melakukannya, buat grup administrator dan pemohon terpisah di bagian atas hierarki resource untuk pengguna Anda.

Pastikan grup administrator Anda bertanggung jawab untuk melakukan tindakan berikut:

Mengelola dan memelihara infrastruktur sertifikat Anda seperti penyediaan CA.
Konfigurasi template sertifikat.
Mengelola daftar pencabutan sertifikat (CRL) dan protokol status sertifikat online (OCSP) Anda.
Menerapkan kebijakan keamanan untuk CA Anda.

Untuk project yang menghosting CA root, hindari pemberian peran dasar seperti Pemilik (roles/owner), Editor (roles/editor), dan Admin Layanan CA (roles/privateca.admin) kepada pengguna atau grup mana pun. Praktik ini mencegah penghapusan yang tidak disengaja, kesalahan konfigurasi, dan eksposur berlebihan. Sebagai gantinya, gunakan Privileged Access Manager (PAM) untuk akses tepat waktu (JIT) sesuai kebutuhan dengan justifikasi dan persetujuan setelah CA root diinstal dan dikonfigurasi.

Pastikan grup pemohon bertanggung jawab atas operasi sehari-hari dalam memproses permintaan sertifikat dan menerbitkan sertifikat berdasarkan template yang telah ditentukan sebelumnya.

Tabel berikut mencantumkan peran IAM yang biasanya dikaitkan dengan berbagai fungsi tugas:

Persona	Deskripsi	Peran IAM
Administrator sertifikat	Menyiapkan dan mengelola infrastruktur CA dan sertifikat.	Pemilik Certificate Manager (`roles/certificatemanager.owner`), Admin Layanan CA (`roles/privateca.admin`)
Peminta sertifikat	Minta sertifikat untuk beban kerja.	Certificate Authority Service Certificate Requester (`roles/privateca.certificateRequester`)
Beban kerja (akun layanan otomatisasi)	Digunakan oleh workload atau dalam pipeline untuk meminta sertifikat.	Certificate Authority Service Workload Certificate Requester (`roles/privateca.workloadCertificateRequester`)
Engineer keamanan atau pemilik PKI	Mengelola kebijakan, pencabutan, dan siklus proses sertifikat.	CA Service Operation Manager (`roles/privateca.caManager`), Certificate Authority Service Certificate Manager (`roles/privateca.certificateManager`)
Engineer DevOps atau platform	Mengelola deployment sertifikat di load balancer, dan lainnya.	Certificate Manager Editor (`roles/certificatemanager.editor`)
Auditor atau kepatuhan	Pantau sertifikat dan penggunaannya.	Pelihat Certificate Manager (`roles/certificatemanager.viewer`), Auditor Certificate Authority Service (`roles/privateca.auditor`)

Menggunakan otorisasi DNS per project untuk deployment multi-region dan multi-cloud

Sebaiknya gunakan pendekatan otorisasi DNS per project untuk mengelola beberapa otorisasi secara independen untuk project di beberapa region, beberapa cloud, dan di seluruh siklus proses pengembangan software (SDLC).

Mengelompokkan otorisasi DNS membantu memastikan bahwa setiap project mempertahankan serangkaian data dan izin DNS-nya sendiri yang berbeda. Tingkat kontrol ini memungkinkan setiap project mengelola konfigurasi DNS-nya secara mandiri, tanpa mengganggu atau terpengaruh oleh operasi project lain. Misalnya, tim pengembangan dapat bereksperimen dengan konfigurasi DNS baru untuk aplikasi tertentu tanpa menimbulkan dampak buruk pada sistem produksi atau proyek lain yang sedang berjalan.

Menggunakan data CAA untuk melindungi domain Anda

Data Certification Authority Authorization (CAA) adalah mekanisme keamanan di Domain Name System (DNS). Data CAA memberi pemilik domain kontrol penuh untuk mengonfigurasi Certificate Authority (CA) publik yang dapat menerbitkan sertifikat untuk domain mereka. Kontrol ini penting untuk mencegah penerbitan sertifikat yang tidak sah. Dengan adanya CAA, permukaan serangan untuk sertifikat palsu berkurang, sehingga membuat situs lebih aman.

Untuk sertifikat yang dikelola Google, sebaiknya Anda mengizinkan secara manual berikut untuk keandalan terbaik permintaan penerbitan dan perpanjangan sertifikat Anda:

Cloud Logging, Cloud Monitoring, dan visibilitas

Bagian berikut menjelaskan praktik terbaik untuk pencatatan log audit dan untuk memantau penggunaan dan masa berlaku sertifikat.

Mengaktifkan dan menggabungkan logging audit

Untuk memantau semua resource organisasi Anda, gabungkan Log audit aktivitas admin untuk semua layanan, termasuk Certificate Manager, ke lokasi terpusat.

Dengan begitu, tim keamanan atau auditor Anda dapat meninjau semua aktivitas yang terkait dengan pembuatan atau modifikasi resource Certificate Manager dan CA Service di satu tempat. Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi log gabungan, lihat Menggabungkan dan menyimpan log organisasi Anda.

Memantau penggunaan dan masa berlaku sertifikat

Sebaiknya siapkan pemberitahuan berbasis log untuk peristiwa Certificate Manager yang penting, seperti penggunaan CA root, masa berlaku sertifikat, dan penghapusan sertifikat. Peringatan ini membantu Anda memilah operasi, seperti tingkat kegagalan pembuatan sertifikat yang tinggi, dan dapat memicu proses hilir untuk meminta sertifikat baru atau meningkatkan kuota.

Konfigurasi pemberitahuan dan kebijakan log berikut untuk operasi terkait hak istimewa:

Persyaratan kepatuhan

Biasanya, framework kepatuhan menentukan ekspektasi dan tujuan tingkat tinggi untuk pengelolaan sertifikat, bukan untuk produk atau konfigurasi tertentu.

Misalnya, Standar Keamanan Data Industri Kartu Pembayaran (PCI DSS) dan National Institute of Standards and Technology (NIST) mewajibkan organisasi untuk mendokumentasikan dan menerapkan periode rotasi untuk kunci penandatanganan. Mereka juga mewajibkan pemantauan berkelanjutan terhadap inventaris dan semua kunci penandatanganan dan sertifikat tepercaya yang melindungi data pemegang kartu.

Untuk mengetahui informasi selengkapnya tentang cara layanan Google Cloud dapat membantu memenuhi berbagai persyaratan framework kepatuhan, lihat referensi berikut: