Kelola kunci API untuk beban kerja yang sensitif terhadap keamanan

AWS Secrets Manager membantu Anda mengelola, mengambil, dan memutar kredenSIAL database, kredenSIAL aplikasi, token OAuth, kunci API, dan rahasia lainnya sepanjang siklus hidupnya. Halaman ini memberikan panduan preskriptif untuk mengelola kunci API dan kredenSIAL pihak ketiga dalam beban kerja yang sensitif terhadap keamanan. Gabungkan rotasi otomatis dengan AWS KMS kunci yang dikelola pelanggan dan kebijakan IAM dengan hak istimewa terendah. Konfigurasikan juga akses titik akhir VPC untuk meminimalkan jendela eksposur dan radius ledakan dari kredensia yang dikompromikan.

Simpan kunci API di AWS Secrets Manager

Bagian ini menjelaskan cara menyusun rahasia kunci API Anda untuk rotasi dan pengambilan yang optimal. Simpan setiap kunci API sebagai rahasia terpisah dengan nilai JSON terstruktur. Dengan struktur ini, aplikasi Anda dapat mengambil bidang individual, dan Manajer Rahasia dapat meneruskan nilai yang benar ke fungsi rotasi.

Contoh berikut menunjukkan struktur JSON umum untuk rahasia kunci API pihak ketiga. Bidang aktual bergantung pada persyaratan penyedia Anda — tinjau dokumentasi penyedia untuk kredenSIAL dan metadata spesifik yang perlu Anda simpan.

{
  "apiKey": "your-api-key-value",
  "apiKeyId": "key-identifier",
  "endpoint": "https://api.example.com/v1",
  "provider": "example-service"
}

Contoh struktur rahasia untuk kunci API

Bidang	Nilai contoh	Tujuan
apiKey	sk_live_abc123...	Nilai kredensi yang digunakan aplikasi Anda untuk mengotentikasi dengan API pihak ketiga.
apiKeyId	key_001	Pengidentifikasi untuk kunci di sisi penyedia. Digunakan selama rotasi untuk membuat kunci baru dan menghapus yang lama.
endpoint	https://api.example.com/v1	URL titik akhir API. Simpan dengan kunci sehingga pengambilan mengembalikan semua yang dibutuhkan aplikasi untuk terhubung.
provider	stripe	Nama penyedia. Berguna untuk menandai, memfilter, dan logika fungsi rotasi yang menangani beberapa penyedia.

Tandai setiap rahasia dengan metadata untuk mendukung kondisi kebijakan IAM dan penyaringan organisasi. Misalnya, Anda dapat menandai rahasia dengan tim pemilik, lingkungan, dan cakupan kepatuhan menggunakan konsol AWS CLI or:

aws secretsmanager tag-resource \
    --secret-id prod/payments/stripe-api-key \
    --tags Key=Team,Value=payments Key=Environment,Value=production \
           Key=Provider,Value=stripe Key=Compliance,Value=pci-dss

Untuk informasi lebih lanjut tentang membuat rahasia, lihatBuat AWS Secrets Manager Rahasia.

Konfigurasi enkripsi

Secrets Manager mengenkripsi setiap nilai rahasia saat diam menggunakan AWS KMS kunci. Untuk beban kerja yang sensitif terhadap keamanan, pilih kunci enkripsi berdasarkan persyaratan kepatuhan dan kontrol akses Anda.

Opsi kunci KMS untuk rahasia kunci API

Tipe Kunci	Kapan harus digunakan	Pertimbangan keamanan
AWS kunci terkelola (aws/secretsmanager)	Default untuk sebagian besar beban kerja. Tidak ada biaya tambahan atau overhead manajemen kunci.	Kebijakan kunci dibatasi hanya untuk operasi Manajer Rahasia dan tidak dapat dimodifikasi. Tidak dapat digunakan untuk akses lintas akun.
Kunci yang dikelola pelanggan	Persyaratan kepatuhan (misalnya, PCI DSS, HIPAA, SOC 2, atau standar lain yang berlaku). Cross-account berbagi rahasia. Persyaratan audit penggunaan utama.	Anda mengontrol kebijakan utama. Anda dapat membatasi prinsipal mana yang dapat mendekripsi. Anda dapat menonaktifkan atau menjadwalkan penghapusan kunci secara independen dari rahasia. Menyediakan jejak audit independen melalui.

Untuk beban kerja yang sensitif terhadap keamanan, gunakan kunci yang dikelola pelanggan dengan kondisi kebijakan utama berikut:

• kms:ViaService— Batasi penggunaan kunci untuk permintaan yang berasal dari Secrets Manager (secretsmanager.<region>.amazonaws.com).

• kms:EncryptionContext:SecretARN— Batasi dekripsi ke ARN rahasia tertentu dengan mencocokkan konteks enkripsi Manajer Rahasia.

• Kunci terpisah per batas kepatuhan — Gunakan AWS KMS kunci yang berbeda untuk rahasia dalam lingkup kepatuhan yang berbeda (misalnya, PCI dibandingkan dengan non-PCI).

Untuk penjelasan lengkap tentang proses enkripsi dan dekripsi, lihatEnkripsi rahasia dan dekripsi di AWS Secrets Manager.

Rotasi otomatis untuk kunci API

Rotasi otomatis mengurangi jendela eksposur kredenSIAL yang dikompromikan. Secrets Manager memanggil fungsi Lambda pada jadwal. Fungsi ini membuat kunci API baru di penyedia, memperbarui nilai rahasia, dan menghapus kunci lama.

Secrets Manager menyediakan fungsi rotasi terkelola untuk beberapa penyedia pihak ketiga melalui rahasia eksternal yang dikelola. Untuk informasi selengkapnya tentang fitur ini dan daftar penyedia yang didukung, lihatRahasia eksternal yang dikelola Mitra. Untuk penyedia tanpa dukungan rotasi terkelola, Anda menerapkan fungsi rotasi Lambda khusus yang memanggil API penyedia untuk membuat dan menghapus kunci.

Siklus hidup fungsi rotasi

Fungsi rotasi Lambda mengimplementasikan empat langkah. Secrets Manager memanggil fungsi sekali untuk setiap langkah, melewati parameter. Step Jika ada langkah yang gagal, Manajer Rahasia secara otomatis mencoba ulang seluruh rotasi.

Langkah-langkah rotasi untuk kunci API

Langkah	Tindakan untuk kunci API	Penanganan kegagalan
createSecret	Panggil API penyedia untuk membuat kunci baru. Simpan nilai kunci baru di Secrets Manager dengan label p AWSPENDING ementasan.	Jika pembuatan kunci gagal, rotasi tidak beralih ke langkah berikutnya. Kunci yang ada tetap aktif sebagaiAWSCURRENT.
setSecret	Untuk kunci API yang dibuat di penyedia, langkah ini biasanya tidak dilakukan. Langkah ini digunakan ketika kunci acak dihasilkan di Secrets Manager dan perlu diatur di penyedia — yang bukan aliran kunci API yang khas.	Jika langkah ini gagal, rotasi tidak dilanjutkan ketestSecret.
testSecret	Ambil AWSPENDING nilai dari Secrets Manager dan buat panggilan API uji ke penyedia untuk memverifikasi kunci baru berfungsi.	Jika pengujian gagal, hapus kunci tertunda di penyedia dan angkat pengecualian.
finishSecret	P AWSCURRENT indah ke kunci baru. Kunci lama bergerak keAWSPREVIOUS. Secara opsional menghapus kunci lama di penyedia.	Jika pembaruan label gagal, rotasi tidak selesai. Kunci baru ada tetapi belum diberi labelAWSCURRENT.

Untuk template fungsi rotasi lengkap dan panduan implementasi, lihatFungsi rotasi lambda.

Konfigurasi jadwal rotasi

Tetapkan interval rotasi berdasarkan persyaratan kepatuhan dan kebijakan keamanan internal Anda. Lihat standar kepatuhan yang berlaku untuk beban kerja Anda untuk menentukan frekuensi rotasi yang sesuai.

Gunakan jendela rotasi untuk mengontrol kapan rotasi terjadi. Ini mencegah rotasi berjalan selama puncak lalu lintas atau jendela pemeliharaan:

aws secretsmanager rotate-secret \
    --secret-id prod/payments/stripe-api-key \
    --rotation-rules '{
        "ScheduleExpression": "cron(0 4 ? * SUN *)",
        "Duration": "2h"
    }'

Untuk sintaks ekspresi jadwal, lihatJadwal rotasi.

Mengambil rahasia secara efisien

Secrets Manager mendukung 10.000 transaksi per detik pada GetSecretValue panggilan. Sebagian besar aplikasi tidak mengalami pelambatan. Untuk aplikasi dengan volume panggilan yang sangat tinggi atau jalur sensitif latensi, gunakan solusi caching untuk mengurangi panggilan API dan meningkatkan waktu respons.

Secrets Manager menyediakan klien caching untuk beberapa bahasa, serta ekstensi Lambda yang menyimpan rahasia secara lokal dalam lingkungan eksekusi. Untuk informasi selengkapnya tentang opsi caching, lihatDapatkan nilai rahasia Secrets Manager menggunakan Java dengan caching sisi klien,Dapatkan nilai rahasia Secrets Manager menggunakan Python dengan caching sisi klien, danDapatkan nilai rahasia Secrets Manager menggunakan Go dengan caching sisi klien.

Untuk semua pola akses, konfigurasikan kebijakan IAM yang secretsmanager:GetSecretValue membatasi rahasia spesifik yang dibutuhkan setiap aplikasi:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/payments/*",
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/Environment": "production"
      }
    }
  }]
}

Pengerasan keamanan untuk beban kerja sensitif

Praktik berikut memberikan pertahanan mendalam untuk kunci API di lingkungan dengan persyaratan keamanan yang ketat (misalnya, PCI DSS, SOC 2, HIPAA, atau kerangka kerja kepatuhan lain yang berlaku):

Batasi akses jaringan dengan titik akhir VPC

Buat titik akhir VPC antarmuka untuk Manajer Rahasia sehingga pengambilan rahasia tidak pernah melintasi internet publik. Terapkan kebijakan titik akhir yang membatasi rahasia mana yang dapat diakses melalui titik akhir. Untuk informasi selengkapnya, lihat Menggunakan titik akhir AWS Secrets Manager VPC.

Menerapkan kebijakan sumber daya ke rahasia

Lampirkan kebijakan sumber daya ke setiap rahasia yang secara eksplisit menolak akses dari kepala sekolah di luar akun Anda atau di luar titik akhir VPC tertentu. Ini memberikan batas otorisasi kedua yang independen dari kebijakan identitas IAM.

Memantau akses rahasia dengan

secara otomatis mencatat semua panggilan API Secrets Manager, termasukGetSecretValue,PutSecretValue, danRotateSecret. Untuk rahasia yang sensitif terhadap keamanan, buat CloudWatch alarm Amazon yang memicu GetSecretValue panggilan tak terduga — misalnya, panggilan dari alamat IP sumber yang tidak dikenal atau prinsipal IAM.

Gunakan AWSPREVIOUS untuk rotasi anggun

Selama rotasi, Secrets Manager mempertahankan nilai kunci sebelumnya dengan label p AWSPREVIOUS ementasan. Jika penyedia Anda membatalkan kunci sebelumnya saat kunci baru dibuat, konfigurasikan aplikasi Anda untuk kembali ke AWSPREVIOUS jika AWSCURRENT mengembalikan kesalahan otentikasi. Ini mencegah downtime selama jendela singkat antara pembuatan kunci dan pembaruan label.

Validasi kebijakan sumber daya sebelum melampirkan

Rahasia tanpa kebijakan sumber daya sudah memblokir akses publik. Saat Anda melampirkan kebijakan sumber daya ke rahasia Anda, gunakan ValidateResourcePolicy API untuk memastikan kebijakan Anda tidak memberikan akses publik yang luas. Anda juga dapat menggunakan BlockPublicPolicy parameter with PutResourcePolicy untuk mencegah melampirkan kebijakan yang memberikan akses publik. Gunakan kunci aws:PrincipalOrgID kondisi dalam kebijakan sumber daya untuk mencegah akses dari kepala sekolah di luar organisasi Anda.

Pertanyaan umum

Bagian ini menjawab pertanyaan umum tentang rotasi kunci API dan manajemen rahasia di AWS Secrets Manager.

Bagaimana cara menangani periode tumpang tindih selama rotasi?

Ini hanya diperlukan jika penyedia membatalkan kunci yang ada saat kunci baru dibuat. Jika penyedia mendukung beberapa kunci aktif secara bersamaan, kedua kunci bekerja selama periode rotasi tanpa logika fallback sisi aplikasi. Untuk penyedia yang membatalkan kunci lama, konfigurasikan aplikasi Anda untuk mencoba lagi AWSPREVIOUS jika kunci saat ini mengembalikan kesalahan 401 atau 403. Hapus kunci lama di penyedia pada finishSecret langkah hanya setelah Anda mengonfirmasi kunci baru berfungsi.

Bagaimana jika penyedia saya tidak mendukung pembuatan kunci terprogram?

Jika penyedia memerlukan pembuatan kunci manual (melalui konsol web, misalnya), Anda tidak dapat sepenuhnya mengotomatiskan rotasi. Sebagai gantinya, gunakan fungsi rotasi yang mengirimkan pemberitahuan (melalui Amazon Simple Notification Service) saat rotasi jatuh tempo, meminta operator untuk membuat kunci secara manual dan memperbarui nilai rahasia. Tetapkan jadwal rotasi agar sesuai dengan persyaratan rotasi kepatuhan Anda dan gunakan CloudWatch alarm Amazon aktif days_since_last_rotation untuk mendeteksi rotasi yang terlewat.

Bagaimana cara menghindari pelambatan API saat mengambil rahasia?

Secrets Manager mendukung 10.000 transaksi per detikGetSecretValue. Sebagian besar aplikasi tidak mengalami pelambatan. Jika aplikasi Anda membuat volume panggilan yang sangat tinggi, gunakan klien caching atau ekstensi Parameter dan Rahasia Lambda. Ini menyimpan nilai rahasia dalam memori dan menyegarkan secara berkala, mengurangi jumlah panggilan API. Atur cache TTL ke nilai yang lebih pendek dari interval rotasi Anda sehingga aplikasi mengambil kunci baru setelah rotasi.

Haruskah saya menggunakan satu rahasia per lingkungan atau satu rahasia dengan versi?

Gunakan rahasia terpisah untuk setiap lingkungan (misalnya, prod/payments/stripe dandev/payments/stripe). Hal ini memungkinkan kebijakan IAM yang berbeda, jadwal rotasi, dan kunci enkripsi per lingkungan. Versi rahasia (label pementasan) adalah untuk manajemen status rotasi, bukan pemisahan lingkungan.