Diese Seite wurde von der Cloud Translation API übersetzt.

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

Dieser Leitfaden enthält Anweisungen zum Einrichten von NGINX für die Verwendung eines Cloud HSM-Schlüssel für die TLS-Auslagerung unter Debian 11 (Bullseye). 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 in der kms-solutions GitHub-Repository

Anwendungsfälle

Die Verwendung eines Cloud HSM-Schlüssels mit NGINX für die TLS-Auslagerung hilft die folgenden Sicherheitsanforderungen von Unternehmen erfüllen:

Ihr NGINX-Webserver soll die TLS-Verschlüsselung auslagern. an Cloud HSM übertragen.
Sie möchten den privaten Schlüssel Ihres Zertifikats nicht im lokalen Dateisystem der Compute Engine-Instanz speichern, auf dem Ihr Web 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 NGINX verwenden, um einen Reverse-Proxy mit TLS zu 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.

Sobald die Einrichtung von OpenSSL abgeschlossen ist, prüfen Sie, ob eine aktuelle Version von nginx installiert ist installiert:

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

Empfehlungen für die Sicherheitskonfiguration

Schützen Sie Ihre Instanz, auf der NGINX gehostet wird, mit dem folgenden Empfehlungen:

Folgen Sie der Anleitung zum Erstellen und Aktivieren von Dienstkonten für Instanzen zum Hosten von NGINX.
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, privaten Google-Zugriff gewährt.
Firewallregeln konfigurieren.
- Erstellen Sie IAP-Firewallregeln nur für SSH.
Erstellen Sie eine Linux-VM und konfigurieren Sie sie so:
- Wählen Sie das 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.
  - Achten Sie darauf, dass das Subnetz die „externe IP-Adresse“ hat auf none festgelegt.
Ihrer Identität den Nutzer IAP-gesicherter Tunnel gewähren (roles/iap.tunnelResourceAccessor) für die Instanz.
- Weitere Informationen finden Sie unter IAP-Konfiguration für Computing.

Von Cloud KMS gehosteten Signaturschlüssel erstellen und konfigurieren

In den nächsten Abschnitten werden die Schritte beschrieben, die zum Erstellen und Konfigurieren eines In Cloud KMS gehosteter Signaturschlüssel.

In Cloud KMS gehosteten Signaturschlüssel erstellen

Erstellen Sie in Ihrem Google 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 zur VM mit IAP herstellen

Stellen Sie mit dem folgenden Befehl mithilfe von IAP eine SSH-Verbindung zu Ihrer VM 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 auf der Instanz vorhanden ist, 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). Weitere Informationen indem Sie das Beispiel zum Generieren einer CSR lesen. CSR angeben an Ihre Zertifizierungsstelle, damit diese ein Zertifikat für von dir. Verwenden Sie in den nachfolgenden Abschnitten das von Ihrer Zertifizierungsstelle bereitgestellte Zertifikat.

Beispielsweise können Sie ein selbst signiertes Zertifikat mit der Methode In Cloud KMS gehosteter Signaturschlüssel. Dazu können Sie mit OpenSSL PKCS #11-URIs anstelle eines regulären Pfads, der den Schlüssel anhand seines Labels identifiziert (Bei Cloud KMS-Schlüsseln ist das Label der CryptoKey-Name.)

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 von der asymmetrischen Signatur verwendete Digest-Algorithmus . Verwenden Sie je nach Schlüssel -sha256, -sha384 oder -sha512.
PKCS_KEY_TYPE: der ID-Typ, der zur Identifizierung des Schlüssels verwendet wird. Verwenden Sie pkcs11:object mit dem Namen des Schlüssels, um die neueste Schlüsselversion zu verwenden. Bis eine bestimmte Schlüsselversion, 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, geben Sie die vollständige Ressourcen-ID des Schlüssels oder Schlüssels an. Version, z. B. projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/NGINX_KEY/cryptoKeyVersions/KEY_VERSION.
CA_CERT: Pfad, unter dem Sie das Zertifikat speichern möchten -Datei.

Wenn der Befehl fehlschlägt, wurde PKCS11_MODULE_PATH möglicherweise falsch festgelegt. oder Sie haben nicht die erforderlichen Berechtigungen, Signaturschlüssel.

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 Standort für Ihre öffentliche Zertifikat:

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

Zulassen, dass NGINX seine PKCS #11-Engine-Vorgänge mit dem mit Folgendem:

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 in der folgendes Snippet:

# 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

Lassen Sie die TLS-Auslagerung zu, 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 Folgendes hinzu: Anweisungen:

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 in den Block http den Parameter folgende Attribute:

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 TLS-Traffic zu überwachen. 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 bereitstellen

Führen Sie dazu diesen Befehl aus:

sudo systemctl edit nginx.service

Fügen Sie im daraufhin angezeigten Editor die folgenden Zeilen hinzu und ersetzen Sie LIBPATH durch den Wert des Standorts, an dem Sie die App installiert haben libkmsp11.so:

[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 zur Verfügung stellen:

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:

sudo systemctl start nginx

Test-NGINX verwendet TLS-Auslagerung an Cloud HSM

Testen Sie mit openssl s_client die Verbindung zu Ihrem NGINX-Server, indem Sie und führen Sie 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"

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

Optionale Konfigurationen

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

Wenn Sie NGINX als Reverse-Proxy mit Load-Balancing verwenden müssen, die NGINX-Konfigurationsdatei zu aktualisieren. Weitere Informationen über Konfigurieren von NGINX als Reverse-Proxy, indem Aktive Hochverfügbarkeit für NGINX Plus in Google Cloud Plattform:

Nächste Schritte

Sie haben Ihren NGINX-Server nun so konfiguriert, dass TLS-Offloading verwendet wird, um Cloud HSM