Security Command Center-Latenz – Übersicht

Diese Seite bietet einen Überblick über den Aktivierungsprozess, der beim Aktivieren von Security Command Center erfolgt. Das Ziel besteht darin, häufig gestellte Fragen zu beantworten:

  • Was passiert, wenn Security Command Center aktiviert ist?
  • Warum gibt es vor dem Start der ersten Scans eine Verzögerung?
  • Was ist die erwartete Laufzeit für die ersten Scans und die laufenden Scans?
  • Wie wirken sich Änderungen an Ressourcen und Einstellungen auf die Leistung aus?

Überblick

Wenn Sie Security Command Center zum ersten Mal aktivieren, muss ein Aktivierungsprozess abgeschlossen sein, bevor Security Command Center mit dem Scannen Ihrer Ressourcen beginnen kann. Anschließend müssen die Scans abgeschlossen sein, bevor Sie die vollständigen Ergebnisse für Ihre Google Cloud-Umgebung sehen.

Wie lange der Aktivierungsprozess und die Scans dauern, hängt von einer Reihe von Faktoren ab, z. B. von der Anzahl der Assets und Ressourcen in Ihrer Umgebung und davon, ob Security Command Center auf Organisationsebene oder Projektebene aktiviert ist.

Bei Aktivierungen auf Organisationsebene muss Security Command Center bestimmte Schritte des Aktivierungsprozesses für jedes Projekt in der Organisation wiederholen. Je nach Anzahl der Projekte in einer Organisation kann die für den Aktivierungsprozess erforderliche Zeit von Minuten bis Stunden reichen. Bei Organisationen mit mehr als 100.000 Projekten, vielen Ressourcen in jedem Projekt und anderen komplizierten Faktoren können Aktivierungs- und erste Scans bis zu 24 Stunden oder länger dauern.

Bei Aktivierungen von Security Command Center auf Projektebene erfolgt die Aktivierung viel schneller, da der Prozess auf das einzelne Projekt beschränkt ist, in dem Security Command Center aktiviert ist.

Die Faktoren, die Latenz beim Starten von Scans, der Verarbeitung von Änderungen an den Einstellungen und der Laufzeit von Scans verursachen können, werden in den folgenden Abschnitten erläutert.

Topologie

Die folgende Abbildung zeigt eine allgemeine Abbildung des Einrichtungs- und Aktivierungsvorgangs.

Abbildung: Einrichtung von Security Command Center (zum Vergrößern klicken)
Abbildung des Security Command Center-Onboardings (zum Vergrößern klicken)

Latenz bei der Einrichtung

Vor dem Start des Scans werden Ihre Ressourcen von Security Command Center erkannt und indexiert.

Zu den indexierten Diensten gehören App Engine, BigQuery, Cloud SQL, Cloud Storage, Compute Engine, Identity and Access Management und Google Kubernetes Engine.

Bei Aktivierungen von Security Command Center auf Projektebene ist die Erkennung und Indexierung auf das einzelne Projekt beschränkt, in dem Security Command Center aktiviert ist.

Bei Aktivierungen auf Organisationsebene erkennt und indexiert Security Command Center Ressourcen in Ihrer Organisation.

Während des Onboarding-Vorgangs werden zwei wichtige Schritte ausgeführt.

Asset-Scan

Security Command Center führt einen ersten Asset-Scan durch, um die Gesamtzahl, den Standort und den Zustand von Projekten, Ordnern, Dateien, Clustern, Identitäten, Zugriffsrichtlinien, registrierten Nutzern und anderen Ressourcen zu ermitteln. Dieser Vorgang ist normalerweise innerhalb von Minuten abgeschlossen.

API-Aktivierung

Wenn Ressourcen gefunden werden, aktiviert Security Command Center Elemente von Google Cloud, die für Security Health Analytics, Event Threat Detection, Container Threat Detection und Web Security Scanner benötigt werden. Bei einigen Erkennungsdiensten müssen bestimmte APIs für geschützte Projekte aktiviert sein, damit sie funktionieren.

Wenn Sie Security Command Center auf Projektebene aktivieren, dauert die API-Aktivierung in der Regel weniger als eine Minute.

Bei Aktivierungen auf Organisationsebene durchläuft Security Command Center alle Projekte, die Sie für das Scannen auswählen, um die erforderlichen APIs zu aktivieren.

Die Anzahl der Projekte in einer Organisation legt weitgehend die Länge der Onboarding- und Aktivierungsprozesse fest. Da APIs für Projekte einzeln aktiviert werden müssen, ist die API-Aktivierung für gewöhnlich die zeitaufwendigste Aufgabe, insbesondere für Unternehmen mit mehr als 100.000 Projekten.

Die erforderliche Zeit zum projektübergreifende Aktivieren von Diensten skaliert linear. Das bedeutet, dass es in der Regel doppelt so lang dauert, Dienst- und Sicherheitseinstellungen in einer Organisation mit 30.000 Projekten zu aktivieren, als eines mit 15.000 Projekten.

Bei einer Organisation mit 100.000 Projekten sollte das Onboarding und die Aktivierung der Premium-Stufe in weniger als fünf Stunden abgeschlossen sein. Wie viel Zeit Sie genau benötigen, hängt von vielen Faktoren ab, z. B. von der Anzahl der verwendeten Projekte oder Container und der Anzahl der Security Command Center-Dienste, die Sie aktivieren.

Scanlatenz

Bei der Einrichtung von Security Command Center entscheiden Sie, welche integrierten Dienste aktiviert werden sollen. Anschließend wählen Sie die Google Cloud-Ressourcen aus, die Sie analysieren oder scannen möchten, um Bedrohungen und Sicherheitslücken zu ermitteln. Wenn APIs für Projekte aktiviert sind, starten ausgewählte Dienste ihre Scans. Die Dauer dieser Scans hängt auch von der Anzahl der Projekte in einer Organisation ab.

Ergebnisse von integrierten Diensten sind verfügbar, wenn die ersten Scans abgeschlossen wurden. Dabei kann es bei jedem Dienst zu Latenzen kommen, wie unten beschrieben.

  • Container Threat Detection hat folgende Latenzen:
    • Aktivierungslatenz von bis zu 3,5 Stunden für neu aufgenommene Projekte oder Organisationen.
    • Aktivierungslatenz von Minuten für neu erstellte Cluster.
    • Erkennungslatenz weniger Minuten für Bedrohungen in Clustern, die aktiviert wurden.

  • Die Aktivierung von Event Threat Detection erfolgt bei integrierten Detektoren innerhalb von Sekunden. Bei neuen oder aktualisierten benutzerdefinierten Detektoren kann es bis zu 15 Minuten dauern, bis die Änderungen wirksam werden. In der Praxis dauert dies in der Regel weniger als 5 Minuten.

    Bei integrierten und benutzerdefinierten Detektoren betragen die Erkennungslatenzen in der Regel weniger als 15 Minuten ab dem Zeitpunkt, an dem ein Log geschrieben wird, bis zu dem Zeitpunkt, an dem ein Ergebnis in Security Command Center verfügbar ist.

  • Rapid Vulnerability Detection beginnt innerhalb von 24 Stunden nach seiner Aktivierung für das Projekt mit dem Scannen eines Projekts und gibt Ergebnisse zurück.

  • Security Health Analytics-Scans starten ca. eine Stunde nach der Aktivierung des Dienstes. Die ersten Security Health Analytics-Scans können bis zu 12 Stunden dauern. Danach werden die meisten Erkennungen in Echtzeit gegen Änderungen der Asset-Konfiguration ausgeführt (Ausnahmen finden Sie unter Security Health Analytics-Erkennungslatenz).

  • VM Threat Detection hat eine Aktivierungslatenz von bis zu 48 Stunden bei neu eingerichteten Organisationen. Bei Projekten beträgt die Aktivierungslatenz bis zu 15 Minuten.

  • Nach dem Aktivieren des Dienstes kann es bis zu 24 Stunden dauern, bis Web Security Scanner gestartet wird. Nach dem ersten Scan wird er dann jede Woche ausgeführt.

Security Command Center führt Fehlerdetektoren aus, die Konfigurationsfehler im Zusammenhang mit Security Command Center und seinen Diensten erkennen. Diese Fehlerdetektoren sind standardmäßig aktiviert und können nicht deaktiviert werden. Die Erkennungslatenzen variieren je nach Fehlerdetektor. Weitere Informationen finden Sie unter Security Command Center-Fehler.

Die IAM-Rollen für Security Command Center können auf Organisations-, Ordner- oder Projektebene gewährt werden. Die Möglichkeit, Ergebnisse, Assets und Sicherheitsquellen anzusehen, zu bearbeiten, zu erstellen oder zu aktualisieren, hängt von der Ebene ab, auf die Ihnen Zugriff gewährt wurde. Weitere Informationen zu Security Command Center-Rollen finden Sie unter Zugriffssteuerung.

Vorläufige Ergebnisse

Während der ersten Scans, aber vor Abschluss des Onboarding-Prozesses werden möglicherweise einige Ergebnisse in der Google Cloud Console angezeigt.

Vorläufige Ergebnisse sind präzise und praktisch, aber sie sind nicht aussagekräftig. Die Verwendung dieser Ergebnisse für eine Complianceprüfung innerhalb der ersten 24 Stunden wird nicht empfohlen.

Nachfolgende Scans

Änderungen, die in Ihrer Organisation oder Ihrem Projekt vorgenommen werden, z. B. das Verschieben von Ressourcen oder das Hinzufügen neuer Ordner und Projekte auf Organisationsebene, wirken sich in der Regel nicht wesentlich auf die Ressourcenerkennungszeit oder die Laufzeit von Scans aus. Einige Scans gehen jedoch nach festgelegten Zeitplänen aus, die festlegen, wie schnell die Security Command Center Änderungen erkennt.

  • Event Threat Detection und Container Threat Detection: Diese Dienste werden in Echtzeit ausgeführt, wenn sie aktiviert sind, und erkennen sofort neue oder geänderte Ressourcen wie Cluster, Buckets oder Logs in aktivierten Projekten.
  • Rapid Vulnerability Detection führt ab dem Datum des ersten Scans wöchentlich weitere Scans durch. Wenn Projekten zwischen Scans neue Ressourcen hinzugefügt werden, werden Sicherheitslücken erst beim nächsten Scan erkannt.
  • Security Health Analytics: Security Health Analytics wird bei Aktivierung in Echtzeit ausgeführt und erkennt neue oder geänderte Ressourcen innerhalb von Minuten, mit Ausnahme der unten aufgeführten Erkennungen.
  • VM Threat Detection: Zum Scannen des Arbeitsspeichers scannt VM Threat Detection jede VM-Instanz sofort nach ihrer Erstellung. Darüber hinaus scannt VM Threat Detection alle VM-Instanzen alle 30 Minuten.
    • Zur Erkennung von Krypto-Mining generiert VM Threat Detection ein Ergebnis pro Prozess, VM und Tag. Jedes Ergebnis enthält nur die Bedrohungen, die mit dem Prozess verbunden sind, der durch das Ergebnis identifiziert wird. Wenn VM Threat Detection Bedrohungen findet, sie jedoch keinem Prozess zuordnen kann, fasst VM Threat Detection für jede VM alle nicht zugehörigen Bedrohungen in einem einzigen Ergebnis zusammen, das jeweils einmal innerhalb eines Zeitraums von 24 Stunden ausgeführt wird. Bei Bedrohungen, die länger als 24 Stunden andauern, generiert die VM Threat Detection alle 24 Stunden neue Ergebnisse.
    • Für die Rootkit-Erkennung im Kernelmodus, die sich in der Vorabversion befindet, generiert VM Threat Detection alle drei Tage ein Ergebnis pro Kategorie, pro VM.

    Zum Scannen nichtflüchtiger Speicher, mit dem bekannte Malware erkannt wird, scannt VM Threat Detection jede VM-Instanz mindestens einmal täglich.

  • Web Security Scanner: Web Security Scanner wird wöchentlich am selben Tag wie der erste Scanvorgang ausgeführt. Da Web Security Scanner wöchentlich ausgeführt wird, erkennt er Änderungen nicht in Echtzeit. Wenn Sie eine Ressource verschieben oder eine Anwendung ändern, wird die Änderung möglicherweise erst nach einer Woche erkannt. Sie können On-Demand-Scans ausführen, um neue oder geänderte Ressourcen zwischen geplanten Scans zu prüfen.

Security Command Center-Fehlerdetektoren werden regelmäßig im Batchmodus ausgeführt. Die Häufigkeit des Batchscans hängt vom Fehlerdetektor ab. Weitere Informationen finden Sie unter Security Command Center-Fehler.

Security Health Analytics-Erkennungslatenz

Erkennungen von Security Health Analytics werden regelmäßig im Batchmodus ausgeführt, nachdem der Dienst aktiviert wurde sowie wenn sich die Konfiguration eines zugehörigen Assets ändert. Sobald Security Health Analytics aktiviert ist, führen alle relevanten Änderungen an der Ressourcenkonfiguration zu aktualisierten Fehlkonfigurationsergebnissen. In einigen Fällen kann die Aktualisierung je nach Asset-Typ und Änderung einige Minuten dauern.

Einige Detektoren von Security Health Analytics unterstützen den unmittelbaren Scanmodus nicht, wenn beispielsweise eine Erkennung außerhalb der Konfiguration einer Ressource ausgeführt wird. Diese in der folgenden Tabelle aufgeführten Detektoren werden regelmäßig ausgeführt und können Fehlkonfigurationen innerhalb von 12 Stunden ermitteln. Weitere Informationen zu Detektoren von Security Health Analytics finden Sie unter Sicherheitslücken und Ergebnisse.

Erkennungen von Security Health Analytics, die den Echtzeitscan-Modus nicht unterstützen
COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED
MFA_NOT_ENFORCED (zuvor als 2SV_NOT_ENFORCED bezeichnet)
OS_LOGIN_DISABLED
SQL_NO_ROOT_PASSWORD
SQL_WEAK_ROOT_PASSWORD

Angriffspfadsimulationen

Angriffspfadsimulationen werden etwa alle sechs Stunden ausgeführt. Wenn Ihre Google Cloud-Organisation größer oder komplexer wird, können auch die Zeit zwischen den Intervallen länger werden.

Wenn Sie Security Command Center zum ersten Mal aktivieren, wird für die Simulationen des Angriffspfads ein Standardsatz hochwertiger Ressourcen verwendet, der alle unterstützten Ressourcentypen in Ihrer Organisation enthält.

Wenn Sie damit beginnen, Ihren eigenen Satz hochwertiger Ressourcen durch Erstellen einer Ressourcenwertkonfiguration zu definieren, werden Sie möglicherweise feststellen, dass die Zeit zwischen den Simulationsintervallen kürzer ist, wenn die Anzahl der Ressourceninstanzen in Ihrem Satz hochwertiger Ressourcen deutlich kleiner als der Standardsatz ist.

Nächste Schritte