Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
DynamoDB tabel global keamanan
Replika tabel global adalah tabel DynamoDB, sehingga Anda menggunakan metode yang sama untuk mengontrol akses ke replika yang Anda lakukan untuk tabel wilayah tunggal, AWS Identity and Access Management termasuk kebijakan identitas (IAM) dan kebijakan berbasis sumber daya. Topik ini mencakup cara mengamankan tabel global multi-akun DynamoDB menggunakan izin IAM dan enkripsi (). AWS Key Management Service AWS KMS Anda mempelajari tentang kebijakan berbasis sumber daya dan peran terkait layanan (SLR) yang memungkinkan replikasi lintas akun lintas wilayah dan auto-scaling, izin IAM yang diperlukan untuk membuat, memperbarui, dan menghapus tabel global, untuk tabel Konsistensi Akhir Multi-wilayah (MREC). Anda juga mempelajari kunci AWS KMS enkripsi untuk mengelola replikasi lintas wilayah dengan aman.
Ini memberikan informasi rinci tentang kebijakan berbasis sumber daya dan izin 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 di seluruh batas akun. Ini dilakukan dengan 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, memberikan izin yang dapat dibatasi ke replika tertentu berdasarkan kondisi konteks sumber pada kunci sepertiaws:SourceAccount,aws:SourceArn, dll. — lihat AWS kunci kondisi global untuk detail selengkapnya. Izin bersifat bi-directional, yang berarti bahwa semua replika harus secara eksplisit memberikan izin satu sama lain sebelum replikasi dapat dibuat di setiap pasangan 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 ketika ditambahkan ke tabel global multi-akun. Ini memverifikasi bahwa operasi replikasi hanya dilakukan oleh layanan DynamoDB resmi dan hanya di antara tabel yang dimaksud.
Peran terkait layanan 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 dikontrol melalui ReplicateSettings izin pada prinsipal layanan, tetapi kami juga mengandalkan peran terkait layanan (SLRs) untuk mengelola replikasi lintas wilayah dan kemampuan auto-scaling lintas akun tertentu. 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.
Pengaturan manajemen peran terkait layanan
Amazon DynamoDB secara otomatis membuat AWSService RoleForDynamo DBGlobal TableSettingsManagement peran 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 AWSServiceRoleForDynamoDBGlobalTableSettingsManagement ke SLR, karena hal ini dapat mengganggu pengelolaan pengaturan dan dapat mengganggu replikasi jika throughput tidak cocok di seluruh replika atau. GSIs 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 permanen 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. DynamoDB auto scaling menggunakan layanan Application AWS Auto Scaling untuk secara dinamis menyesuaikan kapasitas throughput yang disediakan pada replika tabel global Anda. Layanan Application Auto Scaling membuat peran terkait layanan (SLR) bernama. AWSServiceRoleForApplicationAutoScaling_DynamoDBTable 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 alarm. CloudWatch
Saat menerapkan kebijakan berbasis sumber daya ke replika, verifikasi bahwa Anda tidak menolak izin apa pun yang ditentukan dalam Kebijakan terhadap prinsipal AWSApplicationAutoscalingDynamoDBTableApplication Auto Scaling SLR, karena ini akan mengganggu fungsionalitas auto-scaling.
Bagaimana tabel global menggunakan 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 ARN sumber daya tabel tertentu di Wilayah yang terpengaruh. Sumber daya tabel ARN mengikuti formatarn:aws:dynamodb:region:account-id:table/table-name, di mana Anda perlu menentukan nilai Region, ID akun, dan nama tabel yang sebenarnya.
Berikut ini adalah step-by-step topik 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 diotorisasi oleh semua anggota yang ada. Semua anggota yang ada perlu 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
Penyiapan tabel global multi-akun mengikuti alur otorisasi tertentu 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 (ReplicaA) 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 sambil membuat replika dan mereferensikan tabel sumber ARN yang akan 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.
Untuk membuat pengaturan ini:
-
Administrator Akun A harus terlebih dahulu melampirkan kebijakan berbasis sumber daya ke ReplicaA. Kebijakan ini secara eksplisit memberikan izin yang diperlukan untuk Akun B dan layanan replikasi DynamoDB.
-
Demikian pula, administrator Akun B harus melampirkan kebijakan yang cocok ke ReplicAb, dengan referensi akun dibalik untuk memberikan izin yang sesuai ke Akun A, dalam panggilan buat tabel untuk membuat replika B yang merujuk replika A sebagai tabel sumber.
Dalam pengaturan ini, kami memiliki 3 replika ReplicaA, ReplicAb, dan ReplicaC di Akun A, Akun B, dan Akun C, masing-masing. Replica 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 ReplicaA 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 ReplicaA sebagai sumber. Replika B memiliki kebijakan berikut yang memungkinkan replikasi antara semua anggota, dan memungkinkan Akun C untuk menambahkan replika:
-
Terakhir, administrator Akun C membuat replika dengan kebijakan berikut yang memungkinkan izin replikasi antara semua anggota. Kebijakan ini tidak mengizinkan replika lebih lanjut ditambahkan.
Memperbarui tabel global multi-akun
Untuk mengubah setelan 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 Waktu ke Langsung 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 hingga izin diperbaiki. AccessDeniedException
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 dan 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 mendasari 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 menggunakan AWS KMS
Seperti semua tabel DynamoDB, replika tabel global selalu mengenkripsi data saat istirahat menggunakan kunci enkripsi yang disimpan AWS di 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). Tabel global multi-akun tidak mendukung Kunci AWS Terkelola.
Tabel global multi-akun yang menggunakan CMKs 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 terkelola pelanggan yang digunakan untuk mengenkripsi replika karena Anda menghapus replika, Anda harus terlebih dahulu menghapus replika, menunggu tabel dihapus dari grup replikasi dengan memanggil describe di salah satu replika lainnya, lalu nonaktifkan atau hapus kunci.
Jika Anda menonaktifkan atau mencabut akses DynamoDB ke kunci terkelola 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 status 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 AWS KMS kedua kunci untuk replikasi antara replika A dan B. AWS KMS Kunci yang dilampirkan pada replika DynamoDB di setiap akun perlu diperbarui dengan kebijakan berikut: