Kedaulatan, ketersediaan, performa, dan skalabilitas utama di HSM Terkelola
Kunci kriptografi adalah akar kepercayaan untuk mengamankan sistem komputer modern, baik di tempat maupun di cloud. Jadi, mengontrol siapa yang memiliki otoritas atas kunci tersebut sangat penting untuk membangun aplikasi yang aman dan sesuai.
Di Azure, visi kami tentang bagaimana manajemen kunci harus dilakukan di cloud adalah kedaulatan kunci. Kedaulatan utama berarti bahwa organisasi pelanggan memiliki kontrol penuh dan eksklusif atas siapa yang dapat mengakses kunci dan mengubah kebijakan manajemen kunci, dan atas layanan Azure apa yang menggunakan kunci ini. Setelah keputusan ini dibuat oleh pelanggan, personel Microsoft dicegah melalui cara teknis untuk mengubah keputusan ini. Kode layanan manajemen kunci menjalankan keputusan pelanggan sampai pelanggan memberi tahunya untuk melakukan sebaliknya, dan personel Microsoft tidak dapat melakukan intervensi.
Pada saat yang sama, adalah keyakinan kami bahwa setiap layanan di cloud harus dikelola sepenuhnya. Layanan harus memberikan ketersediaan, ketahanan, keamanan, dan janji mendasar cloud yang diperlukan, yang didukung oleh perjanjian tingkat layanan (SLA). Untuk memberikan layanan terkelola, Microsoft perlu melakukan patch server manajemen kunci, meningkatkan firmware modul keamanan perangkat keras (HSM), menyembuhkan perangkat keras yang gagal, melakukan failover, dan melakukan operasi hak istimewa tinggi lainnya. Seperti yang diketahui sebagian besar profesional keamanan, menolak seseorang dengan hak istimewa tinggi atau akses fisik ke akses sistem ke data dalam sistem tersebut adalah masalah yang sulit.
Artikel ini menjelaskan bagaimana kami memecahkan masalah ini dalam layanan Azure Key Vault Managed HSM, memberi pelanggan kedaulatan kunci penuh dan SLA layanan terkelola penuh dengan menggunakan teknologi komputasi rahasia yang dipasangkan dengan HSM.
Lingkungan perangkat keras HSM terkelola
Kumpulan HSM Terkelola pelanggan di wilayah Azure mana pun berada di pusat data Azure yang aman. Tiga instans tersebar di beberapa server. Setiap instans disebarkan di rak yang berbeda untuk memastikan redundansi. Setiap server memiliki Adaptor HSM Marvell LiquidSecurity yang divalidasi FIPS 140-2 Level 3 dengan beberapa inti kriptografi. Inti digunakan untuk membuat partisi HSM yang sepenuhnya terisolasi, termasuk kredensial yang sepenuhnya terisolasi, penyimpanan data, dan kontrol akses.
Pemisahan fisik instans di dalam pusat data sangat penting untuk memastikan bahwa hilangnya satu komponen (misalnya, sakelar top-of-rack atau unit manajemen daya di rak) tidak dapat memengaruhi semua instans kumpulan. Server ini didedikasikan untuk tim Azure Security HSM. Server tidak dibagikan dengan tim Azure lainnya, dan tidak ada beban kerja pelanggan yang disebarkan di server ini. Kontrol akses fisik, termasuk rak terkunci, digunakan untuk mencegah akses tidak sah ke server. Kontrol ini memenuhi FedRAMP-High, PCI, SOC 1/2/3, ISO 270x, dan standar keamanan dan privasi lainnya, dan secara teratur diverifikasi secara independen sebagai bagian dari program kepatuhan Azure. HSM telah meningkatkan keamanan fisik, divalidasi untuk memenuhi persyaratan FIPS 140-2 Level 3. Seluruh layanan HSM Terkelola dibangun di atas platform Azure aman standar, termasuk peluncuran tepercaya, yang melindungi dari ancaman persisten tingkat lanjut.
Adaptor HSM dapat mendukung puluhan partisi HSM yang terisolasi. Berjalan di setiap server adalah proses kontrol yang disebut Node Service. Node Service mengambil kepemilikan setiap adaptor dan menginstal kredensial untuk pemilik adaptor, dalam hal ini, Microsoft. HSM dirancang agar kepemilikan adaptor tidak memberi Microsoft akses ke data yang disimpan dalam partisi pelanggan. Ini hanya memungkinkan Microsoft untuk membuat, mengubah ukuran, dan menghapus partisi pelanggan. Ini mendukung pengambilan cadangan buta dari partisi apa pun untuk pelanggan. Dalam cadangan buta, cadangan dibungkus oleh kunci yang disediakan pelanggan yang dapat dipulihkan oleh kode layanan hanya di dalam instans HSM Terkelola yang dimiliki oleh pelanggan, dan yang kontennya tidak dapat dibaca oleh Microsoft.
Arsitektur kumpulan HSM Terkelola
Gambar 1 menunjukkan arsitektur kumpulan HSM, yang terdiri dari tiga VM Linux, masing-masing berjalan di server HSM di rak pusat datanya sendiri untuk mendukung ketersediaan. Komponen pentingnya adalah:
- Pengontrol kain HSM (HFC) adalah sarana kontrol untuk layanan. HFC mendorong patching dan perbaikan otomatis untuk kumpulan.
- Batas kriptografi yang sesuai dengan FIPS 140-2 Level 3, eksklusif untuk setiap pelanggan, termasuk tiga enklave rahasia Intel Secure Guard Extensions (Intel SGX), masing-masing terhubung ke instans HSM. Kunci akar untuk batas ini dihasilkan dan disimpan dalam tiga HSM. Seperti yang kami jelaskan nanti dalam artikel ini, tidak ada orang yang terkait dengan Microsoft yang memiliki akses ke data yang berada dalam batas ini. Hanya kode layanan yang berjalan di enklave Intel SGX (termasuk agen Node Service), yang bertindak atas nama pelanggan, yang memiliki akses.
Lingkungan eksekusi tepercaya (TEE)
Kumpulan HSM Terkelola terdiri dari tiga instans layanan. Setiap instans layanan diimplementasikan sebagai lingkungan eksekusi tepercaya (TEE) yang menggunakan kemampuan Intel SGX dan Open Enclave SDK. Eksekusi dalam TEE memastikan bahwa tidak ada orang di komputer virtual (VM) yang menghosting layanan atau server host VM memiliki akses ke rahasia pelanggan, data, atau partisi HSM. Setiap TEE didedikasikan untuk pelanggan tertentu, dan menjalankan manajemen TLS, penanganan permintaan, dan kontrol akses ke partisi HSM. Tidak ada kredensial atau kunci enkripsi data khusus pelanggan yang ada dalam teks yang jelas di luar TEE ini, kecuali sebagai bagian dari paket domain keamanan. Paket tersebut dienkripsi ke kunci yang disediakan pelanggan, dan diunduh ketika kumpulan mereka pertama kali dibuat.
TEE berkomunikasi di antara mereka sendiri dengan menggunakan TLS yang dites. TLS yang dibuktikan menggabungkan kemampuan pengesahan jarak jauh platform Intel SGX dengan TLS 1.2. Ini memungkinkan kode HSM Terkelola di TEE untuk membatasi komunikasinya hanya ke kode lain yang ditandatangani oleh kunci penandatanganan kode layanan HSM Terkelola yang sama, untuk mencegah serangan man-in-the-middle. Kunci penandatanganan kode layanan HSM Terkelola disimpan di Microsoft Product Release and Security Service (yang juga digunakan untuk menyimpan, misalnya, kunci penandatanganan kode Windows). Kunci dikendalikan oleh tim HSM Terkelola. Sebagai bagian dari kewajiban peraturan dan kepatuhan kami untuk manajemen perubahan, kunci ini tidak dapat digunakan oleh tim Microsoft lainnya untuk menandatangani kodenya.
Sertifikat TLS yang digunakan untuk komunikasi TEE-ke-TEE dikeluarkan sendiri oleh kode layanan di dalam TEE. Sertifikat berisi laporan platform yang dihasilkan oleh enklave Intel SGX di server. Laporan platform ditandatangani dengan kunci yang berasal dari kunci yang menyatu dengan Intel ke dalam CPU saat diproduksi. Laporan mengidentifikasi kode yang dimuat ke enklave Intel SGX dengan kunci penandatanganan kode dan hash binernya. Dari laporan platform ini, instans layanan dapat menentukan bahwa serekan juga ditandatangani oleh kunci penandatanganan kode layanan HSM Terkelola, dan, dengan beberapa entanglemen kripto melalui laporan platform, itu juga dapat menentukan bahwa kunci penandatanganan sertifikat yang dikeluarkan sendiri juga harus dibuat di dalam TEE, untuk mencegah peniruan eksternal.
Menawarkan SLA ketersediaan dengan kontrol kunci yang dikelola pelanggan penuh
Untuk memastikan ketersediaan tinggi, layanan HFC membuat tiga kumpulan di wilayah Azure yang dipilih pelanggan.
Pembuatan kumpulan HSM terkelola
Properti ketersediaan tinggi kumpulan HSM Terkelola berasal dari instans HSM tiga kali lipat yang dikelola secara otomatis yang selalu disinkronkan (atau, jika Anda menggunakan replikasi multi-wilayah, agar keenam instans tetap sinkron). Pembuatan kumpulan dikelola oleh layanan HFC, yang mengalokasikan kumpulan di seluruh perangkat keras yang tersedia di wilayah Azure yang dipilih pelanggan.
Ketika kumpulan baru diminta, HFC memilih tiga server di beberapa rak yang memiliki ruang yang tersedia pada adaptor HSM mereka, dan kemudian mulai membuat kumpulan:
HFC menginstruksikan agen Node Service pada masing-masing dari tiga TEE untuk meluncurkan instans baru kode layanan dengan menggunakan sekumpulan parameter. Parameter mengidentifikasi penyewa Microsoft Entra pelanggan, alamat IP jaringan virtual internal dari ketiga instans, dan beberapa konfigurasi layanan lainnya. Satu partisi ditetapkan secara acak sebagai primer.
Tiga instans dimulai. Setiap instans terhubung ke partisi pada adaptor HSM lokalnya, dan kemudian nol dan menginisialisasi partisi dengan menggunakan nama pengguna dan kredensial yang dihasilkan secara acak (untuk memastikan bahwa partisi tidak dapat diakses oleh operator manusia atau oleh instans TEE lain).
Instans utama membuat sertifikat akar pemilik partisi dengan menggunakan kunci privat yang dihasilkan di HSM. Ini menetapkan kepemilikan kumpulan dengan menandatangani sertifikat tingkat partisi untuk partisi HSM dengan menggunakan sertifikat akar ini. Primer juga menghasilkan kunci enkripsi data, yang digunakan untuk melindungi semua data pelanggan saat tidak aktif di dalam layanan. Untuk bahan kunci, pembungkusan ganda digunakan karena HSM juga melindungi bahan kunci itu sendiri.
Selanjutnya, data kepemilikan ini disinkronkan ke dua instans sekunder. Setiap sekunder menghubungi primer dengan menggunakan TLS yang dites. Primer berbagi sertifikat akar pemilik partisi dengan kunci privat dan kunci enkripsi data. Sekunder sekarang menggunakan sertifikat akar partisi untuk mengeluarkan sertifikat partisi ke partisi HSM mereka sendiri. Setelah ini selesai, Anda memiliki partisi HSM pada tiga server terpisah yang dimiliki oleh sertifikat akar partisi yang sama.
Melalui tautan TLS yang diujukkan, partisi HSM utama berbagi dengan sekunder kunci pembungkus data yang dihasilkan (digunakan untuk mengenkripsi pesan antara ketiga HSM) dengan menggunakan API aman yang disediakan oleh vendor HSM. Selama pertukaran ini, HSM mengonfirmasi bahwa mereka memiliki sertifikat pemilik partisi yang sama, dan kemudian mereka menggunakan skema Diffie-Hellman untuk mengenkripsi pesan sehingga kode layanan Microsoft tidak dapat membacanya. Semua yang dapat dilakukan kode layanan adalah mengangkut blob buram antara HSM.
Pada titik ini, ketiga instans siap untuk diekspos sebagai kumpulan di jaringan virtual pelanggan. Mereka berbagi sertifikat pemilik partisi dan kunci privat yang sama, kunci enkripsi data yang sama, dan kunci pembungkusan data umum. Namun, setiap instans memiliki kredensial unik ke partisi HSM mereka. Sekarang langkah-langkah akhir selesai.
Setiap instans menghasilkan pasangan kunci RSA dan permintaan penandatanganan sertifikat (CSR) untuk sertifikat TLS yang menghadap publik. CSR ditandatangani oleh sistem infrastruktur kunci publik (PKI) Microsoft dengan menggunakan akar publik Microsoft, dan sertifikat TLS yang dihasilkan dikembalikan ke instans.
Ketiga instans mendapatkan kunci penyegelan Intel SGX mereka sendiri dari CPU lokal mereka. Kunci dihasilkan dengan menggunakan kunci unik CPU sendiri dan kunci penandatanganan kode TEE.
Kumpulan ini memperoleh kunci kumpulan unik dari kunci penyegelan Intel SGX, mengenkripsi semua rahasianya dengan menggunakan kunci kumpulan ini, lalu menulis blob terenkripsi ke disk. Blob ini hanya dapat didekripsi dengan ditandatangani kode oleh kunci penyegelan Intel SGX yang sama yang berjalan pada CPU fisik yang sama. Rahasia terikat ke instans tertentu tersebut.
Proses bootstrap aman sekarang selesai. Proses ini telah memungkinkan pembuatan kumpulan HSM triple-redundan dan pembuatan jaminan kriptografi dari kedaulatan data pelanggan.
Mempertahankan SLA ketersediaan saat runtime dengan menggunakan penyembuhan layanan rahasia
Cerita pembuatan kumpulan yang dijelaskan dalam artikel ini dapat menjelaskan bagaimana layanan HSM Terkelola dapat memberikan SLA ketersediaan tingginya dengan mengelola server yang mendasar layanan dengan aman. Bayangkan bahwa server, adaptor HSM, atau bahkan catu daya ke rak, gagal. Tujuan dari layanan HSM Terkelola adalah, tanpa intervensi pelanggan atau kemungkinan rahasia terekspos dalam teks yang jelas di luar TEE, untuk menyembuhkan kumpulan kembali ke tiga instans sehat. Hal ini dicapai melalui penyembuhan layanan rahasia.
Ini dimulai dengan HFC yang mendeteksi kumpulan mana yang memiliki instans di server yang gagal. HFC menemukan server baru yang sehat dalam wilayah kumpulan untuk menyebarkan instans pengganti. Ini meluncurkan instans baru, yang kemudian diperlakukan persis sebagai sekunder selama langkah provisi awal: menginisialisasi HSM, menemukan rahasia utamanya yang ditukar dengan aman melalui TLS yang dibuktikan, menandatangani HSM ke dalam hierarki kepemilikan, dan kemudian menyegel data layanannya ke CPU barunya. Layanan ini sekarang disembuhkan, sepenuhnya otomatis dan sepenuhnya rahasia.
Memulihkan dari bencana dengan menggunakan domain keamanan
Domain keamanan adalah blob aman yang berisi semua kredensial yang diperlukan untuk membangun kembali partisi HSM dari awal: kunci pemilik partisi, kredensial partisi, kunci pembungkus data, ditambah cadangan awal HSM. Sebelum layanan ditayangkan, pelanggan harus mengunduh domain keamanan dengan menyediakan sekumpulan kunci enkripsi RSA untuk mengamankannya. Data domain keamanan berasal dari TEE dan dilindungi oleh kunci konten yang dihasilkan dan implementasi algoritma Berbagi Rahasia Shamir, yang membagi berbagi kunci di seluruh kunci publik RSA yang disediakan pelanggan sesuai dengan parameter kuorum yang dipilih pelanggan. Selama proses ini, tidak ada kunci layanan atau kredensial yang pernah diekspos dalam teks biasa di luar kode layanan yang berjalan di TEEs. Hanya pelanggan, dengan menyajikan kuorum kunci RSA mereka ke TEE, yang dapat mendekripsi domain keamanan selama skenario pemulihan.
Domain keamanan hanya diperlukan ketika, karena beberapa bencana, seluruh wilayah Azure hilang dan Microsoft kehilangan ketiga instans kumpulan secara bersamaan. Jika hanya satu instans, atau bahkan dua instans, yang hilang, maka penyembuhan layanan rahasia akan diam-diam pulih ke tiga instans sehat tanpa intervensi pelanggan. Jika seluruh wilayah hilang, karena kunci penyegelan Intel SGX unik untuk setiap CPU, Microsoft tidak memiliki cara untuk memulihkan kredensial HSM dan kunci pemilik partisi. Mereka hanya ada dalam konteks instans.
Dalam kejadian yang sangat tidak mungkin terjadi bencana ini, pelanggan dapat memulihkan status kumpulan dan data mereka sebelumnya dengan membuat kumpulan kosong baru, menyuntikkannya ke domain keamanan, dan kemudian menyajikan kuorum kunci RSA mereka untuk membuktikan kepemilikan domain keamanan. Jika pelanggan telah mengaktifkan replikasi multi-wilayah, bencana yang bahkan lebih tidak mungkin dari kedua wilayah yang mengalami kegagalan lengkap secara bersamaan harus terjadi sebelum intervensi pelanggan diperlukan untuk memulihkan kumpulan dari domain keamanan.
Mengontrol akses ke layanan
Seperti yang dijelaskan, kode layanan kami di TEE adalah satu-satunya entitas yang memiliki akses ke HSM itu sendiri karena kredensial yang diperlukan tidak diberikan kepada pelanggan atau kepada orang lain. Sebagai gantinya, kumpulan pelanggan terikat dengan instans Microsoft Entra mereka, dan ini digunakan untuk autentikasi dan otorisasi. Pada provisi awal, pelanggan dapat memilih sekumpulan karyawan awal untuk menetapkan peran Administrator untuk kumpulan. Individu-individu ini, dan karyawan dalam peran Administrator Global penyewa Microsoft Entra pelanggan, dapat mengatur kebijakan kontrol akses dalam kumpulan. Semua kebijakan kontrol akses disimpan oleh layanan dalam database yang sama dengan kunci yang ditutupi, yang juga dienkripsi. Hanya kode layanan di TEE yang memiliki akses ke kebijakan kontrol akses ini.
Ringkasan
HSM terkelola menghilangkan kebutuhan pelanggan untuk melakukan tradeoff antara ketersediaan dan kontrol atas kunci kriptografi dengan menggunakan teknologi enklave rahasia yang canggih dan didukung perangkat keras. Seperti yang dijelaskan dalam artikel ini, dalam implementasi ini, tidak ada personel atau perwakilan Microsoft yang dapat mengakses materi kunci yang dikelola pelanggan atau rahasia terkait, bahkan dengan akses fisik ke komputer host dan HSM HSM Terkelola. Keamanan ini telah memungkinkan pelanggan kami dalam layanan keuangan, manufaktur, sektor publik, pertahanan, dan vertikal lainnya untuk mempercepat migrasi mereka ke cloud dengan keyakinan penuh.