CircleCI-Audit-Logs erfassen

Unterstützt in:

Dieser Parser extrahiert Felder aus CircleCI-Prüfprotokollen im CSV- und JSON-Format und wandelt sie in das einheitliche Datenmodell (Unified Data Model, UDM) um. Sie verarbeitet beide Formate, führt Datentransformationen und ‑anreicherungen durch und ordnet die extrahierten Felder den entsprechenden UDM-Feldern im event-Objekt zu. Es konzentriert sich auf Nutzeraktionen, Ressourcenzugriff und Aktualisierungsereignisse, kategorisiert sie und füllt relevante UDM-Felder wie principal, target, network und metadata aus.

Hinweise

Prüfen Sie, ob die folgenden Voraussetzungen erfüllt sind:

  • Google SecOps-Instanz.
  • Privilegierter Zugriff auf CircleCI

Feeds einrichten

Es gibt zwei verschiedene Einstiegspunkte zum Einrichten von Feeds in der Google SecOps-Plattform:

  • SIEM-Einstellungen > Feeds
  • Content Hub> Content-Pakete

Feeds über „SIEM-Einstellungen“ > „Feeds“ einrichten

So konfigurieren Sie einen Feed:

  1. Rufen Sie die SIEM-Einstellungen > Feeds auf.
  2. Klicken Sie auf Neuen Feed hinzufügen.
  3. Klicken Sie auf der nächsten Seite auf Einen einzelnen Feed konfigurieren.
  4. Geben Sie im Feld Feed name (Feedname) einen Namen für den Feed ein, z. B. CircleCI Logs (CircleCI-Logs).
  5. Wählen Sie Webhook als Quelltyp aus.
  6. Wählen Sie CircleCI als Logtyp aus.
  7. Klicken Sie auf Weiter.
  8. Optional: Geben Sie Werte für die folgenden Eingabeparameter an:
    • Trennzeichen für Aufteilung: Das Trennzeichen, das zum Trennen von Logzeilen verwendet wird, z. B. \n.
    • Asset-Namespace: der Asset-Namespace.
    • Aufnahmelabels: Das Label, das auf die Ereignisse aus diesem Feed angewendet wird.
  9. Klicken Sie auf Weiter.
  10. Prüfen Sie die Feedkonfiguration auf dem Bildschirm Finalize (Abschließen) und klicken Sie dann auf Submit (Senden).
  11. Klicken Sie auf Geheimen Schlüssel generieren, um einen geheimen Schlüssel zur Authentifizierung dieses Feeds zu generieren.
  12. Kopieren Sie den geheimen Schlüssel und speichern Sie ihn. Sie können diesen geheimen Schlüssel nicht noch einmal aufrufen. Bei Bedarf können Sie einen neuen geheimen Schlüssel generieren. Dadurch wird der vorherige geheime Schlüssel jedoch ungültig.
  13. Kopieren Sie auf dem Tab Details die Feed-Endpunkt-URL aus dem Feld Endpunktinformationen. Sie müssen diese Endpunkt-URL in Ihrer Clientanwendung angeben.
  14. Klicken Sie auf Fertig.

Feeds über den Content Hub einrichten

Geben Sie Werte für die folgenden Felder an:

  • Trennzeichen für Aufteilung: Das Trennzeichen, das zum Trennen von Logzeilen verwendet wird, z. B. \n.

Erweiterte Optionen

  • Feedname: Ein vorausgefüllter Wert, der den Feed identifiziert.
  • Quelltyp: Methode, die zum Erfassen von Logs in Google SecOps verwendet wird.
  • Asset-Namespace: Der Namespace, der dem Feed zugeordnet ist.
  • Aufnahmelabels: Labels, die auf alle Ereignisse aus diesem Feed angewendet werden.

  • Klicken Sie auf Geheimen Schlüssel generieren, um einen geheimen Schlüssel zur Authentifizierung dieses Feeds zu generieren.

  • Kopieren Sie den geheimen Schlüssel und speichern Sie ihn. Sie können diesen geheimen Schlüssel nicht noch einmal aufrufen. Bei Bedarf können Sie einen neuen geheimen Schlüssel generieren. Dadurch wird der vorherige geheime Schlüssel jedoch ungültig.

  • Kopieren Sie auf dem Tab Details die Feed-Endpunkt-URL aus dem Feld Endpunktinformationen. Sie müssen diese Endpunkt-URL in Ihrer Clientanwendung angeben.

API-Schlüssel für den Webhook-Feed erstellen

  1. Rufen Sie die Google Cloud Console > Anmeldedaten auf.

    Zu den Anmeldedaten

  2. Klicken Sie auf Anmeldedaten erstellen und wählen Sie anschließend API-Schlüssel aus.

  3. Schränken Sie den API-Schlüsselzugriff auf die Google Security Operations API ein.

Endpunkt-URL angeben

  1. Geben Sie in Ihrer Clientanwendung die HTTPS-Endpunkt-URL an, die im Webhook-Feed bereitgestellt wird.
  2. Aktivieren Sie die Authentifizierung, indem Sie den API-Schlüssel und den geheimen Schlüssel als Teil des benutzerdefinierten Headers im folgenden Format angeben:

    X-goog-api-key = API_KEY
    X-Webhook-Access-Key = SECRET
    

    Empfehlung: Geben Sie den API-Schlüssel als Header an, anstatt ihn in der URL anzugeben.

  3. Wenn Ihr Webhook-Client keine benutzerdefinierten Headern unterstützt, können Sie den API-Schlüssel und den geheimen Schlüssel mit Suchparametern im folgenden Format angeben:

    ENDPOINT_URL?key=API_KEY&secret=SECRET
    

    Ersetzen Sie Folgendes:

    • ENDPOINT_URL: Die URL des Feed-Endpunkts.
    • API_KEY: Der API-Schlüssel für die Authentifizierung bei Google SecOps.
    • SECRET: Der geheime Schlüssel, den Sie zur Authentifizierung des Feeds generiert haben.

Webhook in CircleCI konfigurieren

  1. Melden Sie sich in der CircleCI-Weboberfläche an.
  2. Wählen Sie das Projekt aus, aus dem Sie die Logs aufnehmen möchten.
  3. Klicken Sie auf Projekteinstellungen.
  4. Wählen Sie Webhooks aus.
  5. Klicken Sie auf Webhook hinzufügen.
  6. Geben Sie Werte für die folgenden Eingabeparameter an:

    • Webhook-Name: Geben Sie einen aussagekräftigen Namen an, z. B. Google SecOps.
    • Endpoint URL (Endpunkt-URL): Geben Sie die <ENDPOINT_URL> des Google SecOps API-Endpunkt ein.
    • Ereignisse:Wählen Sie die CircleCI-Ereignisse aus, die den Webhook auslösen sollen. Wenn Sie beispielsweise workflow-completed auswählen, werden Daten gesendet, nachdem ein Workflow abgeschlossen ist.
  7. Klicken Sie auf Speichern, um den Webhook zu erstellen.

UDM-Zuordnungstabelle

Logfeld UDM-Zuordnung Logik
account.id read_only_udm.about.resource.attribute.labels.value Der Wert von account.id aus dem Rohlog wird dem UDM-Feld read_only_udm.about.resource.attribute.labels.value zugewiesen, wobei der entsprechende key account_id ist.
Aktion read_only_udm.metadata.product_event_type Der Wert von action aus dem Rohlog wird dem UDM-Feld read_only_udm.metadata.product_event_type zugewiesen.
actor.id read_only_udm.principal.user.product_object_id Der Wert von actor.id aus dem Rohlog wird dem UDM-Feld read_only_udm.principal.user.product_object_id zugewiesen.
actor.name read_only_udm.principal.user.userid Das Präfix „github: “ wird aus dem Feld actor.name im Rohlog entfernt. Der verbleibende Wert wird dem UDM-Feld read_only_udm.principal.user.userid zugewiesen. Wenn actor.name im Rohlog vorhanden ist, wird read_only_udm.metadata.event_type der Wert USER_RESOURCE_UPDATE_CONTENT zugewiesen. Andernfalls wird USER_RESOURCE_ACCESS zugewiesen.
id read_only_udm.metadata.product_log_id Der Wert von id aus dem Rohlog wird dem UDM-Feld read_only_udm.metadata.product_log_id zugewiesen. Der Parser legt read_only_udm.metadata.log_type auf CIRCLECI fest. Der Parser legt read_only_udm.metadata.product_name auf CIRCLECI fest. Der Parser legt read_only_udm.metadata.vendor_name auf CIRCLECI fest.
occurred_at read_only_udm.metadata.event_timestamp Der Wert von occurred_at aus dem Rohlog wird als Zeitstempel geparst und dem UDM-Feld read_only_udm.metadata.event_timestamp zugewiesen.
organization.name read_only_udm.target.administrative_domain Das Präfix „github: “ wird aus dem Feld organization.name im Rohlog entfernt. Der verbleibende Wert wird dem UDM-Feld read_only_udm.target.administrative_domain zugewiesen.
payload.job.id read_only_udm.about.resource.attribute.labels.value Der Wert von payload.job.id aus dem Rohlog wird dem UDM-Feld read_only_udm.about.resource.attribute.labels.value zugewiesen, wobei der entsprechende key job_id ist.
payload.job.job_name read_only_udm.about.resource.attribute.labels.value Der Wert von payload.job.job_name aus dem Rohlog wird dem UDM-Feld read_only_udm.about.resource.attribute.labels.value zugewiesen, wobei der entsprechende key job_name ist.
payload.job.job_status read_only_udm.about.resource.attribute.labels.value Der Wert von payload.job.job_status aus dem Rohlog wird dem UDM-Feld read_only_udm.about.resource.attribute.labels.value zugewiesen, wobei der entsprechende key job_status ist.
payload.workflow.id read_only_udm.about.resource.attribute.labels.value Der Wert von payload.workflow.id aus dem Rohlog wird dem UDM-Feld read_only_udm.about.resource.attribute.labels.value zugewiesen, wobei der entsprechende key workflow_id ist.
request.id read_only_udm.network.session_id Der Wert von request.id aus dem Rohlog wird dem UDM-Feld read_only_udm.network.session_id zugewiesen.
scope.id read_only_udm.about.resource.attribute.labels.value Der Wert von scope.id aus dem Rohlog wird dem UDM-Feld read_only_udm.about.resource.attribute.labels.value zugewiesen, wobei der entsprechende key scope_id ist. Der Parser setzt sec_action anfangs auf BLOCK. Wenn das Feld success im Rohlog „true“ ist, wird sec_action in ALLOW geändert. Der Wert von sec_action wird dann dem UDM-Feld read_only_udm.security_result.action zugewiesen.
target.id read_only_udm.target.resource.product_object_id Der Wert von target.id aus dem Rohlog wird dem UDM-Feld read_only_udm.target.resource.product_object_id zugewiesen.
target.name read_only_udm.target.resource.name Das Präfix „github: “ wird im Rohlog aus dem Feld target.name entfernt. Der verbleibende Wert wird dem UDM-Feld read_only_udm.target.resource.name zugewiesen. Der Parser legt read_only_udm.target.resource.resource_type auf STORAGE_OBJECT fest.
version read_only_udm.target.resource.attribute.labels.value Der Wert von version aus dem Rohlog wird in einen String umgewandelt und dem UDM-Feld read_only_udm.target.resource.attribute.labels.value zugewiesen, wobei der entsprechende key version ist.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten