Konsep AWS Secrets Manager

Rahasia

Dalam Secrets Manager, rahasia terdiri dari informasi rahasia, nilai rahasia, ditambah metadata tentang rahasia. Nilai rahasia dapat berupa string atau biner. Untuk menyimpan beberapa nilai string dalam satu rahasia, kami sarankan Anda menggunakan string teks JSON dengan pasangan kunci/nilai, misalnya:

{
  "host"       : "ProdServer-01.databases.example.com",
  "port"       : "8888",
  "username"   : "administrator",
  "password"   : "EXAMPLE-PASSWORD",
  "dbname"     : "MyDatabase",
  "engine"     : "mysql"
}

Metadata rahasia meliputi:

• Nama Sumber Daya Amazon (ARN) dengan format berikut:

  arn:aws:secretsmanager:<Region>:<AccountId>:secret:SecretName-6RandomCharacters

  Secrets Manager mencakup enam karakter acak di akhir nama rahasia untuk membantu memastikan bahwa ARN rahasia itu unik. Jika rahasia asli dihapus, dan kemudian rahasia baru dibuat dengan nama yang sama, kedua rahasia memiliki ARN yang berbeda karena karakter ini. Pengguna dengan akses ke rahasia lama tidak secara otomatis mendapatkan akses ke rahasia baru karena ARN berbeda.

• Nama rahasia, deskripsi, kebijakan sumber daya, dan tag.

• ARN untuk kunci enkripsi, yang digunakan Secrets Manager untuk mengenkripsi dan mendekripsi nilai rahasia. AWS KMS key Secrets Manager menyimpan teks rahasia dalam bentuk terenkripsi dan mengenkripsi rahasia dalam perjalanan. Lihat Enkripsi rahasia dan dekripsi di AWS Secrets Manager.

• Informasi tentang cara memutar rahasia, jika Anda mengatur rotasi. Lihat Rotasi.

Secrets Manager menggunakan kebijakan izin IAM untuk memastikan bahwa hanya pengguna yang berwenang yang dapat mengakses atau memodifikasi rahasia. Lihat Kontrol autentikasi dan akses untuk AWS Secrets Manager.

Sebuah rahasia memiliki versi yang menyimpan salinan dari nilai rahasia terenkripsi. Ketika Anda mengubah nilai rahasia, atau rahasia diputar, Secrets Manager membuat versi baru. Lihat Versi.

Anda dapat menggunakan rahasia di beberapa Wilayah AWS dengan mereplikasi itu. Ketika Anda mereplikasi rahasia, Anda membuat salinan rahasia asli atau primer yang disebut rahasia replika. Rahasia replika tetap terkait dengan rahasia utama. Lihat Replikasi AWS Secrets Manager rahasia ke yang lain Wilayah AWS.

Lihat Buat dan kelola rahasia dengan AWS Secrets Manager.

Versi

Sebuah rahasia memiliki versi yang menyimpan salinan dari nilai rahasia terenkripsi. Ketika Anda mengubah nilai rahasia, atau rahasia diputar, Secrets Manager membuat versi baru.

Secrets Manager tidak menyimpan riwayat rahasia linier dengan versi. Sebagai gantinya, ia melacak tiga versi tertentu dengan memberi label:

• Versi saat ini - AWSCURRENT

• Versi sebelumnya - AWSPREVIOUS

• Versi yang tertunda (selama rotasi) - AWSPENDING

Rahasia selalu memiliki versi berlabelAWSCURRENT, dan Secrets Manager mengembalikan versi tersebut secara default saat Anda mengambil nilai rahasia.

Anda juga dapat memberi label versi dengan label Anda sendiri update-secret-version-stagedengan memanggilAWS CLI. Anda dapat melampirkan hingga 20 label ke versi secara rahasia. Dua versi rahasia tidak dapat memiliki label pementasan yang sama. Versi dapat memiliki beberapa label.

Secrets Manager tidak pernah menghapus versi berlabel, tetapi versi yang tidak berlabel dianggap usang. Secrets Manager menghapus versi usang ketika ada lebih dari 100. Secrets Manager tidak menghapus versi yang dibuat kurang dari 24 jam yang lalu.

Gambar berikut menunjukkan rahasia yang memiliki versi AWS berlabel dan versi berlabel pelanggan. Versi tanpa label dianggap usang dan akan dihapus oleh Secrets Manager di beberapa titik di masa mendatang.

Rotasi

Rotasi adalah proses memperbarui rahasia secara berkala untuk membuatnya lebih sulit bagi penyerang untuk mengakses kredensialnya. Di Secrets Manager, Anda dapat mengatur rotasi otomatis untuk rahasia Anda. Ketika Secrets Manager memutar rahasia, ia memperbarui kredensialnya baik dalam rahasia maupun database atau layanan. Lihat Putar AWS Secrets Manager rahasia.

Tip

Untuk beberapaRahasia yang dikelola oleh layanan lain, Anda menggunakan rotasi terkelola. Untuk menggunakanRotasi terkelola, Anda pertama kali membuat rahasia melalui layanan pengelolaan.

Strategi rotasi

Secrets Manager menawarkan dua strategi rotasi:

• Pengguna tunggal
• Pengguna bergantian

Strategi rotasi: pengguna tunggal

Strategi ini memperbarui kredensil untuk satu pengguna dalam satu rahasia. Untuk instans Amazon RDS Db2, karena pengguna tidak dapat mengubah kata sandi mereka sendiri, Anda harus memberikan kredensi admin dalam rahasia terpisah. Ini adalah strategi rotasi paling sederhana, dan cocok untuk sebagian besar kasus penggunaan. Secara khusus, kami menyarankan Anda menggunakan strategi ini untuk kredensil untuk satu kali (ad hoc) atau pengguna interaktif.

Ketika rahasia berputar, koneksi database terbuka tidak terputus. Sementara rotasi sedang terjadi, ada periode waktu singkat antara ketika kata sandi dalam database berubah dan ketika rahasia diperbarui. Selama waktu ini, ada risiko rendah database menolak panggilan yang menggunakan kredenal yang diputar. Anda dapat mengurangi risiko ini dengan strategi coba lagi yang tepat. Setelah rotasi, koneksi baru menggunakan kredensil baru.

Strategi rotasi: pengguna bergantian

Strategi ini memperbarui kredensil untuk dua pengguna dalam satu rahasia. Anda membuat pengguna pertama, dan selama rotasi pertama, fungsi rotasi mengkloningnya untuk membuat pengguna kedua. Setiap kali rahasia berputar, fungsi rotasi mengganti kata sandi pengguna mana yang diperbarui. Karena sebagian besar pengguna tidak memiliki izin untuk mengkloning diri mereka sendiri, Anda harus memberikan kredensialnya untuk rahasia lain. superuser Sebaiknya gunakan strategi rotasi pengguna tunggal ketika pengguna kloning di database Anda tidak memiliki izin yang sama dengan pengguna asli, dan untuk kredensi untuk pengguna satu kali (ad hoc) atau interaktif.

Strategi ini sesuai untuk database dengan model izin di mana satu peran memiliki tabel database dan peran kedua memiliki izin untuk mengakses tabel database. Ini juga sesuai untuk aplikasi yang membutuhkan ketersediaan tinggi. Jika aplikasi mengambil rahasia selama rotasi, aplikasi masih mendapatkan set kredensil yang valid. Setelah rotasi, keduanya user dan user_clone kredensialnya valid. Bahkan ada lebih sedikit kemungkinan aplikasi mendapatkan penolakan selama jenis rotasi ini daripada rotasi pengguna tunggal. Jika database di-host di server farm di mana perubahan kata sandi membutuhkan waktu untuk menyebar ke semua server, ada risiko database menolak panggilan yang menggunakan kredensi baru. Anda dapat mengurangi risiko ini dengan strategi coba lagi yang tepat.

Secrets Manager membuat pengguna kloning dengan izin yang sama dengan pengguna asli. Jika Anda mengubah izin pengguna asli setelah klon dibuat, Anda juga harus mengubah izin pengguna kloning.

Misalnya, jika Anda membuat rahasia dengan kredensi pengguna database, rahasia berisi satu versi dengan kredensialnya.

Rotasi pertama - Fungsi rotasi membuat tiruan pengguna Anda dengan kata sandi yang dihasilkan, dan kredensi tersebut menjadi versi rahasia saat ini.

Rotasi kedua - Fungsi rotasi memperbarui kata sandi untuk pengguna asli.

Rotasi ketiga - Fungsi rotasi memperbarui kata sandi untuk pengguna kloning.