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 memahami halaman ringkasan Certificate Manager dan halaman ringkasan Certificate Authority Service.

Mendesain arsitektur pengelolaan sertifikat

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

Bagian berikut menjelaskan rekomendasi kami untuk setiap pilihan desain.

Memilih jenis sertifikat

Saat membuat sertifikat, Anda harus memastikan untuk memilih jenis sertifikat yang sesuai dengan 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 yang bermanfaat untuk topik yang disebutkan dalam diagram alur:

Menyederhanakan hierarki CA Service pribadi

Sebaiknya pertahankan hierarki CA Service Anda sesederhana mungkin untuk memastikan kelancaran operasi dan pemecahan masalah. Anda harus menyimpan root certificate authority (CA) 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 salah konfigurasi. Meskipun CA Service adalah layanan regional, CA root di satu region dapat menandatangani CA bawahan yang berlokasi di region lain.

Ikuti praktik terbaik ini dalam hierarki CA Service Anda seperti yang ditunjukkan dalam diagram:

  • Isolasi CA root Anda di project-nya Google Cloud sendiri untuk menandatangani CA penerbit.

  • Buat CA penerbit di kumpulan CA yang dihosting di project terpisah. Hosting kumpulan ini di project terpisah dan segmentasikan berdasarkan lokasi geografis (region), siklus proses pengembangan software (pengembangan, produksi, pengujian), atau kasus penggunaan tertentu.

  • Konfigurasi Certificate Manager untuk menggunakan kumpulan CA penerbit yang dapat menerbitkan sertifikat tepercaya 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 satu sertifikat gagal diperpanjang atau tidak sengaja dihapus, 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 pengganti 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 layanan lain Google Cloud nya. Certificate Manager hanya mendukung Public Certificate Authority (pki.goog) dan Let's Encrypt CA (letsencrypt.org) untuk menerbitkan sertifikat yang dikelola Google dan tepercaya secara publik. Certificate Manager menyediakan sertifikat yang dikelola Google dengan masa berlaku 45 hari atau 90 hari, bergantung pada CA penerbit:

  • Sertifikat yang diterbitkan oleh CA Publik secara bertahap beralih dari masa berlaku 90 hari ke masa berlaku 45 hari. Sertifikat 90 hari yang ada akan tetap berlaku selama 90 hari hingga perpanjangan berikutnya.
  • Sertifikat yang diterbitkan oleh Let's Encrypt CA memiliki masa berlaku 90 hari.

Certificate Manager otomatis memulai proses perpanjangan saat sekitar sepertiga masa berlaku sertifikat tersisa. Perpanjangan dimulai sekitar 15 hari sebelum masa berlaku habis untuk sertifikat 45 hari dan sekitar 30 hari sebelum masa berlaku habis untuk sertifikat 90 hari.

Meningkatkan skala dan performa sertifikat

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

Menerapkan deployment terdesentralisasi untuk Certificate Manager

Gunakan Certificate Manager berdasarkan per project dan per lokasi, yang berarti sertifikat Anda disimpan di project yang sama dengan resource terkait di region yang sama. Strategi ini meningkatkan keandalan dengan mencegah penggunaan ulang sertifikat di berbagai region dan secara efektif meminimalkan dampak jika terjadi pemadaman layanan regional.

Selain itu, karena kuota dan batas diterapkan di tingkat Google Cloud project, men-deploy Certificate Manager di beberapa project akan meningkatkan kuota keseluruhan Anda. Hal ini karena penggunaan resource dalam satu project tidak memengaruhi kuota yang tersedia dalam 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 lainnya adalah sebagai berikut:

  • Jika Anda perlu mendukung klien lama yang tidak mendukung sertifikat ECDSA, Anda dapat menyediakan sertifikat RSA-2048 selain sertifikat ECDSA P-256.
  • Jika Anda memiliki persyaratan kepatuhan tertentu 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 eliptik, 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 besar daripada ukuran kunci RSA yang didukung secara luas.

Manfaat utama ECDSA:

  • Performa: Operasi penandatanganan ECDSA jauh lebih tidak intensif secara komputasi daripada operasi RSA yang memberikan tingkat keamanan yang setara. Hal ini mengurangi beban dan latensi CPU, yang sangat penting untuk sistem dengan throughput tinggi atau sensitif terhadap latensi.

  • Efisiensi: kunci dan tanda tangan yang lebih kecil memerlukan lebih sedikit bandwidth dan penyimpanan, yang sangat bermanfaat untuk lingkungan dengan resource terbatas seperti perangkat seluler dan IoT.

Anda dapat membuat kebijakan organisasi kustom berikut untuk menerapkan 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 dan tepercaya secara 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. Penggunaan kumpulan CA meningkatkan total kueri efektif per detik (QPS) 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 dengan aman tanpa menyebabkan waktu non-operasional karena masa berlaku sertifikat habis atau terganggu.

Menggunakan peta sertifikat

Untuk memastikan skalabilitas yang optimal, sebaiknya gunakan peta sertifikat dengan resource yang didukung. Peta sertifikat didesain untuk skala, mendukung ribuan entri sertifikat secara default, dan mampu menangani jutaan sertifikat. Saat digunakan oleh load balancer, entri peta sertifikat akan diprioritaskan daripada sertifikat lainnya, 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. Mengharuskan Anda 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 hanya dapat menyediakan sertifikat setelah load balancer disiapkan sepenuhnya dan menayangkan traffic jaringan. Anda dapat menyediakan sertifikat terlebih dahulu, sebelum proxy target siap menayangkan 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 Certificate Lifecycle Management (CLM) pilihan Anda. Hal ini membantu mengurangi error, waktu non-operasional, dan memastikan efisiensi operasional.

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

  1. Pantau masa berlaku sertifikat menggunakan Cloud Monitoring dan pemberitahuan. Sebaiknya buat pemberitahuan untuk sertifikat yang akan habis masa berlakunya dalam 15 hingga 30 hari ke depan.
  2. Buat permintaan penandatanganan sertifikat (CSR) dan kunci pribadi untuk dikirimkan ke CA Anda.
  3. Kirim CSR dan kunci pribadi ke CA Anda, lalu ambil sertifikat baru.

  4. Upload sertifikat baru ke Certificate Manager ke peta sertifikat yang sesuai.

    • Jika nama domain dalam sertifikat baru cocok dengan sertifikat yang akan habis masa berlakunya, gunakan metode UpdateCertificate pada resource sertifikat yang ada.
    • Jika sertifikat baru memiliki nama domain yang berbeda, gunakan metode CreateCertificateRequest terlebih dahulu dengan file PEM (privacy-enhanced mail) baru untuk membuatnya. Kemudian, gunakan UpdateCertificateMapEntry metode untuk mengganti referensi sertifikat lama dalam peta sertifikat dengan yang baru.

    Penting: Anda harus menyelesaikan proses ini dalam satu panggilan API tanpa menyebabkan waktu non-operasional.

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 Certificate Manager dan CA Service yang telah ditetapkan atau kustom untuk mengurangi risiko insiden keamanan terkait akses yang terlalu istimewa.

Merencanakan pemisahan tugas

Sebaiknya pertahankan identitas dan izin yang berbeda untuk administrator sertifikat dan orang yang memiliki peran penerbit sertifikat atau peminta sertifikat. Untuk melakukannya, buat grup administrator dan peminta 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.
  • Mengonfigurasi template sertifikat.
  • Mengelola daftar pencabutan sertifikat (CRL) dan respons protokol status sertifikat online (OCSP).
  • Menerapkan kebijakan keamanan untuk CA Anda.

Untuk project yang menghosting CA root, hindari menetapkan peran dasar seperti Pemilik (roles/owner), Editor (roles/editor), dan Admin CA Service (roles/privateca.admin) ke pengguna atau grup mana pun. Praktik ini mencegah penghapusan yang tidak disengaja, salah konfigurasi, dan paparan berlebihan. Sebagai gantinya, gunakan Privileged Access Manager (PAM) untuk akses just-in-time (JIT) sesuai kebutuhan dengan justifikasi dan persetujuan setelah CA root diinstal dan dikonfigurasi.

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

Tabel berikut mencantumkan peran IAM yang biasanya terkait dengan berbagai fungsi pekerjaan:

Persona Deskripsi Peran IAM
Administrator sertifikat Menyiapkan dan mengelola infrastruktur CA dan sertifikat. Pemilik Certificate Manager (roles/certificatemanager.owner),
Admin CA Service (roles/privateca.admin)
Peminta sertifikat Meminta sertifikat untuk workload. Peminta Sertifikat Certificate Authority Service (roles/privateca.certificateRequester)
Workload (akun layanan otomatisasi) Digunakan oleh workload atau dalam pipeline untuk meminta sertifikat. Peminta Sertifikat Workload Certificate Authority Service (roles/privateca.workloadCertificateRequester)
Engineer keamanan atau pemilik PKI Mengelola kebijakan, pencabutan, dan siklus proses sertifikat. Manajer Operasi CA Service (roles/privateca.caManager), Manajer Sertifikat Certificate Authority Service (roles/privateca.certificateManager)
Engineer DevOps atau platform Mengelola deployment sertifikat di load balancer, dan lainnya. Editor Certificate Manager (roles/certificatemanager.editor)
Auditor atau kepatuhan Memantau 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 kumpulan 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 mengambil risiko dampak buruk pada sistem produksi atau project lain yang sedang berlangsung.

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 Public Certificate Authority (CA) yang dapat menerbitkan sertifikat untuk domain mereka. Kontrol ini penting untuk mencegah penerbitan sertifikat yang tidak sah. Dengan CAA, area serangan untuk sertifikat palsu akan berkurang, sehingga membuat situs lebih aman secara efektif.

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

Cloud Logging, Cloud Monitoring, dan visibilitas

Bagian berikut menjelaskan praktik terbaik untuk logging 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.

Hal ini memungkinkan tim keamanan atau auditor Anda 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. Pemberitahuan ini membantu Anda melakukan triase operasi, seperti tingkat kegagalan pembuatan sertifikat yang tinggi, dan dapat memicu proses hilir untuk meminta sertifikat baru atau meningkatkan kuota.

Konfigurasikan 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 tertentu atau konfigurasi tertentu.

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

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

Langkah berikutnya