Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Diese Seite wurde von der Cloud Translation API übersetzt.

Audit-Logging von VPC Service Controls

In diesem Dokument werden die Audit-Logs beschrieben, die von VPC Service Controls als Teil von Cloud-Audit-Logs erstellt werden.

Übersicht

Dienste vonCloud de Confiance by S3NS erstellen Audit-Logs, um Ihnen Antworten auf Fragen wie „Wer hat was wo und wann getan?“ für Ihre Ressourcen in Cloud de Confiance zu liefern.

Ihre Projekte in Cloud de Confiance enthalten nur die Audit-Logs für Ressourcen, die sich direkt im jeweiligen Projekt in Cloud de Confiance befinden. Andere Ressourcen in Cloud de Confiance wie Ordner, Organisationen und Rechnungskonten enthalten jeweils eigene Audit-Logs.

Einen allgemeinen Überblick über Cloud-Audit-Logs finden Sie unter Cloud-Audit-Logs – Übersicht. Detaillierte Informationen zum Format von Audit-Logs finden Sie unter Audit-Logs verstehen.

Verfügbare Audit-Logs

Für VPC Service Controls stehen die folgenden Arten von Audit-Logs zur Verfügung:

Audit-Logs zu Richtlinienverstößen

Gibt an, wann einem Nutzer oder Dienstkonto aufgrund eines Verstoßes gegen die Sicherheitsrichtlinien der Zugriff verweigert wird. Der Dienstname und der Methodenname in Audit-Logs zu Richtlinienverstößen geben die Namen der Ressource an, auf die der Nutzer oder das Dienstkonto keinen Zugriff hatte.

Audit-Logs zu Richtlinienverstößen können nicht deaktiviert werden. Sie können jedoch den Ausschlussfilter für Ihre _Default-Senke um LOG_ID("cloudaudit.googleapis.com/policy") erweitern, um Audit-Logs zu Richtlinienverstößen auszuschließen. Sie können auch die Senke _Default für Cloud Logging deaktivieren, um zu verhindern, dass Logs an den Bucket _Default weitergeleitet werden.

Ausführlichere Informationen finden Sie unter Arten von Audit-Logs.

Geprüfte Vorgänge

In der folgenden Tabelle wird zusammengefasst, welche API-Vorgänge dem jeweiligen Audit-Log-Typ in VPC Service Controls entsprechen:

Audit-Logkategorie	VPC Service Controls-Methoden
Audit-Logs zu Richtlinienverstößen	Die Methoden der Dienste, die in VPC Service Controls eingebunden sind, werden unterstützt.

Inhalt von Audit-Log-Einträgen

Jeder Audit-Log-Eintrag enthält Informationen, die in zwei Hauptkategorien unterteilt werden können: Informationen zum ursprünglichen Aufruf und Informationen zu Verstößen gegen die Sicherheitsrichtlinien. Die Informationen werden wie nachfolgend beschrieben durch die VPC Service Controls API angegeben:

Audit-Log-Feld	Beschreibung
`serviceName`	Der Dienst, auf den der Zugriff durch einen Dienstperimeter eingeschränkt wird. Die Anfrage an diesen Dienst hat gegen eine VPC Service Controls-Prüfung verstoßen und zur Erstellung dieses Audit-Logs geführt.
`methodName`	Der Name des Methodenaufrufs, der zu dem in dem Eintrag beschriebenen Verstoß der Sicherheitsrichtlinien geführt hat. Häufig ist `methodName` die Methode, die dem im Feld `serviceName` angegebenen Dienst von Cloud de Confiance by S3NS zugeordnet ist.
`authenticationInfo.principalEmail`	Die E-Mail-Adresse des Nutzers oder Dienstkontos, von dem die Anfrage stammt. Einige E‑Mail-Adressen werden möglicherweise entfernt. Weitere Informationen finden Sie unter Aufruferidentitäten in Audit-Logs.
`resourceName`	Die in der ursprünglichen Anfrage des Clients angegebene Cloud de Confiance by S3NS -Ressource. `resourceName` kann ein Projekt, ein Ordner, eine Organisation oder eine Ressource wie ein Bucket von Cloud de Confiance by S3NS sein.
`requestMetadata.callerIp`	Die IP-Adresse des Aufrufers. Wenn der Anruf aus dem Internet stammt, ist `requestMetadata.callerIp` eine öffentliche IPv4- oder IPv6-Adresse. Wenn der Aufruf von einer Compute Engine-VM stammt, ist `requestMetadata.callerIp` eine VM-IP-Adresse. Die VM-IP-Adresse kann eine interne oder eine externe IP-Adresse sein. Wenn der Aufruf aus dem internen Produktionsnetzwerk von Google stammt, ist der Wert in diesem Feld `private`. Dieser Fall tritt ein, wenn der Aufruf von einem Dienst von Cloud de Confiance by S3NS an einen anderen gesendet wird.
`request_metadata.caller_network`	Der Name des Netzwerks des Anrufers. Dieser Wert wird nur festgelegt, wenn das Hostprojekt des Netzwerks zur selben Organistation von Cloud de Confiance by S3NS oder zum selben Projekt gehört wie die aufgerufene Ressource. Weitere Informationen finden Sie unter VPC-Netzwerke.
`status`	Der allgemeine Status der Bearbeitung eines in dem Eintrag beschriebenen Vorgangs.
`metadata`	Informationen zum Verstoß gegen die Sicherheitsrichtlinie.
`metadata.resourceNames`	Die Namen der Ressourcen, die an dem im Datensatz beschriebenen Verstoß gegen die Sicherheitsrichtlinie beteiligt sind.
`metadata.dryRun`	Ein boolescher Wert, der `True` ist, wenn das Audit-Log für eine Richtlinienprüfung im Probebetrieb gilt. Weitere Informationen finden Sie unter Probelaufmodus für Dienstperimeter.
`metadata.vpcServiceControlsTroubleshootToken`	Ein Fehlerbehebungstoken, mit dem Sie den Verstoß mit dem Verstoßanalysetool (Vorschau) diagnostizieren können.
`metadata.vpcServiceControlsUniqueId`	Die eindeutige Kennzeichnung des in dem Datensatz beschriebenen VPC Service Controls-Verstoßes.
`metadata.violationReason`	Der Grund für den Verstoß. `RESOURCE_NOT_IN_SAME_SERVICE_PERIMETER` bedeutet beispielsweise, dass die Ressourcen, auf die zugegriffen wird, nicht zum selben Dienstperimeter gehören.
`metadata.securityPolicyInfo`	Der Name des Serviceperimeters, für den der Verstoß aufgetreten ist, und die eindeutige Kennung der Organisation, zu der der Perimeter gehört.
`metadata.egressViolations`	Ein Egress-Verstoß tritt in der Regel auf, wenn eine Anfrage fehlschlägt, weil die Quelle durch einen Dienstperimeter geschützt ist und sich die Zielressource außerhalb des Perimeters befindet. Die Quelle kann ein Projekt oder ein VPC-Netzwerk sein.
`metadata.ingressViolations`	Die Art des Verstoßes. Häufig tritt dieser Verstoß auf, wenn mit der Anfrage versucht wird, auf eine Zielressource zuzugreifen, die durch einen Dienstperimeter geschützt ist. Die Quelle kann entweder ein Projekt oder ein VPC-Netzwerk sein. Dieses Feld enthält eine Struktur, die den Ingress-Verstoß erklärt.
`metadata.servicePerimeter`	Der Name des Dienstperimeters, der an dem Verstoß beteiligt ist.
`metadata.source`	Dieses Feld enthält die Quelle der Anfrage, die entweder ein Projekt oder ein VPC-Netzwerk sein kann.
`metadata.targetResource`	Die Ressource, auf die sich die Anfrage bezog und die den Verstoß verursacht hat. Dieses Feld kann ein Projekt sein.
`metadata.targetResourcePermissions`	Die Liste der IAM-Berechtigungen, die für den Zugriff auf die Zielressource erforderlich sind. Um den Verstoß zu beheben, konfigurieren Sie Ingress- oder Egress-Regeln, um die IAM-Rollen mit diesen Berechtigungen zuzulassen. Wenn die erforderliche IAM-Berechtigung unbekannt ist oder von einem nicht unterstützten Dienst oder einer nicht unterstützten Methode stammt, protokolliert VPC Service Controls `vpcsc.permissions.unavailable` in diesem Feld. Sie können den `vpcsc.permissions.unavailable`-Verstoß ignorieren, sofern Sie keine IAM-Rollen in den Regeln für eingehenden oder ausgehenden Traffic verwenden. Wenn dieser Verstoß bei einer Anfrage auftritt, die gemäß IAM-Rollen durch eine Ingress- oder Egress-Regel zugelassen werden sollte, wenden Sie sich an Cloud Customer Care.
`metadata.accessLevels`	Alle übereinstimmenden Zugriffsebenen in der Organisation, die zur selben Zugriffsrichtlinie gehören. Diese Zugriffsebenen sind möglicherweise nicht im verletzten Perimeter angegeben und können daher zu einem `NO_MATCHING_ACCESS_LEVEL`-Verstoß führen.
`metadata.intermediateServices`	Die Liste der Dienste, die an der Anfragekette beteiligt sind. Dieses Feld ist bei vom Nutzer initiierten Anfragen leer.
`metadata.deviceState`	Der Status des Geräts, von dem die Anfrage stammt, wenn die Geräterichtlinie aktiviert ist. Der Standardwert für dieses Feld ist `Unknown`.

Audit-Logformat

Audit-Logeinträge umfassen folgende Komponenten:

Den Logeintrag selbst. Dabei handelt es sich um ein Objekt vom Typ LogEntry. Nützliche Felder sind unter anderem:
- logName enthält die Ressourcen-ID und den Audit-Logtyp. Die Ressource ist ein Projekt, ein Ordner, eine Organisation oder ein Rechnungskonto.
- resource enthält das Ziel zum geprüften Vorgang.
- timeStamp enthält die Uhrzeit des geprüften Vorgangs
- protoPayload enthält die geprüften Informationen
Die Audit-Logdaten, bei denen es sich um ein AuditLog-Objekt handelt, das sich im Feld protoPayload des Logeintrags befindet
- Das Feld @type ist auf "type.googleapis.com/google.cloud.audit.AuditLog" gesetzt.
- Das Feld serviceName gibt den Dienst an, der das Audit-Log geschrieben hat. Das Format dieses Felds ist dienstspezifisch.
Optionale dienstspezifische Auditinformationen. Das Objekt ist dienstspezifisch. Bei früheren Integrationen befindet sich dieses Objekt im Feld serviceData des AuditLog-Objekts. Spätere Integrationen verwenden das Feld metadata.

Informationen zu anderen Feldern in diesen Objekten sowie zu deren Interpretation finden Sie unter Audit-Logs verstehen.

Logname

Lognamen von Cloud-Audit-Logs enthalten Ressourcenkennungen, die das Projekt inCloud de Confiance oder eine andere Entität von Cloud de Confiance angeben, die der Inhaber der Audit-Logs ist. Außerdem geben sie an, ob das Log Audit-Logging-Daten zu Administratoraktivitäten, Datenzugriff, Richtlinienverstößen oder Systemereignissen enthält.

Im Folgenden finden Sie die Namen der Audit-Logs, einschließlich Variablen für die Ressourcenkennungen:

   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Factivity
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Factivity
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fpolicy

Dienstname

Für VPC Service Controls-Audit-Logs werden die Dienstnamen der Dienste verwendet, die in VPC Service Controls eingebunden sind.

Eine vollständige Liste aller Cloud Logging API-Dienstnamen und des jeweiligen überwachten Ressourcentyps finden Sie auf der Seite mit der Zuordnungstabelle für Dienste und Ressourcen.

Ressourcentypen

Für VPC Service Controls-Audit-Logs werden die Ressourcentypen verwendet, die von den Diensten unterstützt werden, die in VPC Service Controls eingebunden sind.

Eine Liste aller überwachten Cloud Logging-Ressourcentypen und beschreibende Informationen finden Sie unter Überwachte Ressourcentypen.

Aufruferidentitäten

Die IP-Adresse des Aufrufers wird im Feld RequestMetadata.caller_ip des Objekts AuditLog gespeichert. In Logging können bestimmte Aufruferidentitäten und IP-Adressen entfernt werden.

Informationen dazu, welche Informationen in Audit-Logs entfernt werden, finden Sie unter Aufruferidentitäten in Audit-Logs.

Audit-Logging aktivieren

Audit-Logs zu Administratoraktivitäten sind immer aktiviert. Sie können sie nicht deaktivieren.

Berechtigungen und Rollen

IAM-Berechtigungen und ‑Rollen bestimmen, ob Sie auf Audit-Logdaten in Cloud de Confiance -Ressourcen zugreifen können.

Berücksichtigen Sie Folgendes bei der Entscheidung, welche Logging-spezifischen Berechtigungen und Rollen für Ihren Anwendungsfall gelten:

Die Rolle „Logs Viewer“ (roles/logging.viewer) bietet Ihnen Lesezugriff auf die Audit-Logs zu Administratoraktivitäten, Richtlinienverstößen und Systemereignissen. Wenn Sie nur diese Rolle haben, können Sie keine Audit-Logs zum Datenzugriff aufrufen, die sich im Bucket _Default befinden.
Die Rolle „Private Logs Viewer“ ((roles/logging.privateLogViewer) enthält die Berechtigungen, die in roles/logging.viewer enthalten sind, sowie die Möglichkeit, Audit-Logs zum Datenzugriff im Bucket _Default zu lesen.

Wenn diese privaten Logs in benutzerdefinierten Buckets gespeichert sind, kann jeder Nutzer, der Berechtigungen zum Lesen von Logs in diesen Buckets hat, die privaten Logs lesen. Weitere Informationen zu Log-Buckets finden Sie auf der Seite zum Routing und zur Speicherung.

Weitere Informationen zu den IAM-Berechtigungen und ‑Rollen für Audit-Logdaten finden Sie unter Zugriffssteuerung mit IAM.

Logs ansehen

Sie können alle Audit-Logs oder Audit-Lognamen abfragen. Der Audit-Logname enthält die Ressourcenkennung des Projekts, Ordners, Rechnungskontos oder der Organisation in Cloud de Confiance , für die Sie Audit-Logging-Informationen aufrufen möchten. In Ihren Abfragen können Sie indexierte Felder des Typs LogEntry angeben. Weitere Informationen zum Abfragen von Logs finden Sie auf der Seite zum Erstellen von Abfragen im Log-Explorer.

Die meisten Audit-Logs können in Cloud Logging über dieCloud de Confiance Console, die Google Cloud CLI oder die Logging API aufgerufen werden. Für Audit-Logs im Zusammenhang mit der Abrechnung können Sie jedoch nur die Google Cloud CLI oder die Logging API verwenden.

Console

In der Cloud de Confiance Console können Sie mit dem Log-Explorer die Audit-Logeinträge für Ihr Projekt, Ihren Ordner oder Ihre Organisation in Cloud de Confiance abrufen:

Rufen Sie in der Cloud de Confiance Console die Seite Log-Explorer auf:
Zum Log-Explorer

Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.
Wählen Sie ein vorhandenes Projekt, einen Ordner oder eine Organisation in Cloud de Confiance aus.
Wenn Sie alle Audit-Logs aufrufen möchten, geben Sie eine der folgenden Abfragen in das Feld des Abfrageeditors ein und klicken Sie dann auf Abfrage ausführen:
```
logName:"cloudaudit.googleapis.com"
```
```
protoPayload."@type"="type.googleapis.com/google.cloud.audit.AuditLog"
```
So rufen Sie im Bereich Query Builder die Audit-Logs für eine bestimmte Ressource und einen bestimmten Typ von Audit-Log auf:
- Wählen Sie unter Ressourcentyp die Cloud de Confiance -Ressource aus, deren Audit-Logs angezeigt werden sollen.
- Wählen Sie unter Logname den Audit-Logtyp aus, den Sie sehen möchten:
  - Wählen Sie für Audit-Logs zu Administratoraktivitäten die Option activity aus.
  - Wählen Sie für Audit-Logs zum Datenzugriff die Option data_access aus.
  - Wählen Sie für Audit-Logs zu Systemereignissen die Option system_event aus.
  - Wählen Sie für Audit-Logs zu Richtlinienverstößen die Option policy aus.
- Klicken Sie auf Abfrage ausführen.
Wenn diese Optionen nicht angezeigt werden, sind im Projekt, im Ordner oder in der Organisation in Cloud de Confiance keine Audit-Logs dieses Typs verfügbar.

Wenn beim Aufrufen von Logs im Log-Explorer Probleme auftreten, lesen Sie die Informationen zur Fehlerbehebung.

Weitere Informationen zu Abfragen mit dem Log-Explorer finden Sie auf der Seite zum Erstellen von Abfragen im Log-Explorer.

gcloud

Die Google Cloud CLI bietet eine Befehlszeile für die Logging API. Geben Sie in jedem Lognamen eine gültige Ressourcenkennung an. Wenn die Abfrage beispielsweise eine PROJECT_ID enthält, muss sich die von Ihnen angegebene Projekt-ID auf das aktuell inCloud de Confiance ausgewählte Projekt beziehen.

Führen Sie den folgenden Befehl aus, um Audit-Logeinträge auf Ebene des Projekts in Cloud de Confiance zu lesen:

gcloud logging read "logName : projects/PROJECT_ID/logs/cloudaudit.googleapis.com" \
    --project=PROJECT_ID

Führen Sie den folgenden Befehl aus, um Audit-Logeinträge auf Ordnerebene zu lesen:

gcloud logging read "logName : folders/FOLDER_ID/logs/cloudaudit.googleapis.com" \
    --folder=FOLDER_ID

Führen Sie den folgenden Befehl aus, um Audit-Logeinträge auf Organisationsebene zu lesen:

gcloud logging read "logName : organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com" \
    --organization=ORGANIZATION_ID

Führen Sie den folgenden Befehl aus, um Audit-Logeinträge auf Cloud-Rechnungskontoebene zu lesen:

gcloud logging read "logName : billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com" \
    --billing-account=BILLING_ACCOUNT_ID

Fügen Sie Ihrem Befehl das Flag --freshness hinzu, um Logs zu lesen, die mehr als einen Tag alt sind.

Weitere Informationen zur Verwendung der gcloud CLI finden Sie unter gcloud logging read.

REST

Wenn Sie Ihre Logdaten mit der Cloud Logging API abfragen möchten, verwenden Sie die Methode entries.list.

Beispielabfragen

So verwenden Sie die Beispielabfragen in der folgenden Tabelle:

Ersetzen Sie die Variablen im Abfrageausdruck durch Ihre eigenen Projektinformationen und kopieren Sie den Ausdruck dann mit dem Symbol der Zwischenablage .
Rufen Sie in der Cloud de Confiance Console die Seite Log-Explorer auf:
Zum Log-Explorer

Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.
Aktivieren Sie Abfrage anzeigen, um das Feld „Query Editor” zu öffnen, und fügen Sie den Ausdruck dann in das Feld des Query Editor ein:
Klicken Sie auf Abfrage ausführen. Logs, die Ihrer Abfrage entsprechen, werden im Bereich Abfrageergebnisse aufgeführt.

Verwenden Sie die folgenden Abfragen im Log-Explorer, um Audit-Logs für VPC Service Controls zu finden:

Beschreibung der Abfrage	Ausdruck
Details zum Verstoß basierend auf einer Ablehnungs-ID	log_id("cloudaudit.googleapis.com/policy") severity=ERROR resource.type="audited_resource" protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata" protoPayload.metadata.vpcServiceControlsUniqueId="`UNIQUE_ID`" Ersetzen Sie `UNIQUE_ID` durch die eindeutige ID der Ablehnung.
Verstöße für eine IP-Adresse	log_id("cloudaudit.googleapis.com/policy") severity=ERROR resource.type="audited_resource" protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata" protoPayload.requestMetadata.callerIp="`IP_ADDRESS`" Ersetzen Sie `IP_ADDRESS` durch die IP-Adresse des Anrufers.
Verstöße für einen Dienst	log_id("cloudaudit.googleapis.com/policy") severity=ERROR resource.type="audited_resource" protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata" protoPayload.serviceName="`SERVICE_NAME`" Ersetzen Sie `SERVICE_NAME` durch den Namen des eingeschränkten Dienstes.
Änderung der Zugriffsebene an einem Perimeter	logName="organizations/`ORGANIZATION_ID`/logs/cloudaudit.googleapis.com%2Factivity" severity=NOTICE protoPayload.serviceName="accesscontextmanager.googleapis.com" protoPayload.methodName="google.identity.accesscontextmanager.v1.AccessContextManager.UpdateServicePerimeter" -protoPayload.metadata.previousState:"`ACCESS_LEVEL`" protoPayload.request.servicePerimeter.status.accessLevels:"`ACCESS_LEVEL`" Ersetzen Sie `ORGANIZATION_ID` durch die numerische ID Ihrer Organisation und `ACCESS_LEVEL` durch den eindeutigen Namen der Zugriffsebene.
CRUD-Vorgänge für Perimeter	logName="organizations/`ORGANIZATION_ID`/logs/cloudaudit.googleapis.com%2Factivity" severity=NOTICE protoPayload.serviceName="accesscontextmanager.googleapis.com" protoPayload.methodName=~"google.identity.accesscontextmanager.v1.AccessContextManager.ServicePerimeter" protoPayload.request.servicePerimeter.name=~".`PERIMETER_NAME`$" Ersetzen Sie `PERIMETER_NAME` durch den Namen des Perimeters..
CRUD-Vorgänge für Zugriffsebenen	logName="organizations/`ORGANIZATION_ID`/logs/cloudaudit.googleapis.com%2Factivity" severity=NOTICE protoPayload.serviceName="accesscontextmanager.googleapis.com" protoPayload.methodName=~"google.identity.accesscontextmanager.v1.AccessContextManager.AccessLevel" protoPayload.request.accessLevel.name=~".`ACCESS_LEVEL`$"
Vorgänge für Regeln für eingehenden Traffic erstellen und aktualisieren	logName="organizations/`ORGANIZATION_ID`/logs/cloudaudit.googleapis.com%2Factivity" protoPayload.serviceName="accesscontextmanager.googleapis.com" protoPayload.methodName=~"google.identity.accesscontextmanager.v1.AccessContextManager.ServicePerimeter" protoPayload.request.servicePerimeter.status.ingressPolicies:""
Vorgänge für Regeln für ausgehenden Traffic erstellen und aktualisieren	logName="organizations/`ORGANIZATION_ID`/logs/cloudaudit.googleapis.com%2Factivity" protoPayload.serviceName="accesscontextmanager.googleapis.com" protoPayload.methodName=~"google.identity.accesscontextmanager.v1.AccessContextManager.ServicePerimeter" protoPayload.request.servicePerimeter.status.egressPolicies:""

Audit-Logs weiterleiten

Sie können Audit-Logs auf dieselbe Weise wie andere Arten von Logs an unterstützte Ziele weiterleiten. Im Folgenden erfahren Sie, warum es sinnvoll sein kann, Audit-Logs weiterzuleiten:

Sie können Kopien von Audit-Logs zu Cloud Storage, BigQuery oder Pub/Sub weiterleiten, um Audit-Logs länger zu behalten oder leistungsfähigere Suchfunktionen zu nutzen. Mit Pub/Sub haben Sie die Möglichkeit, die Logs zu anderen Anwendungen, anderen Repositories und Systemen von Drittanbietern weiterzuleiten.
Zum Verwalten der Audit-Logs einer gesamten Organisation können Sie aggregierte Senken erstellen, mit denen sich Logs aus beliebigen oder allen Projekten der Organisation in Cloud de Confiance weiterleiten lassen.

Eine Anleitung zum Weiterleiten von Logs finden Sie unter Logs an unterstützte Ziele weiterleiten.