Praktik terbaik keamanan pencegahan di DynamoDB - Amazon DynamoDB

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

Praktik terbaik keamanan pencegahan di DynamoDB

Praktik terbaik berikut dapat membantu Anda mengantisipasi dan mencegah insiden keamanan di Amazon DynamoDB.

Enkripsi saat diam

DynamoDB mengenkripsi semua data pengguna saat diam yang disimpan dalam tabel, indeks, aliran, dan cadangan menggunakan kunci enkripsi yang disimpan dalam AWS Key Management Service (AWS KMS). Hal ini memberi lapisan perlindungan data tambahan dengan mengamankan data Anda dari akses yang tidak sah ke penyimpanan dasar.

Anda dapat menentukan apakah DynamoDB harus menggunakan Kunci milik AWS (tipe enkripsi default), atau kunci Kunci yang dikelola AWS yang dikelola pelanggan untuk mengenkripsi data pengguna. Untuk informasi selengkapnya, lihat Enkripsi Amazon DynamoDB saat Diam.

Menggunakan peran IAM untuk mengautentikasi akses ke DynamoDB

Untuk pengguna, aplikasi, dan AWS layanan lain untuk mengakses DynamoDB, mereka harus menyertakan kredensyal yang AWS valid dalam permintaan API mereka. AWS Anda tidak boleh menyimpan AWS kredensyal secara langsung di aplikasi atau instans EC2. Ini adalah kredensial jangka panjang yang tidak dirotasi secara otomatis, dan karenanya dapat menimbulkan dampak bisnis yang signifikan jika dibobol. Peran IAM memungkinkan Anda memperoleh kunci akses sementara yang dapat digunakan untuk mengakses AWS layanan dan sumber daya.

Untuk informasi selengkapnya, lihat Manajemen Identitas dan Akses untuk Amazon DynamoDB.

Menggunakan kebijakan IAM untuk otorisasi dasar DynamoDB

Saat memberikan izin, Anda memutuskan siapa yang mendapatkannya, API DynamoDB mana yang mereka dapatkan izinnya, dan tindakan khusus yang ingin Anda izinkan pada sumber daya tersebut. Menerapkan akses hak akses paling rendah adalah hal mendasar dalam mengurangi risiko keamanan dan dampak yang dapat disebabkan oleh kesalahan atau niat jahat.

Memberikan kebijakan izin kepada identitas IAM (yaitu, pengguna, grup, dan peran) dan dengan demikian memberikan izin untuk melakukan operasi pada sumber daya DynamoDB.

Anda dapat melakukan hal ini dengan cara berikut:

Menggunakan ketentuan kebijakan IAM untuk kontrol akses ketat

Ketika memberikan izin di DynamoDB, Anda dapat menetapkan syarat yang menentukan bagaimana kebijakan izin berlaku. Menerapkan akses hak akses paling rendah adalah hal mendasar dalam mengurangi risiko keamanan dan dampak yang dapat disebabkan oleh kesalahan atau niat jahat.

Anda dapat menetapkan syarat saat memberikan izin menggunakan kebijakan IAM. Misalnya, Anda dapat melakukan hal berikut:

  • Memberi izin kepada pengguna akan akses hanya-baca pada item dan atribut tertentu dalam tabel atau indeks sekunder.

  • Memberi izin kepada pengguna akan akses hanya-tulis pada atribut tertentu dalam tabel, berdasarkan identitas pengguna tersebut.

Untuk informasi selengkapnya, lihat Menggunakan Syarat Kebijakan IAM untuk Kontrol Akses Ketat.

Menggunakan kebijakan dan titik akhir VPC untuk mengakses DynamoDB

Jika Anda hanya memerlukan akses ke DynamoDB dari dalam cloud privat virtual (VPC), Anda harus menggunakan titik akhir VPC untuk membatasi akses hanya dari VPC yang diperlukan. Melakukan hal ini akan mencegah lalu lintas melintasi internet terbuka dan tunduk pada lingkungan tersebut.

Menggunakan titik akhir VPC untuk DynamoDB akan memungkinkan Anda untuk mengontrol dan membatasi akses menggunakan hal berikut:

  • Kebijakan titik akhir VPC – Kebijakan ini diterapkan pada titik akhir VPC DynamoDB. Kebijakan tersebut memungkinkan Anda untuk mengontrol dan membatasi akses API ke tabel DynamoDB.

  • Kebijakan IAM – Dengan menggunakan syarat aws:sourceVpce pada kebijakan yang diberikan kepada pengguna, grup, atau peran, Anda dapat memberlakukan bahwa semua akses ke tabel DynamoDB adalah melalui titik akhir VPC tertentu.

Untuk informasi selengkapnya, lihat Titik Akhir untuk Amazon DynamoDB.

Pertimbangkan enkripsi di sisi klien

Kami menyarankan Anda merencanakan strategi enkripsi Anda sebelum menerapkan tabel Anda di DynamoDB. Jika Anda menyimpan data sensitif atau rahasia di DynamoDB, pertimbangkan untuk menyertakan enkripsi di sisi klien dalam paket Anda. Dengan cara ini, Anda dapat mengenkripsi data sedekat mungkin dengan asalnya, dan memastikan perlindungannya sepanjang siklus hidupnya. Mengenkripsi data bergerak dan data diam Anda yang sensitif membantu memastikan bahwa data plaintext Anda tidak tersedia untuk pihak ketiga mana pun.

AWS Database Encryption SDK untuk DynamoDB adalah pustaka perangkat lunak yang membantu Anda melindungi data tabel Anda sebelum mengirimkannya ke DynamoDB. Pustaka ini mengenkripsi, menandatangani, memverifikasi, dan mendekripsi item tabel DynamoDB Anda. Anda mengontrol atribut mana yang dienkripsi dan ditandatangani.

Pertimbangan Utama Utama

Jangan gunakan nama sensitif atau data plaintext sensitif di Kunci Utama untuk tabel dan Indeks Sekunder Global. Nama kunci akan muncul dalam definisi tabel Anda. Misalnya, nama Kunci Utama dapat diakses oleh siapa saja yang memiliki izin untuk menelepon DescribeTable. Nilai kunci dapat muncul di log Anda AWS CloudTraildan lainnya. Selain itu, DynamoDB menggunakan nilai-nilai kunci untuk mendistribusikan data dan permintaan rute AWS dan administrator dapat mengamati nilai-nilai untuk menjaga kesehatan layanan.

Jika Anda perlu menggunakan data sensitif dalam tabel atau nilai kunci GSI, sebaiknya gunakan enkripsi end-to-end klien. Ini memungkinkan Anda untuk melakukan referensi nilai kunci ke data Anda sambil memastikan bahwa itu tidak pernah muncul tidak terenkripsi di log terkait DynamoDB Anda. Salah satu cara untuk mencapai ini adalah dengan menggunakan AWS Database Encryption SDK untuk DynamoDB, tetapi itu tidak diperlukan. Jika Anda menggunakan solusi Anda sendiri, kami harus selalu menggunakan algoritma enkripsi yang cukup aman. Anda tidak boleh menggunakan opsi non-kriptografi seperti hash, karena mereka tidak dianggap cukup aman dalam kebanyakan situasi.

Jika nama kunci Primary Key Anda sensitif, sebaiknya gunakan `pk` dan `sk` sebagai gantinya. Ini adalah praktik terbaik umum yang membuat desain Partition Key Anda fleksibel.

Selalu konsultasikan dengan pakar keamanan atau tim AWS akun Anda jika Anda khawatir tentang pilihan yang tepat.