Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Keamanan tabel global DynamoDB
Replika tabel global adalah tabel DynamoDB, jadi Anda menggunakan metode yang sama untuk mengontrol akses ke replika yang Anda lakukan untuk tabel wilayah tunggal, termasuk kebijakan identitas AWS Identity and Access Management (IAM) dan kebijakan berbasis sumber daya. Topik ini mencakup cara mengamankan tabel global multi-akun DynamoDB menggunakan izin IAM dan AWS Key Management Service enkripsi ().AWS KMS Anda mempelajari tentang kebijakan berbasis sumber daya dan peran terkait layanan (SLR) yang memungkinkan replikasi lintas akun lintas wilayah dan penskalaan otomatis, izin IAM yang diperlukan untuk membuat, memperbarui, dan menghapus tabel global, untuk tabel konsistensi akhir Multi-wilayah (MREC). Anda juga mempelajari tentang kunci AWS KMS enkripsi untuk mengelola replikasi lintas wilayah dengan aman.
Ini memberikan informasi terperinci tentang kebijakan dan izin berbasis sumber daya yang diperlukan untuk membuat replikasi tabel lintas akun dan lintas wilayah. Memahami model keamanan ini sangat penting bagi pelanggan yang perlu menerapkan solusi replikasi data lintas akun yang aman.
Otorisasi utama layanan untuk replikasi
Tabel global multi-akun DynamoDB menggunakan pendekatan otorisasi yang berbeda karena replikasi dilakukan melintasi batas akun. Ini dilakukan menggunakan prinsip layanan replikasi DynamoDB:. replication.dynamodb.amazonaws.com Setiap akun yang berpartisipasi harus secara eksplisit mengizinkan prinsipal tersebut dalam kebijakan sumber daya tabel replika, memberinya izin yang dapat dibatasi ke replika tertentu oleh kondisi konteks sumber pada kunci sepertiaws:SourceAccount,aws:SourceArn, dll. — lihat kunci kondisi AWS global untuk detail selengkapnya. Izin bersifat dua arah, yang berarti bahwa semua replika harus secara eksplisit memberikan izin satu sama lain sebelum replikasi dapat dibuat di sepasang replika tertentu.
Izin utama layanan berikut sangat penting untuk replikasi lintas akun:
-
dynamodb:ReadDataForReplicationmemberikan kemampuan untuk membaca data untuk tujuan replikasi. Izin ini memungkinkan perubahan dalam satu replika untuk dibaca dan disebarkan ke replika lain. -
dynamodb:WriteDataForReplicationmemungkinkan penulisan data yang direplikasi ke tabel tujuan. Izin ini memungkinkan perubahan disinkronkan di semua replika dalam tabel global. -
dynamodb:ReplicateSettingsmemungkinkan sinkronisasi pengaturan tabel di seluruh replika, menyediakan konfigurasi yang konsisten di semua tabel yang berpartisipasi.
Setiap replika harus memberikan izin di atas untuk semua replika lain dan untuk dirinya sendiri — yaitu kondisi konteks sumber harus menyertakan set lengkap replika yang terdiri dari tabel global. Izin ini diverifikasi untuk setiap replika baru saat ditambahkan ke tabel global multi-akun. Ini memverifikasi bahwa operasi replikasi hanya dilakukan oleh layanan DynamoDB resmi dan hanya di antara tabel yang dimaksud.
Service-linked peran untuk tabel global multi-akun
Tabel global multi-akun DynamoDB mereplikasi pengaturan di semua replika sehingga setiap replika diatur secara identik dengan throughput yang konsisten dan memberikan pengalaman fail-over yang mulus. Replikasi pengaturan dikendalikan melalui ReplicateSettings izin pada prinsip layanan, tetapi kami juga mengandalkan peran terkait layanan (SLR) untuk mengelola replikasi lintas wilayah lintas akun tertentu dan kemampuan penskalaan otomatis. Peran-peran ini diatur hanya sekali per AWS akun. Setelah dibuat, peran yang sama melayani semua tabel global di akun Anda. Untuk informasi selengkapnya tentang peran terkait layanan, lihat Menggunakan peran terkait layanan di Panduan Pengguna IAM.
Peran terkait layanan manajemen pengaturan
Amazon DynamoDB secara otomatis membuat peran AWSServiceRoleForDynamoDBGlobalTableSettingsManagement terkait layanan (SLR) saat Anda membuat replika tabel global multi-akun pertama di akun. Peran ini mengelola replikasi pengaturan lintas wilayah lintas akun untuk Anda.
Saat menerapkan kebijakan berbasis sumber daya ke replika, konfirmasikan bahwa Anda tidak menolak izin apa pun yang ditentukan dalam prinsip SLR, karena hal ini dapat mengganggu manajemen pengaturan dan dapat mengganggu replikasi jika throughput tidak cocok di seluruh replika atau GSI. AWSServiceRoleForDynamoDBGlobalTableSettingsManagement Jika Anda menolak izin SLR yang diperlukan, replikasi ke dan dari replika yang terpengaruh dapat berhenti, dan status tabel replika akan berubah menjadi. REPLICATION_NOT_AUTHORIZED Untuk tabel global multi-akun, jika replika tetap dalam REPLICATION_NOT_AUTHORIZED status selama lebih dari 20 jam, replika dikonversi secara ireversibel ke tabel DynamoDB wilayah tunggal. SLR memiliki izin berikut:
-
application-autoscaling:DeleteScalingPolicy -
application-autoscaling:DescribeScalableTargets -
application-autoscaling:DescribeScalingPolicies -
application-autoscaling:DeregisterScalableTarget -
application-autoscaling:PutScalingPolicy -
application-autoscaling:RegisterScalableTarget
Peran terkait layanan penskalaan otomatis
Saat mengonfigurasi tabel global untuk mode kapasitas yang disediakan, penskalaan otomatis harus dikonfigurasi untuk tabel global. Penskalaan otomatis DynamoDB menggunakan layanan Penskalaan Otomatis AWS Aplikasi untuk menyesuaikan kapasitas throughput yang disediakan secara dinamis pada replika tabel global Anda. Layanan Penskalaan Otomatis Aplikasi membuat peran terkait layanan (SLR) bernama _DynamoDBTable. AWSServiceRoleForApplicationAutoScaling Peran terkait layanan ini secara otomatis dibuat di AWS akun Anda saat pertama kali mengonfigurasi penskalaan otomatis untuk tabel DynamoDB. Hal ini memungkinkan Application Auto Scaling untuk mengelola kapasitas tabel yang disediakan dan membuat CloudWatch alarm.
Saat menerapkan kebijakan berbasis sumber daya ke replika, pastikan Anda tidak menolak izin apa pun yang ditentukan dalam prinsip SLR Penskalaan Otomatis Aplikasi, karena ini akan mengganggu fungsi penskalaan otomatis. AWSApplicationAutoscalingDynamoDBTablePolicy
Bagaimana tabel global digunakan AWS IAM
Bagian berikut menjelaskan izin yang diperlukan untuk operasi tabel global yang berbeda dan memberikan contoh kebijakan untuk membantu Anda mengonfigurasi akses yang sesuai untuk pengguna dan aplikasi Anda.
catatan
Semua izin yang dijelaskan harus diterapkan ke sumber daya tabel tertentu ARN di Wilayah yang terkena dampak. Sumber daya tabel ARN mengikuti formatarn:aws:dynamodb:region:account-id:table/table-name, di mana Anda perlu menentukan Wilayah, ID akun, dan nilai nama tabel yang sebenarnya.
Berikut ini adalah topik langkah demi langkah yang kami bahas di bagian di bawah ini:
-
Membuat tabel global multi-akun dan menambahkan replika
-
Memperbarui tabel global multi-akun
-
Menghapus tabel global dan menghapus replika
Membuat tabel global dan menambahkan replika
Izin untuk membuat tabel global
Ketika replika baru ditambahkan ke tabel regional untuk membentuk tabel global multi-akun atau ke tabel global multi-akun yang ada, prinsipal IAM yang melakukan tindakan harus disahkan oleh semua anggota yang ada. Semua anggota yang ada harus memberikan izin berikut dalam kebijakan tabel mereka agar penambahan replika berhasil:
-
dynamodb:AssociateTableReplica- Izin ini memungkinkan tabel untuk digabungkan ke dalam pengaturan tabel global. Ini adalah izin dasar yang memungkinkan pembentukan awal hubungan replikasi.
Kontrol yang tepat ini hanya memungkinkan akun resmi untuk berpartisipasi dalam pengaturan tabel global.
Contoh kebijakan IAM untuk membuat tabel global
Pengaturan tabel global multi-akun mengikuti alur otorisasi khusus yang menyediakan replikasi aman. Mari kita periksa bagaimana ini bekerja dalam praktik dengan berjalan melalui skenario praktis di mana pelanggan ingin membuat tabel global dengan dua replika. Replika pertama (replikaA) berada di Akun A di wilayah ap-east-1, sedangkan replika kedua (replicab) ada di Akun B di wilayah eu-south-1.
-
Di akun sumber (Akun A), proses dimulai dengan membuat tabel replika utama. Administrator akun harus melampirkan kebijakan berbasis sumber daya ke tabel ini yang secara eksplisit memberikan izin yang diperlukan ke akun tujuan (Akun B) untuk melakukan asosiasi. Kebijakan ini juga mengizinkan layanan replikasi DynamoDB untuk melakukan tindakan replikasi penting.
-
Akun tujuan (Akun B) mengikuti proses serupa dengan melampirkan kebijakan berbasis sumber daya yang sesuai saat membuat replika dan mereferensikan tabel sumber ARN untuk digunakan untuk membuat replika. Kebijakan ini mencerminkan izin yang diberikan oleh Akun A, menciptakan hubungan dua arah tepercaya. Sebelum membuat replikasi, DynamoDB memvalidasi izin lintas akun ini untuk memverifikasi otorisasi yang tepat ada.
Untuk membuat pengaturan ini:
-
Administrator Akun A harus terlebih dahulu melampirkan kebijakan berbasis sumber daya ke replikaA. Kebijakan ini secara eksplisit memberikan izin yang diperlukan untuk Akun B dan layanan replikasi DynamoDB.
-
Demikian pula, administrator Akun B harus melampirkan kebijakan pencocokan ke ReplicaB, dengan referensi akun dibalik untuk memberikan izin yang sesuai ke Akun A, dalam panggilan buat tabel untuk membuat replika B yang mereferensikan replika A sebagai tabel sumber.
Dalam pengaturan ini, kami memiliki 3 replika replikaA, replicab, dan replicac di Akun A, Akun B, dan Akun C, masing-masing. Replika A adalah replika pertama, yang dimulai sebagai tabel regional, dan kemudian Replicab dan ReplicaC ditambahkan ke dalamnya.
-
Administrator Akun A harus terlebih dahulu melampirkan kebijakan berbasis sumber daya ke replikaA yang memungkinkan replikasi dengan semua anggota, dan mengizinkan prinsipal IAM Akun B dan Akun C untuk menambahkan replika.
-
Administrator Akun B harus menambahkan replika (Replica B) yang menunjuk ke replikaA sebagai sumber. Replica B memiliki kebijakan berikut yang memungkinkan replikasi antara semua anggota, dan mengizinkan Akun C untuk menambahkan replika:
-
Akhirnya, administrator Akun C membuat replika dengan kebijakan berikut yang memungkinkan izin replikasi antara semua anggota. Kebijakan tidak mengizinkan replika lebih lanjut ditambahkan.
Memperbarui tabel global multi-akun
Untuk mengubah pengaturan replika untuk tabel global yang ada menggunakan UpdateTable API, Anda memerlukan izin berikut pada sumber daya tabel di Wilayah tempat Anda melakukan panggilan API: dynamodb:UpdateTable
Anda juga dapat memperbarui konfigurasi tabel global lainnya, seperti kebijakan penskalaan otomatis dan pengaturan Time to Live. Izin berikut diperlukan untuk operasi pembaruan tambahan ini:
Untuk memperbarui pengaturan Time to Live dengan UpdateTimeToLive API, Anda harus memiliki izin berikut pada sumber daya tabel di semua Wilayah yang berisi replika: dynamodb:UpdateTimeToLive
Untuk memperbarui kebijakan penskalaan otomatis replika dengan UpdateTableReplicaAutoScaling API, Anda harus memiliki izin berikut pada sumber daya tabel di semua Wilayah yang berisi replika:
-
application-autoscaling:DeleteScalingPolicy -
application-autoscaling:DeleteScheduledAction -
application-autoscaling:DeregisterScalableTarget -
application-autoscaling:DescribeScalableTargets -
application-autoscaling:DescribeScalingActivities -
application-autoscaling:DescribeScalingPolicies -
application-autoscaling:DescribeScheduledActions -
application-autoscaling:PutScalingPolicy -
application-autoscaling:PutScheduledAction -
application-autoscaling:RegisterScalableTarget
catatan
Anda perlu memberikan dynamodb:ReplicateSettings izin di semua wilayah replika dan akun agar tabel pembaruan berhasil. Jika ada replika yang tidak memberikan izin untuk mereplikasi pengaturan ke replika apa pun di tabel global multi-akun, semua operasi Pembaruan di semua replika akan gagal AccessDeniedException sampai izin diperbaiki.
Menghapus tabel global dan menghapus replika
Untuk menghapus tabel global, Anda harus menghapus semua replika. Tidak seperti Tabel Global akun yang sama, Anda tidak dapat menggunakan UpdateTable untuk menghapus tabel replika di wilayah terpencil dan setiap replika harus dihapus melalui DeleteTable API dari akun yang mengontrolnya.
Izin untuk menghapus tabel global dan menghapus replika
Izin berikut diperlukan baik untuk menghapus replika individual maupun untuk menghapus tabel global sepenuhnya. Menghapus konfigurasi tabel global hanya menghapus hubungan replikasi antara tabel di Wilayah yang berbeda. Itu tidak menghapus tabel DynamoDB yang mendasarinya di Wilayah terakhir yang tersisa. Tabel di Wilayah terakhir terus ada sebagai tabel DynamoDB standar dengan data dan pengaturan yang sama.
Anda memerlukan izin berikut pada sumber daya tabel di setiap Wilayah tempat Anda menghapus replika:
-
dynamodb:DeleteTable -
dynamodb:DeleteTableReplica
Bagaimana tabel global digunakan AWS KMS
Seperti semua tabel DynamoDB, replika tabel global selalu mengenkripsi data saat diam menggunakan kunci enkripsi yang disimpan di AWS Key Management Service ().AWS KMS
catatan
Tidak seperti tabel global akun yang sama, replika yang berbeda dalam tabel global multi-akun dapat dikonfigurasi dengan jenis kunci yang berbeda ( AWS KMS kunci yang AWS dimiliki, atau kunci yang dikelola pelanggan). Multi-account tabel global tidak mendukung Kunci AWS Terkelola.
Multi-account tabel global yang menggunakan CMK memerlukan kebijakan kunci setiap replika untuk memberikan izin kepada prinsipal layanan replikasi DynamoDB (replication.dynamodb.amazonaws.com) untuk mengakses kunci untuk replikasi dan manajemen pengaturan. Izin berikut diperlukan:
-
kms:Decrypt -
kms:ReEncrypt* -
kms:GenerateDataKey* -
kms:DescribeKey
Penting
DynamoDB memerlukan akses ke kunci enkripsi replika untuk menghapus replika. Jika Anda ingin menonaktifkan atau menghapus kunci yang dikelola pelanggan yang digunakan untuk mengenkripsi replika karena Anda menghapus replika, pertama-tama Anda harus menghapus replika, menunggu tabel dihapus dari grup replikasi dengan memanggil description di salah satu replika lainnya, lalu menonaktifkan atau menghapus kunci tersebut.
Jika Anda menonaktifkan atau mencabut akses DynamoDB ke kunci yang dikelola pelanggan yang digunakan untuk mengenkripsi replika, replikasi ke dan dari replika akan berhenti dan status replika akan berubah menjadi. INACCESSIBLE_ENCRYPTION_CREDENTIALS Jika replika tetap dalam INACCESSIBLE_ENCRYPTION_CREDENTIALS keadaan selama lebih dari 20 jam, replika dikonversi secara ireversibel ke tabel DynamoDB wilayah tunggal.
Contoh AWS KMS kebijakan
AWS KMS Kebijakan ini memungkinkan DynamoDB mengakses kedua AWS KMS kunci untuk replikasi antara replika A dan B. K AWS KMS unci yang dilampirkan ke replika DynamoDB di setiap akun perlu diperbarui dengan kebijakan berikut: