Best Practices für die Aktivierung von VPC Service Controls

In diesem Dokument wird der empfohlene Prozess zum Konfigurieren und Durchsetzen des VPC Service Controls-Schutzes in Ihrer Google Cloud-Organisation beschrieben.

Die sorglose Aktivierung von VPC Service Controls kann Probleme mit vorhandenen Anwendungen verursachen und einen Ausfall verursachen. Wir empfehlen eine sorgfältige Planung, damit Sie ausreichend Zeit haben, um Daten zu erheben, Tests durchzuführen und Logs über Verstöße zu analysieren. Sorgen Sie dafür, dass Mitglieder aus Ihrem VPC Service Controls-Betriebsteam und Ihrem Anwendungsteam für die Aufgabe verfügbar sind.

Für jede Arbeitslast oder Anwendung, die Sie in VPC Service Controls einrichten, sollten Sie den Aktivierungsprozess wiederholen.

Kommunikation koordinieren

Oft ist das Team für Netzwerksicherheit oder Cloud-Aktivierung für die Aktivierung von VPC Service Controls verantwortlich. Wir empfehlen, eine feste Person auszuwählen, die funktionsübergreifende Besprechungen erstellt und verfolgt und Aufgaben dokumentiert. Ihre Teams arbeiten bei Folgendem zusammen:

  • Zugriffsmuster für Google Cloud APIs
  • Identifikation von Verstößen gegen den Dienstperimeter
  • Zugriff auf den Perimeter gewähren

Ähnlich wie bei herkömmlichen Netzwerk-Firewalls sollen die für die effiziente Funktion legitimer geschäftlicher Arbeitslasten erforderlichen Datenflüsse identifiziert und zugelassen werden.

Zugriffsmuster und Anwendungsfälle dokumentieren

Zu Beginn der Aktivierung müssen Sie alle gültigen Zugriffsmuster identifizieren und eindeutig dokumentieren. Zugriffsmuster sind wiederholbare Typen von Interaktionen zwischen Elementen außerhalb und innerhalb des Perimeters. Im Folgenden sind einige gängige Zugriffsmuster aufgeführt:

  • Muster für den Datenzugriff: Dienste außerhalb des Perimeters speichern Daten, die sich im Perimeter befinden, oder rufen diese ab.
  • Ressourcenzugriffsmuster:
    • Nutzer greifen über die Google Cloud Console auf Projekte im Perimeter zu.
    • Tools und Dienste von Drittanbietern verwalten Ressourcen innerhalb des Perimeters und greifen darauf zu.
    • Dienste oder Ressourcen innerhalb des Perimeters greifen auf Google APIs zu.
  • Endpunktzugriffsmuster:
    • Nutzer greifen über ein von Ihrer Organisation verwaltetes Gerät auf Ressourcen innerhalb des Perimeters zu.
    • Lokale Ressourcen kommunizieren mit Ressourcen innerhalb des Perimeters.

Nachdem Sie die Zugriffsmuster für eine Arbeitslast identifiziert haben, identifizieren Sie Ihre Anwendungsfälle und kategorisieren sie unter einem der Zugriffsmuster in der obigen Liste. Im Folgenden sind einige gängige Anwendungsfälle aufgeführt:

  • Cloud-Administratoren verwalten Projekte, die Teil eines Perimeters sind.
  • Automatisierungsdienste wie Terraform, Jenkins und Microsoft Azure DevOps, die sich außerhalb des Perimeters befinden, verwaltet werden, verwalten die Ressourcenbereitstellung innerhalb des Perimeters.
  • Dienste zur Konfigurationsverwaltung wie Ansible, Chef oder Puppet, die sich außerhalb des Perimeters befinden, verwalten die Bereitstellung und Konfiguration von Software für Ressourcen, die sich im Perimeter befinden.
  • Sicherheitsmonitoring und Durchsetzungsdienste wie Forseti oder SIEM, die sich außerhalb des Perimeters befinden, nutzen Daten oder setzen die Sicherheitsrichtlinien für eine Ressource, die sich innerhalb des Perimeters befindet.

Dokumentieren Sie für jeden Anwendungsfall Folgendes:

  • Das Zugriffsmuster
  • Die Aktoren, die den Anwendungsfall auslösen können
  • Bedingungen, die den Anwendungsfall auslösen
  • Ob der Anwendungsfall ein gültiges Zugriffsmuster ist und zugelassen werden sollte
  • Alle Annahmen, die diesen Anwendungsfall betreffen

Ein Beispiel für das Zugriffsmuster und eine Anwendungsfallverfolgung finden Sie unter Vorlage für die VPC Service Controls-Einführung: Anwendungsfälle (PDF).

Interviews durchführen

Führen Sie Interviews mit Ihren Arbeitslastteams durch, um Zugriffsmuster und Anwendungsfälle zu besprechen, die Sie aus den vorangegangenen Kommunikationsvorlagen erfassen. Im Folgenden finden Sie Beispiele für Fragen, die Sie in diesen Interviews stellen können:

  • Haben Ihre Anwendungsfälle eine hohe Priorität und werden bei der VPC Service Controls-Aktivierung berücksichtigt? Wir empfehlen, dass Sie bei der ersten Aktivierung nur Arbeitslasten mit hoher Priorität berücksichtigen und andere, weniger kritische nach dem Schutz geschäftskritischer Ressourcen einführen.

  • Können Sie alle Anwendungsfälle umfassend und abschließend ausführen? Dies machen Sie, um alle möglichen Perimeter-Szenarien auszulösen, damit Sie vollständig analysieren und bestätigen können, dass die Anwendung nach dem Erzwingen des Perimeters ordnungsgemäß funktioniert.

  • Wie lange dauert die Ausführung des Anwendungsfalls?

  • Planen Sie größere Änderungen an dieser Arbeitslast, die möglicherweise mit der Aktivierung von VPC Service Controls in Konflikt stehen? Arbeitslast-Features müssen einen stabilen Status haben, bevor Sie VPC Service Controls aktivieren.

Probelauf vorbereiten

Probelaufmodus das Testen der Erzwingung von VPC Service Controls die Erkennung von Verstößen ohne Unterbrechung der Anwendungen. Sie konfigurieren einen Probelauf als separaten Perimeter, der alle Verstöße protokolliert, aber keine Blockierung ausführt. Sie können Arbeitslasten ausführen, während sie sich im Probelaufperimeter befinden, und Verstoßlogs erstellen, die dann analysiert werden.

So bereiten Sie Umgebung für den Probelauf vor:

  1. Identifizieren Sie alle Projekte, die als Teil des Perimeters qualifiziert sind, und schließen Sie den Anwendungsfall und das Interviewverfahren für diese Projekte ab.
  2. Probelaufperimeter erstellen und fügen Sie alle Projekte hinzu.
  3. Fügen Sie im VPC Service Controls-Dienstperimeter unter Eingeschränkte Dienste > Zu schützende Dienste alle unterstützten Dienste hinzu.

  4. Erstellen: aggregierte Logging-Senke der alle Logs an BigQuery sendet, oder ein Logsenke für jedes Projekt, das die Probelauflogs an eine gemeinsame BigQuery- Dataset. Mit einer SQL-Abfrage können Sie diese Logeinträge abfragen und VPC Service Controls-Verstöße identifizieren.

    Verwenden Sie den folgenden Filter, wenn Sie eine Logsenke erstellen, um alle relevanten VPC Service Controls-Logeinträge einzubeziehen:

    logName="projects/$PROJECT/logs/cloudaudit.googleapis.com%2Fpolicy"

  5. Für maximale Sicherheit sollten Sie den Zugriff auf nicht unterstützte Dienste nicht zulassen. Konfigurieren Sie den Perimeter so, dass nur eingeschränkte Dienste darin funktionieren. Dazu konfigurieren Sie die Liste der zugänglichen Dienste auf RESTRICTED-SERVICES.

  6. Wenn Sie bereits eine Liste zulässiger öffentlicher IP-Adressen, Identitäten, vertrauenswürdiger Geräte, Projekte oder VPC-Netzwerke haben, fügen Sie sie einer Ingress-Regel oder Zugriffsebene im Probelaufperimeter hinzu. Wenn Sie bekannte legitime Abläufe zulassen, lässt sich die Anzahl der Logs zu Verstößen reduzieren und Prüfer können sich auf umsetzbare Ereignisse konzentrieren.

  7. Prüfen Sie, dass keine der VPCs in den Projekten einen ausgehenden Pfad zum Internet oder der privaten VIP hat.

  8. Prüfen Sie, dass bei allen VPCs das *.googleapis.com-DNS auf restricted.googleapis.com verweist.

    Unter Zonendetails steht beim DNS-Namen „*.googleapis.com“ im Feld „Daten“ der Eintrag „restricted.googleapis.com“.

Anwendungsfälle ausführen

Lassen Sie Ihr Anwendungsteam zu einem vereinbarten Zeitpunkt die Arbeitslast für das Projekt im Probelaufperimeter ausführen. Achten Sie darauf, dass Sie den gesamten Code kennen, der Google APIs aufrufen kann. Nach Abschluss des Probelaufs werden Ihre das Verstoßprotokoll analysieren kann.

Verstöße analysieren

Probelaufverletzungs-Logs enthalten die meisten Informationen, die Sie benötigen, um festzustellen, ob ein Anwendungsverstoß Aktionen wie das Hinzufügen von Identitäten oder IP-Adressen zur Zulassungsliste des Perimeters erfordert. Die Daten zu Verstößen werden in der BigQuery-Tabelle cloudaudit_googleapis_com_policy gespeichert. Im Folgenden sind die Hauptelemente zur Analyse des Verstoßes aufgeführt:

  • Der geschützte Dienst und die API-Methode, die aufgerufen.
  • Das Projekt innerhalb des Perimeters, das die Anfrage blockiert hätte.
  • Die E-Mail-Adresse der Identität, die die geschützte API aufruft.
  • Die IP-Adresse des Aufrufers.
  • Die Art des Verstoßes.

Das folgende Beispiel ist eine BigQuery-Abfrage, die alle Details zu Verstößen zurückgibt:

SELECT
receiveTimestamp, #time of violation
Resource.labels.service, #protected Google Cloud service being blocked
protopayload_auditlog.methodName, #method name being called
resource.labels.project_id as PROJECT, #protected project blocking the call
protopayload_auditlog.authenticationInfo.principalEmail, #caller identity
protopayload_auditlog.requestMetadata.callerIp, #caller IP
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator
JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation
protopayload_auditlog.metadataJson, #raw violation entry
FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`
where JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') = "true" #ensure these are dry-run logs

Relevante Verstöße abfragen

Mit diesen Strategien können Sie die relevanten Verstöße erkennen:

  • Fügen Sie einen Zeitstempel-Qualifier für das Zeitfenster hinzu, wenn jede eindeutige Anwendung ihren Anwendungsfall ausgeführt hat:

    WHERE receiveTimestamp >'2020-07-23 19:53:48.241317 UTC'

  • Fügen Sie einen Filter für die Namenskonvention von Arbeitslastidentitäten oder Projekten hinzu:

    WHERE where resource.labels.project_id like '%APPLICATION_NAME%'

Logs zu Verstößen prüfen

Stellen Sie bei der Prüfung der Logs für Verstöße fest, ob Folgendes zutrifft:

  • Wird die Identität (E-Mail) die geschützten APIs voraussichtlich aufrufen?
  • Sollte der Aufrufer die API von außerhalb des Perimeters aufrufen können?

Bestimmen Sie anhand der vorherigen Kriterien, ob Sie der Identität, dem Gerät, der IP-Adresse, dem CIDR-Bereich, dem Projekt oder dem Netzwerk den Zugriff auf den Perimeter von außerhalb gestatten müssen.

Einige Einträge haben möglicherweise die IP-Adresse private. Dies bedeutet, dass der Aufruf aus dem Google-Netzwerk stammt, entweder von Google-Diensten oder von einer VPC in einem Projekt außerhalb des Perimeters. Für Google-Dienste wie Autoren von Logsenken müssen Sie das Google-Dienstkonto einer Zulassungsliste hinzufügen.

Einträge ohne E-Mail-Adressen entstehen durch das Entfernen von Cloud-Audit-Logs für schreibgeschützte Vorgänge, die aufgrund fehlender IAM-Berechtigungen abgelehnt wurden. In solchen Fällen können Sie anhand der IP-Adresse und Ressourcennamen den Ursprung des Zugriffsversuchs nachvollziehen. Diese Art von Zugriffsversuch kann ein versehentlicher Zugriff von einem Nutzer außerhalb Ihrer Organisation sein. Beispiel: Nutzer, der einen ähnlich benannten Bucket falsch schreibt

Wenn Sie den Verstoßtyp SERVICE_NOT_ALLOWED_FROM_VPC sehen, ist die Arbeitslast einen Dienst verwenden, der von VPC Service Controls unterstützt wird, der Liste der geschützten APIs hinzugefügt. Wenn beispielsweise IAM einen solchen Verstoß verursacht hat, sollte der Administrator IAM der Liste der zugänglichen Dienste hinzufügen. Führen Sie dazu den folgenden Google Cloud CLI-Befehl aus:

gcloud access-context-manager perimeters update perimeter_test \
 --add-vpc-allowed-services=RESTRICTED-SERVICES,IAM.googleapis.com \
 --policy=1234567890

Sie können ein Looker Studio-Dashboard erstellen, um Verstöße zu prüfen. Weitere Informationen finden Sie unter VPC Service Controls-Verstöße in Ihrer Google Cloud-Organisation mit Looker Studio beobachten. Looker Studio hieß früher Data Studio.

Nächste Schritte