Arsitektur referensi Keyfactor EJBCA

Ringkasan

Arsitektur referensi ini menentukan desain konseptual untuk mengintegrasikan Keyfactor EJBCA Enterprise sebagai Certificate Authority (CA) pihak ketiga di Google Distributed Cloud (GDC) yang terisolasi.

Keyfactor EJBCA Enterprise adalah platform Certificate Authority yang sangat skalabel, tangguh, dan sesuai dengan FIPS yang memungkinkan organisasi mengelola infrastruktur kunci publik (PKI) di berbagai lingkungan.

GDC dengan air gap mencakup layanan Certificate Authority native untuk pengelolaan kunci dan sertifikat otomatis di dalam batas cloud yang dihosting. Layanan CA native adalah solusi yang direkomendasikan untuk sebagian besar pelanggan, yang menyediakan kemampuan PKI yang terkelola sepenuhnya dan lancar dalam platform. Namun, organisasi yang telah menstandarkan infrastruktur PKI mereka di Keyfactor EJBCA untuk workload yang ada di luar GDC mungkin lebih memilih untuk memanfaatkan arsitektur CA dan kebijakan pengelolaan yang sama dan konsisten untuk workload yang berjalan dalam lingkungan GDC mereka.

Fitur dan kemampuan

Solusi ini menyediakan beberapa komponen fungsional inti untuk pengelolaan siklus proses sertifikat:

  • Pengelolaan Siklus Proses Sertifikat Otomatis: Manfaatkan penerbit EJBCA kustom di dalam cluster standar GDC untuk mengotomatiskan penyediaan, perpanjangan, dan pencabutan sertifikat server melalui cert-manager.
  • Otomatisasi ACME Standar: Dukungan untuk protokol Automatic Certificate Management Environment (ACME) menggunakan tantangan DNS-01, yang memungkinkan layanan platform meminta dan memperpanjang sertifikat dengan lancar.
  • Integrasi HSM yang Aman: Perlindungan kriptografi langsung dari semua kunci pribadi CA di dalam Modul Keamanan Hardware (HSM) bersertifikasi CC EAL4+, yang memastikan materi kunci tidak pernah keluar dari batas keamanan fisik. Keyfactor EJBCA Enterprise dapat menggunakan HSM terkelolanya sendiri atau terhubung ke HSM eksternal.
  • Kompatibilitas Terisolasi: Alur kerja khusus untuk mencerminkan image penerbit cert-manager EJBCA dari registry publik ke registry Harbor pribadi GDC, yang memastikan ketersediaan offline.
  • Isolasi Traffic Egress: Konfigurasi jaringan keluar menggunakan resource GDC Subnet dan CloudNATGateway untuk membatasi traffic GDC API langsung ke alamat IP server EJBCA eksternal.

Prinsip arsitektur

  • Model Tanggung Jawab Bersama: Pelanggan mengoperasikan server dan HSM EJBCA eksternal yang memiliki infrastruktur PKI fisik dan kunci root CA, sementara GDC menyediakan komputasi, DNS internal, dan lapisan klien otomatis di dalam cluster standar.
  • Desain yang Berfokus pada Keamanan: Mematuhi persyaratan keamanan yang terisolasi dengan menggunakan cermin image container lokal dan menerapkan gating egress yang ketat untuk meminimalkan permukaan serangan jaringan.
  • Standarisasi Protokol: Memprioritaskan protokol standar (ACME dan mTLS REST) untuk interaksi CA, menghindari dependensi API eksklusif, dan memungkinkan integrasi klien yang fleksibel.

Arsitektur

Arsitektur ini mengikuti model Certificate Authority eksternal, tempat server EJBCA dan Modul Keamanan Hardware (HSM) pendukungnya dihosting secara eksternal di luar batas fisik GDC, tetapi dapat diakses melalui jaringan. Server EJBCA dapat di-deploy secara eksternal sebagai appliance hardware atau software. Integrasi inti yang dijelaskan dalam panduan ini hanya mengharuskan server EJBCA eksternal dapat dijangkau melalui alamat IP yang stabil.

Diagram arsitektur Keyfactor EJBCA.

Komponen utama arsitektur ini meliputi:

  • Server EJBCA Enterprise: Di-deploy secara eksternal sebagai appliance hardware atau software Keyfactor, yang menampung CA (Root dan Subordinate) dan menghasilkan semua materi kunci CA di dalam HSM bersertifikasi CC EAL4+.
  • VPC Default: VPC tempat workload pengguna di-deploy, baik di cluster Kubernetes standar maupun di mesin virtual.
  • DNS Internal GDC: Mengelola zona DNS pribadi lokal (menggunakan nama domain pribadi yang dikonfigurasi dalam variabel lingkungan) yang digunakan untuk menyelesaikan tantangan ACME DNS-01.
  • Gateway NAT Egress GDC: Mengarahkan traffic keluar dari pod cluster ke alamat IP server EJBCA eksternal.
  • Registry Pribadi Harbor: Menghosting image container yang dicerminkan (seperti penerbit cert-manager EJBCA) untuk deployment yang terisolasi.

Konsep dan teknologi

Bagian ini menjelaskan komponen fungsional, tanggung jawabnya, dan cara berkomunikasi dalam sistem.

Infrastruktur dan platform

  • Cluster Standar GDC: Lingkungan komputasi utama tempat pod penerbit EJBCA dan cert-manager berada, yang menjalankan otomatisasi sertifikat untuk workload.
  • Registry Harbor: Sumber tepercaya lokal yang aman untuk semua image container di GDC. Registry ini menyediakan pemindaian otomatis untuk memastikan image bebas dari kerentanan yang diketahui sebelum deployment.
  • Gateway Egress GDC: Resource jaringan native platform (Subnet dan CloudNATGateway) yang mengatur dan mengamankan traffic API keluar dari pod cluster ke server CA eksternal.

Layanan dan logika

  • Server EJBCA Enterprise: Mesin CA eksternal (appliance software atau hardware ) yang bertanggung jawab untuk mengelola hierarki CA (Root dan Subordinate), memvalidasi permintaan sertifikat, menandatangani sertifikat, dan mencatat data audit.
  • Modul Keamanan Hardware (HSM): Modul kriptografi yang sesuai dengan CC EAL4+ yang menangani pembuatan kunci dan penandatanganan sertifikat, yang menjamin bahwa kunci pribadi CA tidak pernah diekspos.
  • DNS Internal GDC: Mengelola zona DNS pribadi (ManagedDNSZone dan ResourceRecordSet) yang digunakan oleh layanan validasi tantangan ACME untuk memverifikasi kepemilikan domain melalui data TXT sementara.
  • cert-manager dengan Penerbit EJBCA: Pengontrol sertifikat native Kubernetes yang mencegat permintaan Sertifikat dan memanfaatkan penerbit EJBCA untuk menerjemahkannya ke dalam panggilan EJBCA API yang aman.

Alur dan antarmuka data

  • Protokol ACME: Antarmuka API standar untuk penerbitan sertifikat server yang divalidasi domain dan otomatis menggunakan tantangan DNS-01.
  • EJBCA REST API: Antarmuka RESTful yang digunakan untuk bootstrapping administratif dan operasi terprogram (seperti penandatanganan dan pencabutan CSR).
  • Autentikasi Klien mTLS: Mekanisme autentikasi utama untuk integrasi cert-manager, yang memverifikasi identitas klien melalui TLS mutual menggunakan sertifikat klien khusus.

Pertimbangan

  • Skalabilitas dan performa:
    • Server EJBCA eksternal harus diskalakan (CPU, memori, kapasitas HSM) untuk menangani permintaan validasi dan penandatanganan serentak, terutama selama profil penerbitan burst.
    • Resource gateway egress GDC harus diukur untuk memastikan latensi minimal ke server CA eksternal, sehingga mencegah waktu tunggu habis selama siklus validasi cert-manager.
  • Keamanan dan kepatuhan:
    • Mengisolasi kunci root CA di dalam HSM eksternal memenuhi standar keamanan dan kepatuhan yang tinggi (seperti BSI VS-NfD).
    • Akses administratif ke EJBCA harus dibatasi secara ketat menggunakan kontrol akses berbasis peran (RBAC) dan dipetakan ke nomor seri sertifikat klien yang unik.
  • Ketersediaan dan keandalan:
    • Deployment server EJBCA eksternal dengan ketersediaan tinggi di beberapa zona ketersediaan (menggunakan konfigurasi aktif-pasif atau cluster) direkomendasikan untuk memastikan operasi berkelanjutan dan menghindari satu titik kegagalan.
    • Men-deploy beberapa replika pengontrol cert-manager di dalam GDC memastikan bahwa penerbitan sertifikat otomatis sisi cluster tetap tangguh.
  • Pengelolaan operasional:
    • Pelanggan mempertahankan kepemilikan server EJBCA, termasuk patching sistem, rotasi kunci HSM, dan publikasi CRL.
    • Administrator platform GDC pelanggan bertanggung jawab untuk memelihara pengontrol penerbit cert-manager dan EJBCA dalam cluster serta mengelola data DNS pribadi sisi GDC.

Keputusan desain

Pilihan arsitektur utama untuk solusi ini berfokus pada penyeimbangan otomatisasi dengan batasan lingkungan yang terisolasi.

Opsi integrasi EJBCA

Layanan Certificate Authority native GDC adalah solusi PKI yang direkomendasikan untuk sebagian besar pelanggan, yang menyediakan kapabilitas PKI yang terkelola sepenuhnya dan lancar dalam lingkungan GDC dengan air gap. Namun, untuk organisasi yang telah menstandarkan infrastruktur PKI mereka di Keyfactor EJBCA untuk workload di luar GDC, mengintegrasikan server CA eksternal yang ada ditawarkan sebagai opsi keikutsertaan. Hal ini memungkinkan mereka menggunakan kembali template PKI, kebijakan keamanan, dan model operasional yang sudah ada tanpa mendesain ulang hierarki kepercayaan atau memigrasikan alur kerja inti.

Opsi validasi tantangan ACME

Protokol validasi tantangan ACME HTTP-01 dan DNS-01 didukung sepenuhnya. Meskipun panduan arsitektur ini menyoroti tantangan DNS-01 menggunakan DNS internal GDC (yang ideal untuk lingkungan pribadi yang terisolasi yang tidak dapat mendukung traffic HTTP publik masuk), pelanggan dapat memilih metode validasi berdasarkan topologi jaringan, kebijakan keamanan, dan persyaratan workload tertentu.

Rekomendasi saluran administratif mTLS

Penggunaan TLS mutual (mTLS) direkomendasikan sebagai metode autentikasi yang tangguh untuk cert-manager dan klien integrasi. mTLS menyediakan verifikasi kriptografi identitas klien yang sangat aman dengan memanfaatkan sertifikat klien, meskipun pelanggan dapat memilih untuk mengonfigurasi mekanisme autentikasi lain yang didukung oleh instance EJBCA mereka sesuai dengan kebijakan keamanan perusahaan.

Asumsi dan batasan

Asumsi

  • Server EJBCA eksternal di-deploy, dikonfigurasi, dan dapat dijangkau melalui alamat IP yang stabil.
  • Server EJBCA telah dikonfigurasi sebelumnya dengan CA Root dan Subordinate yang diperlukan, beserta profil Entitas Akhir yang sesuai.
  • Mekanisme yang aman (seperti node bastion atau alur kerja transfer offline) tersedia untuk memublikasikan image container penerbit EJBCA ke registry Harbor GDC.
  • Cluster Kubernetes standar di dalam GDC telah menginstal atau mengonfigurasi cert-manager untuk operasi.

Batasan

  • Pemeliharaan HSM & EJBCA Eksternal: Bidang kontrol GDC tidak mengelola server EJBCA eksternal atau HSM pendukungnya; operasi siklus proses (pencadangan, upgrade, rotasi kunci) ditangani oleh tim operasi PKI pelanggan.
  • Batasan Validasi DNSSEC: Karena DNS internal pribadi digunakan, validasi DNSSEC harus dinonaktifkan di sisi server dalam konfigurasi ACME untuk menghindari kegagalan resolusi untuk domain pribadi lokal.
  • Dependensi Konektivitas Egress: Layanan penerbitan sertifikat otomatis bergantung pada ketersediaan dan latensi link jaringan antara rack GDC dan server EJBCA eksternal.