Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Kontoübergreifende, regionsübergreifende Abonnements
Sie können mit einem Inhaber eines anderen AWS Kontos zusammenarbeiten und dessen Protokollereignisse auf Ihren AWS Ressourcen empfangen, z. B. in einem Amazon Kinesis- oder Amazon Data Firehose (dies wird als kontoübergreifender Datenaustausch bezeichnet). Diese Protokollereignisdaten können beispielsweise aus einem zentralisierten Amazon Kinesis Data Streams oder Firehose-Stream gelesen werden, um eine benutzerdefinierte Verarbeitung und Analyse durchzuführen. Benutzerdefinierte Verarbeitung ist besonders nützlich, wenn Sie über viele Konten zusammenarbeiten und Daten analysieren.
Wenn beispielsweise die IT-Sicherheitsgruppe eines Unternehmens Daten zur Echtzeit-Erkennung von Eindringversuchen oder auf Unregelmäßigkeiten analysieren möchten, kann sie eine Prüfung aller Konten in allen Abteilungen des Unternehmens durchführen und dabei alle Produktionsprotokolle für eine zentrale Verarbeitung erfassen. Ein Echtzeit-Stream von Ereignisdaten für diese Konten kann zusammengestellt und an die Informationssicherheitsgruppen übermittelt werden, die Amazon Kinesis Data Streams verwenden können, um die Daten an ihre bestehenden Sicherheitsanalysesysteme anzuhängen.
**Anmerkung**
Die Protokollgruppe und das Ziel müssen sich in derselben AWS Region befinden. Die AWS -Ressource, auf die das Ziel verweist, kann sich jedoch in einer anderen Region befinden. In den Beispielen in den folgenden Abschnitten werden alle regionsspezifischen Ressourcen in USA Ost (Nord-Virginia) erstellt.
Wenn Sie Mitgliedskonten konfiguriert haben AWS Organizations und mit ihnen arbeiten, können Sie die Protokollzentralisierung verwenden, um Protokolldaten von Quellkonten in einem zentralen Überwachungskonto zu sammeln.
Wenn Sie mit zentralisierten Protokollgruppen arbeiten, können Sie beim Erstellen von Abonnementfiltern die folgenden Systemfelddimensionen verwenden:
+ `@aws.account`- Diese Dimension stellt die AWS Konto-ID dar, von der das Protokollereignis ausgegangen ist.
+ `@aws.region`- Diese Dimension stellt die AWS Region dar, in der das Protokollereignis generiert wurde.
Diese Dimensionen helfen bei der Identifizierung der Quelle der Protokolldaten und ermöglichen so eine detailliertere Filterung und Analyse von Metriken, die aus zentralisierten Protokollen stammen.
**Topics**
+ [Kontoübergreifender regionsübergreifender Austausch von Protokolldaten mithilfe von Amazon Kinesis Data Streams](CrossAccountSubscriptions-Kinesis.md)
+ [Kontoübergreifender regionsübergreifender Austausch von Protokolldaten mit Firehose](CrossAccountSubscriptions-Firehose.md)
+ [Kontoübergreifende, regionsübergreifende Abonnements auf Kontoebene mit Amazon Kinesis Data Streams](CrossAccountSubscriptions-Kinesis-Account.md)
+ [Kontoübergreifende, regionsübergreifende Abonnements auf Kontoebene mit Firehose](CrossAccountSubscriptions-Firehose-Account.md)
# Kontoübergreifender regionsübergreifender Austausch von Protokolldaten mithilfe von Amazon Kinesis Data Streams
Wenn Sie ein kontoübergreifendes Abonnement erstellen, können Sie ein einzelnes Konto oder eine Organisation angeben, die der Sender sein soll. Wenn Sie eine Organisation angeben, können alle Konten in der Organisation mit diesem Verfahren Protokolle an das Receiver-Konto senden.
Wenn Sie Protokolldaten für mehrere Konten freigeben möchten, müssen Sie Sender und Receiver der Protokolldaten festlegen:
+ **Absender der Protokolldaten** — Ruft die Zielinformationen vom Empfänger ab und teilt Logs mit, dass CloudWatch Logs bereit ist, seine Protokollereignisse an das angegebene Ziel zu senden. In den Verfahren im Rest dieses Abschnitts wird der Absender der Protokolldaten mit der fiktiven AWS Kontonummer 1111111111 angezeigt.
Wenn mehrere Konten in einer Organisation Protokolle an ein Empfängerkonto senden, können Sie eine Richtlinie erstellen, die allen Konten in der Organisation die Berechtigung zum Senden von Protokollen an das Empfängerkonto gewährt. Sie müssen immer noch separate Abonnementfilter für jedes Senderkonto einrichten.
+ **Empfänger von Protokolldaten** — richtet ein Ziel ein, das einen Amazon Kinesis Data Streams Streams-Stream kapselt und CloudWatch Logs darüber informiert, dass der Empfänger Protokolldaten empfangen möchte. Der Empfänger gibt dann die Informationen über sein Ziel für den Absender frei. In den Verfahren im Rest dieses Abschnitts wird der Empfänger der Protokolldaten mit der fiktiven AWS Kontonummer 999999999999 angezeigt.
Um Protokollereignisse von kontoübergreifenden Benutzern zu empfangen, erstellt der Empfänger der Protokolldaten zunächst ein Protokollziel. CloudWatch Jedes Ziel umfasst die folgenden Schlüsselelemente:
**Name des Ziels**
Der Name der Zielregion, die Sie erstellen möchten.
**Ziel-ARN**
Der Amazon-Ressourcenname (ARN) der AWS Ressource, die Sie als Ziel für den Abonnement-Feed verwenden möchten.
**ARN der Rolle**
Eine AWS Identity and Access Management (IAM) -Rolle, die CloudWatch Logs die erforderlichen Berechtigungen erteilt, um Daten in den ausgewählten Stream zu übertragen.
**Zugriffsrichtlinie**
Ein IAM-Richtliniendokument (im JSON-Format, das in der IAM-Richtliniengrammatik geschrieben ist), das kontrolliert, welche Benutzer Schreibberechtigung für das Ziel haben.
**Anmerkung**
Die Protokollgruppe und das Ziel müssen sich in derselben AWS Region befinden. Die AWS Ressource, auf die das Ziel verweist, kann sich jedoch in einer anderen Region befinden. In den Beispielen in den folgenden Abschnitten werden alle regionsspezifischen Ressourcen in USA Ost (Nord-Virginia) erstellt.
**Topics**
+ [Einrichten eines neuen kontoübergreifenden Abonnements](Cross-Account-Log_Subscription-New.md)
+ [Aktualisieren eines bestehenden kontoübergreifenden Abonnements](Cross-Account-Log_Subscription-Update.md)
# Einrichten eines neuen kontoübergreifenden Abonnements
Befolgen Sie die Schritte in diesen Abschnitten, um ein neues kontoübergreifendes Protokollabonnement einzurichten.
**Topics**
+ [Schritt 1: Erstellen eines Ziels](CreateDestination.md)
+ [Schritt 2: (Nur bei Verwendung einer Organisation) Erstellen Sie eine IAM-Rolle](CreateSubscriptionFilter-IAMrole.md)
+ [Schritt 3: Add/validate IAM-Berechtigungen für das kontoübergreifende Ziel](Subscription-Filter-CrossAccount-Permissions.md)
+ [Schritt 4: Erstellen eines Abonnementfilters](CreateSubscriptionFilter.md)
+ [Validierung des Ablaufs von Protokollereignissen](ValidateLogEventFlow.md)
+ [Ändern der Mitgliedschaft im Ziel zur Laufzeit](ModifyDestinationMembership.md)
# Schritt 1: Erstellen eines Ziels
**Wichtig**
Alle Schritte in diesem Verfahren müssen im Konto des Protokolldatenempfängers ausgeführt werden.
In diesem Beispiel hat das Konto des Empfängers der Protokolldaten die Konto-ID 9999999999, während die AWS Konto-ID des Absenders der Protokolldaten 1111111111 lautet. AWS
In diesem Beispiel wird ein Ziel mithilfe eines Amazon Kinesis Data Streams-Streams namens und einer Rolle erstellt RecipientStream, die es CloudWatch Logs ermöglicht, Daten darauf zu schreiben.
Wenn das Ziel erstellt ist, sendet CloudWatch Logs im Namen des Empfängerkontos eine Testnachricht an das Ziel. Wenn der Abonnementfilter später aktiv ist, sendet CloudWatch Logs im Namen des Quellkontos Protokollereignisse an das Ziel.
**So erstellen Sie ein Ziel**
1. Erstellen Sie im Empfängerkonto einen Ziel-Stream in Amazon Kinesis Data Streams. Geben Sie an der Eingabeaufforderung Folgendes ein:
```
aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
```
1. Warten Sie, bis der -Stream aktiv wird. **Sie können den Befehl **aws kinesis describe-stream** verwenden, um das zu überprüfen. StreamDescription StreamStatus**Eigentum. Notieren Sie sich außerdem den Wert **StreamDescription.streamArn,** da Sie ihn später an Logs übergeben werden: CloudWatch
```
aws kinesis describe-stream --stream-name "RecipientStream"
{
"StreamDescription": {
"StreamStatus": "ACTIVE",
"StreamName": "RecipientStream",
"StreamARN": "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream",
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"EndingHashKey": "34028236692093846346337460743176EXAMPLE",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber": "4955113521868881845667950383198145878459135270218EXAMPLE"
}
}
]
}
}
```
Es kann einige Minuten dauern, bis der Stream im aktiven Status angezeigt wird.
1. Erstellen Sie die IAM-Rolle, die CloudWatch Logs die Berechtigung erteilt, Daten in Ihren Stream einzufügen. Zunächst müssen Sie eine Vertrauensrichtlinie in einer Datei **\$1/ TrustPolicyFor** CWL.json erstellen. Erstellen Sie in einem Text-Editor die Richtliniendatei, verwenden Sie nicht die IAM-Konsole.
Diese Richtlinie enthält einen globalen Bedingungskontextschlüssel `aws:SourceArn`, der das `sourceAccountId` angibt, um das Confused-Deputy-Problem zu vermeiden. Wenn Sie die Quell-Kontonummer beim ersten Aufruf noch nicht kennen, empfehlen wir Ihnen, die Ziel-ARN in das Quell-ARN-Feld einzutragen. Bei den folgenden Aufrufen sollten Sie als Quell-ARN den tatsächlichen Quell-ARN angeben, den Sie beim ersten Aufruf ermittelt haben. Weitere Informationen finden Sie unter [Confused-Deputy-Prävention](Subscriptions-confused-deputy.md).
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Action": "sts:AssumeRole"
}
}
```
1. Verwenden Sie den Befehl **aws iam create-role**, um die IAM-Rolle zu erstellen und die Vertrauensrichtlinie anzugeben. Notieren Sie sich den zurückgegebenen Role.Arn-Wert, da er später auch an Logs übergeben wird: CloudWatch
```
aws iam create-role \
--role-name CWLtoKinesisRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Principal": {
"Service": "logs.amazonaws.com"
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisRole",
"Path": "/",
"Arn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
}
}
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um zu definieren, welche Aktionen CloudWatch Logs auf Ihrem Konto ausführen kann. Verwenden Sie zunächst einen Texteditor, um eine Berechtigungsrichtlinie in einer Datei **\$1/ PermissionsFor CWL.json** zu erstellen:
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
}
]
}
```
1. **Ordnen Sie die Berechtigungsrichtlinie der Rolle zu, indem Sie den Befehl aws iam verwenden: put-role-policy**
```
aws iam put-role-policy \
--role-name CWLtoKinesisRole \
--policy-name Permissions-Policy-For-CWL \
--policy-document file://~/PermissionsForCWL.json
```
1. Nachdem sich der Stream im aktiven Status befindet und Sie die IAM-Rolle erstellt haben, können Sie das CloudWatch Logs-Ziel erstellen.
1. In diesem Schritt wird keine Zugriffsrichtlinie mit Ihrem Ziel verknüpft. Es ist zudem erst der erste von zwei Schritten zum Erstellen eines Ziels. Notieren Sie sich den in der Nutzlast ausgegebenen Wert **DestinationArn**:
```
aws logs put-destination \
--destination-name "testDestination" \
--target-arn "arn:aws:kinesis:region:999999999999:stream/RecipientStream" \
--role-arn "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
{
"DestinationName" : "testDestination",
"RoleArn" : "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
"DestinationArn" : "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"TargetArn" : "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream"
}
```
1. Verknüpfen Sie, nachdem Schritt 7a abgeschlossen ist, im Empfängerkonto der Protokolldaten eine Zugriffsrichtlinie mit dem Ziel. Diese Richtlinie muss die PutSubscriptionFilter Aktion **logs:** spezifizieren und erteilt dem Absenderkonto die Erlaubnis, auf das Ziel zuzugreifen.
Die Richtlinie erteilt dem AWS Konto, das Protokolle sendet, die entsprechenden Berechtigungen. Sie können nur dieses eine Konto in der Richtlinie angeben, oder wenn das Senderkonto Mitglied einer Organisation ist, kann die Richtlinie die Organisations-ID der Organisation angeben. Auf diese Weise können Sie nur eine Richtlinie erstellen, mit der mehrere Konten in einer Organisation Protokolle an dieses Zielkonto senden können.
Verwenden Sie einen Texteditor, um eine Datei mit dem Namen `~/AccessPolicy.json` mit einer der folgenden Richtlinienanweisungen zu erstellen.
Diese erste Beispielrichtlinie ermöglicht es allen Konten in der Organisation, die die ID `o-1234567890` haben, Protokolle an das Empfängerkonto zu senden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": "logs:PutSubscriptionFilter",
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-1234567890"
]
}
}
}
]
}
```
------
In diesem nächsten Beispiel kann nur das Protokolldatenabsenderkonto (111111111111) Protokolle an das Protokolldatenempfängerkonto senden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "111111111111"
},
"Action": "logs:PutSubscriptionFilter",
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
}
]
}
```
------
1. Fügen Sie die Richtlinie, die Sie im vorherigen Schritt erstellt haben, dem Ziel an.
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/AccessPolicy.json
```
Diese Zugriffsrichtlinie ermöglicht es Benutzern im AWS Konto mit der ID 111111111111, **PutSubscriptionFilter**gegen das Ziel mit ARN arn:aws:logs ::999999999999:destination:TestDestination anzurufen. *region* Jeder Versuch PutSubscriptionFilter eines anderen Benutzers, für dieses Ziel anzurufen, wird abgewiesen.
Informationen dazu, wie Sie die Berechtigungen eines Benutzers mit einer Zugriffsrichtlinie prüfen, finden Sie unter [Verwenden der Richtlinienvalidierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html) im *IAM-Benutzerhandbuch*.
Wenn Sie fertig sind und AWS Organizations für Ihre kontoübergreifenden Berechtigungen verwenden, folgen Sie den Schritten unter[Schritt 2: (Nur bei Verwendung einer Organisation) Erstellen Sie eine IAM-Rolle](CreateSubscriptionFilter-IAMrole.md). Wenn Sie dem anderen Konto Berechtigungen direkt erteilen, anstatt Organizations zu verwenden, können Sie diesen Schritt überspringen und mit fortfahren [Schritt 4: Erstellen eines Abonnementfilters](CreateSubscriptionFilter.md).
# Schritt 2: (Nur bei Verwendung einer Organisation) Erstellen Sie eine IAM-Rolle
Wenn Sie im vorherigen Abschnitt das Ziel mithilfe einer Zugriffsrichtlinie erstellt haben, die der Organisation, in der sich Konto `111111111111` befindet, Berechtigungen erteilt, anstatt Konto `111111111111` direkt Berechtigungen zu erteilen, führen Sie die Schritte in diesem Abschnitt aus. Andernfalls können Sie mit [Schritt 4: Erstellen eines Abonnementfilters](CreateSubscriptionFilter.md) fortfahren.
Mit den Schritten in diesem Abschnitt wird eine IAM-Rolle erstellt, die davon ausgehen und überprüfen CloudWatch kann, ob das Absenderkonto berechtigt ist, einen Abonnementfilter für das Empfängerziel zu erstellen.
Führen Sie die Schritte in diesem Abschnitt im Sender-Konto aus. Die Rolle muss im Sender-Konto vorhanden sein, und Sie geben den ARN dieser Rolle im Abonnementfilter an. In diesem Beispiel ist das Sender-Konto `111111111111`.
**Um die IAM-Rolle zu erstellen, die für kontoübergreifende Protokollabonnements erforderlich ist, verwenden Sie AWS Organizations**
1. Erstellen Sie die folgende Vertrauensrichtlinie in einer Datei namens `/TrustPolicyForCWLSubscriptionFilter.json`. Erstellen Sie in einem Text-Editor die Richtliniendatei, verwenden Sie nicht die IAM-Konsole.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Erstellen Sie als Nächstes die IAM-Rolle, die diese Richtlinie verwendet. Notieren Sie sich den `Arn`-Wert, der vom Befehl zurückgegeben wird, Sie benötigen ihn später in diesem Verfahren. In diesem Beispiel verwenden wir `CWLtoSubscriptionFilterRole` für den Namen der Rolle, die wir erstellen.
```
aws iam create-role \
--role-name CWLtoSubscriptionFilterRole \
--assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um die Aktionen zu definieren, die CloudWatch Logs auf Ihrem Konto ausführen kann.
1. Verwenden Sie zunächst einen Text-Editor, um die folgende Berechtigungsrichtlinie in einer Datei mit dem Namen zu erstellen `~/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Geben Sie den folgenden Befehl ein, um die soeben erstellte Berechtigungsrichtlinie mit der Rolle zu verknüpfen, die Sie in Schritt 2 erstellt haben.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
Wenn Sie fertig sind, können Sie mit [Schritt 4: Erstellen eines Abonnementfilters](CreateSubscriptionFilter.md) fortfahren.
# Schritt 3: Add/validate IAM-Berechtigungen für das kontoübergreifende Ziel
Gemäß der Bewertungslogik für AWS kontenübergreifende Richtlinien muss für den Zugriff auf eine kontoübergreifende Ressource (z. B. ein Kinesis- oder Firehose-Stream, der als Ziel für einen Abonnementfilter verwendet wird) eine identitätsbasierte Richtlinie im sendenden Konto vorhanden sein, die expliziten Zugriff auf die kontenübergreifende Zielressource gewährt. Weitere Informationen zur Logik der Richtlinienbewertung finden Sie unter [Bewertungslogik für kontenübergreifende Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).
Sie können die identitätsbasierte Richtlinie der IAM-Rolle oder dem IAM-Benutzer zuordnen, die Sie zum Erstellen des Abonnementfilters verwenden. Diese Richtlinie muss im übermittelnden Konto vorhanden sein. Wenn Sie die Administratorrolle verwenden, um den Abonnementfilter zu erstellen, können Sie diesen Schritt überspringen und mit [Schritt 4: Erstellen eines Abonnementfilters](CreateSubscriptionFilter.md) fortfahren.
**Um die IAM-Berechtigungen hinzuzufügen oder zu validieren, die für kontoübergreifende Konten erforderlich sind**
1. Geben Sie den folgenden Befehl ein, um zu überprüfen, welche IAM-Rolle oder welcher IAM-Benutzer zur Ausführung von Log-Befehlen verwendet wird. AWS
```
aws sts get-caller-identity
```
Daraufhin erhalten Sie ein Ergebnis, das dem hier dargestellten entspricht:
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
Notieren Sie sich den Wert, der durch *RoleName* oder dargestellt wird. *UserName*
1. Melden Sie sich AWS-Managementkonsole im sendenden Konto an und suchen Sie nach den angehängten Richtlinien mit der IAM-Rolle oder dem IAM-Benutzer, die in der Ausgabe des in Schritt 1 eingegebenen Befehls zurückgegeben wurden.
1. Stellen Sie sicher, dass die mit dieser Rolle oder diesem Benutzer verknüpften Richtlinien explizite Zugriffsberechtigungen für die `logs:PutSubscriptionFilter` auf der kontoübergreifenden Zielressource enthalten.
Die folgende Richtlinie gewährt Berechtigungen zum Erstellen eines Abonnementfilters für jede Zielressource nur in einem einzigen AWS Konto, einem Konto: `999999999999`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnAccountResources",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:*"
]
}
]
}
```
------
Die folgende Richtlinie gewährt Berechtigungen zum Erstellen eines Abonnementfilters nur für eine bestimmte Zielressource mit `sampleDestination` dem Namen „ AWS Einzelkonto“`123456789012`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersonAccountResource",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:sampleDestination"
]
}
]
}
```
------
# Schritt 4: Erstellen eines Abonnementfilters
Wenn Sie ein Ziel erstellt haben, kann das Empfängerkonto der Protokolldaten den Ziel-ARN (arn:aws:logs:us-east-1:999999999999:destination:testDestination) für andere AWS -Konten freigeben, damit diese Protokollereignisse an dasselbe Ziel senden können. Die anderen sendenden Kontobenutzer erstellen einen Abonnementfilter für die jeweiligen Protokollgruppen für dieses Ziel. Der Abonnementfilter startet sofort den Fluss der Echtzeit-Protokolldaten aus der gewählten Protokollgruppe an das angegebene Ziel.
**Anmerkung**
Wenn Sie einer gesamten Organisation Berechtigungen für den Abonnementfilter gewähren, müssen Sie den ARN der IAM-Rolle verwenden, die Sie in [Schritt 2: (Nur bei Verwendung einer Organisation) Erstellen Sie eine IAM-Rolle](CreateSubscriptionFilter-IAMrole.md) erstellt haben.
Im folgenden Beispiel wird ein Abonnementfilter in einem sendenden Konto erstellt. Der Filter ist einer Protokollgruppe zugeordnet, die AWS CloudTrail Ereignisse enthält, sodass jede protokollierte Aktivität, die mit „Root“ AWS -Anmeldeinformationen ausgeführt wird, an das Ziel gesendet wird, das Sie zuvor erstellt haben. Dieses Ziel kapselt einen Stream namens "“. RecipientStream
Bei den restlichen Schritten in den folgenden Abschnitten wird davon ausgegangen, dass Sie die Anweisungen unter [ CloudTrail Ereignisse an CloudWatch Protokolle senden](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) im *AWS CloudTrail Benutzerhandbuch* befolgt und eine Protokollgruppe erstellt haben, die Ihre CloudTrail Ereignisse enthält. Diese Schritte gehen davon aus, dass der Name dieser Protokollgruppe `CloudTrail/logs` ist.
Wenn Sie den folgenden Befehl eingeben, stellen Sie sicher, dass Sie als IAM-Benutzer angemeldet sind oder die IAM-Rolle verwenden, für die Sie die Richtlinie hinzugefügt haben, in [Schritt 3: Add/validate IAM-Berechtigungen für das kontoübergreifende Ziel](Subscription-Filter-CrossAccount-Permissions.md).
```
aws logs put-subscription-filter \
--log-group-name "CloudTrail/logs" \
--filter-name "RecipientStream" \
--filter-pattern "{$.userIdentity.type = Root}" \
--destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
```
Die Protokollgruppe und das Ziel müssen sich in derselben AWS Region befinden. Das Ziel kann jedoch auf eine AWS Ressource verweisen, z. B. auf einen Amazon Kinesis Data Streams Streams-Stream, der sich in einer anderen Region befindet.
# Validierung des Ablaufs von Protokollereignissen
Nachdem Sie den Abonnementfilter erstellt haben, leitet CloudWatch Logs alle eingehenden Protokollereignisse, die dem Filtermuster entsprechen, an den Stream weiter, der im Zielstream mit dem Namen "" gekapselt ist. **RecipientStream** Der Besitzer des Ziels kann überprüfen, ob dies der Fall ist, indem er den get-shard-iterator Befehl **aws kinesis** verwendet, um einen Amazon Kinesis Data Streams Streams-Shard abzurufen, und den Befehl **aws kinesis get-records verwendet, um einige Amazon Kinesis** Data Streams Streams-Datensätze abzurufen:
```
aws kinesis get-shard-iterator \
--stream-name RecipientStream \
--shard-id shardId-000000000000 \
--shard-iterator-type TRIM_HORIZON
{
"ShardIterator":
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
}
aws kinesis get-records \
--limit 10 \
--shard-iterator
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
```
**Anmerkung**
Möglicherweise müssen Sie den Befehl get-records einige Male erneut ausführen, bevor Amazon Kinesis Data Streams Daten zurückgibt.
Sie sollten eine Antwort mit einer Reihe von Amazon Kinesis Data Streams Streams-Datensätzen sehen. Das Datenattribut im Amazon Kinesis Data Streams Streams-Datensatz wird im GZIP-Format komprimiert und anschließend base64-codiert. Sie können die Rohdaten über die Befehlszeile mit dem folgenden Unix-Befehl überprüfen:
```
echo -n "" | base64 -d | zcat
```
Die dekodierten und dekomprimierten base64-Daten sind als JSON mit folgender Struktur formatiert:
```
{
"owner": "111111111111",
"logGroup": "CloudTrail/logs",
"logStream": "111111111111_CloudTrail/logs_us-east-1",
"subscriptionFilters": [
"RecipientStream"
],
"messageType": "DATA_MESSAGE",
"logEvents": [
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
]
}
```
Die wichtigsten Elemente in dieser Datenstruktur lauten wie folgt:
**owner**
Die AWS Konto-ID der ursprünglichen Protokolldaten.
**logGroup**
Der Name der Protokollgruppe der ursprünglichen Protokolldaten.
**logStream**
Der Name des Protokoll-Stream der ursprünglichen Protokolldaten.
**subscriptionFilters**
Die Namenliste der Abonnementfilter, die mit den ursprünglichen Protokolldaten übereingestimmt haben.
**messageType**
Datennachrichten verwenden den Typ „DATA\$1MESSAGE“. Manchmal können CloudWatch Logs Amazon Kinesis Data Streams Streams-Datensätze mit dem Typ „CONTROL\$1MESSAGE“ ausgeben, hauptsächlich um zu überprüfen, ob das Ziel erreichbar ist.
**logEvents**
Die tatsächlichen Protokolldaten, die als Array von Protokollereignis-Datensätzen dargestellt werden. Die ID-Eigenschaft ist eine eindeutige Kennung für jedes Protokollereignis.
# Ändern der Mitgliedschaft im Ziel zur Laufzeit
In manchen Situationen müssen Sie die Mitgliedschaft einiger Benutzer in einem Ziel, das Ihr Eigentum ist, hinzufügen oder entfernen. Sie können den Befehl `put-destination-policy` für Ihr Ziel mit einer neuen Zugriffsrichtlinie verwenden. Im folgenden Beispiel wird festgelegt, dass das zuvor hinzugefügte Konto **111111111111** keine Protokolldaten mehr sendet und das Konto **222222222222** aktiviert wird.
1. Rufen Sie die Richtlinie ab, die derzeit mit dem Ziel **TestDestination** verknüpft ist, und notieren Sie sich Folgendes: **AccessPolicy**
```
aws logs describe-destinations \
--destination-name-prefix "testDestination"
{
"Destinations": [
{
"DestinationName": "testDestination",
"RoleArn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"TargetArn": "arn:aws:kinesis:region:999999999999:stream/RecipientStream",
"AccessPolicy": "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\", \"Effect\": \"Allow\", \"Principal\": {\"AWS\": \"111111111111\"}, \"Action\": \"logs:PutSubscriptionFilter\", \"Resource\": \"arn:aws:logs:region:999999999999:destination:testDestination\"}] }"
}
]
}
```
1. Aktualisieren Sie die Richtlinie, sodass angezeigt wird, dass das Konto **111111111111** angehalten wurde und das Konto **222222222222** aktiviert wurde. Fügen Sie diese Richtlinie in die Datei **\$1/ NewAccessPolicy** .json ein:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "222222222222"
},
"Action": "logs:PutSubscriptionFilter",
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
}
]
}
```
------
1. Rufen Sie **PutDestinationPolicy**auf, um die in der **NewAccessPolicy.json-Datei** definierte Richtlinie dem Ziel zuzuordnen:
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Damit werden schließlich die Protokollereignisse von der Konto-ID **111111111111** deaktiviert. Protokollereignisse der Konto-ID **222222222222** werden an das Ziel übertragen, sobald der Eigentümer des Kontos **222222222222** einen Abonnementfilter erstellt.
# Aktualisieren eines bestehenden kontoübergreifenden Abonnements
Wenn Sie derzeit über ein kontoübergreifendes Protokoll-Abonnement verfügen, bei dem das Zielkonto Berechtigungen nur bestimmten Senderkonten gewährt, und Sie dieses Abonnement aktualisieren möchten, damit das Zielkonto Zugriff auf alle Konten in einer Organisation gewährt, führen Sie die Schritte in diesem Abschnitt aus.
**Topics**
+ [Schritt 1: Aktualisieren der Abonnementfilter](Cross-Account-Log_Subscription-Update-filter.md)
+ [Schritt 2: Aktualisieren der bestehenden Richtlinie für die Zugriffsrichtlinie](Cross-Account-Log_Subscription-Update-policy.md)
# Schritt 1: Aktualisieren der Abonnementfilter
**Anmerkung**
Dieser Schritt ist nur für kontenübergreifende Abonnements für Protokolle erforderlich, die von den in [Protokollierung von AWS Diensten aktivieren](AWS-logs-and-resource-policy.md) aufgeführten Services erstellt werden. Wenn Sie nicht mit Protokollen arbeiten, die von einer dieser Protokollgruppen erstellt wurden, können Sie zu [Schritt 2: Aktualisieren der bestehenden Richtlinie für die Zugriffsrichtlinie](Cross-Account-Log_Subscription-Update-policy.md) wechseln.
In bestimmten Fällen müssen Sie die Abonnementfilter in allen Absenderkonten aktualisieren, die Protokolle an das Zielkonto senden. Das Update fügt eine IAM-Rolle hinzu, die davon ausgehen und überprüfen CloudWatch kann, dass das Absenderkonto berechtigt ist, Protokolle an das Empfängerkonto zu senden.
Befolgen Sie die Schritte in diesem Abschnitt für jedes Senderkonto, das Sie aktualisieren möchten, um die Organisations-ID für die kontoübergreifenden Abonnementberechtigungen zu verwenden.
In den Beispielen in diesem Abschnitt wurden für zwei Konten, `111111111111` und `222222222222`, bereits Abonnementfilter erstellt, um Protokolle an Konto `999999999999` zu senden. Die vorhandenen Abonnementfilterwerte lauten wie folgt:
```
## Existing Subscription Filter parameter values
\ --log-group-name "my-log-group-name"
\ --filter-name "RecipientStream"
\ --filter-pattern "{$.userIdentity.type = Root}"
\ --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
```
Wenn Sie die aktuellen Parameterwerte des Abonnementfilters suchen müssen, geben Sie den folgenden Befehl ein.
```
aws logs describe-subscription-filters
\ --log-group-name "my-log-group-name"
```
**Um einen Abonnementfilter zu aktualisieren, um ab sofort Organisation IDs für kontoübergreifende Protokollberechtigungen zu verwenden**
1. Erstellen Sie die folgende Vertrauensrichtlinie in einer Datei namens `~/TrustPolicyForCWL.json`. Erstellen Sie in einem Text-Editor die Richtliniendatei, verwenden Sie nicht die IAM-Konsole.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Erstellen Sie als Nächstes die IAM-Rolle, die diese Richtlinie verwendet. Notieren Sie sich den `Arn`-Wert des `Arn`-Werts, der vom Befehl zurückgegeben wird, den Sie später in diesem Verfahren benötigen. In diesem Beispiel verwenden wir `CWLtoSubscriptionFilterRole` für den Namen der Rolle, die wir erstellen.
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.json
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um die Aktionen zu definieren, die CloudWatch Logs auf Ihrem Konto ausführen kann.
1. Verwenden Sie zunächst einen Text-Editor, um die folgende Berechtigungsrichtlinie in einer Datei mit dem Namen zu erstellen `/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Geben Sie den folgenden Befehl ein, um die soeben erstellte Berechtigungsrichtlinie mit der Rolle zu verknüpfen, die Sie in Schritt 2 erstellt haben.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
1. Geben Sie den folgenden Befehl ein, um den Abonnementfilter zu aktualisieren.
```
aws logs put-subscription-filter
\ --log-group-name "my-log-group-name"
\ --filter-name "RecipientStream"
\ --filter-pattern "{$.userIdentity.type = Root}"
\ --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
\ --role-arn "arn:aws:iam::111111111111:role/CWLtoSubscriptionFilterRole"
```
# Schritt 2: Aktualisieren der bestehenden Richtlinie für die Zugriffsrichtlinie
Nachdem Sie die Abonnementfilter in allen Senderkonten aktualisiert haben, können Sie die Zielzugriffsrichtlinie im Empfängerkonto aktualisieren.
In den folgenden Beispielen ist das Empfängerkonto `999999999999` und das Ziel hat den Namen `testDestination`.
Das Update ermöglicht es allen Konten, die Teil der Organisation mit der ID `o-1234567890` sind, Protokolle an das Empfängerkonto zu senden. Nur die Konten, für die Abonnementfilter erstellt wurden, senden tatsächlich Protokolle an das Empfängerkonto.
**So aktualisieren Sie die Zielzugriffsrichtlinie im Empfängerkonto, um eine Organisations-ID für Berechtigungen zu verwenden**
1. Verwenden Sie im Empfängerkonto einen Texteditor, um eine `~/AccessPolicy.json`-Datei mit dem folgenden Inhalt zu erstellen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": "logs:PutSubscriptionFilter",
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-1234567890"
]
}
}
}
]
}
```
------
1. Geben Sie den folgenden Befehl ein, um die Richtlinie, die Sie soeben erstellt haben, dem vorhandenen Ziel anzufügen. Um ein Ziel so zu aktualisieren, dass statt einer Zugriffsrichtlinie, die ein bestimmtes AWS Konto auflistet, eine Zugriffsrichtlinie mit einer Organisations-ID verwendet wird IDs, fügen Sie den `force` Parameter hinzu.
**Warnung**
Wenn Sie mit Protokollen arbeiten, die von einem AWS Dienst gesendet wurden, der unter aufgeführt ist[Protokollierung von AWS Diensten aktivieren](AWS-logs-and-resource-policy.md), müssen Sie, bevor Sie diesen Schritt ausführen, zuerst die Abonnementfilter in allen Absenderkonten aktualisiert haben, wie unter beschrieben[Schritt 1: Aktualisieren der Abonnementfilter](Cross-Account-Log_Subscription-Update-filter.md).
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Kontoübergreifender regionsübergreifender Austausch von Protokolldaten mit Firehose
Wenn Sie Protokolldaten für mehrere Konten freigeben möchten, müssen Sie Sender und Receiver der Protokolldaten festlegen:
+ **Absender der Protokolldaten** — Ruft die Zielinformationen vom Empfänger ab und teilt Logs mit, dass CloudWatch Logs bereit ist, seine Protokollereignisse an das angegebene Ziel zu senden. In den Verfahren im Rest dieses Abschnitts wird der Absender der Protokolldaten mit der fiktiven AWS Kontonummer 1111111111 angezeigt.
+ **Empfänger von Protokolldaten** — richtet ein Ziel ein, das einen Amazon Kinesis Data Streams Streams-Stream kapselt und CloudWatch Logs darüber informiert, dass der Empfänger Protokolldaten empfangen möchte. Der Empfänger gibt dann die Informationen über sein Ziel für den Absender frei. In den Verfahren im Rest dieses Abschnitts wird der Empfänger der Protokolldaten mit der fiktiven AWS Kontonummer 222222222222 angezeigt.
Das Beispiel in diesem Abschnitt verwendet einen Firehose-Lieferstream mit Amazon S3 S3-Speicher. Sie können Firehose-Lieferstreams auch mit unterschiedlichen Einstellungen einrichten. Weitere Informationen finden Sie unter [Firehose Delivery Stream erstellen](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).
**Anmerkung**
Die Protokollgruppe und das Ziel müssen sich in derselben AWS Region befinden. Die AWS Ressource, auf die das Ziel verweist, kann sich jedoch in einer anderen Region befinden.
**Anmerkung**
Der Firehose-Abonnementfilter für ***dasselbe Konto*** und denselben ***regionsübergreifenden*** Lieferstream wird unterstützt.
**Topics**
+ [Schritt 1: Erstellen Sie einen Firehose-Lieferstream](CreateFirehoseStream.md)
+ [Schritt 2: Erstellen eines Ziels](CreateFirehoseStreamDestination.md)
+ [Schritt 3: Add/validate IAM-Berechtigungen für das kontoübergreifende Ziel](Subscription-Filter-CrossAccount-Permissions-Firehose.md)
+ [Schritt 4: Erstellen eines Abonnementfilters](CreateSubscriptionFilterFirehose.md)
+ [Validierung des Flusses von Protokollereignissen](ValidateLogEventFlowFirehose.md)
+ [Ändern der Mitgliedschaft im Ziel zur Laufzeit](ModifyDestinationMembershipFirehose.md)
# Schritt 1: Erstellen Sie einen Firehose-Lieferstream
**Wichtig**
Bevor Sie die folgenden Schritte ausführen, müssen Sie eine Zugriffsrichtlinie verwenden, damit Firehose auf Ihren Amazon S3 S3-Bucket zugreifen kann. Weitere Informationen finden Sie unter [Zugriffskontrolle](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3) im *Amazon Data Firehose Developer Guide*.
Alle Schritte in diesem Abschnitt (Schritt 1) müssen im Konto des Protokolldatenempfängers ausgeführt werden.
USA Ost (Nord-Virginia) wird in den folgenden Beispielbefehlen verwendet. Ersetzen Sie diese Region durch die richtige Region für Ihre Bereitstellung.
**Um einen Firehose-Lieferstream zu erstellen, der als Ziel verwendet werden soll**
1. Erstellen eines Amazon-S3-Buckets:
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. Erstellen Sie die IAM-Rolle, die Firehose die Berechtigung erteilt, Daten in den Bucket zu legen.
1. Verwenden Sie zunächst einen Text-Editor zum Erstellen einer Vertrauensrichtlinie in einer Datei `~/TrustPolicyForFirehose.json`.
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. Erstellen Sie die IAM-Rolle und geben Sie die Datei mit der Vertrauensrichtlinie an, die Sie gerade erstellt haben.
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. Die Ausgabe für den Befehl sieht dann wie folgt aus. Notieren Sie sich den Rollennamen und die Rollen-ARN.
```
{
"Role": {
"Path": "/",
"RoleName": "FirehosetoS3Role",
"RoleId": "AROAR3BXASEKW7K635M53",
"Arn": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"CreateDate": "2021-02-02T07:53:10+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "222222222222"
}
}
}
}
}
}
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um die Aktionen zu definieren, die Firehose in Ihrem Konto ausführen kann.
1. Verwenden Sie zunächst einen Text-Editor, um die folgende Berechtigungsrichtlinie in einer Datei mit dem Namen zu erstellen `~/PermissionsForFirehose.json`. Abhängig von Ihrem Anwendungsfall müssen Sie dieser Datei möglicherweise weitere Berechtigungen hinzufügen.
```
{
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}]
}
```
1. Geben Sie den folgenden Befehl ein, um die soeben erstellte Berechtigungsrichtlinie der IAM-Rolle zuzuordnen.
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. Geben Sie den folgenden Befehl ein, um den Firehose-Lieferstream zu erstellen. Ersetzen Sie *my-role-arn* und *amzn-s3-demo-bucket2-arn* durch die richtigen Werte für Ihre Bereitstellung.
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket"}'
```
Die Ausgabe sollte folgendermaßen oder ähnlich aussehen:
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# Schritt 2: Erstellen eines Ziels
**Wichtig**
Alle Schritte in diesem Verfahren müssen im Konto des Protokolldatenempfängers ausgeführt werden.
Wenn das Ziel erstellt wurde, sendet CloudWatch Logs im Namen des Empfängerkontos eine Testnachricht an das Ziel. Wenn der Abonnementfilter später aktiv ist, sendet CloudWatch Logs im Namen des Quellkontos Protokollereignisse an das Ziel.
**So erstellen Sie ein Ziel**
1. Warten Sie, bis der Firehose-Stream, in dem Sie ihn erstellt haben, aktiv [Schritt 1: Erstellen Sie einen Firehose-Lieferstream](CreateFirehoseStream.md) wird. **Sie können den folgenden Befehl verwenden, um das StreamDescription zu überprüfen. StreamStatus**Eigentum.
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
Beachten Sie außerdem die **DeliveryStreamDescription. DeliveryStreamARN-Wert**, da Sie ihn in einem späteren Schritt verwenden müssen. Beispielausgabe dieses Befehls:
```
{
"DeliveryStreamDescription": {
"DeliveryStreamName": "my-delivery-stream",
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamEncryptionConfiguration": {
"Status": "DISABLED"
},
"DeliveryStreamType": "DirectPut",
"VersionId": "1",
"CreateTimestamp": "2021-02-01T23:59:15.567000-08:00",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
}
},
"ExtendedS3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
},
"S3BackupMode": "Disabled"
}
}
],
"HasMoreDestinations": false
}
}
```
Es kann einige Minuten dauern, bis der Bereitstellungsdatenstrom im aktiven Status angezeigt wird.
1. Wenn der Lieferstream aktiv ist, erstellen Sie die IAM-Rolle, die CloudWatch Logs die Erlaubnis erteilt, Daten in Ihren Firehose-Stream einzufügen. Zunächst müssen Sie eine Vertrauensrichtlinie in einer Datei **TrustPolicyFor\$1/** CWL.json erstellen. Verwenden Sie einen Text-Editor, um diese Richtlinie zu erstellen. Weitere Informationen zu CloudWatch Logs-Endpunkten finden Sie unter [Amazon CloudWatch Logs-Endpunkte und](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html) Kontingente.
Diese Richtlinie enthält einen globalen Bedingungskontextschlüssel `aws:SourceArn`, der das `sourceAccountId` angibt, um das Confused-Deputy-Problem zu vermeiden. Wenn Sie die Quell-Kontonummer beim ersten Aufruf noch nicht kennen, empfehlen wir Ihnen, die Ziel-ARN in das Quell-ARN-Feld einzutragen. Bei den folgenden Aufrufen sollten Sie als Quell-ARN den tatsächlichen Quell-ARN angeben, den Sie beim ersten Aufruf ermittelt haben. Weitere Informationen finden Sie unter [Confused-Deputy-Prävention](Subscriptions-confused-deputy.md).
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.region.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
```
1. Verwenden Sie den Befehl **aws iam create-role**, um die IAM-Rolle zu erstellen und geben Sie die Datei mit der Vertrauensrichtlinie an, die Sie gerade erstellt haben.
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
Dies ist eine Beispielausgabe. Notieren Sie den zurückgegebenen `Role.Arn`-Wert, da Sie ihn in einem späteren Schritt benötigen.
```
{
"Role": {
"Path": "/",
"RoleName": "CWLtoKinesisFirehoseRole",
"RoleId": "AROAR3BXASEKYJYWF243H",
"Arn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"CreateDate": "2021-02-02T08:10:43+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.region.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
}
}
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um zu definieren, welche Aktionen CloudWatch Logs auf Ihrem Konto ausführen kann. Verwenden Sie zunächst einen Texteditor, um eine Berechtigungsrichtlinie in einer Datei **\$1/ PermissionsFor CWL.json** zu erstellen:
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. Verknüpfen Sie mit dem folgenden Befehl die Berechtigungsrichtlinie mit der Rolle:
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Nachdem sich der Firehose-Lieferstream im aktiven Zustand befindet und Sie die IAM-Rolle erstellt haben, können Sie das CloudWatch Logs-Ziel erstellen.
1. In diesem Schritt wird keine Zugriffsrichtlinie mit Ihrem Ziel verknüpft. Es ist zudem erst der erste von zwei Schritten zum Erstellen eines Ziels. Notieren Sie sich die in der Nutzlast zurückgegebene ARN des neuen Zielortes, da Sie diese in einem späteren Schritt als `destination.arn` verwenden werden.
```
aws logs put-destination \
--destination-name "testFirehoseDestination" \
--target-arn "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream" \
--role-arn "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole"
{
"destination": {
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"arn": "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"}
}
```
1. Verknüpfen Sie, nachdem der vorherige Schritt abgeschlossen ist, im Empfängerkonto der Protokolldaten (222222222222) eine Zugriffsrichtlinie mit dem Ziel.
Diese Richtlinie ermöglicht dem Sender-Konto der Protokolldaten (111111111111), auf das Ziel nur im Empfängerkonto der Protokolldaten (222222222222) zuzugreifen. Sie können einen Texteditor verwenden, um diese Richtlinie in die Datei **\$1/ AccessPolicy** .json einzufügen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "111111111111"
},
"Action" : "logs:PutSubscriptionFilter",
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. Damit wird eine Richtlinie erstellt, die bestimmt, wer Schreibzugriff auf das Ziel hat. In dieser Richtlinie muss die PutSubscriptionFilter Aktion **logs:** für den Zugriff auf das Ziel angegeben werden. Kontoübergreifende Benutzer verwenden die Aktion **PutSubscriptionFilter**, um Protokollereignisse an das Ziel zu senden:
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# Schritt 3: Add/validate IAM-Berechtigungen für das kontoübergreifende Ziel
Gemäß der Bewertungslogik für AWS kontenübergreifende Richtlinien muss für den Zugriff auf eine kontoübergreifende Ressource (z. B. ein Kinesis- oder Firehose-Stream, der als Ziel für einen Abonnementfilter verwendet wird) eine identitätsbasierte Richtlinie im sendenden Konto vorhanden sein, die expliziten Zugriff auf die kontenübergreifende Zielressource gewährt. Weitere Informationen zur Logik der Richtlinienbewertung finden Sie unter [Bewertungslogik für kontenübergreifende Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).
Sie können die identitätsbasierte Richtlinie der IAM-Rolle oder dem IAM-Benutzer zuordnen, die Sie zum Erstellen des Abonnementfilters verwenden. Diese Richtlinie muss im übermittelnden Konto vorhanden sein. Wenn Sie die Administratorrolle verwenden, um den Abonnementfilter zu erstellen, können Sie diesen Schritt überspringen und mit [Schritt 4: Erstellen eines Abonnementfilters](CreateSubscriptionFilter.md) fortfahren.
**Um die IAM-Berechtigungen hinzuzufügen oder zu validieren, die für kontoübergreifende Konten erforderlich sind**
1. Geben Sie den folgenden Befehl ein, um zu überprüfen, welche IAM-Rolle oder welcher IAM-Benutzer zur Ausführung von Log-Befehlen verwendet wird. AWS
```
aws sts get-caller-identity
```
Daraufhin erhalten Sie ein Ergebnis, das dem hier dargestellten entspricht:
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
Notieren Sie sich den Wert, der durch *RoleName* oder dargestellt wird. *UserName*
1. Melden Sie sich AWS-Managementkonsole im sendenden Konto an und suchen Sie nach den angehängten Richtlinien mit der IAM-Rolle oder dem IAM-Benutzer, die in der Ausgabe des in Schritt 1 eingegebenen Befehls zurückgegeben wurden.
1. Stellen Sie sicher, dass die mit dieser Rolle oder diesem Benutzer verknüpften Richtlinien explizite Zugriffsberechtigungen für die `logs:PutSubscriptionFilter` auf der kontoübergreifenden Zielressource enthalten.
Die folgende Richtlinie gewährt Berechtigungen zum Erstellen eines Abonnementfilters für jede Zielressource nur in einem einzigen AWS Konto, einem Konto: `999999999999`
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnAnyResourceInOneSpecificAccount",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:*"
]
}
]
}
```
------
Die folgende Richtlinie gewährt Berechtigungen zum Erstellen eines Abonnementfilters nur für eine bestimmte Zielressource mit `sampleDestination` dem Namen „ AWS Einzelkonto“`123456789012`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnSpecificResource",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:amzn-s3-demo-bucket"
]
}
]
}
```
------
# Schritt 4: Erstellen eines Abonnementfilters
Wechseln Sie zum Senderkonto, das in diesem Beispiel 111111111111 lautet. Sie erstellen nun den Abonnementfilter im Senderkonto. In diesem Beispiel ist der Filter mit einer Protokollgruppe verknüpft, die AWS CloudTrail Ereignisse enthält, sodass jede protokollierte Aktivität, die mit „Root“ AWS -Anmeldeinformationen ausgeführt wird, an das Ziel übermittelt wird, das Sie zuvor erstellt haben. Weitere Informationen zum Senden von AWS CloudTrail Ereignissen an CloudWatch Protokolle finden Sie unter [Senden von CloudTrail Ereignissen an CloudWatch Protokolle](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) im *AWS CloudTrail Benutzerhandbuch*.
Wenn Sie den folgenden Befehl eingeben, stellen Sie sicher, dass Sie als IAM-Benutzer angemeldet sind oder die IAM-Rolle verwenden, für die Sie die Richtlinie hinzugefügt haben, in [Schritt 3: Add/validate IAM-Berechtigungen für das kontoübergreifende Ziel](Subscription-Filter-CrossAccount-Permissions-Firehose.md).
```
aws logs put-subscription-filter \
--log-group-name "aws-cloudtrail-logs-111111111111-300a971e" \
--filter-name "firehose_test" \
--filter-pattern "{$.userIdentity.type = AssumedRole}" \
--destination-arn "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
```
Die Protokollgruppe und das Ziel müssen sich in derselben AWS Region befinden. Das Ziel kann jedoch auf eine AWS Ressource verweisen, z. B. auf einen Firehose-Stream, der sich in einer anderen Region befindet.
# Validierung des Flusses von Protokollereignissen
Nachdem Sie den Abonnementfilter erstellt haben, leitet CloudWatch Logs alle eingehenden Protokollereignisse, die dem Filtermuster entsprechen, an den Firehose-Lieferstream weiter. Die Daten werden in Ihrem Amazon S3 S3-Bucket basierend auf dem Zeitpufferintervall angezeigt, das für den Firehose-Lieferstream festgelegt ist. Sobald genügend Zeit abgelaufen ist, können Sie die Daten im Amazon-S3-Bucket überprüfen. Geben Sie zur Prüfung des Buckets den folgenden Befehl ein:
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
Die Ausgabe des Befehls sieht dann wie folgt aus:
```
{
"Contents": [
{
"Key": "2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba",
"LastModified": "2021-02-02T09:00:26+00:00",
"ETag": "\"EXAMPLEa817fb88fc770b81c8f990d\"",
"Size": 198,
"StorageClass": "STANDARD",
"Owner": {
"DisplayName": "firehose+2test",
"ID": "EXAMPLE27fd05889c665d2636218451970ef79400e3d2aecca3adb1930042e0"
}
}
]
}
```
Sie können dann ein bestimmtes Objekt aus dem Bucket abrufen, indem Sie den folgenden Befehl eingeben. Ersetzen Sie den Wert von `key` mit dem Wert, den Sie im vorherigen Befehl gefunden haben.
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket' --key '2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba' testfile.gz
```
Die Daten im Amazon-S3-Objekt sind im GZIP-Format komprimiert. Sie können die Rohdaten über die Befehlszeile mit einem der folgenden Befehlen überprüfen:
Linux:
```
zcat testfile.gz
```
macOS:
```
zcat
In manchen Situationen müssen Sie Protokollsender in einem Ziel, das Ihr Eigentum ist, hinzufügen oder entfernen. Sie können die **PutDestinationPolicy**Aktion auf Ihrem Ziel mit einer neuen Zugriffsrichtlinie verwenden. Im folgenden Beispiel wird festgelegt, dass das zuvor hinzugefügte Konto **111111111111** keine Protokolldaten mehr senden kann und das Konto **333333333333** aktiviert wird.
1. Rufen Sie die Richtlinie ab, die derzeit mit dem Ziel **TestDestination** verknüpft ist, und notieren Sie sich Folgendes: **AccessPolicy**
```
aws logs describe-destinations \
--destination-name-prefix "testFirehoseDestination"
{
"destinations": [
{
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam:: 222222222222:role/CWLtoKinesisFirehoseRole",
"accessPolicy": "{\n \"Version\" : \"2012-10-17\",\n \"Statement\" : [\n {\n \"Sid\" : \"\",\n \"Effect\" : \"Allow\",\n \"Principal\" : {\n \"AWS\" : \"111111111111 \"\n },\n \"Action\" : \"logs:PutSubscriptionFilter\",\n \"Resource\" : \"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination\"\n }\n ]\n}\n\n",
"arn": "arn:aws:logs:us-east-1: 222222222222:destination:testFirehoseDestination",
"creationTime": 1612256124430
}
]
}
```
1. Aktualisieren Sie die Richtlinie dementsprechend, dass das Konto **111111111111** angehalten wurde und das Konto **333333333333** aktiviert wurde. Fügen Sie diese Richtlinie in die Datei **\$1/ NewAccessPolicy** .json ein:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "333333333333 "
},
"Action" : "logs:PutSubscriptionFilter",
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. Verwenden Sie den folgenden Befehl, um die in der **NewAccessPolicyJSON-Datei** definierte Richtlinie dem Ziel zuzuordnen:
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Damit werden schließlich die Protokollereignisse von der Konto-ID **111111111111** deaktiviert. Protokollereignisse der Konto-ID **333333333333** werden an das Ziel übertragen, sobald der Eigentümer des Kontos **333333333333** einen Abonnementfilter erstellt.
# Kontoübergreifende, regionsübergreifende Abonnements auf Kontoebene mit Amazon Kinesis Data Streams
Wenn Sie ein kontoübergreifendes Abonnement erstellen, können Sie ein einzelnes Konto oder eine Organisation angeben, die der Sender sein soll. Wenn Sie eine Organisation angeben, können alle Konten in der Organisation mit diesem Verfahren Protokolle an das Receiver-Konto senden.
Wenn Sie Protokolldaten für mehrere Konten freigeben möchten, müssen Sie Sender und Receiver der Protokolldaten festlegen:
+ **Absender der Protokolldaten** — Ruft die Zielinformationen vom Empfänger ab und teilt Logs mit, dass CloudWatch Logs bereit ist, seine Protokollereignisse an das angegebene Ziel zu senden. In den Verfahren im Rest dieses Abschnitts wird der Absender der Protokolldaten mit der fiktiven AWS Kontonummer 1111111111 angezeigt.
Wenn mehrere Konten in einer Organisation Protokolle an ein Empfängerkonto senden, können Sie eine Richtlinie erstellen, die allen Konten in der Organisation die Berechtigung zum Senden von Protokollen an das Empfängerkonto gewährt. Sie müssen immer noch separate Abonnementfilter für jedes Senderkonto einrichten.
+ **Empfänger von Protokolldaten** — richtet ein Ziel ein, das einen Amazon Kinesis Data Streams Streams-Stream kapselt und CloudWatch Logs darüber informiert, dass der Empfänger Protokolldaten empfangen möchte. Der Empfänger gibt dann die Informationen über sein Ziel für den Absender frei. In den Verfahren im Rest dieses Abschnitts wird der Empfänger der Protokolldaten mit der fiktiven AWS Kontonummer 999999999999 angezeigt.
Um Protokollereignisse von kontoübergreifenden Benutzern zu empfangen, erstellt der Empfänger der Protokolldaten zunächst ein Protokollziel. CloudWatch Jedes Ziel umfasst die folgenden Schlüsselelemente:
**Name des Ziels**
Der Name der Zielregion, die Sie erstellen möchten.
**Ziel-ARN**
Der Amazon-Ressourcenname (ARN) der AWS Ressource, die Sie als Ziel für den Abonnement-Feed verwenden möchten.
**ARN der Rolle**
Eine AWS Identity and Access Management (IAM) -Rolle, die CloudWatch Logs die erforderlichen Berechtigungen erteilt, um Daten in den ausgewählten Stream zu übertragen.
**Zugriffsrichtlinie**
Ein IAM-Richtliniendokument (im JSON-Format, das in der IAM-Richtliniengrammatik geschrieben ist), das kontrolliert, welche Benutzer Schreibberechtigung für das Ziel haben.
**Anmerkung**
Die Protokollgruppe und das Ziel müssen sich in derselben AWS Region befinden. Die AWS Ressource, auf die das Ziel verweist, kann sich jedoch in einer anderen Region befinden. In den Beispielen in den folgenden Abschnitten werden alle regionsspezifischen Ressourcen in USA Ost (Nord-Virginia) erstellt.
**Topics**
+ [Einrichten eines neuen kontoübergreifenden Abonnements](Cross-Account-Log_Subscription-New-Account.md)
+ [Aktualisieren eines bestehenden kontoübergreifenden Abonnements](Cross-Account-Log_Subscription-Update-Account.md)
# Einrichten eines neuen kontoübergreifenden Abonnements
Befolgen Sie die Schritte in diesen Abschnitten, um ein neues kontoübergreifendes Protokollabonnement einzurichten.
**Topics**
+ [Schritt 1: Erstellen eines Ziels](CreateDestination-Account.md)
+ [Schritt 2: (Nur bei Verwendung einer Organisation) Erstellen Sie eine IAM-Rolle](CreateSubscriptionFilter-IAMrole-Account.md)
+ [Schritt 3: Erstellen Sie eine Abonnementfilterrichtlinie auf Kontoebene](CreateSubscriptionFilter-Account.md)
+ [Validierung des Ablaufs von Protokollereignissen](ValidateLogEventFlow-Account.md)
+ [Ändern der Mitgliedschaft im Ziel zur Laufzeit](ModifyDestinationMembership-Account.md)
# Schritt 1: Erstellen eines Ziels
**Wichtig**
Alle Schritte in diesem Verfahren müssen im Konto des Protokolldatenempfängers ausgeführt werden.
In diesem Beispiel hat das Konto des Empfängers der Protokolldaten die Konto-ID 9999999999, während die AWS Konto-ID des Absenders der Protokolldaten 1111111111 lautet. AWS
In diesem Beispiel wird ein Ziel mithilfe eines Amazon Kinesis Data Streams-Streams namens und einer Rolle erstellt RecipientStream, die es CloudWatch Logs ermöglicht, Daten darauf zu schreiben.
Wenn das Ziel erstellt ist, sendet CloudWatch Logs im Namen des Empfängerkontos eine Testnachricht an das Ziel. Wenn der Abonnementfilter später aktiv ist, sendet CloudWatch Logs im Namen des Quellkontos Protokollereignisse an das Ziel.
**So erstellen Sie ein Ziel**
1. Erstellen Sie im Empfängerkonto einen Ziel-Stream in Amazon Kinesis Data Streams. Geben Sie an der Eingabeaufforderung Folgendes ein:
```
aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
```
1. Warten Sie, bis der -Stream aktiv wird. **Sie können den Befehl **aws kinesis describe-stream** verwenden, um das zu überprüfen. StreamDescription StreamStatus**Eigentum. Notieren Sie sich außerdem den Wert **StreamDescription.streamArn,** da Sie ihn später an Logs übergeben werden: CloudWatch
```
aws kinesis describe-stream --stream-name "RecipientStream"
{
"StreamDescription": {
"StreamStatus": "ACTIVE",
"StreamName": "RecipientStream",
"StreamARN": "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream",
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"EndingHashKey": "34028236692093846346337460743176EXAMPLE",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber": "4955113521868881845667950383198145878459135270218EXAMPLE"
}
}
]
}
}
```
Es kann einige Minuten dauern, bis der Stream im aktiven Status angezeigt wird.
1. Erstellen Sie die IAM-Rolle, die CloudWatch Logs die Berechtigung erteilt, Daten in Ihren Stream einzufügen. Zunächst müssen Sie eine Vertrauensrichtlinie in einer Datei **\$1/ TrustPolicyFor** CWL.json erstellen. Erstellen Sie in einem Text-Editor die Richtliniendatei, verwenden Sie nicht die IAM-Konsole.
Diese Richtlinie enthält einen globalen Bedingungskontextschlüssel `aws:SourceArn`, der das `sourceAccountId` angibt, um das Confused-Deputy-Problem zu vermeiden. Wenn Sie die Quell-Kontonummer beim ersten Aufruf noch nicht kennen, empfehlen wir Ihnen, die Ziel-ARN in das Quell-ARN-Feld einzutragen. Bei den folgenden Aufrufen sollten Sie als Quell-ARN den tatsächlichen Quell-ARN angeben, den Sie beim ersten Aufruf ermittelt haben. Weitere Informationen finden Sie unter [Confused-Deputy-Prävention](Subscriptions-confused-deputy.md).
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Action": "sts:AssumeRole"
}
}
```
1. Verwenden Sie den Befehl **aws iam create-role**, um die IAM-Rolle zu erstellen und die Vertrauensrichtlinie anzugeben. Notieren Sie sich den zurückgegebenen Role.Arn-Wert, da er später auch an Logs übergeben wird: CloudWatch
```
aws iam create-role \
--role-name CWLtoKinesisRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Principal": {
"Service": "logs.amazonaws.com"
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2023-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisRole",
"Path": "/",
"Arn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
}
}
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um zu definieren, welche Aktionen CloudWatch Logs auf Ihrem Konto ausführen kann. Verwenden Sie zunächst einen Texteditor, um eine Berechtigungsrichtlinie in einer Datei **\$1/ PermissionsFor CWL.json** zu erstellen:
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
}
]
}
```
1. **Ordnen Sie die Berechtigungsrichtlinie der Rolle zu, indem Sie den Befehl aws iam verwenden: put-role-policy**
```
aws iam put-role-policy \
--role-name CWLtoKinesisRole \
--policy-name Permissions-Policy-For-CWL \
--policy-document file://~/PermissionsForCWL.json
```
1. Nachdem sich der Stream im aktiven Status befindet und Sie die IAM-Rolle erstellt haben, können Sie das CloudWatch Logs-Ziel erstellen.
1. In diesem Schritt wird keine Zugriffsrichtlinie mit Ihrem Ziel verknüpft. Es ist zudem erst der erste von zwei Schritten zum Erstellen eines Ziels. Notieren Sie sich den in der Nutzlast ausgegebenen Wert **DestinationArn**:
```
aws logs put-destination \
--destination-name "testDestination" \
--target-arn "arn:aws:kinesis:region:999999999999:stream/RecipientStream" \
--role-arn "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
{
"DestinationName" : "testDestination",
"RoleArn" : "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
"DestinationArn" : "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"TargetArn" : "arn:aws:kinesis:us-east-1:999999999999:stream/RecipientStream"
}
```
1. Verknüpfen Sie, nachdem Schritt 7a abgeschlossen ist, im Empfängerkonto der Protokolldaten eine Zugriffsrichtlinie mit dem Ziel. Diese Richtlinie muss die PutSubscriptionFilter Aktion **logs:** spezifizieren und erteilt dem Absenderkonto die Erlaubnis, auf das Ziel zuzugreifen.
Die Richtlinie erteilt dem AWS Konto, das Protokolle sendet, die entsprechenden Berechtigungen. Sie können nur dieses eine Konto in der Richtlinie angeben, oder wenn das Senderkonto Mitglied einer Organisation ist, kann die Richtlinie die Organisations-ID der Organisation angeben. Auf diese Weise können Sie nur eine Richtlinie erstellen, mit der mehrere Konten in einer Organisation Protokolle an dieses Zielkonto senden können.
Verwenden Sie einen Texteditor, um eine Datei mit dem Namen `~/AccessPolicy.json` mit einer der folgenden Richtlinienanweisungen zu erstellen.
Diese erste Beispielrichtlinie ermöglicht es allen Konten in der Organisation, die die ID `o-1234567890` haben, Protokolle an das Empfängerkonto zu senden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-1234567890"
]
}
}
}
]
}
```
------
In diesem nächsten Beispiel kann nur das Protokolldatenabsenderkonto (111111111111) Protokolle an das Protokolldatenempfängerkonto senden.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "111111111111"
},
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
}
]
}
```
------
1. Fügen Sie die Richtlinie, die Sie im vorherigen Schritt erstellt haben, dem Ziel an.
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/AccessPolicy.json
```
Diese Zugriffsrichtlinie ermöglicht es Benutzern im AWS Konto mit der ID 111111111111, **PutSubscriptionFilter**gegen das Ziel mit ARN arn:aws:logs ::999999999999:destination:TestDestination anzurufen. *region* Jeder Versuch PutSubscriptionFilter eines anderen Benutzers, für dieses Ziel anzurufen, wird abgewiesen.
Informationen dazu, wie Sie die Berechtigungen eines Benutzers mit einer Zugriffsrichtlinie prüfen, finden Sie unter [Verwenden der Richtlinienvalidierung](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html) im *IAM-Benutzerhandbuch*.
Wenn Sie fertig sind und AWS Organizations für Ihre kontoübergreifenden Berechtigungen verwenden, folgen Sie den Schritten unter[Schritt 2: (Nur bei Verwendung einer Organisation) Erstellen Sie eine IAM-Rolle](CreateSubscriptionFilter-IAMrole-Account.md). Wenn Sie dem anderen Konto Berechtigungen direkt erteilen, anstatt Organizations zu verwenden, können Sie diesen Schritt überspringen und mit fortfahren [Schritt 3: Erstellen Sie eine Abonnementfilterrichtlinie auf Kontoebene](CreateSubscriptionFilter-Account.md).
# Schritt 2: (Nur bei Verwendung einer Organisation) Erstellen Sie eine IAM-Rolle
Wenn Sie im vorherigen Abschnitt das Ziel mithilfe einer Zugriffsrichtlinie erstellt haben, die der Organisation, in der sich Konto `111111111111` befindet, Berechtigungen erteilt, anstatt Konto `111111111111` direkt Berechtigungen zu erteilen, führen Sie die Schritte in diesem Abschnitt aus. Andernfalls können Sie mit [Schritt 3: Erstellen Sie eine Abonnementfilterrichtlinie auf Kontoebene](CreateSubscriptionFilter-Account.md) fortfahren.
Mit den Schritten in diesem Abschnitt wird eine IAM-Rolle erstellt, die davon ausgehen und überprüfen CloudWatch kann, ob das Absenderkonto berechtigt ist, einen Abonnementfilter für das Empfängerziel zu erstellen.
Führen Sie die Schritte in diesem Abschnitt im Sender-Konto aus. Die Rolle muss im Sender-Konto vorhanden sein, und Sie geben den ARN dieser Rolle im Abonnementfilter an. In diesem Beispiel ist das Sender-Konto `111111111111`.
**Um die IAM-Rolle zu erstellen, die für kontoübergreifende Protokollabonnements erforderlich ist, verwenden Sie AWS Organizations**
1. Erstellen Sie die folgende Vertrauensrichtlinie in einer Datei namens `/TrustPolicyForCWLSubscriptionFilter.json`. Erstellen Sie in einem Text-Editor die Richtliniendatei, verwenden Sie nicht die IAM-Konsole.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Erstellen Sie als Nächstes die IAM-Rolle, die diese Richtlinie verwendet. Notieren Sie sich den `Arn`-Wert, der vom Befehl zurückgegeben wird, Sie benötigen ihn später in diesem Verfahren. In diesem Beispiel verwenden wir `CWLtoSubscriptionFilterRole` für den Namen der Rolle, die wir erstellen.
```
aws iam create-role \
--role-name CWLtoSubscriptionFilterRole \
--assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um die Aktionen zu definieren, die CloudWatch Logs auf Ihrem Konto ausführen kann.
1. Verwenden Sie zunächst einen Text-Editor, um die folgende Berechtigungsrichtlinie in einer Datei mit dem Namen zu erstellen `~/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Geben Sie den folgenden Befehl ein, um die soeben erstellte Berechtigungsrichtlinie mit der Rolle zu verknüpfen, die Sie in Schritt 2 erstellt haben.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
Wenn Sie fertig sind, können Sie mit [Schritt 3: Erstellen Sie eine Abonnementfilterrichtlinie auf Kontoebene](CreateSubscriptionFilter-Account.md) fortfahren.
# Schritt 3: Erstellen Sie eine Abonnementfilterrichtlinie auf Kontoebene
Wenn Sie ein Ziel erstellt haben, kann das Empfängerkonto der Protokolldaten den Ziel-ARN (arn:aws:logs:us-east-1:999999999999:destination:testDestination) für andere AWS -Konten freigeben, damit diese Protokollereignisse an dasselbe Ziel senden können. Die anderen sendenden Kontobenutzer erstellen einen Abonnementfilter für die jeweiligen Protokollgruppen für dieses Ziel. Der Abonnementfilter startet sofort den Fluss der Echtzeit-Protokolldaten aus der gewählten Protokollgruppe an das angegebene Ziel.
**Anmerkung**
Wenn Sie einer gesamten Organisation Berechtigungen für den Abonnementfilter gewähren, müssen Sie den ARN der IAM-Rolle verwenden, die Sie in [Schritt 2: (Nur bei Verwendung einer Organisation) Erstellen Sie eine IAM-Rolle](CreateSubscriptionFilter-IAMrole-Account.md) erstellt haben.
Im folgenden Beispiel wird eine Abonnementfilterrichtlinie auf Kontoebene in einem Absenderkonto erstellt. Der Filter ist dem Absenderkonto zugeordnet, `111111111111` sodass jedes Protokollereignis, das den Filter- und Auswahlkriterien entspricht, an das zuvor erstellte Ziel gesendet wird. Dieses Ziel kapselt einen Stream namens "“. RecipientStream
Das `selection-criteria` Feld ist optional, aber wichtig, um Protokollgruppen, die zu einer unendlichen Protokollrekursion führen können, aus einem Abonnementfilter auszuschließen. Weitere Informationen zu diesem Problem und zur Bestimmung, welche Protokollgruppen ausgeschlossen werden sollen, finden Sie unter[Verhinderung der Rekursion von Protokollen](Subscriptions-recursion-prevention.md). Derzeit ist NOT IN der einzige unterstützte Operator für`selection-criteria`.
```
aws logs put-account-policy \
--policy-name "CrossAccountStreamsExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:logs:region:999999999999:destination:testDestination", "FilterPattern": "", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
Die Protokollgruppen des Absenderkontos und das Ziel müssen sich in derselben AWS Region befinden. Das Ziel kann jedoch auf eine AWS Ressource verweisen, z. B. auf einen Amazon Kinesis Data Streams Streams-Stream, der sich in einer anderen Region befindet.
# Validierung des Ablaufs von Protokollereignissen
Nachdem Sie die Abonnementfilterrichtlinie auf Kontoebene erstellt haben, leitet CloudWatch Logs alle eingehenden Protokollereignisse, die dem Filtermuster und den Auswahlkriterien entsprechen, an den Stream weiter, der im Zielstream mit dem Namen "" gekapselt ist. **RecipientStream** Der Besitzer des Ziels kann überprüfen, ob dies der Fall ist, indem er den get-shard-iterator Befehl **aws kinesis** verwendet, um einen Amazon Kinesis Data Streams Streams-Shard abzurufen, und den Befehl **aws kinesis get-records verwendet, um einige Amazon Kinesis** Data Streams Streams-Datensätze abzurufen:
```
aws kinesis get-shard-iterator \
--stream-name RecipientStream \
--shard-id shardId-000000000000 \
--shard-iterator-type TRIM_HORIZON
{
"ShardIterator":
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
}
aws kinesis get-records \
--limit 10 \
--shard-iterator
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiKEXAMPLE"
```
**Anmerkung**
Möglicherweise müssen Sie den `get-records` Befehl einige Male erneut ausführen, bevor Amazon Kinesis Data Streams Daten zurückgibt.
Sie sollten eine Antwort mit einer Reihe von Amazon Kinesis Data Streams Streams-Datensätzen sehen. Das Datenattribut im Amazon Kinesis Data Streams Streams-Datensatz wird im GZIP-Format komprimiert und anschließend base64-codiert. Sie können die Rohdaten über die Befehlszeile mit dem folgenden Unix-Befehl überprüfen:
```
echo -n "" | base64 -d | zcat
```
Die dekodierten und dekomprimierten base64-Daten sind als JSON mit folgender Struktur formatiert:
```
{
"owner": "111111111111",
"logGroup": "CloudTrail/logs",
"logStream": "111111111111_CloudTrail/logs_us-east-1",
"subscriptionFilters": [
"RecipientStream"
],
"messageType": "DATA_MESSAGE",
"logEvents": [
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "3195310660696698337880902507980421114328961542429EXAMPLE",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
]
}
```
Die wichtigsten Elemente der Datenstruktur sind die folgenden:
**messageType**
Datennachrichten verwenden den Typ "DATA\$1MESSAGE". Manchmal geben CloudWatch Logs Amazon Kinesis Data Streams Streams-Datensätze mit dem Typ „CONTROL\$1MESSAGE“ aus, hauptsächlich um zu überprüfen, ob das Ziel erreichbar ist.
**owner**
Die AWS Konto-ID der ursprünglichen Protokolldaten.
**logGroup**
Der Name der Protokollgruppe der ursprünglichen Protokolldaten.
**logStream**
Der Name des Protokoll-Stream der ursprünglichen Protokolldaten.
**subscriptionFilters**
Die Namenliste der Abonnementfilter, die mit den ursprünglichen Protokolldaten übereingestimmt haben.
**logEvents**
Die tatsächlichen Protokolldaten, die als Array von Protokollereignis-Datensätzen dargestellt werden. Die "id"-Eigenschaft ist eine eindeutige Kennung für jedes Protokollereignis.
**Richtlinienebene**
Die Ebene, auf der die Richtlinie durchgesetzt wurde. „ACCOUNT\$1LEVEL\$1POLICY“ ist die Filterrichtlinie `policyLevel` für Abonnements auf Kontoebene.
# Ändern der Mitgliedschaft im Ziel zur Laufzeit
In manchen Situationen müssen Sie die Mitgliedschaft einiger Benutzer in einem Ziel, das Ihr Eigentum ist, hinzufügen oder entfernen. Sie können den Befehl `put-destination-policy` für Ihr Ziel mit einer neuen Zugriffsrichtlinie verwenden. Im folgenden Beispiel wird festgelegt, dass das zuvor hinzugefügte Konto **111111111111** keine Protokolldaten mehr sendet und das Konto **222222222222** aktiviert wird.
1. Rufen Sie die Richtlinie ab, die derzeit mit dem Ziel **TestDestination** verknüpft ist, und notieren Sie sich Folgendes: **AccessPolicy**
```
aws logs describe-destinations \
--destination-name-prefix "testDestination"
{
"Destinations": [
{
"DestinationName": "testDestination",
"RoleArn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole",
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"TargetArn": "arn:aws:kinesis:region:999999999999:stream/RecipientStream",
"AccessPolicy": "{\"Version\": \"2012-10-17\", \"Statement\": [{\"Sid\": \"\", \"Effect\": \"Allow\", \"Principal\": {\"AWS\": \"111111111111\"}, \"Action\": \"logs:PutSubscriptionFilter\", \"Resource\": \"arn:aws:logs:region:999999999999:destination:testDestination\"}] }"
}
]
}
```
1. Aktualisieren Sie die Richtlinie, sodass angezeigt wird, dass das Konto **111111111111** angehalten wurde und das Konto **222222222222** aktiviert wurde. Fügen Sie diese Richtlinie in die Datei **\$1/ NewAccessPolicy** .json ein:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "222222222222"
},
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination"
}
]
}
```
------
1. Rufen Sie **PutDestinationPolicy**auf, um die in der **NewAccessPolicy.json-Datei** definierte Richtlinie dem Ziel zuzuordnen:
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Damit werden schließlich die Protokollereignisse von der Konto-ID **111111111111** deaktiviert. Protokollereignisse der Konto-ID **222222222222** werden an das Ziel übertragen, sobald der Eigentümer des Kontos **222222222222** einen Abonnementfilter erstellt.
# Aktualisieren eines bestehenden kontoübergreifenden Abonnements
Wenn Sie derzeit über ein kontoübergreifendes Protokoll-Abonnement verfügen, bei dem das Zielkonto Berechtigungen nur bestimmten Senderkonten gewährt, und Sie dieses Abonnement aktualisieren möchten, damit das Zielkonto Zugriff auf alle Konten in einer Organisation gewährt, führen Sie die Schritte in diesem Abschnitt aus.
**Topics**
+ [Schritt 1: Aktualisieren der Abonnementfilter](Cross-Account-Log_Subscription-Update-filter-Account.md)
+ [Schritt 2: Aktualisieren der bestehenden Richtlinie für die Zugriffsrichtlinie](Cross-Account-Log_Subscription-Update-policy-Account.md)
# Schritt 1: Aktualisieren der Abonnementfilter
**Anmerkung**
Dieser Schritt ist nur für kontenübergreifende Abonnements für Protokolle erforderlich, die von den in [Protokollierung von AWS Diensten aktivieren](AWS-logs-and-resource-policy.md) aufgeführten Services erstellt werden. Wenn Sie nicht mit Protokollen arbeiten, die von einer dieser Protokollgruppen erstellt wurden, können Sie zu [Schritt 2: Aktualisieren der bestehenden Richtlinie für die Zugriffsrichtlinie](Cross-Account-Log_Subscription-Update-policy-Account.md) wechseln.
In bestimmten Fällen müssen Sie die Abonnementfilter in allen Absenderkonten aktualisieren, die Protokolle an das Zielkonto senden. Das Update fügt eine IAM-Rolle hinzu, die davon ausgehen und überprüfen CloudWatch kann, dass das Absenderkonto berechtigt ist, Protokolle an das Empfängerkonto zu senden.
Befolgen Sie die Schritte in diesem Abschnitt für jedes Senderkonto, das Sie aktualisieren möchten, um die Organisations-ID für die kontoübergreifenden Abonnementberechtigungen zu verwenden.
In den Beispielen in diesem Abschnitt wurden für zwei Konten, `111111111111` und `222222222222`, bereits Abonnementfilter erstellt, um Protokolle an Konto `999999999999` zu senden. Die vorhandenen Abonnementfilterwerte lauten wie folgt:
```
## Existing Subscription Filter parameter values
{
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"FilterPattern": "{$.userIdentity.type = Root}",
"Distribution": "Random"
}
```
Wenn Sie die aktuellen Parameterwerte des Abonnementfilters suchen müssen, geben Sie den folgenden Befehl ein.
```
aws logs describe-account-policies \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-name "CrossAccountStreamsExamplePolicy"
```
**Um einen Abonnementfilter zu aktualisieren, um ab sofort Organisation IDs für kontoübergreifende Protokollberechtigungen zu verwenden**
1. Erstellen Sie die folgende Vertrauensrichtlinie in einer Datei namens `~/TrustPolicyForCWL.json`. Erstellen Sie in einem Text-Editor die Richtliniendatei, verwenden Sie nicht die IAM-Konsole.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Erstellen Sie als Nächstes die IAM-Rolle, die diese Richtlinie verwendet. Notieren Sie sich den `Arn`-Wert des `Arn`-Werts, der vom Befehl zurückgegeben wird, den Sie später in diesem Verfahren benötigen. In diesem Beispiel verwenden wir `CWLtoSubscriptionFilterRole` für den Namen der Rolle, die wir erstellen.
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.json
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um die Aktionen zu definieren, die CloudWatch Logs auf Ihrem Konto ausführen kann.
1. Verwenden Sie zunächst einen Text-Editor, um die folgende Berechtigungsrichtlinie in einer Datei mit dem Namen zu erstellen `/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Geben Sie den folgenden Befehl ein, um die soeben erstellte Berechtigungsrichtlinie mit der Rolle zu verknüpfen, die Sie in Schritt 2 erstellt haben.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
1. Geben Sie den folgenden Befehl ein, um die Abonnementfilterrichtlinie zu aktualisieren.
```
aws logs put-account-policy \
--policy-name "CrossAccountStreamsExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:logs:region:999999999999:destination:testDestination", "FilterPattern": "{$.userIdentity.type = Root}", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
# Schritt 2: Aktualisieren der bestehenden Richtlinie für die Zugriffsrichtlinie
Nachdem Sie die Abonnementfilter in allen Senderkonten aktualisiert haben, können Sie die Zielzugriffsrichtlinie im Empfängerkonto aktualisieren.
In den folgenden Beispielen ist das Empfängerkonto `999999999999` und das Ziel hat den Namen `testDestination`.
Das Update ermöglicht es allen Konten, die Teil der Organisation mit der ID `o-1234567890` sind, Protokolle an das Empfängerkonto zu senden. Nur die Konten, für die Abonnementfilter erstellt wurden, senden tatsächlich Protokolle an das Empfängerkonto.
**So aktualisieren Sie die Zielzugriffsrichtlinie im Empfängerkonto, um eine Organisations-ID für Berechtigungen zu verwenden**
1. Verwenden Sie im Empfängerkonto einen Texteditor, um eine `~/AccessPolicy.json`-Datei mit dem folgenden Inhalt zu erstellen.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": "*",
"Action": [
"logs:PutSubscriptionFilter",
"logs:PutAccountPolicy"
],
"Resource": "arn:aws:logs:us-east-1:999999999999:destination:testDestination",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": [
"o-1234567890"
]
}
}
}
]
}
```
------
1. Geben Sie den folgenden Befehl ein, um die Richtlinie, die Sie soeben erstellt haben, dem vorhandenen Ziel anzufügen. Um ein Ziel so zu aktualisieren, dass es eine Zugriffsrichtlinie mit einer Organisations-ID anstelle einer Zugriffsrichtlinie verwendet, in der ein bestimmtes AWS Konto aufgeführt ist IDs, geben Sie den `force` Parameter an.
**Warnung**
Wenn Sie mit Protokollen arbeiten, die von einem AWS Dienst gesendet wurden, der unter aufgeführt ist[Protokollierung von AWS Diensten aktivieren](AWS-logs-and-resource-policy.md), müssen Sie, bevor Sie diesen Schritt ausführen, zuerst die Abonnementfilter in allen Absenderkonten aktualisiert haben, wie unter beschrieben[Schritt 1: Aktualisieren der Abonnementfilter](Cross-Account-Log_Subscription-Update-filter-Account.md).
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Kontoübergreifende, regionsübergreifende Abonnements auf Kontoebene mit Firehose
Wenn Sie Protokolldaten für mehrere Konten freigeben möchten, müssen Sie Sender und Receiver der Protokolldaten festlegen:
+ **Absender der Protokolldaten** — Ruft die Zielinformationen vom Empfänger ab und teilt Logs mit, dass CloudWatch Logs bereit ist, seine Protokollereignisse an das angegebene Ziel zu senden. In den Verfahren im Rest dieses Abschnitts wird der Absender der Protokolldaten mit der fiktiven AWS Kontonummer 1111111111 angezeigt.
+ **Empfänger von Protokolldaten** — richtet ein Ziel ein, das einen Amazon Kinesis Data Streams Streams-Stream kapselt und CloudWatch Logs darüber informiert, dass der Empfänger Protokolldaten empfangen möchte. Der Empfänger gibt dann die Informationen über sein Ziel für den Absender frei. In den Verfahren im Rest dieses Abschnitts wird der Empfänger der Protokolldaten mit der fiktiven AWS Kontonummer 222222222222 angezeigt.
Das Beispiel in diesem Abschnitt verwendet einen Firehose-Lieferstream mit Amazon S3 S3-Speicher. Sie können Firehose-Lieferstreams auch mit unterschiedlichen Einstellungen einrichten. Weitere Informationen finden Sie unter [Firehose Delivery Stream erstellen](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).
**Anmerkung**
Die Protokollgruppe und das Ziel müssen sich in derselben AWS Region befinden. Die AWS Ressource, auf die das Ziel verweist, kann sich jedoch in einer anderen Region befinden.
**Anmerkung**
Der Firehose-Abonnementfilter für ***dasselbe Konto*** und denselben ***regionsübergreifenden*** Lieferstream wird unterstützt.
**Topics**
+ [Schritt 1: Erstellen Sie einen Firehose-Lieferstream](CreateFirehoseStream-Account.md)
+ [Schritt 2: Erstellen eines Ziels](CreateFirehoseStreamDestination-Account.md)
+ [Schritt 3: Erstellen Sie eine Abonnementfilterrichtlinie auf Kontoebene](CreateSubscriptionFilterFirehose-Account.md)
+ [Validierung des Flusses von Protokollereignissen](ValidateLogEventFlowFirehose-Account.md)
+ [Ändern der Mitgliedschaft im Ziel zur Laufzeit](ModifyDestinationMembershipFirehose-Account.md)
# Schritt 1: Erstellen Sie einen Firehose-Lieferstream
**Wichtig**
Bevor Sie die folgenden Schritte ausführen, müssen Sie eine Zugriffsrichtlinie verwenden, damit Firehose auf Ihren Amazon S3 S3-Bucket zugreifen kann. Weitere Informationen finden Sie unter [Zugriffskontrolle](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3) im *Amazon Data Firehose Developer Guide*.
Alle Schritte in diesem Abschnitt (Schritt 1) müssen im Konto des Protokolldatenempfängers ausgeführt werden.
USA Ost (Nord-Virginia) wird in den folgenden Beispielbefehlen verwendet. Ersetzen Sie diese Region durch die richtige Region für Ihre Bereitstellung.
**Um einen Firehose-Lieferstream zu erstellen, der als Ziel verwendet werden soll**
1. Erstellen eines Amazon-S3-Buckets:
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. Erstellen Sie die IAM-Rolle, die Firehose die Berechtigung erteilt, Daten in den Bucket zu legen.
1. Verwenden Sie zunächst einen Text-Editor zum Erstellen einer Vertrauensrichtlinie in einer Datei `~/TrustPolicyForFirehose.json`.
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. Erstellen Sie die IAM-Rolle und geben Sie die Datei mit der Vertrauensrichtlinie an, die Sie gerade erstellt haben.
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. Die Ausgabe für den Befehl sieht dann wie folgt aus. Notieren Sie sich den Rollennamen und die Rollen-ARN.
```
{
"Role": {
"Path": "/",
"RoleName": "FirehosetoS3Role",
"RoleId": "AROAR3BXASEKW7K635M53",
"Arn": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"CreateDate": "2021-02-02T07:53:10+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "222222222222"
}
}
}
}
}
}
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um die Aktionen zu definieren, die Firehose in Ihrem Konto ausführen kann.
1. Verwenden Sie zunächst einen Text-Editor, um die folgende Berechtigungsrichtlinie in einer Datei mit dem Namen zu erstellen `~/PermissionsForFirehose.json`. Abhängig von Ihrem Anwendungsfall müssen Sie dieser Datei möglicherweise weitere Berechtigungen hinzufügen.
```
{
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}]
}
```
1. Geben Sie den folgenden Befehl ein, um die soeben erstellte Berechtigungsrichtlinie der IAM-Rolle zuzuordnen.
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. Geben Sie den folgenden Befehl ein, um den Firehose-Lieferstream zu erstellen. Ersetzen Sie *my-role-arn* und *amzn-s3-demo-bucket2-arn* durch die richtigen Werte für Ihre Bereitstellung.
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket"}'
```
Die Ausgabe sollte folgendermaßen oder ähnlich aussehen:
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# Schritt 2: Erstellen eines Ziels
**Wichtig**
Alle Schritte in diesem Verfahren müssen im Konto des Protokolldatenempfängers ausgeführt werden.
Wenn das Ziel erstellt wurde, sendet CloudWatch Logs im Namen des Empfängerkontos eine Testnachricht an das Ziel. Wenn der Abonnementfilter später aktiv ist, sendet CloudWatch Logs im Namen des Quellkontos Protokollereignisse an das Ziel.
**So erstellen Sie ein Ziel**
1. Warten Sie, bis der Firehose-Stream, in dem Sie ihn erstellt haben, aktiv [Schritt 1: Erstellen Sie einen Firehose-Lieferstream](CreateFirehoseStream-Account.md) wird. **Sie können den folgenden Befehl verwenden, um das StreamDescription zu überprüfen. StreamStatus**Eigentum.
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
Beachten Sie außerdem die **DeliveryStreamDescription. DeliveryStreamARN-Wert**, da Sie ihn in einem späteren Schritt verwenden müssen. Beispielausgabe dieses Befehls:
```
{
"DeliveryStreamDescription": {
"DeliveryStreamName": "my-delivery-stream",
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamEncryptionConfiguration": {
"Status": "DISABLED"
},
"DeliveryStreamType": "DirectPut",
"VersionId": "1",
"CreateTimestamp": "2021-02-01T23:59:15.567000-08:00",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
}
},
"ExtendedS3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
},
"S3BackupMode": "Disabled"
}
}
],
"HasMoreDestinations": false
}
}
```
Es kann einige Minuten dauern, bis der Bereitstellungsdatenstrom im aktiven Status angezeigt wird.
1. Wenn der Lieferstream aktiv ist, erstellen Sie die IAM-Rolle, die CloudWatch Logs die Erlaubnis erteilt, Daten in Ihren Firehose-Stream einzufügen. Zunächst müssen Sie eine Vertrauensrichtlinie in einer Datei **TrustPolicyFor\$1/** CWL.json erstellen. Verwenden Sie einen Text-Editor, um diese Richtlinie zu erstellen. Weitere Informationen zu CloudWatch Logs-Endpunkten finden Sie unter [Amazon CloudWatch Logs-Endpunkte und](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html) Kontingente.
Diese Richtlinie enthält einen globalen Bedingungskontextschlüssel `aws:SourceArn`, der das `sourceAccountId` angibt, um das Confused-Deputy-Problem zu vermeiden. Wenn Sie die Quell-Kontonummer beim ersten Aufruf noch nicht kennen, empfehlen wir Ihnen, die Ziel-ARN in das Quell-ARN-Feld einzutragen. Bei den folgenden Aufrufen sollten Sie als Quell-ARN den tatsächlichen Quell-ARN angeben, den Sie beim ersten Aufruf ermittelt haben. Weitere Informationen finden Sie unter [Confused-Deputy-Prävention](Subscriptions-confused-deputy.md).
```
{
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
```
1. Verwenden Sie den Befehl **aws iam create-role**, um die IAM-Rolle zu erstellen und geben Sie die Datei mit der Vertrauensrichtlinie an, die Sie gerade erstellt haben.
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
Dies ist eine Beispielausgabe. Notieren Sie den zurückgegebenen `Role.Arn`-Wert, da Sie ihn in einem späteren Schritt benötigen.
```
{
"Role": {
"Path": "/",
"RoleName": "CWLtoKinesisFirehoseRole",
"RoleId": "AROAR3BXASEKYJYWF243H",
"Arn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"CreateDate": "2023-02-02T08:10:43+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
}
}
```
1. Erstellen Sie eine Berechtigungsrichtlinie, um zu definieren, welche Aktionen CloudWatch Logs auf Ihrem Konto ausführen kann. Verwenden Sie zunächst einen Texteditor, um eine Berechtigungsrichtlinie in einer Datei **\$1/ PermissionsFor CWL.json** zu erstellen:
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. Verknüpfen Sie mit dem folgenden Befehl die Berechtigungsrichtlinie mit der Rolle:
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Nachdem sich der Firehose-Lieferstream im aktiven Zustand befindet und Sie die IAM-Rolle erstellt haben, können Sie das CloudWatch Logs-Ziel erstellen.
1. In diesem Schritt wird keine Zugriffsrichtlinie mit Ihrem Ziel verknüpft. Es ist zudem erst der erste von zwei Schritten zum Erstellen eines Ziels. Notieren Sie sich die in der Nutzlast zurückgegebene ARN des neuen Zielortes, da Sie diese in einem späteren Schritt als `destination.arn` verwenden werden.
```
aws logs put-destination \
--destination-name "testFirehoseDestination" \
--target-arn "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream" \
--role-arn "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole"
{
"destination": {
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"arn": "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"}
}
```
1. Verknüpfen Sie, nachdem der vorherige Schritt abgeschlossen ist, im Empfängerkonto der Protokolldaten (222222222222) eine Zugriffsrichtlinie mit dem Ziel. Diese Richtlinie ermöglicht dem Sender-Konto der Protokolldaten (111111111111), auf das Ziel nur im Empfängerkonto der Protokolldaten (222222222222) zuzugreifen. Sie können einen Texteditor verwenden, um diese Richtlinie in die `~/AccessPolicy.json` Datei einzufügen:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "111111111111"
},
"Action" : ["logs:PutSubscriptionFilter","logs:PutAccountPolicy"],
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. Damit wird eine Richtlinie erstellt, die bestimmt, wer Schreibzugriff auf das Ziel hat. In dieser Richtlinie müssen die `logs:PutAccountPolicy` Aktionen `logs:PutSubscriptionFilter` und für den Zugriff auf das Ziel angegeben werden. Kontoübergreifende Benutzer verwenden die `PutAccountPolicy` Aktionen `PutSubscriptionFilter` und, um Protokollereignisse an das Ziel zu senden.
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# Schritt 3: Erstellen Sie eine Abonnementfilterrichtlinie auf Kontoebene
Wechseln Sie zum Senderkonto, das in diesem Beispiel 111111111111 lautet. Sie werden nun die Abonnementfilterrichtlinie auf Kontoebene im sendenden Konto erstellen. In diesem Beispiel bewirkt der Filter, dass jedes Protokollereignis, das die Zeichenfolge enthält, `ERROR` in allen außer zwei Protokollgruppen an das Ziel gesendet wird, das Sie zuvor erstellt haben.
```
aws logs put-account-policy \
--policy-name "CrossAccountFirehoseExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination", "FilterPattern": "{$.userIdentity.type = AssumedRole}", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
Die Protokollgruppen des sendenden Kontos und das Ziel müssen sich in derselben AWS Region befinden. Das Ziel kann jedoch auf eine AWS Ressource verweisen, z. B. auf einen Firehose-Stream, der sich in einer anderen Region befindet.
# Validierung des Flusses von Protokollereignissen
Nachdem Sie den Abonnementfilter erstellt haben, leitet CloudWatch Logs alle eingehenden Protokollereignisse, die dem Filtermuster und den Auswahlkriterien entsprechen, an den Firehose-Lieferstream weiter. Die Daten werden in Ihrem Amazon S3 S3-Bucket basierend auf dem Zeitpufferintervall angezeigt, das für den Firehose-Lieferstream festgelegt ist. Sobald genügend Zeit abgelaufen ist, können Sie die Daten im Amazon-S3-Bucket überprüfen. Geben Sie zur Prüfung des Buckets den folgenden Befehl ein:
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
Die Ausgabe des Befehls sieht dann wie folgt aus:
```
{
"Contents": [
{
"Key": "2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba",
"LastModified": "2023-02-02T09:00:26+00:00",
"ETag": "\"EXAMPLEa817fb88fc770b81c8f990d\"",
"Size": 198,
"StorageClass": "STANDARD",
"Owner": {
"DisplayName": "firehose+2test",
"ID": "EXAMPLE27fd05889c665d2636218451970ef79400e3d2aecca3adb1930042e0"
}
}
]
}
```
Sie können dann ein bestimmtes Objekt aus dem Bucket abrufen, indem Sie den folgenden Befehl eingeben. Ersetzen Sie den Wert von `key` mit dem Wert, den Sie im vorherigen Befehl gefunden haben.
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket' --key '2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba' testfile.gz
```
Die Daten im Amazon-S3-Objekt sind im GZIP-Format komprimiert. Sie können die Rohdaten über die Befehlszeile mit einem der folgenden Befehlen überprüfen:
Linux:
```
zcat testfile.gz
```
macOS:
```
zcat
In manchen Situationen müssen Sie Protokollsender in einem Ziel, das Ihr Eigentum ist, hinzufügen oder entfernen. Mit der neuen Zugriffsrichtlinie können Sie die `PutAccountPolicy` Aktionen **PutDestinationPolicy**und auf Ihrem Ziel verwenden. Im folgenden Beispiel wird festgelegt, dass das zuvor hinzugefügte Konto **111111111111** keine Protokolldaten mehr senden kann und das Konto **333333333333** aktiviert wird.
1. Rufen Sie die Richtlinie ab, die derzeit mit dem Ziel **TestDestination** verknüpft ist, und notieren Sie sich Folgendes: **AccessPolicy**
```
aws logs describe-destinations \
--destination-name-prefix "testFirehoseDestination"
```
Die zurückgegebenen Daten könnten so aussehen.
```
{
"destinations": [
{
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam:: 222222222222:role/CWLtoKinesisFirehoseRole",
"accessPolicy": "{\n \"Version\" : \"2012-10-17\",\n \"Statement\" : [\n {\n \"Sid\" : \"\",\n \"Effect\" : \"Allow\",\n \"Principal\" : {\n \"AWS\" : \"111111111111 \"\n },\n \"Action\" : \"logs:PutSubscriptionFilter\",\n \"Resource\" : \"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination\"\n }\n ]\n}\n\n",
"arn": "arn:aws:logs:us-east-1: 222222222222:destination:testFirehoseDestination",
"creationTime": 1612256124430
}
]
}
```
1. Aktualisieren Sie die Richtlinie dementsprechend, dass das Konto **111111111111** angehalten wurde und das Konto **333333333333** aktiviert wurde. Fügen Sie diese Richtlinie in die Datei **\$1/ NewAccessPolicy .json** ein:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "333333333333 "
},
"Action" : ["logs:PutSubscriptionFilter","logs:PutAccountPolicy"],
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. Verwenden Sie den folgenden Befehl, um die in der **NewAccessPolicyJSON-Datei** definierte Richtlinie dem Ziel zuzuordnen:
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Damit werden schließlich die Protokollereignisse von der Konto-ID **111111111111** deaktiviert. Protokollereignisse der Konto-ID **333333333333** werden an das Ziel übertragen, sobald der Eigentümer des Kontos **333333333333** einen Abonnementfilter erstellt.