Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Strategi untuk ekspansi global
Survei
Kami akan senang mendengar dari Anda. Harap berikan umpan balik tentang AWS PRA dengan mengikuti survei singkat
AWS
Layanan Jaminan Keamanan
Pertanyaan-pertanyaan berikut adalah umum, dan hanya Anda yang dapat menjawabnya untuk kasus penggunaan Anda:
-
Di mana data pribadi pelanggan saya harus berada?
-
Di mana data pelanggan saya disimpan?
-
Bagaimana dan di mana data pribadi dapat melintasi batas?
-
Apakah akses manusia atau layanan ke data lintas wilayah merupakan transfer?
-
Bagaimana saya bisa yakin bahwa tidak ada pemerintah asing yang mengakses data pribadi pelanggan saya?
-
Di mana saya dapat menyimpan cadangan dan situs panas atau dingin saya?
-
Untuk menjaga data lokal, haruskah saya mempertahankan AWS landing zone di setiap wilayah tempat saya menyediakan layanan? Atau bisakah saya menggunakan AWS Control Tower landing zone yang sudah ada?
Untuk persyaratan residensi data, penerapan arsitektur yang berbeda mungkin bekerja lebih baik untuk organisasi yang berbeda. Beberapa organisasi mungkin memiliki persyaratan bahwa data pribadi pelanggan mereka tetap berada dalam wilayah tertentu. Jika demikian, Anda mungkin khawatir dengan cara mematuhi peraturan secara umum sambil menegakkan kewajiban ini. Apa pun situasinya, ada beberapa pertimbangan saat memilih strategi penyebaran multi-akun.
Untuk menentukan komponen desain arsitektur utama, bekerja sama dengan tim kepatuhan dan kontrak Anda untuk mengonfirmasi persyaratan di mana, kapan, dan bagaimana data pribadi dapat melintas Wilayah AWS. Tentukan apa yang memenuhi syarat sebagai transfer data, seperti memindahkan, menyalin, atau melihat. Selain itu, pahami apakah ada ketahanan khusus dan kontrol perlindungan data yang harus diterapkan. Apakah strategi pencadangan dan pemulihan bencana memerlukan failover lintas wilayah? Jika demikian, tentukan Wilayah mana yang dapat Anda gunakan untuk menyimpan data cadangan Anda. Tentukan apakah ada persyaratan untuk enkripsi data, seperti algoritma enkripsi khusus atau modul keamanan perangkat keras khusus untuk pembuatan kunci. Setelah Anda menyelaraskan dengan pemangku kepentingan kepatuhan pada topik ini, mulailah mempertimbangkan pendekatan desain untuk lingkungan multi-akun Anda.
Berikut ini adalah tiga pendekatan yang dapat Anda gunakan untuk merencanakan strategi AWS multi-akun Anda, dalam urutan pemisahan infrastruktur yang meningkat:
Penting juga untuk diingat bahwa kepatuhan privasi mungkin tidak berhenti hanya pada kedaulatan data. Tinjau sisa panduan ini untuk memahami solusi yang mungkin untuk banyak tantangan lain, seperti manajemen persetujuan, permintaan subjek data, tata kelola data, dan bias AI.
Central landing zone dengan Wilayah terkelola
Jika Anda ingin memperluas secara global tetapi telah membuat arsitektur multi-akun di AWS, biasanya ingin menggunakan landing zone multi-akun (MALZ) yang sama untuk mengelola tambahan. Wilayah AWS Dalam konfigurasi ini, Anda akan terus mengoperasikan layanan infrastruktur seperti logging, pabrik akun, dan administrasi umum dari AWS Control Tower landing zone yang ada, di Wilayah tempat Anda membuatnya.
Untuk beban kerja produksi, Anda dapat mengoperasikan penyebaran Regional dengan memperluas AWS Control Tower landing zone ke Wilayah baru. Dengan melakukan ini, Anda dapat memperluas AWS Control Tower tata kelola ke Wilayah baru. Dengan cara ini, Anda dapat menyimpan penyimpanan data pribadi dalam Wilayah tertentu yang dikelola, data masih berada di akun yang mendapat manfaat dari layanan infrastruktur dan AWS Control Tower tata kelola. Di AWS Organizations, akun yang berisi data pribadi masih digulung di bawah OU Data Pribadi khusus, di mana semua pagar pembatas kedaulatan data diimplementasikan. AWS Control Tower Selain itu, beban kerja khusus Wilayah terkandung dalam akun khusus, daripada membuat akun produksi yang mungkin berisi beban kerja yang sama di beberapa Wilayah.
Penyebaran ini dapat menjadi yang paling hemat biaya, tetapi pertimbangan tambahan diperlukan untuk mengendalikan aliran data pribadi melintasi Akun AWS dan batas-batas Regional. Pertimbangkan hal berikut:
-
Log mungkin berisi data pribadi, sehingga beberapa konfigurasi tambahan mungkin diperlukan untuk memuat atau menyunting bidang sensitif untuk mencegah transfer lintas wilayah selama agregasi. Untuk informasi selengkapnya dan praktik yang direkomendasikan untuk mengontrol agregasi log di seluruh Wilayah, lihat Penyimpanan log terpusat di panduan ini.
-
Akun untuk isolasi VPCs dan arus lalu lintas jaringan dua arah yang sesuai dalam desain. AWS Transit Gateway Anda dapat membatasi lampiran Transit Gateway mana yang diizinkan dan disetujui, dan Anda dapat membatasi siapa atau apa yang dapat mengubah tabel rute VPC.
-
Anda mungkin perlu mencegah anggota tim operasi cloud Anda mengakses data pribadi. Misalnya, log aplikasi yang berisi data transaksi pelanggan dapat dianggap memiliki sensitivitas yang lebih tinggi daripada sumber log lainnya. Persetujuan tambahan dan pagar pembatas teknis mungkin diperlukan, seperti kontrol akses berbasis peran dan kontrol akses berbasis atribut. Selain itu, data mungkin tunduk pada batasan tempat tinggal dalam hal akses. Misalnya, data di satu Wilayah A hanya dapat diakses dari dalam Wilayah tersebut.
Diagram berikut menunjukkan landing zone terpusat dengan penyebaran Regional.
Zona pendaratan regional
Memiliki lebih dari satu MALZ dapat membantu Anda mencapai persyaratan kepatuhan yang lebih ketat dengan sepenuhnya mengisolasi beban kerja yang memproses data pribadi dibandingkan dengan beban kerja non-material. AWS Control Tower agregasi logging terpusat dapat dikonfigurasi secara default dan karenanya disederhanakan. Dengan pendekatan ini, Anda tidak perlu mempertahankan pengecualian untuk logging dengan aliran log terpisah yang memerlukan redaksi. Anda bahkan dapat memiliki tim operasi cloud lokal dan khusus untuk setiap MALZ, yang membatasi akses operator ke residensi lokal.
Banyak organisasi memiliki penyebaran landing zone berbasis AS dan Uni Eropa yang terpisah. Setiap landing zone regional memiliki postur keamanan tunggal dan tata kelola terkait untuk akun di Wilayah. Misalnya, enkripsi data pribadi menggunakan dedicated HSMs mungkin tidak diperlukan dalam beban kerja di satu MALZ, tetapi mungkin diperlukan di MALZ lain.
Meskipun strategi ini dapat disesuaikan untuk memenuhi banyak persyaratan saat ini dan masa depan, penting untuk memahami biaya tambahan dan overhead operasional yang terkait dengan pemeliharaan beberapa MALZs. Untuk informasi lebih lanjut, lihat harga AWS Control Tower
Diagram berikut menunjukkan zona pendaratan terpisah di dua Wilayah.
AWS Awan Berdaulat Eropa
Beberapa organisasi memerlukan pemisahan menyeluruh dari beban kerja mereka yang beroperasi di Wilayah Ekonomi Eropa (EEA) dan beban kerja yang beroperasi di tempat lain. Dalam situasi ini, pertimbangkan AWS European Sovereign Cloud
AWS European Sovereign Cloud secara fisik dan logis terpisah dari yang ada Wilayah AWS, semuanya menawarkan keamanan, ketersediaan, dan kinerja yang sama. Hanya AWS karyawan yang berlokasi di UE yang memiliki kendali atas operasi dan dukungan untuk AWS European Sovereign Cloud. Jika Anda memiliki persyaratan residensi data yang ketat, AWS European Sovereign Cloud menyimpan semua metadata yang Anda buat (seperti peran, izin, label sumber daya, dan konfigurasi yang digunakan untuk dijalankan) di UE. AWS AWS European Sovereign Cloud juga memiliki sistem penagihan dan pengukuran penggunaannya sendiri.
Untuk pendekatan ini, Anda akan menggunakan pola yang sama seperti pada bagian sebelumnya, zona pendaratan Regional. Namun, untuk layanan yang Anda berikan kepada pelanggan Eropa, Anda dapat menggunakan MALZ khusus di AWS European Sovereign Cloud.
