Diese Seite wurde von der Cloud Translation API übersetzt.

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 das TLS-Offloading unter Debian 11 (Bullseye) zu verwenden. Möglicherweise müssen Sie diese Befehle anpassen, damit sie mit Ihrem Betriebssystem oder Ihrer Linux-Distribution funktionieren.

Eine Terraform-basierte Blueprint-Version dieser Anleitung finden Sie im GitHub-Repository von kms-solutions.

Anwendungsfälle

Die Verwendung eines Cloud HSM-Schlüssels mit NGINX für das TLS-Offloading 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 sollten 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 die Zertifikate öffentlicher Anwendungen durch ein HSM mit der Zertifizierung FIPS 140-2 Level 3 geschützt werden müssen.
Sie möchten mit NGINX einen Reverse-Proxy mit TLS-Terminierung erstellen, um Ihre Webanwendung zu schützen.

Hinweise

Führen Sie vor dem Fortfahren 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

Schützen 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 die Organisationsrichtlinien so, dass externe IP-Adressen und das Erstellen von Dienstkontoschlüsseln eingeschränkt werden.
- constraints/compute.vmExternalIpAccess
- constraints/iam.disableServiceAccountKeyCreation
Erstellen Sie ein benutzerdefiniertes Subnetz, für das der private Google-Zugriff aktiviert ist.
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 allen Firewallregeln geeignete Labels hinzu.
  - Das Feld „Externe IP“ des Subnetzes muss auf none festgelegt sein.
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 die Compute-Umgebung.

Von Cloud KMS gehosteten Signaturschlüssel erstellen und konfigurieren

In den folgenden Abschnitten wird beschrieben, wie Sie einen von Cloud KMS gehosteten Signaturschlüssel erstellen und konfigurieren.

Von Cloud KMS gehosteten Signaturschlüssel erstellen

Erstellen Sie in IhremGoogle Cloud -Projekt einen Cloud KMS-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"

SSH-Verbindung zu Ihrer VM über IAP herstellen

Stellen Sie mit dem folgenden Befehl eine SSH-Verbindung zu Ihrer VM über IAP her:

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 die Rolle „Nutzer IAP-gesicherter Tunnel“ (roles/iap.tunnelResourceAccessor) für die Identität, die mit der gcloud CLI authentifiziert wurde, auf der Instanz vorhanden ist.

Zertifikat mit OpenSSL erstellen

Erstellen Sie für eine Produktionsumgebung eine CSR (Certificate Signing Request). Weitere Informationen finden Sie im Beispiel zum Erstellen eines CSR. Reichen Sie das CSR bei Ihrer Zertifizierungsstelle ein, damit diese ein Zertifikat für Sie erstellen kann. Verwenden Sie in den folgenden Abschnitten das von Ihrer Zertifizierungsstelle bereitgestellte Zertifikat.

Zu Übungszwecken können Sie ein selbst signiertes Zertifikat mit dem von Cloud KMS gehosteten 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: die Art der Kennung, die zum Identifizieren des Schlüssels verwendet wird. Wenn Sie die neueste 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, verwenden Sie den Namen des Schlüssels, z. B. NGINX_KEY. Wenn Sie pkcs11:id verwenden, verwenden Sie die vollständige Ressourcen-ID des Schlüssels oder der Schlüsselversion, z. B. projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/NGINX_KEY/cryptoKeyVersions/KEY_VERSION.
CA_CERT: Der Pfad, unter 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 das öffentliche 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 folgenden Abschnitten werden die Schritte zur Vorbereitung und zum Testen Ihrer Umgebung beschrieben.

Bibliothekskonfigurationen für NGINX vorbereiten

Erlauben Sie NGINX, seine 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 wie im folgenden Snippet gezeigt hinzu:

# 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 Anweisungen 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 Anweisungen hinzu:

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

Konfigurieren Sie in derselben /etc/nginx/nginx.conf-Datei SSL-Richtlinien, um Ihr Zertifikat und den zugehörigen privaten Schlüssel in Cloud HSM zu verwenden. Fügen Sie im 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 den Empfang von TLS-Traffic konfigurieren

Bearbeiten Sie die Datei /etc/nginx/sites-enabled/default, um auf TLS-Traffic zu lauschen. Entfernen Sie die Kommentarzeichen für die SSL-Konfiguration im Block server. Die resultierende Änderung sollte in etwa 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 angeben

Führen Sie dazu diesen Befehl aus:

sudo systemctl edit nginx.service

Fügen Sie im angezeigten 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 an Ihr Cloud HSM verwendet

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

openssl s_client -connect localhost:443

Der Client sollte den SSL-Handshake abschließen und eine Pause einlegen. Der Kunde wartet auf Ihre Antwort, wie unten dargestellt:

# 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.

Ihre Prüfprotokolle sollten jetzt Vorgänge für Ihren NGINX_KEY-Schlüssel enthalten. Rufen Sie in der Cloud Console „Cloud Logging“ auf, um die Logs aufzurufen. Fügen Sie dem verwendeten Projekt den folgenden Filter hinzu:

resource.type="cloudkms_cryptokeyversion"

Nach dem Ausführen der Abfrage 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 zu veröffentlichen.

Wenn Sie NGINX als Reverse-Proxy mit Load Balancing verwenden möchten, sollten Sie die NGINX-Konfigurationsdatei aktualisieren. Weitere Informationen zum Konfigurieren von NGINX als Reverse-Proxy finden Sie unter All-Active-HA für NGINX Plus auf der Google Cloud Platform.

Nächste Schritte

Sie haben Ihren NGINX-Server jetzt so konfiguriert, dass TLS-Offloading auf Cloud HSM verwendet wird.