Logeinträge weiterleiten

Mit Cloud Logging können Sie Logeinträge aus Cloud de Confiance by S3NS -Diensten, Ihren Anwendungen und anderen Cloud-Anbietern an Ziele für die Speicherung, Analyse und den Export an Drittanbieter weiterleiten.

Standardmäßig leitet Cloud Logging alle Logeinträge an Log-Buckets in dem Projekt, Ordner oder der Organisation weiter, aus dem sie stammen. Sie können jedoch Logs-Senken konfigurieren, um Logdaten an benutzerdefinierte Buckets oder Pub/Sub weiterzuleiten. Pub/Sub unterstützt den Export Ihrer Daten in Drittanbietertools.

Logeinträge weiterleiten und exportieren

Routing ist der Vorgang, bei dem Logeinträge, die von einem Cloud de Confiance -Projekt, -Ordner oder einer ‑Organisation empfangen werden, an ein Ziel weitergeleitet werden. Ein Ziel ist ein Dienst, der empfangene Logeinträge verarbeitet und eine Aktion ausführt. Sie können beispielsweise Logeinträge an ein Log-Bucket weiterleiten. Bei diesem Ziel werden die Logeinträge nach Fehlerinformationen durchsucht und dann in den Speicher geschrieben.

Beim Exportieren werden Logeinträge aus Cloud de Confiance by S3NS an einen externen Speicherort verschoben. Sie können Logeinträge beispielsweise an Pub/Sub weiterleiten und dann in Tools von Drittanbietern exportieren.

Cloud Logging verwendet Logsenken, um Logeinträge an Ziele weiterzuleiten. Standardmäßig werden Ihre Logeinträge an einen von zwei Log-Buckets in IhremCloud de Confiance Projekt, Ordner oder Ihrer Organisation weitergeleitet. Sie können Logsenken erstellen, um Ihre Logdaten an andere Ziele weiterzuleiten. Sie können auch einen der vom System erstellten Log-Senken ändern. In diesem Dokument werden diese Optionen beschrieben.

Mit dem Log-Explorer können Sie Logeinträge, die in Log-Buckets gespeichert sind, in den lokalen Speicher herunterladen. Die Downloadoption ist jedoch auf 10.000 Logeinträge beschränkt. Wenn Sie Ihre Logeinträge ausCloud de Confiance by S3NSexportieren möchten, konfigurieren Sie eine Logsenke, um eingehende Logeinträge an Pub/Sub weiterzuleiten, und exportieren Sie die Daten dann aus Cloud de Confiance by S3NS.

Log-Router

Jedes Cloud de Confiance Projekt, Rechnungskonto, jeder Ordner und jede Organisation hat einen Log-Router, der den Fluss von Logeinträgen durch Senken auf Ressourcenebene verwaltet. Ein Log-Router verwaltet auch den Fluss eines Logeintrags durch Senken, die sich in der Ressourcenhierarchie des Eintrags befinden. Senken steuern, wie Logeinträge an Ziele weitergeleitet werden.

Ein Log-Router speichert einen Logeintrag vorübergehend. Dieses Verhalten schützt vor vorübergehenden Unterbrechungen und Ausfällen, die auftreten können, wenn ein Logeintrag durch Senken fließt. Temporärer Speicher schützt nicht vor Konfigurationsfehlern.

Der temporäre Speicher eines Log-Routers unterscheidet sich vom Langzeitspeicher, der von Logging-Buckets bereitgestellt wird.

Eingehende Logeinträge mit Zeitstempeln, die mehr als die Aufbewahrungsdauer für Logs in der Vergangenheit liegen oder die mehr als 24 Stunden in der Zukunft liegen, werden verworfen.

Logsenken

Wenn eine Logs-Senke einen Logeintrag empfängt, wird entschieden, ob der Logeintrag ignoriert oder an das Ziel der Senke weitergeleitet werden soll. Die Logsenke vergleicht den Logeintrag mit ihren Filtern, um diese Entscheidung zu treffen. Das Ziel einer Senke kann ein Projekt, ein Speicherort oder ein Dienst wie Pub/Sub sein. Eine Senke kann beispielsweise Logeinträge an einen Log-Bucket weiterleiten.

Logsinks gehören zu einer bestimmten Cloud de Confiance by S3NS Ressource Cloud de Confiance :Projekte, Rechnungskonten, Ordner und Organisationen. Diese Ressourcen enthalten auch mehrere Logsinks. Wenn eine Ressource einen Logeintrag empfängt, wird dieser von jeder Logsenke in dieser Ressource unabhängig ausgewertet. Daher können mehrere Logsinks denselben Logeintrag weiterleiten.

Standardmäßig werden Logdaten in dem Projekt gespeichert, aus dem die Daten stammen. Es gibt jedoch mehrere Gründe, warum Sie diese Konfiguration ändern sollten:

  • Um die Speicherung Ihrer Logdaten zu zentralisieren.
  • Logdaten mit anderen Geschäftsdaten zusammenführen
  • Zum Organisieren Ihrer Logdaten in einer für Sie nützlichen Weise.
  • Sie können Ihre Logs an andere Anwendungen, Repositories oder Dritte senden. Sie möchten Ihre Logs beispielsweise aus Cloud de Confiance by S3NS exportieren, damit Sie sie auf einer Drittanbieterplattform ansehen können. Wenn Sie Ihre Logeinträge exportieren möchten, erstellen Sie eine Logsenke, die Ihre Logeinträge an Pub/Sub weiterleitet.

Bei einer falsch konfigurierten Logsenke werden Logeinträge nicht weitergeleitet. Wenn eine Senke falsch konfiguriert ist, werden Logeinträge geschrieben, in denen die Details des Fehlers angegeben sind. Außerdem wird eine E‑Mail an die wichtigen Kontakte für die Ressource gesendet. Weitere Informationen finden Sie unter Fehlerbehebung: Fehler ansehen.

Mit Logsenken können Logeinträge nicht rückwirkend weitergeleitet werden. Eine Logsenke kann also keinen Logeintrag weiterleiten, der vor der Erstellung der Senke empfangen wurde. Wenn eine Senke falsch konfiguriert ist, werden nur Logeinträge weitergeleitet, die nach der Behebung des Konfigurationsfehlers eingehen.

Unterstützung für Organisationen und Ordner

Um die Logdaten in einer Organisation oder einem Ordner zu verwalten, haben Sie folgende Möglichkeiten:

  • Sie können aggregierte Senken erstellen, mit denen Logeinträge für eine Organisation oder einen Ordner und deren untergeordnete Elemente an das in der Senke angegebene Ziel weitergeleitet werden. Es gibt zwei Arten von aggregierten Senken:

    • Nicht abfangende aggregierte Senken
    • Aggregierte Senken abfangen

    Abfangende Senken können das Routingverhalten für Ressourcen auf niedrigeren Ebenen in der Hierarchie überschreiben. Nicht abfangende Senken haben keine Auswirkungen auf das Routing für andere Ressourcen. Wenn eine abfangende Senke in einer Ressource mit einem Logeintrag übereinstimmt, wird der Logeintrag nicht an die Senken in untergeordneten Ressourcen gesendet. Eine Ausnahme besteht jedoch: Der Logeintrag wird immer an die _Required-Logsenke in der Ressource gesendet, aus der der Logeintrag stammt.

  • Sie können Standardressourceneinstellungen für Cloud Logging konfigurieren, um die Konfiguration der vom System erstellten _Default-Senke für neue Ressourcen in einer Organisation oder einem Ordner anzugeben. Sie können diese Einstellungen beispielsweise verwenden, um die _Default-Senke zu deaktivieren oder die Filter in dieser Senke anzugeben.

Routing-Beispiele

In diesem Abschnitt wird veranschaulicht, wie ein Logeintrag, der in einem Projekt erstellt wurde, durch die Senken in der zugehörigen Ressourcenhierarchie fließen kann.

Beispiel: Es sind keine aggregierten Senken vorhanden

Wenn in der Ressourcenhierarchie des Logeintrags keine aggregierten Senken vorhanden sind, wird der Logeintrag an die Logsenken in dem Projekt gesendet, aus dem der Logeintrag stammt. Eine Senke auf Projektebene leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem Einschlussfilter der Senke übereinstimmt, aber nicht mit einem der Ausschlussfilter der Senke.

Beispiel: Es ist ein nicht abfangender aggregierter Sink vorhanden.

Angenommen, in der Ressourcenhierarchie ist für einen Logeintrag eine nicht abfangende aggregierte Senke vorhanden. Nachdem der Log-Router den Logeintrag an die nicht abfangende aggregierte Senke gesendet hat, geschieht Folgendes:

  1. Die nicht abfangende zusammengefasste Senke leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem Einschlussfilter übereinstimmt, aber nicht mit einem Ausschlussfilter.

  2. Der Log-Router sendet den Logeintrag an die Logsenken in dem Projekt, in dem der Logeintrag erstellt wurde.

    Eine Senke auf Projektebene leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem Einschlussfilter der Senke übereinstimmt, aber nicht mit einem der Ausschlussfilter der Senke.

Beispiel: Es ist eine abfangende aggregierte Senke vorhanden

Angenommen, in der Ressourcenhierarchie ist eine abfangende aggregierte Senke für einen Logeintrag vorhanden. Nachdem der Log-Router den Logeintrag an die abfangende aggregierte Senke gesendet hat, geschieht eines der folgenden Dinge:

  • Der Logeintrag stimmt mit dem Einschlussfilter überein, aber nicht mit einem Ausschlussfilter:

    1. Der Logeintrag wird an das Ziel der abfangenden aggregierten Senke weitergeleitet.
    2. Der Logeintrag wird an die Senke _Required in dem Projekt gesendet, aus dem der Logeintrag stammt.

  • Der Logeintrag stimmt nicht mit dem Einschlussfilter überein oder er stimmt mit mindestens einem Ausschlussfilter überein:

    1. Der Logeintrag wird nicht von der abfangenden aggregierten Senke weitergeleitet.

    2. Der Log-Router sendet den Logeintrag an die Logsenken in dem Projekt, in dem der Logeintrag erstellt wurde.

      Eine Senke auf Projektebene leitet den Logeintrag an das Ziel der Senke weiter, wenn der Logeintrag mit dem Einschlussfilter der Senke übereinstimmt, aber nicht mit einem der Ausschlussfilter der Senke.

Filter für Logsenken

Jede Logs-Senke enthält einen Einschlussfilter und kann mehrere Ausschlussfilter enthalten. Mit diesen Filtern wird festgelegt, ob die Logsenke einen Logeintrag an das Ziel der Senke weiterleitet. Wenn Sie keine Filter angeben, wird jeder Logeintrag an das Ziel der Senke weitergeleitet.

Ein Logeintrag wird von einem Log-Sink anhand der folgenden Regeln weitergeleitet:

  • Wenn der Logeintrag nicht mit dem Einschlussfilter übereinstimmt, wird er nicht weitergeleitet. Wenn für eine Senke kein Einschlussfilter angegeben ist, stimmt jeder Logeintrag mit diesem Filter überein.

  • Wenn der Logeintrag mit dem Einschlussfilter und mindestens einem Ausschlussfilter übereinstimmt, wird er nicht weitergeleitet.

  • Wenn der Logeintrag mit dem Einschlussfilter übereinstimmt und mit keinem Ausschlussfilter, wird er an das Ziel der Senke weitergeleitet.

Die Filter in einer Logsenke werden mit der Logging-Abfragesprache angegeben.

Sie können Ausschlussfilter nicht verwenden, um die Nutzung Ihres entries.write API-Kontingents oder die Anzahl der entries.write API-Aufrufe zu verringern. Ausschlussfilter werden angewendet, nachdem Logeinträge von der Logging API empfangen wurden.

Vom System erstellte Logsenken

Für jedes Cloud de Confiance Projekt, Rechnungskonto, jeden Ordner und jede Organisation erstellt Cloud Logging zwei Logsinks: _Required und _Default. Die Ein- und Ausschlussfilter für diese Senken sorgen dafür, dass jeder Logeintrag, der von der Ressource stammt, über eine dieser Senken weitergeleitet wird. Beide Senken leiten Logdaten an einen Log-Bucket weiter, der sich in derselben Ressource wie die Logsenke befindet.

Im Rest dieses Abschnitts finden Sie Informationen zu den Filtern und Zielen der vom System erstellten Logsinks.

_Required Logsenke

Die _Required-Logsink in einer Ressource leitet eine Teilmenge von Audit-Logs an den _Required-Log-Bucket der Ressource weiter. Für diese Senke sind keine Ausschlussfilter angegeben und der Einschlussfilter ist wie folgt:

LOG_ID("cloudaudit.googleapis.com/activity") OR
LOG_ID("externalaudit.googleapis.com/activity") OR
LOG_ID("cloudaudit.googleapis.com/system_event") OR
LOG_ID("externalaudit.googleapis.com/system_event") OR
LOG_ID("cloudaudit.googleapis.com/access_transparency") OR
LOG_ID("externalaudit.googleapis.com/access_transparency")

Die Logsenke _Required entspricht nur Logeinträgen, die von der Ressource stammen, in der die Logsenke _Required definiert ist. Angenommen, eine Log-Senke leitet einen Aktivitätslogeintrag aus dem Projekt A an das Projekt B weiter. Da der Logeintrag nicht aus dem Projekt B stammt, wird er durch die _Required-Logsink im Projekt B nicht an den _Required-Log-Bucket weitergeleitet.

Sie können die Logs-Senke _Required nicht ändern oder löschen.

_Default Logsenke

Die _Default-Logsenke in einer Ressource leitet Logeinträge an den _Default-Log-Bucket der Ressource weiter. Da der Einschlussfilter für diese Senke leer ist, entspricht er allen Logeinträgen. Der Ausschlussfilter ist jedoch so konfiguriert:

NOT LOG_ID("cloudaudit.googleapis.com/activity") AND
NOT LOG_ID("externalaudit.googleapis.com/activity") AND
NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND
NOT LOG_ID("externalaudit.googleapis.com/system_event") AND
NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND
NOT LOG_ID("externalaudit.googleapis.com/access_transparency")

Sie können die Logs-Senke _Default ändern und deaktivieren. Sie können beispielsweise die Logs-Senke _Default bearbeiten und das Ziel ändern. Sie können auch vorhandene Filter ändern und Ausschlussfilter hinzufügen.

Senkenziele

Das Ziel einer Senke kann sich in einer anderen Ressource als die Senke befinden. Sie können beispielsweise eine Logsenke verwenden, um Logeinträge aus einem Projekt an einen Log-Bucket weiterzuleiten, der in einem anderen Projekt gespeichert ist.

Die folgenden Ziele werden unterstützt:

Cloud de Confiance -Projekt

Wählen Sie dieses Ziel aus, wenn die Logsenken im Zielprojekt Ihre Logeinträge weiterleiten sollen oder wenn Sie eine abfangende aggregierte Senke erstellt haben. Die Logsinks im Zielprojekt können die Logeinträge an jedes unterstützte Ziel weiterleiten, mit Ausnahme eines Projekts.

Die vom System erstellten Logsenken im Zielprojekt schließen Logeinträge aus, die an den Log-Bucket _Required im Quellprojekt weitergeleitet werden. Wenn Sie beispielsweise Administratoraktivitätslogs an ein anderes Projekt weiterleiten, werden diese Logeinträge sowohl von den _Required- als auch von den _Default-Logsinks im Zielprojekt ausgeschlossen. Um diese Logeinträge zu speichern, müssen Sie im Zielprojekt die _Default-Logsenke aktualisieren oder eine benutzerdefinierte Logsenke erstellen.

Log-Bucket
Wählen Sie dieses Ziel aus, wenn Sie Ihre Logdaten in von Cloud Logging verwalteten Ressourcen speichern möchten. In Log-Buckets gespeicherte Logdaten können mit Diensten wie dem Log-Explorer aufgerufen und analysiert werden.
Pub/Sub-Thema
Wählen Sie dieses Ziel aus, wenn Sie Ihre Logdaten ausCloud de Confiance by S3NS exportieren und dann eine Drittanbieterintegration verwenden möchten. Logeinträge werden als JSON formatiert und dann an ein Pub/Sub-Thema weitergeleitet.

Einschränkungen für Ziele

In diesem Abschnitt werden zielgruppenspezifische Einschränkungen beschrieben:

  • Die folgenden Einschränkungen gelten, wenn das Ziel einer Logs-Senke ein Cloud de Confiance -Projekt ist:

    • Es gibt ein Hop-Limit.
    • Die _Required-Logsenke im Zielprojekt leitet Logeinträge an den _Required-Log-Bucket des Projekts weiter, wenn die Logeinträge mit dem Filter der Senke übereinstimmen und aus dem Zielprojekt stammen.
    • Die _Default-Logsenke im Zielprojekt leitet Logeinträge weiter, die mit ihrem Einschlussfilter übereinstimmen und nicht mit einem Ausschlussfilter. In der Logs-Senke _Default werden einige Logeinträge ausgeschlossen. Über diesen Senke werden beispielsweise keine Logeinträge zu Administratoraktivitäten und Systemereignissen weitergeleitet. Sie können diese Senke ändern.
    • Nur aggregierte Senken, die sich in der Ressourcenhierarchie eines Logeintrags befinden, verarbeiten den Eintrag.

    Angenommen, das Ziel einer Logs-Senke im Projekt A ist das Projekt B. In diesem Fall gelten die folgenden Regeln:

    • Aufgrund des One-Hop-Limits können die Logsenken im Projekt B Logeinträge nicht in ein anderes Cloud de Confiance Projekt umleiten.
    • Im Log-Bucket _Required des Projekts B werden nur Logeinträge gespeichert, die aus dem Projekt B stammen. In diesem Log-Bucket werden keine Logeinträge gespeichert, die aus einer anderen Ressource stammen, einschließlich der Einträge, die aus dem Projekt A stammen.
    • Wenn Projekt A und Projekt B unterschiedliche Ressourcenhierarchien haben, wird ein Logeintrag, den eine Logs-Senke in Projekt A an Projekt B weiterleitet, nicht an die aggregierten Senken in der Ressourcenhierarchie von Projekt B gesendet.
    • Wenn Projekt A und Projekt B dieselbe Ressourcenhierarchie haben, werden Logeinträge an die aggregierten Senken in dieser Hierarchie gesendet. Wenn ein Logeintrag nicht von einer aggregierten Senke abgefangen wird, sendet der Log-Router den Eintrag an die Senken im Projekt A.

Best Practices

Verwalten Sie Ihre Log-Senken, wenn Sie Ihren Log-Speicher verwalten. Wenn Sie beispielsweise das Ziel einer Logsenke löschen, löschen Sie auch die entsprechende Logsenke.

Best Practices für die Verwendung von Routing für Data Governance oder für gängige Anwendungsfälle finden Sie in den folgenden Dokumenten:

Beispiele: Logspeicher zentralisieren

In diesem Abschnitt wird beschrieben, wie Sie zentralen Speicher konfigurieren können. Durch die zentrale Speicherung können Sie Logdaten an einem einzigen Ort abfragen. Das vereinfacht Ihre Abfragen, wenn Sie nach Trends suchen oder Probleme untersuchen. Aus Sicherheitssicht haben Sie auch einen Speicherort, was die Aufgaben Ihrer Sicherheitsanalysten vereinfachen kann.

Wenn Sie die Speicherung Ihrer Logs zentralisieren, sollten Sie prüfen, ob Sie das Projekt, in dem Ihre Logdaten gespeichert werden, mit einem Pfandrecht belegen möchten. Eine Sperre kann das versehentliche Löschen eines Projekts verhindern. Weitere Informationen finden Sie unter Projekte mit Sperren schützen.

Zentrale Speicherung von Logs für Projekte in einem Ordner

Angenommen, Sie verwalten einen Ordner und möchten den Speicher Ihrer Logeinträge zentralisieren. Für diesen Anwendungsfall können Sie Folgendes tun:

  1. In diesem Ordner erstellen Sie ein Projekt mit dem Namen CentralStorage.
  2. Erstellen Sie eine abfangende zusammengefasste Senke für Ihren Ordner und konfigurieren Sie sie so, dass alle Logeinträge weitergeleitet werden. Sie haben das Ziel der Senke auf das Projekt CentralStorage festgelegt.

Wenn ein Logeintrag, der im Ordner oder in einer seiner untergeordneten Ressourcen stammt, eingeht, wird er an die von Ihnen erstellte abfangende aggregierte Senke gesendet. Über diese Senke werden Logeinträge an das Projekt CentralStorage weitergeleitet. Die Logsenken in diesem Projekt verarbeiten die Logeinträge:

  • Die _Default-Logsenke leitet alle Logeinträge, die mit dem Filter der Senke übereinstimmen, an den _Default-Log-Bucket weiter. Dieser Log-Bucket ist Ihr zentraler Speicherort.

  • Die _Required-Logsenke leitet die Logeinträge, die den Filtern der Senke entsprechen und aus dem CentralStorage-Projekt stammen, an den _Required-Log-Bucket weiter. Dieser Log-Bucket ist kein zentraler Speicherort. Sie können jedoch alle Ihre Protokolldaten zentral speichern. Ein Beispiel finden Sie unter Audit-Logs an einem zentralen Ort speichern.

Nachdem die Verarbeitung der aggregierten Senke abgeschlossen ist, wird der Logeintrag an die _Required-Logsenke in der Ressource gesendet, in der der Logeintrag erstellt wurde. Wenn der Logeintrag mit dem Filter in der _Required-Logsenke übereinstimmt, wird er an den _Required-Log-Bucket der Ressource weitergeleitet. Daher werden Logeinträge für jedes Cloud de Confiance Projekt in Ihrem Ordner im zugehörigen _Required-Log-Bucket gespeichert.

Logspeicher für eine Reihe von Projekten zentralisieren

Sie können Logeinträge auch an einem einzigen Ort speichern, wenn Sie keine Organisation oder keinen Ordner haben. Zum Beispiel könnten Sie Folgendes tun:

  1. Erstellen Sie ein Projekt mit dem Namen CentralStorage.
  2. Für jedes Projekt außer CentralStorage bearbeiten Sie die Logsinks _Default und legen als Ziel das Projekt CentralStorage fest.

Vielleicht fragen Sie sich, warum im vorherigen Beispiel das Ziel der _Default-Logsinks ein Projekt und nicht der _Default-Log-Bucket in diesem Projekt ist. Die Hauptgründe dafür sind Einfachheit und Einheitlichkeit. Wenn Sie Logeinträge an ein Projekt weiterleiten, wird durch die Logsinks im Zielprojekt gesteuert, welche Logeinträge gespeichert werden und wo sie gespeichert werden. Das bedeutet, dass Sie die Filter- und Zielfunktionen zentralisieren. Wenn Sie ändern möchten, welche Logeinträge gespeichert werden oder wo sie gespeichert werden, müssen Sie nur die Log-Senken in einem Projekt ändern.

Zentrale Speicherung von Audit-Logs

Sie können Logeinträge, die der _Required-Logsenke entsprechen, zentral speichern. Um diese Logeinträge zentral zu speichern, haben Sie folgende Möglichkeiten:

  • Erstellen Sie Logsenken, die Logeinträge, die der Logsenke _Required entsprechen, an einen zentralen Log-Bucket weiterleiten.

  • Konfigurieren Sie Logsenken wie in den beiden vorherigen Beispielen und fügen Sie dann im Zielprojekt eine Logsenke hinzu, die Logeinträge, die der _Required-Logsenke entsprechen, an einen Log-Bucket weiterleitet. Sie können die Filter auch in der _Default-Logsenke bearbeiten.

Bevor Sie eine solche Strategie implementieren, sollten Sie sich die Preisrichtlinien ansehen.

Nächste Schritte

Informationen zum Weiterleiten und Speichern von Cloud Logging-Daten finden Sie in den folgenden Dokumenten: