Sertifikat SSH Memusatkan Kepercayaan Akses pada Otoritas Penandatangan

Akses SSH berbasis public key sering dimulai dengan pemetaan sederhana: taruh public key pengguna di authorized_keys, simpan private key pada pengguna, lalu server menerima pihak yang dapat membuktikan kepemilikan private key pasangannya. Model ini langsung dan efektif, tetapi biaya administrasinya meningkat ketika jumlah pengguna dan host bertambah. Setiap host dapat menjadi lokasi lain tempat status akses harus ditambahkan, diaudit, dan dicabut.

Sertifikat OpenSSH mengubah model distribusi tersebut. Certificate authority menandatangani public key SSH dan menyertakan metadata identitas serta policy. Server yang dikonfigurasi untuk mempercayai CA itu dapat menerima sertifikat yang diterbitkannya tanpa menyimpan setiap key pengguna secara lokal. Titik kepercayaan bergeser dari sekumpulan besar key individual menuju sekumpulan lebih kecil otoritas penandatangan beserta policy di sisi server.

Mekanisme ini bukan sistem sertifikat X.509 yang dipakai HTTPS. OpenSSH menetapkan format sertifikat dan aturan validasinya sendiri. Istilah certificate pada keduanya menggambarkan binding bertanda tangan, bukan kompatibilitas format.

Sertifikat membawa lebih dari public key

Sertifikat user OpenSSH memuat public key yang disertifikasi, serial number, tipe sertifikat, identifier, valid principals, interval validitas, critical options, extensions, dan tanda tangan CA. Field tersebut membuat verifier dapat mengevaluasi lebih dari sekadar kepemilikan private key.

Principal menjadi bagian penting dalam authorization. Sertifikat dapat menyebut identitas atau role yang kemudian dipetakan server ke account. Server tetap menentukan principal mana yang diterima; tanda tangan CA yang valid tidak dengan sendirinya memberi akses ke account apa pun.

Batas waktu menambahkan constraint lain. CA dapat menerbitkan sertifikat yang hanya berlaku dalam interval terbatas. Key pair dasarnya dapat bertahan jauh lebih lama, tetapi authorization yang ditandatangani berakhir pada batas sertifikat. Masa berlaku pendek mengurangi ketergantungan pada penghapusan key pengguna berumur panjang dari banyak host setelah akses rutin berakhir.

Critical options dan extensions membawa perilaku tambahan. OpenSSH membedakan opsi yang wajib diproses verifier dari extension yang menyatakan capability yang diizinkan. Perbedaan ini penting secara operasional: policy penerbitan sertifikat dapat membatasi forwarding atau perilaku session lain, tetapi administrator perlu memverifikasi semantik OpenSSH yang benar-benar dipakai dan tidak memperlakukan metadata sebagai label bebas.

Server mempercayai CA lalu menerapkan policy account

Untuk autentikasi user, sshd dapat dikonfigurasi dengan TrustedUserCAKeys yang menunjuk public key CA user tepercaya. Saat client menyajikan sertifikat user, server memverifikasi tanda tangan CA dan constraint sertifikat, lalu menerapkan aturan authorization miliknya.

Desain yang umum memetakan principal sertifikat melalui AuthorizedPrincipalsFile atau AuthorizedPrincipalsCommand. Dengan pemisahan ini, CA bertanggung jawab menandatangani principal yang dinyatakan, sedangkan server atau fleet host menentukan principal yang boleh masuk ke account tertentu.

Pemisahan tersebut mencegah interpretasi CA trust yang terlalu luas. Mempercayai otoritas penandatangan tidak seharusnya berarti setiap sertifikat yang diterbitkannya dapat login sebagai setiap user lokal. Pemetaan principal menyediakan batas policy kedua antara penerbitan identitas dan authorization account.

Struktur yang sama dapat mendukung akses berbasis role. Sertifikat dapat membawa principal seperti production-readonly, sedangkan account tertentu menerima principal tersebut. Model role persisnya tetap merupakan pilihan policy operasional; sertifikat SSH menyediakan input bertanda tangan untuk policy itu, bukan sistem authorization lengkap.

Masa berlaku pendek mengubah tekanan revocation

Deployment authorized_keys tradisional sering mengandalkan penghapusan sebagai mekanisme revocation utama. Pada sertifikat, interval validitas pendek dapat membuat akses rutin berakhir secara alami. Pengguna dapat menerima sertifikat baru selama policy akses masih mengizinkannya, sedangkan sertifikat lama berhenti berlaku setelah interval validitas selesai.

Expiration bukan revocation seketika. Sertifikat tetap dapat diterima sampai masa berlakunya berakhir kecuali kontrol lain menolaknya. OpenSSH mendukung key revocation list melalui RevokedKeys, yang dapat dipakai untuk menolak key atau sertifikat tertentu. Lingkungan yang membutuhkan respons segera memerlukan proses revocation sesuai kebutuhan tersebut dan tidak cukup mengandalkan lifetime pendek.

Private key CA memerlukan perlindungan lebih kuat daripada key user biasa karena komprominya memperbesar skala dampak. Penyerang yang dapat menerbitkan sertifikat yang diterima server berpotensi membuat identitas dan principal dalam kewenangan otoritas tersebut. Penyimpanan key CA, akses signing, audit record, rotation, dan recovery karena itu menjadi bagian inti desain keamanan.

Sertifikat berumur pendek mengurangi authorization yang tertinggal, tetapi tidak menggantikan kontrol pada signing service. Jalur penerbitan menjadi titik enforcement bernilai tinggi.

Sertifikat host menangani sisi SSH yang berbeda

OpenSSH juga mendukung host certificate. Host CA menandatangani host key server, dan client dapat mempercayai CA tersebut untuk hostname atau pattern yang ditentukan. Mekanisme ini dapat mengurangi kebutuhan mendistribusikan fingerprint setiap host secara individual sambil tetap mempertahankan autentikasi server secara kriptografis.

Sertifikat user dan host menangani masalah distribusi yang berkaitan tetapi berbeda. Sertifikat user membantu server mengevaluasi identitas client. Sertifikat host membantu client mengevaluasi identitas server. Mencampur CA key atau tipe sertifikat keduanya mengurangi pemisahan administratif dan membuat policy lebih sulit diaudit.

Host certificate tidak menghapus verifikasi hostname. Sertifikat membawa principal untuk identitas host yang diwakilinya, dan client memeriksa host yang disajikan terhadap konfigurasi trust yang berlaku. CA trust dengan demikian digabungkan dengan constraint nama, bukan menggantikannya.

Policy penerbitan menjadi bagian dari kontrol akses

Ketika sertifikat menggantikan distribusi authorized_keys dalam skala besar, workflow signing menjadi tempat identitas, principal yang diminta, validitas, dan constraint session bertemu. Workflow itu dapat manual atau otomatis, tetapi keputusan authorization-nya memerlukan sumber policy yang eksplisit.

Signer tidak boleh menerima principal yang diminta secara sembarang hanya karena caller memiliki public key yang valid. Public key membuktikan kontrol atas material key; hal itu tidak menetapkan hak atas root, role production, atau principal istimewa lain. Signing service harus menentukan claim yang diizinkan dari identitas yang sudah diautentikasi dan policy akses.

Data audit menjadi lebih berguna ketika mencatat serial sertifikat, key identifier, principal, interval validitas, dan keputusan penerbitan. Field ini dapat menghubungkan event autentikasi server dengan artifact authorization tertentu yang diterbitkan, sesuai aturan logging dan retention lingkungan tersebut.

Automation dapat membuat lifetime sertifikat pendek tetap praktis, tetapi availability ikut menjadi faktor. Jika pengguna sering membutuhkan sertifikat baru, issuer yang tidak tersedia dapat memblokir session baru setelah sertifikat lama kedaluwarsa. Service tersebut memerlukan failure model yang menjaga keamanan tanpa mengubah emergency bypass key menjadi jalur akses paralel permanen.

Migrasi perlu mempertahankan batas trust yang eksplisit

Fleet tidak harus memindahkan setiap account sekaligus. Certificate trust dapat diperkenalkan untuk user atau role tertentu sementara akses berbasis key lama tetap dipakai untuk pengecualian yang terkontrol. Hal pentingnya adalah menjaga setiap jalur tetap terlihat. Entry authorized_keys yang terlupakan dapat bertahan melewati policy sertifikat dan diam-diam mempertahankan akses yang dianggap operator sudah berakhir.

Inventory karena itu perlu mencakup authorization berbasis sertifikat maupun direct key. Break-glass key, account automation, dan jalur recovery memerlukan owner yang jelas serta aturan lifecycle yang disengaja. Adopsi sertifikat menyederhanakan distribusi key hanya jika jalur lama tidak berubah menjadi sistem kedua yang luput dari audit.

Nilai sertifikat SSH paling jelas saat klaimnya tetap presisi: otoritas tepercaya menandatangani public key bersama principal, batas waktu, dan opsi tertentu. Server dan client tetap menerapkan policy lokal, private key tetap memerlukan perlindungan, dan CA menjadi infrastruktur dengan konsentrasi risiko keamanan yang tinggi. Dengan batas tersebut tetap utuh, sertifikat menggantikan distribusi key berulang dengan relasi trust yang lebih kecil dan lebih mudah diaudit.