Menjaga nama host HTTP asli antara proksi balik dan aplikasi web back-end-nya

Kami menyarankan agar Anda mempertahankan nama host HTTP asli saat Anda menggunakan proksi terbalik di depan aplikasi web. Jika Anda menggunakan nama host yang berbeda pada proxy terbalik daripada yang disediakan ke server aplikasi di bagian belakang dapat menyebabkan cookie atau URL pengalihan tidak berfungsi dengan baik. Misalnya, status sesi mungkin hilang, autentikasi mungkin gagal, atau URL back-end mungkin secara tidak sengaja diekspos ke pengguna. Anda menghindari masalah ini dengan mempertahankan nama host permintaan awal, sehingga server aplikasi melihat domain yang sama dengan browser web.

Panduan ini berlaku terutama untuk aplikasi yang dihosting dalam penawaran platform as a service (PaaS) seperti Azure App Service dan Azure Container Apps. Artikel ini menyediakan panduan implementasi tertentu untuk layanan proksi terbalik yang umum digunakan, termasuk Azure Application Gateway, Azure Front Door, dan Azure API Management.

Nota

API Web kurang sensitif terhadap ketidakcocokan nama host. API Web biasanya tidak bergantung pada cookie kecuali Anda menggunakan cookie untuk mengamankan komunikasi antara aplikasi satu halaman dan API back-end-nya, misalnya, dalam pola Backends for Frontends. API Web sering kali tidak mengembalikan URL absolut kembali ke diri mereka sendiri, kecuali dalam gaya API tertentu, seperti Open Data Protocol (OData) dan HATEOAS. Panduan yang diberikan dalam artikel ini berlaku dalam skenario di mana implementasi API Anda bergantung pada cookie atau menghasilkan URL absolut.

Jika Anda membutuhkan Keamanan Lapisan Transport end-to-end/Secure Sockets Layer (TLS/SSL), atau koneksi antara proksi balik dan layanan back-end menggunakan protokol HTTPS, layanan back-end juga memerlukan sertifikat TLS yang cocok untuk nama host yang asli. Persyaratan ini menambah kompleksitas operasional saat Anda menyebarkan dan memperbarui sertifikat, tetapi banyak layanan PaaS menyediakan sertifikat TLS gratis yang dikelola sepenuhnya.

Host permintaan HTTP

Dalam banyak kasus, server aplikasi atau komponen dalam alur permintaan membutuhkan nama domain internet yang digunakan browser untuk mengaksesnya. Nama domain ini adalah host permintaan. Host bisa berupa alamat IP, tetapi biasanya berupa nama seperti contoso.com, yang kemudian dipetakan oleh browser ke alamat IP dengan menggunakan Sistem Nama Domain (DNS). Nilai host biasanya ditentukan dari komponen host dariURI permintaan , yang dikirim browser ke aplikasi sebagai header HTTP Host.

Penting

Jangan pernah menggunakan nilai host dalam mekanisme keamanan. Browser atau agen pengguna lain menyediakan nilai, dan pengguna dapat mengubahnya.

Dalam beberapa skenario, terutama ketika ada proksi terbalik HTTP dalam rantai permintaan, header host asli mungkin berubah sebelum mencapai server aplikasi. Proksi terbalik menutup sesi jaringan klien dan membuat koneksi baru ke sisi server. Dalam sesi baru ini, proksi terbalik dapat mempertahankan nama host asli dari sesi klien, atau dapat menetapkan nama baru. Jika proksi terbalik menetapkan nama host baru, proksi sering mengirim nilai host asli juga, di header HTTP lainnya, seperti Forwarded atau X-Forwarded-Host. Termasuk nilai ini memungkinkan aplikasi untuk menentukan nama host asli, namun hanya jika diprogram untuk membaca header ini.

Mengapa platform web menggunakan nama host

Layanan PaaS multipenyewa sering memerlukan nama host terdaftar dan tervalidasi untuk merutekan permintaan masuk ke server back-end penyewa yang benar. Ini karena biasanya ada kumpulan penyeimbang beban bersama yang menerima permintaan masuk untuk semua penyewa. Penyewa biasanya menggunakan nama host penerima untuk mencari back-end yang benar untuk penyewa pelanggan.

Untuk memudahkan memulai, platform ini biasanya menyediakan domain default yang telah dikonfigurasi sebelumnya untuk merutekan lalu lintas ke instans yang Anda sebarkan. Untuk App Service, domain bawaan ini adalah azurewebsites.net. Setiap aplikasi web yang Anda buat mendapatkan subdomainnya sendiri, misalnya, contoso.azurewebsites.net. Demikian pula, domain default adalah azurecontainerapps.io untuk Aplikasi Kontainer dan azure-api.net untuk API Management.

Penerapan produksi tidak menggunakan domain default ini. Sebagai gantinya, sediakan domain Anda sendiri untuk selaras dengan organisasi Anda, atau merek aplikasi Anda. Misalnya, contoso.com mungkin diarahkan ke contoso.azurewebsites.net aplikasi web di App Service, namun domain ini sebaiknya tidak terlihat oleh pengguna yang mengunjungi situs web. Namun, nama host kustom contoso.com ini harus didaftarkan ke layanan PaaS sehingga platform dapat mengidentifikasi server back-end yang harus menanggapi permintaan.

Diagram yang mengilustrasikan perutean berbasis host di App Service.

Mengapa aplikasi menggunakan nama host

Server aplikasi mungkin memerlukan nama host untuk membuat URL absolut atau mengeluarkan cookie untuk domain tertentu. Dalam skenario ini, kode aplikasi mungkin perlu:

  • Mengembalikan URL absolut, bukan URL relatif, dalam respons HTTP-nya (meskipun situs web umumnya merender tautan relatif).

  • Buat URL yang akan digunakan di luar respons HTTP-nya di mana URL relatif tidak dapat digunakan, misalnya, saat mengirim tautan situs web melalui email ke pengguna.

  • Buat URL pengalihan absolut untuk layanan eksternal. Misalnya, URL pengalihan absolut untuk layanan autentikasi seperti Microsoft Entra ID mungkin menunjukkan tempatnya mengembalikan pengguna setelah autentikasi berhasil.

  • Terbitkan cookie HTTP yang dibatasi untuk host tertentu, seperti yang didefinisikan dalam atribut cookieDomain.

Anda dapat memenuhi semua persyaratan ini dengan memasukkan nama host yang diharapkan ke dalam konfigurasi aplikasi serta menggunakan nilai yang sudah ditetapkan secara statis alih-alih nama host yang diterima pada permintaan. Tetapi pendekatan ini mempersulit pengembangan dan penyebaran aplikasi. Selain itu, satu instalasi aplikasi dapat melayani beberapa host. Misalnya, satu aplikasi web dapat digunakan untuk beberapa penyewa aplikasi yang memiliki nama host unik mereka sendiri, seperti tenant1.contoso.com dan tenant2.contoso.com.

Terkadang nama host masuk digunakan oleh komponen di luar kode aplikasi atau di middleware di server aplikasi, dan Anda mungkin tidak memiliki kontrol penuh. Berikut adalah beberapa contoh:

  • Di App Service, Anda dapat memberlakukan https untuk aplikasi web Anda. Pendekatan ini mengalihkan permintaan HTTP yang tidak aman ke HTTPS. Dalam hal ini, nama host masuk digunakan untuk menghasilkan URL absolut untuk header Location pengalihan HTTP.

  • Aplikasi Kontainer juga dapat mengalihkan permintaan HTTP ke HTTPS dan juga menggunakan host masuk untuk menghasilkan URL HTTPS.

  • App Service memiliki pengaturan afinitas ARR yang menyediakan sesi permanen, yang memastikan bahwa permintaan dari sesi browser yang sama dialihkan ke server back-end yang sama. Ujung depan App Service menambahkan cookie ke respons HTTP. Cookie Domain diatur ke host yang dituju.

  • App Service menyediakan kemampuan autentikasi dan otorisasi sehingga pengguna dapat masuk dan mengakses data di API.

    • Nama host masuk digunakan untuk membuat URL pengalihan, yang menunjukkan tempat penyedia identitas mengembalikan pengguna setelah autentikasi.
    • Saat Anda mengaktifkan fitur ini, fitur ini juga mengaktifkan pengalihan HTTP-ke-HTTPS. Nama host masuk digunakan untuk menghasilkan lokasi pengalihan.

Mengesampingkan nama host bukanlah solusi

Katakanlah Anda membuat aplikasi web di App Service, atau layanan serupa seperti Container Apps. Host dilengkapi dengan domain contoso.azurewebsites.net. default Namun, Anda belum mengonfigurasi domain kustom di App Service. Untuk menempatkan proksi terbalik, seperti Application Gateway, di depan aplikasi ini, Anda mengatur catatan DNS untuk contoso.com agar mengarah ke alamat IP dari Application Gateway. Proksi terbalik menerima permintaan contoso.com dari browser dan meneruskannya ke titik akhir App Service di contoso.azurewebsites.net. App Service adalah layanan back-end akhir untuk host yang diminta. App Service tidak mengenali contoso.com domain kustom, sehingga menolak semua permintaan masuk untuk nama host ini. Ini tidak dapat menentukan rute permintaan.

Untuk membuat konfigurasi ini berfungsi, Anda mungkin mempertimbangkan untuk mengubah atau menulis ulang header permintaan HTTP di Application Gateway dan mengaturnya ke nilai Host. Tetapi jika Anda melakukan pendekatan ini, permintaan keluar dari Application Gateway membuatnya tampak seperti permintaan asli ditujukan untuk contoso.azurewebsites.net alih-alih contoso.com.

Diagram yang mengilustrasikan konfigurasi dengan nama host diubah.

App Service sekarang mengenali nama host dan menerima permintaan tanpa memerlukan nama domain kustom untuk dikonfigurasi. Application Gateway memudahkan untuk menggantikan header host dengan host dari kumpulan back-end. Azure Front Door melakukan proses ini secara default. Tetapi solusi ini dapat menyebabkan masalah ketika aplikasi tidak melihat nama host asli.

Potensi masalah

Bagian berikut menjelaskan masalah umum yang dapat muncul ketika nama host HTTP asli tidak dipertahankan antara proksi terbalik dan aplikasi back-end.

URL absolut yang salah

Jika nama host asli tidak dipertahankan, dan server aplikasi menggunakan nama host masuk untuk menghasilkan URL absolut, domain back-end mungkin diungkapkan kepada pengguna. URL absolut ini dihasilkan oleh kode aplikasi atau oleh fitur platform seperti dukungan untuk pengalihan HTTP-ke-HTTPS di App Service dan Aplikasi Kontainer. Diagram berikut mengilustrasikan masalahnya.

Diagram yang mengilustrasikan masalah URL absolut yang salah.

  1. Browser mengirimkan permintaan untuk contoso.com ke proksi terbalik.

  2. Proksi terbalik mengubah nama host menjadi contoso.azurewebsites.net dalam permintaan ke aplikasi web back-end, atau ke domain default serupa untuk layanan serupa lainnya.

  3. Aplikasi ini menghasilkan URL absolut yang didasarkan pada nama host contoso.azurewebsites.net masuk, misalnya, https://contoso.azurewebsites.net/.

  4. Peramban mengikuti URL ini, yang langsung masuk ke layanan back-end daripada kembali ke proxy terbalik di contoso.com.

Perilaku ini mungkin menimbulkan risiko keamanan di mana proksi terbalik juga berfungsi sebagai firewall aplikasi web. Pengguna menerima URL yang mengarah langsung ke aplikasi back-end dan melewati proksi terbalik.

Penting

Untuk mengurangi risiko keamanan ini, pastikan bahwa aplikasi web back-end menerima lalu lintas jaringan secara langsung hanya dari proksi terbalik. Misalnya, Anda dapat menggunakan pembatasan akses di App Service sehingga meskipun URL absolut yang salah dihasilkan, itu tidak berfungsi. Pengguna berbahaya tidak dapat menggunakan URL untuk melewati firewall.

URL pengalihan yang salah

Kasus yang lebih spesifik dari skenario sebelumnya terjadi ketika URL pengalihan absolut dihasilkan. Layanan identitas seperti Microsoft Entra ID memerlukan URL ini saat Anda menggunakan protokol identitas berbasis browser seperti OpenID Connect (OIDC), Open Authorization (OAuth) 2.0, atau Security Assertion Markup Language (SAML) 2.0. URL pengalihan ini mungkin dihasilkan oleh server aplikasi atau middleware atau oleh fitur platform seperti kemampuan autentikasi dan otorisasi App Service. Diagram berikut mengilustrasikan masalahnya.

Diagram yang mengilustrasikan masalah URL pengalihan yang salah.

  1. Browser mengirimkan permintaan untuk contoso.com ke proksi terbalik.

  2. Proksi terbalik menulis ulang nama host ke contoso.azurewebsites.net pada permintaan ke aplikasi web back-end atau ke domain default serupa untuk layanan lain.

  3. Aplikasi ini menghasilkan URL pengalihan absolut yang didasarkan pada nama host contoso.azurewebsites.net masuk, misalnya, https://contoso.azurewebsites.net/.

  4. Browser masuk ke penyedia identitas untuk mengautentikasi pengguna. Permintaan mencakup URL pengalihan yang dihasilkan untuk menunjukkan tempat mengembalikan pengguna setelah autentikasi berhasil.

  5. Penyedia identitas biasanya memerlukan URL pengalihan untuk didaftarkan di muka. Penyedia identitas harus menolak permintaan karena URL pengalihan yang disediakan tidak terdaftar. Jika URL pengalihan salah terdaftar, penyedia identitas (idP) mengarahkan browser ke URL pengalihan yang ditentukan dalam permintaan autentikasi. Dalam hal ini, URL https://contoso.azurewebsites.net/.

  6. Peramban mengikuti URL ini, yang langsung menuju layanan back-end daripada kembali ke proksi terbalik tersebut.

Cookie rusak

Ketidakcocokan nama host juga dapat menyebabkan masalah ketika server aplikasi mengeluarkan cookie dan menggunakan nama host masuk untuk membangun Domain atribut cookie. Atribut Domain memastikan bahwa cookie hanya digunakan untuk domain tertentu. Cookie ini dihasilkan oleh kode aplikasi atau oleh fitur platform seperti pengaturan afinitas ARR App Service. Diagram berikut mengilustrasikan masalahnya.

Diagram yang mengilustrasikan domain cookie yang salah.

  1. Browser mengirimkan permintaan untuk contoso.com ke proksi terbalik.

  2. Proksi terbalik menyetel ulang nama host untuk menjadi contoso.azurewebsites.net pada permintaan ke aplikasi web back-end atau ke domain default lain yang serupa untuk layanan lain.

  3. Aplikasi ini menghasilkan cookie yang menggunakan domain berdasarkan nama host contoso.azurewebsites.net masuk. Browser menyimpan cookie untuk domain khusus ini, bukan untuk domain contoso.com yang digunakan pengguna.

  4. Browser tidak menyertakan cookie pada permintaan berikutnya untuk contoso.com, karena domain cookie contoso.azurewebsites.net tidak cocok dengan domain permintaan. Aplikasi tidak menerima cookie yang dikeluarkan sebelumnya. Pengguna mungkin kehilangan status yang seharusnya ada di cookie, dan fitur seperti afinitas ARR mungkin tidak berfungsi. Masalah ini tidak menghasilkan kesalahan dan tidak langsung terlihat oleh pengguna akhir, yang membuatnya sulit untuk memecahkan masalah.

Panduan implementasi untuk layanan Azure umum

Untuk menghindari potensi masalah ini, kami sarankan Anda menjaga nama host asli dalam panggilan antara reverse proxy dan server aplikasi back-end.

Diagram yang memperlihatkan konfigurasi di mana nama host dipertahankan.

Konfigurasi back-end

Banyak platform hosting web mengharuskan Anda secara eksplisit mengonfigurasi nama host masuk yang diizinkan. Bagian berikut menjelaskan cara menerapkan konfigurasi ini untuk layanan Azure yang paling umum. Platform lain biasanya menyediakan metode serupa untuk mengonfigurasi domain kustom.

Jika Anda menghosting aplikasi web di App Service, lampirkan nama domain kustom ke aplikasi web dan hindari menggunakan nama host default azurewebsites.net ke ujung belakang. Anda tidak perlu mengubah resolusi DNS saat melampirkan domain kustom ke aplikasi web. Sebagai gantinya, verifikasi domain dengan menggunakan TXT catatan tanpa memengaruhi catatan CNAME atau A biasa Anda. Catatan-catatan ini masih diarahkan ke alamat IP proksi terbalik. Jika Anda memerlukan TLS/SSL end-to-end, impor sertifikat yang ada dari Key Vault atau gunakan Sertifikat Layanan App untuk domain kustom Anda. Dalam hal ini, sertifikat terkelola App Service gratis tidak dapat digunakan, karena memerlukan catatan DNS domain, bukan proksi terbalik, untuk diarahkan langsung ke App Service.

Jika Anda menggunakan Aplikasi Kontainer, gunakan domain kustom untuk aplikasi Anda untuk menghindari penggunaan azurecontainerapps.io nama host. Gunakan sertifikat terkelola atau impor sertifikat yang sudah ada.

Jika Anda memiliki proksi terbalik di depan API Management, yang juga bertindak sebagai proksi terbalik, konfigurasikan domain kustom pada instans API Management Anda. Pendekatan ini menghindari penggunaan azure-api.net nama host. Jika Anda memerlukan TLS/SSL ujung-ke-ujung, impor sertifikat terkelola yang sudah ada atau gratis. Tetapi API kurang sensitif terhadap masalah yang disebabkan oleh ketidakcocokan nama host, sehingga konfigurasi ini mungkin tidak sama pentingnya.

Jika Anda menghosting aplikasi di platform lain, seperti di Kubernetes atau langsung di komputer virtual, tidak ada fungsionalitas bawaan yang tergantung pada nama host masuk. Anda bertanggung jawab atas bagaimana nama host digunakan di server aplikasi. Rekomendasi untuk mempertahankan nama host masih berlaku untuk komponen apa pun di aplikasi Anda yang bergantung padanya, kecuali Anda secara khusus membuat aplikasi Anda menyadari proksi terbalik dan menghormati forwarded header atau X-Forwarded-Host , misalnya.

Konfigurasi proksi terbalik

Saat Anda menentukan backend dalam proksi terbalik, Anda masih dapat menggunakan domain default layanan backend, misalnya, https://contoso.azurewebsites.net/. URL ini digunakan oleh proksi terbalik untuk menyelesaikan alamat IP yang benar untuk layanan back-end. Jika Anda menggunakan domain default platform, alamat IP dijamin benar. Anda biasanya tidak dapat menggunakan domain yang terlihat oleh publik, seperti contoso.com, karena domain tersebut harus diarahkan ke alamat IP proksi terbalik itu sendiri. Pengecualian untuk aturan ini adalah ketika Anda menggunakan teknik resolusi DNS yang lebih canggih, seperti DNS split-horizon.

Penting

Jika Anda memiliki firewall generasi berikutnya seperti Azure Firewall Premium antara reverse proxy dan back end akhir, Anda mungkin perlu menggunakan DNS split-horizon. Jenis firewall ini mungkin secara eksplisit memeriksa apakah header HTTP Host diarahkan ke alamat IP target. Dalam kasus ini, nama host yang asli digunakan oleh browser harus mengarah ke alamat IP proksi terbalik ketika diakses melalui internet publik. Tetapi, dari sudut pandang firewall, nama host tersebut harus dikonversi menjadi alamat IP layanan back-end yang terakhir. Untuk informasi selengkapnya, lihat Menimplementasikan jaringan Zero Trust untuk aplikasi web dengan menggunakan Azure Firewall dan Application Gateway.

Pada kebanyakan proksi terbalik, Anda dapat mengonfigurasi nama host mana yang diteruskan ke layanan back-end. Informasi berikut menjelaskan cara memastikan bahwa layanan Azure yang paling umum menggunakan nama host asli dari permintaan masuk.

Nota

Anda juga dapat memilih untuk mengganti nama host dengan domain kustom yang ditetapkan secara eksplisit, daripada mengambilnya dari permintaan masuk. Jika aplikasi hanya menggunakan satu domain, pendekatan tersebut mungkin berfungsi dengan baik. Jika penerapan aplikasi yang sama menerima permintaan dari beberapa domain, seperti dalam skenario multitenancy, Anda tidak dapat menentukan satu domain secara statis. Ambil nama host dari permintaan masuk, kecuali aplikasi secara eksplisit dikodekan untuk memperhitungkan header HTTP lainnya. Dalam kebanyakan kasus, Anda tidak boleh mengambil alih nama host. Teruskan nama host masuk yang tidak dimodifikasi ke backend.

Apakah Anda mempertahankan atau mengganti nama host di proksi terbalik, pastikan bahwa server belakang dikonfigurasi untuk menerima permintaan dalam format Anda.

Application Gateway

Jika Anda menggunakan Application Gateway sebagai proksi terbalik, pastikan bahwa nama host asli dipertahankan dengan menonaktifkan opsi Ganti dengan nama host baru pada pengaturan HTTP back-end. Pengaturan ini menonaktifkan Pilih nama host dari alamat back-end dan Ambil alih dengan pengaturan nama domain tertentu , yang keduanya menimpa nama host. Dalam properti Azure Resource Manager untuk Application Gateway, konfigurasi ini sesuai dengan mengatur properti hostName ke null dan pickHostNameFromBackendAddress ke false.

Karena pengujian kesehatan dikirimkan di luar konteks permintaan masuk, mereka tidak dapat menentukan nama host yang benar secara dinamis. Sebagai gantinya, buat pemeriksaan kesehatan kustom, nonaktifkan Pilih nama host dari pengaturan HTTP back-end, dan tentukan nama host secara eksplisit. Untuk nama host ini, gunakan domain kustom yang sesuai untuk konsistensi. Atau, gunakan domain default platform hosting di sini, karena pengujian kesehatan mengabaikan cookie yang salah atau mengalihkan URL di dalam respons.

Jika nama host tidak dipertahankan dan Anda perlu mendiagnosis masalah yang dihasilkan, lihat Memecahkan masalah pengalihan App Service di Application Gateway. Jika Anda tidak dapat sepenuhnya mempertahankan nama host, pertimbangkan untuk menggunakan header HTTP dan penulisan ulang URL sebagai solusi parsial.

Azure Front Door

Jika Anda menggunakan Azure Front Door, pertahankan nama host dengan membiarkan header host origin kosong dalam definisi asal. Dalam definisi Resource Manager asli, konfigurasi ini berkaitan dengan pengaturan originHostHeader ke null.

API Management

Secara bawaan, API Management menggantikan nama host yang dikirim ke back end dengan komponen host URL layanan web API, yang sesuai dengan nilai serviceUrl dari definisi Resource Manager API. Sebagai gantinya, paksa API Management untuk menggunakan nama host permintaan masuk dengan menambahkan kebijakan header yang inboundditetapkan :

<inbound>
  <base />
  <set-header name="Host" exists-action="override">
    <value>@(context.Request.OriginalUrl.Host)</value>
  </set-header>
</inbound>

API kurang sensitif terhadap masalah yang disebabkan oleh ketidakcocokan nama host, sehingga konfigurasi ini mungkin tidak sepenting.

Konfigurasi aplikasi

Bahkan ketika Anda mempertahankan nama host asli di tingkat proksi terbalik, proksi terbalik masih mengakhiri koneksi TLS klien. Koneksi baru yang dibuat proksi ke ujung belakang kehilangan alamat IP klien asli dan skema HTTPS. Nilai-nilai ini biasanya diteruskan melalui header HTTP yang umum digunakan. Contohnya termasuk X-Forwarded-For untuk alamat IP klien, X-Forwarded-Proto untuk skema asli, dan X-Forwarded-Host untuk nama host asli. Aplikasi Anda harus dikonfigurasi untuk membaca header ini sehingga dapat menentukan skema permintaan, alamat klien, dan informasi host asli dengan benar.

Jika kerangka kerja aplikasi Anda tidak memproses X-Forwarded-Proto, aplikasi memperlakukan koneksi back-end sebagai HTTP biasa, meskipun pengguna terhubung melalui HTTPS. Kesalahan persepsi itu adalah penyebab paling umum dari perulangan pengalihan HTTP-ke-HTTPS tak terbatas. Ini juga dapat mengakibatkan flag cookie yang tidak aman atau kesalahan konten campuran.

Sebagian besar kerangka kerja web memiliki mekanisme untuk memproses header yang diteruskan. Tinjau dokumentasi kerangka kerja Anda dan konfigurasikan dengan tepat. Contoh berikut mencakup kerangka kerja umum:

Penting

Hanya percayai header yang diteruskan dari proksi yang diketahui. Misalnya, konfigurasikanKnownProxies atau KnownNetworks untuk membatasi sumber mana yang dapat mengatur header yang diteruskan. Menerima header yang diteruskan dari sumber yang tidak tepercaya memungkinkan klien untuk memalsukan alamat IP atau skema aslinya.

Langkah berikutnya

Tinjau panduan layanan Azure Well-Architected Framework untuk layanan Azure yang Anda gunakan dalam beban kerja Anda.

  • Last updated on