Best Practices für Unternehmen

Erfahren Sie die Schlüsselkonzepte und Best Practices, um Google Cloud Platform bestmöglich für Unternehmen zu nutzen. In dieser Anleitung werden nicht-funktionale Themen, die für Unternehmen wichtig sind, besprochen.

Diese Anleitung ist aufgeteilt in die folgenden Abschnitte:

Projekte und Zugriff

Projekte stellen das Kernstück der Organisation in Google Cloud Platform dar. Projekte bieten abstrakte Gruppierungen, die Sie verwenden können, um einer bestimmten Abteilung oder einem funktionellen Team Ressourcen zuzuweisen. Alle Cloud Platform-Ressourcen gehören zu einem Projekt. Projekte können Sie mit der Google Cloud Platform Console und der Resource Manager API verwalten. Die Cloud IAM API enthält außerdem verschiedene Methoden zur Verwaltung von Projektberechtigungen über die Resource Manager API.

Projekte verwenden, um den Zugriff auf Ressourcen zu steuern

Projekte bieten, außer dort, wo Zwischenverbindungen gewährt wurden, eine isolierende Grenze zwischen den Ressourcen, die von Ihrem Unternehmen verwendet werden. Nutzer und Gruppen können verschiedene Rollen in verschiedenen Projekten zugewiesen werden, beispielsweise viewer, editor und owner. Rollen lassen sich in der GCP Console auf der Seite "IAM & Verwaltung" oder mit der Cloud IAM API zuweisen. Allerdings ist es momentan nicht möglich, mit dieser API benutzerdefinierte Rollen zu erstellen und diesen Berechtigungen zuzuweisen.

Außerdem können Sie die Steuerung des Zugriffs auf bestimmte Projekte delegieren. Nutzer, denen die Rolle owner zugewiesen ist, können Nutzern, Gruppen und Dienstkonten Zugriff gewähren bzw. den Zugriff widerrufen.

Jedem Google-Konto kann Zugang zu einem Projekt gewährt werden

Sie können jedem Google-Konto, beispielsweise einem Gmail-Konto, Zugriff auf ein Projekt gewähren. Jedem Google-Konto kann auch deshalb der Zugriff gewährt werden, weil es zu einer Gruppe gehört, die Zugriff auf das Projekt hat. Diese Funktion kann hilfreich sein, da sie Ihnen erlaubt, externen Parteien, wie Dienstleistern, schnell Zugriff zu gewähren. Abhängig von Ihren Sicherheitsrichtlinien wollen Sie diese Flexibilität für Ihr Unternehmen jedoch möglicherweise nicht nutzen. Sie können dieses Risiko mit der Cloud IAM-API verwalten. Auch können Sie die API nutzen, um Überwachungsfunktionen zu erstellen, die Aufgaben außerhalb Ihrer Richtlinien überwacht und eine Warnung ausgibt oder die Aufgaben automatisch aufhebt.

Projekte werden durch eindeutige Kennungen identifiziert

Jedes Projekt verfügt über eine eindeutige Projekt-ID, die aus einer kurzen Reihe kleingeschriebener Buchstaben, Ziffern und Bindestrichen besteht, und einer Projektnummer. Wenn Sie ein Projekt erstellen, können Sie die Projekt-ID angeben. Google teilt automatisch die Projektnummer zu. Nachdem die Projekt-ID und die Projektnummer erstellt wurden, können sie nicht mehr geändert werden.

Wir empfehlen, dass Sie sich für eine einfachere Verwaltung bei der Planung Ihrer Projekt-ID Zeit nehmen. Eine typische Namenskonvention für eine Projekt-ID sollte dem folgenden Muster entsprechen:

[company tag]-[group tag]-[system name]-[environment (dev, test, uat, stage, prod)]

Die Entwicklungsumgebung für das Vergütungssystem der Personalabteilung könnte beispielsweise acmeco-hr-comp-dev genannt werden.

Sie können einen für Menschen lesbaren Projektnamen angeben. Diese Namen müssen nicht global eindeutig sein und können bearbeitet werden. Projekt-IDs dürfen 6 bis 30 Zeichen lang sein, während Projektnamen 4 bis 30 Zeichen lang sein dürfen.

Projekte ermöglichen präzise Kostenberechnung

Google organisiert Ihre Rechnung, einschließlich der exportierbaren CSV- oder JSON-Version, nach Projekt. Das Projekt stellt die oberste Ebene Ihrer Rechnung dar. Es gibt innerhalb dieser Ebene weitere Aufschlüsselungen nach SKU, aber die oberste Ebene liefert einen exzellenten Überblick über die gesamten Kosten einer Gruppe von Compute- und Netzwerkressourcen.

In Rechnungsdaten exportieren werden die Inhalte der exportierbaren Rechnungsdatei erklärt.

Zugriff zwischen Projekten ist möglich, muss aber explizit erlaubt werden

Dienstkonten können wie Nutzern und Gruppen Zugriff auf mehrere Projekte gewährt werden. Dieser Zugriff zwischen Projekten ermöglicht es Prozessen in einem Projekt, direkt auf die Ressourcen innerhalb eines anderen Projekts zuzugreifen.

Wenn ein Dienstkonto von Projekt A auf eine Ressource in Projekt B zugreift, fallen die Kosten für das Projekt an, das die Ressource besitzt, hier Projekt B.

Die Ausnahme zu dieser Regel stellen Abfragen in Google BigQuery dar. Wenn von Projekt B aus ein Nutzer oder Dienstkonto in Projekt A gespeicherte BigQuery-Daten abfragt, werden die Kosten dem Projekt zugerechnet, von dem die Abfrage ausging, hier Projekt B. Jedoch verbleiben die Kosten für die Speicherung der Daten bei Projekt A. Dieser Ansatz vereinfacht das Verständnis davon, wie verschiedene Gruppen BigQuery zur Datenanalyse verwenden.

Jedes Projekt gehört zu einem bestimmten Rechnungskonto

Rechnungskonten sind organisationsweite Ressourcen, die nur von einem Abrechnungsadministrator bearbeitet werden können. Sie können Abrechnungsadministratoren auf der Seite "Abrechnung" in der GCP Console verwalten. Jedes Projekt ist mit genau einem Rechnungskonto verbunden. Projekte können mit einem Rechnungskonto nur durch einen Nutzer, der sowohl Projektinhaber als auch Abrechnungsadministrator ist, mit einem Rechnungskonto verbunden werden. Die Kosten und Rechnungen für den Support sind mit einem einzelnen Rechnungskonto verbunden.

Projekte basieren nicht auf geographischen oder vergleichbaren Zonen

Ein Projekt ist eine logische Gruppe von Ressourcen, die nicht mit einer bestimmten geographischen Region verknüpft sind. Ebenso stellt ein Projekt keine Verfügbarkeitszone dar. Ressourcen innerhalb eines bestimmten Projekts können in mehreren geographischen Regionen und Zonen bestehen.

Beispielsweise kann Projekt A Ressourcen in USA zentral, Europa und Asien, jeweils mit mehreren Regionen, beinhalten, während Projekt B möglicherweise nur Ressourcen in Europa beinhaltet, auch mit mehreren Zonen.

Sie müssen keine geographische Region oder Zone angeben, wenn Sie ein Projekt erstellen. Nur in App Engine besteht eine Ausnahme zu dieser Regel. Apps in App-Engine haben immer eine geographische Region. Sie können die standardmäßige Einstellung des Standorts von App Engine ändern, wenn Sie ein neues Projekt erstellen. Beachten Sie, dass bestimmte Ressourcen mit gewissen geographischen Orten verknüpft werden können, nachdem ein Projekt erstellt wurde. Dieses Konzept wird in den kommenden Abschnitten genauer beschrieben.

Authentifizierung und Identität

In diesem Abschnitt werden Best Practices für die Erstellung und Verwaltung von Authentifizierung und Identitäten in Google Cloud-Platform beschrieben.

Anmeldedaten des Unternehmens verwenden

Google Cloud Platform nutzt Google-Konten zur Authentifizierung und zur Zugriffsverwaltung. Google empfiehlt, vollständig verwaltete Google-Konten für eine bessere Sichtbarkeit, Prüfung und Zugriffssteuerung der Cloud Platform-Ressourcen.

Cloud Identity bietet kostenlose verwaltete Google-Konten, die Sie mit Google-Diensten einschließlich der Cloud Platform nutzen können. Wenn Sie für alle Nutzer Cloud Identity-Konten verwenden, können Sie die Nutzer in der gesamten Domain über die Google Admin-Konsole verwalten.

Als G Suite-Administrator können Sie alle Nutzer und Einstellungen über die G Suite-Admin-Konsole verwalten. Standardmäßig wird allen neuen Nutzern eine G Suite-Lizenz zugewiesen. Falls ein Teil Ihrer Entwickler keine G Suite-Lizenz benötigt, können Sie stattdessen Cloud Identity-Konten hinzufügen.

Weitere Informationen finden Sie unter Einstieg in Cloud Identity.

Nutzer im Google-Verzeichnis bereitstellen

Das globale Verzeichnis von G Suite bietet strukturiert gespeicherte Daten von Nutzern und Gruppen zur Authentifizierung und Autorisierung. Das globale Verzeichnis steht sowohl für Cloud Platform-Ressourcen als auch für G Suite-Ressourcen bereit und kann auf verschiedene Arten bereitgestellt werden. Bereitgestellte Nutzer können die zahlreichen Authentifizierungsfunktionen nutzen, darunter die Einmalanmeldung (SSO), OAuth und die Zwei-Faktor-Authentifizierung.

Sie können Nutzer mit einem der folgenden Tools automatisch bereitstellen:

GCDS ist ein Connector, der Nutzer und Gruppen in Ihrem Namen sowohl für Cloud Platform als auch für G Suite bereitstellen kann. Mithilfe von GCDS können sie Nutzer, Gruppen und betriebsfremde Kontakte automatisch hinzufügen, bearbeiten und löschen. Sie können die Daten von Ihrem LDAP-Verzeichnis-Server mit Ihrer Cloud Platform-Domain durch LDAP-Anfragen synchronisieren. Diese Synchronisierung ist einseitig: Die Daten in Ihrem LDAP-Verzeichnis-Server werden nie bearbeitet.

GCDS wird in Ihrem Netzwerk auf einer Maschine unter Ihrer Kontrolle ausgeführt. Es verbindet sich durch Standard-LDAP oder sicheres LDAP sowie Secure Socktes Layer (SSL) mit Ihrem LDAP-Server. Diese Verbindung tritt an jedem Port auf, den Sie angeben, aber standardmäßig an jedem LDAP-Standardport. GCDS verbindet sich über das Internet durch HTTPS auf Port 443 mit der G Suite-Domain. Diese Verbindung kann auch über einen Proxy-Host in Ihrem Netzwerk laufen.

Wenn Sie es vorziehen, Ihre eigenen Lösungen zur Bereitstellung von Nutzern und Gruppen zu erstellen, können Sie Google Admin SDK verwenden. Das Admin SDK bietet Methoden, mit denen Sie Cloud Platform-Nutzer und ihre Verbindungen mit Gruppen und Unternehmen verwalten können. Das SDK unterstützt HTTPS-REST-Endpoints und bietet Python-, Java-, .NET- und andere Clientbibliotheken.

Zusätzlich zu diesen eingebauten Tools und Diensten bieten viele führende Anbieter für die Identitätsverwaltung Connectoren für das globale Verzeichnis von G Suite. Diese Connectoren stellen üblicherweise Nutzer und ihre Verbindung mit Gruppen und Unternehmen bereit, indem sie die Google Admin SDK's Directory API nutzen.

Cloud Platform-Administratoren können Nutzer und ihre Verbindung zu Gruppen zu Testzwecken oder anderen Zwecken manuell bereitstellen, indem Sie die G Suite Admin-Konsole nutzen.

Mehr über das globale Verzeichnis von G Suite erfahren Sie in Das globale Verzeichnis verwalten.

Konflikte der Konten bei der Bereitstellung von Nutzern lösen

Falls Nutzer Ihrer Domain eine betriebliche E-Mail-Adresse verwendet haben, um ein persönliches Google-Konto zu erstellen - beispielsweise, um sich bei Google-Diensten wie YouTube oder Blogger anzumelden - werden diese Konten Konflikte verursachen, wenn Sie sie zu G Suite oder Cloud Platform hinzufügen. Die Autorisierung für bestehende Konten muss manuell aufgehoben und auf die neuen Nutzerkonten transferiert werden.

Mehr Informationen darüber, wie Sie Konflikte der Konten verhindern und lösen können, erfahren Sie in Konflikte zwischen Konten lösen.

Rollen der Domainverwaltung definieren

Wenn ein Projekt mit einer Domain verbunden wird, wird eine neue Rolle mit dem namen Super-Admin erstellt. Die Rolle Super-Admin bezieht sich auf die Domain selbst. Verwenden Sie eine vordefinierte Rolle oder erstellen Sie eine benutzerdefinierte Rolle und definieren Sie ihren Verwaltungsbereich:

  • Nutzer: Organisation, die eine Teilmenge von Benutzern oder global ist.
  • Berechtigungen: Beispielsweise Gruppen- oder Sicherheitsverwaltung.

Diese Rollen können mit der Admin-Konsole oder der Roles API verwaltet werden. Weitere Informationen zu Administratorrollen für Domains finden Sie unter Administratorrollen.

SSO mit SAML-Austausch implementieren

Cloud Platform unterstützt SSO auf SAML 2.0-Basis, wodurch eine reibungslose Einmalanmeldung bei der Cloud Platform-Konsole, SSH auf Web- und Befehlszeilenbasis und OAuth-Eingabeaufforderungen ermöglicht werden. Die Befehlszeilentools von Cloud Platform, wie gcloud, gsutil und bq nutzen ebenfalls SSO auf SAML 2.0-Basis für die Browser-basierte Authentifizierung.

Wenn der Nutzer auf eines dieser Tools zugreift, ohne sich vorher bei dem SSO-Anbieter authentifiziert zu haben, entweder direkt oder durch Zugriff auf andere Anwendungen, wird der Nutzer aufgefordert, den Benutzernamen, nicht jedoch sein Passwort, einzugeben. Dieser Schritt hilft der Google-Infrastruktur zur Authentifizierung dabei, die Domain, bei der der Nutzer sich authentifizieren will, zu erkennen.

Mehr Informationen über die Einrichtung von Google SSO erfahren Sie in Einmalanmeldung (SSO) für G Suite-Konten einrichten. Die Informationen in dieser Anleitung gelten sowohl für Cloud Platform als auch für G Suite, da beide Produkte das gleiche Verzeichnis, die gleiche auth- und SSO-Infrastruktur teilen.

Google als Identitätsdienstleister für andere Dienste in Betracht ziehen

Sie können eine Authentifizierungslösung verwenden, die vollständig auf der Cloud basiert, indem Sie Ihre eigenen Apps mit Google OpenID Connect authentifizieren und, indem Sie Google als SAML 2.0-Identitätsdienstleiter zur Authentifizierung von Standard-Apps nutzen.

Google und Drittanbieter bieten Bibliotheken, die Sie für viele Implementierungsdetails bei der Verwendung von OpenID Connect zur Authentifizierung von Nutzern nutzen können. Sie können Google als Ihren SAML 2.0-Identitätsdienstleister einsetzten, statt ein Verzeichnis eines Drittanbieters, wie Microsoft Active Directory, zu nutzen. G Suite unterstützt mehr als 15 beliebte SaaS-Dienstleister. Empfohlene G Suite-Identitätspartner sind unter anderem Ping und Okta. Sie können auch neue benutzerdefinierte SAML-App-Integrationen hinzufügen.

Mit Google als Ihrem Identitätsdienstleister können Sie die umfassende Infrastruktur zur Authentifizierung von Google, einschließlich der Zwei-Faktor-Authentifizierung und FIDO U2F Security Key-Geräten, nutzen.

Gruppen von Nutzern Projektrollen zuweisen

Mit Google Groups können Sie die Projekt-Autorisierung eines großen Unternehmens verwalten. Wenn Sie bereits vertraut sind mit Role-Based Access Control (RBAC), können Sie sich Google Groups als analog zu RBAC-Rollen vorstellen, während Projektrollen analog sind zu RBAC-Berechtigungen. Sie können Gruppen Projektrollen auf ähnliche Art zuweisen, wie Sie sie Nutzern zuweisen, und die Gruppenzugehörigkeit wie oben beschrieben verwalten.

Interaktionen zwischen Server mit Dienstkonten autorisieren

Dienstkonten können, wie Nutzern, die Autorisierung bei bestimmten Ressourcen durch ähnliche Verfahren gewährt werden. Zum Beispiel kann einer Anwendung die Möglichkeit gegeben werden, in Google Cloud Storage-Buckets zu lesen und zu schreiben oder auf bestimmte Datensätze in BigQuery zuzugreifen. Dienstkonten sind nützlich, um automatische Vorgänge auszuführen, da sie mit einem privaten Schlüssel und nicht mit einem Passwort authentifiziert werden.

Anwendungsautorisierung mit OAuth2 delegieren

Cloud Platform APIs unterstützen OAuth 2.0 und Bereiche bieten präzise Autorisierung für die Methoden, die unterstützt werden. Cloud Platform unterstützt OAuth für Dienst- und Nutzerkonten. Es wird auch dreibeiniges OAuth genannt.

OAuth 2.0 wird gewöhnlich für die Autorisierung von Web-Apps verwendet. Es verfügt auch über einen Modus für installierte Anwendungen, der Desktop-Apps unterstützt.

Die Cloud Platform unterstützt Standardanmeldedaten für Anwendungen, die sich gut für den nutzerunabhängigen Zugriff auf APIs eignen, beispielsweise wenn alle Nutzer Zugriff auf dieselben Daten haben. Für Vorgänge von einem Befehlszeilenterminal können Sie das Befehlszeilentool gcloud autorisieren, um im Namen Ihres Nutzerkontos oder eines Dienstkontos auf APIs zuzugreifen. gsutil kann diese Anmeldedaten ebenfalls verwenden.

Instanzidentität vor dem Übertragen von Daten überprüfen

Instanzen können ein JSON Web Token (JWT) generieren, das Details zur Instanz sowie die RS256-Signatur von Google enthält. Die Anwendungen gleichen die Signatur mit den öffentlichen OAuth2-Zertifikaten von Google ab. Auf diese Weise wird die Identität der Instanz überprüft, mit der eine Verbindung hergestellt wurde.

Unter Identität von Instanzen prüfen wird beschrieben, wie signierte Instanztoken angefordert und geprüft werden.

Netzwerk und Sicherheit

Projekte zur vollständigen Isolation von Ressourcen nutzen

Google nutzt Software-definierte Netzwerke, die es Ihnen erlauben, jedes Paket auf Sicherheit zu überprüfen. Dadurch wird eine vollständige Isolation der Cloud Platform-Projekte ermöglicht. Im Cloud Platform-Blog können Sie mehr über Software-definierte Netzwerke in den Rechenzentren von Google erfahren.

Auf der Seite "Sicherheit in Google Cloud Platform" können Sie mehr über Sicherheit erfahren.

Netzwerke innerhalb von Projekten verwenden, um Gruppen von VM-Instanzen zu isolieren

Jedes Projekt unterstützt bis zu fünf isolierte Netzwerke. Jedes Netzwerk stellt einen globalen IP-Adressraum dar. Daher können Sie Ressourcen, beispielsweise Instanzen virtueller Maschinen (VM) in Google Compute Engine, in mehreren geographischen Regionen erstellen und diese Ressourcen werden sich den gleichen IP-Adressraum teilen, da sie sich im gleichen virtuellen Netzwerk befinden. Beachten Sie, dass trotz des flachen Netzwerkadressraums Kosten beim Ausgang von Daten berechnet werden, wenn Sie Ihre Zone verlassen. Mehr Informationen unter Netzwerkpreise.

Sie können eine Erhöhung der Beschränkungen anfragen, um bis zu 15 isolierte Netzwerke in jedem Projekt zu erhalten.

Lokale DNS des Netzwerks einsetzen

Jedes Netzwerk unterstützt einen lokalen Domainnamen-Server (DNS), der es VM-Instanzen erlaubt, sich schnell und einfach durch den Namen zu finden. Ähnlich wie der globale Adressraum ist dieses lokale DNS im gesamten Netzwerk tätig, unabhängig von der Region oder Zone der VM-Instanz, die den Dienst nutzt.

Eine virtuelle Firewall und Routen steuern den gesamten Netzwerkzugriff

Cloud Platform nutzt ein Software-definiertes Netzwerk, das viel Flexibilität in virtuellen Anwendungen bietet. Sie können Firewallregeln erstellen, um den eingehenden Traffic zu Instanzen und Lastenausgleichsmodulen, sowohl aus dem öffentlichen Internet als auch von anderen Instanzen im gleichen Netzwerk, zu steuern. Sie können Firewallregeln auf bestimmte Instanz-Tags anwenden. Sie können beispielsweise eine Firewallregel erstellen, die dynamisch auf eine Reihe an Instanzen mit dem gleichen Tag angewendet wird, wodurch die automatische Skalierung von Clustern vereinfacht wird.

Routen sind ähnlich flexibel. Sie definieren Routen für das Netzwerk, die definieren, wie VM-Instanzen Traffic an andere Instanzen im gleichen Netzwerk und externe Ressourcen leiten. Routen können auch auf bestimmte Instanz-Tags angewendet werden. Dies erlaubt es Ihnen, Regeln aufzustellen, die dynamisch auf Instanzen angewendet werden können.

iptables und Routen verwenden, um ausgehenden Traffic zu filtern und begrenzen

Während die Firewallregeln von Cloud Platform eingehenden Traffic zu Ihren VM-Instanzen steuern können, können Netzwerkrouten den ausgehenden Traffic von VMs zu IP-Adressbereichen steuern. Beispielsweise lässt sich der komplette externe Traffic durch ein NAT-Gateway weiterleiten. Außerdem kann der gesamte Traffic an IP-Bereiche des Unternehmens durch ein VPN-Gateway geleitet oder der Zugriff auf IP-Bereiche abgelehnt werden, indem die Route zu einem nicht vorhandenen IP-Bereich führt. Wenn Sie den ausgehenden Traffic von einer VM-Instanz zu bestimmten Ports steuern und beispielsweise jeglichen Traffic durch Port 80 filtern möchten, konfigurieren Sie iptables oder einen anderen hostbasierten Filtermechanismus für die Instanz.

VM-Instanzen haben eine externe IP-Adresse und können eine öffentliche IP-Adresse haben

Jeder VM-Instanz ist eine interne Adresse zugewiesen, die zum Adressbereich des Netzwerks, in dem sie erstellt wurde, passt. Diese Adresse kann für Traffic zwischen Instanzen im gleichen Netzwerk verwendet werden. Optional können Sie einer VM-Instanz eine externe, öffentliche IP-Adresse zuweisen. Diese externe Adresse kann entweder vorübergehend oder, gegen eine Gebühr, statisch sein. Beachten Sie, dass Ihnen Kosten für eine reservierte statische IP-Adresse entstehen, wenn die VM-Instanz nicht ausgeführt wird und auch, wenn die IP nicht mit einer VM-Instanz verbunden ist.

Ihr Standardkontingent beinhaltet die Verfügbarkeit einer kleinen Anzahl an externen IP-Adressen: 23 vorübergehende und 7 statische pro Region. Mit einer Erhöhung des Kontingents können Sie die Anzahl an externen vorübergehenden IP-Adressen auf 500 pro Region anheben. Wenn Sie mehr externe IP-Adressen benötigen, als die Kontingente zur Verfügung stellen, kontaktieren Sie den Cloud-Support oder Ihren Technical Account Manager, um über Ihre Anforderungen zu sprechen.

VM-Instanzen benötigen eine öffentliche IP-Adresse, um Cloud Platform-Dienste zu erreichen

Ihre VM-Instanzen benötigen eine externe IP-Adresse, um Internetressourcen, darunter auch Cloud Platform APIs und andere Dienste zu erreichen. Während diese Vorgehensweise Anlass zur Sorge geben kann, empfehlen wir, den eingehenden Traffic auf diese VM-Instanzen mithilfe von Firewallregeln zu begrenzen.

Falls Ihre Sicherheitsrichtlinien wirklich interne VM-Instanzen vorschreiben, müssen Sie manuell einen NAT-Proxy für Ihr Netzwerk und eine korrespondierende Route einrichten, damit die internen Instanzen das Internet erreichen können. Dabei ist zu beachten, dass Sie sich mit SSH nicht direkt mit einer vollständig internen VM-Instanz verbinden können. Mit solchen internen Maschinen verbinden Sie sich, indem Sie eine Bastion-Instanz einrichten, die über eine externe IP-Adresse verfügt, und dann durch diese tunneln. Weitere Informationen unter Bastion-Hosts.

Bestimmte Ressourcen in Regionen für niedrigere Latenz und Notfallwiederherstellung speichern

Eine Region stellt eine geographische Region dar. Genauer gesagt handelt es sich um den Standort eines Rechenzentrums-Campus. Innerhalb einer Region gibt es mehrere Zonen, die im Hinblick auf die zugrunde liegende Infrastruktur Verfügbarkeitszonen sind. Bestimmte Ressourcen in Cloud Platform sind global, aber andere Ressourcen können bestimmten Regionen oder, in manchen Fällen, bestimmten Zonen zugewiesen werden. VM-Instanzen, persistente Laufwerke, Cloud Storage-Buckets, App Engine-Apps, Cloud Bigtable, Cloud Dataproc, Datensätze in BigQuery, Cloud VPN und einige andere Ressourcen können alle innerhalb einer bestimmten geographischen Region erstellt werden.

Nutzen Sie Regionen und Zonen, um die geeignete Dienstredundanz zu erreichen oder die Latenz durch Berücksichtigung der Geographie zu minimieren.

Cloud VPN zur sicheren Verbindung von Remote-Netzwerken verwenden

Google Cloud VPN ist ein flexibles Tool, das verwendet werden kann, um Remote-Netzwerke sicher zu verbinden. Darunter die Verbindung zwischen Cloud Platform und einem Netzwerk vor Ort, zwei Netzwerken in verschiedenen Projekten oder zwei Netzwerken im gleichen Projekt. Cloud VPN-Tunnels werden bei gleichbleibendem Preis monatlich berechnet. Hinzu kommen die Standardpreise für ausgehenden Traffic. Beachten Sie, dass die Verbindung von zwei Netzwerken im gleichen Projekt auch standardmäßige Kosten für ausgehenden Traffic verursacht.

Durch Instanz-Tags auf Routen können Sie dynamisch steuern, welche VM-Instanzen Traffic durch das VPN senden können.

Scannen Sie nach üblichen Schwachstellen in Websites

Spüren Sie mit Google Cloud Security Scanner übliche Schwachstellen in Websites auf. Dieses Tool untersucht Ihre App Engine-Apps auf Cross-Site-Scripting und Problemen mit gemischtem Inhalt.

Wie bei allen dynamischen Scannern für Schwachstellen bedeutet ein sauberer Scan nicht, dass Ihre Seite sicher ist. Sie müssen trotzdem eine manuelle Sicherheitsüberprüfung durchführen.

Cloud Router kann dynamisch Routen zu Cloud VPN hinzufügen

Trotz der Flexibiltät von Cloud VPN müssen die IP-Adressbereiche statisch hinzugefügt und von allen Tunnels entfernt werden. Google Cloud Router weicht diese Beschränkung auf, indem es das Border Gateway Protocol (BGP) nutzt, um die Tunnels automatisch zu aktualisieren.

Ein Netzwerk kann in Subnetzwerke unterteilt werden

Subnetzwerke auf Compute Engine erlauben es Ihnen, den Adressbereich, in dem VM-Instanzen erstellt werden, zu steuern, und gleichzeitig Routen zwischen ihnen anzulegen. Subnetzwerke können jeden nicht-öffentlichen IP-Bereich haben, daher müssen Sie nicht zu einem gemeinsamen übergeordneten Netzwerk gehören. Subnetzwerke innerhalb einer bestimmten Netzwerkgruppe können sich gegenseitig erreichen.

Sie können durch Firewallregeln und Routen eine weitere Isolation zwischen Subnetzwerken erreichen.

Logging, Überwachung und Prüfung

Überwachen Sie den Zugriff auf und die Nutzung von den Ressourcen Ihres Kontos, um Bedrohungen zu erkennen und Risiken zu vermindern. Cloud Platform bietet umfangreiche Tools zur Überwachung und Benachrichtigung, die einen wichtigen Teil der Gesamtlösung darstellen können.

Cloud Logging als zentralisierten Speicherort für Logs nutzen

Google Cloud Logging bietet einen allgemeinen, zentralisierten Speicherort für Logs. Logs von VM-Instanzen, App Engine und verwalteten Diensten werden automatisch in diesem zentralisierten Logging-Bereich angezeigt. Sie können auch andere beliebige Logs an Cloud Logging senden. Verwenden Sie diese Funktion, um alle Ihre System- und Anwendungs-Logs für eine einfachere Analyse und Überwachung an einem Ort zu sammeln.

Zugriff auf Systemressourcen überwachen

Überwachen Sie Folgendes, um zu prüfen, wie auf Ihre Systemressourcen zugegriffen wird:

  • Veränderungen an Compute Engine-Ressourcen, wie das Erstellen und Löschen von Instanzen und Laufwerken, die Änderung von Firewallregeln und die Konfiguration des Lastenausgleichs und der Autoskalierung mit der RegionOperations-API.

  • Anfragen für Compute Engine-Informationen wie instance/get-Aufrufe mit Aktivitäts-Logs.

  • Compute Engine-Anwendungs-Logs und -Authentifizierungsversuche mit dem Google Cloud Logging Agent.

  • VPN-Traffic zwischen Gateways, darunter Quell- und IP-Adressen, mit dem privaten Netzwerk-Log.

  • BigQuery-Abfragen und Vorgänge mit Tabellen, Datensätzen und Anzeigen mit der BigQuery-API.

  • Zugriff auf Cloud Storage-Objekte mit den Zugriffs-Logs von Cloud Storage.

  • App Engine-Bereitstellungen, Versionshochstufungen sowie Cron-, Index-, Warteschlangen- oder andere Konfigurationsänderungen mit den App Engine-Admin-Logs.

  • Cloud SQL-Vorgänge mit der Methode "operations.list" in Cloud SQL.

  • Google Cloud Deployment Manager-Vorgänge mit der Deployment Manager-API.

Kontozugriff überwachen

Mit der Reports API und dem Audit-Log zu Anmeldeaktivitäten in der Admin-Konsole können Sie alle Zugriffe auf Ihre Domain überwachen.

Administrative Maßnahmen überwachen

Änderungen an Projektrollen lassen sich mit der IAM API überwachen. Mit dem Audit-Log der Admin-Konsole können Sie außerdem alle Vorgänge überwachen, die in der Admin-Konsole der Domain ausgeführt werden.

Logs nach BigQuery zur Analyse und langfristigen Speicherung exportieren

BigQuery ist ein exzellentes Tool zur schnellen Analyse riesiger Datenmengen. Darüber hinaus stellt BigQuery eine äußerst kostengünstige Möglichkeit dar, um Daten zu Analysezwecken zu speichern. Cloud Logging lässt sich so konfigurieren, dass Logs direkt nach BigQuery exportiert werden. Sie können dann mit diesem leistungsstarken Tool detaillierte Analysen ausführen, um Trends in den Logs zu erkennen.

Unerwünschte Änderungen an Logs verhindern

Logs werden in Cloud Storage im ursprünglichen Projekt gespeichert. Standardmäßig haben Projektinhaber und -bearbeiter Inhaberberechtigungen für alle Cloud Storage-Buckets im Projekt und für Objekte unter dem hierarchischen Berechtigungsmodell des Buckets.

Orientieren Sie sich an den folgenden Grundsätzen, um das Risiko versehentlicher oder böswilliger Änderungen an Ihren Logs zu minimieren.

Grundsatz der geringsten Berechtigung

Gewähren Sie nur so viele Berechtigungen, wie zum Erledigen einer Aufgabe nötig sind. Verwenden Sie die Rolle owner nur für Projekte und Log-Buckets. Die Rolle owner ist für die Verwaltung von Teammitgliedern, Autorisierungen usw. vorgesehen.

Teammitglieder mit der Rolle editor können trotzdem noch Anwendungen bereitstellen und ihre Ressourcen ändern oder konfigurieren.

Sie könnten auch einer größeren Anzahl von Nutzern verwalteten Zugriff auf Buckets und Objekte über eine benutzerdefinierte Anwendung bereitstellen, die die Cloud Storage API mit einem dedizierten Dienstkonto nutzt, und dann in der Anwendung die Prüfung hinzufügen.

Nachweisbarkeit

Cloud Storage verschlüsselt automatisch alle Daten, bevor sie auf ein Laufwerk geschrieben werden. Durch Implementierung der Objektversionierung für die Log-Buckets können Sie die Nachweisbarkeit zusätzlich sichern. Wird ein Objekt in einem Bucket überschrieben oder gelöscht, wird automatisch eine Kopie des Objekts mit Erstellungs-Properties zur Identifizierung der Kopie gespeichert. Leider schützt diese Funktion nicht davor, dass ein Projektinhaber das archivierte Objekt löscht oder die Versionierung deaktiviert.

Aufgabentrennung

Sie können die Aufgaben weiter aufteilen. Beispielsweise benötigen Sie möglicherweise zwei Leute, um die Logs zu überprüfen und unterzeichnen. In diesem Fall können Sie die Log-Buckets in ein Projekt mit einem anderen Inhaber kopieren. Führen Sie hierfür gsutil cp im Rahmen eines regelmäßigen Cronjobs aus oder verwenden Sie den Cloud Storage Transfer Service, wenn die jeweils kopierte Menge an Log-Daten 10 TB überschreitet. Diese Vorgehensweise schützt nicht vor einem Projektinhaber, der den ursprünglichen Bucket löscht, bevor die Kopie entsteht, oder das ursprüngliche Logging deaktiviert.

Diese Vorgehensweise führt zu Cloud-basierten Kopien, ohne etwas auf Ihre lokale Maschine zu speichern. Daher ist sie schnell und effizient. Für Kopien innerhalb einer Region entstehen keine Kosten für ein- oder ausgehenden Netzwerk-Traffic, für das Kopieren selbst fallen jedoch Vorgangsgebühren an.

Zur Reduzierung der Speicherkosten für duplizierte Logs können Sie die Objekte in Nearline Storage kopieren und die Verwaltung des Objektlebenszyklus für die ursprünglichen Bucket-Objekte implementieren. Nachdem Sie verifiziert haben, dass diese Bucket-Objekte in das Sicherungsprojekt repliziert wurden (zum Beispiel wöchentlich), entfernen Sie sie.

Stackdriver Monitoring für das Überwachen von Ressourcen und für Warnungen verwenden

Mit Stackdriver Monitoring lassen sich verschiedene Ressourcen wie VM-Instanzen, App Engine und Cloud Pub/Sub überwachen. Viele dieser Überwachungsintegrationen werden automatisch zur Verfügung gestellt und Sie müssen nur die Grenzen für Benachrichtigungen konfigurieren.

Cloud Platform bietet auch die Möglichkeit, bestimmte Log-Einträge aufzuspüren und benutzerdefinierte Messwerte für diese Inhalte zu erstellen.

Logging und Überwachung mit Cloud Platfrom vereinheitlichen

Stackdriver Monitoring ermöglich Ihnen, Messwerte von VMs zu versenden, die sich außerhalb der Cloud Platform befinden. Mit einem installierbaren Agent können Sie dann Messwerte und Benachrichtigungen für alle Ihre Ressourcen, einschließlich lokale Ressourcen und Ressourcen in anderen Clouds, in einem einzigen Dashboard anzeigen lassen.

Die Seite "Aktivität" verwenden, um die Aktivität in den Projekten Ihres Unternehmens zu betrachten

Die Seite "Aktivität" in der GCP Console zeigt den unternehmensweiten Verlauf der Aktivitäten in all Ihren Projekten. Er kann nach einem oder mehreren Projekten, Aktivitätsarten und Datumsbereichen gefiltert werden, um schnell Änderungen und Anpassungen zu finden. Ein Reihe an Kernprodukten unterstützt aktuell den Aktivitätsverlauf und weitere werden im Laufe der Zeit hinzugefügt.

Support und Schulung

Mindestens Gold-Support für Produktionsanwendungen erwerben

Ein Supportpaket wird für das gesamte Unternehmen erworben. Obwohl eine breite Palette an Supportpaketen zur Verfügung steht, empfehlen wir dringend die Gold- und Platin-Pakete, damit schwerwiegende Probleme in Projekten auf Produktionsebene zügig gelöst werden.

Community als exzellente Hilfsquelle nutzen

Die Nutzer-Community wird von Google-Mitarbeitern aktiv unterstützt und gefördert. Unter Überblick über den Community-Support erfahren Sie, wo Sie die verschiedenen Community-Seiten mit ausführlichen Informationen zur Cloud Platform finden.

Gängige Fallstricke mit Schulungen für Einsteiger und Fortgeschrittene vermeiden

Die Qualifikationsschulungen von Google für die Cloud-Plattform reichen von Einführungskursen, die Ihnen einen allgemeinen Überblick verschaffen, bis zu ausführlichen Intensivkursen zu bestimmten Technologien. Auf der Website der Google Cloud Platform können Sie einen Kurs auswählen.

Wir empfehlen, dass sich zumindest wichtige Mitarbeiter in Ihrer Organisation Cloud Platform-Qualifikationen aneignen. Der Kurs CPO200: Die Google Cloud Platform für Systems Operations-Profis ist besonders hilfreich für Mitarbeiter, die Compute Engine-Anwendungen bereitstellen und verwalten.

Interne Kompetenzzentren für Produkte aufbauen

Die Cloud Platform bietet ein breites Spektrum an Produkten, Diensten und APIs, die auf kreative und unerwartete Weise kombiniert werden können. Google investiert kontinuierlich in diese Produkte und stellt fortlaufend neue Funktionen bereit. Es kann sich als nützlich erweisen, die Informationen, Erfahrungswerte und Arbeitsabläufe Ihrer Organisation in einer internen Knowledge Base wie einem Wiki, einer Google Sites-Website oder einer Intranet-Website festzuhalten.

Führen Sie in Ihrem Wiki die Produktexperten auf, die neue Nutzer beraten und bei der Verwendung bestimmter Cloud Platform-Produkte gemäß den Best Practices Ihrer Organisation unterstützen können.

Internes Support-Clearinghouse einrichten

Die Anzahl der Personen, die Sie zum Einreichen von Support-Tickets im Namen Ihrer Organisation autorisieren können, ist beschränkt. Wir empfehlen daher, dass Sie ein internes Support-Clearinghouse oder ein Team zum Sichten einrichten. Damit können Sie doppelte Tickets und Kommunikationspannen vermeiden und die Kommunikation mit dem Google Cloud-Support so klar wie möglich halten.

Google Partner nutzen

Von Zeit zu Zeit kann es vorkommen, dass Sie die Expertise und Kapazität Ihrer Organisation durch Hilfe von außen ergänzen müssen. Google hat ein umfangreiches Partnernetzwerk aufgebaut, das Ihnen in diesem Fall unter die Arme greifen kann. Weitere Informationen zu Partnern finden Sie unter Google Cloud Platform – Partner.

Keine Cloud Platform-Nachrichten und -Ankündigungen mehr verpassen

Wenn Sie den Google Cloud Platform-Blog abonnieren, sind Sie immer über die aktuellen Neuigkeiten, Ankündigungen und Kundenberichte informiert.

Abrechnung und Kostenverteilung

In der monatlichen Rechnung sind Kosten nach Projekt und dann nach Ressourcentyp gegliedert

Ihre monatliche Rechnung wird per E-Mail an Ihren Abrechnungsadministrator gesendet. Die Rechnung beinhaltet viele Details. Erinnern Sie sich daran, dass in der Rechnung die Ressourcennutzung erst nach Projekt und dann nach Ressourcentyp aufgegliedert ist. Die sorgfältige Wahl des Namens eines Projekts lässt Sie einfach erkennen, welche Teams oder Produkte Ressourcen verbrauchen. Sie können diese Informationen verwenden, um Ausgleichsbuchungen für diese Abteilungen in Ihrem Unternehmen zu vereinfachen.

Nutzen Sie den täglichen Export der Rechnung, um eine für Maschinen lesbare Version Ihrer Rechnung zu erhalten

Sie können die Funktion, Rechnungen zu exportieren, aktivieren, um täglich eine detaillierte Auflistung der Produkte zu erhalten. Diese Datei kann entweder als JSON oder CVS formatiert und in einem Cloud Storage-Bucket veröffentlicht werden. Diese unbearbeiteten Daten können die täglichen Berichte über Ihre Nutzung von und Kosten für Cloud Platform vereinfachen. Den Abrechnungsexport aktivieren Sie im Bereich zur Verwaltung des Rechnungskontos der GCP Console.

Projekt-Labels verwenden, um Projekte im Abrechnungsexport weiter einzuteilen

In der GCP Console haben Sie auf der Seite Projekte die Möglichkeit, Projekten benutzerdefinierte Labels als Schlüssel/Wert-Paare hinzuzufügen. Diese Labels werden in der Abrechnungsexportdatei angezeigt. Verwenden Sie diese Labels, um Projekte weiter einzuteilen.

Gutschriften erhalten Sie auf Ihrem Rechnungskonto, nicht für ein spezielles Projekt

Wenn Sie Gutschriften erhalten, beispielsweise wegen einer Rückerstattung oder zu Werbezwecken, wird der Betrag Ihrem Rechnungskonto gutgeschrieben, nicht einem bestimmten Projekt. Dies bedeutet, dass alle Projekte diese Gutschriften verbrauchen, bis sie aufgebraucht sind. Dadurch kann die exakte Kostenberechnung etwas erschwert werden. Gutschriften erhalten Sie im Allgemeinen aber so selten, dass Sie auf Ihre Kostenberechnungen keinen großen Einfluss haben sollten.

Ausgaben für Projekte können gedeckelt werden

Kosten in Compute Engine werden über das Kontingentsystem gesteuert. Jedes Projekt hat ein bestimmtes Kontingent, das die Obergrenze der Ressourcen, die ein Projekt verbrauchen kann, bestimmt. Füllen Sie das Formular "Anfrage zur Kontingentänderung" aus, um diese Kontingente anzupassen.

Für App Engine, eine automatisch skalierende Ressource, können Sie ein Support-Ticket eröffnen, um eine Funktion zu erhalten, die Sie ein maximales tägliches Budget festlegen lässt. Wenn Sie diese Grenze überschritten haben, stellt die App ihren Dienst ein. Seien Sie also sorgfältig im Umgang mit dieser Funktion. Beachten Sie, dass das Maximum eine Schätzung ist. Die Berechnung exakter Verbrauchskosten muss offline geschehen.

Benachrichtigungen für monatliche Ausgabegrenzen einrichten

Sie können eine monatliche Grenze für jedes Rechnungskonto konfigurieren. Beachten Sie, dass dies keine Grenze für die Ausgaben des Rechnungskontos darstellt. Stattdessen ist es ein Mechanismus zur Überwachung. Abrechnungsadministratoren erhalten Benachrichtigungen, wenn das Konto 50 %, 90 % und 100 % der monatlichen Grenze erreicht. Die tatsächlich berechneten Kosten können nach der Abrechnung höher ausfallen. Sie können diese Einstellungen in der GCP Console auf der Seite Benachrichtigungen für Ihr Rechnungskonto konfigurieren.

BigQuery-Kosten überwachen und analysieren

Sie können vor der Rechnung eine Schätzung der BigQuery-Kosten erhalten, indem Sie die BigQuery-Methode Jobs:list verwenden, um eine Auflistung der pro Anfrage berechneten Byte der letzten sechs Monate zu erhalten. Außerdem besteht die Möglichkeit, die Kosten nach einzelnen Abfragen aufzuschlüsseln. Verwenden Sie hierfür die Methode Jobs:get, um die Abfrage und den Abfragesteller zu ermitteln.

Risikomanagement

Projekte zur Bestimmung von Ressourceninhaberschaft benutzen

Sie können Cloud Platform-Projekte benutzen, um die Inhaberschaft von Cloud Platform-Ressourcen innerhalb Ihres Unternehmens zu bestimmen. Denken Sie daran, dass eine bestimmte Abteilung mehrere Projekte und die darin enthaltenen Ressourcen besitzen kann. Sie können Projekt-Labels verwenden, um Inhaberschaft im Unternehmen zu kennzeichnen oder andere Dimensionen, die Sie überwachen wollen. Sie können beispielsweise Labels wie owner:marketing oder cost-center:cc-123 zu einem Projekt hinzufügen. Diese Labels können so konfiguriert werden, dass sie in der GCP Console und der exportierten Rechnung sichtbar sind, und sie können als Filter in API-Aufrufen verwendet werden.

Nur Abrechnungsadministratoren können neue Projekte erstellen

Abrechnungsadministratoren sind die einzigen, die neue Projekte erstellen, die über ihr Rechnungskonto abrechenbar sind, können. Indem Sie den Abrechnungsadministratoren die Verantwortung für den Ressourcenverbrauch übertragen, ist jemand für den Ressourcenverbrauch und die Kosten für die Ressourcen verantwortlich.

Projektinhaber nutzen, um die Verantwortung für den Zugriff auf eigene Ressourcen zu steuern

Jedes Projekt hat bestimmte Inhaber, die einzelne Personen sein müssen. Gruppen sind nicht möglich. Diese Inhaber haben die Möglichkeit, herauszufinden, wer Zugriff auf das Projekt hat, wie darauf zugegriffen wurde und in welcher Rolle. Nutzen Sie Projektinhaber, um die Verantwortung für Ressourcen in Ihrem Unternehmen zu übertragen.

Ressourcenlabels nutzen, um die Inhaber innerhalb eines Projekts oder zwischen Projekten zu identifizieren

Manche Ressourcen, wie VM-Instanzen, erlauben es Ihnen, Labels mit Namenswerten hinzuzufügen. Verwenden Sie diese Labels, um die Ressourceninhaberschaft weiter zu unterteilen. Zum Beispiel: owner:johndoe.

Nutzern die geeigneten Berechtigungen einräumen, um dem Prinzip der geringsten Berechtigung zu entsprechen

Cloud Platform bietet eine Reihe an Mechanismen, um die Berechtigungen für das Prinzip der geringsten Berechtigung genauer zu regulieren. Geben Sie Entwicklern die geringsten Berechtigungen auf der Projektebene: Die Rollen viewer, editor und owner. Diese Berechtigungen werden von Ressourcen wie Compute Engine und Cloud Storage übernommen. Mit der Rolle owner sollen Teammitgliedschaften, Autorisierungen usw. verwaltet werden.

Evaluieren Sie, ob Entwickler überhaupt Zugriff auf Projektebene benötigen, oder ob es ausreicht, ihnen Zugriff auf eine bestimmte Cloud Platform-Ressource zu gewähren. Beispielsweise können Sie SSH-Schlüssel zu Ihren Instanzen hinzufügen, um Entwicklern Zugriff auf individuelle VM-Instanzen zu gewähren, ohne ihnen Zugriff auf das Projekt oder alle Instanzen in dem Projekt zu gewähren.

Compliance der Überwachungsrichtlinie mit ACL-Berichten

Mithilfe von Sicherheitsberichten lassen sich Domainrollen wie Super Admin überwachen. Alternativ können Sie dafür die Roles API in einer zentralen Berichtslösung einsetzen. Bei einem Complianceverstoß werden dann Benachrichtigungen verschickt oder Berechtigungen automatisch aufgehoben.

Verwenden Sie die GCP Console, um die Projektnutzung für Aufgaben außerhalb der Richtlinien zu überwachen, oder verwenden Sie stattdessen die Cloud IAM API in einer zentralen Lösung für Berichte, um automatisch Benachrichtigungen zu versenden oder den Zugriff aufzuheben.

Verwenden Sie die Cloud Storage Bucket Access Controls API, um die Bucket-Nutzung für Aufgaben außerhalb der Richtlinien zu überwachen und schicken Sie automatisch Benachrichtigungen oder heben Sie den Zugriff automatisch auf. Dies ist besonders wichtig für Audit-Log-Buckets.

Richtlinien mit Policy-Entitlement-Systemen durchsetzen

Durch das Logging, Überwachen und Prüfen in Cloud Platform können Sie Bedrohungen erkennen und Risiken minimieren. Sie können auch Richtlinien definieren, verwalten und durchsetzen, indem Sie sie an Drittanbieter oder Policy-Entitlement-Systeme anpassen, oder, indem Sie Ihre eigene Richtlinie erstellen. Dadurch können Sie zwischen Rollen der Projektinhaberschaft und Rollen der Richtlinienverwaltung unterscheiden. Zur Umsetzung dieses Plans müssen Sie die Projektinhaberkonten und -Berechtigungen weit im Voraus planen – insbesondere hinsichtlich der übernommenen Berechtigungen, wie die für Cloud Storage. Sie sollten auch evaluieren, ob die APIs Ihre benötigten Vorgänge zur Richtlinienverwaltung unterstützen.

Plan für die Notfallwiederherstellung

Vorfälle, die den Dienst unterbrechen, können jederzeit geschehen. Ihr Netzwerk könnte von einem Ausfall betroffen sein, mit Ihrem letzten App-Push könnte ein kritischer Fehler eingeführt worden sein oder Sie könnten, in seltenen Fällen, mit einer Naturkatastrophe zu kämpfen haben.

Wenn etwas schiefgeht, ist es wichtig, einen robusten, zielgerichteten und gut getesteten Plan für die Notfallwiederherstellung zu haben. Cloud Platform bietet viele der Funktionen, die Sie für die Implementierung eines solchen Plans benötigen. Beispielsweise Redundanz, Skalierbarkeit, Compliance und Sicherheit.

Im Disaster Recovery Cookbook werden Sie durch einige Szenarien geführt, um Ihnen zu zeigen, wie Cloud Platform helfen kann.

Machen Sie sich mit den Nutzungsrichtlinien und Compliance-Zertifizierungen vertraut

Einige wichtige Links:

Weitere Informationen

Testen Sie die weiteren Google Cloud Platform-Funktionen. Anleitungen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...