Auf dieser Seite wird beschrieben, wie Sie Secure Socket Layer (SSL), jetzt Transport Layer Security (TLS), in Ihrer Anwendung verwenden können, um Verbindungen zu Cloud SQL-Instanzen zu verschlüsseln.
Übersicht
Cloud SQL unterstützt den Verbindungsaufbau zu einer Instanz mit dem SSL/TLS-Protokoll. SSL/TLS-Verbindungen bieten eine zusätzliche Sicherheitsebene, indem sie die Daten verschlüsseln, die zwischen Ihrem Client und der Datenbank in Ihrer Cloud SQL-Instanz übertragen werden. Optional kann Ihre SSL/TLS-Verbindung die Serveridentität durch Validieren des auf der Cloud SQL-Instanz installierten Serverzertifikats und die Clientidentität durch Validieren des auf dem Client installierten Clientzertifikats prüfen.
Serverzertifikate
Wenn Sie eine Instanz erstellen, erstellt und installiert Cloud SQL automatisch ein Serverzertifikat, das von einer Zertifizierungsstelle (Certificate Authority, CA) signiert ist. Sie können das CA-Zertifikat auf den Clienthostcomputer herunterladen und damit die Identität der CA und des Cloud SQL-Servers überprüfen. Optional können Sie den Typ der Zertifizierungsstelle auswählen, die Cloud SQL zum Signieren des Serverzertifikats verwendet.
Clientzertifikate
Optional können Sie Clientzertifikate zusammen mit Schlüsseln für den Hostcomputer des Clients für die gegenseitige Authentifizierung (Überprüfung der Server- und Clientidentität) erstellen und herunterladen. Sie können den Typ der Zertifizierungsstelle nicht auswählen, die Cloud SQL zum Signieren des Clientzertifikats verwendet.
Verbindung über SSL/TLS herstellen
Wenn Sie von Clients aus eine Verbindung zu einer Cloud SQL-Instanz herstellen, können Sie SSL/TLS sowohl für direkte Verbindungen als auch für Verbindungen verwenden, die den Cloud SQL Auth-Proxy oder Cloud SQL-Sprach-Connectors verwenden.
Für direkte Verbindungen empfiehlt Google dringend, die SSL/TLS-Verschlüsselung mit der Einstellung „SSL-Modus“ in Cloud SQL zu erzwingen. Optional können Sie auch die Überprüfung von Clientzertifikaten erzwingen. Weitere Informationen finden Sie unter SSL/TLS-Verschlüsselung erzwingen.
Bei Verbindungen, die den Cloud SQL Auth-Proxy oder Cloud SQL-Sprach-Connectors verwenden, werden die Verbindungen automatisch mit SSL/TLS verschlüsselt und die Client- und Serveridentität wird überprüft, ohne dass Sie ein Server-CA-Zertifikat und ein Clientzertifikat herunterladen müssen.
Weitere Informationen zu den Cloud SQL-Verbindungsoptionen finden Sie unter Cloud SQL-Verbindungen.
Weitere Informationen zur clientseitigen SSL/TLS-Konfiguration finden Sie in der Dokumentation zu Ihrer Datenbank-Engine.Hierarchien von Zertifizierungsstellen (Certificate Authorities, CAs)
In diesem Abschnitt werden die drei Arten von Serverzertifizierungsstellen (Certificate Authority, CA) beschrieben, die Sie für Ihre Cloud SQL-Instanzen auswählen können. Es gibt drei Optionen:
CA pro Instanz: Bei dieser Option signiert eine interne CA, die jeder Cloud SQL-Instanz zugewiesen ist, das Serverzertifikat für diese Instanz. Cloud SQL erstellt und verwaltet diese CAs. Wenn Sie eine CA pro Instanz auswählen möchten, wählen Sie Von Google verwaltete interne Zertifizierungsstelle (Google Cloud Console) aus oder geben Sie
GOOGLE_MANAGED_INTERNAL_CAfür die EinstellungserverCaMode(Cloud SQL Admin API) oder das Flag--server-ca-mode(gcloud CLI) an, wenn Sie die Instanz erstellen. Wenn Sie die Einstellung oder das Flag beim Erstellen einer Instanz nicht angeben, ist diese Option der Standardwert für die Instanz.Gemeinsame CA: Bei dieser Option wird eine CA-Hierarchie verwendet, die aus einer Stamm-CA und untergeordneten Server-CAs besteht. Die untergeordneten Server-CAs in einer Region signieren die Serverzertifikate und werden für alle Instanzen in der Region freigegeben. Cloud SQL hostet und verwaltet die Root-CA und untergeordnete Server-CAs im Google CloudCertificate Authority Service (CA Service). Cloud SQL übernimmt auch die Rotation von Stamm-CAs und untergeordneten Server-CAs und stellt öffentlich verfügbare Links zum Herunterladen der CA-Zertifikatsammlungen bereit. Wenn Sie eine gemeinsame Zertifizierungsstelle auswählen möchten, geben Sie
GOOGLE_MANAGED_CAS_CAfür die EinstellungserverCaMode(Cloud SQL Admin API) oder das Flag--server-ca-mode(gcloud CLI) an, wenn Sie die Instanz erstellen.Vom Kunden verwaltete Zertifizierungsstelle: Mit dieser Option erstellen und verwalten Sie Ihre eigene Zertifizierungsstellenhierarchie. Wählen Sie diese Option aus, wenn Sie Ihre eigenen Zertifizierungsstellen und Zertifikate verwalten möchten. Wenn Sie eine vom Kunden verwaltete CA auswählen möchten, müssen Sie einen CA-Pool und eine CA in CA Service erstellen. Geben Sie in Cloud SQL den CA-Pool und
als ausgewählt angezeigt.CUSTOMER_MANAGED_CAS_CAfür die EinstellungserverCaMode(Cloud SQL Admin API) oder das Flag--server-ca-mode(gcloud CLI) an, wenn Sie die Instanz erstellen.
Nachdem Sie eine Instanz erstellt haben, können Sie mit dem Befehl gcloud sql instances describe oder in der Google Cloud Console sehen, welche CA-Hierarchie für eine Cloud SQL-Instanz konfiguriert ist.
Weitere Informationen finden Sie unter Instanzinformationen ansehen.
In der folgenden Tabelle werden die drei Optionen für die Zertifizierungsstellenhierarchie verglichen.
| Feature | CA pro Instanz | Gemeinsame CA | Vom Kunden verwaltete CA |
|---|---|---|---|
| CA-Struktur | Separate Zertifizierungsstelle für jede Instanz | Stamm-CA und untergeordnete CAs, die von Instanzen in derselben Region gemeinsam genutzt werden | CA-Hierarchie, die Sie erstellen und verwalten |
| Kryptografische Attribute | RSA-2048-Bit-Schlüssel mit SHA256-Algorithmus | Elliptic Curve Digital Signature Algorithm (ECDSA) mit 384-Bit-Schlüssel mit SHA384-Algorithmus | Elliptic Curve Digital Signature Algorithm (ECDSA) mit 384-Bit-Schlüssel mit SHA384-Algorithmus |
| Gültigkeitszeitraum der Zertifizierungsstelle | 10 Jahre | 25 Jahre für die Stamm-CA und 10 Jahre für untergeordnete CAs | Konfigurierbar * |
| Gültigkeitszeitraum des Serverzertifikats | 10 Jahre | 1 Jahr | 1 Jahr** |
| Vom Nutzer initiierte Rotation von CA? | Ja | Nein. Die CA-Rotation wird von Cloud SQL verwaltet. | Ja |
| Vom Nutzer initiierte Rotation des Serverzertifikats | Ja | Ja | Ja |
| CA-Vertrauensanker für TLS-Verbindungen | Die eindeutige Zertifizierungsstelle pro Instanz ist der Trust-Anchor für die entsprechende Instanz. | Die Root-Zertifizierungsstelle und untergeordnete Zertifizierungsstellen sind die Trust-Anchors für alle Instanzen in einer bestimmten Region. | Die Zertifizierungsstellen, die Sie erstellen und verwalten, sind die Trust-Anchors. |
| Bestätigung der Serveridentität | Durch die Bestätigung der CA wird die Serveridentität bestätigt, da jede Instanz eine eindeutige CA hat. | Die Überprüfung des Hostnamens zusammen mit der Überprüfung der Zertifizierungsstelle ist für die Überprüfung der Serveridentität erforderlich, da Server-Zertifizierungsstellen instanzübergreifend verwendet werden. | Auch wenn die Zertifizierungsstelle nicht für alle Instanzen freigegeben ist, sollten Sie den Hostnamen zusammen mit der Zertifizierungsstelle überprüfen. |
| Feld „Alternativer Antragstellername“ (Subject Alternative Name, SAN) in Serverzertifikaten | Das Feld „SAN“ enthält den Hostnamen (DNS-Name der Instanz) nur für Instanzen, für die Private Service Connect aktiviert ist. Der Hostname kann zur Überprüfung der Serveridentität verwendet werden. Wenn Sie mit dem DNS-Namen als Hostnamen eine Verbindung zu einer Cloud SQL-Instanz herstellen, müssen Sie die DNS-Auflösung einrichten. | Das Feld „SAN“ enthält den Hostnamen (DNS-Name der Instanz) für alle Arten von Instanzen. Der Hostname kann zur Überprüfung der Serveridentität verwendet werden. Wenn Sie mit dem DNS-Namen als Hostnamen eine Verbindung zu einer Cloud SQL-Instanz herstellen, müssen Sie die DNS-Auflösung einrichten. | Das Feld „SAN“ enthält den Hostnamen (DNS-Name der Instanz) für alle Arten von Instanzen. Der Hostname kann zur Überprüfung der Serveridentität verwendet werden. |
| Unterstützung von Cloud SQL Auth-Proxy-Versionen | Unterstützt alle Versionen des Cloud SQL Auth-Proxys, Version 1 und höher. | Erfordert Cloud SQL Auth-Proxy Version 2.13.0 oder höher. | Erfordert Cloud SQL Auth-Proxy Version 2.14.3 oder höher. |
| Einschränkungen bei Dienstverbindungen | Keine |
Verbindungen von den folgenden Google Cloud
Diensten werden nicht unterstützt:
|
Verbindungen von den folgenden Google Cloud
Diensten werden nicht unterstützt:
|
* Bei der vom Kunden verwalteten CA-Option beträgt der standardmäßige Gültigkeitszeitraum eines CA-Zertifikats im CA Service 10 Jahre. Sie haben die Möglichkeit, einen anderen Gültigkeitszeitraum für Ihre CA-Zertifikate zu konfigurieren. Ein kürzerer Gültigkeitszeitraum für die Zertifizierungsstelle kann häufigere Zertifizierungsstellenrotationen erfordern. Ein Gültigkeitszeitraum von weniger als einem Jahr kann sich auf den Gültigkeitszeitraum Ihrer Serverzertifikate auswirken. Weitere Informationen finden Sie unter CA-Rotation verwalten.
** Bei der Option „Vom Kunden verwaltete Zertifizierungsstelle“ beträgt die standardmäßige Gültigkeitsdauer eines Serverzertifikats ein Jahr. Wenn Sie jedoch einen Gültigkeitszeitraum von weniger als einem Jahr für Ihr CA-Zertifikat konfigurieren, hat Ihr Serverzertifikat einen kürzeren Gültigkeitszeitraum. Weitere Informationen zum Konfigurieren des Gültigkeitszeitraums Ihres CA-Zertifikats beim Erstellen finden Sie unter CA-Zertifikateinstellungen und Stammzertifizierungsstelle erstellen.
Pro Instanz ausgestellte CA, die von Cloud SQL gehostet wird
Die CA-Hierarchie pro Instanz ist die Standardkonfiguration für den Server-CA-Modus, wenn Sie eine Instanz mit der gcloud CLI, der Cloud SQL Admin API oder Terraform erstellen.
Cloud SQL erstellt für jede Instanz eine neue selbstsignierte Server-CA, wenn Sie die Instanz erstellen.
Wenn Sie diese Einstellung verwenden möchten, konfigurieren Sie serverCaMode auf GOOGLE_MANAGED_INTERNAL_CA, wenn Sie die Instanz erstellen.
Sie können die Konfigurationseinstellung serverCaMode entweder mit der Cloud SQL Admin API oder der gcloud CLI nicht angeben oder in der Google Cloud Console die Option Google internal Certificate Authority (Interne Google-Zertifizierungsstelle) auswählen.
Das folgende Diagramm zeigt die CA-Hierarchie pro Instanz.
Gemeinsam genutzte CAs, die von CA Service gehostet werden
Die freigegebene CA-Hierarchie ist die Standardkonfiguration für den Server-CA-Modus, wenn Sie eine Instanz über die Google Cloud Console erstellen.
Dieser Server-CA-Modus besteht aus einer Stamm-CA und untergeordneten Server-CAs in jeder Region. Die untergeordneten Server-CAs stellen Serverzertifikate aus und werden für alle Instanzen in der Region freigegeben. Cloud SQL übernimmt die Rotation der freigegebenen regionalen Server-CAs und stellt öffentlich verfügbare Links zum Herunterladen der CA-Zertifikatbündel bereit.
Sie können eine Instanz so konfigurieren, dass sie eine Server-CA-Hierarchie verwendet, in der die ausstellenden CAs für die Instanzen in derselben Region freigegeben sind. Wenn Sie diese Einstellung verwenden möchten, konfigurieren Sie serverCaMode auf GOOGLE_MANAGED_CAS_CA, wenn Sie die Instanz erstellen.
Sie können in der Google Cloud Konsole auch Von Google verwaltete CAS-Zertifizierungsstelle auswählen.
Das folgende Diagramm zeigt die Hierarchie der gemeinsamen Zertifizierungsstelle.
Vom Kunden verwaltete CAs
In diesem Server-CA-Modus können Sie Ihre eigene CA-Hierarchie in CA Service einrichten.
Wenn Sie die Option für vom Kunden verwaltete CAs in Cloud SQL verwenden möchten, erstellen Sie einen CA-Pool in derselben Region wie Ihre Cloud SQL-Instanzen. Anschließend erstellen Sie mindestens eine CA.
Wenn Sie die Cloud SQL-Instanz erstellen, geben Sie die ID des CA-Pools im Feld serverCaPool an und konfigurieren Sie das Feld serverCaMode mit dem Wert CUSTOMER_MANAGED_CAS_CA.
CA Service stellt eine CA aus dem CA-Pool bereit und verwendet diese CA, um das Serverzertifikat für die Instanz auszustellen.
Wenn Sie CAs in CA Service erstellen, können Sie je nach Anwendungsfall entweder eine Stamm-CA oder eine untergeordnete CA erstellen. Sie können beispielsweise eine untergeordnete CA erstellen, wenn Sie eine Stamm-CA-Hierarchie einrichten oder eine Kette zu einer externen CA erstellen möchten.
Wählen Sie die Option für vom Kunden verwaltete Zertifizierungsstellen nur aus, wenn Sie Ihre eigenen Zertifizierungsstellen und Zertifikate verwalten möchten. Weitere Informationen finden Sie unter Vom Kunden verwaltete CA verwenden.
Rotation des Serverzertifikats
Cloud SQL bietet die Möglichkeit, das Serverzertifikat zu rotieren. Damit wird das alte Zertifikat vor seinem Ablauf nahtlos durch ein neues ersetzt.
Bei Instanzen, die die CA pro Instanz, die gemeinsam genutzte CA oder vom Kunden verwaltete CA-Hierarchien verwenden, erhalten die Projektinhaber etwa drei Monate vor Ablauf des Serverzertifikats für eine Cloud SQL-Instanz eine E-Mail von Cloud SQL, in der sie darüber informiert werden, dass die Zertifikatsrotation für diese Instanz begonnen hat. Die E-Mail enthält den Namen der Instanz und besagt, dass dem Projekt ein neues Serverzertifikat hinzugefügt wurde. Das vorhandene Serverzertifikat funktioniert weiterhin normal. Tatsächlich hat die Instanz während dieses Zeitraums zwei Serverzertifikate.
Welcher Befehl für die Rotation des Serverzertifikats verwendet werden muss, hängt davon ab, ob Sie ein Serverzertifikat verwenden, das von einer CA pro Instanz ausgestellt wurde, oder ein Serverzertifikat, das von der freigegebenen CA oder der vom Kunden verwalteten CA ausgestellt wurde.
Laden Sie vor Ablauf des aktuellen Serverzertifikats die neue server-ca.pem-Datei herunter, die die Zertifikatsinformationen für das aktuelle und das neue Serverzertifikat enthält. Aktualisieren Sie Ihre PostgreSQL-Clients so, dass die neue Datei verwendet wird. Dafür kopieren Sie sie auf alle PostgreSQL-Client-Hostcomputer und ersetzen die vorhandene Datei.
Nachdem alle PostgreSQL-Clients aktualisiert wurden, senden Sie einen rotate-Befehl (für die instanzspezifische Zertifizierungsstelle) oder einen rotate-Befehl (für die gemeinsam genutzte Zertifizierungsstelle oder die vom Kunden verwaltete Zertifizierungsstelle) an die Cloud SQL-Instanz, um zum neuen Serverzertifikat zu rotieren. Danach wird das alte Serverzertifikat nicht mehr erkannt und nur das neue Serverzertifikat kann verwendet werden.
Clientzertifikate sind von der Rotation des Serverzertifikats nicht betroffen.Ablauf des SSL-Zertifikats
Für Cloud SQL-Instanzen, die instanzbezogene Zertifizierungsstellen verwenden (serverCaMode ist auf GOOGLE_MANAGED_INTERNAL_CA festgelegt), haben die SSL-Zertifikate eine Gültigkeitsdauer von 10 Jahren. Bevor diese Zertifikate ablaufen, müssen Sie die Rotation des Server-CA-Zertifikats durchführen.
Bei Instanzen, die gemeinsame Zertifizierungsstellen verwenden (serverCaMode ist auf GOOGLE_MANAGED_CAS_CA festgelegt), beträgt der Ablaufzeitraum der Serverzertifikate 1 Jahr.
Führen Sie vor Ablauf eine Rotation des Serverzertifikats durch.
Das Zertifikat der Stammzertifizierungsstelle (Certificate Authority, CA) hat eine Gültigkeitsdauer von 25 Jahren und das Zertifikat der untergeordneten gemeinsamen CA eine Gültigkeitsdauer von 10 Jahren.
Cloud SQL übernimmt die Rotation.
Wenn Sie eine vom Kunden verwaltete Zertifizierungsstelle verwenden (serverCaMode ist auf CUSTOMER_MANAGED_CAS_CA festgelegt), können Sie die CA-Zertifikatsrotation durchführen, indem Sie die Zertifizierungsstellen in dem von Ihnen erstellten CA-Pool rotieren. Die Ablaufzeit einer CA beträgt in der Regel 10 Jahre. Sie können jedoch einen kürzeren Gültigkeitszeitraum für Ihre CA in CA Service konfigurieren.
Verwenden Sie den CA-Rotationsprozess in CA Service, um die CAs zu rotieren. Weitere Informationen finden Sie unter CA-Rotation verwalten.
Wenn ein Client so konfiguriert ist, dass er die Zertifizierungsstelle oder den Hostnamen im Serverzertifikat überprüft, schlagen die Verbindungen dieses Clients zu Cloud SQL-Instanzen mit abgelaufenen Serverzertifikaten fehl. Um Unterbrechungen von Clientverbindungen zu vermeiden, sollten Sie das Serverzertifikat rotieren, bevor es abläuft.
Unabhängig davon, ob Sie den CA-Servermodus „Pro Instanz“, „Gemeinsam“ oder „Vom Kunden verwaltet“ verwenden, können Sie die SSL-Konfiguration Ihrer Cloud SQL-Instanz jederzeit zurücksetzen.