Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Untuk mengonfigurasi inspeksi TLS Azure Firewall Premium dengan benar, Anda harus memberikan sertifikat CA menengah yang valid dan menyimpannya di Azure Key vault.
Sertifikat yang digunakan oleh Azure Firewall Premium
Ada tiga jenis sertifikat yang digunakan dalam penyebaran umum:
Sertifikat CA Menengah (Sertifikat CA)
Certificate Authority (CA) adalah organisasi yang dipercaya untuk menandatangani sertifikat digital. CA memverifikasi identitas dan legitimasi perusahaan atau individu yang meminta sertifikat. Jika verifikasi berhasil, CA akan mengeluarkan sertifikat yang ditandatangani. Ketika server memberikan sertifikat kepada klien (misalnya, browser web Anda) selama handshake SSL/TLS, klien mencoba memverifikasi tanda tangan terhadap daftar penanda tangan berkualitas yang diketahui. Browser web biasanya memiliki daftar CA yang mereka percayai secara implisit untuk mengidentifikasi host. Jika otoritas tidak ada dalam daftar, seperti halnya beberapa situs yang menandatangani sertifikat mereka sendiri, browser memperingatkan pengguna bahwa tidak ada otoritas yang dikenal yang menandatangani sertifikat. Browser dan bertanya kepada pengguna apakah mereka ingin melanjutkan komunikasi dengan situs yang belum diverifikasi.
Sertifikat Server (Sertifikat Situs Web)
Sertifikat yang terkait dengan nama domain tertentu. Jika situs web memiliki sertifikat yang valid, itu berarti bahwa otoritas sertifikat telah mengambil langkah-langkah untuk memverifikasi bahwa alamat web sebenarnya milik organisasi tersebut. Saat Anda mengetikkan URL atau mengikuti tautan ke situs web aman, browser Anda memeriksa sertifikat untuk karakteristik berikut:
- Alamat situs web cocok dengan alamat pada sertifikat.
- Otoritas sertifikat yang dikenal browser sebagai otoritas tepercaya menandatangani sertifikat.
Terkadang pengguna dapat tersambung ke server dengan sertifikat yang tidak tepercaya. Azure Firewall menghilangkan koneksi seolah-olah server menghentikan koneksi.
Sertifikat CA Root (sertifikat kanal root)
Otoritas sertifikat dapat menerbitkan beberapa sertifikat dalam bentuk struktur pohon. Sertifikat akar adalah sertifikat pohon teratas.
Azure Firewall Premium dapat memotong lalu lintas HTTP/S keluar dan secara otomatis menghasilkan sertifikat server untuk www.website.com. Sertifikat ini dibuat menggunakan sertifikat CA Menengah yang Anda berikan. Browser pengguna akhir dan aplikasi klien (IaaS, PaaS, dan beban kerja lainnya) harus memercayai sertifikat CA akar organisasi Anda atau sertifikat CA menengah agar prosedur ini berfungsi.
Persyaratan sertifikat CA menengah
Pastikan sertifikat CA Anda mematuhi persyaratan berikut:
Saat disebarkan sebagai rahasia Key Vault, Anda harus menggunakan PFX tanpa Kata Sandi (PKCS12) dengan sertifikat dan kunci privat. Sertifikat PEM tidak didukung.
Sertifikat harus berupa sertifikat tunggal dan tidak mencakup seluruh rantai sertifikat.
Ini harus berlaku selama satu tahun ke depan.
Ini harus berupa key pribadi RSA dengan ukuran minimal 4096 byte.
Sertifikat harus memiliki ekstensi
KeyUsageyang ditandai sebagai Kritikal dengan flagKeyCertSign(RFC 5280; 4.2.1.3 Penggunaan Kunci).Sertifikat harus memiliki ekstensi
BasicConstraintsyang ditandai sebagai Penting (RFC 5280; 4.2.1.9 Batasan Dasar).Flag
CAharus diatur ke TRUE.Panjang Jalur harus lebih dari atau sama dengan satu.
Ini harus dapat diekspor.
Azure Key Vault
Azure Key Vault adalah penyimpanan rahasia yang dikelola platform yang bisa Anda gunakan untuk melindungi rahasia, kunci, dan sertifikat TLS/SSL. Azure Firewall Premium mendukung integrasi dengan Key Vault untuk sertifikat server yang dilampirkan ke Kebijakan Firewall.
Untuk mengonfigurasi key vault Anda:
- Simpan sertifikat CA perantara Anda sebagai rahasia Key Vault menggunakan file PFX yang dikodekan tanpa kata sandi dan base-64. File PFX adalah sertifikat digital yang berisi kunci privat dan kunci publik. Azure Firewall mengakses sertifikat secara eksklusif melalui antarmuka Rahasia Key Vault.
- Atau, Anda dapat mengimpor sertifikat menggunakan fitur Sertifikat Key Vault. Saat Anda melakukan ini, Key Vault secara otomatis membuat rahasia yang sesuai dengan nama yang sama, yang digunakan Azure Firewall untuk mengakses sertifikat. Menggunakan fitur Sertifikat disarankan karena memungkinkan Anda mengonfigurasi pemberitahuan kedaluwarsa.
- Setelah Anda menyimpan sertifikat, tentukan kebijakan akses di Key Vault untuk memberikan identitas terkelola izin Baca dan Tampilkan di bawah Izin Rahasia.
Catatan
Azure Firewall tidak mendukung akses sertifikat yang disimpan hanya sebagai objek Sertifikat Key Vault tanpa rahasia yang sesuai. Terlepas dari cara Anda mengimpor sertifikat, identitas terkelola harus memiliki izin Rahasia (bukan izin Sertifikat) pada brankas kunci.
- Sertifikat CA yang disediakan harus dipercaya oleh beban kerja Azure Anda. Pastikan mereka ditempatkan dengan benar.
- Karena Azure Firewall Premium terdaftar sebagai Layanan Tepercaya Key Vault, hal ini memungkinkan Anda untuk melewati Firewall internal Key Vault dan menghilangkan paparan Key Vault Anda dari Internet.
Catatan
Setiap kali Anda mengimpor sertifikat FIREWALL CA baru ke Azure Key Vault (baik untuk pertama kalinya atau mengganti sertifikasi CA yang kedaluwarsa), Anda harus secara eksplisit memperbarui pengaturan Azure Firewall Policy TLS dengan sertifikat baru.
Anda dapat membuat atau menggunakan ulang identitas terkelola yang ditetapkan pengguna yang digunakan Azure Firewall untuk mengambil sertifikat dari Key Vault atas nama Anda. Untuk informasi selengkapnya, lihat Apa itu identitas terkelola untuk sumber daya Azure?
Catatan
Kontrol akses berbasis peran Azure (Azure RBAC) saat ini tidak didukung untuk otorisasi. Gunakan model kebijakan akses sebagai gantinya. Untuk informasi selengkapnya, lihat Kontrol akses berbasis peran Azure (Azure RBAC) vs. kebijakan akses.
Mengonfigurasi sertifikat dalam kebijakan Anda
Untuk mengonfigurasi sertifikat CA dalam kebijakan Firewall Premium Anda, pilih kebijakan Anda lalu pilih inspeksi TLS. Pilih Aktif pada halaman inspeksi TLS. Lalu pilih sertifikat CA Anda di Azure Key Vault, seperti yang ditunjukkan dalam gambar berikut:
Penting
Untuk melihat dan mengonfigurasi sertifikat dari portal Microsoft Azure, Anda harus menambahkan akun pengguna Azure Anda ke kebijakan Akses Key Vault. Berikan akun pengguna Anda Get dan List di bawah Hak Akses Rahasia.
Buat sertifikat CA Anda sendiri yang ditandatangani sendiri
Jika Anda ingin membuat sertifikat Anda sendiri ntuk membantu Anda menguji dan memverifikasi inspeksi TLS, Anda dapat menggunakan skrip berikut untuk membuat CA Root dan CA Menengah yang ditandatangani sendiri.
Penting
Untuk produksi, Anda harus menggunakan PKI perusahaan Anda untuk membuat sertifikat CA Menengah. PKI perusahaan menggunakan infrastruktur yang ada dan menangani distribusi CA Root ke semua perangkat titik akhir. Untuk informasi selengkapnya, lihat Menyebarkan dan mengonfigurasi sertifikat CA Perusahaan untuk Azure Firewall.
Ada dua versi skrip:
- skrip bash
cert.sh - Skrip PowerShell
cert.ps1
Selain itu, kedua skrip menggunakan file konfigurasi openssl.cnf. Untuk menggunakan skrip, salin isi dari openssl.cnf, dan cert.shatau cert.ps1 ke komputer lokal Anda.
Skrip menghasilkan file berikut:
- rootCA.crt/rootCA.key - Sertifikat publik CA Root dan kunci pribadi.
- interCA.crt/interCA.key - Sertifikat publik CA menengah dan key pribadi
- interCA.pfx - Paket CA menengah pkcs12 yang digunakan firewall
Penting
rootCA.key harus disimpan di lokasi offline yang aman. Skrip menghasilkan sertifikat dengan validitas 1024 hari. Skrip memerlukan biner openssl yang terinstal di komputer lokal Anda. Untuk informasi lebih lanjut, lihat https://www.openssl.org/
Setelah sertifikat dibuat, sebarkan ke lokasi berikut:
- rootCA.crt - Terapkan pada komputer titik akhir (Hanya sertifikat publik).
- interCA.pfx - Simpan sebagai rahasia di Azure Key Vault dan tetapkan ke kebijakan firewall.
openssl.cnf
[ req ]
default_bits = 4096
distinguished_name = req_distinguished_name
string_mask = utf8only
default_md = sha512
[ req_distinguished_name ]
countryName = Country Name (2 letter code)
stateOrProvinceName = State or Province Name
localityName = Locality Name
0.organizationName = Organization Name
organizationalUnitName = Organizational Unit Name
commonName = Common Name
emailAddress = Email Address
[ rootCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ interCA_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true, pathlen:1
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
[ server_ext ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:false
keyUsage = critical, digitalSignature
extendedKeyUsage = serverAuth
Skrip bash - cert.sh
#!/bin/bash
# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 1024 -out rootCA.crt -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA" -config openssl.cnf -extensions rootCA_ext
# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj "/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA"
# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 1024 -sha256 -extfile openssl.cnf -extensions interCA_ext
# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password "pass:"
echo ""
echo "================"
echo "Successfully generated root and intermediate CA certificates"
echo " - rootCA.crt/rootCA.key - Root CA public certificate and private key"
echo " - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
echo " - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
echo "================"
PowerShell - cert.ps1
# Create root CA
openssl req -x509 -new -nodes -newkey rsa:4096 -keyout rootCA.key -sha256 -days 3650 -out rootCA.crt -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Root CA' -config openssl.cnf -extensions rootCA_ext
# Create intermediate CA request
openssl req -new -nodes -newkey rsa:4096 -keyout interCA.key -sha256 -out interCA.csr -subj '/C=US/ST=US/O=Self Signed/CN=Self Signed Intermediate CA'
# Sign on the intermediate CA
openssl x509 -req -in interCA.csr -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out interCA.crt -days 3650 -sha256 -extfile openssl.cnf -extensions interCA_ext
# Export the intermediate CA into PFX
openssl pkcs12 -export -out interCA.pfx -inkey interCA.key -in interCA.crt -password 'pass:'
Write-Host ""
Write-Host "================"
Write-Host "Successfully generated root and intermediate CA certificates"
Write-Host " - rootCA.crt/rootCA.key - Root CA public certificate and private key"
Write-Host " - interCA.crt/interCA.key - Intermediate CA public certificate and private key"
Write-Host " - interCA.pfx - Intermediate CA pkcs12 package which could be uploaded to Key Vault"
Write-Host "================"
Pembuatan sertifikat otomatis
Untuk penyebaran non-produksi, Anda dapat menggunakan mekanisme Pembuatan Otomatis Sertifikasi Premium Azure Firewall, yang secara otomatis membuat tiga sumber daya berikut untuk Anda:
- Identitas Terkelola
- Key Vault
- Sertifikat CA Root yang ditandatangani sendiri
Cukup pilih identitas yang dikelola baru, dan identitas tersebut mengikat tiga sumber daya bersama dalam kebijakan Premium Anda dan menyiapkan inspeksi TLS.
Pemecahan Masalah
Jika sertifikat CA Anda valid, tetapi Anda tidak dapat mengakses FQDN atau URL dalam inspeksi TLS, periksa hal berikut:
Pastikan sertifikat server web valid.
Pastikan sertifikat CA Akar diinstal pada sistem operasi klien.
Pastikan klien browser atau HTTPS memuat sertifikat akar yang valid. Firefox dan beberapa browser lainnya mungkin memiliki kebijakan sertifikasi khusus.
Pastikan jenis tujuan URL dalam aturan aplikasi Anda mencakup jalur dan hyperlink lain yang disematkan di halaman HTML tujuan yang benar. Anda dapat menggunakan wildcard untuk memudahkan jangkauan jalur URL yang diperlukan sepenuhnya.