Bagikan melalui

Menerapkan komunikasi lintas penyewa dengan menggunakan aplikasi multipenyewa

  • Artikel

Panduan ini menyediakan solusi untuk mencapai komunikasi dua arah yang aman antara layanan yang dihosting dalam langganan Azure yang dikelola penyewa Microsoft Entra yang berbeda.

Mengamankan komunikasi multipenyewa di Azure bisa menjadi tantangan karena keterbatasan yang melekat pada banyak layanan. Anda dapat menghilangkan kebutuhan untuk mengelola kredensial secara langsung dengan menggunakan identitas terkelola Azure untuk mendapatkan token dari ID Microsoft Entra. Namun, identitas terkelola Azure tidak berfungsi di seluruh batas penyewa, dan alternatif umumnya adalah menggunakan rahasia bersama, seperti URL tanda tangan akses bersama. Ingatlah bahwa jika Anda menggunakan rahasia bersama, Anda perlu mendistribusikan dan memutar rahasia dengan aman di seluruh batas penyewa Microsoft Entra.

Salah satu opsi yang menghindari overhead ini adalah membuat aplikasi multipenyewa untuk mewakili identitas beban kerja Anda. Melalui proses persetujuan, Anda dapat membuat identitas beban kerja ini diketahui oleh penyewa eksternal dan pada akhirnya memungkinkannya untuk mengautentikasi layanan di penyewa eksternal.

Artikel ini menyajikan contoh implementasi pola ini yang menggunakan kode sampel.

Pola ini dapat digunakan kembali untuk skenario multipenyewa apa pun yang memiliki berbagai layanan yang perlu berkomunikasi di seluruh batas penyewa Microsoft Entra.

Sistem

Diagram arsitektur komunikasi lintas penyewa.

Unduh file PowerPoint arsitektur ini.

Alur kerja

Alur kerja berikut ini sesuai dengan diagram sebelumnya:

  1. Admin di sisi penyedia membuat pendaftaran aplikasi multipenyewa dan menyiapkan rahasia klien untuk itu.

  2. Admin di sisi pelanggan menyediakan perwakilan layanan di penyewanya. Perwakilan layanan ini didasarkan pada aplikasi multipenyewa yang dibuat penyedia. Anda dapat melakukan langkah ini dengan beberapa cara. Dalam contoh, kami memilih untuk membuat URL untuk diberikan kepada admin penyewa pelanggan, tetapi Anda dapat menggunakan Microsoft Graph API sebagai gantinya.

  3. Pelanggan menerapkan peran kontrol akses berbasis peran (RBAC) ke perwakilan layanan baru ini sehingga diizinkan untuk mengakses Azure Bus Layanan.

  4. Aplikasi fungsi penyedia menggunakan ID klien dan rahasia klien pendaftaran aplikasi untuk mengirim pesan terautentikasi ke antrean Bus Layanan pelanggan.

  5. Aplikasi fungsi pelanggan menggunakan identitas terkelola untuk membaca pesan penyedia dari antrean melalui pemicu Bus Layanan.

  6. Setelah menerima pesan, aplikasi fungsi pelanggan biasanya melakukan beberapa pekerjaan sebelum mengirim pesan status kembali ke penyedia. Dalam hal ini, untuk tujuan demo, aplikasi fungsi segera mengirim pesan status ke penyedia pada antrean terpisah dalam Bus Layanan yang sama.

  7. Aplikasi fungsi ini membaca dari antrean status dari penyewa pelanggan melalui timer yang dipicu Azure Functions.

Detail skenario

Penyedia memiliki beberapa pelanggan. Penyedia dan setiap pelanggan memiliki penyewa ID Microsoft Entra dan sumber daya Azure individual mereka sendiri. Penyedia dan setiap pelanggan membutuhkan metode komunikasi dua arah yang aman sehingga mereka dapat bertukar pesan melalui antrean Bus Layanan. Solusinya harus memiliki kisah identitas yang menarik yang menghindari pengenalan kredensial atau rahasia yang tidak perlu.

Apa yang harus diketahui tentang aplikasi multipenyewa

  • Objek aplikasi adalah instans aplikasi yang unik secara global.

  • Saat aplikasi terdaftar di Microsoft Entra, objek aplikasi dan objek perwakilan layanan secara otomatis dibuat di penyewa.

  • Objek perwakilan layanan dibuat di setiap penyewa yang menggunakan aplikasi dan mereferensikan objek aplikasi. Objek aplikasi memiliki hubungan satu-ke-banyak dengan objek perwakilan layanan yang sesuai.

  • Objek aplikasi adalah representasi global aplikasi Anda dan digunakan di semua penyewa. Objek perwakilan layanan adalah representasi lokal yang digunakan dalam penyewa tertentu.

  • Objek perwakilan layanan harus dibuat di setiap penyewa tempat aplikasi digunakan sehingga dapat menetapkan identitas untuk mengakses sumber daya yang diamankan penyewa. Aplikasi penyewa tunggal hanya memiliki satu objek perwakilan layanan di penyewa rumahnya. Objek perwakilan layanan ini dibuat dan diizinkan untuk digunakan selama pendaftaran aplikasi. Aplikasi multipenyewa juga memiliki objek perwakilan layanan yang dibuat di setiap penyewa, dan pengguna dari penyewa tersebut menyetujui penggunaannya.

  • Untuk mengakses sumber daya yang diamankan oleh penyewa Microsoft Entra, prinsip keamanan harus mewakili entitas yang memerlukan akses.

  • Ketika aplikasi diberikan izin untuk mengakses sumber daya di penyewa setelah pendaftaran atau persetujuan, objek perwakilan layanan dibuat. Arsitektur ini diimplementasikan dengan alur persetujuan.

Bagaimana penyedia mengirim pesan kepada pelanggan?

Idealnya, penyedia dapat menetapkan identitas terkelola ke sumber daya komputasi Azure yang bertanggung jawab untuk mengirim pesan ke antrean pelanggan. Penyewa pelanggan dikonfigurasi untuk mempercayai identitas terkelola dari penyewa penyedia. Namun, federasi sejati antara dua penyewa Microsoft Entra, yang pada dasarnya akan memungkinkan "berbagi" identitas dari satu penyewa ke penyewa lain, saat ini tidak dimungkinkan. Jadi, penyedia perlu mengautentikasi dengan menggunakan identitas yang dikenali pelanggan. Penyedia perlu mengautentikasi ke penyewa Microsoft Entra pelanggan sebagai perwakilan layanan yang diketahui pelanggan.

Kami menyarankan agar penyedia mendaftarkan aplikasi multipenyewa di penyewanya sendiri dan kemudian membuat setiap pelanggan menyediakan perwakilan layanan terkait ke penyewa mereka. Penyedia kemudian dapat mengautentikasi ke penyewa pelanggan dan API yang dihosting pelanggan dengan menggunakan perwakilan layanan ini. Penyedia tidak perlu berbagi rahasia klien dalam pendekatan ini. Manajemen kredensial adalah tanggung jawab satu-satunya penyedia.

Bagaimana pelanggan mengirim pesan kepada penyedia?

Kami menyarankan agar pelanggan membuat atau menghosting antrean tempat penyedia dapat membaca. Pelanggan menulis pesan ke dalam antrean. Penyedia berulang kali melakukan polling setiap antrean pelanggan untuk pesan dengan menggunakan objek perwakilan layanan. Kelemahan dari pendekatan ini adalah memperkenalkan latensi polling ketika penyedia menerima pesan. Kode juga perlu berjalan lebih sering di penyedia karena harus bangun dan melakukan logika polling alih-alih menunggu peristiwa untuk memicunya. Namun, manajemen kredensial tetap menjadi tanggung jawab penyedia satu-satunya, yang memperkuat keamanan.

Solusi lain yang mungkin adalah meminta penyedia membuat atau menghosting antrean untuk setiap pelanggannya. Setiap pelanggan membuat aplikasi multipenyewa mereka sendiri dan meminta penyedia menyediakannya di penyewanya sebagai objek perwakilan layanan. Pelanggan kemudian menggunakan objek perwakilan layanan ini untuk mengirim pesan ke antrean khusus pelanggan di sisi penyedia. Manajemen kredensial tetap menjadi tanggung jawab pelanggan. Salah satu kelemahan dari pendekatan ini adalah penyedia harus menyediakan perwakilan layanan yang terkait dengan aplikasi pelanggan ke dalam penyewanya. Proses ini manual, dan penyedia kemungkinan tidak ingin langkah manual menjadi bagian dari alur untuk onboarding pelanggan baru.

Penyiapan kode sampel

Langkah-langkah berikut memandu Anda melalui proses pengaturan komunikasi lintas penyewa antara penyedia dan pelanggan.

Penyetelan penyedia

Penyiapan penyedia mencakup langkah-langkah untuk menghasilkan dan menyediakan perwakilan layanan aplikasi multipenyewa dan langkah-langkah untuk menyediakan penyewa pelanggan.

  1. Buat aplikasi fungsi yang dipicu HTTP untuk mengirim pesan untuk menulis ke antrean perintah Bus Layanan pelanggan dalam penyewa pelanggan.

  2. Buat aplikasi fungsi yang dipicu waktu untuk memeriksa antrean status secara berkala dalam Bus Layanan pelanggan dalam penyewa pelanggan.

Membuat aplikasi multipenyewa dalam penyewa penyedia

Pertama, buat aplikasi multipenyewa di penyewa penyedia dan provisikan identitas tersebut dalam penyewa pelanggan. Dalam skenario ini, identitas adalah perwakilan layanan. Arsitektur sebelumnya dalam artikel ini menunjukkan kepada Anda cara menyiapkan dan memprovisikan perwakilan layanan dari penyewa penyedia ke penyewa pelanggan. Arsitektur ini juga menguraikan cara memprovisikan dengan beberapa penyewa Microsoft Entra.

  1. Pilih opsi organisasi multipenyewa.

  2. Tambahkan situs web berikut sebagai URI pengalihan: https://entra.microsoft.com. Anda dapat mengubah URI ini agar sesuai dengan kebutuhan bisnis Anda.

  3. Daftar dan catat nilai ID aplikasi (klien).

Membuat rahasia klien baru

  1. Setelah Anda membuat aplikasi multipenyewa, buat rahasia klien untuk perwakilan layanan ini.

  2. Simpan rahasia yang dihasilkan di lokasi yang aman. Rahasia dan ID klien adalah kredensial klien Anda yang diperlukan untuk bertukar kode, dalam alur kode otorisasi, dan untuk token ID di langkah berikutnya.

Azure Functions - Dipicu HTTP

Gunakan fungsi HTTP untuk memulai penyebaran dari penyewa penyedia dengan mengirim pesan ke antrean penyebaran Bus Layanan pelanggan. Kami memilih fungsi yang dipicu HTTP sebagai metode pengiriman untuk memulai bukti konsep ini. Perwakilan layanan yang Anda buat sebelumnya bertindak sebagai kredensial untuk mengakses penyewa pelanggan dan menulis ke antrean tertentu dalam Bus Layanan. Anda juga perlu menyelesaikan penyiapan pelanggan agar langkah ini berfungsi dengan baik.

Azure Functions - Timer-triggered

Gunakan fungsi yang dipicu timer untuk melakukan polling antrean status penyebaran dari dalam penyewa pelanggan. Kami melakukan polling antrean status penyebaran setiap 10 detik untuk tujuan demo dalam bukti konsep ini. Pendekatan ini menghilangkan kebutuhan pelanggan untuk memiliki perwakilan layanan untuk mengakses penyewa penyedia.

Penyiapan pelanggan

  1. Provisikan perwakilan layanan dengan memodifikasi dan menggunakan URL yang disediakan.

  2. Cakupan perwakilan layanan penyedia untuk menggunakan kontrol RBAC yang sesuai.

  3. Buat fungsi yang dipicu Bus Layanan untuk membaca pesan dari antrean pesan Bus Layanan dan menempatkan pesan ke dalam antrean lain. Untuk tujuan demo, alur ini optimal untuk menguji fungsionalitas.

  4. Buat identitas terkelola yang ditetapkan sistem untuk fungsi yang dipicu Bus Layanan.

  5. Tetapkan cakupan Bus Layanan identitas terkelola yang ditetapkan sistem.

Memprovisikan perwakilan layanan dari penyewa penyedia ke penyewa pelanggan

  1. Kunjungi URL berikut setelah mengganti client_id parameter string kueri dengan ID klien Anda sendiri: https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize?response_type=code&response_mode=query&scope=openid&client_id=<your_client_ID>.

    Anda juga dapat menyediakan perwakilan layanan ke penyewa Microsoft Entra lain dengan panggilan API Microsoft Graph admin, perintah Azure PowerShell, atau perintah Azure CLI.

  2. Masuk dengan akun dari penyewa pelanggan.

  3. Pada layar persetujuan, pilih Terima untuk menyediakan aplikasi penyedia di penyewa pelanggan. URL akhirnya mengalihkan ke microsoft.com, yang masih memiliki efek yang diinginkan dari penyediaan identitas ke penyewa pelanggan.

  4. Verifikasi identitas dalam penyewa Microsoft Entra pelanggan dengan masuk ke Aplikasi Perusahaan untuk melihat perwakilan layanan yang baru disediakan.

Menyiapkan RBAC untuk perwakilan layanan yang disediakan

Cakupan perwakilan layanan penyedia dari penyiapan perwakilan layanan penyedia untuk memiliki peran "Bus Layanan Pemilik Data" pada Bus Layanan. Perwakilan layanan ini digunakan dalam penulisan ke antrean dengan fungsi yang dipicu HTTP dan membaca dari antrean dari fungsi yang dipicu timer. Pastikan Anda menambahkan peran "Pemilik Data Bus Layanan Azure" ke perwakilan layanan.

Azure Functions - pemicu Bus Layanan

Ikuti langkah-langkah dalam tutorial fungsi berbasis identitas untuk menentukan pemicu fungsi dari antrean Bus Layanan dan untuk mempelajari cara menyiapkan identitas terkelola. Panduan ini membantu Anda memicu aplikasi fungsi dari antrean Bus Layanan saat pesan ditambahkan ke antrean. Anda juga menggunakan identitas terkelola saat menempatkan pesan ke dalam antrean yang berbeda. Untuk tujuan demo, kami menggunakan fungsi yang sama untuk mendorong pesan.

Di namespace Bus Layanan yang baru dibuat, pilih Kontrol Akses (IAM). Anda dapat melihat dan mengonfigurasi siapa yang memiliki akses ke sumber daya di sarana kontrol.

Memberikan akses aplikasi fungsi ke namespace Bus Layanan dengan menggunakan identitas terkelola

  1. Pastikan Anda menambahkan peran "Azure Bus Layanan Data Receiver" ke identitas terkelola.

  2. Di pemilih identitas terkelola, pilih Aplikasi Fungsi dari kategori identitas terkelola yang ditetapkan sistem. Label Aplikasi Fungsi mungkin memiliki angka dalam tanda kurung di sampingnya. Angka tersebut menunjukkan berapa banyak aplikasi yang memiliki identitas yang ditetapkan sistem dalam langganan.

Terhubung ke Azure Service Bus di aplikasi fungsi

  1. Di portal, cari aplikasi fungsi Anda atau buka di halaman Aplikasi Fungsi.

  2. Di Pengaturan aplikasi, pilih + Baru untuk membuat pengaturan aplikasi baru dalam tabel. Service BusConnection__fullyQualifiedNamespace <SERVICE_BUS_NAMESPACE>.Service Bus.windows.net.

Manajemen siklus hidup rahasia klien perwakilan layanan

Jika Anda memperkenalkan rahasia ke dalam arsitektur lintas penyewa Anda, maka Anda perlu mengelola siklus hidup rahasia klien yang dihasilkan. Lihat Praktik terbaik untuk manajemen rahasia untuk mempelajari cara menyimpan, memutar, dan memantau rahasia klien dengan aman.

Pengaturan Lokal

Setiap subdirektori berisi versi local.settings.json file yang tersendat, yang dapat dimodifikasi untuk menjalankan fungsi Azure secara lokal. Untuk mengonfigurasi pengaturan di Azure, perbarui Pengaturan Aplikasi.

Perintah menghitung DefaultAzureCredential beberapa pengaturan sebelum mencapai kredensial Azure CLI. Untuk menghindari kebingungan, sebaiknya jalankan az login -t <tenant ID> perintah untuk memberikan kredensial yang benar saat Anda mengembangkan fungsi lokal.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Langkah berikutnya