Logs in ein SIEM-System exportieren

Auf dieser Seite wird beschrieben, wie Sie Logs aus Google Distributed Cloud (GDC) mit Air Gap in ein externes SIEM-System (Security Information and Event Management) exportieren. Diese Integration ermöglicht eine zentralisierte Loganalyse und eine verbesserte Sicherheitsüberwachung.

Der Kern des Logexports besteht in der Bereitstellung einer benutzerdefinierten SIEMOrgForwarder-Ressource. Diese Ressource fungiert als Konfigurationsdatei, in der die Details der externen SIEM-Instanz angegeben werden, die die Logs empfangen soll. Durch das Definieren dieser Parameter in der SIEMOrgForwarder-Datei können Administratoren eine optimierte und sichere Pipeline für den Logexport einrichten.

Hinweis

Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen eine der zugehörigen SIEM-Exportrollen für die Organisation zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verwalten benutzerdefinierter SIEMOrgForwarder-Ressourcen benötigen.

Je nach Zugriffsebene und erforderlichen Berechtigungen können Sie in Ihrem Projekt-Namespace Rollen als Ersteller, Editor oder Betrachter für diese Ressource erhalten. Weitere Informationen finden Sie unter IAM-Berechtigungen vorbereiten.

Nachdem Sie die erforderlichen Berechtigungen erhalten haben, führen Sie die folgenden Schritte aus, bevor Sie Logs in ein externes SIEM-System exportieren:

  1. Verbindung herstellen: Stellen Sie eine Verbindung zwischen GDC und dem externen SIEM-Ziel her. Arbeiten Sie bei Bedarf mit dem Infrastrukturbetreiber zusammen, um eine Uplink-Verbindung zu Ihrem Kundennetzwerk herzustellen.

  2. Umgebungsvariablen festlegen: Legen Sie die folgenden Umgebungsvariablen fest, um die Befehle auf dieser Seite auszuführen:

    • Der Pfad der kubeconfig-Datei:

      export KUBECONFIG=KUBECONFIG_PATH

      Ersetzen Sie KUBECONFIG_PATH durch den Pfad zur kubeconfig-Datei für den Management API-Server.

    • Ihr Projekt-Namespace:

      export PROJECT_NAMESPACE=PROJECT_NAMESPACE

Logexport konfigurieren

So exportieren Sie Logs in ein externes SIEM-System:

  1. Geben Sie ein Token an, um den Logging-Stack mit dem SIEM-System zu verbinden. Dazu müssen Sie ein Secret in Ihrem Projekt-Namespace erstellen, um das Token im Fall von Splunk und das Passwort im Fall von Elastic SIEM zu speichern:

    cat <<EOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: SECRET_NAME
  namespace: ${PROJECT_NAMESPACE}
type: Opaque
stringData:
  SECRET_FIELD: FIELD_VALUE
EOF

    Ersetzen Sie Folgendes:

    • SECRET_NAME: der Name Ihres Secrets.
    • SECRET_FIELD: der Name des Felds, in dem Sie das Secret speichern möchten. Im Fall von Elastic ist das der Nutzername.
    • FIELD_VALUE: ist das Token im Fall von Splunk und das Passwort im Fall von Elastic.
    • TOKEN: Ihr Token.

  2. Stellen Sie die benutzerdefinierte SIEMOrgForwarder-Ressource in Ihrem Projekt-Namespace bereit. Sie müssen den Logtyp angeben, indem Sie zwischen Audit- und Betriebslogs wählen. Wenn Sie den Logexport für beide Logtypen konfigurieren möchten, müssen Sie für jeden Typ eine SIEMOrgForwarder-Ressource bereitstellen.

    Das folgende Beispiel zeigt, wie Sie eine Konfiguration auf eine benutzerdefinierte SIEMOrgForwarder-Ressource für Splunk anwenden:

      cat <<EOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -
  apiVersion: logging.gdc.goog/v1
  kind: SIEMOrgForwarder
  metadata:
    name: SIEM_ORG_FORWARDER
    namespace: ${PROJECT_NAMESPACE}
  spec:
    source: LOG_TYPE
    destinations:
      splunkOutputs:
        - host: SIEM_HOST
          token:
            name: SECRET_NAME
            field: SECRET_FIELD
          tls: "TLS"
          netConnectTimeout: NET_CONNECT_TIMEOUT
  EOF

    Ersetzen Sie Folgendes:

    • SIEM_ORG_FORWARDER: der Name der SIEMOrgForwarder-Definitionsdatei.
    • LOG_TYPE: der Logtyp, den Sie exportieren. Zulässige Werte sind audit und operational.
    • SIEM_HOST: der Name des SIEM-Hosts.
    • SECRET_NAME: der Name Ihres Secrets.
    • SECRET_FIELD: der Name des Felds, in dem Sie das Secret gespeichert haben.
    • TLS: der Status von Transport Layer Security (TLS). Zulässige Werte sind "On" und "Off".
    • NET_CONNECT_TIMEOUT: die maximale Zeit in Sekunden, die gewartet werden soll, bis eine Verbindung hergestellt wird. Ein Wert von 180 bedeutet beispielsweise, dass 180 Sekunden gewartet werden soll.

    Das folgende Beispiel zeigt, wie Sie eine Konfiguration auf eine benutzerdefinierte SIEMOrgForwarder-Ressource für Elastic anwenden:

      cat <<EOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -
  apiVersion: logging.gdc.goog/v1
  kind: SIEMOrgForwarder
  metadata:
    name: SIEM_ORG_FORWARDER
    namespace: ${PROJECT_NAMESPACE}
  spec:
    source: LOG_TYPE
    destinations:
      elasticOutputs:
        - host: SIEM_HOST
          port: SIEM_PORT
          http_credential:
            http_user: HTTP_USER_NAME
            http_passwd: SECRET_NAME
          tls: "TLS"
          netConnectTimeout: NET_CONNECT_TIMEOUT
          index: INDEX
  EOF

    Ersetzen Sie Folgendes:

    • SIEM_ORG_FORWARDER: der Name der SIEMOrgForwarder-Definitionsdatei.
    • LOG_TYPE: der Logtyp, den Sie exportieren. Zulässige Werte sind audit und operational.
    • SIEM_HOST: der Name des SIEM-Hosts.
    • SIEM_PORT: der Port der SIEM-Instanz.
    • HTTP_USER_NAME: der Nutzername der SIEM-Instanz.
    • SECRET_NAME: der Name Ihres Secrets.
    • TLS: der Status von Transport Layer Security (TLS). Zulässige Werte sind "On" und "Off".
    • NET_CONNECT_TIMEOUT: die maximale Zeit in Sekunden, die gewartet werden soll, bis eine Verbindung hergestellt wird. Ein Wert von 180 bedeutet beispielsweise, dass 180 Sekunden gewartet werden soll.
    • INDEX: der Index für die Elastic-Instanz. Wenn nicht angegeben, wird der Logtyp (audit oder operational) verwendet. Dieses Feld ist optional.

  3. Prüfen Sie den Status der bereitgestellten benutzerdefinierten SIEMOrgForwarder-Ressource:

      kubectl --kubeconfig=${KUBECONFIG} describe siemorgforwarder/SIEM_ORG_FORWARDER \
      -n ${PROJECT_NAMESPACE}

    Prüfen Sie je nach Logtyp den folgenden Status:

    • Audit-Logs: Prüfen Sie den AuditLoggingReady Status.

    • Betriebslogs: Prüfen Sie den OperationalLoggingReady Status.