Edit

Bagikan melalui

Memetakan permintaan ke penyewa dalam solusi multipenyewa

Azure

Setiap kali permintaan masuk ke aplikasi Anda, Anda perlu menentukan penyewa yang permintaannya dimaksudkan. Bila Anda memiliki infrastruktur khusus penyewa yang bahkan dapat dihosting di wilayah geografis yang berbeda, Anda harus mencocokkan permintaan masuk ke penyewa. Kemudian, Anda harus meneruskan permintaan ke infrastruktur fisik yang menjadi tuan rumah sumber daya penyewa itu, seperti yang diilustrasikan di bawah ini:

Diagram showing mapping a request from tenants to deployments.

Pada halaman ini, kami memberikan panduan bagi pembuat keputusan teknis tentang pendekatan yang dapat Anda pertimbangkan untuk memetakan permintaan kepada penyewa yang sesuai, dan pertukaran yang terlibat dalam pendekatan.

Catatan

Halaman ini sebagian besar membahas aplikasi berbasis HTTP, seperti situs web dan API. Namun, banyak prinsip sama yang mendasari berlaku untuk aplikasi multitenant yang menggunakan protokol komunikasi lainnya.

Pendekatan untuk mengidentifikasi penyewa

Ada beberapa cara Anda dapat mengidentifikasi penyewa untuk permintaan masuk.

Nama domain

Jika Anda menggunakan nama domain atau subdomain khusus-penyewa, kemungkinan permintaan dapat dengan mudah dipetakan ke penyewa dengan menggunakan Host header, atau header HTTP lain yang menyertakan nama host asli untuk setiap permintaan.

Bagaimanapun, pertimbangkan pertanyaan-pertanyaan berikut:

  • Bagaimana pengguna akan tahu nama domain mana yang akan digunakan untuk mengakses layanan?
  • Apakah Anda memiliki titik masuk pusat, seperti halaman landing atau halaman login, yang digunakan semua penyewa? Jika Anda melakukannya, bagaimana pengguna akan mengidentifikasi penyewa yang perlu mereka akses?
  • Informasi lain apa yang Anda gunakan untuk memverifikasi akses ke penyewa, seperti token otorisasi? Apakah token otorisasi menyertakan nama domain khusus-penyewa?

Properti permintaan HTTP

Jika Anda tidak menggunakan nama domain khusus penyewa, Anda mungkin masih dapat menggunakan aspek permintaan HTTP untuk mengidentifikasi penyewa yang untuk permintaan tertentu ditujukan. Misalnya, pertimbangkan permintaan HTTP yang mengidentifikasi nama penyewa sebagai tailwindtraders. Ini dapat dikomunikasikan menggunakan hal-hal berikut:

  • Struktur jalur URL, seperti https://app.contoso.com/tailwindtraders/.
  • String kueri di URL, seperti https://contoso.com/app?tenant=tailwindtraders.
  • Header permintaan HTTP kustom, seperti X-Tenant-Id: tailwindtraders.

Penting

Header permintaan HTTP kustom tidak berguna di mana permintaan HTTP GET dikeluarkan dari browser web, atau di mana permintaan ditangani oleh beberapa jenis proxy web. Anda hanya boleh menggunakan header HTTP kustom untuk operasi GET saat anda sedang membangun API, atau jika anda mengontrol klien yang mengeluarkan permintaan dan tidak ada proxy web yang termasuk dalam rantai pemrosesan permintaan.

Saat menggunakan pendekatan ini, Anda harus mempertimbangkan pertanyaan-pertanyaan berikut:

  • Apakah pengguna akan tahu cara mengakses layanan? Misalnya, jika Anda menggunakan string kueri untuk mengidentifikasi penyewa, apakah halaman landing pusat perlu mengarahkan pengguna ke penyewa yang tepat, dengan menambahkan string kueri?
  • Apakah Anda memiliki titik masuk pusat, seperti halaman landing atau halaman login, yang digunakan semua penyewa? Jika Anda melakukannya, bagaimana pengguna akan mengidentifikasi penyewa yang perlu mereka akses?
  • Apakah aplikasi Anda menyediakan API? Misalnya, apakah aplikasi web Anda adalah aplikasi satu-halaman (SPA) atau aplikasi seluler dengan backend API? Jika demikian, Anda mungkin dapat menggunakan API gateway atau reverse proxy untuk melakukan pemetaan penyewa.

Klaim token

Banyak aplikasi menggunakan protokol autentikasi dan otorisasi berbasis klaim, seperti OAuth 2.0 atau SAML. Protokol ini memberikan token otorisasi kepada klien. Token berisi serangkaian klaim, yang merupakan bagian-bagian informasi tentang aplikasi atau pengguna klien. Klaim dapat digunakan untuk mengomunikasikan informasi seperti alamat email pengguna. Sistem Anda kemudian dapat menyertakan alamat email pengguna, mencari pemetaan pengguna-ke-penyewa, lalu meneruskan permintaan ke penyebaran yang sesuai. Atau, Anda bahkan dapat menyertakan pemetaan penyewa dalam sistem identitas Anda, dan menambahkan klaim ID penyewa ke token.

Jika Anda menggunakan klaim untuk memetakan permintaan kepada penyewa, Anda harus mempertimbangkan pertanyaan-pertanyaan berikut:

  • Apakah Anda akan menggunakan klaim untuk mengidentifikasi penyewa? Klaim apa yang akan Anda gunakan?
  • Bisakah pengguna menjadi anggota dari beberapa penyewa? Jika memungkinkan, lalu bagaimana pengguna akan memilih penyewa yang ingin mereka ajak bekerja sama?
  • Apakah ada sistem autentikasi dan otorisasi pusat untuk semua penyewa? Jika tidak, bagaimana Anda akan memastikan bahwa semua otoritas token mengeluarkan token dan klaim yang konsisten?

Kunci API

Banyak aplikasi mengekspos API. Ini mungkin untuk penggunaan internal dalam organisasi Anda, atau untuk penggunaan eksternal oleh mitra atau pelanggan. Metode autentikasi umum untuk API adalah dengan menggunakan kunci API. Kunci API disediakan dengan masing-masing permintaan, dan mereka dapat digunakan untuk mencari penyewa.

Kunci API dapat dihasilkan dengan beberapa cara. Pendekatan umum adalah menghasilkan nilai acak secara kriptografis dan menyimpannya dalam tabel pencarian, di samping ID penyewa. Ketika permintaan diterima, sistem Anda menemukan kunci API di tabel pencarian, dan kemudian mencocokkannya dengan ID penyewa. Pendekatan lain adalah membuat string yang bermakna dengan ID penyewa yang disertakan di dalamnya, dan kemudian Anda akan menandatangani kunci secara digital, dengan menggunakan pendekatan seperti HMAC. Saat memproses setiap permintaan, Anda memverifikasi tanda tangan lalu mengekstrak ID penyewa.

Catatan

Kunci API tidak memberikan tingkat keamanan yang tinggi karena perlu dibuat dan dikelola secara manual, dan karena mereka tidak berisi klaim. Pendekatan yang lebih modern dan aman adalah menggunakan mekanisme otorisasi berbasis klaim dengan token berumur pendek, seperti OAuth 2.0 atau OpenID Connect.

Pertimbangkan pertanyaan-pertanyaan berikut:

  • Bagaimana Anda akan membuat dan mengeluarkan kunci API?
  • Bagaimana klien API Anda akan menerima dan menyimpan kunci API dengan aman?
  • Apakah Anda memerlukan kunci API anda menjadi kedaluwarsa setelah jangka waktu tertentu? Bagaimana Anda akan memutar kunci API klien Anda, tanpa menyebabkan downtime?
  • Apakah hanya mengandalkan kunci API customer-rolled memberikan tingkat keamanan yang memadai untuk API Anda?

Catatan

Kunci API tidak sama dengan kata sandi. Kunci API harus dihasilkan oleh sistem, dan mereka harus unik pada semua penyewa, sehingga setiap kunci API dapat dipetakan secara unik ke satu penyewa. API gateway, seperti Azure API Management, dapat membuat dan mengelola kunci API, memvalidasi kunci pada permintaan masuk, dan memetakan kunci ke pelanggan API individual.

Sertifikat klien

Autentikasi sertifikat klien, kadang-kadang disebut mutual TLS (mTLS), umumnya digunakan untuk komunikasi layanan-ke-layanan. Sertifikat klien menyediakan cara yang aman untuk mengautentikasi klien. Demikian pula dengan token dan klaim, sertifikat klien menyediakan atribut yang dapat digunakan untuk menentukan penyewa. Misalnya, subjek sertifikat mungkin berisi alamat email pengguna, yang dapat digunakan untuk mencari penyewa.

Ketika berencana untuk menggunakan sertifikat klien untuk pemetaan penyewa, pertimbangkan hal-hal berikut:

  • Bagaimana Anda akan menerbitkan dan memperbarui sertifikat klien dengan aman yang dipercaya oleh layanan Anda? Sertifikat klien bisa rumit untuk dikerjakan, karena mereka membutuhkan infrastruktur khusus untuk mengelola dan mengeluarkan sertifikat.
  • Apakah sertifikat klien hanya akan digunakan untuk permintaan login awal, atau dilampirkan ke semua permintaan ke layanan Anda?
  • Akankah proses penerbitan dan pengelolaan sertifikat menjadi tidak terkelola ketika Anda memiliki sejumlah besar klien?
  • Bagaimana Anda akan menerapkan pemetaan antara sertifikat klien dan penyewa?

Proksi Terbalik

Proksi terbalik, juga disebut sebagai proksi aplikasi, dapat digunakan untuk merutekan permintaan HTTP. Proksi terbalik menerima permintaan dari titik akhir ingress, dan dapat meneruskan permintaan ke salah satu dari banyak titik akhir backend. Proksi terbalik berguna untuk aplikasi multipenyewa karena mereka dapat melakukan pemetaan antara beberapa bagian informasi permintaan, membongkar tugas dari infrastruktur aplikasi Anda.

Banyak proksi terbalik dapat menggunakan properti permintaan untuk membuat keputusan tentang perutean penyewa. Mereka dapat memeriksa nama domain tujuan, jalur URL, string kueri, header HTTP, dan bahkan klaim dalam token.

Proksi terbalik umum berikut digunakan di Azure:

  • Azure Front Door adalah penyeimbang beban global dan Web Application Firewall. Front Door menggunakan jaringan edge global Microsoft untuk membuat aplikasi web yang cepat, aman, dan dapat diskalakan secara luas.
  • Azure Application Gateway adalah penyeimbang beban lalu lintas web terkelola yang Anda terapkan ke wilayah fisik yang sama dengan layanan backend Anda.
  • Azure API Management dioptimalkan untuk lalu lintas API.
  • Teknologi komersial dan open-source (yang Anda host sendiri) termasuk nginx, Traefik, dan HAProxy.

Minta validasi

Penting bahwa aplikasi Anda memvalidasi yang setiap permintaan yang diterimanya diotorisasi untuk penyewa. Misalnya, jika aplikasi Anda menggunakan nama domain kustom untuk memetakan permintaan ke penyewa, maka aplikasi Anda masih harus memeriksa apakah setiap permintaan yang diterima oleh aplikasi diotorisasi untuk penyewa tersebut. Meskipun permintaan tersebut menyertakan nama domain atau pengenal penyewa lainnya, itu tidak berarti Anda harus secara otomatis memberikan akses. Ketika Anda menggunakan OAuth 2.0, Anda melakukan validasi dengan memeriksa klaim audiens dan cakupan.

Catatan

Ini adalah bagian dari prinsip desain keamanan assume zero trust dalam Kerangka kerja Microsoft Azure Well-Architected.

Saat menerapkan validasi permintaan, Anda harus mempertimbangkan hal-hal berikut:

  • Bagaimana Anda akan mengotorisasi semua permintaan ke aplikasi Anda? Anda perlu mengotorisasi permintaan, terlepas dari pendekatan yang Anda gunakan untuk memetakannya ke infrastruktur fisik.
  • Gunakan kerangka kerja autentikasi dan otorisasi dan middleware tepercaya, digunakan secara luas, dan dikelola dengan baik, alih-alih mengimplementasikan semua logika validasi sendiri. Misalnya, jangan membuat logika validasi tanda tangan token atau pustaka kriptografi sertifikat klien. Sebagai gantinya, gunakan fitur platform aplikasi Anda (atau paket tepercaya yang dikenal) yang telah divalidasi dan diuji.

Performa

Logika pemetaan penyewa kemungkinan berjalan pada setiap permintaan ke aplikasi Anda. Pertimbangkan seberapa baik proses pemetaan penyewa akan diskalakan, seiring pertumbuhan solusi Anda. Misalnya, jika Anda meminta tabel database sebagai bagian dari pemetaan penyewa Anda, apakah database akan mendukung sejumlah besar beban? Jika pemetaan penyewa Anda memerlukan dekripsi token, apakah persyaratan perhitungan akan menjadi terlalu tinggi dari waktu ke waktu? Jika lalu lintas Anda cukup sederhana, maka ini mungkin tidak mempengaruhi kinerja Anda secara keseluruhan. Namun, ketika Anda memiliki aplikasi skala-tinggi, overhead yang terlibat dalam pemetaan ini dapat menjadi signifikan.

Afinitas Sesi

Satu pendekatan untuk mengurangi overhead kinerja logika pemetaan penyewa adalah dengan menggunakan afinitas sesi. Alih-alih melakukan pemetaan pada setiap permintaan, pertimbangkan untuk mengkomputasi informasi hanya pada permintaan pertama untuk setiap sesi. Aplikasi Anda kemudian menyediakan cookie sesi kepada klien. Klien meneruskan cookie sesi kembali ke layanan Anda dengan semua permintaan klien berikutnya dalam sesi tersebut.

Catatan

Banyak layanan jaringan dan aplikasi di Azure dapat mengeluarkan cookie sesi dan langsung mengarahkan permintaan dengan menggunakan afinitas sesi.

Pertimbangkan pertanyaan-pertanyaan berikut:

  • Dapatkah Anda menggunakan afinitas sesi untuk mengurangi overhead pada permintaan pemetaan ke penyewa?
  • Layanan apa yang Anda gunakan untuk merutekan permintaan ke penerapan fisik untuk setiap penyewa? Apakah layanan ini mendukung afinitas sesi berbasis cookie?

Migrasi penyewa

Penyewa sering perlu dipindahkan ke infrastruktur baru sebagai bagian dari siklus hidup penyewa. Saat penyewa dipindahkan ke penerapan baru, titik akhir HTTP yang mereka akses mungkin berubah. Ketika ini terjadi, pertimbangkan bahwa proses pemetaan-penyewa Anda perlu diperbarui. Anda mungkin perlu mempertimbangkan hal berikut ini:

  • Jika aplikasi Anda menggunakan nama domain untuk permintaan pemetaan, maka itu mungkin juga memerlukan perubahan DNS pada saat migrasi. Perubahan DNS mungkin memerlukan waktu untuk menyebar ke klien, bergantung pada waktu untuk hidup dari entri DNS dalam layanan DNS Anda.
  • Jika migrasi Anda mengubah alamat titik akhir apa pun selama proses migrasi, maka pertimbangkan untuk mengalihkan sementara permintaan untuk penyewa ke halaman pemeliharaan yang secara otomatis diperbarui.

Kontributor

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

Penulis utama:

Kontributor lain:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Pelajari tentang pertimbangan saat Anda bekerja dengan nama domain dalam aplikasi multipenyewa.