Memodifikasi arsitektur zona arahan Azure untuk memenuhi persyaratan di beberapa lokasi

  • Artikel

Organisasi di banyak industri tunduk pada persyaratan peraturan, termasuk persyaratan residensi data, keamanan data, dan kedaulatan data. Beberapa organisasi perlu mematuhi peraturan yang bertentangan di beberapa lokasi geografis. Dalam hal ini, mereka perlu memodifikasi arsitektur zona pendaratan Azure mereka sesuai dengan semua peraturan yang berlaku.

Misalnya, mungkin ada dua peraturan yang bertentangan, peraturan A dan peraturan B. Peraturan A mungkin memerlukan residensi data di negara atau wilayah A, dan peraturan B mungkin memerlukan residensi data di negara atau wilayah B.

Konflik peraturan tersebut dapat berlaku untuk:

  • Organisasi multinasional, seperti perusahaan multinasional atau organisasi non-pemerintah (LSM), yang harus mematuhi peraturan lokal di negara atau wilayah tempat mereka beroperasi.

  • Vendor perangkat lunak independen (ISV) yang memberikan solusi kepada organisasi di beberapa lokasi, dan solusinya harus mematuhi peraturan lokal di setiap lokasi.

  • ISV yang memberikan solusi bagi organisasi multinasional yang perlu mematuhi peraturan lokal setiap negara atau wilayah tempat mereka beroperasi.

Jika Anda hanya perlu memenuhi satu set persyaratan peraturan, lihat Menyesuaikan arsitektur zona pendaratan Azure untuk memenuhi persyaratan.

Pertimbangan peraturan

Persyaratan peraturan biasanya terkait dengan perlindungan data, residensi data, transfer data, isolasi, atau izin personel. Persyaratan ini dapat bertentangan di antara beberapa lokasi geografis. Misalnya, peraturan Uni Eropa (UE) mungkin memerlukan residensi data di negara Uni Eropa, sementara peraturan Inggris Mungkin memerlukan residensi data di Inggris Raya.

Jika peraturan menyebabkan kontrol kebijakan yang bertentangan, Anda harus menyesuaikan arsitektur zona pendaratan Azure dan penetapan kebijakan yang sesuai. Untuk informasi selengkapnya, lihat bagian dalam artikel ini, Skenario yang memerlukan modifikasi.

Saat beberapa peraturan berlaku, Anda tidak perlu memodifikasi arsitektur zona pendaratan Azure jika:

  • Beberapa peraturan memerlukan penetapan Azure Policy yang identik.

  • Kontrol dalam satu peraturan adalah superset dari peraturan lain. Kontrol superset secara otomatis berlaku untuk kedua peraturan.

  • Kontrol dalam beberapa peraturan tidak tumpang tindih. Saat Anda menerapkan beberapa set kontrol, satu implementasi mencakup semua peraturan. Penugasan Azure Policy bersifat pelengkap.

  • Berbagai peraturan memiliki berbagai jenis implementasi. Dari perspektif peraturan, tidak masalah implementasi mana yang Anda pilih. Misalnya, mungkin ada dua peraturan yang masing-masing memiliki model otorisasi yang berbeda, tetapi kedua model otorisasi dapat diterima. Anda dapat memilih implementasi yang paling sesuai dengan organisasi Anda.

Tip

Anda harus berusaha untuk memiliki penugasan kebijakan dan pengecualian atau pengecualian sebanyak mungkin.

Pertimbangan untuk ISV

Ada tiga model penyebaran untuk ISV.

  • Perangkat lunak sebagai layanan murni (SaaS): ISV menyediakan solusi sebagai layanan.

  • Pelanggan disebarkan: Pelanggan menyebarkan solusi di lingkungan mereka sendiri.

  • SaaS penyebaran ganda: Model ini menggabungkan model yang disebarkan pelanggan dan model SaaS murni.

Dalam model SaaS murni, ISV bertanggung jawab untuk mengelola kepatuhan atas nama pelanggan. ISV harus menunjukkan kepatuhan kepada pelanggan dan berpotensi kepada auditor atau regulator. Jika Anda menggunakan model SaaS, arsitektur Anda mungkin tunduk pada beberapa peraturan yang dapat bertentangan. ISV harus mengelola kepatuhan untuk berbagai peraturan ini. Untuk informasi selengkapnya, lihat bagian dalam artikel ini, Skenario yang memerlukan modifikasi.

Dalam model yang disebarkan pelanggan, pelanggan bertanggung jawab untuk mengelola kepatuhan. Untuk model ini, ISV tidak perlu memodifikasi zona pendaratan. Namun, solusi ini disebarkan di zona pendaratan yang disebarkan pelanggan, termasuk kontrol kebijakan dan kebijakan kustom apa pun.

Tip

ISV dapat menargetkan inisiatif kebijakan pada persyaratan kepatuhan tertentu untuk menguji solusi. Praktik ini dapat membantu meminimalkan kemungkinan konflik dengan kebijakan yang digunakan pelanggan untuk memenuhi persyaratan kepatuhan mereka.

Dalam model SaaS penyebaran ganda, semua pertimbangan untuk model SaaS yang disebarkan pelanggan dan murni berlaku.

Pertimbangan untuk organisasi multinasial

Organisasi multinasial menggunakan berbagai struktur untuk mengatur tata kelola TI mereka.

  • Struktur terdesentralisasi: Fungsi TI diatur secara lokal di setiap lokasi geografis.

  • Struktur terpusat: Fungsi TI diatur dari tempat terpusat, biasanya kantor pusat organisasi.

  • Struktur hibrid: Fungsi TI global disediakan secara terpusat, sementara fungsi TI yang diperlukan hanya secara lokal diatur di setiap lokasi geografis.

Dalam skenario terdesentralisasi, tim IT lokal bertanggung jawab untuk mengelola kepatuhan dan dapat menyesuaikan zona pendaratan mereka.

Dalam skenario terpusat, tim IT pusat bertanggung jawab untuk mengelola kepatuhan dan harus memastikan bahwa solusi memenuhi persyaratan kepatuhan lokal dari semua lokasi geografis tempat organisasi multinasional beroperasi. Persyaratan kepatuhan dari berbagai lokasi geografis dapat bertentangan, dan mungkin perlu untuk memodifikasi zona pendaratan.

Dalam skenario hibrid, pertimbangan untuk skenario terdesentralisasi dan terpusat berlaku. Organisasi terpusat menyediakan solusi yang perlu disebarkan organisasi lokal di lingkungan mereka. Organisasi terpusat juga menguji bahwa solusi tersebut disebarkan di semua zona pendaratan organisasi lokal.

Skenario yang memerlukan modifikasi

Anda mungkin perlu memodifikasi zona pendaratan jika ada kumpulan kebijakan yang bertentangan yang ditetapkan ke berbagai penyebaran. Mungkin ada beberapa solusi atau satu solusi yang perlu disediakan untuk berbagai lokasi geografis atau klasifikasi data.

Jumlah modifikasi yang diperlukan tergantung pada tingkat isolasi yang dipanggil oleh peraturan. Semakin banyak kondisi yang dimiliki peraturan, semakin banyak zona pendaratan yang perlu dimodifikasi. Misalnya, jika peraturan memerlukan kondisi seperti personel yang dibersihkan, berbagai penyedia identitas atau direktori, infrastruktur manajemen terpisah, atau infrastruktur konektivitas terpisah, zona pendaratan memerlukan modifikasi yang luas. Jika peraturan hanya mengharuskan aplikasi dan infrastruktur konektivitas diisolasi, zona pendaratan membutuhkan modifikasi minimal.

Penyewa Microsoft Entra

Sebaiknya gunakan satu penyewa Microsoft Entra untuk sebagian besar skenario, termasuk skenario multinasial. Namun, ada skenario di mana Anda mungkin lebih suka atau memerlukan beberapa penyewa Microsoft Entra, seperti:

  • Jika Anda perlu memisahkan penyewa Microsoft Entra perusahaan dari penyewa SaaS Microsoft Entra untuk meningkatkan keamanan dan membuat batas yang jelas antara produk dan operasi bisnis.

  • Jika peraturan yang bertentangan berlaku, dan Anda memerlukan penyewa Microsoft Entra terpisah untuk rezim peraturan yang berbeda. Misalnya, peraturan mungkin memiliki persyaratan izin dan kewarganegaraan yang memerlukan isolasi lengkap antara penyewa Microsoft Entra atau persyaratan residensi data yang memerlukan penyewa terpisah. Skenario umum termasuk ISV yang perlu menyebarkan instans terisolasi dari solusi SaaS atau organisasi multinasial yang perlu menyebarkan instans terisolasi dari solusi yang sama.

Saat berkolaborasi di beberapa penyewa Microsoft Entra, Anda perlu merencanakan tantangan dan kebutuhan yang signifikan dengan cermat. Buat hanya jumlah minimum penyewa Microsoft Entra yang Anda butuhkan untuk memenuhi persyaratan operasional atau peraturan. Anda dapat menggunakan grup manajemen dan kontrol akses berbasis peran Azure (RBAC) untuk mengatur akses ke langganan dan sumber daya di bawah satu penyewa, seperti yang dijelaskan di bagian berikutnya.

Tip

Penyewa Microsoft Entra yang Anda pilih untuk zona arahan Anda tidak memengaruhi autentikasi tingkat aplikasi Anda. Anda masih dapat menggunakan idP lain terlepas dari penyewa mana yang Anda pilih. Untuk pelanggan dan pelanggan sektor publik dalam industri yang diatur, identitas pengguna akhir biasanya disediakan ketika Anda berintegrasi dengan Penyedia Identitas yang disetujui, seperti IdP milik pemerintah atau bersertifikat.

Diagram berikut ini memperlihatkan opsi yang bisa Anda gunakan untuk menata penyewa Microsoft Entra.

A diagram that shows three ways to organize Microsoft Entra tenants.

Tip

Jika Anda memiliki beberapa penyewa Microsoft Entra untuk memenuhi persyaratan peraturan, beri nama penyewa berdasarkan lokasi geografis daripada peraturan tertentu, misalnya contoso-ops-us.com dalam contoh diagram.

Untuk informasi selengkapnya, lihat Zona pendaratan Azure dan beberapa penyewa Microsoft Entra dan pertimbangan ISV untuk zona pendaratan Azure.

Grup pengelolaan

Jika Anda tidak memerlukan penyewa Microsoft Entra terpisah untuk menyediakan isolasi yang ketat, Anda harus menyebarkan beberapa zona pendaratan Azure dalam satu penyewa Microsoft Entra. Anda dapat menyesuaikan hierarki grup manajemen untuk memenuhi persyaratan peraturan yang bertentangan.

Anda dapat menyebarkan arsitektur zona pendaratan penuh untuk setiap set peraturan yang ingin Anda pisahkan. Model ini memerlukan jumlah penyesuaian paling sedikit dan memungkinkan Anda memanfaatkan otomatisasi yang ada untuk penyebaran.

A diagram that shows separate landing zones for each regulation.

Catatan

Diagram ini tidak menampilkan semua grup manajemen.

Berbagi grup manajemen platform

Jika regulasi memungkinkan, grup manajemen platform dapat dibagikan. Anda dapat membuat grup manajemen terpisah di bawah grup manajemen zona pendaratan untuk setiap set peraturan yang perlu dipisahkan. Anda dapat menetapkan kebijakan yang sesuai untuk setiap grup manajemen aplikasi. Zona pendaratan aplikasi berbagi grup manajemen yang berada di bawah grup manajemen platform. Sumber daya dalam grup manajemen aplikasi juga dapat dipisahkan oleh langganan atau grup sumber daya.

Hierarki grup manajemen ini adalah desain sederhana dan hemat biaya untuk mengisolasi aplikasi dengan peraturan yang bertentangan. Namun, dalam desain ini, grup manajemen platform untuk konektivitas, identitas/keamanan, dan manajemen harus berbagi kumpulan kebijakan yang sama. Anda mungkin memerlukan set kebijakan yang berbeda untuk setiap grup manajemen platform jika peraturan memberlakukan pembatasan pada berbagi infrastruktur konektivitas, layanan identitas, layanan manajemen utama, atau infrastruktur tempat seluruh lingkungan dikelola.

A diagram that shows an architecture that shares the platform management group.

Mengisolasi identitas dan keamanan

Jika peraturan mencegah Anda berbagi infrastruktur manajemen identitas dan kunci, Anda dapat membagi grup manajemen platform. Pertahankan grup manajemen untuk konektivitas dan manajemen di grup manajemen platform bersama dan memiliki grup manajemen identitas dan keamanan yang terkait dengan setiap set peraturan.

Hierarki grup manajemen ini secara signifikan lebih kompleks daripada grup manajemen platform yang dibagikan sepenuhnya karena Anda harus mereplikasi sebagian grup manajemen platform. Untuk membatasi kompleksitas, Anda dapat menyebarkan hierarki lengkap untuk setiap set peraturan dan lingkungan bersama, dan mengabaikan atau menghapus grup manajemen yang berlebihan.

A diagram that shows an architecture that isolates identity and security.

Mengisolasi konektivitas

Banyak peraturan memiliki persyaratan yang terkait dengan pemrosesan dan penyimpanan data di lokasi geografis tertentu, dengan beberapa persyaratan tentang bagaimana pengguna terhubung ke aplikasi. Untuk peraturan tersebut, Anda dapat berbagi manajemen konektivitas seperti yang ditunjukkan pada arsitektur sebelumnya. Mungkin tidak ada peraturan yang mengharuskan Anda untuk menduplikasi infrastruktur di beberapa wilayah, tetapi Anda mungkin perlu untuk tujuan latensi. Kebijakan yang ditetapkan perlu mendukung infrastruktur duplikat di beberapa wilayah.

Ketika peraturan memiliki persyaratan konektivitas yang bertentangan, Anda dapat membuat grup manajemen konektivitas yang terkait dengan setiap set peraturan. Struktur ini mirip dengan arsitektur sebelumnya yang mengaitkan grup manajemen identitas dan keamanan dengan setiap set peraturan.

Jika peraturan bertentangan dengan konektivitas dan juga identitas dan keamanan, Anda dapat menggunakan desain berikut.

A diagram that shows an architecture that isolates connectivity.

Langkah berikutnya