GitGuardian Enterprise-Logs erfassen
Parserversion: 1.0
In diesem Dokument wird beschrieben, wie Sie GitGuardian Enterprise so konfigurieren, dass Logs über Webhooks an Google Security Operations gesendet werden.
GitGuardian Enterprise ist eine Plattform zur Erkennung und Behebung von vertraulichen Informationen, die Quellcode-Repositories, CI/CD-Pipelines und Entwickler-Workstations auf offengelegte Anmeldedaten und vertrauliche Daten überwacht. Sie erhalten Echtzeitbenachrichtigungen, wenn Secrets erkannt werden, und Sicherheitsteams können Workflows zur Behebung von Vorfällen verwalten.
Hinweis
Prüfen Sie, ob folgende Voraussetzungen erfüllt sind:
- Eine Google SecOps-Instanz
- GitGuardian Enterprise-Arbeitsbereich mit Zugriffsebene „Manager“
- Zugriff auf die Google Cloud Console (zum Erstellen von API-Schlüsseln)
- GitGuardian-Abo „Business“ oder höher (für die Unterstützung benutzerdefinierter Webhooks)
Webhook-Feed in Google SecOps erstellen
Feed erstellen
- Rufen Sie die SIEM-Einstellungen > Feeds auf.
- Klicken Sie auf Neuen Feed hinzufügen.
- Klicken Sie auf der nächsten Seite auf Einen einzelnen Feed konfigurieren.
- Geben Sie im Feld Feedname einen Namen für den Feed ein, z. B.
GitGuardian Enterprise Incidents. - Wählen Sie Webhook als Quelltyp aus.
- Wählen Sie GitGuardian Enterprise als Log type (Protokolltyp) aus.
- Klicken Sie auf Weiter.
Geben Sie Werte für die folgenden Eingabeparameter an:
- Trennzeichen für Aufteilung (optional): Feld leer lassen (jede Webhook-Anfrage enthält ein einzelnes Ereignis)
- Asset-Namespace: Der Asset-Namespace
- Labels für Datenaufnahme: Das Label, das auf die Ereignisse aus diesem Feed angewendet werden soll
Klicken Sie auf Weiter.
Prüfen Sie die neue Feedkonfiguration auf dem Bildschirm Abschließen und klicken Sie dann auf Senden.
Secret-Schlüssel generieren und speichern
Nachdem Sie den Feed erstellt haben, müssen Sie einen Secret-Schlüssel für die Authentifizierung generieren:
- Klicken Sie auf der Feed-Detailseite auf Geheimen Schlüssel generieren.
- Ein Dialogfeld mit dem geheimen Schlüssel wird angezeigt.
Kopieren und speichern Sie den geheimen Schlüssel an einem sicheren Ort.
Feed-Endpunkt-URL abrufen
- Rufen Sie den Tab Details des Feeds auf.
- Kopieren Sie im Bereich Endpunktinformationen die Feed-Endpunkt-URL.
Das URL-Format lautet:
https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreateoder
https://<REGION>-malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreateSpeichern Sie diese URL für die nächsten Schritte.
Klicken Sie auf Fertig.
Google Cloud API-Schlüssel erstellen
Für Google SecOps ist ein API-Schlüssel für die Authentifizierung erforderlich. Erstellen Sie einen eingeschränkten API-Schlüssel in der Google Cloud Console.
API-Schlüssel erstellen
- Rufen Sie die Seite „Anmeldedaten“ in der Google Cloud Console auf.
- Wählen Sie Ihr Projekt aus (das Projekt, das mit Ihrer Google SecOps-Instanz verknüpft ist).
- Klicken Sie auf Anmeldedaten erstellen > API-Schlüssel.
- Ein API-Schlüssel wird erstellt und in einem Dialogfeld angezeigt.
- Klicken Sie auf API-Schlüssel bearbeiten, um den Schlüssel einzuschränken.
API-Schlüssel einschränken
Auf der Seite mit den Einstellungen für API-Schlüssel:
- Name: Geben Sie einen aussagekräftigen Namen ein, z. B.
Google SecOps GitGuardian Webhook API Key.
- Name: Geben Sie einen aussagekräftigen Namen ein, z. B.
Gehen Sie unter API-Einschränkungen so vor:
- Wählen Sie Schlüssel einschränken aus.
- Suchen Sie im Drop-down-Menü APIs auswählen nach Google SecOps API (oder Chronicle API) und wählen Sie die API aus.
Klicken Sie auf Speichern.
Kopieren Sie den API-Schlüsselwert aus dem Feld API-Schlüssel oben auf der Seite.
Speichern Sie den API-Schlüssel sicher.
GitGuardian Enterprise-Webhook konfigurieren
Webhook-URL erstellen
Kombinieren Sie die Google SecOps-Endpunkt-URL und den API-Schlüssel:
<ENDPOINT_URL>?key=<API_KEY>Beispiel:
https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=AIzaSyD...
Benutzerdefinierten Webhook in GitGuardian erstellen
Für den persönlichen Arbeitsbereich:
- Melden Sie sich im GitGuardian-Dashboard an.
- Gehen Sie zu Einstellungen> „Workspace“ > „Integrationen“ > „Ziele“ > „Benutzerdefinierter Webhook“.
- Klicken Sie auf Benutzerdefinierten Webhook hinzufügen oder Neuen benutzerdefinierten Webhook erstellen.
Geben Sie die folgenden Konfigurationsdetails an:
- Name: Geben Sie einen aussagekräftigen Namen ein, z. B.
Google SecOps SIEM Integration. - URL: Fügen Sie die vollständige Endpunkt-URL mit API-Schlüssel von oben ein.
- Signaturtoken: Fügen Sie den geheimen Schlüssel aus der Google SecOps-Feederstellung ein.
- Benutzerdefinierter Header (optional): Lassen Sie dieses Feld leer, es sei denn, Sie müssen Umgebungs- oder Dienst-Tags angeben.
- Name: Geben Sie einen aussagekräftigen Namen ein, z. B.
Wählen Sie im Bereich Event Subscription (Ereignisabo) die Ereignisse aus, die Sie an Google SecOps senden möchten:
- Vorfälle:
- ☑ Neuer Vorfall erkannt
- ☑ Neues Vorkommen erkannt
- ☑ Vorfall behoben
- ☑ Vorfall ignoriert
- ☑ Vorfall wieder geöffnet
- ☑ Regression von Vorfällen
- ☑ Vorfall zugewiesen
- ☑ Vorfall neu zugewiesen
- ☑ Zuweisung des Vorfalls aufgehoben
- ☑ Schweregrad des Vorfalls geändert
- ☑ Gültigkeit des Vorfalls geändert
- ☑ Zugriff auf Vorfall gewährt
- ☑ Zugriff auf Vorfall entzogen
- ☑ Vorfall öffentlich geteilt
- ☑ Vorfall wurde nicht öffentlich geteilt
- ☑ Feedback gesendet
- ☑ Neuer Kommentar zu einem Vorfall
- Vorfälle:
Klicken Sie auf Erstellen oder Speichern.
GitGuardian sendet eine Testnachricht, um zu prüfen, ob der Webhook funktioniert.
Für Arbeitsbereiche für Unternehmen:
- Melden Sie sich im GitGuardian-Dashboard an.
Legen Sie den Umfang für Ihren Webhook fest:
- Alle Vorfälle im Arbeitsbereich: Rufen Sie das Team „Alle Vorfälle“ auf.
- Bestimmte Teamvorfälle: Rufen Sie das gewünschte Team auf.
Gehen Sie zu Einstellungen> „Workspace“ > „Integrationen“ > „Ziele“ > „Benutzerdefinierter Webhook“.
- Alternativ können Sie auf der Teamseite zu Integrationen > Benutzerdefinierter Webhook wechseln.
Klicken Sie auf Benutzerdefinierten Webhook hinzufügen oder Neuen benutzerdefinierten Webhook erstellen.
Geben Sie die folgenden Konfigurationsdetails an:
- Name: Geben Sie einen aussagekräftigen Namen ein, z. B.
Google SecOps SIEM Integration. - URL: Fügen Sie die vollständige Endpunkt-URL mit API-Schlüssel von oben ein.
- Signaturtoken: Fügen Sie den geheimen Schlüssel aus der Google SecOps-Feederstellung ein.
- Benutzerdefinierter Header (optional): Lassen Sie dieses Feld leer, es sei denn, Sie müssen Umgebungs- oder Dienst-Tags angeben.
- Name: Geben Sie einen aussagekräftigen Namen ein, z. B.
Wählen Sie im Bereich Event Subscription (Ereignisabo) die Ereignisse aus, die Sie an Google SecOps senden möchten:
- Vorfälle:
- ☑ Neuer Vorfall erkannt
- ☑ Neues Vorkommen erkannt
- ☑ Vorfall behoben
- ☑ Vorfall ignoriert
- ☑ Vorfall wieder geöffnet
- ☑ Regression von Vorfällen
- ☑ Vorfall zugewiesen
- ☑ Vorfall neu zugewiesen
- ☑ Zuweisung des Vorfalls aufgehoben
- ☑ Schweregrad des Vorfalls geändert
- ☑ Gültigkeit des Vorfalls geändert
- ☑ Zugriff auf Vorfall gewährt
- ☑ Zugriff auf Vorfall entzogen
- ☑ Vorfall öffentlich geteilt
- ☑ Vorfall wurde nicht öffentlich geteilt
- ☑ Feedback gesendet
- ☑ Neuer Kommentar zu einem Vorfall
- Vorfälle:
Klicken Sie auf Erstellen oder Speichern.
GitGuardian sendet eine Testnachricht, um zu prüfen, ob der Webhook funktioniert.
Webhook-Zustellung überprüfen
- Rufen Sie im GitGuardian-Dashboard Ihre benutzerdefinierte Webhook-Konfiguration auf.
- Klicken Sie auf Testnachricht senden oder Webhook testen.
- GitGuardian sendet eine Beispielnutzlast an Google SecOps.
- Rufen Sie in der Google SecOps-Konsole die SIEM-Einstellungen > Feeds auf.
- Suchen Sie Ihren GitGuardian-Feed und prüfen Sie, ob das Testereignis empfangen wurde.
Prüfen Sie, ob der Feedstatus als Aktiv mit einem aktuellen Zeitstempel für die Aufnahme angezeigt wird.
Referenz zu Authentifizierungsmethoden
Google SecOps-Webhook-Feeds unterstützen mehrere Authentifizierungsmethoden. Wählen Sie die Methode aus, die von Ihrem Anbieter unterstützt wird.
Methode 1: Suchparameter (empfohlen für GitGuardian)
Benutzerdefinierte Webhooks von GitGuardian funktionieren am besten mit Anmeldedaten, die an die URL angehängt werden.
URL-Format:
<ENDPOINT_URL>?key=<API_KEY>Beispiel:
https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=AIzaSyD...GitGuardian-Webhook-Konfiguration:
- URL: Vollständige Endpunkt-URL mit API-Schlüsselparameter
- Signatur-Token: Geheimer Google SecOps-Schlüssel (für die HMAC-Bestätigung)
Anfrageformat:
POST <ENDPOINT_URL>?key=<API_KEY> HTTP/1.1 Content-Type: application/json Timestamp: 1234567890 Gitguardian-Signature: sha256=abc123... { "source": "GitGuardian", "timestamp": "2025-01-15T10:30:00Z", "action": "incident_triggered", "incident": {...} }
Methode 2: Benutzerdefinierte Header (Alternative)
Wenn Sie Anmeldedaten nicht in der URL angeben möchten, verwenden Sie benutzerdefinierte Header.
Anfrageformat:
POST <ENDPOINT_URL> HTTP/1.1 Content-Type: application/json x-goog-chronicle-auth: <API_KEY> Timestamp: 1234567890 Gitguardian-Signature: sha256=abc123... { "source": "GitGuardian", "timestamp": "2025-01-15T10:30:00Z", "action": "incident_triggered", "incident": {...} }
Überprüfung der GitGuardian-Webhook-Signatur
GitGuardian signiert alle Webhook-Nutzlasten mit HMAC-SHA256, um die Authentizität zu gewährleisten und Manipulationen zu verhindern.
Signatur-Header
GitGuardian fügt Webhook-Anfragen die folgenden Header hinzu:
- Gitguardian-Signatur: HMAC-SHA256-Signatur im Format
sha256=<hex_digest> - Zeitstempel: Unix-Zeitstempel, der angibt, wann die Anfrage gesendet wurde
- X-GitGuardian-Signature: Veralteter Header (wird weiterhin für die Abwärtskompatibilität unterstützt)
Signaturalgorithmus
Die Signatur wird so berechnet:
HMAC-SHA256(key=timestamp + signature_token, message=payload)Wobei:
- timestamp: Wert aus dem
Timestamp-Header - signature_token: Der geheime Schlüssel, der in den GitGuardian-Webhook-Einstellungen konfiguriert ist
- payload: Roh-JSON-Anfragetext als UTF-8-String
- timestamp: Wert aus dem
Beispiel für die Verifizierung (Python)
import hmac import hashlib def verify_signature(signature: str, timestamp: str, signature_token: str, payload: str) -> bool: if not signature.startswith("sha256="): return False signature = signature.split("sha256=")[-1] hmac_digest = hmac.new( key=bytes(timestamp + signature_token, "utf-8"), msg=bytes(payload, "utf-8"), digestmod=hashlib.sha256 ).hexdigest() return hmac.compare_digest(signature, hmac_digest)
Schutz vor Replay-Angriffen
Der
Timestamp-Header verhindert Replay-Angriffe. Wenn sich der aktuelle Zeitstempel um mehr als einige Sekunden (empfohlen: 300 Sekunden) vom Webhook-Zeitstempel unterscheidet, lehnen Sie die Anfrage ab.
Ereignistypen und Nutzlaststruktur
GitGuardian sendet verschiedene Ereignistypen basierend auf Änderungen im Lebenszyklus von Vorfällen.
Vorfallereignisse
| Ereignistyp | Aktionswert | Beschreibung |
|---|---|---|
| Neuer Vorfall erkannt | incident_triggered |
Ein neuer Secret-Vorfall wurde erkannt |
| Neues Vorkommen erkannt | new_occurrence |
Ein neues Auftreten eines vorhandenen Vorfalls wurde gefunden |
| Vorfall behoben | incident_resolved |
Der Vorfall wurde als behoben markiert. |
| Vorfall ignoriert | incident_ignored |
Der Vorfall wurde als ignoriert markiert |
| Vorfall wieder geöffnet | incident_reopened |
Ein zuvor geschlossener Vorfall wurde wieder geöffnet |
| Regression von Vorfällen | incident_regression |
Für diesen Vorfall wurde eine neue Regression gefunden |
| Vorfall zugewiesen | incident_assigned |
Der Vorfall wurde einem Nutzer zugewiesen |
| Vorfall neu zugewiesen | incident_reassigned |
Der Vorfall wurde einem anderen Nutzer zugewiesen. |
| Vorfall nicht zugewiesen | incident_unassigned |
Ein Nutzer wurde von diesem Vorfall entfernt |
| Schweregrad geändert | incident_severity_changed |
Der Schweregrad wurde aktualisiert |
| Gültigkeit geändert | incident_validity_changed |
Der Gültigkeitsstatus wurde aktualisiert |
| Zugriff gewährt | incident_access_granted |
Einem Nutzer wurde Zugriff auf diesen Vorfall gewährt |
| Zugriff entzogen | incident_access_revoked |
Der Zugriff auf diesen Vorfall wurde für einen Nutzer widerrufen |
| Öffentlich geteilt | incident_shared_publicly |
Ein Link für die öffentliche Freigabe wurde generiert |
| Nicht öffentlich freigegeben | incident_unshared_publicly |
Der Link für die öffentliche Freigabe wurde deaktiviert. |
| Feedback gesendet | issue_feedback_received |
Für diesen Vorfall wurde Feedback gesendet |
| Neuer Kommentar | incident_note_created |
Für diesen Vorfall wurde ein neuer Hinweis erstellt |
Beispiel für die Struktur der Nutzlast
Alle Webhook-Nutzlasten folgen dieser Struktur:
{ "source": "GitGuardian", "timestamp": "2025-01-15T10:30:00.123456Z", "action": "incident_triggered", "message": "A new incident has been detected.", "target_user": "john.doe@example.com", "target_team": "Security Team", "custom_webhook_name": "Google SecOps SIEM Integration", "incident": { "id": 12345, "date": "2025-01-15T10:29:58.123456Z", "detector": { "name": "aws_iam", "display_name": "AWS Keys", "nature": "specific", "family": "credentials" }, "secret_hash": "abc123...", "secret_revoked": false, "validity": "valid", "occurrence_count": 1, "status": "triggered", "assignee_email": null, "severity": "high", "gitguardian_url": "https://dashboard.gitguardian.com/workspace/1/incidents/12345" } }
Webhook-Limits und Best Practices
Anfragelimits
| Limit | Wert |
|---|---|
| Maximale Anfragengröße | 4 MB |
| Maximale Anzahl von Abfragen pro Sekunde | 15.000 |
| Zeitlimit für Anfragen | 30 Sekunden |
| Wiederholungsverhalten | Automatisch mit exponentiellem Backoff |
Best Practices
- Ereignisauswahl: Abonnieren Sie nur Ereignisse, die für Ihre Sicherheitsvorgänge relevant sind, um Rauschen zu reduzieren.
- Teambereich: In Arbeitsbereichen für Unternehmen können Sie Webhooks auf Teamebene erstellen, um Vorfälle nach Teameigentum zu filtern.
- Signaturüberprüfung: Speichern Sie das Signatur-Token sicher und übertragen Sie es niemals in den Quellcode.
- Monitoring: Prüfen Sie regelmäßig den Webhook-Zustellungsstatus im GitGuardian-Dashboard.
- Testen: Verwenden Sie die Funktion für Testnachrichten, um die Webhook-Konfiguration vor der Verwendung in der Produktion zu prüfen.
Übermittlungsgarantien
Wichtig: Die Webhook-Übermittlung erfolgt auf Best-Effort-Basis und ist nicht garantiert. Wenn Ihr Google SecOps-Endpunkt nicht erreichbar ist oder Netzwerkprobleme auftreten, werden Webhook-Ereignisse möglicherweise nicht empfangen. Webhooks sind zwar in der Regel zuverlässig, die Zustellung kann jedoch nicht garantiert werden.
Bei kritischen Anwendungsfällen sollten Sie Webhooks durch regelmäßiges API-Polling ergänzen, damit keine Vorfälle übersehen werden.
UDM-Zuordnungstabelle
| Logfeld | UDM-Zuordnung | Logik |
|---|---|---|
| date | metadata.event_timestamp | Konvertiert im ISO8601-Format |
| has_user | metadata.event_type | Wird auf „USER_UNCATEGORIZED“ gesetzt, wenn „has_user“ „true“ ist, andernfalls auf „GENERIC_EVENT“ |
| event_name | metadata.product_event_type | Wert direkt kopiert |
| id | metadata.product_log_id | Wert direkt kopiert |
| metadata.product_name | Auf „GitGuardian Enterprise“ festgelegt | |
| metadata.vendor_name | Legen Sie diesen Wert auf „GitGuardian“ fest. | |
| member_email | principal.user.email_addresses | Zusammengeführt aus member_email |
| member_name | principal.user.user_display_name | Wert direkt kopiert |
| member_id | principal.user.userid | In String umgewandelt |
| action_type | security_result.action_details | Wert direkt kopiert |
| target_ids | target.resource.product_object_id | Wert aus dem ersten Element von „target_ids“ |
Änderungsprotokoll
Änderungsprotokoll für diesen Parser ansehen
Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten