Key Management Service (KMS) menggunakan application access points (AAP) untuk mengontrol cara aplikasi yang dikelola sendiri melakukan autentikasi serta mengakses kunci dan rahasia dalam instans KMS. Sebelum aplikasi dapat menggunakan kunci atau rahasia, aplikasi tersebut harus melakukan autentikasi melalui AAP.
AAP terdiri dari dua komponen: kebijakan izin dan kredensial.
Buat AAP terpisah untuk setiap aplikasi yang mengakses KMS. Dengan demikian, setiap aplikasi memiliki izin aksesnya sendiri dan dapat diaudit secara independen.
Cara kerja
Setiap AAP menerapkan dua lapis kontrol:
Kebijakan izin — menentukan kunci dan rahasia mana yang dapat diakses oleh aplikasi, serta dari alamat IP mana akses tersebut diizinkan
Kredensial — mengotentikasi identitas aplikasi sebelum memberikan akses
Kebijakan izin
Kebijakan izin menentukan resource KMS mana yang dapat diakses oleh aplikasi dan dalam kondisi apa. Setiap AAP mendukung hingga tiga kebijakan izin.
Setiap kebijakan mencakup hal-hal berikut:
Izin RBAC — operasi yang boleh dilakukan oleh aplikasi
Resource yang dapat diakses — kunci atau rahasia yang dapat diakses oleh aplikasi
Aturan akses jaringan — alamat IP sumber dari mana akses diizinkan
Izin RBAC
| Role | Cakupan | Operasi yang didukung |
|---|---|---|
| CryptoServiceKeyUser | Kunci dalam instans KMS | Operasi kriptografi melalui Instance API. Lihat Daftar operasi berdasarkan fungsi. |
| CryptoServiceSecretUser | Rahasia dalam instans KMS | Operasi terkait rahasia melalui Instance API. Lihat Daftar operasi berdasarkan fungsi. |
| SecretUser | Semua rahasia dalam Akun Alibaba Cloud saat ini | GetSecretValue melalui OpenAPI |
Kredensial
Kredensial membuktikan identitas aplikasi yang mengakses KMS. Dua jenis kredensial didukung: client key dan RAM role.
Pilih jenis kredensial
| Skenario | Jenis kredensial |
|---|---|
| Aplikasi memerlukan autentikasi identitas dan perilaku untuk menggunakan kunci atau rahasia dalam instans KMS | Client key |
| Aplikasi berjalan di Elastic Compute Service (ECS), Container Service for Kubernetes (ACK), atau Function Compute, dan dikaitkan dengan RAM role dari Resource Access Management (RAM) | RAM role |
Client key
Client key menandatangani permintaan dari aplikasi ke KMS dan memverifikasi tanda tangan tersebut. Client key terdiri dari dua bagian:
Application Access Secret (ClientKeyContent)
Password
Batas siklus hidup:
| Properti | Nilai |
|---|---|
| Periode validitas default | Lima tahun (disarankan satu tahun) |
| Maksimum client key per AAP | Tiga |
| Penyimpanan | KMS tidak menyimpan client key. Jika Anda kehilangan client key, hapus dan buat yang baru. |
| Tanggapan kompromi | Segera hapus kunci yang dikompromikan dan buat penggantinya. |
Untuk merotasi client key sebelum masa berlakunya habis, lihat Ubah client key. Setelah beralih ke kunci baru, hapus kunci lama dari KMS.
RAM role
Gunakan RAM role ketika aplikasi Anda berjalan di Elastic Compute Service (ECS), Container Service for Kubernetes (ACK), atau Function Compute, sudah dikaitkan dengan RAM role, dan Anda perlu mengambil nilai rahasia menggunakan titik akhir KMS. KMS mengotentikasi permintaan OpenAPI menggunakan RAM — tidak diperlukan client key.
SDK yang mendukung autentikasi client key
SDK KMS yang berbeda mendukung metode autentikasi yang berbeda. Untuk ikhtisar lengkap, lihat Referensi SDK.
SDK berikut mendukung autentikasi client key:
| SDK | Cakupan akses | Jenis titik akhir |
|---|---|---|
| KMS Instance SDK | Kunci dan rahasia dalam instans KMS | Titik akhir instans KMS (memerlukan client key) |
| Secret SDK | Rahasia dalam instans KMS, atau rahasia di seluruh Akun Alibaba Cloud saat ini | Titik akhir instans KMS atau titik akhir KMS |
Saat menggunakan Secret SDK dengan titik akhir KMS, Anda dapat melakukan autentikasi dengan client key, Pasangan Kunci Akses (AccessKey pair) dari RAM user, atau RAM role. Jenis titik akhir bergantung pada cara Anda mengonfigurasi cakupan kebijakan izin: atur ke instans KMS untuk menggunakan titik akhir instans KMS, atau atur ke Shared KMS Gateway untuk menggunakan titik akhir KMS.
Notifikasi kedaluwarsa client key
Alibaba Cloud mengirimkan notifikasi kedaluwarsa melalui email atau pesan internal pada interval berikut sebelum client key kedaluwarsa: enam bulan, tiga bulan, satu bulan, dan tujuh hari.
Untuk mengatur peringatan proaktif, konfigurasikan CloudMonitor agar mengirimkan notifikasi 180 hari, 90 hari, 30 hari, dan 7 hari sebelum kedaluwarsa. Lihat Event peringatan.
Log dan audit
Peristiwa manajemen
KMS terintegrasi dengan ActionTrail untuk mencatat peristiwa manajemen AAP. Lihat Audit event KMS dan Gunakan ActionTrail untuk mengkueri event KMS.
Log panggilan client key
KMS terintegrasi dengan Simple Log Service (SLS) untuk mencatat panggilan yang dilakukan menggunakan client key. Log disimpan selama 180 hari dan dapat dicari di halaman Simple Log Service for KMS. Untuk memeriksa apakah client key tertentu telah digunakan, masukkan ID-nya ke dalam kotak pencarian di bawah kms_audit_log. Jika bidang access_key_id dalam hasil pencarian cocok dengan ID client key, berarti kunci tersebut telah dipanggil.
Langkah selanjutnya
Akses instans KMS menggunakan AAP — buat AAP dan integrasikan dengan aplikasi Anda
Referensi SDK — pilih dan integrasikan SDK
Deskripsi titik akhir — pahami perbedaan antara titik akhir instans KMS dan titik akhir KMS
Kuota performa — batas QPS (permintaan per detik)