Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# AWS Secrets Manager praktik terbaik
Secrets Manager menyediakan sejumlah fitur keamanan untuk dipertimbangkan saat Anda mengembangkan dan menerapkan kebijakan keamanan Anda sendiri. Praktik terbaik berikut adalah pedoman umum dan tidak mewakili solusi keamanan yang lengkap. Karena praktik terbaik ini mungkin tidak sesuai atau cukup untuk lingkungan Anda, anggap sebagai pertimbangan yang membantu dan bukan sebagai resep.
**Topics**
+ [Menyimpan kredensi dan informasi sensitif lainnya di AWS Secrets Manager](#best-practices-store-secrets-safely)
+ [Temukan rahasia yang tidak dilindungi dalam kode Anda](#w2aab9b9)
+ [Pilih kunci enkripsi untuk rahasia Anda](#w2aab9c11)
+ [Gunakan caching untuk mengambil rahasia](#w2aab9c13)
+ [Putar rahasia Anda](#w2aab9c15)
+ [Mengurangi risiko menggunakan CLI](#w2aab9c17)
+ [Batasi akses ke rahasia](#w2aab9c19)
+ [Replikasi rahasia](#w2aab9c21)
+ [Memantau rahasia](#w2aab9c23)
+ [Jalankan infrastruktur Anda di jaringan pribadi](#w2aab9c25)
## Menyimpan kredensi dan informasi sensitif lainnya di AWS Secrets Manager
Secrets Manager dapat membantu meningkatkan postur keamanan dan kepatuhan Anda, serta mengurangi risiko akses tidak sah ke informasi sensitif Anda. Secrets Manager mengenkripsi rahasia saat istirahat menggunakan kunci enkripsi yang Anda miliki dan simpan di AWS Key Management Service ()AWS KMS. Saat Anda mengambil rahasia, Secrets Manager mendekripsi rahasia dan mengirimkannya dengan aman melalui TLS ke lingkungan lokal Anda. Untuk informasi selengkapnya, lihat [Buat AWS Secrets Manager rahasia](create_secret.md).
## Temukan rahasia yang tidak dilindungi dalam kode Anda
CodeGuru Reviewer terintegrasi dengan Secrets Manager untuk menggunakan detektor rahasia yang menemukan rahasia yang tidak dilindungi dalam kode Anda. Detektor rahasia mencari kata sandi hardcode, string koneksi database, nama pengguna, dan banyak lagi. Untuk informasi selengkapnya, lihat [Temukan rahasia yang tidak dilindungi dalam kode Anda dengan Amazon Reviewer CodeGuru](integrating-codeguru.md).
Amazon Q dapat memindai basis kode Anda untuk mencari kerentanan keamanan dan masalah kualitas kode untuk meningkatkan postur aplikasi Anda selama siklus pengembangan. Untuk informasi selengkapnya, lihat [Memindai kode Anda dengan Amazon Q](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/security-scans.html) di *Panduan Pengguna Pengembang Amazon Q*.
## Pilih kunci enkripsi untuk rahasia Anda
Untuk kebanyakan kasus, kami sarankan menggunakan kunci `aws/secretsmanager` AWS terkelola untuk mengenkripsi rahasia. Tidak ada biaya untuk menggunakannya.
Untuk dapat mengakses rahasia dari akun lain atau menerapkan kebijakan kunci ke kunci enkripsi, gunakan kunci yang dikelola pelanggan untuk mengenkripsi rahasia.
+ Dalam kebijakan kunci, tetapkan nilai `secretsmanager..amazonaws.com` ke kunci [https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service)kondisi. Ini membatasi penggunaan kunci hanya untuk permintaan dari Secrets Manager.
+ Untuk lebih membatasi penggunaan kunci hanya permintaan dari Secrets Manager dengan konteks yang benar, gunakan kunci atau nilai dalam [konteks enkripsi Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html#security-encryption-encryption-context) sebagai syarat untuk menggunakan kunci KMS dengan membuat:
+ [Operator kondisi string](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String) dalam kebijakan IAM atau kebijakan kunci
+ [Kendala hibah](https://docs.aws.amazon.com/kms/latest/APIReference/API_GrantConstraints.html) dalam hibah
Untuk informasi selengkapnya, lihat [Enkripsi rahasia dan dekripsi di AWS Secrets Manager](security-encryption.md).
## Gunakan caching untuk mengambil rahasia
Untuk menggunakan rahasia Anda dengan paling efisien, kami sarankan Anda menggunakan salah satu komponen caching Secrets Manager yang didukung berikut ini untuk menyimpan rahasia Anda dan memperbaruinya hanya jika diperlukan:
+ [Java dengan caching sisi klien](retrieving-secrets_cache-java.md)
+ [Python dengan caching sisi klien](retrieving-secrets_cache-python.md)
+ [.NET dengan caching sisi klien](retrieving-secrets_cache-net.md)
+ [Pergi dengan caching sisi klien](retrieving-secrets_cache-go.md)
+ [Karat dengan caching sisi klien](retrieving-secrets_cache-rust.md)
+ [AWS Parameter dan Rahasia Ekstensi Lambda](retrieving-secrets_lambda.md)
+ [Gunakan AWS Secrets Manager rahasia di Amazon Elastic Kubernetes Service](integrate_eks.md)
+ Gunakan [Menggunakan AWS Secrets Manager Agen](secrets-manager-agent.md) untuk membakukan konsumsi rahasia dari Secrets Manager di seluruh lingkungan seperti AWS Lambda Amazon Elastic Container Service, Amazon Elastic Kubernetes Service, dan Amazon Elastic Compute Cloud.
## Putar rahasia Anda
Jika Anda tidak mengubah rahasia Anda untuk jangka waktu yang lama, rahasia menjadi lebih mungkin untuk dikompromikan. Dengan Secrets Manager, Anda dapat mengatur rotasi otomatis sesering setiap empat jam. Secrets Manager menawarkan dua strategi untuk rotasi: [Pengguna tunggal](rotation-strategy.md#rotating-secrets-one-user-one-password) dan[Pengguna bergantian](rotation-strategy.md#rotating-secrets-two-users). Untuk informasi selengkapnya, lihat [Putar AWS Secrets Manager rahasia](rotating-secrets.md).
## Mengurangi risiko menggunakan CLI
Saat Anda menggunakan AWS operasi AWS CLI untuk memanggil, Anda memasukkan perintah tersebut di shell perintah. Sebagian besar shell perintah menawarkan fitur yang dapat membahayakan rahasia Anda, seperti logging dan kemampuan untuk melihat perintah yang terakhir dimasukkan. Sebelum Anda menggunakan AWS CLI untuk memasukkan informasi sensitif, pastikan untuk[Mengurangi risiko menggunakan AWS CLI untuk menyimpan rahasia Anda AWS Secrets Manager](security_cli-exposure-risks.md).
## Batasi akses ke rahasia
Dalam pernyataan kebijakan IAM yang mengontrol akses ke rahasia Anda, gunakan prinsip akses yang [paling tidak memiliki hak istimewa](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege). Anda dapat menggunakan [peran dan kebijakan IAM, kebijakan](auth-and-access_iam-policies.md) [sumber daya](auth-and-access_resource-policies.md), dan [kontrol akses berbasis atribut (](auth-and-access-abac.md)ABAC). Untuk informasi selengkapnya, lihat [Otentikasi dan kontrol akses untuk AWS Secrets Manager](auth-and-access.md).
**Topics**
+ [Blokir akses luas ke rahasia](#iam-contextkeys-blockpublicpolicy)
+ [Berhati-hatilah dengan kondisi alamat IP dalam kebijakan](#iam-contextkeys-ipaddress)
+ [Batasi permintaan dengan kondisi titik akhir VPC](#iam-contextkeys-vpcendpoint)
### Blokir akses luas ke rahasia
Dalam kebijakan identitas yang memungkinkan tindakan`PutResourcePolicy`, kami sarankan Anda menggunakannya`BlockPublicPolicy: true`. Kondisi ini berarti bahwa pengguna hanya dapat melampirkan kebijakan sumber daya ke rahasia jika kebijakan tidak mengizinkan akses luas.
Secrets Manager menggunakan penalaran otomatis Zelkova untuk menganalisis kebijakan sumber daya untuk akses luas. Untuk informasi selengkapnya tentang Zelkova, lihat [Cara AWS menggunakan penalaran otomatis untuk membantu Anda mencapai keamanan dalam skala besar di Blog Keamanan](https://aws.amazon.com/blogs/security/protect-sensitive-data-in-the-cloud-with-automated-reasoning-zelkova/). AWS
Contoh berikut menunjukkan cara menggunakan`BlockPublicPolicy`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "secretsmanager:PutResourcePolicy",
"Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:secretName-AbCdEf",
"Condition": {
"Bool": {
"secretsmanager:BlockPublicPolicy": "true"
}
}
}
}
```
------
### Berhati-hatilah dengan kondisi alamat IP dalam kebijakan
Berhati-hatilah saat Anda menentukan [operator kondisi alamat IP](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_IPAddress) atau kunci `aws:SourceIp` kondisi dalam pernyataan kebijakan yang mengizinkan atau menolak akses ke Secrets Manager. Misalnya, jika Anda melampirkan kebijakan yang membatasi AWS tindakan untuk permintaan dari rentang alamat IP jaringan perusahaan Anda ke rahasia, maka permintaan Anda sebagai pengguna IAM yang menjalankan permintaan dari jaringan perusahaan berfungsi seperti yang diharapkan. Namun, jika Anda mengaktifkan layanan lain untuk mengakses rahasia atas nama Anda, seperti saat Anda mengaktifkan rotasi dengan fungsi Lambda, fungsi tersebut akan memanggil operasi Secrets Manager dari ruang alamat AWS-internal. Permintaan yang terkena dampak kebijakan dengan filter alamat IP gagal.
Selain itu, kunci `aws:sourceIP` kondisi kurang efektif ketika permintaan berasal dari titik akhir VPC Amazon. Untuk membatasi permintaan ke titik akhir VPC tertentu, gunakan. [Batasi permintaan dengan kondisi titik akhir VPC](#iam-contextkeys-vpcendpoint)
### Batasi permintaan dengan kondisi titik akhir VPC
Untuk mengizinkan atau menolak akses ke permintaan dari titik akhir VPC atau VPC tertentu, gunakan `aws:SourceVpc` untuk membatasi akses ke permintaan dari VPC yang ditentukan atau `aws:SourceVpce` untuk membatasi akses ke permintaan dari titik akhir VPC yang ditentukan. Lihat [Contoh: Izin dan VPCs](auth-and-access_resource-policies.md#auth-and-access_examples_vpc).
+ `aws:SourceVpc` membatasi akses ke permintaan dari VPC yang ditentukan.
+ `aws:SourceVpce` membatasi akses ke permintaan dari VPC endpoint yang ditentukan.
Jika Anda menggunakan kunci kondisi ini dalam pernyataan kebijakan sumber daya yang mengizinkan atau menolak akses ke rahasia Secrets Manager, Anda dapat secara tidak sengaja menolak akses ke layanan yang menggunakan Secrets Manager untuk mengakses rahasia atas nama Anda. Hanya beberapa AWS layanan yang dapat berjalan dengan titik akhir dalam VPC Anda. Jika Anda membatasi permintaan rahasia ke titik akhir VPC atau VPC, maka panggilan ke Secrets Manager dari layanan yang tidak dikonfigurasi untuk layanan dapat gagal.
Lihat [Menggunakan titik akhir AWS Secrets Manager VPC](vpc-endpoint-overview.md).
## Replikasi rahasia
Secrets Manager dapat secara otomatis mereplikasi rahasia Anda ke beberapa AWS Wilayah untuk memenuhi persyaratan ketahanan atau pemulihan bencana Anda. Untuk informasi selengkapnya, lihat [Replikasi AWS Secrets Manager rahasia di seluruh Wilayah](replicate-secrets.md).
## Memantau rahasia
Secrets Manager memungkinkan Anda untuk mengaudit dan memantau rahasia melalui integrasi dengan layanan AWS pencatatan, pemantauan, dan pemberitahuan. Untuk informasi lebih lanjut, lihat:
+ [Log AWS Secrets Manager peristiwa dengan AWS CloudTrail](monitoring-cloudtrail.md)
+ [Monitor AWS Secrets Manager dengan Amazon CloudWatch](monitoring-cloudwatch.md)
+ [Memantau AWS Secrets Manager rahasia untuk kepatuhan dengan menggunakan AWS Config](configuring-awsconfig-rules.md)
+ [Biaya Monitor Secrets Manager](monitor-secretsmanager-costs.md)
+ [Mendeteksi ancaman dengan Amazon GuardDuty](monitoring-guardduty.md)
## Jalankan infrastruktur Anda di jaringan pribadi
Kami menyarankan Anda menjalankan infrastruktur sebanyak mungkin di jaringan pribadi yang tidak dapat diakses dari internet publik. Anda dapat membuat koneksi pribadi antara VPC dan Secrets Manager dengan membuat antarmuka *VPC* endpoint. Lihat informasi yang lebih lengkap di [Menggunakan titik akhir AWS Secrets Manager VPC](vpc-endpoint-overview.md).