Konsep dasar Azure Key Vault
Azure Key Vault adalah layanan cloud untuk menyimpan dan mengakses rahasia dengan aman. Rahasia adalah segala hal yang aksesnya ingin Anda kontrol dengan ketat, seperti kunci API, kata sandi, sertifikat, atau kunci kriptografi. Layanan Key Vault mendukung dua jenis kontainer: vault dan kumpulan modul keamanan perangkat keras terkelola (HSM). Vault mendukung penyimpanan perangkat lunak dan kunci, rahasia, dan sertifikat yang didukung HSM. Kumpulan HSM terkelola hanya mendukung kunci yang didukung HSM. Lihat ringkasan REST API Azure Key Vault untuk rincian lengkap.
Berikut adalah istilah penting lainnya:
Penyewa: Penyewa adalah organisasi yang memiliki dan mengelola instans tertentu dari layanan cloud Microsoft. Ini paling sering digunakan untuk merujuk ke set layanan Azure dan Microsoft 365 untuk organisasi.
Pemilik vault: Pemilik vault dapat membuat brankas kunci dan mendapatkan akses dan kontrol penuh atasnya. Pemilik vault juga dapat menyiapkan audit untuk mencatat siapa yang mengakses rahasia dan kunci. Admin dapat mengontrol siklus hidup kunci. Mereka dapat bergulir ke versi baru kunci, mencadangkannya, dan melakukan tugas terkait.
Konsumen vault: Konsumen vault dapat melakukan tindakan pada aset di dalam brankas kunci ketika pemilik vault memberikan akses konsumen. Tindakan yang tersedia bergantung pada izin yang diberikan.
Administrator HSM Terkelola: Pengguna yang diberi peran Administrator memiliki kontrol penuh atas kumpulan HSM terkelola. Mereka dapat membuat lebih banyak penetapan peran untuk mendelegasikan akses terkontrol ke pengguna lain.
Officer/Pengguna HSM Crypto Terkelola: Peran bawaan yang biasanya ditetapkan kepada pengguna atau perwakilan layanan yang akan melakukan operasi kriptografi menggunakan kunci dalam HSM Terkelola. Pengguna Kripto dapat membuat kunci baru, tetapi tidak dapat menghapus kunci.
Pengguna Enkripsi Layanan Kripto HSM Terkelola: Peran bawaan yang biasanya ditetapkan ke identitas layanan terkelola akun layanan (misalnya, Akun penyimpanan) untuk enkripsi data tidak aktif dengan kunci yang dikelola pelanggan.
Sumber daya - Item yang dapat dikelola yang tersedia melalui Azure. Contoh umumnya adalah komputer virtual, akun penyimpanan, aplikasi web, database, dan jaringan virtual. Masih banyak lagi.
Kelompok sumber daya: Kelompok sumber daya adalah kontainer yang menampung sumber daya terkait untuk sebuah solusi Azure. Grup sumber daya dapat menyertakan semua sumber daya untuk solusi, atau hanya sumber daya yang ingin Anda kelola sebagai grup. Anda memutuskan bagaimana Anda ingin mengalokasikan sumber daya ke kelompok sumber daya, berdasarkan apa yang paling masuk akal bagi organisasi Anda.
Perwakilan keamanan: Perwakilan keamanan utama Azure adalah identitas keamanan yang digunakan oleh aplikasi, layanan, dan alat otomatisasi yang dibuat pengguna untuk mengakses sumber daya Azure tertentu. Anggap saja sebagai "identitas pengguna" (nama pengguna dan kata sandi atau sertifikat) dengan peran tertentu, dan izin yang dikontrol dengan ketat. Seorang perwakilan keamanan hanya perlu melakukan hal-hal tertentu, berbeda dengan identitas pengguna umum. Ini meningkatkan keamanan jika Anda hanya memberinya tingkat izin minimum yang diperlukan untuk melakukan tugas manajemennya. Perwakilan keamanan yang digunakan dengan aplikasi atau layanan disebut perwakilan layanan.
ID Microsoft Entra: ID Microsoft Entra adalah layanan Direktori Aktif untuk penyewa. Setiap direktori memiliki satu domain atau lebih. Sebuah direktori dapat memiliki banyak langganan yang terkait dengannya, tetapi hanya satu penyewa.
ID penyewa Azure: ID penyewa adalah cara unik untuk mengidentifikasi instans Microsoft Entra dalam langganan Azure.
Identitas terkelola:Azure Key Vault menyediakan cara untuk menyimpan kredensial dengan aman serta kunci dan rahasia lainnya, tetapi kode Anda perlu mengautentikasi ke Key Vault untuk mengambilnya. Menggunakan identitas terkelola membuat penyelesaian masalah ini lebih sederhana dengan memberi layanan Azure identitas yang dikelola secara otomatis di ID Microsoft Entra. Anda dapat menggunakan identitas ini untuk mengautentikasi ke Key Vault atau layanan apa pun yang mendukung autentikasi Microsoft Entra, tanpa memiliki kredensial apa pun dalam kode Anda. Untuk informasi selengkapnya, lihat gambar berikut dan gambaran umum identitas terkelola untuk sumber daya Azure.
Autentikasi
Untuk melakukan operasi apa pun dengan Key Vault, pertama Anda perlu mengautentikasinya. Ada tiga cara untuk mengautentikasi ke Key Vault:
- Identitas terkelola untuk sumber daya Azure: Saat menerapkan aplikasi pada mesin virtual di Azure, Anda dapat menetapkan identitas ke mesin virtual Anda yang memiliki akses ke Key Vault. Anda juga dapat menetapkan identitas ke sumber daya Azure lainnya. Keuntungan dari pendekatan ini adalah bahwa aplikasi atau layanan tidak mengelola rotasi rahasia pertama. Azure secara otomatis memutar identitas. Kami menyarankan pendekatan ini sebagai praktik terbaik.
- Prinsip dan sertifikat layanan: Anda dapat menggunakan prinsip dan sertifikat layanan terkait yang memiliki akses ke Key Vault. Kami tidak menyarankan pendekatan ini karena pemilik atau pengembang aplikasi harus memutar sertifikat.
- Prinsip dan rahasia layanan: Meskipun Anda dapat menggunakan prinsip dan rahasia layanan untuk mengautentikasi ke Key Vault, kami tidak menyarankannya. Sulit untuk memutar rahasia bootstrap secara otomatis yang digunakan untuk mengautentikasi ke Key Vault.
Enkripsi data saat transit
Azure Key Vault memberlakukan protokol Keamanan Lapisan Transportasi (TLS) untuk melindungi data saat berpindah antara Azure Key Vault dan klien. Klien menegosiasikan koneksi TLS dengan Azure Key Vault. TLS menyediakan autentikasi yang kuat, privasi pesan, dan integritas (memungkinkan deteksi perusakan pesan, penyadapan, dan pemalsuan), interoperabilitas, fleksibilitas algoritma, dan kemudahan penyebaran dan penggunaan.
Perfect Forward Secrecy (PFS) melindungi koneksi antara sistem klien pelanggan dan layanan cloud Microsoft dengan kunci unik. Koneksi juga menggunakan panjang kunci enkripsi 2.048-bit berbasis RSA. Kombinasi ini menyulitkan seseorang untuk menyadap dan mengakses data yang sedang transit.
Peran Key Vault
Gunakan tabel berikut untuk lebih memahami bagaimana Key Vault dapat membantu memenuhi kebutuhan pengembang dan administrator keamanan.
| Peran | Pernyataan masalah | Diselesaikan oleh Azure Key Vault |
|---|---|---|
| Pengembang untuk aplikasi Azure | "Saya ingin menulis aplikasi untuk Azure yang menggunakan kunci untuk penandatanganan dan enkripsi. Tapi saya ingin kunci ini berada di luar dari aplikasi saya sehingga solusinya cocok untuk aplikasi yang didistribusikan secara geografis. Saya ingin kunci dan rahasia ini dilindungi, tanpa harus menulis kode sendiri. Saya juga ingin kunci dan rahasia ini mudah bagi saya untuk digunakan dari aplikasi saya, dengan performa optimal." |
√ Kunci disimpan dalam vault dan dipanggil oleh URI saat diperlukan. √ Kunci dijaga oleh Azure, menggunakan algoritme standar industri, panjang kunci, dan modul keamanan perangkat keras. √ Kunci diproses dalam HSM yang berada di pusat data Azure yang sama dengan aplikasi. Metode ini memberikan keandalan yang lebih baik dan latensi yang berkurang dibandingkan kunci yang berada di lokasi terpisah, seperti di lokal. |
| Pengembang untuk perangkat lunak sebagai layanan (SaaS) | "Saya tidak ingin tanggung jawab atau potensi tanggung jawab atas kunci penyewa dan rahasia pelanggan saya. Saya ingin pelanggan memiliki dan mengelola kunci mereka sehingga saya dapat fokus melakukan apa yang terbaik saya lakukan, yaitu menyediakan fitur perangkat lunak inti." |
√ Pelanggan dapat mengimpor kunci mereka sendiri ke Azure, dan mengelolanya. Ketika aplikasi SaaS perlu melakukan operasi kriptografi dengan menggunakan kunci pelanggan, Key Vault melakukan operasi ini atas nama aplikasi. Aplikasi tidak melihat kunci pelanggan. |
| Kepala pejabat keamanan (CSO) | "Saya ingin tahu bahwa aplikasi kami mematuhi FIPS 140 Level 3 HSM untuk manajemen kunci yang aman. Saya ingin memastikan bahwa organisasi saya mengendalikan siklus hidup kunci dan dapat memantau penggunaan kunci. Dan meskipun kami menggunakan beberapa layanan dan sumber daya Azure, saya ingin mengelola kunci dari satu lokasi di Azure." |
√ Pilih vault atau HSM terkelola untuk HSM yang divalidasi FIPS 140. √ Pilih kumpulan HSM terkelola untuk HSM yang divalidasi FIPS 140-2 Tingkat 3. √ Key Vault dirancang agar Microsoft tidak melihat atau mengekstrak kunci Anda. √ Penggunaan kunci dicatat hampir secara real-time. √ Vault menyediakan satu antarmuka, terlepas dari berapa banyak vault yang Anda miliki di Azure, wilayah mana yang mereka dukung, dan aplikasi mana yang menggunakannya. |
Siapa pun dengan langganan Azure dapat membuat dan menggunakan brankas kunci. Meskipun Key Vault menguntungkan pengembang dan admin keamanan, itu dapat diimplementasikan dan dikelola oleh admin organisasi yang mengelola layanan Azure lainnya. Misalnya, admin ini dapat masuk dengan langganan Azure, membuat vault untuk organisasi tempat menyimpan kunci, lalu bertanggung jawab atas tugas operasional seperti ini:
- Membuat atau mengimpor kunci atau rahasia
- Mencabut atau menghapus kunci atau rahasia
- Beri wewenang kepada pengguna atau aplikasi untuk mengakses brankas kunci, sehingga mereka dapat mengelola atau menggunakan kunci dan rahasianya
- Mengonfigurasi penggunaan kunci (misalnya, menandatangani atau mengenkripsi)
- Pantau penggunaan kunci
Administrator ini kemudian memberikan URI kepada pengembang untuk memanggil dari aplikasi mereka. Administrator ini juga memberikan informasi log penggunaan kunci kepada administrator keamanan.
Pengembang juga dapat mengelola kunci secara langsung, dengan menggunakan API. Untuk informasi selengkapnya, lihat panduan pengembang Key Vault.
Langkah berikutnya
- Pelajari tentang fitur keamanan Azure Key Vault.
- Pelajari cara mengamankan kumpulan HSM terkelola Anda
Azure Key Vault tersedia di sebagian besar wilayah. Untuk informasi selengkapnya, lihat halaman Harga Key Vault.