Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Perlindungan data di Amazon Security Lake

Model tanggung jawab AWS https://aws.amazon.com/compliance/shared-responsibility-model/ berlaku untuk perlindungan data di Amazon Security Lake. Seperti dijelaskan dalam model ini, AWS bertanggung jawab untuk melindungi infrastruktur global yang menjalankan semua AWS Cloud. Anda bertanggung jawab untuk mempertahankan kendali atas konten yang di-host pada infrastruktur ini. Anda juga bertanggung jawab atas tugas-tugas konfigurasi dan manajemen keamanan untuk Layanan AWS yang Anda gunakan. Untuk informasi selengkapnya tentang privasi data, lihat FAQ Privasi Data Ket . Untuk informasi tentang perlindungan data di Eropa, lihat Pusat Peraturan Umum Perlindungan Data (GDPR).

Untuk tujuan perlindungan data, kami menyarankan Anda melindungi Akun AWS kredenSIAL dan mengatur pengguna individu dengan AWS IAM Identity Center atau AWS Identity and Access Management (IAM). Dengan cara itu, setiap pengguna hanya diberi izin yang diperlukan untuk memenuhi tanggung jawab tugasnya. Kami juga menyarankan supaya Anda mengamankan data dengan cara-cara berikut:

Kami sangat merekomendasikan agar Anda tidak pernah memasukkan informasi identifikasi yang sensitif, seperti nomor rekening pelanggan Anda, ke dalam tanda atau bidang isian bebas seperti bidang Nama. Ini termasuk saat Anda bekerja dengan Security Lake atau lainnya Layanan AWS menggunakan konsol, API AWS CLI, atau AWS SDK. Data apa pun yang Anda masukkan ke dalam tanda atau bidang isian bebas yang digunakan untuk nama dapat digunakan untuk log penagihan atau log diagnostik. Saat Anda memberikan URL ke server eksternal, kami sangat menganjurkan supaya Anda tidak menyertakan informasi kredensial di dalam URL untuk memvalidasi permintaan Anda ke server itu.

Enkripsi saat diam

Amazon Security Lake menyimpan data Anda saat istirahat dengan aman menggunakan solusi AWS enkripsi. Log keamanan mentah dan data peristiwa disimpan dalam bucket multi-penyewa Amazon Simple Storage Service (Amazon S3) khusus sumber di akun yang dikelola Security Lake. Setiap sumber log memiliki bucket multi-tenant sendiri. Security Lake mengenkripsi data mentah ini menggunakan kunci yang AWS dimiliki dari AWS Key Management Service (AWS KMS). AWS kunci yang dimiliki adalah kumpulan AWS KMS kunci yang dimiliki dan dikel AWS ola oleh layanan — dalam hal ini Security Lake — untuk digunakan di beberapa akun. AWS

Security Lake menjalankan tugas ekstrak, transformasi, dan memuat (ETL) pada log mentah dan data peristiwa.

Setelah pekerjaan ETL selesai, Security Lake membuat bucket S3 penyewa tunggal di akun Anda (satu bucket untuk masing-masing Wilayah AWS tempat Anda mengaktifkan Security Lake). Data disimpan dalam bucket S3 multi-tenant hanya sementara sampai Security Lake dapat mengirimkan data dengan andal ke bucket S3 penyewa tunggal. Bucket penyewa tunggal menyertakan kebijakan berbasis sumber daya yang memberikan izin Security Lake untuk menulis log dan data peristiwa ke bucket. Untuk mengenkripsi data di bucket S3 Anda, Anda dapat memilih kunci S3-managed enkripsi atau kunci yang dikelola pelanggan (dari AWS KMS). Kedua opsi menggunakan enkripsi simetris.

Menggunakan kunci KMS untuk enkripsi data Anda

Secara default, data yang dikirimkan oleh Security Lake ke bucket S3 Anda dienkripsi oleh enkripsi sisi server Amazon dengan kunci en S3-managed kripsi Amazon ()SSE-S3. Untuk menyediakan lapisan keamanan yang Anda kelola secara langsung, Anda dapat menggunakan enkripsi sisi server dengan AWS KMS kunci (SSE-KMS) untuk data Security Lake Anda.

SSE-KMS tidak didukung di konsol Security Lake. Untuk digunakan SSE-KMS dengan Security Lake API atau CLI, pertama-tama Anda membuat kunci KMS atau menggunakan kunci yang ada. Anda melampirkan kebijakan ke kunci yang menentukan pengguna mana yang dapat menggunakan kunci tersebut untuk mengenkripsi dan mendekripsi data Security Lake.

Jika Anda menggunakan kunci yang dikelola pelanggan untuk mengenkripsi data yang ditulis ke bucket S3 Anda, Anda tidak dapat memilih kunci Multi-wilayah. Untuk kunci yang dikelola pelanggan, Security Lake membuat hibah atas nama Anda dengan mengirimkan CreateGrant permintaan ke AWS KMS. Hibah AWS KMS digunakan untuk memberikan akses Security Lake ke kunci KMS di akun pelanggan.

Security Lake memerlukan hibah untuk menggunakan kunci yang dikelola pelanggan Anda untuk operasi internal berikut:

Security Lake tidak memerlukan Decrypt izin. Ketika pengguna kunci yang berwenang membaca data Security Lake, S3 mengelola dekripsi, dan pengguna yang berwenang dapat membaca data dalam bentuk tidak terenkripsi. Namun, pelanggan memerlukan Decrypt izin untuk menggunakan data sumber. Untuk informasi selengkapnya tentang izin pelanggan, lihatMengelola akses data untuk pelanggan Security Lake.

Jika Anda ingin menggunakan kunci KMS yang ada untuk mengenkripsi data Security Lake, Anda harus mengubah kebijakan kunci untuk kunci KMS. Kebijakan kunci harus mengizinkan peran IAM yang terkait dengan lokasi danau data Lake Formation untuk menggunakan kunci KMS untuk mendekripsi data. Untuk petunjuk tentang cara mengubah kebijakan kunci untuk kunci KMS, lihat Meng ubah kebijakan kunci di Panduan Peng AWS Key Management Service embang.

Kunci KMS Anda dapat menerima permintaan hibah, memungkinkan Security Lake mengakses kunci, saat Anda membuat kebijakan kunci atau menggunakan kebijakan kunci yang ada dengan izin yang sesuai. Untuk petunjuk tentang cara membuat kebijakan kunci, lihat Membuat kebijakan kunci di Panduan Peng AWS Key Management Service embang.

Lampirkan kebijakan kunci berikut ke kunci KMS Anda:

{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:role/ExampleRole"},
  "Action": [
    "kms:CreateGrant",
    "kms:DescribeKey",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

Izin IAM yang diperlukan saat menggunakan kunci terkelola pelanggan

Lihat bagian Memulai: Prasyarat untuk ikhtisar peran IAM yang perlu Anda buat untuk menggunakan Security Lake.

Saat Anda menambahkan sumber kustom atau pelanggan, Security Lake membuat peran IAM di akun Anda. Peran-peran ini dimaksudkan untuk dibagikan dengan identitas IAM lainnya. Mereka mengizinkan sumber khusus untuk menulis data ke danau data dan pelanggan untuk mengkonsumsi data dari danau data. Kebijakan AWS terkelola yang disebut AmazonSecurityLakePermissionsBoundary menetapkan batas izin untuk peran ini.

Mengenkripsi antrian Amazon SQS

Saat Anda membuat danau data, Security Lake membuat dua antrian Amazon Simple Queue Service (Amazon SQS) yang tidak terenkripsi di akun administrator Security Lake yang didelegasikan. Anda harus mengenkripsi antrian ini untuk melindungi data Anda. Enkripsi sisi server (SSE) default yang disediakan oleh Amazon Simple Queue Service tidak cukup. Anda harus membuat kunci yang dikelola pelanggan di AWS Key Management Service (AWS KMS) untuk mengenkripsi antrian dan memberikan izin utama layanan Amazon S3 untuk bekerja dengan antrian terenkripsi. Untuk petunjuk tentang pemberian izin ini, lihat Mengapa pemberitahuan peristiwa Amazon S3 tidak dikirimkan ke antrian Amazon SQS yang menggunakan enkripsi sisi server? di Pusat Peng AWS etahuan.

Karena Security Lake digunakan AWS Lambda untuk mendukung pekerjaan ekstrak, transfer, dan memuat (ETL) pada data Anda, Anda juga harus memberikan izin Lambda untuk mengelola pesan di antrian Amazon SQS Anda. Untuk informasi, lihat Izin peran eksekusi di Panduan AWS Lambda Pengembang.

Enkripsi saat bergerak

Security Lake mengenkripsi semua data yang sedang transit antar AWS layanan. Security Lake melindungi data dalam transit, saat melakukan perjalanan ke dan dari layanan, dengan secara otomatis mengenkripsi semua data antar-jaringan menggunakan protokol enkripsi Transport Layer Security (TLS) 1.2. Permintaan HTTPS langsung yang dikirim ke Security Lake API ditandatangani dengan menggunakan Algoritma AWS Signature Version 4 untuk membuat koneksi aman.