Bedrock — perlindungan data
AWS mengamankan infrastrukturnya; kamu mengamankan isinya dan konfigurasimu. Halaman ini merangkum bagian yang jadi tanggung jawabmu di Bedrock.
Intisari
- Shared responsibility model: AWS menjaga infrastruktur global, kamu menjaga konten dan konfigurasi.
- TLS 1.2 diwajibkan untuk berkomunikasi dengan AWS; TLS 1.3 direkomendasikan.
- Nyalakan CloudTrail untuk mencatat aktivitas API dan pengguna.
- Jangan pernah menaruh informasi rahasia di tag atau field teks bebas seperti Name.
- Untuk modul kriptografi tervalidasi FIPS 140-3, pakai endpoint FIPS.
Siapa bertanggung jawab atas apa
| AWS | Kamu |
|---|---|
| Keamanan fisik dan infrastruktur global | Isi data yang kamu unggah dan kirim |
| Isolasi antar penyewa | IAM policy dan siapa boleh apa |
| Patching layanan terkelola | Konfigurasi enkripsi dan jaringan |
| Ketersediaan layanan | Retensi, penghapusan, dan klasifikasi datamu |
Daftar yang direkomendasikan dokumentasinya
- Lindungi kredensial akun, dan buat pengguna individual lewat IAM Identity Center atau IAM — masing-masing dengan izin seperlunya.
- Aktifkan MFA pada setiap akun.
- Gunakan SSL/TLS. TLS 1.2 diwajibkan, TLS 1.3 direkomendasikan.
- Aktifkan pencatatan aktivitas API dan pengguna dengan CloudTrail.
- Gunakan solusi enkripsi AWS beserta kontrol keamanan default tiap layanan.
- Pakai layanan keamanan terkelola seperti Macie untuk menemukan dan mengamankan data sensitif di S3.
- Kalau butuh modul kriptografi tervalidasi FIPS 140-3, gunakan endpoint FIPS.
Peringatan yang paling sering dilanggar: jangan menaruh informasi rahasia atau sensitif —
misalnya alamat email pelanggan — ke dalam tag atau field teks bebas
seperti Name. Ini berlaku di konsol, API, CLI, dan SDK. Nama knowledge base seperti
kb-budi-santoso-nasabah-prioritas adalah kebocoran data yang terlihat oleh siapa pun yang bisa
membaca daftar resource, dan ikut muncul di laporan biaya.
Enkripsi
| Apa | Bagaimana |
|---|---|
| Saat transit | TLS, ditegakkan layanan |
| Dokumen sumber di S3 | SSE-S3 atau SSE-KMS dengan kunci milikmu |
| Resource knowledge base | Bisa dienkripsi dengan kunci KMS |
| Vector store pihak ketiga | Bisa dienkripsi dengan kunci KMS |
| Log dan riwayat percakapan | Tanggung jawabmu — CloudWatch Logs dan DynamoDB perlu diatur sendiri |
Memakai customer managed key di KMS memberi dua hal yang tidak diberikan kunci bawaan: kendali atas kebijakan kunci (siapa boleh mendekripsi) dan jejak audit CloudTrail untuk setiap pemakaian kunci. Untuk data yang tunduk pada aturan kepatuhan, itu bukan kemewahan.
iam.PolicyStatement(
actions=["kms:Decrypt", "kms:GenerateDataKey"],
resources=[kunci.key_arn],
conditions={"StringEquals": {"kms:ViaService": f"s3.{region}.amazonaws.com"}},
)
Kondisi kms:ViaService membatasi pemakaian kunci hanya lewat layanan tertentu — sehingga
kredensial yang bocor tidak bisa dipakai mendekripsi data secara langsung.
Yang khas aplikasi GenAI
| Risiko | Penawar |
|---|---|
| Prompt dan respons tercatat mentah di log | Sensor dengan Comprehend sebelum mencatat |
| Riwayat percakapan disimpan selamanya | TTL di DynamoDB, S3 Lifecycle |
| Memori agent menyerap data pribadi | Tetapkan apa yang boleh diingat; beri retensi |
| Dokumen sensitif ikut ter-ingest | Macie + filter metadata |
| Nama resource membocorkan identitas | Konvensi penamaan tanpa data pribadi |
Latihan: telusuri satu permintaan di aplikasimu dari ujung ke ujung dan tuliskan setiap tempat teks pengguna tersimpan: log Lambda, riwayat DynamoDB, model invocation log, dan memori agent. Untuk masing-masing, jawab tiga hal: dienkripsi dengan kunci apa, disimpan berapa lama, dan siapa yang bisa membacanya.
Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.