Ringkasan tentang penghentian TLS dan ujung ke ujung TLS dengan App Gateway

  • Artikel

Keamanan Lapisan Transportasi (TLS), sebelumnya dikenal sebagai Secure Sockets Layer (SSL), adalah teknologi keamanan standar untuk membuat tautan terenkripsi antara server web dan browser. Tautan ini memastikan bahwa semua data yang dilewatkan antara server web dan browser tetap privat dan terenkripsi. Gateway aplikasi mendukung penghentian TLS di gateway serta enkripsi TLS ujung ke ujung.

Penghentian TLS

Application Gateway mendukung penghentian TLS di gateway, setelah itu lalu lintas biasanya mengalir tanpa dienkripsi ke server ujung belakang. Ada sejumlah keuntungan melakukan penghentian TLS di gateway aplikasi:

  • Peningkatan performa - Performa terbesar yang dicapai saat melakukan dekripsi TLS adalah berjabat tangan awal. Untuk meningkatkan performa, server melakukan cache dekripsi ID sesi TLS dan mengelola tiket sesi TLS. Jika ini dilakukan di gateway aplikasi, semua permintaan dari klien yang sama dapat menggunakan nilai yang di-cache. Jika itu dilakukan di server backend, maka setiap kali permintaan klien masuk ke server yang berbeda, klien harus mengaauthenticate ulang. Penggunaan tiket TLS dapat membantu mengurangi masalah ini, tetapi tidak didukung oleh semua klien dan mungkin sulit untuk dikonfigurasi dan dikelola.
  • Pemanfaatan server ujung ke belakang yang lebih baik - Pemrosesan SSL/TLS sangat intensif menggunakan CPU, dan menjadi lebih intensif seiring peningkatan ukuran kunci. Menghapus pekerjaan ini dari server ujung belakang memungkinkan mereka untuk fokus pada hal yang paling efisien, mengirimkan konten.
  • Perutean cerdas – Dengan mendekripsi lalu lintas, gateway aplikasi memiliki akses ke konten permintaan, seperti header, URI, dan sebagainya, dan dapat menggunakan data ini untuk merutekan permintaan.
  • Manajemen sertifikat – Sertifikat hanya perlu dibeli dan diinstal pada gateway aplikasi dan tidak semua server ujung belakang. Ini menghemat waktu dan uang.

Untuk mengonfigurasi penghentian TLS, sertifikat TLS/SSL harus ditambahkan ke pendengar. Hal ini memungkinkan Application Gateway untuk mendekripsi lalu lintas masuk dan mengenkripsi lalu lintas respons ke klien. Sertifikat yang diberikan ke Application Gateway harus dalam format Personal Information Exchange (PFX), yang berisi kunci privat dan publik. Algoritma PFX yang didukung tercantum di fungsi PFXImportCertStore.

Penting

Sertifikat pendengar memerlukan seluruh rantai sertifikat untuk diunggah (sertifikat akar dari CA, perantara dan sertifikat daun) untuk membangun rantai kepercayaan.

Catatan

Gateway aplikasi tidak menyediakan kemampuan apa pun untuk membuat sertifikat baru atau mengirim permintaan sertifikat ke otoritas sertifikasi.

Agar sambungan TLS berfungsi, Anda perlu memastikan bahwa sertifikat TLS/SSL memenuhi kondisi berikut:

  • Tanggal dan waktu saat ini berada dalam rentang tanggal "Valid dari" dan "Valid hingga" pada sertifikat.
  • Sertifikat "Nama Umum" (CN) cocok dengan header host dalam permintaan. Misalnya, jika klien membuat permintaan ke https://www.contoso.com/, maka CN harus www.contoso.com.

Jika Anda memiliki kesalahan dengan nama umum sertifikat backend (CN), lihat panduan pemecahan masalah kami.

Sertifikat didukung untuk penghentian TLS

Gateway aplikasi mendukung jenis sertifikat berikut:

  • Sertifikat OS (Otoritas Sertifikat): Sertifikat OS adalah sertifikat digital yang dikeluarkan oleh otoritas sertifikat (OS)
  • Sertifikat EV (Extended Validation/Validasi Diperpanjang): Sertifikat EV adalah sertifikat yang sesuai dengan pedoman sertifikat standar industri. Ini akan mengubah bilah pencari browser menjadi hijau dan menerbitkan nama perusahaan juga.
  • Sertifikat Kartubebas: Sertifikat ini mendukung sejumlah subdomain berdasarkan *.site.com, di mana subdomain Anda akan menggantikan *. Namun, tidak mendukung site.com, jadi jika pengguna mengakses situs web Anda tanpa mengetik "www" terkemuka, sertifikat kartubebas tidak akan membahasnya.
  • Sertifikat yang Ditandatangani Sendiri: Browser klien tidak mempercayai sertifikat ini dan akan memperingatkan pengguna bahwa sertifikat layanan virtual bukan bagian dari rantai kepercayaan. Sertifikat yang ditandatangani sendiri dapat digunakan untuk pengujian atau lingkungan di mana administrator mengontrol klien dan dapat dengan aman melewati pemberitahuan keamanan browser. Beban kerja produksi tidak boleh menggunakan sertifikat yang ditandatangani sendiri.

Untuk informasi lebih lanjut, lihat konfigurasi penghentian TLS dengan gateway aplikasi.

Ukuran sertifikat

Periksa bagian Batas Application Gateway untuk mengetahui ukuran sertifikat TLS/SSL maksimum yang didukung.

Enkripsi TLS end-to-end

Anda mungkin tidak ingin komunikasi yang tidak terenkripsi ke server ujung belakang. Anda mungkin memiliki persyaratan keamanan, persyaratan kepatuhan, atau aplikasi hanya dapat menerima sambungan yang aman. Azure Application Gateway memiliki enkripsi TLS ujung ke ujung untuk mendukung persyaratan ini.

TLS ujung ke ujung mengizinkan Anda mengenkripsi dan mengirimkan data sensitif dengan aman ke ujung belakang saat Anda menggunakan fitur penyeimbang muatan Lapisan-7 dari Application Gateway. Fitur ini mencakup afinitas sesi berbasis cookie, perutean berbasis URL, dukungan untuk perutean berdasarkan situs, kemampuan untuk regenerasi atau memasukkan header X-Forwarded-*, dan sebagainya.

Saat dikonfigurasi dengan mode komunikasi TLS ujung ke ujung, Application Gateway menghentikan sesi TLS di gateway dan mendekripsi lalu lintas pengguna. Kemudian menerapkan aturan yang dikonfigurasi untuk memilih instans kumpulan ujung belakang yang sesuai untuk merutekan lalu lintas. Application Gateway kemudian memulai sambungan TLS baru ke server ujung belang dan mengenkripsi kembali data menggunakan sertifikat kunci publik server ujung belakang sebelum mengirimkan permintaan ke ujung belakang. Setiap respons dari server web melalui proses yang sama kembali ke pengguna akhir. TLS ujung ke ujung diaktifkan dengan mengatur pengaturan protokol di Pengaturan HTTP Ujung Belakang ke HTTPS, yang kemudian diterapkan ke kumpulan ujung belakang.

Di gateway SKU Application Gateway v1, kebijakan TLS hanya menerapkan versi TLS untuk lalu lintas frontend dan cipher yang ditentukan ke target frontend dan backend. Di gateway SKU Application Gateway v2, kebijakan TLS hanya berlaku untuk lalu lintas frontend, koneksi TLS backend akan selalu dinegosiasikan melalui TLS 1.0 ke versi TLS 1.2.

Application Gateway hanya berkomunikasi dengan server backend yang telah mengizinkan daftar sertifikat mereka dengan Application Gateway atau yang sertifikatnya ditandatangani oleh otoritas CA terkenal dan CN sertifikat cocok dengan nama host di pengaturan backend HTTP. Ini termasuk layanan Azure tepercaya seperti Azure App Service/Web Apps dan Azure API Management.

Jika sertifikat anggota di kumpulan backend tidak ditandatangani oleh otoritas CA terkenal, maka setiap instans di kumpulan backend dengan TLS end to end diaktifkan harus dikonfigurasi dengan sertifikat untuk memungkinkan komunikasi yang aman. Menambahkan sertifikat memastikan bahwa gateway aplikasi hanya berkomunikasi dengan instans backend yang diketahui. Ini semakin mengamankan komunikasi ujung ke ujung.

Catatan

Sertifikat yang ditambahkan ke Pengaturan HTTP Ujung Belakang untuk mengautentikasi server ujung belakang dapat sama dengan sertifikat yang ditambahkan ke pendengar untuk penghentian TLS di gateway aplikasi atau berbeda untuk keamanan yang ditingkatkan.

end to end TLS scenario

Dalam contoh ini, permintaan yang menggunakan TLS1.2 dirutekan ke server ujung belakang di Pool1 menggunakan TLS ujung ke ujung.

TLS ujung ke ujung dan perizinan pendaftaran sertifikat

Application Gateway hanya berkomunikasi dengan server backend yang telah mengizinkan daftar sertifikat mereka dengan Application Gateway atau yang sertifikatnya ditandatangani oleh otoritas CA terkenal dan CN sertifikat cocok dengan nama host di pengaturan backend HTTP. Ada beberapa perbedaan dalam proses pengaturan TLS ujung ke ujung sehubungan dengan versi Application Gateway yang digunakan. Bagian berikut menjelaskan versi satu per satu.

TLS ujung ke ujung dengan SKU v1

Untuk mengaktifkan TLS ujung ke ujung dengan server ujung belakang dan untuk Application Gateway untuk merutekan permintaan ke mereka, pemeriksaan kesehatan harus berhasil dan mengembalikan respons yang sehat.

Untuk pemeriksaan kesehatan HTTPS, Application Gateway v1 SKU menggunakan sertifikat autentikasi yang sama persis (kunci publik dari sertifikat server ujung belakang dan bukan sertifikat akar) untuk diunggah ke pengaturan HTTP.

Hanya sambungan ke ujung belakang yang diketahui dan diizinkan yang kemudian diizinkan. Ujung belakang yang tersisa dianggap tidak sehat oleh pemeriksaan kesehatan. Sertifikat yang ditandatangani sendiri hanya untuk tujuan pengujian dan tidak direkomendasikan untuk beban kerja produksi. Sertifikat tersebut harus diizinkan terdaftar dengan gateway aplikasi seperti yang dijelaskan dalam langkah-langkah sebelumnya sebelum dapat digunakan.

Catatan

Autentikasi dan penyiapan sertifikat akar tepercaya tidak diperlukan untuk layanan Azure tepercaya seperti Azure App Service. Mereka dianggap tepercaya secara default.

TLS ujung ke ujung dengan SKU v2

Sertifikat Autentikasi sudah tidak digunakan dan digantikan oleh Sertifikat Akar Tepercaya di Application Gateway SKU v2. Fungsi mereka mirip dengan Sertifikat Autentikasi dengan beberapa perbedaan utama:

  • Sertifikat yang ditandatangani oleh otoritas CA terkenal yang CN-nya cocok dengan nama host di pengaturan backend HTTP tidak memerlukan langkah tambahan agar TLS end to end berfungsi.

    Misalnya, jika sertifikat ujung belakang dikeluarkan oleh OS terkenal dan memiliki CN contoso.com, dan bidang host pengaturan http ujung belakang juga diatur ke contoso.com, maka tidak ada langkah tambahan yang diperlukan. Anda dapat mengatur protokol pengaturan http ujung belakang ke HTTPS dan pemeriksaan kesehatan serta jalur data akan mengaktifkan TLS. Jika Anda menggunakan Azure App Service atau layanan web Azure lainnya sebagai ujung belakang Anda, ini secara implisit juga dipercaya dan tidak ada langkah lebih lanjut yang diperlukan untuk TLS ujung ke ujung.

Catatan

Agar sertifikat TLS/SSL dapat dipercaya, sertifikat server ujung belakang tersebut harus diterbitkan oleh OS yang terkenal. Jika sertifikat tidak diterbitkan oleh OS tepercaya, gateway aplikasi kemudian akan memeriksa untuk melihat apakah sertifikat OS penerbit dikeluarkan oleh OS tepercaya, dan seterusnya hingga OS tepercaya ditemukan (di titik mana sambungan aman yang tepercaya akan dibuat) atau tidak ada OS tepercaya yang dapat ditemukan (di titik mana gateway aplikasi akan menandai ujung belakang tidak sehat). Oleh karena itu, sebaiknya sertifikat server ujung belakang berisi OS akar dan perantara.

  • Jika sertifikat server ujung belakang ditandatangani sendiri, atau ditandatangani oleh OS/perantara yang tidak dikenal, maka sertifikat akar tepercaya harus diunggah untuk mengaktifkan TLS ujung ke ujung di Application Gateway v2. Application Gateway hanya akan berkomunikasi dengan ujung belakang yang sertifikat akar milik sertifikat servernya cocok dengan salah satu daftar sertifikat akar tepercaya di pengaturan http ujung belakang yang terkait dengan kumpulan tersebut.

  • Selain kecocokan sertifikat akar, Application Gateway v2 juga memvalidasi jika pengaturan Host yang ditentukan di pengaturan http ujung belakang cocok dengan nama umum (CN) yang diberikan oleh sertifikat TLS/SSL server ujung belakang. Saat mencoba membuat sambungan TLS ke ujung belakang, Application Gateway v2 mengatur ekstensi Indikasi Nama Server (SNI) ke Host yang ditentukan dalam pengaturan http ujung belakang.

  • Jika pilih nama host dari target ujung belakang dipilih alih-alih bidang Host di pengaturan http ujung belakang, maka header SNI selalu diatur ke kumpulan ujung belakang FQDN dan CN di server ujung belakang sertifikat TLS/SSL harus cocok dengan FQDN-nya. Anggota kumpulan ujung belakang dengan IP tidak didukung dalam skenario ini.

  • Sertifikat akar adalah sertifikat akar yang berkode base64 dari sertifikat server ujung belakang.

Perbedaan SNI pada SKU v1 dan v2

Seperti yang disebutkan sebelumnya, Application Gateway menghentikan lalu lintas TLS dari klien di Application Gateway Listener (sebut saja sambungan ujung depan), mendekripsi lalu lintas, menerapkan aturan yang diperlukan untuk menentukan server ujung belakang tempat permintaan harus diteruskan, dan menetapkan sesi TLS baru dengan server ujung belakang (sebut saja sambungan ujung belakang).

Tabel berikut memberikan garis luar perbedaan SNI antara SKU v1 dan v2 dalam hal sambungan ujung depan dan belakang.

Sambungan TLS ujung depan (klien ke gateway aplikasi)

Skenario v1 v2
Jika klien menentukan header SNI dan semua pendengar multi-situs diaktifkan dengan bendera "Butuh SNI" Mengembalikan sertifikat yang sesuai dan jika situs tidak ada (sesuai dengan server_name), koneksi diatur ulang. Mengembalikan sertifikat yang sesuai jika tersedia, jika tidak, mengembalikan sertifikat pendengar HTTPS pertama sesuai dengan urutan yang ditentukan oleh aturan perutean permintaan yang terkait dengan pendengar HTTPS
Jika klien tidak menentukan header SNI dan jika semua header multi-situs diaktifkan dengan "Butuh SNI" Atur ulang sambungannya Mengembalikan sertifikat pendengar HTTPS pertama sesuai dengan urutan yang ditentukan oleh aturan perutean permintaan yang terkait dengan pendengar HTTPS
Jika klien tidak menentukan header SNI dan jika ada pendengar dasar yang dikonfigurasi dengan sertifikat Kembalikan sertifikat yang dikonfigurasi di pendengar dasar ke klien (sertifikat default atau fallback) Mengembalikan sertifikat yang dikonfigurasikan di pendengar dasar

Tip

Bendera SNI dapat dikonfigurasi dengan PowerShell atau dengan menggunakan templat ARM. Untuk informasi selengkapnya, lihat RequireServerNameIndication dan Quickstart: Lalu lintas web langsung dengan Azure Application Gateway - templat ARM.

Sambungan TLS ujung belakang (gateway aplikasi ke server ujung belakang)

Untuk pemeriksaan lalu lintas

Skenario v1 v2
Header SNI (nama_server) selama jabat tangan TLS sebagai FQDN Atur sebagai FQDN dari kumpulan ujung belakang. Sesuai RFC 6066, alamat IPv4 dan IPv6 harfiah tidak diizinkan dalam nama host SNI.
Catatan: FQDN di kumpulan ujung belakang jika DNS menyelesaikan alamat IP server ujung belakang (publik atau privat)		 Header SNI (nama_server) diatur sebagai nama host dari pemeriksaan kustom yang dilampirkan ke pengaturan HTTP (jika dikonfigurasi), jika tidak dari nama host yang disebutkan dalam pengaturan HTTP, jika tidak dari FQDN yang disebutkan di kumpulan ujung belakang. Urutan prioritas adalah kumpulan backend pengaturan > HTTP pemeriksaan > kustom.
Catatan: Jika nama host yang dikonfigurasi dalam pengaturan HTTP dan pemeriksaan kustom berbeda, sesuai dengan prioritas, SNI akan ditetapkan sebagai nama host dari pemeriksaan kustom.
Jika alamat kumpulan ujung belakang adalah alamat IP (v1) atau jika nama host pemeriksaan kustom dikonfigurasi sebagai alamat IP (v2) SNI (nama_server) tidak akan diatur.
Catatan: Dalam hal ini, server backend harus dapat mengembalikan sertifikat default/fallback dan ini harus diperbolehkan tercantum dalam pengaturan HTTP di bawah sertifikat autentikasi. Jika tidak ada sertifikat default/fallback yang dikonfigurasi di server ujung belakang dan SNI diharapkan, server mungkin mengatur ulang sambungan dan akan menyebabkan kegagalan pemeriksaan		 Dalam urutan prioritas yang disebutkan sebelumnya, jika mereka memiliki alamat IP sebagai nama host, SNI tidak akan diatur sesuai RFC 6066.
Catatan: SNI juga tidak akan diatur dalam pemeriksaan v2 jika tidak ada pemeriksaan kustom yang dikonfigurasi dan tidak ada nama host yang diatur pada pengaturan HTTP atau kumpulan ujung belakang

Catatan

Jika pemeriksaan kustom tidak dikonfigurasi, Application Gateway mengirimkan pemeriksaan default dalam format ini - <protocol>://127.0.0.1:<port>/. Misalnya, untuk pemeriksaan HTTPS default, itu akan dikirim sebagai https://127.0.0.1:443/. Perhatikan bahwa, 127.0.0.1 yang disebutkan di sini hanya digunakan sebagai header host HTTP dan sesuai RFC 6066, tidak akan digunakan sebagai header SNI. Untuk informasi lebih lanjut tentang kesalahan pemeriksaan kesehatan, periksa panduan pemecahan masalah kesehatan ujung belakang.

Untuk lalu lintas langsung

Skenario v1 v2
Header SNI (nama_server) selama jabat tangan TLS sebagai FQDN Atur sebagai FQDN dari kumpulan ujung belakang. Sesuai RFC 6066, alamat IPv4 dan IPv6 harfiah tidak diizinkan dalam nama host SNI.
Catatan: FQDN di kumpulan ujung belakang jika DNS menyelesaikan alamat IP server ujung belakang (publik atau privat)		 Header SNI (server_name) diatur sebagai nama host dari pengaturan HTTP, jika tidak, jika opsi PickHostnameFromBackendAddress dipilih atau jika tidak ada nama host yang disebutkan, maka itu akan ditetapkan sebagai FQDN dalam konfigurasi kumpulan backend
Jika alamat kumpulan backend adalah alamat IP atau nama host tidak diatur dalam pengaturan HTTP SNI tidak akan ditetapkan sesuai RFC 6066 jika entri kumpulan backend bukan FQDN SNI akan ditetapkan sebagai nama host dari input FQDN dari klien dan CN sertifikat ujung belakang harus cocok dengan nama host ini.
Nama host tidak disediakan dalam Pengaturan HTTP, tetapi FQDN ditentukan sebagai Target untuk anggota kumpulan backend SNI akan ditetapkan sebagai nama host dari input FQDN dari klien dan CN sertifikat ujung belakang harus cocok dengan nama host ini. SNI akan ditetapkan sebagai nama host dari input FQDN dari klien dan CN sertifikat ujung belakang harus cocok dengan nama host ini.

Langkah berikutnya

Setelah mempelajari tentang TLS ujung ke ujung, buka Konfigurasi TLS ujung ke ujung dengan menggunakan Application Gateway with PowerShell untuk membuat gateway aplikasi menggunakan TLS ujung ke ujung.