Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Ringkasan Certificate Authority Service
Certificate Authority Service (CA Service) adalah layananGoogle Cloud yang sangat skalabel yang memungkinkan Anda menyederhanakan dan mengotomatiskan deployment, pengelolaan, dan keamanan certificate authority (CA) pribadi.
CA pribadi menerbitkan sertifikat digital yang mencakup identitas entitas, identitas penerbit,
dan tanda tangan kriptografis. Sertifikat pribadi adalah salah satu cara paling umum
untuk mengautentikasi pengguna, mesin, atau layanan melalui jaringan. Sertifikat
pribadi sering digunakan di lingkungan DevOps untuk melindungi
penampung, microservice, virtual machine, dan akun layanan.
Dengan menggunakan Layanan CA, Anda dapat melakukan hal berikut:
- Membuat CA root dan CA bawahan kustom.
- Tentukan subjek, algoritma kunci, dan lokasi CA.
- Pilih region CA subordinat yang tidak bergantung pada region CA root-nya.
- Buat template yang dapat digunakan kembali dan berparameter untuk skenario penerbitan sertifikat umum.
- Bawa CA root Anda sendiri dan konfigurasikan CA lain untuk dihubungkan ke CA root
yang ada yang berjalan di lokal atau di tempat lain di luar Google Cloud.
- Simpan kunci CA pribadi Anda menggunakan Cloud HSM, yang divalidasi FIPS
140-2 Level 3 dan tersedia di beberapa region di benua Amerika,
Eropa, dan Asia Pasifik.
- Dapatkan log dan peroleh visibilitas terkait siapa yang melakukan apa, kapan, dan di mana dengan Cloud Audit Logs.
- Tentukan kontrol akses terperinci dengan Identity and Access Management (IAM) dan
perimeter keamanan virtual dengan Kontrol Layanan VPC.
- Kelola sertifikat dalam volume tinggi dengan mengetahui bahwa Layanan CA
mendukung penerbitan hingga 25 sertifikat per detik per CA (tingkat DevOps), yang
berarti setiap CA dapat menerbitkan jutaan sertifikat. Anda dapat membuat beberapa
CA di balik satu endpoint penerbitan yang disebut kumpulan CA dan mendistribusikan permintaan
sertifikat yang masuk ke semua CA. Dengan fitur ini, Anda dapat secara efektif
menerbitkan hingga 100 sertifikat per detik.
- Kelola, otomatiskan, dan integrasikan CA pribadi dengan cara yang paling
nyaman bagi Anda: menggunakan API, Google Cloud CLI, konsol Google Cloud , atau
Terraform.
Kasus penggunaan sertifikat
Anda dapat menggunakan CA pribadi untuk menerbitkan sertifikat untuk kasus penggunaan berikut:
- Integritas supply chain software dan identitas kode: Penandatanganan kode, autentikasi
artefak, dan sertifikat identitas aplikasi.
- Identitas pengguna: Sertifikat autentikasi klien yang digunakan sebagai identitas pengguna
untuk jaringan zero trust, VPN, penandatanganan dokumen, email, smartcard, dan lainnya.
- Identitas IoT dan perangkat seluler: Sertifikat autentikasi klien yang digunakan
sebagai identitas dan autentikasi perangkat, misalnya, akses nirkabel.
- Identitas intra-layanan: Sertifikat mTLS yang digunakan oleh microservice.
- Saluran continuous integration dan continuous delivery (CI/CD): Sertifikat penandatanganan kode yang digunakan di seluruh build CI/CD untuk meningkatkan integritas dan keamanan kode.
- Kubernetes dan Istio: Sertifikat untuk mengamankan koneksi antara
komponen Kubernetes dan Istio.
Alasan memilih PKI pribadi
Dalam Infrastruktur Kunci Publik (PKI) Web standar, jutaan klien di seluruh
dunia memercayai sekumpulan certificate authority (CA) independen untuk menyatakan identitas
(seperti nama domain) dalam sertifikat. Sebagai bagian dari tanggung jawabnya, CA berkomitmen
untuk hanya menerbitkan sertifikat jika mereka telah memvalidasi identitas
dalam sertifikat tersebut secara independen. Misalnya, CA biasanya perlu memverifikasi bahwa seseorang yang meminta sertifikat untuk nama domain example.com benar-benar mengontrol domain tersebut sebelum menerbitkan sertifikat kepadanya. Karena CA tersebut
dapat menerbitkan sertifikat untuk jutaan pelanggan yang mungkin tidak memiliki
hubungan langsung, CA tersebut hanya dapat menyatakan identitas yang
dapat diverifikasi secara publik. CA tersebut dibatasi pada proses verifikasi tertentu yang ditentukan dengan baik
dan diterapkan secara konsisten di seluruh PKI Web.
Tidak seperti PKI Web, PKI pribadi sering kali melibatkan hierarki CA yang lebih kecil, yang dikelola langsung oleh organisasi. PKI pribadi hanya mengirimkan sertifikat kepada klien
yang secara inheren memercayai organisasi untuk memiliki kontrol yang sesuai (misalnya, mesin yang dimiliki oleh organisasi tersebut). Karena admin CA sering kali memiliki
cara mereka sendiri untuk memvalidasi identitas yang sertifikatnya mereka terbitkan (misalnya, menerbitkan sertifikat kepada karyawan mereka sendiri), mereka tidak dibatasi oleh
persyaratan yang sama seperti untuk Web PKI. Fleksibilitas ini adalah salah satu keunggulan utama PKI pribadi dibandingkan PKI Web. PKI pribadi memungkinkan kasus penggunaan baru seperti mengamankan
situs internal dengan nama domain pendek tanpa memerlukan kepemilikan unik
nama tersebut, atau mengenkode format identitas alternatif (seperti
ID SPIFFE) ke dalam
sertifikat.
Selain itu, PKI Web mewajibkan semua CA untuk mencatat setiap sertifikat yang telah mereka
terbitkan ke log Transparansi Sertifikat
publik, yang mungkin tidak diperlukan untuk organisasi yang menerbitkan sertifikat ke
layanan internal mereka. PKI pribadi memungkinkan organisasi menjaga topologi infrastruktur internal mereka, seperti nama layanan jaringan atau aplikasi mereka, tetap bersifat pribadi dari seluruh dunia.
Langkah berikutnya
Kecuali dinyatakan lain, konten di halaman ini dilisensikan berdasarkan Lisensi Creative Commons Attribution 4.0, sedangkan contoh kode dilisensikan berdasarkan Lisensi Apache 2.0. Untuk mengetahui informasi selengkapnya, lihat Kebijakan Situs Google Developers. Java adalah merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-08-12 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-12 UTC."],[[["\u003cp\u003eCertificate Authority Service (CA Service) is a scalable Google Cloud service for managing and securing private certificate authorities (CAs), which are used for authenticating users, machines, or services over networks.\u003c/p\u003e\n"],["\u003cp\u003eCA Service allows the creation of custom root and subordinate CAs, and includes features such as customizable templates, bring-your-own root CA, secure key storage with Cloud HSM, audit logging, and granular access controls.\u003c/p\u003e\n"],["\u003cp\u003eCA Service supports high-volume certificate issuance, up to 25 certificates per second per CA, with the ability to create multiple CAs behind one CA pool to issue up to 100 certificates per second.\u003c/p\u003e\n"],["\u003cp\u003ePrivate CAs are advantageous over Web PKI because they allow organizations greater flexibility in validating identities and enable use cases like securing internal sites with short domain names and encoding alternative identity formats.\u003c/p\u003e\n"],["\u003cp\u003ePrivate CAs also offer enhanced privacy, as they do not require public logging of issued certificates, thus allowing organizations to keep their internal network structure confidential.\u003c/p\u003e\n"]]],[],null,["# Certificate Authority Service overview\n======================================\n\nCertificate Authority Service (CA Service) is a highly scalable\nGoogle Cloud service that lets you simplify and automate the\ndeployment, management, and security of private certificate authorities (CA).\nPrivate CAs issue digital certificates that include entity identity, issuer identity,\nand cryptographic signatures. Private certificates are one of the most common\nways to authenticate users, machines, or services over networks. Private\ncertificates are often used in DevOps environments to protect\ncontainers, microservices, virtual machines, and service accounts.\n\nUsing CA Service, you can do the following:\n\n- Create custom root and subordinate CAs.\n- Define the subject, key algorithm, and location of the CA.\n- Select a subordinate CA's region independent of its root CA's region.\n- Create reusable and parameterized templates for common certificate issuance scenarios.\n- Bring your own root CA and configure other CAs to chain up to the existing root CA running on-premises or anywhere else outside Google Cloud.\n- Store your private CA keys using [Cloud HSM](/kms/docs/hsm), which is FIPS 140-2 Level 3 validated and available in several regions across the Americas, Europe, and Asia Pacific.\n- Obtain logs and gain visibility into who did what, when, and where with [Cloud Audit Logs](/audit-logs).\n- Define granular access controls with [Identity and Access Management (IAM)](/iam) and virtual security perimeters with [VPC Service Controls](/vpc-service-controls?hl=en).\n- Manage high volumes of certificates knowing that CA Service supports issuing up to 25 certificates per second per CA (DevOps tier), which means that each CA can issue millions of certificates. You can create multiple CAs behind one issuance endpoint called a CA pool and distribute the incoming certificate requests across all the CAs. Using this feature, you can effectively issue up to 100 certificates per second.\n- Manage, automate, and integrate private CAs in whichever way is most convenient for you: using APIs, the Google Cloud CLI, the Google Cloud console, or [Terraform](https://www.terraform.io/).\n\nCertificate use cases\n---------------------\n\nYou can use your private CAs to issue certificates for the following use cases:\n\n- **Software supply chain integrity and code identity**: Code signing, artifact authentication, and application identity certificates.\n- **User identity**: Client authentication certificates used as user identity for zero trust networking, VPN, document signing, email, smartcard, and more.\n- **IoT and mobile device identity**: Client authentication certificates used as device identity and authentication, for example, wireless access.\n- **Intraservice identity**: mTLS certificates used by microservices.\n- **Continuous integration and continuous delivery (CI/CD) channels**: Code signing certificates used throughout the CI/CD build to improve code integrity and security.\n- **Kubernetes and Istio**: Certificates to secure connections between the Kubernetes and Istio components.\n\nWhy choose a private PKI\n------------------------\n\nIn a typical Web Public Key Infrastructure (PKI), millions of clients across the\nworld trust a set of independent certificate authorities (CAs) to assert identities\n(such as domain names) in certificates. As part of their responsibilities, CAs commit\nto only issuing certificates when they have independently validated the identity\nin that certificate. For example, a CA typically needs to verify that\nsomebody requesting a certificate for the domain name `example.com` actually\ncontrols the said domain before they issue a certificate to them. Since those CAs\ncan issue certificates for millions of customers where they might not have an\nexisting direct relationship, they are limited to asserting identities that are\npublicly verifiable. Those CAs are limited to certain well-defined verification\nprocesses that are consistently applied across the Web PKI.\n\nUnlike Web PKI, a private PKI often involves a smaller CA hierarchy, which is\ndirectly managed by an organization. A private PKI sends certificates only to clients\nthat inherently trust the organization to have the appropriate controls (for\nexample, machines owned by that organization). Since the CA admins often have\ntheir own ways of validating identities for which they issue certificates (for\nexample, issuing certificates to their own employees), they aren't limited by\nthe same requirements as for Web PKI. This flexibility is one of the main advantages\nof private PKI over Web PKI. A private PKI enables new use cases such as securing\ninternal websites with short domain names without requiring unique ownership of\nthose names, or encoding alternative identities formats (such\nas [SPIFFE IDs](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/)) into\na certificate.\n\nIn addition, the Web PKI requires all CAs to log every certificate they've\nissued to public [Certificate Transparency](https://certificate.transparency.dev/howctworks/)\nlogs, which may not be required for organizations issuing certificates to their\ninternal services. Private PKI allows organizations to keep their internal\ninfrastructure topology, such as the names of their network services or\napplications, private from the rest of the world.\n\nWhat's next\n-----------\n\n- Understand [CA Service pricing](/certificate-authority-service/pricing).\n- Learn about [security and compliance](/certificate-authority-service/docs/certificate-authority-compliance).\n- Review CA Service [locations](/certificate-authority-service/docs/locations).\n- Get started with the [CA Service](/certificate-authority-service/docs/create-certificate)."]]
