Amazon S3 CloudTrail-Ereignisse
Wichtig
Amazon S3 wendet jetzt serverseitige Verschlüsselung mit von Amazon S3 verwalteten Verschlüsselungsschlüssel (SSE-S3) als Basisverschlüsselung für jeden Bucket in Amazon S3 an. Ab dem 5. Januar 2023 werden alle neuen Objekt-Uploads auf Amazon S3 ohne zusätzliche Kosten und ohne Auswirkungen auf die Leistung automatisch verschlüsselt. Der Status der automatischen Verschlüsselung für die Standardverschlüsselungskonfiguration von S3-Buckets und für neue Objekt-Uploads ist in AWS CloudTrail-Protokollen, S3 Inventory, S3 Storage Lens, der Amazon-S3-Konsole und als zusätzlicher Amazon-S3-API-Antwortheader in der AWS Command Line Interface und den AWS-SDKs verfügbar. Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Standardverschlüsselung.
Dieser Abschnitt enthält Informationen zu den Ereignissen, die S3 in CloudTrail protokolliert.
Amazon-S3-Datenereignisse in CloudTrail
Datenereignisse liefern Informationen über die Ressourcenoperationen, die auf oder in einer Ressource ausgeführt werden (z. B. Lesen oder Schreiben in ein Amazon-S3-Objekt). Sie werden auch als Vorgänge auf der Datenebene bezeichnet. Datenereignisse sind oft Aktivitäten mit hohem Volume. Standardmäßig protokolliert CloudTrail keine Datenereignisse. Der CloudTrail-Ereignisverlauf zeichnet keine Datenereignisse auf.
Für Datenereignisse werden zusätzliche Gebühren fällig. Weitere Informationen zu CloudTrail-Preisen finden Sie unter AWS CloudTrail – Preise
Sie können Datenereignisse für die Amazon-S3-Ressourcentypen mithilfe der CloudTrail-Konsole, AWS CLI oder CloudTrail-API-Operationen protokollieren. Weitere Informationen zum Protokollieren von Datenereignissen finden Sie unter Protokollieren von Datenereignissen mit dem AWS-Managementkonsole und Protokollieren von Datenereignissen mit dem AWS Command Line Interface im AWS CloudTrail-Benutzerhandbuch.
In der folgenden Tabelle sind die Amazon-S3-Ressourcentypen aufgeführt, für die Sie Datenereignisse protokollieren können. In der Spalte Datenereignistyp (Konsole) wird der Wert angezeigt, der in der CloudTrail-Konsole aus der Liste Datenereignistyp ausgewählt werden kann. In der Wertspalte resources.type wird der resources.type Wert angezeigt, den Sie angeben würden, wenn Sie erweiterte Event-Selektoren mithilfe der APIs AWS CLI oder CloudTrail konfigurieren würden. In der Spalte Daten-APIs, die in CloudTrail protokolliert wurden, werden die API-Aufrufe angezeigt, die für den Ressourcentyp in CloudTrail protokolliert wurden.
| Typ des Datenereignisses (Konsole) | resources.type-Wert | Bei CloudTrail protokollierte Daten-APIs |
|---|---|---|
| S3 |
AWS::S3::Object
|
|
| S3 Express One Zone |
|
|
| S3-Zugangspunkt |
AWS::S3::Access Point
|
|
| S3 Object Lambda |
AWS::S3ObjectLambda::AccessPoint
|
|
| S3-Outposts |
AWS::S3Outposts::Object
|
Sie können erweiterte Event-Selektoren so konfigurieren, dass sie nach den Feldern eventName, readOnly und resources.ARN filtern, sodass nur die Ereignisse protokolliert werden, die für Sie wichtig sind. Weitere Informationen zu diesen Kontingenten finden Sie unter AdvancedFieldSelector in derAWS CloudTrail-API-Referenz.
Amazon-S3-Verwaltungsereignisse in CloudTrail
Amazon S3 protokolliert alle Operationen auf der Steuerebene als Verwaltungsereignisse. Weitere Informationen zu S3-API-Operationen finden Sie in der Amazon-S3-API-Referenz.
Wie CloudTrail Anfragen an Amazon S3 erfasst
Standardmäßig protokolliert CloudTrail API-Aufrufe auf S3-Bucket-Ebene für die letzten 90 Tage, aber keine an Objekte gerichteten Anforderungen. Aufrufe auf Bucket-Ebene sind Ereignisse wie CreateBucket, DeleteBucket, PutBucketLifecycle, PutBucketPolicy usw. Sie können Ereignisse auf Bucket-Ebene auf der CloudTrail-Konsole anzeigen. Sie können dort jedoch keine Datenereignisse (Aufrufe auf Amazon-S3-Objektebene) anzeigen – Sie müssen für diese CloudTrail-Protokolle analysieren oder abfragen.
Wenn Sie Datenaktivitäten mit AWS CloudTrail protokollieren, umfasst der Ereignisdatensatz für ein Amazon S3-DeleteObjects-Datenereignis sowohl das DeleteObjects-Ereignis als auch ein DeleteObject-Ereignis für jedes Objekt, das im Rahmen dieses Vorgangs gelöscht wurde. Sie können die zusätzliche Sichtbarkeit gelöschter Objekte aus dem Ereignisdatensatz ausschließen. Weitere Informationen finden Sie unter AWS CLIProtokollieren von Datenereignissen für Trails im AWS CloudTrail-Benutzerhandbuch.
Aktionen auf Amazon-S3-Kontoebene, die durch CloudTrail-Protokollierung verfolgt werden
CloudTrail protokolliert Aktionen auf Kontoebene. Amazon-S3-Datensätze werden zusammen mit anderen AWS-Service-Datensätzen in einer Protokolldatei erfasst. Anhand eines Zeitraums und der Dateigröße bestimmt CloudTrail, wann diese Informationen in eine neue erstellte Protokolldatei geschrieben werden sollen.
Die Tabellen in diesem Abschnitt listen die Amazon-S3-Aktionen auf Kontoebene auf, die für die Protokollierung durch CloudTrail unterstützt werden.
Amazon-S3-API-Aktionen auf Kontoebene, die durch CloudTrail-Protokollierung nachverfolgt werden, werden als folgende Ereignisnamen angezeigt. Der CloudTrail-Ereignisname unterscheidet sich vom API-Aktionsnamen. Beispiel: DeletePublicAccessBlock ist DeleteAccountPublicAccessBlock.
Amazon-S3-Aktionen auf Bucket-Ebene, die durch die CloudTrail-Protokollierung verfolgt werden
Standardmäßig protokolliert CloudTrail Aktionen für Buckets für allgemeine Zwecke auf Bucket-Ebene. Amazon-S3-Datensätze werden zusammen mit anderen AWS-Service-Datensätzen in einer Protokolldatei erfasst. Anhand eines Zeitraums und der Dateigröße bestimmt CloudTrail, wann diese Informationen in eine neue erstellte Protokolldatei geschrieben werden sollen.
In diesem Abschnitt werden die Amazon-S3-Aktionen auf Bucket-Ebene aufgelistet, die für die Protokollierung durch CloudTrail unterstützt werden.
Amazon-S3-API-Aktionen auf Bucket-Ebene, die durch CloudTrail-Protokollierung nachverfolgt werden, werden als folgende Ereignisnamen angezeigt. In einigen Fällen unterscheidet sich der CloudTrail-Ereignisname vom API-Aktionsnamen. Zum Beispiel, PutBucketLifecycleConfiguration ist PutBucketLifecycle.
-
CreateBucketMetadataConfiguration (V2-API-Betrieb)
-
CreateBucketMetadataTableConfiguration (V1-API-Betrieb)
-
DeleteBucketMetadataConfiguration (V2-API-Betrieb)
-
DeleteBucketMetadataTableConfiguration (V1-API-Betrieb)
-
GetBucketMetadataConfiguration (V2-API-Betrieb)
-
GetBucketMetadataTableConfiguration (V1-API-Betrieb)
Zusätzlich zu diesen API-Operationen können Sie auch die Objektebenenaktion OPTIONS-Objekt verwenden. Diese Aktion wird von der CloudTrail-Protokollierung als Aktion auf Bucket-Ebene behandelt, weil die Aktion die CORS-Konfiguration eines Buckets überprüft.
S3-Express-One-Zone-Aktionen auf Bucket-Ebene (regionaler API-Endpunkt), die durch CloudTrail-Protokollierung verfolgt werden
Standardmäßig protokolliert CloudTrail Aktionen auf Bucket-Ebene für Verzeichnis-Buckets als Verwaltungsereignisse. Die eventsource für CloudTrail-Verwaltungsereignisse für S3 Express One Zone ist s3express.amazonaws.com.
Die folgenden regionalen Endpunkt-API-Operationen werden in CloudTrail protokolliert.
Weitere Informationen finden Sie unter Protokollierung mit AWS CloudTrail für S3 Express One Zone.
Amazon-S3-Aktionen auf Objektebene in kontoübergreifenden Szenarios
Nachfolgend sind spezielle Anwendungsfälle beschrieben, die API-Aufrufe auf Objektebene in kontenübergreifenden Szenarien enthalten. Außerdem wird beschrieben, wie CloudTrail-Protokolle gemeldet werden. CloudTrail sendet Protokolle an den Anforderer (das Konto, das den API-Aufruf getätigt hat), außer in einigen Fällen, in denen der Zugriff verweigert wurde, in denen Protokolleinträge geschwärzt oder weggelassen werden. Bei der Einrichtung von kontoübergreifendem Zugriff sehen Sie sich die Beispiele in diesem Abschnitt an.
Anmerkung
Die Beispiele setzen voraus, dass die CloudTrail-Protokolle ordnungsgemäß konfiguriert sind.
Beispiel 1: CloudTrail sendet Protokolle an den Bucket-Eigentümer
CloudTrail sendet Zugriffsprotokolle nur dann an den Bucket-Eigentümer, wenn der Bucket-Eigentümer keine Berechtigungen für die entsprechende Objekt-API-Operation besitzt. Sehen Sie sich das folgende kontenübergreifende Szenario vor:
-
Konto A ist Eigentümer des Buckets.
-
Konto B (Anforderer) versucht, auf ein Objekt in diesem Bucket zuzugreifen.
-
Konto C besitzt das Objekt. Konto C kann dasselbe Konto wie Konto A sein oder auch nicht.
Anmerkung
CloudTrail sendet die API-Protokolle auf Objektebene immer an den Anforderer (Konto B). Darüber hinaus sendet CloudTrail diese Protokolle nur dann an den Bucket-Eigentümer (Konto A), wenn der Bucket-Eigentümer das Objekt nicht besitzt oder keine Berechtigungen für die entsprechenden API-Aktionen für dieses Objekt besitzt.
Beispiel 2: CloudTrail gibt keine E-Mail-Adressen weiter, die bei der Einrichtung von Objekt-ACLs verwendet werden
Sehen Sie sich das folgende kontenübergreifende Szenario vor:
-
Konto A ist Eigentümer des Buckets.
-
Konto B (Anforderer) sendet eine Anforderung, um eine ACL-Erteilung für ein Objekt unter Verwendung einer E-Mail-Adresse einzurichten. Weitere Informationen über ACLs finden Sie in Zugriffskontrolllisten (ACL) – Übersicht.
Der Anforderer erhält die Protokolle zusammen mit der E-Mail-Information. Der Bucket-Eigentümer erhält jedoch das CloudTrail-Protokoll, das das Ereignis meldet – falls er berechtigt ist, Protokolle zu erhalten, wie in Beispiel 1 Der Bucket-Eigentümer erhält jedoch keine Informationen über die ACL-Konfiguration, insbesondere die E-Mail des Empfängers und die Erteilung. Die einzige Information, die das Protokoll dem Bucket-Eigentümer mitteilt, ist, dass Konto B einen ACL-API-Aufruf vorgenommen hat.