Merancang hierarki CA

Dengan AWS Private CA, Anda dapat membuat hierarki otoritas sertifikat hingga lima level. CA akar, di bagian atas pohon hierarki, dapat memiliki sejumlah cabang. CA akar dapat memiliki sebanyak empat tingkat CA bawahan di setiap cabang. Anda juga dapat membuat beberapa hierarki, masing-masing dengan akarnya sendiri.

Hierarki CA yang dirancang dengan baik menawarkan manfaat berikut:

• Kontrol keamanan terperinci yang sesuai untuk setiap CA

• Pembagian tugas administratif untuk penyeimbangan beban dan keamanan yang lebih baik

• Penggunaan CA dengan kepercayaan terbatas yang dapat dibatalkan untuk operasi sehari-hari

• Masa validitas dan batas jalur sertifikat

Diagram berikut mengilustrasikan hierarki CA tiga tingkat yang sederhana.

Setiap CA di pohon didukung oleh sertifikat X.509 v3 dengan otoritas penandatanganan (dilambangkan dengan ikon). pen-and-paper Ini berarti bahwa sebagai CA, sertifikat lain yang berada di bawahnya dapat ditandatangani. Ketika CA menandatangani sertifikat CA tingkat yang lebih rendah, itu memberikan otoritas terbatas yang dapat dibatalkan pada sertifikat yang ditandatangani. CA akar di level 1 menandatangani sertifikat CA bawahan tingkat tinggi di level 2. CA ini, pada gilirannya, menandatangani sertifikat untuk CA di level 3 yang digunakan oleh administrator PKI (infrastruktur kunci publik) yang mengelola sertifikat entitas akhir.

Keamanan dalam hierarki CA harus dikonfigurasikan menjadi yang terkuat di bagian atas hierarki. Pengaturan ini melindungi sertifikat CA akar dan kunci privatnya. CA akar menambatkan kepercayaan untuk semua CA bawahan dan sertifikat entitas akhir di bawahnya. Sementara kerusakan lokal dapat dihasilkan dari kompromi sertifikat entitas akhir, kompromi akar menghancurkan kepercayaan di seluruh PKI. Root dan CA bawahan tingkat tinggi jarang digunakan (biasanya untuk menandatangani sertifikat CA lainnya). Akibatnya, mereka dikontrol dengan ketat dan diaudit untuk memastikan risiko kompromi yang lebih rendah. Di tingkat hierarki yang lebih rendah, keamanan tidak terlalu ketat. Pendekatan ini memungkinkan tugas administratif rutin menerbitkan dan mencabut sertifikat entitas akhir untuk pengguna, host komputer, dan layanan perangkat lunak.

catatan

Menggunakan CA akar untuk menandatangani sertifikat bawahan adalah peristiwa langka yang terjadi hanya dalam beberapa keadaan:

• Saat PKI dibuat

• Ketika otoritas sertifikat tingkat tinggi perlu diganti

• Saat penanggap daftar pencabutan sertifikat (CRL) atau Protokol Status Sertifikat Online (OCSP) perlu dikonfigurasi

Akar dan CA tingkat tinggi lainnya memerlukan proses operasional dan protokol kontrol akses yang sangat aman.

Memvalidasi sertifikat entitas akhir

Sertifikat entitas akhir mendapatkan kepercayaannya dari jalur sertifikasi yang mengarah kembali melalui CA bawahan ke CA akar. Ketika disajikan dengan sertifikat entitas akhir, peramban web atau klien lain mencoba membangun rantai kepercayaan. Misalnya, mungkin memeriksa untuk melihat bahwa nama khusus penerbit sertifikat dan nama khusus subjek cocok dengan bidang yang sesuai dari sertifikat CA penerbit. Pencocokan akan berlanjut di setiap tingkat berturut-turut ke atas hierarki hingga klien mencapai akar tepercaya yang terkandung dalam penyimpanan kepercayaannya.

Penyimpanan kepercayaan adalah pustaka CA tepercaya yang berisi peramban atau sistem operasi. Untuk PKI privat, TI organisasi Anda harus memastikan bahwa setiap peramban atau sistem sebelumnya telah menambahkan CA akar privat ke penyimpanan kepercayaannya. Jika tidak, jalur sertifikasi tidak dapat divalidasi, yang mengakibatkan kesalahan klien.

Diagram berikutnya menunjukkan jalur validasi yang diikuti peramban saat disajikan dengan sertifikat X.509 entitas akhir. Perhatikan bahwa sertifikat entitas akhir tidak memiliki otoritas penandatanganan dan hanya berfungsi untuk mengautentikasi entitas yang memilikinya.

Peramban memeriksa sertifikat entitas akhir. Peramban menemukan bahwa sertifikat menawarkan tanda tangan dari CA bawahan (level 3) sebagai kredensial kepercayaannya. Sertifikat untuk CA bawahan harus disertakan dalam file PEM yang sama. Atau, mereka juga dapat berada dalam file terpisah yang berisi sertifikat yang membentuk rantai kepercayaan. Setelah menemukan ini, peramban memeriksa sertifikat CA bawahan (tingkat 3) dan menemukan bahwa sertifikat CA bawahan menawarkan tanda tangan dari CA bawahan (tingkat 2). Pada gilirannya, CA bawahan (level 2) menawarkan tanda tangan dari CA akar (level 1) sebagai kredensial kepercayaannya. Jika peramban menemukan salinan sertifikat CA akar privat yang telah diinstal sebelumnya di penyimpanan kepercayaannya, peramban akan memvalidasi sertifikat entitas akhir sebagai tepercaya.

Biasanya, peramban juga memeriksa setiap sertifikat terhadap daftar pencabutan sertifikat (CRL). Sertifikat yang kedaluwarsa, dicabut, atau salah konfigurasi ditolak dan validasi gagal.

Merencanakan struktur hierarki CA

Secara umum, hierarki CA Anda harus mencerminkan struktur organisasi Anda. Bertujuan untuk panjang jalur (yaitu, jumlah tingkat CA) tidak lebih dari yang diperlukan untuk mendelegasikan peran administratif dan keamanan. Menambahkan CA ke hierarki berarti meningkatkan jumlah sertifikat di jalur sertifikasi, yang meningkatkan waktu validasi. Menjaga panjang jalur seminimal mungkin juga mengurangi jumlah sertifikat yang dikirim dari server ke klien saat memvalidasi sertifikat entitas akhir.

Secara teori, CA root, yang tidak memiliki pathLenConstraintparameter, dapat mengotorisasi tingkat CA bawahan yang tidak terbatas. CA bawahan dapat memiliki CA bawahan anak sebanyak yang diizinkan oleh konfigurasi internalnya. AWS Private CA hierarki terkelola mendukung jalur sertifikasi CA hingga kedalaman lima tingkat.

Struktur CA yang dirancang dengan baik memiliki beberapa manfaat:

• Kontrol administratif terpisah untuk unit organisasi lain

• Kemampuan untuk mendelegasikan akses ke CA bawahan

• Struktur hierarkis yang melindungi CA tingkat tinggi dengan kontrol keamanan tambahan

Dua struktur CA umum mencakup semua ini:

• Dua level CA: CA akar dan CA bawahan

  Ini adalah struktur CA paling sederhana yang memungkinkan administrasi, kontrol, dan kebijakan keamanan terpisah untuk CA akar dan CA bawahan. Anda dapat mempertahankan kontrol dan kebijakan yang membatasi untuk CA akar Anda sambil mengizinkan akses yang lebih permisif untuk CA bawahan. Yang kedua ini digunakan untuk penerbitan massal sertifikat entitas akhir.

• Tiga level CA: root CA dan dua lapisan CA bawahan

  Mirip dengan yang di atas, struktur ini menambahkan lapisan CA tambahan untuk lebih memisahkan CA akar dari operasi CA tingkat rendah. Lapisan CA tengah hanya digunakan untuk menandatangani CA bawahan yang melakukan penerbitan sertifikat entitas akhir.

Struktur CA yang kurang umum meliputi berikut ini:

• Empat atau lebih level CA

  Meskipun kurang umum daripada hierarki tiga tingkat, hierarki CA dengan empat atau lebih tingkat dimungkinkan dan mungkin diperlukan untuk memungkinkan delegasi administratif.

• Satu level CA: root CA saja

  Struktur ini biasanya digunakan untuk developer dan pengujian ketika rantai kepercayaan penuh tidak diperlukan. Digunakan dalam produksi, itu tidak lazim. Selain itu, ini melanggar praktik terbaik dalam mempertahankan kebijakan keamanan terpisah untuk CA akar dan CA yang menerbitkan sertifikat entitas akhir.

  Namun, jika Anda sudah menerbitkan sertifikat langsung dari CA root, Anda dapat bermigrasi ke. AWS Private CA Melakukannya memberikan keuntungan keamanan dan kontrol dibandingkan menggunakan root CA yang dikelola dengan OpenSSL atau perangkat lunak lain.

Contoh PKI privat untuk produsen

Dalam contoh ini, perusahaan teknologi hipotetis memproduksi dua produk Internet untuk Segala (IoT), bola lampu pintar dan pemanggang roti pintar. Selama produksi, setiap perangkat menerbiktan sertifikat entitas akhir sehingga dapat berkomunikasi dengan aman melalui internet dengan produsen. PKI perusahaan juga mengamankan infrastruktur komputernya, termasuk situs web internal dan berbagai layanan komputer dengan host mandiri yang menjalankan keuangan dan operasi bisnis.

Hasilnya, model hierarki CA hampir mirip dengan aspek administratif dan operasional bisnis ini.

Hierarki ini berisi tiga akar, satu untuk Operasi Internal dan dua untuk Operasi Eksternal (satu CA akar untuk setiap lini produk). Ini juga menggambarkan beberapa panjang jalur sertifikasi, dengan dua tingkat CA untuk Operasi Internal dan tiga tingkat untuk Operasi Eksternal.

Penggunaan CA root terpisah dan lapisan CA bawahan tambahan di sisi Operasi Eksternal adalah keputusan desain yang melayani kebutuhan bisnis dan keamanan. Dengan beberapa pohon CA, PKI tahan terhadap reorganisasi, divestasi, atau akuisisi perusahaan nantinya. Saat terjadi perubahan, seluruh hierarki CA akar dapat bergerak dengan teratur dengan divisi yang diamankannya. Dan dengan dua tingkat CA bawahan, CA akar memiliki tingkat isolasi yang tinggi dari CA tingkat 3 yang bertanggung jawab untuk menandatangani sertifikat secara massal untuk ribuan atau jutaan item yang diproduksi.

Di sisi internal, web perusahaan dan operasi komputer internal melengkapi hierarki dua tingkat. Tingkat ini memungkinkan administrator web dan teknisi operasi untuk mengelola penerbitan sertifikat secara independen untuk domain kerjanya sendiri. Pengelompokan PKI ke dalam domain fungsional yang berbeda adalah praktik terbaik keamanan dan melindungi masing-masing dari kompromi yang mungkin memengaruhi yang lain. Administrator web menerbitkan sertifikat entitas akhir untuk digunakan oleh peramban web di seluruh perusahaan, mengautentikasi dan mengenkripsi komunikasi di situs web internal. Teknisi operasi menerbitkan sertifikat entitas akhir yang mengautentikasi host pusat data dan layanan komputasi satu sama lain. Sistem ini membantu menjaga keamanan data sensitif dengan mengenkripsinya di LAN.

Menetapkan batasan panjang pada jalur sertifikasi

Struktur hierarki CA ditentukan dan ditegakkan oleh ekstensi batasan dasar yang ada dalam setiap sertifikat. Ekstensi menentukan dua kendala:

• cA – Apakah sertifikat menentukan CA. Jika nilai ini SALAH (default), maka sertifikat tersebut adalah sertifikat entitas akhir.

• pathLenConstraint— Jumlah maksimum CA bawahan tingkat rendah yang dapat ada dalam rantai kepercayaan yang valid. Sertifikat entitas akhir tidak dihitung karena bukan sertifikat CA.

Sertifikat CA akar membutuhkan fleksibilitas maksimum dan tidak menyertakan batasan panjang jalur. Ini memungkinkan root untuk menentukan jalur sertifikasi dengan panjang berapa pun.

catatan

AWS Private CA membatasi jalur sertifikasi hingga lima tingkat.

CA bawahan memiliki nilai pathLenConstraint yang sama dengan atau lebih besar dari nol, bergantung pada lokasi dalam penempatan hierarki dan fitur yang diinginkan. Misalnya, dalam hierarki dengan tiga CA, tidak ada batasan jalur yang ditentukan untuk CA akar. CA bawahan pertama memiliki panjang jalur 1 dan karena itu dapat menandatangani CA turunan. Masing-masing CA turunan ini harus memiliki nilai nol pathLenConstraint. Ini berarti bahwa mereka dapat menandatangani sertifikat entitas akhir, tetapi tidak dapat menerbitkan sertifikat CA tambahan. Membatasi kekuatan untuk membuat CA baru adalah kontrol keamanan yang penting.

Diagram berikut mengilustrasikan penyebaran otoritas terbatas ini ke bawah hierarki.

Dalam hierarki empat tingkat ini, akar tidak dibatasi (seperti biasa). Tetapi CA bawahan pertama memiliki nilai 2 pathLenConstraint, yang membatasi CA turunannya untuk naik lebih dari dua tingkat. Hasilnya, untuk jalur sertifikasi yang valid, nilai kendala harus dikurangi menjadi nol di dua tingkat berikutnya. Jika peramban web menemukan sertifikat entitas akhir dari cabang ini yang memiliki panjang jalur lebih dari empat, validasi gagal. Sertifikat tersebut dapat merupakan hasil dari CA yang dibuat secara tidak sengaja, CA yang salah konfigurasi, atau penerbitan yang tidak sah.

Mengelola panjang jalur dengan template

AWS Private CA menyediakan template untuk menerbitkan sertifikat root, subordinat, dan entitas akhir. Templat ini merangkum praktik terbaik untuk nilai-nilai batasan dasar, termasuk panjang jalur. Templat meliputi hal-hal berikut:

• RootCACertificate/V1

• Subordinatecacertificate_ 0/V1 PathLen

• Subordinatecacertificate_ 1/V1 PathLen

• Subordinatecacertificate_ 2/V1 PathLen

• Subordinatecacertificate_ 3/V1 PathLen

• EndEntityCertificate/V1

IssueCertificate API akan mengembalikan kesalahan jika Anda mencoba membuat CA dengan panjang jalur lebih besar atau sama dengan panjang jalur sertifikat CA yang diterbitkannya.

Untuk informasi selengkapnya tentang templat sertifikat, lihat Memahami templat sertifikat.

Mengotomatiskan penyiapan hierarki CA dengan AWS CloudFormation

Ketika Anda telah menetapkan desain untuk hierarki CA Anda, Anda dapat mengujinya dan memasukkannya ke dalam produksi menggunakan AWS CloudFormation templat. Untuk contoh templat seperti itu, lihat Mendeklarasikan Hirarki CA Privat di Panduan Pengguna AWS CloudFormation .