Best Practices zum Aktivieren von VPC Service Controls

In diesem Dokument wird das empfohlene Verfahren zum Konfigurieren und Erzwingen des VPC Service Controls-Schutzes in Ihrer Google Cloud-Organisation beschrieben.

Das unvorsichtige Aktivieren von VPC Service Controls kann Probleme mit vorhandenen Anwendungen und möglicherweise zu einem Ausfall führen. Wir empfehlen, die Aktivierung sorgfältig zu planen und ausreichend Zeit für das Erfassen von Daten, das Durchführen von Tests und das Analysieren von Verstoßlogs einzuräumen. Sorgen Sie dafür, dass alle Beteiligten aus Ihrem VPC Service Controls-Betriebsteam und Ihrem Anwendungsteam für diese Aufgabe verfügbar sind.

Wiederholen Sie den Aktivierungsvorgang für jede Arbeitslast oder Anwendung, die Sie für VPC Service Controls einrichten.

Kommunikation koordinieren

Häufig leitet das Team für die Netzwerksicherheit oder die Cloud-Aktivierung die Aktivierung von VPC Service Controls. Wir empfehlen, eine engagierte Person damit beauftragen, funktionsübergreifende Besprechungen zu erstellen und zu verfolgen und Maßnahmen zu dokumentieren. Ihre Teams arbeiten bei Folgendem zusammen:

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

Ähnlich wie bei herkömmlichen Netzwerk-Firewalls besteht der Zweck darin, die für das effiziente Funktionieren legitimer Geschäftsarbeitslasten erforderlichen Datenflüsse zu identifizieren und zuzulassen.

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:

  • Datenzugriffsmuster: Dienste außerhalb des Perimeters speichern oder rufen Daten im Perimeter 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, Arbeitslasten mit der höchsten Priorität nur bei der erstmaligen Aktivierung zu berücksichtigen und andere, weniger kritische Arbeitslasten nach dem Schutz geschäftskritischer Ressourcen einzubinden.

  • 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

Der Probelaufmodus reduziert die Komplexität des Testens der Erzwingung von VPC Service Controls, da Verstöße ohne Unterbrechung der Anwendungen erkannt werden. 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. Erstellen Sie einen Probelauf-Perimeter 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 Sie eine zusammengefasste Logging-Senke, die alle Logs an BigQuery sendet, oder eine Logsenke für jedes Projekt, das die Probelauflogs an ein gemeinsames BigQuery-Dataset sendet. Mit einer SQL-Abfrage können Sie diese Logeinträge abfragen und VPC Service Controls-Verstöße identifizieren.

    Verwenden Sie den folgenden Filter, um eine Logsenke zu erstellen, die alle relevanten VPC Service Controls-Lognachrichten enthält:

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

  5. Aus Sicherheitsgründen sollten Sie den Zugriff auf nicht unterstützte Dienste nicht zulassen. Konfigurieren Sie den Perimeter so, dass nur eingeschränkte Dienste im Perimeter 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 diese je nach Anwendungsfall im Probelaufperimeter einer Regel für eingehenden Traffic oder einer Zugriffsebene hinzu. Das Zulassen bekannter legitimer Abläufe trägt dazu bei, die Anzahl der Verstoßlogs zu reduzieren und ermöglicht es den Prüfern, sich auf umsetzbare Ereignisse zu 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 kann das zuständige Team die Verstoß-Log-Analyse durchführen.

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?

Ermitteln Sie anhand der vorherigen Kriterien, ob die Identität, das Gerät, die IP-Adresse, der CIDR-Bereich, das Projekt oder das Netzwerk von außerhalb auf den Perimeter zugreifen darf.

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. Bei einem solchen Zugriffsversuch kann es sich um einen versehentlichen Zugriff durch einen Nutzer außerhalb Ihrer Organisation handeln. Beispiel: Ein Nutzer, der sich bei einem Bucket mit ähnlichem Namen vertippt.

Wenn Sie den Verstoßtyp SERVICE_NOT_ALLOWED_FROM_VPC sehen, verwendet die Arbeitslast möglicherweise einen Dienst, der von VPC Service Controls unterstützt wird, aber nicht in die Liste der geschützten APIs aufgenommen wurde. Wenn beispielsweise IAM einen solchen Verstoß verursacht hat, sollte der Administrator IAM der Liste der zugänglichen Dienste hinzufügen, indem er den folgenden Google Cloud CLI-Befehl ausführt:

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 Verstöße gegen VPC Service Controls in Ihrer Google Cloud-Organisation mit Looker Studio beobachten. Looker Studio hieß bisher Data Studio.

Nächste Schritte