Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Kontrol akses DAX
DynamoDB Accelerator (DAX) dirancang untuk bekerja sama dengan DynamoDB guna menambahkan lapisan caching ke aplikasi Anda dengan lancar. Namun, DAX dan DynamoDB memiliki mekanisme kontrol akses terpisah. Kedua layanan menggunakan AWS Identity and Access Management (IAM) untuk menerapkan kebijakan keamanan masing-masing, tetapi model keamanan untuk DAX dan DynamoDB berbeda.
Kami sangat menyarankan agar Anda memahami kedua model keamanan, sehingga dapat menerapkan langkah-langkah keamanan yang tepat untuk aplikasi Anda yang menggunakan DAX.
Bagian ini menjelaskan mekanisme kontrol akses yang disediakan oleh DAX dan memberikan contoh kebijakan IAM yang dapat disesuaikan dengan kebutuhan Anda.
Lindungi data sensitif dalam nama cluster
Saat Anda membuat cluster DAX, jangan sertakan informasi identifikasi sensitif, seperti nomor akun pelanggan Anda, dalam nama cluster. Nama cluster dapat terlihat di luar akun Anda. Saat Anda mengaktifkan enkripsi saat transit, DAX menggunakan AWS Certificate Manager (ACM) untuk menyediakan sertifikat Transport Layer Security (TLS) untuk titik akhir cluster, dan sertifikat tersebut menyertakan nama cluster Anda.
ACM secara otomatis mencatat setiap sertifikat publik yang dikeluarkan di log Transparansi Sertifikat publik (CT), dan persyaratan kebijakan browser mencegah Anda memilih keluar. Akibatnya, log CT publik berisi nama-nama cluster TLS-enabled DAX setelah ACM mengeluarkan atau memperbarui sertifikat. Untuk panduan umum tentang penamaan sumber daya, lihatPerlindungan data di DynamoDB. Untuk informasi selengkapnya tentang pencatatan CT, lihat Pencatatan transparansi AWS sertifikat di Panduan Pengguna Manajer Sertifikat.
Dengan DynamoDB, Anda dapat membuat kebijakan IAM yang membatasi tindakan yang dapat dilakukan pengguna pada sumber daya DynamoDB individu. Misalnya, Anda dapat membuat peran pengguna yang hanya mengizinkan pengguna melakukan tindakan hanya baca di tabel DynamoDB tertentu. (Untuk informasi selengkapnya, lihat Manajemen Identitas dan Akses untuk Amazon DynamoDB.) Sebagai perbandingan, model keamanan DAX berfokus pada keamanan klaster dan kemampuan klaster untuk melakukan tindakan API DynamoDB atas nama Anda.
Awas
Jika saat ini Anda menggunakan kebijakan dan peran IAM untuk membatasi akses ke data tabel DynamoDB, penggunaan DAX dapat merusak kebijakan tersebut. Misalnya, pengguna dapat memiliki akses ke tabel DynamoDB melalui DAX tetapi tidak memiliki akses eksplisit ke tabel yang sama yang mengakses DynamoDB secara langsung. Untuk informasi selengkapnya, lihat Manajemen Identitas dan Akses untuk Amazon DynamoDB.
DAX tidak memberlakukan pemisahan tingkat pengguna pada data di DynamoDB. Sebaliknya, pengguna mewarisi izin kebijakan IAM klaster DAX ketika mengakses klaster tersebut. Jadi, saat mengakses tabel DynamoDB melalui DAX, satu-satunya kontrol akses yang berlaku adalah izin dalam kebijakan IAM cluster DAX. Tidak ada izin lain yang diakui.
Jika memerlukan isolasi, sebaiknya Anda membuat klaster DAX tambahan dan lingkup kebijakan IAM untuk setiap klaster. Misalnya, Anda dapat membuat beberapa klaster DAX dan mengizinkan setiap klaster mengakses hanya satu tabel.
Peran layanan IAM untuk DAX
Ketika membuat sebuah klaster DAX, Anda harus mengasosiasikan instans dengan peran IAM. Hal ini dikenal sebagai peran layanan untuk klaster.
Misalnya, Anda ingin membuat klaster DAX baru bernama DAXCluster01. Anda dapat membuat peran layanan bernama DAXServiceRole, dan mengaitkan peran dengan DAX cluster01. Kebijakan untuk DAXServiceRole akan menentukan tindakan DynamoDB yang dapat dilakukan Dax Cluster01, atas nama pengguna yang berinteraksi dengan DAXcluster01.
Saat Anda membuat peran layanan, Anda harus menentukan hubungan kepercayaan antara DAXServiceRole dan layanan DAX itu sendiri. Hubungan kepercayaan menentukan entitas yang dapat mengambil peran dan memanfaatkan izinnya. Berikut ini adalah contoh dokumen hubungan kepercayaan untuk DAXServiceRole:
Hubungan kepercayaan ini memungkinkan cluster DAX untuk mengasumsikan DAXServiceRole dan melakukan panggilan API DynamoDB atas nama Anda.
Tindakan API DynamoDB yang diizinkan dijelaskan dalam dokumen kebijakan IAM, yang Anda lampirkan. DAXServiceRole Berikut adalah contoh dokumen kebijakan.
Kebijakan ini mengizinkan DAX melakukan tindakan API DynamoDB yang diperlukan di tabel DynamoDB. Tindakan dynamodb:DescribeTable diperlukan agar DAX dapat mempertahankan metadata tentang tabel, dan tindakan lain adalah tindakan pembacaan dan penulisan yang dilakukan pada item dalam tabel. Tabel bernama Books berada di Wilayah us-west-2 dan dimiliki oleh ID akun AWS 123456789012.
catatan
DAX mendukung mekanisme untuk mencegah masalah wakil yang membingungkan selama akses lintas layanan. Untuk informasi selengkapnya, lihat Masalah confused deputy di Panduan Pengguna IAM.
Kebijakan IAM untuk mengizinkan akses klaster DAX
Setelah membuat klaster DAX, Anda perlu memberikan izin untuk pengguna sehingga pengguna dapat mengakses klaster DAX.
Misalnya, Anda ingin memberikan akses ke DAXCluster01 untuk pengguna bernama Alice. Pertama-tama Anda akan membuat kebijakan IAM (AliceAccessPolicy) yang mendefinisikan klaster DAX dan tindakan API DAX yang dapat diakses oleh penerima. Kemudian, Anda akan memberikan akses dengan melampirkan kebijakan ini ke pengguna Alice.
Dokumen kebijakan berikut memberikan akses penuh kepada penerima di DAXCluster01.
Dokumen kebijakan mengizinkan akses ke klaster DAX, tetapi tidak memberikan izin DynamoDB apa pun. (Izin DynamoDB diberikan oleh peran layanan DAX).
Untuk pengguna Alice, Anda harus terlebih dahulu membuat AliceAccessPolicy dengan dokumen kebijakan yang ditampilkan sebelumnya. Kemudian, Anda akan melampirkan kebijakan tersebut pada Alice.
catatan
Selain melampirkan kebijakan kepada pengguna, Anda dapat melampirkannya ke peran IAM. Dengan cara itu, semua pengguna yang mengambil peran tersebut akan memiliki izin yang Anda tetapkan dalam kebijakan.
Kebijakan pengguna, bersama dengan peran layanan DAX, menentukan sumber daya DynamoDB dan tindakan API yang dapat diakses penerima melalui DAX.
Studi Kasus: Mengakses DynamoDB dan DAX
Skenario berikut dapat membantu Anda memahami lebih jauh tentang kebijakan IAM yang digunakan dengan DAX. (Skenario ini disebut di seluruh bagian ini). Diagram berikut menunjukkan gambaran umum tingkat tinggi skenario.
Dalam skenario ini, terdapat entitas berikut:
-
Pengguna (Bob).
-
Peran IAM (
BobUserRole). Bob mengambil peran ini saat runtime. -
Kebijakan IAM (
BobAccessPolicy). Kebijakan ini dilampirkan padaBobUserRole.BobAccessPolicymenentukan sumber daya DynamoDB dan DAX yang dapat diaksesBobUserRole. -
Klaster DAX (
DAXCluster01). -
Peran layanan IAM (
DAXServiceRole). Peran ini mengizinkanDAXCluster01untuk mengakses DynamoDB. -
Kebijakan IAM (
DAXAccessPolicy). Kebijakan ini dilampirkan padaDAXServiceRole.DAXAccessPolicymenentukan API dan sumber daya DynamoDB yang dapat diaksesDAXCluster01. -
Tabel DynamoDB (
Books).
Kombinasi pernyataan kebijakan di BobAccessPolicy dan DAXAccessPolicy menentukan apa yang dapat dilakukan Bob dengan tabel Books. Misalnya, Bob mungkin dapat mengakses Books secara langsung (menggunakan titik akhir DynamoDB), secara tidak langsung (menggunakan klaster DAX), atau keduanya. Bob mungkin juga dapat membaca data dari Books, menulis data ke Books, atau keduanya.
Akses ke DynamoDB, tetapi tidak ada akses ke DAX
Mengizinkan akses langsung ke tabel DynamoDB sekaligus mencegah akses tidak langsung menggunakan klaster DAX dapat dilakukan. Untuk akses langsung ke DynamoDB, izin untuk BobUserRole ditentukan oleh BobAccessPolicy (yang terlampir pada peran).
Read-only akses ke DynamoDB (hanya)
Bob dapat mengakses DynamoDB dengan BobUserRole. Kebijakan IAM yang terlampir pada peran ini (BobAccessPolicy) menentukan tabel DynamoDB yang dapat diakses BobUserRole dan API apa yang dapat diinvokasi BobUserRole.
Pertimbangkan dokumen kebijakan berikut untuk BobAccessPolicy.
Ketika dilampirkan ke BobAccessPolicy, dokumen ini mengizinkan BobUserRole untuk mengakses titik akhir DynamoDB dan melakukan operasi hanya baca pada tabel Books.
DAX tidak muncul dalam kebijakan ini, jadi akses melalui DAX ditolak.
Read/write akses ke DynamoDB (hanya)
Jika BobUserRole memerlukan read/write akses ke DynamoDB, kebijakan berikut akan berfungsi.
Sekali lagi, DAX tidak muncul dalam kebijakan ini, jadi akses melalui DAX ditolak.
Akses ke DynamoDB dan DAX
Untuk mengizinkan akses ke cluster DAX, Anda harus menyertakan DAX-specific tindakan dalam kebijakan IAM.
Tindakan DAX-specific berikut sesuai dengan rekan-rekan mereka dengan nama yang sama di DynamoDB API:
-
dax:GetItem -
dax:BatchGetItem -
dax:Query -
dax:Scan -
dax:PutItem -
dax:UpdateItem -
dax:DeleteItem -
dax:BatchWriteItem -
dax:ConditionCheckItem
Hal yang sama berlaku untuk kunci syarat dax:EnclosingOperation.
Read-only akses ke DynamoDB dan akses read-only ke DAX
Anggaplah Bob membutuhkan akses hanya baca ke tabel Books, dari DynamoDB dan dari DAX. Kebijakan berikut (dilampirkan pada BobUserRole) memberikan akses ini.
Kebijakan tersebut memiliki pernyataan untuk akses DAX (DAXAccessStmt) dan pernyataan lain untuk akses DynamoDB (DynamoDBAccessStmt). Pernyataan tersebut mengizinkan Bob mengirim permintaan GetItem, BatchGetItem, Query, dan Scan ke DAXCluster01.
Namun, peran layanan untuk DAXCluster01 juga akan membutuhkan akses hanya baca ke tabel Books di DynamoDB. Kebijakan IAM berikut, yang terlampir pada DAXServiceRole, akan memenuhi persyaratan ini.
Read/write akses ke DynamoDB dan read-only dengan DAX
Untuk peran pengguna tertentu, Anda dapat menyediakan read/write akses ke tabel DynamoDB, sementara juga memungkinkan akses read-only melalui DAX.
Untuk Bob, kebijakan IAM untuk perlu mengi BobUserRole zinkan tindakan baca dan tulis DynamoDB di Books tabel, sementara juga mendukung tindakan baca-saja melalui. DAXCluster01
Dokumen kebijakan contoh untuk BobUserRole berikut memberikan akses ini.
Selain itu, DAXServiceRole akan memerlukan kebijakan IAM yang mengizinkan DAXCluster01 melakukan tindakan hanya baca pada tabel Books.
Read/write akses ke DynamoDB dan read/write akses ke DAX
Sekarang anggaplah Bob memerlukan read/write akses ke Books tabel, langsung dari DynamoDB atau tidak langsung dari. DAXCluster01 Dokumen kebijakan yang dilampirkan pada BobAccessPolicy berikut memberikan akses ini.
Selain itu, DAXServiceRole akan memerlukan kebijakan IAM yang memungkinkan DAXCluster01 untuk melakukan read/write tindakan di atas Books meja.
Akses ke DynamoDB melalui DAX, tetapi tidak ada akses langsung ke DynamoDB
Dalam skenario ini, Bob dapat mengakses Books tabel melalui DAX, tetapi ia tidak memiliki akses langsung ke Books tabel di DynamoDB. Dengan demikian, ketika mendapatkan akses ke DAX, Bob juga mendapatkan akses ke tabel DynamoDB yang mungkin tidak dapat diakses. Saat Anda mengonfigurasi kebijakan IAM untuk peran layanan DAX, ingatlah bahwa setiap pengguna yang diberi akses ke cluster DAX melalui kebijakan akses pengguna memperoleh akses ke tabel yang ditentukan dalam kebijakan tersebut. Dalam kasus ini, BobAccessPolicy mendapat akses ke tabel yang ditentukan di DAXAccessPolicy.
Jika saat ini Anda menggunakan kebijakan dan peran IAM untuk membatasi akses ke tabel dan data DynamoDB, penggunaan DAX dapat merusak kebijakan tersebut. Dalam kebijakan berikut, Bob memiliki akses ke tabel DynamoDB melalui DAX tetapi tidak memiliki akses langsung eksplisit ke tabel yang sama di DynamoDB.
Dokumen kebijakan berikut (BobAccessPolicy), yang dilampirkan pada BobUserRole, memberikan akses ini.
Dalam kebijakan akses ini, tidak ada izin untuk mengakses DynamoDB secara langsung.
Bersama dengan BobAccessPolicy, DAXAccessPolicy berikut memberi BobUserRole akses ke tabel DynamoDB Books meskipun BobUserRole tidak dapat langsung mengakses tabel Books.
Seperti yang ditunjukkan contoh ini, saat Anda mengonfigurasi kontrol akses untuk kebijakan akses pengguna dan kebijakan akses cluster DAX, Anda harus memahami sepenuhnya akses ujung ke ujung untuk memastikan bahwa prinsip hak istimewa terkecil dipatuhi. Juga pastikan bahwa memberikan akses pengguna ke cluster DAX tidak menumbangkan kebijakan kontrol akses yang telah ditetapkan sebelumnya.