Perintah dan konteks
Edge node CDN berjumlah banyak dan terpapar ke publik, sehingga mendistribusikan key sertifikat berumur panjang akan memperbesar dampak jika terjadi kompromi keamanan. Menggunakan RFC 9345, rancang Delegated Credentials (DC): pemegang sertifikat menerbitkan kredensial berumur pendek, edge menggunakannya untuk autentikasi TLS, dan kredensial tersebut tidak dapat menerbitkan DC lain. Cakup validasi handshake, masa berlaku, rotasi, batasan pencabutan, dan fallback.
Apa yang sedang diuji oleh pewawancara
Poin penilaiannya adalah pemahaman tentang keterikatan (binding) antara DC dan sertifikat end-entity X.509, batas otoritas dari key berumur pendek, negosiasi ekstensi TLS, time window, dan dampak kompromi. Jawaban yang kuat membedakan antara pengurangan waktu paparan dan pencabutan instan, serta menjelaskan fallback yang aman untuk klien tanpa dukungan DC.
Pertanyaan klarifikasi yang perlu diajukan terlebih dahulu
Lalu lintas dan titik terminasi
Konfirmasikan apakah TLS berakhir di CDN, gateway regional, atau origin, apakah edge mencakup domain administratif yang berbeda, dan apakah DTLS atau QUIC dilibatkan. Titik terminasi menentukan jalur penerbitan dan distribusi.
Matriks kompatibilitas klien
Identifikasi versi peramban, seluler, IoT, dan klien internal serta apakah stack TLS mereka dapat ditingkatkan. DC memerlukan negosiasi ekstensi dan validasi baru, sehingga dukungannya tidak dapat diasumsikan tersedia.
Tujuan penanganan kompromi
Perjelas apakah tujuannya adalah untuk membatasi paparan key berumur panjang, masa pakai edge-key, atau keduanya. Periksa apakah kepatuhan memerlukan daftar pencabutan terpisah atau penarikan paksa.
Kerangka jawaban 30 detik
“Pemegang sertifikat menerbitkan DC berumur pendek, yang tanda tangan, penggunaan, dan masa berlakunya divalidasi dengan key sertifikat end-entity. Edge hanya menerima private key DC dan tidak dapat membuat DC lain; klien memvalidasi binding selama alur ekstensi TLS. Gunakan masa berlaku yang pendek, rotasi yang tumpang tindih (overlapping), dan isolasi key, sembari melindungi key berumur panjang. Klien yang tidak mendukung menggunakan jalur sertifikat biasa yang eksplisit; kegagalan validasi tidak pernah diturunkan (downgrade) secara diam-diam. Respons kompromi bergantung pada masa kedaluwarsa yang singkat, penghentian penerbitan, dan jika perlu, mencabut sertifikat induk—bukan dengan mengasumsikan pencabutan DC secara instan.”
Langkah-langkah jawaban mendalam
Langkah 1: Tentukan hubungan penerbitan
Penerbit (issuer) yang memegang private key berumur panjang yang sesuai dengan sertifikat end-entity membuat public key DC, masa berlaku, algoritma tanda tangan, dan informasi penggunaan TLS/DTLS. Public key end-entity memverifikasi tanda tangan tersebut. Edge menerima private key DC dan kredensial publik, tidak pernah menerima private key induk.
Langkah 2: Batasi otoritas dan penggunaan
Private key DC terbatas pada peran autentikasi TLS yang disepakati dan tidak dapat menerbitkan DC lain. Validasi DelegationUsage, kompatibilitas algoritma, dan konteks protokol sehingga kredensial khusus TLS tidak diperlakukan sebagai key penandatanganan umum.
Langkah 3: Validasi selama handshake
Klien memvalidasi rantai X.509 tradisional, kemudian tanda tangan DC, masa berlaku, binding dengan induk, dan konteks handshake. Jika negosiasi ekstensi gagal, gunakan jalur sertifikat biasa yang eksplisit. Kolom keamanan yang tidak dikenal atau tidak konsisten harus menggagalkan validasi alih-alih diabaikan.
Langkah 4: Rancang jendela rotasi
Tetapkan tumpang tindih (overlap) untuk clock skew pada edge, penundaan propagasi, dan durasi handshake maksimum. Muat DC baru sebelum beralih selagi kredensial lama masih valid; hentikan kredensial lama hanya setelah distribusi terkonfirmasi. Sinkronisasi waktu dan pemantauan mencakup batasan tersebut.
Langkah 5: Tangani kompromi dan pencabutan
Penyerang yang memiliki private key DC dapat meniru pihak tersebut dalam koneksi baru hingga DC tersebut kedaluwarsa, tetapi tidak dapat menerbitkan DC lain. Responsnya mencakup penghentian penerbitan, mempersingkat masa berlaku, menarik kredensial edge, dan jika perlu, mencabut sertifikat induk atau beralih ke sertifikat biasa. DC bukanlah mekanisme pencabutan instan.
Langkah 6: Rencanakan kompatibilitas dan fallback
Gunakan matriks klien dan pengalihan lalu lintas bertahap untuk memverifikasi dukungan ekstensi. Klien yang tidak mendukung mengikuti jalur terminasi sertifikat berumur panjang sementara key induk tetap terisolasi. Bedakan “peer tidak memiliki dukungan” dari “validasi gagal”; jangan pernah mendowngrade kegagalan validasi ke teks biasa atau sertifikat sembarang.
Langkah 7: Observasi dan lakukan simulasi
Catat penerbitan, distribusi, pemuatan, kegagalan handshake, clock skew, dan tingkat fallback tanpa mencatat private key. Lakukan simulasi kompromi edge, kegagalan fungsi penerbit, pencabutan induk, dan fallback penuh untuk memverifikasi pemulihan dalam masa berlaku yang singkat.
Contoh jawaban berkualitas tinggi
Saya akan menyimpan key sertifikat berumur panjang di sebuah issuer dan menggunakannya untuk menandatangani DC berumur pendek; edge hanya menerima setiap private key DC. Selama handshake, validasi rantai X.509, lalu binding DC, penggunaan, algoritma, masa berlaku, dan konteks handshake. Lakukan rotasi dengan tumpang tindih, pantau jam sistem, terapkan kompatibilitas secara bertahap, dan sediakan fallback eksplisit untuk klien lama. Jika DC bocor, hentikan penerbitan, tarik kredensial edge, tunggu hingga kedaluwarsa, dan cabut induk jika diperlukan. Pantau kegagalan validasi dan tingkat fallback; DC bukan mekanisme pencabutan instan.
Kesalahan umum
- Kesalahan: Mengasumsikan DC yang bocor dapat dicabut secara instan seperti token OAuth. → Alasan: RFC berfokus pada masa berlaku pendek dan binding terhadap induk. → Solusi: Perpendek masa berlaku serta persiapkan pencabutan dan penarikan sertifikat induk.
- Kesalahan: Membiarkan edge dengan private key DC menerbitkan DC lainnya. → Alasan: Ini memperluas rantai delegasi dan otoritas. → Solusi: Simpan key induk di dalam issuer yang terkontrol.
- Kesalahan: Mengabaikan kolom data ketika dukungan ekstensi tidak ada. → Alasan: Kompatibilitas negosiasi tidak sama dengan keberhasilan validasi. → Solusi: Pisahkan kasus tidak didukung, kegagalan validasi, dan fallback biasa.
- Kesalahan: Melakukan rotasi hanya berdasarkan timestamp penerbitan. → Alasan: Propagasi dan clock skew dapat menyebabkan edge menggunakan kredensial terlalu dini atau terlalu terlambat. → Solusi: Gunakan tumpang tindih dan pantau sinkronisasi waktu.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Apa perbedaan antara DC dan sertifikat X.509 berumur pendek biasa?
DC terikat pada sertifikat end-entity yang ada dan digunakan dalam handshake TLS, sehingga edge tidak perlu memegang private key induk. Sertifikat berumur pendek biasa biasanya masih memerlukan CA atau sistem sertifikat untuk menerbitkan rantai lengkap. Batas penerapan dan validasi keduanya berbeda.
Pertanyaan lanjutan 2: Apa yang dapat dilakukan penyerang dengan private key DC?
Mereka dapat meniru pihak terkait dalam koneksi TLS baru hingga DC kedaluwarsa, tetapi tidak dapat menggunakannya untuk menerbitkan DC lain. Rentang waktunya bergantung pada masa berlaku, status induk, serta kecepatan deteksi dan respons.
Pertanyaan lanjutan 3: Mengapa DelegationUsage diperlukan?
Ini membatasi sertifikat mana yang secara eksplisit mengizinkan partisipasi DC, sehingga mengurangi risiko lintas protokol akibat memasukkan sertifikat tanpa semantik delegasi ke dalam validasi DC.
Pertanyaan lanjutan 4: Apakah QUIC atau DTLS memerlukan trust root terpisah?
Tidak diperlukan trust root baru, tetapi konteks protokol dan aturan ekstensi RFC 9345 harus memvalidasi penggunaan, kolom handshake, dan algoritma. Parsing TLS tidak dapat digunakan kembali untuk protokol lain tanpa peninjauan tersebut.