Perlindungan data di Amazon Security Lake

Model tanggung jawab AWS bersama model berlaku untuk perlindungan data di Amazon Security Lake. Seperti yang dijelaskan dalam model AWS ini, 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. Lihat informasi yang lebih lengkap tentang privasi data dalam Pertanyaan Umum Privasi Data. Lihat informasi tentang perlindungan data di Eropa di pos blog Model Tanggung Jawab Bersama dan GDPR AWS di Blog Keamanan AWS .

Untuk tujuan perlindungan data, kami menyarankan Anda melindungi Akun AWS kredensyal 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:

• Gunakan autentikasi multi-faktor (MFA) pada setiap akun.

• Gunakan SSL/TLS untuk berkomunikasi dengan sumber daya. AWS Kami mensyaratkan TLS 1.2 dan menganjurkan TLS 1.3.

• Siapkan API dan logging aktivitas pengguna dengan AWS CloudTrail.

• Gunakan solusi AWS enkripsi, bersama dengan semua kontrol keamanan default di dalamnya Layanan AWS.

• Gunakan layanan keamanan terkelola lanjut seperti Amazon Macie, yang membantu menemukan dan mengamankan data sensitif yang disimpan di Amazon S3.

• Jika Anda memerlukan modul kriptografi tervalidasi FIPS 140-2 saat mengakses AWS melalui antarmuka baris perintah atau API, gunakan titik akhir FIPS. Lihat informasi yang lebih lengkap tentang titik akhir FIPS yang tersedia di Standar Pemrosesan Informasi Federal (FIPS) 140-2.

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 diam

Amazon Security Lake menyimpan data Anda dengan aman menggunakan solusi AWS enkripsi. Log keamanan mentah dan data peristiwa disimpan dalam bucket Simple Storage Service (Amazon S3) multi-tenant di akun yang dikelola Security Lake. Security Lake mengenkripsi data mentah ini menggunakan kunci AWS milik from AWS Key Management Service ()AWS KMS. AWS kunci yang dimiliki adalah kumpulan AWS KMS kunci yang dimiliki AWS layanan—dalam hal ini Security Lake—memiliki dan mengelola untuk digunakan di beberapa akun. AWS

Security Lake menjalankan pekerjaan ekstrak, transformasi, dan muat (ETL) pada log mentah dan data peristiwa. Data yang diproses tetap dienkripsi di akun layanan Security Lake.

Setelah pekerjaan ETL selesai, Security Lake membuat bucket S3 penyewa tunggal di akun Anda (satu ember 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 data log dan peristiwa ke bucket. Untuk mengenkripsi data di bucket S3, Anda dapat memilih kunci enkripsi yang dikelola S3 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 enkripsi yang dikelola Amazon S3 (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 menggunakan 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 untuk mengenkripsi dan mendekripsi data Security Lake.

Jika Anda menggunakan kunci terkelola pelanggan untuk mengenkripsi data yang ditulis ke bucket S3, 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 Security Lake akses ke kunci KMS di akun pelanggan.

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

• Kirim GenerateDataKey permintaan AWS KMS untuk menghasilkan kunci data yang dienkripsi oleh kunci terkelola pelanggan Anda.

• Kirim RetireGrant permintaan ke AWS KMS. Saat Anda melakukan pembaruan pada data lake Anda, operasi ini memungkinkan penghentian hibah yang ditambahkan ke kunci AWS KMS untuk pemrosesan ETL.

Security Lake tidak memerlukan Decrypt izin. Ketika pengguna resmi kunci membaca data Security Lake, S3 mengelola dekripsi, dan pengguna yang berwenang dapat membaca data dalam bentuk yang tidak terenkripsi. Namun, pelanggan memerlukan Decrypt izin untuk menggunakan data sumber. Untuk informasi selengkapnya tentang izin pelanggan, lihat. Mengelola 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 utama 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 Mengubah kebijakan kunci di Panduan AWS Key Management Service Pengembang.

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 cara membuat kebijakan kunci, lihat Membuat kebijakan kunci di Panduan AWS Key Management Service Pengembang.

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 khusus atau pelanggan, Security Lake membuat peran IAM di akun Anda. 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 data lake, 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 terkelola pelanggan in 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 notifikasi peristiwa Amazon S3 tidak dikirimkan ke antrean Amazon SQS yang menggunakan enkripsi sisi server? di pusat AWS pengetahuan.

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

Enkripsi bergerak

Security Lake mengenkripsi semua data dalam perjalanan antar AWS layanan. Security Lake melindungi data dalam perjalanan, 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 yang aman.