Sichere Einstellungen für Unternehmen

Verwenden Sie die boolesche Einschränkung automaticIamGrantsForDefaultServiceAccounts, um automatische Rollenzuweisungen zu deaktivieren, wenn Cloud de Confiance by S3NS Dienste automatisch Standarddienstkonten mit zu umfangreichen Rollen erstellen.

Standardmäßig werden automatisierten Konten in einigen Systemen zu weitreichende Berechtigungen erteilt, was ein potenzielles Sicherheitsrisiko darstellt. Wenn Sie diese Einschränkung beispielsweise nicht erzwingen und ein Standarddienstkonto erstellen, erhält das Dienstkonto automatisch die Rolle „Bearbeiter“ (roles/editor) für Ihr Projekt. Wenn ein Angreifer einen einzelnen Teil des Systems manipuliert, kann er die Kontrolle über das gesamte Projekt erlangen. Diese Einschränkung deaktiviert diese automatischen Berechtigungen auf hoher Ebene und erzwingt einen sichereren, bewussten Ansatz, bei dem nur die minimal erforderlichen Berechtigungen gewährt werden.

Mit der booleschen Einschränkung iam.disableServiceAccountKeyCreation können Sie verhindern, dass externe Dienstkontoschlüssel erstellt werden. Mit dieser Einschränkung können Sie die Verwendung von nicht verwalteten, langfristigen Anmeldedaten für Dienstkonten steuern. Wenn diese Einschränkung festgelegt ist, können Sie keine von Nutzern verwalteten Anmeldedaten für Dienstkonten in Projekten erstellen, die von der Einschränkung betroffen sind.

Mit der booleschen Einschränkung iam.disableServiceAccountKeyUpload können Sie das Hochladen externer öffentlicher Schlüssel in Dienstkonten deaktivieren. Wenn diese Einschränkung festgelegt ist, können Nutzer keine öffentlichen Schlüssel in Dienstkonten in Projekten hochladen, die von der Einschränkung betroffen sind.

Google empfiehlt Titan-Sicherheitsschlüssel für die 2‑Faktor-Authentifizierung (2FA) für Super Admin-Konten. Für Anwendungsfälle, in denen dies nicht möglich ist, empfehlen wir jedoch, stattdessen einen anderen Sicherheitsschlüssel zu verwenden.

Erzwingen Sie die 2‑Faktor-Authentifizierung für eine bestimmte Organisationseinheit oder die gesamte Organisation. Wir empfehlen, eine OE für Super Admins zu erstellen und die Bestätigung in zwei Schritten für diese OE zu erzwingen.

Es gibt keinen einzelnen Super Admin oder Organisationsadministrator. Erstellen Sie ein oder mehrere (bis zu 20) Administrator-Sicherungskonten. Ein einzelner Super Admin oder Organisationsadministrator kann zu Sperrszenarien führen. Diese Situation birgt auch ein höheres Risiko, da eine Person plattformverändernde Änderungen vornehmen kann, möglicherweise ohne Aufsicht.

Verwenden Sie Privileged Access Manager, um privilegierten Zugriff zu verwalten. Verwenden Sie für alle anderen Zugriffe Zugriffsgruppen, lassen Sie Gruppenmitgliedschaften automatisch ablaufen und implementieren Sie einen Genehmigungsworkflow für Gruppenmitgliedschaften.

Wenn Sie das Modell der geringsten Berechtigung verwenden, können Sie nur bei Bedarf Zugriff auf die benötigten Ressourcen gewähren. Die Verwendung vordefinierter Rollen vereinfacht die Nutzung und reduziert die durch benutzerdefinierte Rollen verursachte Ausweitung, sodass Sie sich nicht um die Verwaltung des Rollenlebenszyklus kümmern müssen.

Legen Sie die zentrale Datenquelle für die Bereitstellung verwalteter Nutzeridentitäten fest. Zu den Mustern gehören das Erstellen von Nutzeridentitäten in Cloud Identity, das Synchronisieren von Identitäten von einem vorhandenen Identitätsanbieter oder die Verwendung der Mitarbeiteridentitätsföderation.

Erzwingen Sie starke und eindeutige Passwörter für alle Nutzerkonten. Verwenden Sie einen Passwortmanager. Schwache oder fehlende Anmeldedaten sind ein häufiges Muster, das böswillige Nutzer leicht ausnutzen können.

Verwenden Sie IAM-Rollen (Identity and Access Management), die auf Jobfunktionen basieren, um Nutzern Berechtigungen zuzuweisen. Jobfunktionen sind vordefinierte Rollen, mit denen Administratoren eine Reihe von Berechtigungen bereitstellen können, die auf eine Jobfunktion beschränkt sind. So wird die Produktivität gesteigert und der Aufwand für das Anfordern von Berechtigungen verringert. Um die Anforderungen Ihrer Organisation besser zu erfüllen, können Sie benutzerdefinierte Rollen auf Grundlage vordefinierter Rollen erstellen.

Organisationsweite Richtlinien festlegen, um zu verhindern, dass externe Mitglieder zu Google-Gruppen hinzugefügt werden

Standardmäßig können externe Nutzerkonten zu Gruppen in Cloud Identity hinzugefügt werden. Wir empfehlen, die Freigabe-Einstellungen so zu konfigurieren, dass Gruppeninhaber keine externen Mitglieder hinzufügen können.

Hinweis: Diese Einschränkung gilt nicht für das Super Admin-Konto oder andere delegierte Administratoren mit Google Groups-Administratorberechtigungen. Da die Föderation von Ihrem Identitätsanbieter mit Administratorberechtigungen ausgeführt wird, gelten die Einstellungen für die Gruppenfreigabe nicht für diese Gruppensynchronisierung. Wir empfehlen Ihnen, die Steuerelemente beim Identitätsanbieter und im Synchronisierungsmechanismus zu prüfen, um sicherzustellen, dass Mitglieder, die nicht zur Domain gehören, nicht zu Gruppen hinzugefügt werden, oder Gruppeneinschränkungen anzuwenden.

Legen Sie die Sitzungsdauer für Cloud de Confiance by S3NS -Dienste so fest, dass sie mindestens einmal täglich abläuft. Wenn Sie ein Konto über einen längeren Zeitraum angemeldet lassen, kann das ein Sicherheitsrisiko darstellen. Wenn Sie eine maximale Sitzungsdauer erzwingen, wird die Sitzung nach einer bestimmten Zeit automatisch beendet und eine neue, sichere Anmeldung ist erforderlich.

So wird die Wahrscheinlichkeit verringert, dass ein böswilliger Nutzer ein gestohlenes Passwort verwendet, und der Zugriff wird regelmäßig neu überprüft.

Bei Neukunden wird automatisch eine Standardsitzungslänge von 16 Stunden erzwungen. Kunden, die ihre Cloud de Confiance by S3NS -Organisation vor 2023 erstellt haben, haben möglicherweise eine Standardeinstellung, die eine erneute Authentifizierung nie erfordert. Prüfen Sie diese Einstellung, um sicherzustellen, dass Sie eine Richtlinie für die erneute Authentifizierung mit einer Sitzungslänge zwischen 1 und 24 Stunden haben. Die Richtlinie zur erneuten Authentifizierung macht das Aktualisierungstoken ungültig und zwingt den Nutzer, die gcloud CLI regelmäßig mit seinem Passwort oder Sicherheitsschlüssel neu zu authentifizieren.

Die Sitzungslänge für Cloud de Confiance by S3NS -Dienste unterscheidet sich von der Sitzungslänge für Google-Dienste, die Websitzungen für die Anmeldung in Google Workspace-Diensten steuert, aber keine Kontrolle über die erneute Authentifizierung für die Cloud de Confiance by S3NShat. Wenn Sie Google Workspace-Dienste verwenden, legen Sie die Sitzungsdauer für beide fest.

Nicht verwaltete Privatnutzerkonten nicht zulassen. Konsolidieren Sie alle nicht verwalteten Privatnutzerkonten und überlegen Sie sich eine Lösung, um die Erstellung weiterer nicht verwalteter Privatnutzerkonten mit Ihrer Domain zu verhindern.

Nicht verwaltete Privatnutzerkonten unterliegen nicht Ihren Prozessen für neue, wechselnde und ausscheidende Mitarbeiter. Daher besteht das Risiko, dass ein Mitarbeiter nach seinem Ausscheiden weiterhin Zugriff auf Ihre Ressourcen hat. Diese Konten werden auch in Bezug auf Steuerelemente wie die domaineingeschränkte Freigabe als extern behandelt.

Super Admin-Konten sollten von den Nutzerkonten für den täglichen Gebrauch getrennt sein. Super Admin-Konten müssen dedizierte Konten sein, die nur für wichtige Änderungen verwendet werden. Aktivieren Sie die Genehmigung durch mehrere Parteien für Administratoraktionen, um die Sicherheit zu erhöhen. Wenn Sie die Genehmigung durch mehrere Parteien aktivieren, werden sensible Aktionen von zwei Administratoren genehmigt. So wird verhindert, dass Angreifer ein Administratorkonto kompromittieren und andere Administratoren aussperren.

Aktivieren Sie die Multi-Faktor-Authentifizierung (MFA), auch 2‑Faktor-Authentifizierung (2FA) genannt, für alle Google-Konten und Cloud Identity-Nutzer, nicht nur für Super Admins. Die MFA für Super Admins ist standardmäßig aktiviert. Die MFA bietet eine zusätzliche Sicherheitsebene, da Passwörter allein oft nicht ausreichen.

Entfernen Sie die domainweiten Rollen „Project Creator“ und „Billing Account Creator“, die standardmäßig allen Mitgliedern einer neuen Organisation zugewiesen werden.

In neuen Organisationen werden allen verwalteten Nutzeridentitäten in der Domain die Rollen „Projektersteller“ und „Rechnungskontoersteller“ zugewiesen. Diese Rollen sind zwar nützlich für den Einstieg, diese Konfiguration ist jedoch nicht für Produktionsumgebungen vorgesehen. Wenn sich Abrechnungskonten vermehren, führt das zu einem erhöhten Verwaltungsaufwand und hat technische Folgen, wenn Dienste auf mehrere Abrechnungskonten aufgeteilt werden. Wenn Sie die kostenlose Projekterstellung zulassen, kann es zu Projekten kommen, die nicht Ihren Governance-Konventionen entsprechen.

Entfernen Sie stattdessen diese Rollen und richten Sie einen Prozess zum Erstellen von Projekten ein, um neue Projekte anzufordern und sie mit der Abrechnung zu verknüpfen.

Wenn Sie Dienstkontoschlüssel verwenden müssen, rotieren Sie die Schlüssel mindestens alle 90 Tage.

Ein Rotationsintervall begrenzt, wie lange ein Angreifer Zugriff auf das System haben kann. Ohne Rotationsintervall hat der Angreifer dauerhaft Zugriff. Verwenden Sie nach Möglichkeit die Workload Identity-Föderation anstelle von Dienstkontoschlüsseln.

Mit Workload Identity-Föderation können sich CI/CD-Systeme und Arbeitslasten, die in anderen Clouds ausgeführt werden, bei Cloud de Confiance by S3NSauthentifizieren. Mit der Workload Identity-Föderation können sich Arbeitslasten, die außerhalb von Cloud de Confiance ausgeführt werden, authentifizieren, ohne dass ein Dienstkontoschlüssel erforderlich ist. Wenn Sie Dienstkontoschlüssel und andere langlebige Anmeldedaten vermeiden, kann die Workload Identity-Föderation dazu beitragen, das Risiko von Anmeldedatenlecks zu verringern.

Die eigenständige Kontowiederherstellung durch Super Admins ist für neue Kunden standardmäßig deaktiviert. Bestehende Kunden haben diese Einstellung möglicherweise aktiviert. Durch das Deaktivieren dieser Einstellung verringern Sie das Risiko, dass ein manipuliertes Telefon, ein manipuliertes E-Mail-Konto oder ein Social Engineering-Angriff Angreifern in Ihrer Umgebung Super Admin-Berechtigungen gewähren kann.

Planen Sie einen internen Prozess, damit ein Super Admin einen anderen Super Admin in Ihrer Organisation kontaktieren kann, wenn er keinen Zugriff mehr auf sein Konto hat. Sorgen Sie außerdem dafür, dass alle Super Admins mit dem Prozess für die supportgestützte Wiederherstellung vertraut sind.

Wenn Sie die Funktion deaktivieren möchten, rufen Sie in der Admin-Konsole die Einstellungen zur Kontowiederherstellung auf.

Legen Sie das Zeitlimit für Inaktivitätssitzungen für sensible Anwendungsfälle auf 15 Minuten fest. Inaktive Sitzungen können von Angreifern zum Diebstahl von Anmeldedaten verwendet werden.

Stellen Sie Powerusern oder Organisationsadministratoren nach Möglichkeit Hardwaresicherheitsschlüssel als zweiten Faktor zur Verfügung. Super Admin-Konten sind die wertvollsten Ziele für ausgeklügelte Angriffe. Hardware-Sicherheitsschlüssel bieten ein hohes Maß an Schutz, da sie phishing-resistent sind. Hardware-Sicherheitsschlüssel sind die bestmögliche Verteidigung gegen Kontoübernahmen für Ihre wichtigsten Administratoren und bauen auf Ihrer Standardrichtlinie für die Bestätigung in zwei Schritten auf.

Wenn Sie einen externen Identitätsanbieter verwenden, richten Sie die Post-SSO-Prüfung ein.

Aktivieren Sie eine zusätzliche Steuerungsebene, die auf der Risikoanalyse für das Google-Log-in basiert. Nachdem Sie diese Einstellung angewendet haben, können Nutzer bei der Anmeldung zusätzliche risikoabhängige Identitätsbestätigungen sehen, wenn Google der Meinung ist, dass eine Nutzeranmeldung verdächtig ist.

Aktivieren Sie Principal Access Boundary-Richtlinien (PAB), um den Zugriff von Identitäten einzuschränken und sich vor Phishing und Daten-Exfiltration zu schützen. Aktivieren Sie eine PAB-Richtlinie für die Organisation, um externe Phishing-Angriffe zu vermeiden. PABs verbessern die Sicherheit, indem sie das Ausmaß eines Angriffs mit einer kompromittierten Identität verringern. Außerdem tragen sie dazu bei, externe Phishing- und andere Exfiltrationsangriffe zu verhindern.

Mit Tags können Sie Annotationen für Ressourcen erstellen und in einigen Fällen Richtlinien je nachdem, ob eine Ressource ein bestimmtes Tag hat, zulassen oder ablehnen. Tags und die bedingte Erzwingung von Richtlinien ermöglichen Ihnen, die Ressourcenhierarchie genau zu steuern.

Mit Cloud-Audit-Logs können Sie Aktivitäten mit hohem Risiko überwachen, z. B. wenn Konten Rollen mit hohem Risiko wie „Administrator der Organisation“ und „Super Admin“ zugewiesen werden. Richten Sie Benachrichtigungen für diese Art von Aktivität ein.

Um zu umfangreichen Zugriff auf Cloud de Confiance by S3NSzu vermeiden, können Sie den Zugriff auf Cloud Shell für von Cloud Identity verwaltete Nutzerkonten blockieren.

Mit dem kontextsensitiven Zugriff können Sie detaillierte Sicherheitsrichtlinien zur Zugriffssteuerung für Anwendungen auf Grundlage von Attributen wie Nutzer-ID, Standort, Sicherheitsstatus des Geräts oder IP-Adresse erstellen. Wir empfehlen, den Zugriff auf die Cloud de Confiance -Konsole (https://console.cloud.google.com/) und die Google Admin-Konsole (https://admin.cloud.google.com) mit dem kontextsensitiven Zugriff einzuschränken.

Cloud de Confiance unterstützt mehrere TLS-Protokollversionen. Um Compliance-Anforderungen zu erfüllen, sollten Sie Handshake-Anfragen von Clients, die ältere TLS-Versionen verwenden, ablehnen.

Verwenden Sie zum Konfigurieren dieses Steuerelements die Einschränkung der Organisationsrichtlinie TLS-Versionen einschränken (gcp.restrictTLSVersion). Sie können diese Einschränkung auf Organisationen, Ordner oder Projekte in der Ressourcenhierarchie anwenden. Für die Einschränkung TLS-Versionen einschränken wird eine Sperrliste verwendet, in der explizite Werte abgelehnt und alle anderen zugelassen werden. Wenn Sie versuchen, eine Zulassungsliste zu verwenden, tritt ein Fehler auf.

Aufgrund der Auswertung der Hierarchie von Organisationsrichtlinien gilt die Einschränkung der TLS-Version für den angegebenen Ressourcenknoten und alle zugehörigen Ordner und Projekte (untergeordnete Elemente). Wenn Sie beispielsweise die TLS-Version 1.0 für eine Organisation ablehnen, wird diese auch für alle untergeordneten Elemente abgelehnt, die von dieser Organisation abstammen.

Sie können die übernommene TLS-Versionsbeschränkung überschreiben, indem Sie die Organisationsrichtlinie für eine untergeordnete Ressource aktualisieren. Wenn in Ihrer Organisationsrichtlinie beispielsweise TLS 1.0 auf Organisationsebene abgelehnt wird, können Sie die Einschränkung für einen untergeordneten Ordner entfernen, indem Sie eine separate Organisationsrichtlinie für diesen Ordner festlegen. Wenn der Ordner untergeordnete Elemente hat, wird die Richtlinie des Ordners aufgrund der Richtlinienübernahme auch auf jede untergeordnete Ressource angewendet.

Wenn Sie die TLS-Version weiter auf TLS 1.3 beschränken möchten, können Sie diese Richtlinie so festlegen, dass auch TLS-Version 1.2 eingeschränkt wird. Sie müssen diese Steuerung in Anwendungen implementieren, die Sie in Cloud de Confiance by S3NShosten. Legen Sie beispielsweise auf Organisationsebene Folgendes fest:

["TLS_VERSION_1","TLS_VERSION_1.1","TLS_VERSION_1.2"]

Sorgen Sie dafür, dass nur Identitäten aus Ihrer Organisation in Ihrer Cloud de Confiance by S3NS -Umgebung zugelassen sind. Verwenden Sie die Organisationsrichtlinieneinschränkung Domaineingeschränkte Freigabe (iam.allowedPolicyMemberDomains) oder iam.managed.allowedPolicyMembers, um mindestens eine Cloud Identity- oder Google Workspace-Kundennummer zu definieren, deren Hauptkonten IAM-Richtlinien (Identity and Access Management) hinzugefügt werden können.

Diese Einschränkungen helfen, zu verhindern, dass Mitarbeiter Zugriff auf externe Konten außerhalb der Kontrolle Ihrer Organisation gewähren, die nicht Ihren Sicherheitsrichtlinien für die Multi-Faktor-Authentifizierung (MFA) oder die Passwortverwaltung entsprechen. Diese Einstellung ist wichtig, um unbefugten Zugriff zu verhindern und dafür zu sorgen, dass nur vertrauenswürdige, verwaltete Unternehmensidentitäten verwendet werden können.

Die Einschränkung gcp.restrictServiceUsagesorgt dafür, dass nur Ihre genehmigten Cloud de Confiance by S3NS Dienste an den richtigen Stellen verwendet werden. Ein Produktions- oder sehr vertraulicher Ordner hat beispielsweise eine kleine Liste von Cloud de Confiance Diensten, die zum Speichern von Daten zugelassen sind. Ein Sandbox-Ordner kann eine längere Liste von Diensten und zugehörigen Datensicherheitskontrollen enthalten, um Daten-Exfiltration zu verhindern. Der Wert ist spezifisch für Ihre Systeme und entspricht Ihrer genehmigten Liste von Diensten und Abhängigkeiten für bestimmte Ordner und Projekte.

Mit dieser Einschränkung kann Ihre Organisation eine Zulassungsliste mit genehmigten Diensten erstellen, um zu verhindern, dass Mitarbeiter nicht geprüfte Dienste verwenden.

Die Einschränkung „Beschränkung des Ressourcenstandorts“ (gcp.resourceLocations) sorgt dafür, dass nur Ihre genehmigten Cloud de Confiance by S3NS Regionen zum Speichern von Daten verwendet werden. Der Wert ist spezifisch für Ihre Systeme und entspricht der genehmigten Liste der Regionen Ihrer Organisation für den Datenstandort.

Mit dieser Einschränkung kann Ihre Organisation erzwingen, dass Ihre Ressourcen und Daten nur in bestimmten, genehmigten geografischen Regionen erstellt und gespeichert werden.

Die boolesche Einschränkung compute.skipDefaultNetworkCreation überspringt die Erstellung des Standardnetzwerks und der zugehörigen Ressourcen beim Erstellen von Cloud de Confiance by S3NS Projekten.

Das Standardnetzwerk ist ein VPC-Netzwerk (Virtual Private Cloud) im automatischen Modus mit vorkonfigurierten IPv4-Firewallregeln, die interne Kommunikationspfade zulassen. Im Allgemeinen ist diese Einrichtung keine empfohlene Sicherheitskonfiguration für Produktionsumgebungen.

DNSSEC (Domain Name System Security Extensions) ist ein Feature des Domain Name System (DNS), mit dem Antworten auf Domainnamenabfragen authentifiziert werden können. Sie bietet keinen Datenschutz für diese Suchvorgänge, verhindert jedoch, dass Angreifer die Antworten auf DNS-Anfragen verfälschen oder manipulieren.

Aktivieren Sie DNSSEC in Cloud DNS an den folgenden Stellen:

• DNS-Zone
• Top-Level-Domain (TLD)
• DNS-Auflösung

Aktivieren Sie den privaten Google-Zugriff für alle Subnetze.

Aktivieren Sie den Zugriff auf private Dienste, um ein privates Netzwerk zwischen Cloud de Confiance by S3NS Diensten wie Google Cloud VMware Engine-Legacy-Netzwerken und Dienstanbietern wie Cloud SQL zu erstellen. Mit dem privaten Dienstzugriff lässt sich vermeiden, dass Netzwerkverbindungen für Arbeitslasten unnötig dem Internet ausgesetzt werden.

Deaktivieren Sie das Erstellen externer IPv6-Subnetze, sofern dies nicht ausdrücklich erforderlich ist. Um die Angriffsfläche zu verringern, sollten Sie IPv6 auf Systemen und in Netzwerken deaktivieren, in denen es nicht aktiv verwaltet wird oder nicht erforderlich ist. Viele Organisationen haben ausgereifte Sicherheitskontrollen und Monitoring für IPv4, aber ihre Tools und Richtlinien erstrecken sich möglicherweise nicht vollständig auf IPv6, was zu einem erheblichen blinden Fleck für Bedrohungen führen kann. Der Betrieb eines Dual-Stack-Netzwerks führt auch zu einer erhöhten Komplexität, da für die effektive Verwaltung und Fehlerbehebung spezielle Konfigurationen und Fachkenntnisse erforderlich sind. Wenn Sie also keinen klaren geschäftlichen Grund für IPv6 haben, kann das Deaktivieren die Umgebung vereinfachen und dafür sorgen, dass der gesamte Traffic einheitlich über Ihre etablierte IPv4-Sicherheitskonfiguration gefiltert wird.

Beschränken Sie den Zugriff auf externe Quellen, da standardmäßig der gesamte Zugriff nach außen zulässig ist. Legen Sie bestimmte Firewallregeln für beabsichtigte Muster von ausgehendem Traffic fest.

Standardmäßig dürfen Systeme oft ausgehende Verbindungen zum Internet herstellen, was als Sicherheitsrisiko angesehen werden kann. Eine Richtlinie vom Typ „Standardmäßig ablehnen“ blockiert ausgehenden Traffic und erfordert, dass spezifische Regeln nur für die bekannten, erforderlichen Ziele erstellt werden.

Beschränken Sie den eingehenden Zugriff nach Möglichkeit nur auf bestimmte Ressourcen und Ressourcenbereiche. Wenn Identity-Aware Proxy (IAP) konfiguriert ist, legen Sie für eingehende SSH- und RDP-Firewallregeln (Remote Desktop Protocol) IAP-IP-Bereiche als Quellen fest.

Durchlässige SSH- und RDP-Firewallregeln ermöglichen Brute-Force-Angriffe. Verwenden Sie stattdessen Cloud de Confiance by S3NS Identity-Aware Proxys (z. B. IAP) für SSH und RDP.

Aktivieren Sie VPC Service Controls als zusätzliche Schutzebene, um potenziellen Datenverlust zu verhindern.

Mit VPC Service Controls können Sie Daten-Exfiltration verhindern, indem Sie Isolationsperimeter für Ihre Cloud-Ressourcen, sensiblen Daten und Netzwerke erstellen.

Der Dienstperimeter schränkt den Nutzen kompromittierter Anmeldedaten ein, da der Perimeter Anfragen an eingeschränkte Dienste blockiert, die von Endpunkten stammen, die von Angreifern kontrolliert werden und sich außerhalb Ihrer Umgebung befinden.

Verwenden Sie für Anwendungen, die hinter Cloud Load Balancing bereitgestellt werden, Google Cloud Armor-Standardrichtlinien oder konfigurieren Sie eigene Richtlinien, um externen Anwendungen oder Diensten Netzwerkschutz von Layer 3 bis Layer 7 hinzuzufügen. Cloud Armor-Sicherheitsrichtlinien schützen Ihre Anwendung durch Layer 7-Filterung. Diese Richtlinien prüfen auch eingehende Anfragen auf häufige Webangriffe oder andere Layer 7-Attribute, um Traffic zu blockieren, bevor er Ihre Back-End-Dienste mit Load-Balancing oder Ihre Back-End-Buckets erreicht. Jede Sicherheitsrichtlinie besteht aus einer Reihe von Regeln, die Attribute von Layer 3 bis Layer 7 enthalten.

Prüfen Sie für jeden Dienstperimeter in der Cloud de Confiance Konsole, ob der Perimetertyp auf „Regulär“ festgelegt ist.

Verwenden Sie Access Context Manager, um für jeden Dienstperimeter zu bestätigen, dass der Perimeter die API schützt.

Mit der booleschen Einschränkung compute.setNewProjectDefaultToZonalDNSOnly können Sie die interne DNS-Einstellung für neue Projekte so festlegen, dass nur zonales DNS verwendet wird. Verwenden Sie zonales DNS, da es im Vergleich zu einzelnen Zonen eine höhere Zuverlässigkeit bietet, weil Fehler bei der DNS-Registrierung isoliert werden .

Wenn Sie Cloud Identity verwenden, geben Sie Audit-Logs aus Cloud Identity für Cloud de Confiance by S3NSfrei.

Audit-Logs zur Administratoraktivität von Google Workspace oder Cloud Identity werden normalerweise in der Google Admin-Konsole verwaltet und angezeigt, separat von Ihren Logs in der Cloud de Confiance -Umgebung. Diese Logs enthalten Informationen, die für Ihre Cloud de Confiance Umgebung relevant sind, z. B. Nutzeranmeldeereignisse.

Wir empfehlen, Cloud Identity-Audit-Logs für Ihre Cloud de Confiance -Umgebung freizugeben, um Logs aus allen Quellen zentral zu verwalten.

Cloud de Confiance -Dienste schreiben Audit-Logeinträge, um die Frage zu beantworten, wer was, wo und wann mit Cloud de Confiance -Ressourcen getan hat.

Aktivieren Sie das Audit-Logging auf Organisationsebene. Sie können das Logging mit der Pipeline konfigurieren, die Sie zum Einrichten der Cloud de Confiance -Organisation verwenden.

In VPC-Flusslogs wird eine Stichprobe von Netzwerkflüssen erfasst, die von VM-Instanzen gesendet und empfangen werden, darunter Instanzen, die als Google Kubernetes Engine-Knoten (GKE) verwendet werden. Die Stichprobe beträgt in der Regel 50% oder weniger der VPC-Netzwerkflüsse.

Wenn Sie VPC-Fluss-Logs aktivieren, aktivieren Sie Logging für alle VMs in einem Subnetz. Sie können jedoch die Menge der in Logging geschriebenen Informationen reduzieren.

Aktivieren Sie VPC-Flusslogs für jedes VPC-Subnetz. Sie können die Protokollierung mit einer Pipeline konfigurieren, mit der Sie ein Projekt erstellen.

Standardmäßig werden durch Firewallregeln nicht automatisch Logs geschrieben.Mit dem Logging von Firewallregeln können Sie die Auswirkungen Ihrer Firewallregeln überwachen, überprüfen und analysieren. Sie können beispielsweise feststellen, ob eine Firewallregel, die Traffic abweisen soll, wie vorgesehen funktioniert. Logging ist auch nützlich, wenn Sie ermitteln möchten, wie viele Verbindungen von einer bestimmten Firewallregel betroffen sind.

Aktivieren Sie das Logging für jede Firewallregel. Sie können das Logging mit einer Pipeline konfigurieren, mit der Sie eine Firewall erstellen.

Standardmäßig wird mit Cloud de Confiance die Prüfung wichtiger Administratoraktivitäten für privilegierte Konten aktiviert und niemand kann sie deaktivieren.

Audit-Logs zur Administratoraktivität enthalten Logeinträge für API-Aufrufe oder andere Aktionen, die die Konfiguration oder Metadaten von Ressourcen ändern. In diesen Logs wird beispielsweise aufgezeichnet, wann Nutzer VM-Instanzen erstellen oder IAM-Berechtigungen ändern.

Audit-Logs zu Administratoraktivitäten enthalten Logeinträge zum Erstellen, Ändern und Löschen von Einschränkungen für Organisationsrichtlinien auf Organisations-, Ordner- und Projektebene.

Diese Logs werden immer geschrieben. Sie können sie nicht konfigurieren, ausschließen oder deaktivieren. Selbst wenn Sie die Cloud Logging API deaktivieren, werden weiterhin Audit-Logs zur Administratoraktivität generiert.

Wir empfehlen Ihrer Organisation, Richtlinien und Verfahren einzurichten, um diese Benachrichtigungen zu überwachen und gemäß Ihren Unternehmensrichtlinien für den Zugriff Aktionen oder Benachrichtigungen zu generieren, um Administratoraktivitäten zu überwachen.

Abonnieren Sie die Benachrichtigungen zu Sicherheitsbulletins für Cloud de Confiance by S3NS -Dienste, um Benachrichtigungen zu Sicherheitslücken und Risikominderungsmaßnahmen zu erhalten.

Wenn Sicherheitsbulletins verfügbar sind, die für Ihren Cloud de Confiance by S3NS -Dienst (z. B. GKE) relevant sind, kann der Dienst Benachrichtigungen zu diesen Ereignissen als Nachrichten in von Ihnen konfigurierten Pub/Sub-Themen veröffentlichen. Sie können diese Benachrichtigungen für ein Pub/Sub-Abo empfangen, Dienste von Drittanbietern einbinden und nach den Benachrichtigungstypen filtern, die Sie erhalten möchten.

Konfigurieren Sie wichtige Kontakte, damit wichtige Benachrichtigungen an einen überwachten Gruppenalias oder eine Mailingliste gesendet werden.

Wenn Sie eine überwachte Gruppen-E-Mail-Adresse verwenden, werden diese zeitkritischen Benachrichtigungen an ein aktives Team gesendet, das schnell reagieren kann.

Mit der Funktion für Abrechnungsanomalien in Cloud Billing können Sie alle Spitzen oder Abweichungen bei den erwarteten Ausgaben im Blick behalten.

Ein plötzlicher, unerwarteter Anstieg der Cloud-Rechnung ist ein wichtiger Indikator für eine Sicherheitsverletzung. Unerwartete Abrechnungsspitzen werden manchmal durch Angreifer verursacht, die sich Zugriff verschafft haben und Ressourcen für unbefugte Aktivitäten nutzen.

Wenn Sie die Erkennung von Abrechnungsanomalien aktivieren, erhalten Sie ein wichtiges Frühwarnsystem, mit dem Sie verdächtige Aktivitäten automatisch kennzeichnen können.

Erstellen Sie eine Logsenke, um Logs für Ihre Sicherheitsmonitoring-Lösung zu exportieren, und legen Sie den Aufbewahrungszeitraum entsprechend Ihren Anforderungen fest.

Die standardmäßigen Aufbewahrungsfristen für Logs sind oft nicht lang genug, um die Anforderungen von 1 bis 7 Jahren zu erfüllen, die durch Compliance-Vorschriften wie PCI oder HIPAA vorgeschrieben sind.

Das Erstellen einer Logsenke zum Exportieren von Logs an einen Ort für die Langzeitspeicherung ist unerlässlich, um bestimmte rechtliche und regulatorische Verpflichtungen zu erfüllen. Mit Logsenken können Sie Protokolle auch an ein zentrales Sicherheitsmonitoring-System senden, um erweiterte Bedrohungen zu erkennen.

Wenn Sie nachverfolgen möchten, wer auf Daten in Ihrer Cloud de Confiance by S3NS -Umgebung zugegriffen hat, aktivieren Sie Audit-Logs zum Datenzugriff. In diesen Logs werden API-Aufrufe aufgezeichnet, mit denen Nutzerdaten gelesen, erstellt oder geändert werden, sowie API-Aufrufe, mit denen Ressourcenkonfigurationen gelesen werden.

Wir empfehlen dringend, Audit-Logs zum Datenzugriff für generative KI-Modelle und sensible Daten zu aktivieren, damit Sie prüfen können, wer die Informationen gelesen hat. Wenn Sie Audit-Logs zum Datenzugriff verwenden möchten, müssen Sie Ihre eigene benutzerdefinierte Erkennungslogik für bestimmte Aktivitäten wie Super Admin-Anmeldungen einrichten.

Audit-Logs zum Datenzugriff können sehr groß sein. Durch Aktivieren von Datenzugriffslogs können Gebühren für die zusätzliche Lognutzung im Cloud de Confiance -Projekt anfallen.

Sie können Cloud Billing-Budgets erstellen, um alle Ihre Cloud de Confiance by S3NS Gebühren zentral zu überwachen. Damit verhindern Sie, dass Ihre Kosten den Rahmen sprengen. Nachdem Sie einen Budgetbetrag festgelegt haben, legen Sie projektbezogene Schwellenwertregelungen für Budgetbenachrichtigungen fest, um E-Mail-Benachrichtigungen auszulösen. Mithilfe dieser Benachrichtigungen können Sie Ihre Ausgaben im Verhältnis zu Ihrem Budget im Blick behalten. Mit Cloud Billing-Budgets können Sie auch die Antworten zur Kostenkontrolle automatisieren.

In Standard-Logs sehen Sie, was die Nutzer Ihrer Organisation tun. In Access Transparency-Logs sehen Sie, was Google-Supportmitarbeiter tun, wenn sie auf das Konto zugreifen. Dieser Zugriff erfolgt in der Regel nur als Reaktion auf eine Supportanfrage. Access Transparency-Logs bieten einen vollständigen und überprüfbaren Audit-Trail für alle Zugriffe, was für die Einhaltung strenger Compliance- und Data Governance-Anforderungen unerlässlich ist.

Sie können Access Transparency auf Organisationsebene aktivieren.

Für weitere Abrechnungsanalysen können Sie Cloud de Confiance by S3NS Abrechnungsdaten in BigQuery oder eine JSON-Datei exportieren. Sie können beispielsweise detaillierte Daten wie Nutzung, Kostenschätzungen und Preise den ganzen Tag automatisch in ein von Ihnen festgelegtes BigQuery-Dataset exportieren. Anschließend haben Sie die Möglichkeit, über BigQuery auf Ihre Cloud Billing-Daten zuzugreifen und eine detaillierte Analyse auszuführen oder mit einem Tool wie Data Studio Daten zu visualisieren.

Alle Daten in Cloud de Confiance werden standardmäßig mit NIST-genehmigten Algorithmen verschlüsselt.

Achten Sie darauf, dass im Cloud Key Management Service (Cloud KMS) nur NIST-genehmigte Algorithmen zum Speichern vertraulicher Schlüssel in der Umgebung verwendet werden. Diese Steuerung sorgt für eine sichere Schlüsselverwendung, indem nur NIST-genehmigte Algorithmen und Sicherheitsmaßnahmen verwendet werden. Das Feld CryptoKeyVersionAlgorithm ist eine bereitgestellte Zulassungsliste.

Entfernen Sie Algorithmen, die nicht den Richtlinien Ihrer Organisation entsprechen.

Legen Sie den Zweck für Cloud KMS-Schlüssel auf ENCRYPT_DECRYPT fest, damit Schlüssel nur zum Ver- und Entschlüsseln von Daten verwendet werden. Diese Steuerung blockiert andere Funktionen wie das Signieren und sorgt dafür, dass Schlüssel nur für den vorgesehenen Zweck verwendet werden. Wenn Sie Schlüssel für andere Funktionen verwenden, sollten Sie diese Anwendungsfälle validieren und in Erwägung ziehen, zusätzliche Schlüssel zu erstellen.

Das Schutzniveau gibt an, wie kryptografische Vorgänge ausgeführt werden. Nachdem Sie einen vom Kunden verwalteten Verschlüsselungsschlüssel (Customer-Managed Encryption Key, CMEK) erstellt haben, können Sie das Schutzniveau nicht mehr ändern. Folgende Schutzniveaus werden unterstützt:

• SOFTWARE:Kryptografische Vorgänge werden in Software ausgeführt.
• HSM:Kryptografische Vorgänge werden in einem Hardware-Sicherheitsmodul (HSM) ausgeführt.
• EXTERN:Kryptografische Vorgänge werden mit einem Schlüssel ausgeführt, der in einem externen Schlüsselverwaltungssystem gespeichert ist, das über das Internet mit Cloud de Confiance verbunden ist. Auf symmetrische Verschlüsselung und asymmetrische Signierung beschränkt.
• EXTERNAL_VPC::Kryptografische Vorgänge werden mit einem Schlüssel ausgeführt, der in einem externen Schlüsselverwaltungssystem gespeichert ist, das über ein VPC-Netzwerk (Virtual Private Cloud) mit Cloud de Confiance verbunden ist. Auf symmetrische Verschlüsselung und asymmetrische Signierung beschränkt.

Achten Sie darauf, dass der Rotationszeitraum Ihrer Cloud KMS-Schlüssel auf 90 Tage festgelegt ist. Es empfiehlt sich, Ihre Sicherheitsschlüssel in regelmäßigen Abständen zu rotieren. Mit dieser Steuerung wird die Schlüsselrotation für Schlüssel erzwungen, die mit HSM-Diensten erstellt werden.

Wenn Sie diesen Rotationszeitraum erstellen, sollten Sie auch geeignete Richtlinien und Verfahren für die sichere Erstellung, Löschung und Änderung von Schlüsselmaterial erstellen, damit Sie Ihre Informationen schützen und die Verfügbarkeit sicherstellen können. Dieser Zeitraum muss den Unternehmensrichtlinien für die Schlüsselrotation entsprechen.

Erstellen Sie eine Verschlüsselungsverwaltungsstrategie mit Cloud Key Management Service (Cloud KMS) mit Autokey, Cloud External Key Manager (Cloud EKM) oder beidem. Mit dieser Strategie kann Ihre Organisation ihre eigenen Verschlüsselungsschlüssel verwenden und verwalten, um Ihre spezifischen Anforderungen zu erfüllen. Wenn Sie Ihre eigenen Verschlüsselungsschlüssel verwenden, haben Sie eine detaillierte, prüfbare Kontrolle über den Datenzugriff. Sie können den Zugriff auf Daten sofort blockieren, indem Sie den Schlüssel deaktivieren.

Mit der Einschränkung für Organisationsrichtlinien Einschränken, welche Projekte KMS-CryptoKeys für CMEK bereitstellen können (gcp.restrictCmekCryptoKeyProjects) können Sie definieren, in welchen Projekten kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs) gespeichert werden können. Mit dieser Einschränkung können Sie die Verwaltung von Verschlüsselungsschlüsseln zentralisieren. Wenn ein ausgewählter Schlüssel diese Einschränkung nicht erfüllt, schlägt die Ressourcenerstellung fehl.

Zum Ändern dieser Einschränkung benötigen Administratoren die IAM-Rolle Administrator für Organisationsrichtlinien (roles/orgpolicy.policyAdmin).

Wenn Sie eine zweite Schutzebene hinzufügen möchten, z. B. „Bring Your Own Key“, ändern Sie diese Einschränkung so, dass sie die Schlüsselnamen des aktivierten CMEK darstellt.

Produktspezifische Informationen:

• In der Gemini Enterprise Agent Platform speichern Sie Ihre Schlüssel im Projekt KEY PROJECTS.

Wenn Sie mehr Kontrolle über Schlüsselvorgänge benötigen, als Google Cloud-powered encryption keys zulässt, können Sie kundenverwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs) verwenden. Diese Schlüssel werden mit Cloud KMS erstellt und verwaltet. Speichern Sie die Schlüssel als Softwareschlüssel, in einem HSM-Cluster oder in einem externen Schlüsselverwaltungssystem.

Verschlüsselungs- und Entschlüsselungsraten für Cloud KMS unterliegen Kontingenten.

Cloud Storage-Besonderheiten

In Cloud Storage können Sie CMEKs für einzelne Objekte verwenden oder Ihre Cloud Storage-Buckets so konfigurieren, dass ein CMEK standardmäßig für alle neuen Objekte verwendet wird, die einem Bucket hinzugefügt werden. Wenn Sie einen vom Kunden verwalteten Verschlüsselungsschlüssel verwenden, wird ein Objekt von Cloud Storage zum Zeitpunkt der Speicherung in einem Bucket mit dem Schlüssel verschlüsselt. Das Objekt wird während der Speicherung automatisch von Cloud Storage entschlüsselt, wenn es für Anfragende bereitgestellt wird.

Bei der Verwendung von CMEKs mit Cloud Storage gelten die folgenden Einschränkungen:

• Sie können ein Objekt nicht mit einem CMEK verschlüsseln, indem Sie seine Metadaten aktualisieren. Fügen Sie den Schlüssel stattdessen hinzu, während Sie das Objekt neu schreiben.
• Cloud Storage verwendet den Befehl „Objekte aktualisieren“, um Verschlüsselungsschlüssel für Objekte festzulegen, aber der Befehl schreibt das Objekt als Teil der Anfrage neu.
• Sie müssen den Cloud KMS-Schlüsselbund am selben Ort wie die Daten erstellen, die Sie verschlüsseln möchten. Wenn sich Ihr Bucket beispielsweise in us-east1 befindet, muss jeder Schlüsselbund, der zum Verschlüsseln von Objekten in diesem Bucket verwendet wird, ebenfalls in us-east1 erstellt werden.
• Für die meisten Dual-Regionen müssen Sie den Cloud KMS-Schlüsselbund in der zugehörigen Multiregion erstellen. Wenn sich Ihr Bucket beispielsweise im Paar us-east1, us-west1 befindet, muss jeder Schlüsselbund, der zum Verschlüsseln von Objekten in diesem Bucket verwendet wird, in der US-Multiregion erstellt werden.
• Für die vordefinierten Dual-Regionen asia1, eur4 und nam4 müssen Sie den Schlüsselbund in derselben vordefinierten Dual-Region erstellen.
• Die CRC32C-Prüfsumme und der MD5-Hash von Objekten, die mit CMEKs verschlüsselt sind, werden nicht zurückgegeben, wenn Objekte mit der JSON API aufgelistet werden.
• Wenn Sie Tools wie Cloud Storage verwenden, um zusätzliche Metadatenanfragen GET für jedes Verschlüsselungsobjekt auszuführen, um die CRC32C- und MD5-Informationen abzurufen, kann die Auflistung erheblich kürzer werden. Cloud Storage kann den Entschlüsselungsabschnitt von asymmetrischen Schlüsseln, die in Cloud KMS gespeichert sind, nicht verwenden, um relevante Objekte automatisch auf dieselbe Weise zu entschlüsseln wie CMEKs.