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) dengan air gap.

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

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 konsisten yang sama 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 Terstandardisasi: Dukungan untuk protokol Automatic Certificate Management Environment (ACME) menggunakan tantangan DNS-01, sehingga layanan platform dapat meminta dan memperpanjang sertifikat dengan lancar.
  • Integrasi HSM yang Aman: Perlindungan kriptografis langsung untuk semua kunci pribadi CA di dalam Hardware Security Module (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 Air-Gap: Alur kerja khusus untuk menduplikasi image penerbit cert-manager EJBCA dari registry publik ke registry Harbor pribadi GDC, sehingga memastikan ketersediaan offline.
  • Isolasi Traffic Egress: Konfigurasi jaringan keluar menggunakan resource Subnet GDC dan CloudNATGateway untuk membatasi traffic GDC API langsung ke alamat IP server EJBCA eksternal.

Prinsip arsitektur

  • Model Tanggung Jawab Bersama: Pelanggan mengoperasikan server EJBCA eksternal dan HSM, 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 air-gapped dengan menggunakan mirror image container lokal dan menerapkan pembatasan traffic keluar yang ketat untuk meminimalkan permukaan serangan jaringan.
  • Standardisasi 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, dengan server EJBCA dan Hardware Security Module (HSM) pendukungnya dihosting secara eksternal di luar batas fisik GDC, tetapi dapat diakses melalui jaringan. Server EJBCA dapat di-deploy secara eksternal sebagai perangkat 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:

  • EJBCA Enterprise Server: Di-deploy secara eksternal sebagai peralatan hardware atau peralatan software Keyfactor, yang menampung CA (Root dan Subordinat) 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 virtual machine.
  • DNS Internal GDC: Mengelola zona DNS pribadi lokal (menggunakan nama domain pribadi yang dikonfigurasi dalam variabel lingkungan) yang digunakan untuk menyelesaikan tantangan DNS-01 ACME.
  • Gateway NAT Egress GDC: Mengarahkan traffic keluar dari pod cluster ke alamat IP server EJBCA eksternal.
  • Harbor Private Registry: Menghosting image container yang diduplikasi (seperti penerbit cert-manager EJBCA) untuk deployment air-gap.

Konsep dan teknologi

Bagian ini menjelaskan komponen fungsional, tanggung jawabnya, dan cara komponen tersebut 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.
  • Harbor Registry: Sumber tepercaya lokal yang aman untuk semua image container di GDC. Artifact Registry 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

  • EJBCA Enterprise Server: Mesin CA eksternal (perangkat software atau hardware) yang bertanggung jawab mengelola hierarki CA (Root dan Subordinat), memvalidasi permintaan sertifikat, menandatangani sertifikat, dan mencatat data audit ke dalam log.
  • Modul Keamanan Hardware (HSM): Modul kriptografis yang mematuhi CC EAL4+ yang menangani pembuatan kunci dan penandatanganan sertifikat, sehingga menjamin bahwa kunci pribadi CA tidak pernah terekspos.
  • 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 EJBCA Issuer: Pengontrol sertifikat native Kubernetes yang menangkap permintaan Certificate dan memanfaatkan penerbit EJBCA untuk menerjemahkannya menjadi panggilan API EJBCA yang aman.

Aliran data dan antarmuka

  • Protokol ACME: Antarmuka API standar untuk penerbitan sertifikat server otomatis yang divalidasi domain menggunakan verifikasi DNS-01.
  • EJBCA REST API: Antarmuka RESTful yang digunakan untuk bootstrap administratif dan operasi terprogram (seperti penandatanganan dan pencabutan CSR).
  • Autentikasi Klien mTLS: Mekanisme autentikasi utama untuk integrasi cert-manager, yang memverifikasi identitas klien melalui mutual TLS 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 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 ketersediaan tinggi server EJBCA eksternal di beberapa zona ketersediaan (menggunakan konfigurasi aktif-pasif atau cluster) direkomendasikan untuk memastikan operasi berkelanjutan dan menghindari titik tunggal kegagalan.
    • Men-deploy beberapa replika pengontrol cert-manager di dalam GDC memastikan bahwa penerbitan sertifikat otomatis di 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 mengelola cert-manager dalam cluster dan pengontrol penerbit EJBCA serta mengelola data DNS pribadi sisi GDC.

Keputusan desain

Pilihan arsitektur utama untuk solusi ini berfokus pada penyeimbangan otomatisasi dengan batasan lingkungan air-gapped.

Opsi integrasi EJBCA

Layanan Certificate Authority native GDC adalah solusi PKI yang direkomendasikan untuk sebagian besar pelanggan, yang menyediakan kemampuan PKI yang lancar dan terkelola sepenuhnya dalam lingkungan GDC dengan air gap. Namun, bagi organisasi yang telah menstandarkan infrastruktur PKI mereka pada 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 dan tidak dapat mendukung traffic HTTP publik masuk), pelanggan dapat memilih salah satu metode validasi berdasarkan topologi jaringan, kebijakan keamanan, dan persyaratan workload spesifik mereka.

Rekomendasi saluran administratif mTLS

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

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 End Entity yang sesuai.
  • Mekanisme yang aman (seperti node bastion atau alur kerja transfer offline) tersedia untuk memublikasikan image container penerbit EJBCA ke registry GDC Harbor.
  • Cluster Kubernetes standar di dalam GDC memiliki cert-manager yang telah diinstal atau dikonfigurasi sebelumnya untuk pengoperasian.

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 rak GDC dan server EJBCA eksternal.