Sertifikat SSH Mengikat Identitas ke Principal dan Batasan

Public key SSH mentah menjawab pertanyaan yang sempit: apakah client yang terhubung memiliki private key yang berpasangan dengan public key ini? Authorization masih membutuhkan pemetaan lain. Server biasanya menaruh key yang diterima di authorized_keys, sering kali bersama option yang membatasi tindakan key tertentu.

Sertifikat OpenSSH menambahkan layer identitas bertanda tangan di sekitar public key. Sertifikat dapat membawa principal, interval validitas, critical option, extension, serial number, dan key identifier. Server yang dikonfigurasi untuk mempercayai signing CA dapat memvalidasi sertifikat tersebut tanpa menyimpan public key mentah milik pemegangnya sebagai entry authorization terpisah.

Perubahan ini menyederhanakan distribusi key, bukan menghapus pemeriksaan kepemilikan. Client tetap membuktikan kepemilikan private key. Sertifikat memasok metadata bertanda tangan yang dapat dievaluasi server sebagai bagian dari authentication dan authorization.

Sertifikat menandatangani public key beserta metadata

Sertifikat user OpenSSH memuat public key subjek dan field yang dicakup signature CA. Secara konseptual:

public key subjek
set principal
valid-after / valid-before
critical option
extension
serial + key ID
        |
        v
   signature CA

Signature mencegah field bertanda tangan tersebut diubah tanpa terdeteksi. Signature tidak mengenkripsinya dan tidak membuat private key subjek dapat diperoleh dari sertifikat.

Untuk user authentication, server memerlukan trust anchor bagi user CA terkait. Pada OpenSSH, TrustedUserCAKeys dapat menunjuk file yang berisi public key CA yang diterima untuk sertifikat user. Mempercayai CA tersebut merupakan delegasi yang luas: sertifikat yang ditandatanganinya dapat memenuhi syarat authentication ketika pemeriksaan lain juga berhasil.

Delegasi tersebut menjadikan perlindungan private key CA sebagai kontrol bernilai tinggi. Kompromi pada user CA tepercaya dapat memungkinkan penerbitan sertifikat tanpa otorisasi dalam cakupan yang diterima server yang mempercayainya.

Principal adalah nama authorization, bukan label bebas

Sertifikat user dapat memuat satu atau beberapa valid principal. Server membandingkan principal tersebut dengan identitas yang bersedia diterima untuk account tujuan, sesuai konfigurasinya.

principal sertifikat: [deploy, release]
                       |
                       v
policy server untuk account tujuan
                       |
                 terima atau tolak

Pemetaan ini perlu dirancang secara eksplisit. Principal dapat mewakili nama account, role, workload identity, atau skema penamaan lain yang didukung deployment. Properti pentingnya adalah policy penerbitan dan policy server memakai arti yang konsisten.

AuthorizedPrincipalsFile dan AuthorizedPrincipalsCommand menyediakan mekanisme untuk menentukan principal yang diterima secara terpisah dari entry authorized_keys mentah milik user. Susunan ini dapat memisahkan trust model sertifikat dari authorization per-key yang lebih lama.

Sertifikat tanpa daftar valid principal memiliki penanganan khusus di OpenSSH dan tidak tepat dianggap setara dengan set principal yang dibatasi ketat. Issuer sebaiknya mengodekan scope identitas yang dimaksud secara sengaja, bukan memakai field kosong sebagai jalan pintas.

Interval validitas membatasi umur sertifikat

Sertifikat OpenSSH membawa nilai valid-after dan valid-before. Server memeriksa waktu saat ini terhadap interval tersebut ketika memvalidasi sertifikat.

Sertifikat berumur pendek dapat mengurangi ketergantungan pada distribusi lalu penghapusan key user satu per satu. Sistem identitas dapat mengautentikasi orang atau workload, menerbitkan sertifikat untuk interval terbatas, lalu membiarkan server SSH mempercayai CA.

pemeriksaan identitas
       |
       v
terbitkan sertifikat berumur pendek
       |
       v
akses SSH selama interval valid
       |
       v
sertifikat kedaluwarsa

Expiry bukan revocation. Sertifikat tetap memiliki signature kriptografis setelah interval validitas berakhir; sertifikat hanya gagal pada pemeriksaan waktu. Jika akses harus dihentikan sebelum expiry, deployment memerlukan mekanisme revocation atau penghapusan trust yang sesuai dengan desainnya.

OpenSSH mendukung data revoked key melalui RevokedKeys. Desain operasional juga dapat merotasi atau menghapus trust CA, tetapi penghapusan CA memengaruhi setiap sertifikat yang bergantung pada trust anchor tersebut sehingga dampaknya jauh lebih luas daripada mencabut satu credential.

Critical option dan extension memiliki semantik kegagalan berbeda

Sertifikat dapat membawa critical option dan extension. Perbedaannya relevan terhadap keamanan.

Critical option memberlakukan kondisi yang harus dikenali dan dipenuhi agar sertifikat diterima. Implementasi yang tidak mendukung sebuah critical option harus menolak sertifikat, bukan mengabaikan batasan itu secara diam-diam.

OpenSSH mendefinisikan critical option seperti source-address, yang dapat membatasi source address tempat sertifikat berlaku. OpenSSH juga mendukung force-command, yang dapat membatasi command yang dijalankan setelah authentication.

Extension mendeskripsikan capability yang dapat diaktifkan, termasuk fasilitas seperti alokasi PTY, agent forwarding, port forwarding, X11 forwarding, dan eksekusi ~/.ssh/rc milik user, bergantung pada sertifikat serta konfigurasi server.

Dengan demikian CA menandatangani lebih dari identitas. CA dapat menandatangani sebagian policy session. Kode penerbitan perlu memperlakukan field tersebut sebagai input security policy, bukan metadata bebas.

Policy server tetap berlaku setelah sertifikat valid

Sertifikat valid bukan token permission universal. Konfigurasi server SSH tetap menjadi bagian dari keputusan.

sshd dapat menerapkan pembatasan account, block Match, kontrol forwarding, pembatasan command, persyaratan authentication method, dan policy lain. Extension sertifikat tidak mengesampingkan larangan pada sisi server. Sertifikat yang mengizinkan sebuah capability tidak memaksa server mengaktifkannya.

Hasilnya memiliki dua layer:

policy sertifikat
      AND
policy server
      |
      v
permission session akhir

Pemisahan layer ini mencegah issuer diperlakukan sebagai satu-satunya authority atas seluruh properti session SSH. CA mengontrol apa yang ditandatangani; setiap server mengontrol apa yang bersedia dijalankan.

Rotasi CA memerlukan periode overlap

Mengganti SSH CA tepercaya adalah migrasi trust anchor. Server memerlukan public key CA baru sebelum sertifikat yang hanya ditandatangani CA tersebut dapat dipakai untuk authentication. Menghapus CA lama terlalu cepat dapat menolak credential yang masih valid; mempertahankannya tanpa batas akan menjaga trust terhadap authority yang seharusnya dipensiunkan.

Urutan terkendali dapat memakai periode overlap:

server mempercayai CA lama
        |
tambahkan trust CA baru
        |
terbitkan dengan CA baru
        |
sertifikat lama habis masa berlaku atau dicabut
        |
hapus trust CA lama

Interval persisnya bergantung pada umur sertifikat dan policy deployment. Invariant yang berguna lebih sederhana: penerbitan sertifikat dan distribusi trust server harus dikoordinasikan.

Field audit menghubungkan penerbitan dengan akses

Serial number dan key identifier dapat membantu korelasi operasional. Keduanya merupakan field sertifikat bertanda tangan sehingga issuer dapat menetapkan nilai yang menghubungkan credential dengan catatan penerbitan.

Field tersebut tidak menggantikan log authentication atau audit trail penerbitan. Deployment yang baik mencatat siapa atau workload apa yang meminta sertifikat, principal dan batasan yang diberikan, CA yang menandatangani, interval validitas, serta serial atau key identifier yang dihasilkan.

Catatan ini menjadi makin penting ketika sertifikat berumur pendek dan diterbitkan dengan frekuensi tinggi. Server mungkin tidak lagi memiliki daftar statis setiap subject key yang diterima sehingga sistem penerbitan menjadi sumber utama riwayat credential.

Trust CA adalah security boundary utama

Sertifikat SSH mengurangi distribusi key per-host dengan memindahkan trust ke signing authority. Penyederhanaan tersebut sekaligus memusatkan authority pada CA.

Desain menjadi lebih kuat ketika policy penerbitannya sempit: autentikasi requester, batasi principal, jaga interval validitas tetap terbatas, terapkan critical option ketika diperlukan, lindungi private key CA, dan simpan data audit yang cukup untuk melacak credential yang diterbitkan. Server kemudian memvalidasi credential bertanda tangan terhadap trust lokal dan policy session lokal, bukan memelihara salinan setiap key user.

Sertifikat bukan pengganti authorization server. Sertifikat adalah pernyataan bertanda tangan yang memberi policy authorization data identitas dan batasan terstruktur untuk dievaluasi.

Referensi

Cybersecurity SSH Autentikasi Kontrol Akses