Certyfikaty usługi Azure Firewall — wersja Premium

  • Artykuł

Aby prawidłowo skonfigurować inspekcję protokołu TLS usługi Azure Firewall w warstwie Premium, należy podać prawidłowy certyfikat pośredniego urzędu certyfikacji i złożyć go w usłudze Azure Key Vault.

Certyfikaty używane przez usługę Azure Firewall — wersja Premium

W typowym wdrożeniu są używane trzy typy certyfikatów:

  • Certyfikat pośredniego urzędu certyfikacji (certyfikat urzędu certyfikacji)

    Urząd certyfikacji to organizacja, która jest zaufana do podpisywania certyfikatów cyfrowych. Urząd certyfikacji weryfikuje tożsamość i legitymację firmy lub osoby żądającej certyfikatu. Jeśli weryfikacja zakończy się pomyślnie, urząd certyfikacji wystawia podpisany certyfikat. Gdy serwer przedstawia certyfikat klientowi (na przykład przeglądarkę internetową) podczas uzgadniania protokołu SSL/TLS, klient próbuje zweryfikować podpis pod listą znanych dobrych osób podpisujących. Przeglądarki internetowe zwykle są dostarczane z listami urzędów certyfikacji, którym niejawnie ufają w celu identyfikowania hostów. Jeśli urząd nie znajduje się na liście, podobnie jak w przypadku niektórych witryn podpisujących własne certyfikaty, przeglądarka powiadamia użytkownika, że certyfikat nie jest podpisany przez uznany urząd i pyta użytkownika, czy chce kontynuować komunikację z niezweryfikowaną witryną.

  • Certyfikat serwera (certyfikat witryny sieci Web)

    Certyfikat skojarzony z określoną nazwą domeny. Jeśli witryna internetowa ma prawidłowy certyfikat, oznacza to, że urząd certyfikacji podjął kroki w celu sprawdzenia, czy adres internetowy rzeczywiście należy do tej organizacji. Po wpiseniu adresu URL lub kliknięciu linku do bezpiecznej witryny internetowej przeglądarka sprawdza certyfikat pod kątem następujących cech:

    • Adres witryny internetowej odpowiada adresowi certyfikatu.
    • Certyfikat jest podpisany przez urząd certyfikacji rozpoznawany przez przeglądarkę jako zaufany urząd.

    Czasami użytkownicy mogą łączyć się z serwerem z niezaufanym certyfikatem. Usługa Azure Firewall usunie połączenie tak, jakby serwer przerwał połączenie.

  • Certyfikat głównego urzędu certyfikacji (certyfikat główny)

    Urząd certyfikacji może wystawiać wiele certyfikatów w postaci struktury drzewa. Certyfikat główny jest najbardziej najlepszym certyfikatem drzewa.

Usługa Azure Firewall Premium może przechwytywać wychodzący ruch HTTP/S i automatycznie generować certyfikat serwera dla usługi www.website.com. Ten certyfikat jest generowany przy użyciu podanego certyfikatu pośredniego urzędu certyfikacji. Przeglądarka użytkownika końcowego i aplikacje klienckie (IaaS, PaaS i inne obciążenia) muszą ufać certyfikatowi głównego urzędu certyfikacji organizacji lub certyfikatowi pośredniego urzędu certyfikacji, aby ta procedura działała.

Certificate process

Wymagania dotyczące certyfikatu pośredniego urzędu certyfikacji

Upewnij się, że certyfikat urzędu certyfikacji spełnia następujące wymagania:

  • W przypadku wdrożenia jako wpisu tajnego usługi Key Vault należy użyć klucza PFX bez hasła (PKCS12) z certyfikatem i kluczem prywatnym. Certyfikaty PEM nie są obsługiwane.

  • Musi to być pojedynczy certyfikat i nie powinien zawierać całego łańcucha certyfikatów.

  • Musi być ważny przez jeden rok do przodu.

  • Musi to być klucz prywatny RSA o minimalnym rozmiarze 4096 bajtów.

  • Musi mieć KeyUsage rozszerzenie oznaczone jako Krytyczne z flagą KeyCertSign (RFC 5280; 4.2.1.3 Użycie klucza).

  • Musi mieć BasicConstraints rozszerzenie oznaczone jako Krytyczne (RFC 5280; 4.2.1.9 Podstawowe ograniczenia).

  • Flaga musi być ustawiona CA na wartość TRUE.

  • Długość ścieżki musi być większa lub równa jednej.

  • Musi być eksportowalny.

Azure Key Vault

Usługa Azure Key Vault to zarządzany przez platformę magazyn wpisów tajnych, którego można użyć do ochrony wpisów tajnych, kluczy i certyfikatów TLS/SSL. Usługa Azure Firewall Premium obsługuje integrację z usługą Key Vault dla certyfikatów serwera dołączonych do zasad zapory.

Aby skonfigurować magazyn kluczy:

  • Musisz zaimportować istniejący certyfikat z parą kluczy do magazynu kluczy.
  • Alternatywnie możesz również użyć wpisu tajnego magazynu kluczy przechowywanego jako plik PFX zakodowany w formacie base-64 bez hasła. Plik PFX to certyfikat cyfrowy zawierający zarówno klucz prywatny, jak i klucz publiczny.
  • Zaleca się użycie importu certyfikatu urzędu certyfikacji, ponieważ umożliwia skonfigurowanie alertu na podstawie daty wygaśnięcia certyfikatu.
  • Po zaimportowaniu certyfikatu lub wpisu tajnego należy zdefiniować zasady dostępu w magazynie kluczy, aby umożliwić przyznanie tożsamości dostępu do certyfikatu/wpisu tajnego.
  • Podany certyfikat urzędu certyfikacji musi być zaufany przez obciążenie platformy Azure. Upewnij się, że są one prawidłowo wdrożone.
  • Ponieważ usługa Azure Firewall Premium jest wymieniona jako zaufana usługa Key Vault, umożliwia obejście wewnętrznej zapory usługi Key Vault i wyeliminowanie jakichkolwiek ekspozycji usługi Key Vault na Internet.

Uwaga

Za każdym razem, gdy importujesz nowy certyfikat urzędu certyfikacji zapory do usługi Azure Key Vault (po raz pierwszy lub zastępując wygasły certyfikat urzędu certyfikacji), należy jawnie zaktualizować ustawienie TLS zasad usługi Azure Firewall przy użyciu nowego certyfikatu.

Możesz utworzyć lub ponownie użyć istniejącej tożsamości zarządzanej przypisanej przez użytkownika, której usługa Azure Firewall używa do pobierania certyfikatów z usługi Key Vault w Twoim imieniu. Aby uzyskać więcej informacji, zobacz Co to są tożsamości zarządzane dla zasobów platformy Azure?

Uwaga

Kontrola dostępu oparta na rolach (RBAC) platformy Azure nie jest obecnie obsługiwana do autoryzacji. Zamiast tego użyj modelu zasad dostępu. Aby uzyskać więcej informacji, zobacz Azure role-based access control (Azure RBAC) vs. access policies (Kontrola dostępu oparta na rolach platformy Azure) a zasady dostępu.

Konfigurowanie certyfikatu w zasadach

Aby skonfigurować certyfikat urzędu certyfikacji w zasadach zapory Premium, wybierz zasady, a następnie wybierz pozycję Inspekcja protokołu TLS. Wybierz pozycję Włączone na stronie inspekcjiprotokołu TLS. Następnie wybierz certyfikat urzędu certyfikacji w usłudze Azure Key Vault, jak pokazano na poniższym rysunku:

Azure Firewall Premium overview diagram

Ważne

Aby wyświetlić i skonfigurować certyfikat w witrynie Azure Portal, musisz dodać konto użytkownika platformy Azure do zasad dostępu usługi Key Vault. Nadaj swojemu kontu użytkownika pozycję Pobierz i wyświetl listę w obszarze Uprawnienia wpisu tajnego. Azure Key Vault Access policy

Tworzenie własnego certyfikatu urzędu certyfikacji z podpisem własnym

Jeśli chcesz utworzyć własne certyfikaty, aby ułatwić testowanie i weryfikowanie inspekcji protokołu TLS, możesz użyć następujących skryptów, aby utworzyć własny certyfikat główny z podpisem własnym i pośredni urząd certyfikacji.

Ważne

W środowisku produkcyjnym należy użyć firmowej infrastruktury kluczy publicznych do utworzenia certyfikatu pośredniego urzędu certyfikacji. Korporacyjna infrastruktura kluczy publicznych korzysta z istniejącej infrastruktury i obsługuje dystrybucję głównego urzędu certyfikacji do wszystkich maszyn punktów końcowych. Aby uzyskać więcej informacji, zobacz Wdrażanie i konfigurowanie certyfikatów urzędu certyfikacji przedsiębiorstwa dla usługi Azure Firewall.

Istnieją dwie wersje tego skryptu:

  • skrypt powłoki bash cert.sh
  • skrypt programu PowerShell cert.ps1

Ponadto oba skrypty używają openssl.cnf pliku konfiguracji. Aby użyć skryptów, skopiuj zawartość openssl.cnfelementu i cert.sh lub cert.ps1 na komputer lokalny.

Skrypty generują następujące pliki:

  • rootCA.crt/rootCA.key — certyfikat publiczny i klucz prywatny głównego urzędu certyfikacji.
  • interCA.crt/interCA.key — certyfikat publiczny pośredniego urzędu certyfikacji i klucz prywatny
  • interCA.pfx — pakiet pkcs12 pośredniego urzędu certyfikacji, który będzie używany przez zaporę

Ważne

rootCA.key powinien być przechowywany w bezpiecznej lokalizacji offline. Skrypty generują certyfikat z ważnością 1024 dni. Skrypty wymagają plików binarnych openssl zainstalowanych na komputerze lokalnym. Aby uzyskać więcej informacji, zobacz https://www.openssl.org/

Po utworzeniu certyfikatów wdróż je w następujących lokalizacjach:

  • rootCA.crt — wdrażanie na maszynach z punktami końcowymi (tylko certyfikat publiczny).
  • interCA.pfx — importowanie jako certyfikatu w usłudze Key Vault i przypisywanie ich do zasad zapory.

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

Skrypt powłoki 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 "================"

Automatyczne generowanie certyfikatów

W przypadku wdrożeń nieprodukcyjnych można użyć mechanizmu automatycznego generowania automatycznej certyfikacji usługi Azure Firewall w warstwie Premium, który automatycznie tworzy następujące trzy zasoby:

  • Tożsamość zarządzana
  • Magazyn kluczy
  • Certyfikat głównego urzędu certyfikacji z podpisem własnym

Wystarczy wybrać nową tożsamość zarządzaną i połączyć trzy zasoby razem w zasadach Premium i skonfigurować inspekcję protokołu TLS.

Screenshot showing auto-generated certificates.

Rozwiązywanie problemów

Jeśli certyfikat urzędu certyfikacji jest ważny, ale nie możesz uzyskać dostępu do nazw FQDN lub adresów URL w ramach inspekcji protokołu TLS, sprawdź następujące elementy:

  • Upewnij się, że certyfikat serwera internetowego jest prawidłowy.

  • Upewnij się, że certyfikat głównego urzędu certyfikacji jest zainstalowany w systemie operacyjnym klienta.

  • Upewnij się, że przeglądarka lub klient HTTPS zawiera prawidłowy certyfikat główny. Firefox i niektóre inne przeglądarki mogą mieć specjalne zasady certyfikacji.

  • Upewnij się, że typ docelowy adresu URL w regule aplikacji obejmuje poprawną ścieżkę i wszystkie inne hiperlinki osadzone na docelowej stronie HTML. Symbole wieloznaczne umożliwiają łatwe pokrycie całej wymaganej ścieżki adresu URL.

Następne kroki