Pertimbangan saat menggunakan nama domain dalam solusi multi-penyewa

Di banyak aplikasi web multipenyewa, nama domain dapat digunakan sebagai cara untuk mengidentifikasi penyewa, untuk membantu merutekan permintaan ke infrastruktur yang benar, dan untuk memberikan pengalaman bermerek kepada pelanggan Anda. Dua pendekatan umum adalah menggunakan subdomain dan nama domain kustom. Di halaman ini, kami memberikan panduan bagi para pembuat keputusan teknis tentang pendekatan yang dapat dipertimbangkan beserta konsekuensinya.

Subdomain

Setiap penyewa mungkin mendapatkan subdomain unik di bawah nama domain bersama umum, menggunakan format seperti tenant.provider.com.

Mari kita pertimbangkan contoh solusi multi-penyewaan yang dibangun oleh Contoso. Pelanggan membeli produk Contoso untuk memudahkan pengelolaan pembuatan faktur. Semua penyewa Contoso mungkin diberi subdomain sendiri, dengan nama domain contoso.com. Atau, jika Contoso menggunakan penyebaran regional, mereka mungkin menetapkan subdomain di us.contoso.com bawah domain dan eu.contoso.com . Dalam artikel ini, kami menyebutnya domain batang. Setiap pelanggan mendapatkan subdomain sendiri dengan domain batang Anda. Misalnya, Tailwind Toys mungkin diberi tailwind.contoso.com, dan Adventure Works mungkin diberi adventureworks.contoso.com.

Mengelola namespace layanan domain Anda

Saat membuat subdomain dengan nama domain Anda sendiri, perhatikan bahwa Anda bisa memiliki banyak pelanggan dengan nama yang sama. Karena mereka berbagi domain batang tunggal, pelanggan pertama yang mendapatkan domain tertentu akan mendapatkan nama pilihan mereka. Kemudian, pelanggan berikutnya harus menggunakan nama subdomain alternatif, karena nama domain lengkap harus unik secara global.

DNS Kartu Bebas

Pertimbangkan untuk menggunakan entri DNS karakter kartubebas untuk menyederhanakan pengelolaan subdomain. Daripada membuat entri DNS untuk tailwind.contoso.com, adventureworks.contoso.comdan sebagainya, Anda bisa dapat membuat entri karakter kartubebas untuk *.contoso.com dan mengarahkan semua subdomain ke alamat IP tunggal (data A) atau nama kanonik (data CNAME).

Subdomain dengan domain batang multi-bagian

Banyak solusi multi-penyewa tersebar di beberapa penyebaran fisik. Ini adalah pendekatan umum ketika Anda perlu mematuhi persyaratan residensi data, atau ketika Anda ingin memberikan performa yang lebih baik dengan menyebarkan sumber daya secara geografis lebih dekat dengan pengguna.

Bahkan dalam satu wilayah, Anda mungkin juga perlu menyebarkan penyewa Anda di seluruh penyebaran independen, untuk mendukung strategi penskalakan Anda. Jika berencana untuk menggunakan subdomain untuk setiap penyewa, Anda dapat mempertimbangkan struktur subdomain multi-bagian.

Berikut contohnya: Contoso menerbitkan aplikasi multi-penyewa untuk keempat pelanggannya. Adventure Works dan Tailwind Traders berada di Amerika Serikat, dan datanya disimpan di instans bersama platform Contoso di AS. Fabrikam dan Worldwide Importers berada di Eropa, dan datanya disimpan di instans Eropa.

Jika Contoso memilih untuk menggunakan domain batang tunggal, contoso.com, untuk semua pelanggannya, mungkin akan terlihat seperti ini:

Entri DNS (yang diperlukan untuk mendukung konfigurasi ini) mungkin terlihat seperti ini:

Setiap pelanggan baru yang diorientasikan membutuhkan subdomain baru, dan jumlah subdomain tumbuh dengan setiap pelanggan.

Atau, Contoso dapat menggunakan domain batang khusus penyebaran atau wilayah, seperti ini:

Kemudian, dengan menggunakan DNS kartubebas, entri DNS untuk penyebaran ini mungkin terlihat seperti ini:

Contoso tidak perlu membuat catatan subdomain untuk setiap pelanggan. Sebaliknya, mereka memiliki satu catatan DNS kartubebas untuk setiap penyebaran geografi, dan setiap pelanggan baru yang ditambahkan di bawah batang tersebut secara otomatis mewarisi data CNAME.

Ada kelebihan dan kekurangan untuk setiap pendekatan. Saat menggunakan domain batang tunggal, setiap penyewa yang Anda orientasikan memerlukan data DNS baru yang akan dibuat, yang menimbulkan lebih banyak biaya operasional. Namun, Anda memiliki lebih banyak fleksibilitas untuk memindahkan penyewa antar penyebaran, karena Anda dapat mengubah data CNAME untuk mengarahkan lalu lintas mereka ke penyebaran lain. Perubahan ini tidak akan memengaruhi penyewa lain. Saat menggunakan beberapa domain batang, ada overhead manajemen yang lebih rendah. Selain itu, Anda dapat menggunakan kembali nama pelanggan di beberapa domain batang regional, karena setiap domain batang secara efektif mewakili namespace layanannya sendiri.

Nama domain kustom

Anda mungkin ingin meminta pelanggan Anda menggunakan nama domain mereka sendiri. Beberapa pelanggan menganggapnya sebagai aspek penting dari branding. Nama domain kustom mungkin juga diperlukan untuk memenuhi persyaratan keamanan pelanggan, terutama jika mereka perlu menyediakan sertifikat TLS mereka sendiri. Meskipun mungkin tampak sepele mengizinkan pelanggan menggunakan nama domain mereka sendiri, ada beberapa kompleksitas tersembunyi untuk pendekatan ini, dan ini membutuhkan pertimbangan yang matang.

Resolusi Nama

Pada akhirnya, setiap nama domain perlu diselesaikan ke alamat IP. Seperti yang telah Anda lihat, pendekatan di mana resolusi nama terjadi dapat bergantung pada apakah Anda menyebarkan satu instans atau beberapa instans solusi Anda.

Mari kita kembali ke contoh. Salah satu pelanggan Contoso, Fabrikam, telah meminta untuk menggunakan invoices.fabrikam.com, sebagai nama domain kustom mereka untuk mengakses layanan Contoso. Karena Contoso memiliki beberapa penyebaran platform mereka, mereka memutuskan untuk menggunakan subdomain dan catatan CNAME untuk mencapai persyaratan perutean mereka. Contoso dan Fabrikam mengonfigurasi data DNS berikut:

Dari perspektif resolusi nama, rantai rekaman ini secara akurat menyelesaikan permintaan invoices.fabrikam.com ke alamat IP penyebaran Eropa Contoso.

Resolusi header host

Resolusi nama hanya setengah dari masalah. Semua komponen web dalam penyebaran Eropa Contoso perlu mengetahui cara menangani permintaan yang tiba dengan nama domain Fabrikam di header permintaan mereka Host . Bergantung pada teknologi web tertentu yang digunakan Contoso, ini mungkin memerlukan konfigurasi lebih lanjut untuk setiap nama domain penyewa, yang menambahkan overhead operasional ekstra ke onboarding penyewa.

Anda juga dapat mempertimbangkan untuk menulis ulang header host, sehingga terlepas dari header Host permintaan yang masuk, server web Anda melihat nilai header yang konsisten. Misalnya, Azure Front Door memungkinkan Anda menulis ulang header Host, sehingga terlepas dari permintaan, server aplikasi Anda menerima satu header Host. Azure Front Door menyebarkan header host asli di X-Forwarded-Host header , sehingga aplikasi Anda dapat memeriksanya lalu mencari penyewa. Namun, menulis Host ulang header dapat menyebabkan masalah lain. Untuk informasi selengkapnya, lihat Preservasi nama host.

Validasi domain

Kepemilikan domain kustom harus divalidasi sebelum mengorientasikannya. Jika tidak, Anda mempertaruhkan pelanggan secara tidak sengaja atau secara jahat memarkir nama domain.

Mari pertimbangkan proses onboarding Contoso untuk Adventure Works, yang meminta menggunakan invoices.adventureworks.com sebagai nama domain kustomnya. Sayangnya, seseorang membuat kesalahan ketik saat mereka mencoba mengorientasikan nama domain kustom, dan mereka melewatkan s. Jadi, mereka menyiapkannya sebagai invoices.adventurework.com. Lalu lintas tidak hanya mengalir dengan benar untuk Adventure Works, tetapi ketika perusahaan lain bernama Adventure Work mencoba menambahkan domain kustom mereka ke platform Contoso, mereka diberi tahu nama domain sudah digunakan.

Saat bekerja dengan domain kustom, terutama dalam layanan mandiri atau proses otomatis, langkah verifikasi domain sudah lazim diwajibkan. Hal ini mungkin mengharuskan data CNAME disiapkan sebelum domain dapat ditambahkan. Sebagai alternatif, Contoso mungkin menghasilkan string acak dan meminta Adventure Works menambahkan data TXT DNS dengan nilai string. Hal ini akan mencegah nama domain ditambahkan, hingga verifikasi selesai.

Serangan pengambilalihan subdomain dan DNS menggantung

Saat bekerja dengan nama domain kustom, Anda berpotensi rentan terhadap kelas serangan yang disebut DNS menggantung atau pengambilalihan subdomain. Serangan ini terjadi saat pelanggan memisahkan nama domain kustom mereka dari layanan Anda, tetapi mereka tidak menghapus data dari server DNS mereka. Entri DNS ini kemudian menunjuk ke sumber daya yang tidak ada dan rentan terhadap pengambilalihan.

Mari kita pertimbangkan bagaimana hubungan Fabrikam dengan Contoso dapat berubah:

1. Fabrikam telah memutuskan untuk tidak lagi bekerja dengan Contoso, sehingga mereka telah mengakhiri hubungan bisnis.
2. Contoso telah mengeluarkan penyewa Fabrikam, dan mereka meminta fabrikam.contoso.com untuk tidak bekerja lagi. Namun, Fabrikam lupa menghapus data CNAME untuk invoices.fabrikam.com.
3. Aktor jahat membuat akun Contoso baru dan memberinya nama fabrikam.
4. Penyerang mengorientasikan nama domain kustom invoices.fabrikam.com ke penyewa baru mereka. Karena Contoso melakukan validasi domain berbasis CNAME, mereka memeriksa server DNS Fabrikam. Mereka melihat bahwa server DNS menampilkan data CNAME untuk invoices.fabrikam.com, yang mengarah ke fabrikam.contoso.com. Contoso menganggap validasi domain kustom berhasil.
5. Jika ada karyawan Fabrikam yang mencoba mengakses situs, permintaan seakan-akan berfungsi. Jika penyerang menyiapkan penyewa Contoso dengan branding Fabrikam, karyawan mungkin tertipu untuk mengakses situs dan memberikan data sensitif, yang kemudian dapat diakses oleh penyerang.

Strategi umum untuk melindungi dari serangan DNS yang menggantai adalah:

• Mengharuskan data CNAME dihapus sebelum nama domain dapat dihapus dari akun penyewa.
• Melarang penggunaan kembali pengidentifikasi penyewa, dan juga mengharuskan penyewa membuat catatan TXT dengan nama yang cocok dengan nama domain dan nilai yang dihasilkan secara acak, yang berubah untuk setiap upaya onboarding.

Sertifikat TLS/SSL

Keamanan Lapisan Transportasi (TLS) adalah komponen penting saat bekerja dengan aplikasi modern. Ini memberikan kepercayaan dan keamanan untuk aplikasi web Anda. Kepemilikan dan manajemen sertifikat TLS adalah sesuatu yang membutuhkan pertimbangan cermat untuk aplikasi multipenyewa.

Biasanya, pemilik nama domain akan bertanggung jawab untuk mengeluarkan dan memperbarui sertifikatnya. Misalnya, Contoso bertanggung jawab untuk menerbitkan dan memperbarui sertifikat TLS untuk us.contoso.com, serta sertifikat karakter kartubebas untuk *.contoso.com. Sama halnya, Fabrikam umumnya akan bertanggung jawab untuk mengelola data apa pun untuk domain fabrikam.com, termasuk invoices.fabrikam.com. Jenis catatan DNS CAA (Otorisasi Otoritas Sertifikat) dapat digunakan oleh pemilik domain. Catatan CAA memastikan bahwa hanya otoritas tertentu yang dapat membuat sertifikat untuk domain.

Jika Anda berencana mengizinkan pelanggan menggunakan domain-nya sendiri, pertimbangkan apakah Anda berencana mengeluarkan sertifikat atas nama pelanggan, atau apakah pelanggan harus menggunakan sertifikatnya sendiri. Setiap opsi memiliki kelebihan dan kekurangan.

• Jika menerbitkan sertifikat untuk pelanggan, Anda dapat menangani pembaruan sertifikat, sehingga pelanggan tidak perlu mengingat untuk memperbaruinya. Namun, jika pelanggan memiliki catatan CAA pada nama domain mereka, mereka mungkin perlu memberi wewenang kepada Anda untuk menerbitkan sertifikat atas nama mereka.
• Jika Anda mengharapkan pelanggan harus menerbitkan dan memberi Anda sertifikatnya sendiri, Anda bertanggung jawab untuk menerima dan mengelola kunci privat dengan cara yang aman, dan Anda mungkin harus mengingatkan pelanggan untuk memperbarui sertifikat sebelum kedaluwarsa, agar layanan mereka tidak terganggu.

Beberapa layanan Azure mendukung pengelolaan sertifikat otomatis untuk domain kustom. Misalnya, Azure Front Door dan App Service menyediakan sertifikat untuk domain kustom, dan mereka secara otomatis menangani proses perpanjangan. Tindakan ini akan menghilangkan beban pengelolaan sertifikat, dari tim operasi Anda. Namun, Anda masih perlu mempertimbangkan pertanyaan kepemilikan dan otoritas, seperti apakah data CAA berlaku dan dikonfigurasi dengan benar. Selain itu, Anda perlu memastikan bahwa domain pelanggan dikonfigurasi untuk mengizinkan sertifikat yang dikelola oleh platform.

Kontributor

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

Penulis utama:

• John Downs | Teknisi Pelanggan Utama, FastTrack untuk Azure

Kontributor lainnya:

• Daniel Scott-Raynsford | Strategi Teknologi Mitra
• Arsen Vladimirskiy | Teknisi Pelanggan Utama, FastTrack untuk Azure

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

Langkah berikutnya

Kembali ke ringkasan pertimbangan arsitektur. Atau, tinjau Microsoft Azure Well-Architected Framework.