Cloud HSM-Schlüssel für TLS-Offloading mit NGINX verwenden

In dieser Anleitung wird beschrieben, wie Sie NGINX einrichten, um einen Cloud HSM-Schlüssel für die TLS-Auslagerung unter Debian 11 (Bullseye) zu verwenden. Möglicherweise müssen Sie diese Befehle an Ihr Betriebssystem oder Ihre Linux-Distribution anpassen.

Eine auf Terraform basierende Blueprint-Version dieser Anleitung finden Sie im GitHub-Repository „kms-solutions“.

Anwendungsfälle

Die Verwendung eines Cloud HSM-Schlüssels mit NGINX für die TLS-Auslagerung trägt dazu bei, die folgenden Sicherheitsanforderungen von Unternehmen zu erfüllen:

Sie möchten, dass Ihr NGINX-Webserver TLS-kryptografische Vorgänge an Cloud HSM auslagert.
Sie möchten den privaten Schlüssel Ihres Zertifikats nicht im lokalen Dateisystem der Compute Engine-Instanz speichern, auf der Ihre Webanwendung gehostet wird.
Sie müssen behördliche Anforderungen erfüllen, bei denen Zertifikate für öffentlich zugängliche Anwendungen durch ein HSM mit FIPS 140-2 Level 3-Zertifizierung geschützt werden müssen.
Sie möchten NGINX verwenden, um einen Reverse-Proxy mit TLS-Terminierung zu erstellen, um Ihre Webanwendung zu schützen.

Hinweise

Führen Sie zuerst die Schritte unter Cloud HSM-Schlüssel mit OpenSSL verwenden aus.

Prüfen Sie nach Abschluss der OpenSSL-Einrichtung, ob eine aktuelle Version von nginx installiert ist:

sudo apt-get update
sudo apt-get install libengine-pkcs11-openssl opensc nginx

Empfehlungen für die Sicherheitskonfiguration

Sichern Sie die Instanz, auf der NGINX gehostet wird, mit den folgenden Empfehlungen:

Folgen Sie der Anleitung zum Erstellen und Aktivieren von Dienstkonten für Instanzen, um NGINX zu hosten.
1. Weisen Sie die folgenden Rollen zu:
  - roles/cloudkms.signerVerifier
  - roles/cloudkms.viewer
Konfigurieren Sie Organisationsrichtlinien so, dass externe IP-Adressen und die Erstellung von Dienstkontoschlüsseln eingeschränkt werden.
- constraints/compute.vmExternalIpAccess
- constraints/iam.disableServiceAccountKeyCreation
Erstellen Sie ein benutzerdefiniertes Subnetz, das den privaten Google-Zugriff ermöglicht.
Firewallregeln konfigurieren.
- Erstellen Sie IAP-Firewallregeln nur für SSH.
Erstellen Sie eine Linux-VM und konfigurieren Sie sie so:
- Wählen Sie das richtige Dienstkonto aus, das Sie zuvor erstellt haben.
- Wählen Sie das Netzwerk aus, das Sie zuvor erstellt haben.
  - Fügen Sie für alle Firewallregeln die entsprechenden Labels hinzu.
  - Prüfen Sie, ob das Feld „externe IP“ für das Subnetz auf none festgelegt ist.
Weisen Sie Ihrer Identität die Rolle „Nutzer IAP-gesicherter Tunnel“ (roles/iap.tunnelResourceAccessor) für die Instanz zu.
- Weitere Informationen finden Sie unter IAP-Konfiguration für Compute.

Cloud HSM-Signaturschlüssel erstellen und konfigurieren

In den nächsten Abschnitten werden die Schritte beschrieben, die zum Erstellen und Konfigurieren eines Cloud HSM-Signaturschlüssels erforderlich sind.

Von Cloud HSM gehosteten Signaturschlüssel erstellen

Erstellen Sie in IhremGoogle Cloud -Projekt einen Cloud HSM-Signaturschlüssel EC-P256-SHA256 im Schlüsselbund, den Sie zuvor für OpenSSL konfiguriert haben:

gcloud kms keys create NGINX_KEY \
  --keyring "KEY_RING" --project "PROJECT_ID" \
  --location "LOCATION" --purpose "asymmetric-signing" \
  --default-algorithm "ec-sign-p256-sha256" --protection-level "hsm"

Über SSH und IAP eine Verbindung zur VM herstellen

Stellen Sie mit dem folgenden Befehl eine SSH-Verbindung zu Ihrer VM her und verwenden Sie dabei IAP:

gcloud compute ssh INSTANCE \
  --zone ZONE --tunnel-through-iap

Wenn ein Problem auftritt, prüfen Sie, ob Sie das Flag --tunnel-through-iap verwendet haben. Prüfen Sie außerdem, ob Sie die Rolle „Nutzer IAP-gesicherter Tunnel“ (roles/iap.tunnelResourceAccessor) für die Identität haben, die mit der gcloud CLI authentifiziert wurde.

Zertifikat mit OpenSSL erstellen

Erstellen Sie für eine Produktionsumgebung eine Anfrage für die Signierung des Zertifikats (Certificate Signing Request, CSR). Beispiel zum Generieren eines CSR Stellen Sie der Zertifizierungsstelle (CA) den CSR zur Verfügung, damit sie ein Zertifikat für Sie erstellen kann. Verwenden Sie das von Ihrer Zertifizierungsstelle bereitgestellte Zertifikat in den nachfolgenden Abschnitten.

Zu Testzwecken können Sie ein selbst signiertes Zertifikat mit dem Cloud HSM-Signaturschlüssel generieren. Dazu können Sie mit OpenSSL PKCS #11-URIs anstelle eines regulären Pfads verwenden und den Schlüssel anhand seines Labels (für Cloud KMS-Schlüssel, der dem CryptoKey-Namen entspricht) identifizieren.

openssl req -new -x509 -days 3650 -subj '/CN=CERTIFICATE_NAME/' \
  DIGEST_FLAG -engine pkcs11 -keyform engine \
  -key PKCS_KEY_TYPE=KEY_IDENTIFIER > CA_CERT

Ersetzen Sie Folgendes:

CERTIFICATE_NAME ist ein Name für das Zertifikat.
DIGEST_FLAG: Der Digest-Algorithmus, der vom asymmetrischen Signaturschlüssel verwendet wird. Verwenden Sie je nach Schlüssel -sha256, -sha384 oder -sha512.
PKCS_KEY_TYPE: Der Typ der Kennung, die zum Identifizieren des Schlüssels verwendet wird. Wenn Sie die aktuelle Schlüsselversion verwenden möchten, verwenden Sie pkcs11:object mit dem Namen des Schlüssels. Wenn Sie eine bestimmte Schlüsselversion verwenden möchten, verwenden Sie pkcs11:id mit der vollständigen Ressourcen-ID der Schlüsselversion.
KEY_IDENTIFIER: Eine Kennung für den Schlüssel. Wenn Sie pkcs11:object verwenden, geben Sie den Namen des Schlüssels ein, z. B. NGINX_KEY. Wenn Sie pkcs11:id verwenden, geben Sie die vollständige Ressourcen-ID des Schlüssels oder der Schlüsselversion an, z. B. projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/NGINX_KEY/cryptoKeyVersions/KEY_VERSION.
CA_CERT: der Pfad, in dem Sie die Zertifikatsdatei speichern möchten.

Wenn der Befehl fehlschlägt, wurde PKCS11_MODULE_PATH möglicherweise falsch festgelegt oder Sie haben nicht die erforderlichen Berechtigungen zur Verwendung des Cloud KMS-Signaturschlüssels.

Sie sollten jetzt ein Zertifikat haben, das so aussieht:

-----BEGIN CERTIFICATE-----
...
...
...
-----END CERTIFICATE-----

Zertifikat für NGINX installieren

Führen Sie die folgenden Befehle aus, um einen Speicherort für Ihr öffentliches Zertifikat zu erstellen:

sudo mkdir /etc/ssl/nginx
sudo mv CA_CERT /etc/ssl/nginx

Umgebung für die Verwendung der PKCS #11-Bibliothek konfigurieren

In den nächsten Abschnitten werden die Schritte beschrieben, die zum Vorbereiten und Testen Ihrer Umgebung erforderlich sind.

Bibliothekskonfigurationen für NGINX vorbereiten

Ermöglichen Sie NGINX, die PKCS #11-Engine-Vorgänge mit der Bibliothek zu protokollieren:

sudo mkdir /var/log/kmsp11
sudo chown www-data /var/log/kmsp11

Erstellen Sie eine leere Bibliothekskonfigurationsdatei mit den entsprechenden Berechtigungen für NGINX.

sudo touch /etc/nginx/pkcs11-config.yaml
sudo chmod 744 /etc/nginx/pkcs11-config.yaml

Bearbeiten Sie die leere Konfigurationsdatei und fügen Sie die erforderliche Konfiguration hinzu, wie im folgenden Snippet gezeigt:

# cat /etc/nginx/pkcs11-config.yaml
---
tokens:
  - key_ring: "projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING"
log_directory: "/var/log/kmsp11"

OpenSSL-Konfiguration testen

Führen Sie dazu diesen Befehl aus:

openssl engine -tt -c -v pkcs11

Die Ausgabe sollte in etwa so aussehen:

(pkcs11) pkcs11 engine
 [RSA, rsaEncryption, id-ecPublicKey]
     [ available ]
     SO_PATH, MODULE_PATH, PIN, VERBOSE, QUIET, INIT_ARGS, FORCE_LOGIN

NGINX für die Verwendung von Cloud HSM konfigurieren

TLS-Offloading zulassen, indem Sie einige NGINX-Dateien bearbeiten. Bearbeiten Sie zuerst die Datei /etc/nginx/nginx.conf an zwei Stellen, um einige Direktiven hinzuzufügen, mit denen NGINX für die Verwendung von PKCS #11 konfiguriert wird.

Fügen Sie nach dem Block event und vor dem Block http die folgenden Direktiven hinzu:

ssl_engine pkcs11;
env KMS_PKCS11_CONFIG=/etc/nginx/pkcs11-config.yaml;

Konfigurieren Sie in derselben /etc/nginx/nginx.conf-Datei SSL-Direktiven, um Ihr Zertifikat und den zugehörigen privaten Schlüssel in Cloud HSM zu verwenden. Fügen Sie dem Block http die folgenden Attribute hinzu:

ssl_certificate "/etc/ssl/nginx/CA_CERT";
ssl_certificate_key "engine:pkcs11:PKCS_KEY_TYPE=KEY_IDENTIFIER";
ssl_protocols TLSv1.2 TLSv1.3; # Consider changing the default to only TLS1.2 or newer

# Consider defining the `ssl_ciphers` to use ciphers approved by your security teams and handle
# appropriate client compatibility requirements.

Ihre /etc/nginx/nginx.conf-Datei sollte so aussehen:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}

ssl_engine pkcs11;
env KMS_PKCS11_CONFIG=/etc/nginx/pkcs11-config.yaml;

http {

        #...
        #...

        # SSL configuration
        ssl_certificate "/etc/ssl/nginx/CA_CERT";
        ssl_certificate_key "engine:pkcs11:pkcs11:object=NGINX_KEY";
        ssl_protocols TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        # ssl_ciphers YOUR_CIPHERS
        ssl_prefer_server_ciphers on;

        #...
        #...

}

NGINX für das Abhören von TLS-Traffic konfigurieren

Bearbeiten Sie die Datei /etc/nginx/sites-enabled/default, um TLS-Traffic zu überwachen. Entfernen Sie die Kommentarzeichen für die SSL-Konfiguration im Block server. Die resultierende Änderung sollte so aussehen:


server {
        listen 80 default_server;
        listen [::]:80 default_server;

        # SSL configuration
        listen 443 ssl default_server;
        listen [::]:443 ssl default_server;

        # ...
        # ...
}

Umgebungsvariablen für den NGINX-Dienst bereitstellen

Führen Sie dazu diesen Befehl aus:

sudo systemctl edit nginx.service

Fügen Sie im resultierenden Editor die folgenden Zeilen hinzu und ersetzen Sie LIBPATH durch den Wert für den Speicherort, an dem Sie libkmsp11.so installiert haben:

[Service]
Environment="GRPC_ENABLE_FORK_SUPPORT=1"
Environment="KMS_PKCS11_CONFIG=/etc/nginx/pkcs11-config.yaml"
Environment="PKCS11_MODULE_PATH=LIBPATH/libkmsp11-1.0-linux-amd64/libkmsp11.so"

Nachdem Sie diese Werte konfiguriert haben, müssen Sie den folgenden Befehl ausführen, um sie verfügbar zu machen:

sudo systemctl daemon-reload

NGINX mit TLS-Offloading neu starten

Führen Sie den folgenden Befehl aus, damit NGINX neu gestartet wird und die aktualisierte Konfiguration verwendet:

sudo systemctl start nginx

Testen, ob NGINX TLS-Offloading für Ihr Cloud HSM verwendet

Verwenden Sie openssl s_client, um die Verbindung zu Ihrem NGINX-Server zu testen. Führen Sie dazu den folgenden Befehl aus:

openssl s_client -connect localhost:443

Der Client schließt den SSL-Handshake ab und wartet auf Ihre Eingabe:

# completes SSL handshake
# ...
# ...
# ...
    Verify return code: 18 (self signed certificate)
# ...
    Max Early Data: 0
---
read R BLOCK

# When the client pauses, it's waiting for instructions.
# Have the client get the index.html file in the root path (`/`), by typing the following:

GET /

# Press enter.
# You should now see the default NGINX index.html file.

In Ihren Audit-Logs sollten jetzt Vorgänge für Ihren NGINX_KEY-Schlüssel angezeigt werden. Wenn Sie die Logs ansehen möchten, rufen Sie in der Google Cloud Console Cloud Logging auf. Fügen Sie dem Projekt, das Sie verwendet haben, den folgenden Filter hinzu:

resource.type="cloudkms_cryptokeyversion"

Nachdem Sie die Abfrage ausgeführt haben, sollten Sie asymmetrische Schlüsselvorgänge für Ihren NGINX_KEY-Schlüssel sehen.

Optionale Konfigurationen

Möglicherweise müssen Sie einen externen Passthrough-Network-Load-Balancer erstellen, um Ihren NGINX-Server mit einer externen IP-Adresse verfügbar zu machen.

Wenn Sie NGINX als Reverse-Proxy mit Load-Balancing verwenden müssen, sollten Sie die NGINX-Konfigurationsdatei aktualisieren. Weitere Informationen zum Konfigurieren von NGINX als Reverse-Proxy finden Sie unter All-Active HA for NGINX Plus on the Google CloudPlatform.

Nächste Schritte

Sie haben Ihren NGINX-Server jetzt für die Verwendung von TLS-Offloading für Cloud HSM konfiguriert.