Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Traitement en temps réel des données du journal avec les abonnements
Vous pouvez utiliser des abonnements pour accéder à un flux en temps réel des événements du journal depuis CloudWatch Logs et le transmettre à d'autres services tels qu'un flux Amazon Kinesis, un flux Amazon Data Firehose, ou AWS Lambda pour un traitement, une analyse ou un chargement personnalisés sur d'autres systèmes. Lorsque les événements du journal sont envoyés au service récepteur, ils sont codés en base64 et compressés au format gzip.
Vous pouvez également utiliser la centralisation CloudWatch des journaux pour répliquer les données des journaux de plusieurs comptes et régions vers un emplacement central. Pour de plus amples informations, veuillez consulter [Centralisation des journaux inter-comptes et inter-régions](CloudWatchLogs_Centralization.md).
Pour commencer à vous abonner pour enregistrer les événements, créez la ressource de réception, telle qu'un flux Amazon Kinesis Data Streams, dans lequel les événements seront diffusés. Un filtre d'abonnement définit le modèle de filtre à utiliser pour filtrer les événements du journal transmis à votre AWS ressource, ainsi que les informations indiquant à qui envoyer les événements de journal correspondants. Les événements du journal sont envoyés à la ressource réceptrice peu après avoir été ingérés, généralement en moins de trois minutes.
**Note**
Si un groupe de journaux abonné utilise la transformation des journaux, le modèle de filtre est comparé aux versions transformées des événements du journal. Pour de plus amples informations, veuillez consulter [Transformez les journaux lors de l'ingestion](CloudWatch-Logs-Transformation.md).
Vous pouvez créer des abonnements au niveau du compte et au niveau du groupe de log. Chaque compte peut avoir un filtre d'abonnement au niveau du compte par région. Chaque groupe de journaux peut avoir jusqu'à deux filtres d'abonnement associés.
**Note**
Si le service de destination renvoie une erreur réessayable, telle qu'une exception de limitation ou une exception de service réessayable (HTTP 5xx par exemple), CloudWatch Logs continue de réessayer la livraison pendant 24 heures au maximum. CloudWatch Logs n'essaie pas de le renvoyer s'il s'agit d'une erreur non réessayable, telle que ou. AccessDeniedException ResourceNotFoundException Dans ces cas, le filtre d'abonnement est désactivé pendant 10 minutes au maximum, puis CloudWatch Logs tente à nouveau d'envoyer les journaux à la destination. Pendant cette période de désactivation, les journaux sont ignorés.
CloudWatch Logs produit également CloudWatch des métriques concernant le transfert des événements du journal aux abonnements. Pour de plus amples informations, veuillez consulter [Surveillance à l'aide de CloudWatch métriques](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md).
Vous pouvez également utiliser un abonnement CloudWatch Logs pour diffuser les données des journaux en temps quasi réel vers un cluster Amazon OpenSearch Service. Pour plus d'informations, consultez la section [Streaming CloudWatch Logs data to Amazon OpenSearch Service](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html).
Les abonnements ne sont pris en charge que pour les groupes de journaux de la classe de journaux standard. Pour plus d'informations sur les classes de log, consultez[Classes de log](CloudWatch_Logs_Log_Classes.md).
**Note**
Les filtres d'abonnement peuvent enregistrer les événements par lots afin d'optimiser la transmission et de réduire le nombre d'appels passés vers la destination. Le dosage n'est pas garanti mais est utilisé dans la mesure du possible.
Pour le traitement par lots et l'analyse des données du journal selon un calendrier, pensez à utiliser[Automatisation de l'analyse des journaux avec des requêtes planifiées](ScheduledQueries.md). Les requêtes planifiées exécutent automatiquement les requêtes CloudWatch Logs Insights et fournissent des résultats à des destinations telles que les buckets Amazon S3 ou les bus d' EventBridge événements Amazon.
**Note**
Les filtres d'abonnement garantissent la diffusion d'événements au moins une fois, tandis que des événements dupliqués peuvent parfois se produire.
**Topics**
+ [Concepts](subscription-concepts.md)
+ [Filtres d'abonnement au niveau des groupes de journaux](SubscriptionFilters.md)
+ [Filtres d'abonnement au niveau du compte](SubscriptionFilters-AccountLevel.md)
+ [Abonnements entre comptes et entre régions](CrossAccountSubscriptions.md)
+ [Prévention du député confus](Subscriptions-confused-deputy.md)
+ [Prévention de la récursivité dans les journaux](Subscriptions-recursion-prevention.md)
# Concepts
Chaque filtre d'abonnement est composé des principaux éléments suivants :
**filter pattern**
Une description symbolique de la façon dont les CloudWatch journaux doivent interpréter les données de chaque événement du journal, ainsi que des expressions de filtrage qui limitent ce qui est livré à la AWS ressource de destination. Pour plus d'informations sur la syntaxe des modèles de filtrage, consultez [Syntaxe des modèles de filtres pour les filtres de métriques, les filtres d'abonnements, les filtres d'événements du journal et Live Tail](FilterAndPatternSyntax.md).
**destination arn**
Le nom de ressource Amazon (ARN) du flux Amazon Kinesis Data Streams, du flux Firehose ou de la fonction Lambda que vous souhaitez utiliser comme destination du flux d'abonnement.
**ARN de rôle**
Rôle IAM qui accorde à CloudWatch Logs les autorisations nécessaires pour placer des données dans la destination choisie. Ce rôle n'est pas nécessaire pour les destinations Lambda car CloudWatch Logs peut obtenir les autorisations nécessaires à partir des paramètres de contrôle d'accès de la fonction Lambda elle-même.
**distribution**
La méthode utilisée pour distribuer les données du journal à la destination, lorsque la destination est un flux dans Amazon Kinesis Data Streams. Par défaut, les données des journaux sont regroupées par flux de journaux. Pour assurer une meilleure répartition de la distribution, vous pouvez regrouper les données des journaux de manière aléatoire.
Pour les abonnements au niveau des groupes de journaux, l'élément clé suivant est également inclus :
**log group name**
Le groupe de journaux auquel associer le filtre d'abonnement. Tous les événements du journal téléchargés vers ce groupe de journaux sont soumis au filtre d'abonnement. Ceux qui correspondent au filtre sont envoyés au service de destination qui reçoit les événements du journal correspondants.
Pour les abonnements au niveau du compte, l'élément clé suivant est également inclus :
**critères de sélection**
Critères utilisés pour sélectionner les groupes de journaux auxquels le filtre d'abonnement au niveau du compte est appliqué. Si vous ne le spécifiez pas, le filtre d'abonnement au niveau du compte est appliqué à tous les groupes de journaux du compte. Ce champ est utilisé pour empêcher les boucles de log infinies. Pour plus d'informations sur le problème des boucles de log infinies, consultez[Prévention de la récursivité dans les journaux](Subscriptions-recursion-prevention.md).
Les critères de sélection ont une limite de taille de 25 Ko.
Pour les groupes de journaux centralisés, les éléments clés suivants sont également inclus. Ces éléments peuvent être utilisés comme critères de sélection de champs pour aider à identifier la source des données des journaux, ce qui permet un filtrage plus granulaire et une analyse des métriques dérivées des journaux centralisés.
**@aws .account**
Ce champ identifie l'identifiant du AWS compte à l'origine de l'événement du journal.
**@aws .région**
Ce champ identifie la AWS région dans laquelle l'événement du journal a été généré.
# Filtres d'abonnement au niveau des groupes de journaux
Vous pouvez utiliser un filtre d'abonnement avec Amazon Kinesis Data Streams AWS Lambda, Amazon Data Firehose ou Amazon Service. OpenSearch Les journaux envoyés à un service via un filtre d'abonnement sont codés en base64 et compressés au format gzip. Si vous utilisez des journaux centralisés avec votre AWS Organizations, vous pouvez choisir d'émettre le champ `@aws.region` système `@aws.account` et pour identifier quelles données proviennent de quels comptes et régions de votre organisation. Cette section fournit des exemples que vous pouvez suivre pour créer un filtre d'abonnement aux CloudWatch journaux qui envoie les données des journaux à Firehose, Lambda, Amazon Kinesis Data Streams et Service. OpenSearch
**Note**
Si vous souhaitez effectuer une recherche dans les données de votre journal, consultez la section [Syntaxe des filtres et](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html) des modèles.
**Topics**
+ [Exemple 1 : filtres d'abonnement avec Amazon Kinesis Data Streams](#DestinationKinesisExample)
+ [Exemple 2 : filtres d'abonnement avec AWS Lambda](#LambdaFunctionExample)
+ [Exemple 3 : filtres d'abonnement avec Amazon Data Firehose](#FirehoseExample)
+ [Exemple 4 : filtres d'abonnement avec Amazon OpenSearch Service](#OpenSearchExample)
## Exemple 1 : filtres d'abonnement avec Amazon Kinesis Data Streams
L'exemple suivant associe un filtre d'abonnement à un groupe de journaux contenant des événements AWS CloudTrail . Le filtre d'abonnement transmet toutes les activités enregistrées à l'aide des AWS informations d'identification « root » à un flux appelé « RootAccess » dans Amazon Kinesis Data Streams. Pour plus d'informations sur la façon d'envoyer AWS CloudTrail des événements aux CloudWatch journaux, consultez la section [Envoyer CloudTrail des événements aux CloudWatch journaux](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cw_send_ct_events.html) dans le *guide de AWS CloudTrail l'utilisateur*.
**Note**
Avant de créer le flux , calculez le volume de données de journaux qui sera généré. Assurez-vous de créer un flux avec suffisamment de partitions pour gérer le volume. Si le flux n'a pas suffisamment de partitions, le flux de journaux sera limité. Pour plus d'informations sur les limites de volume de flux, consultez [Quotas et limites](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) (français non garanti).
Les livrables limités sont réessayés pendant 24 heures au maximum. Au bout de 24 heures, les livrables ayant échoué sont supprimés.
Pour réduire le risque de limitation, procédez comme suit :
Spécifiez `random` le `distribution` moment où vous créez le filtre d'abonnement avec [ PutSubscriptionFilter](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutSubscriptionFilter.html#CWL-PutSubscriptionFilter-request-distribution)ou [ put-subscription-filter](https://awscli.amazonaws.com/v2/documentation/api/2.4.18/reference/logs/put-subscription-filter.html). Par défaut, la distribution du filtre de flux se fait par flux de log, ce qui peut entraîner un ralentissement.
Surveillez votre stream à l'aide de CloudWatch métriques. Cela vous permet d'identifier toute limitation et d'ajuster votre configuration en conséquence. Par exemple, la `DeliveryThrottling` métrique peut être utilisée pour suivre le nombre d'événements de journal pour lesquels CloudWatch Logs a été limité lors du transfert des données vers la destination de l'abonnement. Pour de plus amples informations sur la surveillance, veuillez consulter [Surveillance à l'aide de CloudWatch métriques](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md).
Utilisez le mode de capacité à la demande pour votre flux dans Amazon Kinesis Data Streams. Le mode de capacité à la demande s'adapte instantanément à vos charges de travail à mesure qu'elles augmentent ou diminuent. Pour plus d'informations sur le mode de capacité à la demande, consultez [Mode de capacité à la demande](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-size-a-stream.html#ondemandmode).
Limitez votre modèle de filtre CloudWatch d'abonnement pour qu'il corresponde à la capacité de votre flux dans Amazon Kinesis Data Streams. Si vous envoyez trop de données dans le flux, il se peut que vous deviez réduire la taille du filtre ou ajuster les critères de filtrage.
**Pour créer un filtre d'abonnement pour Amazon Kinesis Data Streams**
1. Créez un flux de destination à l'aide de la commande suivante :
```
$ C:\> aws kinesis create-stream --stream-name "RootAccess" --shard-count 1
```
1. Attendez que le flux devienne actif (cela peut prendre une minute ou deux). **Vous pouvez utiliser la commande Amazon Kinesis Data [Streams](https://docs.aws.amazon.com/cli/latest/reference/kinesis/describe-stream.html) describe-stream suivante pour vérifier le. StreamDescription StreamStatus**propriété. Notez également la valeur **StreamDescription.StreamArn**, car vous en aurez besoin ultérieurement :
```
aws kinesis describe-stream --stream-name "RootAccess"
```
Voici un exemple de sortie :
```
{
"StreamDescription": {
"StreamStatus": "ACTIVE",
"StreamName": "RootAccess",
"StreamARN": "arn:aws:kinesis:us-east-1:123456789012:stream/RootAccess",
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"EndingHashKey": "340282366920938463463374607431768211455",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber":
"49551135218688818456679503831981458784591352702181572610"
}
}
]
}
}
```
1. Créez le rôle IAM qui autorisera CloudWatch Logs à insérer des données dans votre flux. Vous devrez tout d'abord créer une stratégie d'approbation dans un fichier (par exemple, `~/TrustPolicyForCWL-Kinesis.json`). Utilisez un éditeur de texte créer cette stratégie. N'utilisez pas la console IAM pour la créer.
Cette politique comprend une clé de contexte de condition `aws:SourceArn` globale pour aider à prévenir le problème de sécurité du député confus. Pour plus d'informations, consultez [Prévention du député confus](Subscriptions-confused-deputy.md).
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": { "aws:SourceArn": "arn:aws:logs:region:123456789012:*" }
}
}
}
```
1. Utilisez la commande **create-role** pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation. Notez la valeur retournée de **Role.Arn**, car vous en aurez aussi besoin ultérieurement :
```
aws iam create-role --role-name CWLtoKinesisRole --assume-role-policy-document file://~/TrustPolicyForCWL-Kinesis.json
```
Voici un exemple de la sortie.
```
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": { "arn:aws:logs:region:123456789012:*" }
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisRole",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisRole"
}
}
```
1. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte. Vous allez tout d'abord créer une stratégie d'autorisations dans un fichier (par exemple, `~/PermissionsForCWL-Kinesis.json`). Utilisez un éditeur de texte créer cette stratégie. N'utilisez pas la console IAM pour la créer.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:123456789012:stream/RootAccess"
}
]
}
```
1. Associez la politique d’autorisations au rôle à la commande [put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) suivante :
```
aws iam put-role-policy --role-name CWLtoKinesisRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL-Kinesis.json
```
1. Une fois que le flux est en état **actif** et que vous avez créé le rôle IAM, vous pouvez créer le filtre d'abonnement CloudWatch Logs. Le filtre d'abonnement lance immédiatement la transmission de données de journaux en temps réel à partir du groupe de journaux choisi vers votre flux :
```
aws logs put-subscription-filter \
--log-group-name "CloudTrail/logs" \
--filter-name "RootAccess" \
--filter-pattern "{$.userIdentity.type = Root}" \
--destination-arn "arn:aws:kinesis:region:123456789012:stream/RootAccess" \
--role-arn "arn:aws:iam::123456789012:role/CWLtoKinesisRole"
```
1. Après avoir configuré le filtre d'abonnement, CloudWatch Logs transmet à votre stream tous les événements de journal entrants correspondant au modèle de filtre. Vous pouvez vérifier que c'est bien le cas en accédant à un itérateur de partition Amazon Kinesis Data Streams et en utilisant la commande Amazon Kinesis Data Streams get-records pour récupérer certains enregistrements Amazon Kinesis Data Streams :
```
aws kinesis get-shard-iterator --stream-name RootAccess --shard-id shardId-000000000000 --shard-iterator-type TRIM_HORIZON
```
```
{
"ShardIterator":
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiK2OSh0uP"
}
```
```
aws kinesis get-records --limit 10 --shard-iterator "AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiK2OSh0uP"
```
Notez que vous devrez peut-être effectuer cet appel plusieurs fois avant qu'Amazon Kinesis Data Streams ne commence à renvoyer des données.
Vous devriez obtenir une réponse constituée d'un tableau d'enregistrements. L'attribut **Data** d'un enregistrement Amazon Kinesis Data Streams est codé en base64 et compressé au format gzip. Vous pouvez examiner les données brutes à partir de la ligne de commande au moyen des commandes Unix suivantes :
```
echo -n "" | base64 -d | zcat
```
Les données codées et décompressées en base64 sont formatées au format JSON avec la structure suivante :
```
{
"owner": "111111111111",
"logGroup": "CloudTrail/logs",
"logStream": "111111111111_CloudTrail/logs_us-east-1",
"subscriptionFilters": [
"Destination"
],
"messageType": "DATA_MESSAGE",
"logEvents": [
{
"id": "31953106606966983378809025079804211143289615424298221568",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221569",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221570",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
]
}
```
Les éléments clés de la structure de données ci-dessus sont les suivants :
**owner**
L'ID de AWS compte des données du journal d'origine.
**logGroup**
Le nom du groupe de journaux des données du journal source.
**logStream**
Le nom du flux de journaux des données du journal source.
**subscriptionFilters**
La liste des noms de filtres d'abonnements qui correspondaient aux données du journal source.
**messageType**
Les données de messages utiliseront le type « DATA\$1MESSAGE ». Parfois, CloudWatch Logs peut émettre des enregistrements Amazon Kinesis Data Streams de type « CONTROL\$1MESSAGE », principalement pour vérifier si la destination est accessible.
**logEvents**
Les données du journal réelles, représentées sous la forme d'un tableau d'enregistrements d'événements du journal. La propriété « id » est un identifiant unique pour chaque événement de journal.
## Exemple 2 : filtres d'abonnement avec AWS Lambda
Dans cet exemple, vous allez créer un filtre d'abonnement CloudWatch aux journaux qui envoie les données des journaux à votre AWS Lambda fonction.
**Note**
Avant de créer la fonction Lambda, calculez le volume de données du journal qui sera généré. Veillez à créer une fonction qui peut gérer ce volume. Si la fonction n'a pas suffisamment de volume, le flux de journaux sera limité. Pour plus d'informations sur les limites Lambda, consultez [Limites AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/limits.html).
**Pour créer un filtre d'abonnements pour Lambda**
1. Créez la AWS Lambda fonction.
Assurez-vous d'avoir configuré le rôle d'exécution Lambda. Pour plus d'informations, consultez [Étape 2.2 : Créer un rôle IAM (rôle d'exécution)](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) dans le *Guide du développeur AWS Lambda *.
1. Ouvrez un éditeur de texte et créez un fichier nommé `helloWorld.js` avec le contenu suivant :
```
var zlib = require('zlib');
exports.handler = function(input, context) {
var payload = Buffer.from(input.awslogs.data, 'base64');
zlib.gunzip(payload, function(e, result) {
if (e) {
context.fail(e);
} else {
result = JSON.parse(result.toString());
console.log("Event Data:", JSON.stringify(result, null, 2));
context.succeed();
}
});
};
```
1. Zippez le fichier helloWorld.js et enregistrez-le sous le nom `helloWorld.zip`.
1. Utilisez la commande suivante, où le rôle correspond au rôle d'exécution Lambda que vous avez configuré à la première étape :
```
aws lambda create-function \
--function-name helloworld \
--zip-file fileb://file-path/helloWorld.zip \
--role lambda-execution-role-arn \
--handler helloWorld.handler \
--runtime nodejs12.x
```
1. Accordez à CloudWatch Logs l'autorisation d'exécuter votre fonction. Utilisez la commande suivante en remplaçant l'espace réservé au compte par votre propre compte et l'espace réservé au groupe de journaux par le groupe de journaux à traiter :
```
aws lambda add-permission \
--function-name "helloworld" \
--statement-id "helloworld" \
--principal "logs.amazonaws.com" \
--action "lambda:InvokeFunction" \
--source-arn "arn:aws:logs:region:123456789123:log-group:TestLambda:*" \
--source-account "123456789012"
```
1. Créez un filtre d'abonnements à l'aide de la commande suivante en remplaçant l'espace réservé au compte par votre propre compte et l'espace réservé au groupe de journaux par le groupe de journaux à traiter :
```
aws logs put-subscription-filter \
--log-group-name myLogGroup \
--filter-name demo \
--filter-pattern "" \
--destination-arn arn:aws:lambda:region:123456789123:function:helloworld
```
1. (Facultatif) Testez au moyen d'un exemple d'événement de journal. A l'invite de commande, exécutez la commande suivante, qui mettra un message de journal simple dans le flux abonné.
Pour voir le résultat de votre fonction Lambda, accédez à la fonction Lambda où vous verrez le résultat dans/: aws/lambda/helloworld
```
aws logs put-log-events --log-group-name myLogGroup --log-stream-name stream1 --log-events "[{\"timestamp\": , \"message\": \"Simple Lambda Test\"}]"
```
Vous devriez voir une réponse comportant un tableau de Lambda. L'attribut **Data** du registre Lambda est codé en base64 et compressé au format gzip. La charge utile réelle reçue par Lambda est au format suivant `{ "awslogs": {"data": "BASE64ENCODED_GZIP_COMPRESSED_DATA"} }`. Vous pouvez examiner les données brutes à partir de la ligne de commande au moyen des commandes Unix suivantes :
```
echo -n "" | base64 -d | zcat
```
Les données codées et décompressées en base64 sont formatées au format JSON avec la structure suivante :
```
{
"owner": "123456789012",
"logGroup": "CloudTrail",
"logStream": "123456789012_CloudTrail_us-east-1",
"subscriptionFilters": [
"Destination"
],
"messageType": "DATA_MESSAGE",
"logEvents": [
{
"id": "31953106606966983378809025079804211143289615424298221568",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221569",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221570",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
]
}
```
Les éléments clés de la structure de données ci-dessus sont les suivants :
**owner**
L'ID de AWS compte des données du journal d'origine.
**logGroup**
Le nom du groupe de journaux des données du journal source.
**logStream**
Le nom du flux de journaux des données du journal source.
**subscriptionFilters**
La liste des noms de filtres d'abonnements qui correspondaient aux données du journal source.
**messageType**
Les données de messages utiliseront le type « DATA\$1MESSAGE ». Parfois, CloudWatch Logs peut émettre des enregistrements Lambda de type « CONTROL\$1MESSAGE », principalement pour vérifier si la destination est accessible.
**logEvents**
Les données du journal réelles, représentées sous la forme d'un tableau d'enregistrements d'événements du journal. La propriété « id » est un identifiant unique pour chaque événement de journal.
## Exemple 3 : filtres d'abonnement avec Amazon Data Firehose
Dans cet exemple, vous allez créer un abonnement CloudWatch Logs qui envoie tous les événements de log entrants correspondant aux filtres que vous avez définis à votre flux de diffusion Amazon Data Firehose. Les données envoyées par CloudWatch Logs à Amazon Data Firehose sont déjà compressées avec la compression gzip de niveau 6. Vous n'avez donc pas besoin d'utiliser la compression dans votre flux de diffusion Firehose. Vous pouvez ensuite utiliser la fonction de décompression de Firehose pour décompresser automatiquement les journaux. Pour plus d'informations, consultez [Envoyer CloudWatch des journaux à Firehose](https://docs.aws.amazon.com/logs/SubscriptionFilters.html#FirehoseExample).
**Note**
Avant de créer le flux Firehose, calculez le volume de données de journal qui sera généré. Assurez-vous de créer un flux Firehose capable de gérer ce volume. Si le flux ne peut pas traiter le volume, le flux de journaux sera limité. Pour plus d'informations sur les limites de volume de flux Firehose, consultez [Amazon Data Firehose Data](https://docs.aws.amazon.com/firehose/latest/dev/limits.html) Limits.
**Pour créer un filtre d'abonnement pour Firehose**
1. Créez un compartiment Amazon Simple Storage Service (Amazon S3). Nous vous recommandons d'utiliser un bucket créé spécifiquement pour CloudWatch Logs. Toutefois, si vous souhaitez utiliser un compartiment existant, passez directement à l'étape 2.
Exécutez la commande suivante en remplaçant l'espace réservé à la région par la région que vous voulez utiliser :
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
Voici un exemple de sortie :
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Créez le rôle IAM qui autorise Amazon Data Firehose à placer des données dans votre compartiment Amazon S3.
Pour plus d'informations, consultez la section [Contrôler l'accès avec Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html) dans le manuel du développeur *Amazon Data Firehose*.
D'abord, utilisez un éditeur de texte pour créer une politique d'approbation dans un fichier `~/TrustPolicyForFirehose.json` comme suit :
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "firehose.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Utilisez la commande **create-role** pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation. Notez la valeur retournée de **Role.Arn**, car vous en aurez besoin ultérieurement :
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "FirehosetoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/FirehosetoS3Role"
}
}
```
1. Créez une politique d'autorisation pour définir les actions que Firehose peut effectuer sur votre compte. D'abord, utilisez un éditeur de texte pour créer une stratégie d'autorisations dans un fichier `~/PermissionsForFirehose.json` :
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:PutObject" ],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket2",
"arn:aws:s3:::amzn-s3-demo-bucket2/*" ]
}
]
}
```
1. Associez la politique d’autorisations au rôle à la commande put-role-policy suivante :
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose --policy-document file://~/PermissionsForFirehose.json
```
1. Créez un flux de diffusion Firehose de destination comme suit, en remplaçant les valeurs d'espace réservé pour Rolearn **et BucketArn par le rôle et** le bucket que **vous avez** créés : ARNs
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::123456789012:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket2"}'
```
Notez que Firehose utilise automatiquement un préfixe au format YYYY/MM/DD/HH UTC pour les objets Amazon S3 livrés. Vous pouvez spécifier un préfixe supplémentaire à ajouter devant le préfixe de format temporel. Si le préfixe se termine par une barre oblique (/), il apparaît comme un dossier dans le compartiment Amazon S3.
1. Attendez que le flux devienne actif (cela peut prendre quelques minutes). **Vous pouvez utiliser la **describe-delivery-stream**commande Firehose pour vérifier le. DeliveryStreamDescription DeliveryStreamStatus**propriété. En outre, notez le **DeliveryStreamDescription. DeliveryStreamValeur de l'ARN**, dont vous aurez besoin ultérieurement :
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
{
"DeliveryStreamDescription": {
"HasMoreDestinations": false,
"VersionId": "1",
"CreateTimestamp": 1446075815.822,
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:123456789012:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamName": "my-delivery-stream",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"RoleARN": "delivery-stream-role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket2",
"BufferingHints": {
"IntervalInSeconds": 300,
"SizeInMBs": 5
}
}
}
]
}
}
```
1. Créez le rôle IAM qui autorise CloudWatch Logs à insérer des données dans votre flux de diffusion Firehose. D'abord, utilisez un éditeur de texte pour créer une stratégie d'approbation dans un fichier `~/TrustPolicyForCWL.json` :
Cette politique comprend une clé de contexte de condition `aws:SourceArn` globale pour aider à prévenir le problème de sécurité du député confus. Pour plus d'informations, consultez [Prévention du député confus](Subscriptions-confused-deputy.md).
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
}
```
1. Utilisez la commande **create-role** pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation. Notez la valeur retournée de **Role.Arn**, car vous en aurez besoin ultérieurement :
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisFirehoseRole",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole"
}
}
```
1. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte. D'abord, utilisez un éditeur de texte pour créer une stratégie d'autorisations dans un fichier (par exemple, `~/PermissionsForCWL.json`) :
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:PutRecord"],
"Resource":[
"arn:aws:firehose:region:account-id:deliverystream/delivery-stream-name"]
}
]
}
```
1. Associez la politique d'autorisations au rôle à l'aide de la put-role-policy commande :
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Une fois que le flux de diffusion Amazon Data Firehose est actif et que vous avez créé le rôle IAM, vous pouvez créer le filtre d'abonnement CloudWatch Logs. Le filtre d'abonnement lance immédiatement le flux de données de journal en temps réel entre le groupe de journaux choisi et votre flux de diffusion Amazon Data Firehose :
```
aws logs put-subscription-filter \
--log-group-name "CloudTrail" \
--filter-name "Destination" \
--filter-pattern "{$.userIdentity.type = Root}" \
--destination-arn "arn:aws:firehose:region:123456789012:deliverystream/my-delivery-stream" \
--role-arn "arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole"
```
1. Une fois le filtre d'abonnement configuré, CloudWatch Logs transmet tous les événements de journal entrants correspondant au modèle de filtre à votre flux de diffusion Amazon Data Firehose. Vos données commenceront à apparaître dans votre Amazon S3 en fonction de l'intervalle de temps défini sur votre flux de diffusion Amazon Data Firehose. Après un délai suffisant, vous pouvez consulter votre compartiment Amazon S3 pour vérifier vos données.
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket2' --prefix 'firehose/'
{
"Contents": [
{
"LastModified": "2015-10-29T00:01:25.000Z",
"ETag": "\"a14589f8897f4089d3264d9e2d1f1610\"",
"StorageClass": "STANDARD",
"Key": "firehose/2015/10/29/00/my-delivery-stream-2015-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250",
"Owner": {
"DisplayName": "cloudwatch-logs",
"ID": "1ec9cf700ef6be062b19584e0b7d84ecc19237f87b5"
},
"Size": 593
},
{
"LastModified": "2015-10-29T00:35:41.000Z",
"ETag": "\"a7035b65872bb2161388ffb63dd1aec5\"",
"StorageClass": "STANDARD",
"Key": "firehose/2015/10/29/00/my-delivery-stream-2015-10-29-00-35-40-7cc92023-7e66-49bc-9fd4-fc9819cc8ed3",
"Owner": {
"DisplayName": "cloudwatch-logs",
"ID": "1ec9cf700ef6be062b19584e0b7d84ecc19237f87b6"
},
"Size": 5752
}
]
}
```
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket2' --key 'firehose/2015/10/29/00/my-delivery-stream-2015-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250' testfile.gz
{
"AcceptRanges": "bytes",
"ContentType": "application/octet-stream",
"LastModified": "Thu, 29 Oct 2015 00:07:06 GMT",
"ContentLength": 593,
"Metadata": {}
}
```
Les données dans l'objet Amazon S3 sont comprimées au format gzip. Vous pouvez examiner les données brutes à partir de la ligne de commande au moyen de la commande Unix suivante :
```
zcat testfile.gz
```
## Exemple 4 : filtres d'abonnement avec Amazon OpenSearch Service
Dans cet exemple, vous allez créer un abonnement CloudWatch Logs qui envoie à votre domaine de OpenSearch service les événements de journal entrants correspondant aux filtres que vous avez définis.
**Pour créer un filtre d'abonnement pour le OpenSearch service**
1. Créez un domaine OpenSearch de service. Pour plus d'informations, voir [Création de domaines OpenSearch de service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/createupdatedomains.html#createdomains)
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Groupes de journaux**.
1. Sélectionnez le nom du groupe de journaux.
1. Choisissez **Actions**, **Filtres d'abonnement**, puis **Créer un filtre d'abonnement Amazon OpenSearch Service**.
1. Choisissez si vous souhaitez diffuser en continu vers un cluster de ce compte ou un autre compte.
+ Si vous avez choisi **Ce compte**, sélectionnez le domaine que vous avez créé à l'étape 1.
+ Si vous avez choisi **Un autre compte**, entrez l'ARN et le point de terminaison de ce domaine.
1. Si vous avez choisi un autre compte, fournissez l'ARN du domaine et le point de terminaison.
1. Pour le cluster Amazon OpenSearch Service, choisissez le nom du cluster dans lequel les données du groupe de journaux seront livrées.
1. Choisissez un format de journal.
1. Pour le **modèle de filtre d'abonnement**, entrez les termes ou le modèle à rechercher dans les événements de votre journal. Cela garantit que vous n'envoyez que les données qui vous intéressent à votre cluster OpenSearch de services. Pour de plus amples informations, veuillez consulter [Syntaxe des modèles de filtres pour les filtres de métriques](FilterAndPatternSyntaxForMetricFilters.md).
1. (Facultatif) Pour **Select log data to test** (Sélectionner les données de journal à tester), sélectionnez un flux de journal, puis choisissez **Test pattern** (Modèle de test) afin de vérifier que votre filtre de recherche renvoie les résultats attendus.
1. Choisissez **Start streaming** (Démarrer la diffusion).
# Filtres d'abonnement au niveau du compte
**Important**
Il existe un risque de créer une boucle récursive infinie avec des filtres d'abonnement, ce qui peut entraîner une forte augmentation de la facturation en cas d'ingestion si rien n'est fait pour y remédier. Pour atténuer ce risque, nous vous recommandons d'utiliser des critères de sélection dans les filtres d'abonnement au niveau de votre compte afin d'exclure les groupes de journaux qui ingèrent des données de journal provenant de ressources faisant partie du flux de travail de livraison des abonnements. Pour plus d'informations sur ce problème et pour déterminer les groupes de journaux à exclure, consultez[Prévention de la récursivité dans les journaux](Subscriptions-recursion-prevention.md).
Vous pouvez définir une politique d'abonnement au niveau du compte qui inclut un sous-ensemble de groupes de journaux dans le compte. La politique d'abonnement au compte peut fonctionner avec Amazon Kinesis Data Streams AWS Lambda ou Amazon Data Firehose. Les journaux envoyés à un service via une politique d'abonnement au niveau du compte sont codés en base64 et compressés au format gzip. Cette section fournit des exemples que vous pouvez suivre pour créer un abonnement au niveau du compte pour Amazon Kinesis Data Streams, Lambda et Firehose.
**Note**
Pour consulter la liste de toutes les politiques de filtrage des abonnements de votre compte, utilisez la `describe-account-policies` commande dont la valeur est `SUBSCRIPTION_FILTER_POLICY` pour le `--policy-type` paramètre. Pour plus d'informations, consultez [ describe-account-policies¶](https://docs.aws.amazon.com/cli/latest/reference/logs/describe-account-policies.html).
**Topics**
+ [Exemple 1 : filtres d'abonnement avec Amazon Kinesis Data Streams](#DestinationKinesisExample-AccountLevel)
+ [Exemple 2 : filtres d'abonnement avec AWS Lambda](#LambdaFunctionExample-AccountLevel)
+ [Exemple 3 : filtres d'abonnement avec Amazon Data Firehose](#FirehoseExample-AccountLevel)
## Exemple 1 : filtres d'abonnement avec Amazon Kinesis Data Streams
Avant de créer un flux de données Amazon Kinesis Data Streams à utiliser dans le cadre d'une politique d'abonnement au niveau du compte, calculez le volume de données de journal qui sera généré. Assurez-vous de créer un flux avec suffisamment de partitions pour gérer le volume. Si un flux ne contient pas suffisamment de partitions, il est limité. Pour plus d'informations sur les limites de volume de flux, consultez la section [Quotas et limites](https://docs.aws.amazon.com/streams/latest/dev/service-sizes-and-limits.html) dans la documentation Amazon Kinesis Data Streams.
**Avertissement**
Les événements de journal de plusieurs groupes de journaux étant transférés vers la destination, il existe un risque de limitation. Les livrables limités sont réessayés pendant 24 heures au maximum. Au bout de 24 heures, les livrables ayant échoué sont supprimés.
Pour réduire le risque de limitation, procédez comme suit :
Surveillez votre flux Amazon Kinesis Data Streams à l' CloudWatch aide de métriques. Cela vous permet d'identifier les ralentissements et d'ajuster votre configuration en conséquence. Par exemple, la `DeliveryThrottling` métrique suit le nombre d'événements de journal pour lesquels CloudWatch Logs a été limité lors du transfert des données vers la destination de l'abonnement. Pour de plus amples informations, veuillez consulter [Surveillance à l'aide de CloudWatch métriques](CloudWatch-Logs-Monitoring-CloudWatch-Metrics.md).
Utilisez le mode de capacité à la demande pour votre flux dans Amazon Kinesis Data Streams. Le mode de capacité à la demande s'adapte instantanément à vos charges de travail à mesure qu'elles augmentent ou diminuent. Pour plus d'informations, consultez [la section Mode à la demande](https://docs.aws.amazon.com/streams/latest/dev/how-do-i-size-a-stream.html#ondemandmode).
Limitez le modèle de filtre de votre abonnement à CloudWatch Logs pour qu'il corresponde à la capacité de votre flux dans Amazon Kinesis Data Streams. Si vous envoyez trop de données dans le flux, il se peut que vous deviez réduire la taille du filtre ou ajuster les critères de filtrage.
L'exemple suivant utilise une politique d'abonnement au niveau du compte pour transférer tous les événements du journal vers un flux dans Amazon Kinesis Data Streams. Le modèle de filtre associe tous les événements du journal au texte `Test` et les transmet au flux dans Amazon Kinesis Data Streams.
**Pour créer une politique d'abonnement au niveau du compte pour Amazon Kinesis Data Streams**
1. Créez un flux de destination à l'aide de la commande suivante :
```
$ C:\> aws kinesis create-stream —stream-name "TestStream" —shard-count 1
```
1. Patientez quelques minutes pour que le stream soit actif. **Vous pouvez vérifier si le flux est actif en utilisant la commande [describe-stream](https://docs.aws.amazon.com/cli/latest/reference/kinesis/describe-stream.html) pour vérifier le. StreamDescription StreamStatus**propriété.
```
aws kinesis describe-stream --stream-name "TestStream"
```
Voici un exemple de sortie :
```
{
"StreamDescription": {
"StreamStatus": "ACTIVE",
"StreamName": "TestStream",
"StreamARN": "arn:aws:kinesis:region:123456789012:stream/TestStream",
"Shards": [
{
"ShardId": "shardId-000000000000",
"HashKeyRange": {
"EndingHashKey": "EXAMPLE8463463374607431768211455",
"StartingHashKey": "0"
},
"SequenceNumberRange": {
"StartingSequenceNumber":
"EXAMPLE688818456679503831981458784591352702181572610"
}
}
]
}
}
```
1. Créez le rôle IAM qui autorisera CloudWatch Logs à insérer des données dans votre flux. Vous devrez tout d'abord créer une stratégie d'approbation dans un fichier (par exemple, `~/TrustPolicyForCWL-Kinesis.json`). Utilisez un éditeur de texte créer cette stratégie.
Cette politique comprend une clé de contexte de condition `aws:SourceArn` globale pour aider à prévenir le problème de sécurité du député confus. Pour plus d'informations, consultez [Prévention du député confus](Subscriptions-confused-deputy.md).
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": { "aws:SourceArn": "arn:aws:logs:region:123456789012:*" }
}
}
}
```
1. Utilisez la commande **create-role** pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation. Notez la valeur retournée de **Role.Arn**, car vous en aurez aussi besoin ultérieurement :
```
aws iam create-role --role-name CWLtoKinesisRole --assume-role-policy-document file://~/TrustPolicyForCWL-Kinesis.json
```
Voici un exemple de la sortie.
```
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": { "arn:aws:logs:region:123456789012:*" }
}
}
}
},
"RoleId": "EXAMPLE450GAB4HC5F431",
"CreateDate": "2023-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisRole",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisRole"
}
}
```
1. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte. Vous allez tout d'abord créer une stratégie d'autorisations dans un fichier (par exemple, `~/PermissionsForCWL-Kinesis.json`). Utilisez un éditeur de texte créer cette stratégie. N'utilisez pas la console IAM pour le créer.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:123456789012:stream/TestStream"
}
]
}
```
1. Associez la politique d’autorisations au rôle à la commande [put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html) suivante :
```
aws iam put-role-policy --role-name CWLtoKinesisRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL-Kinesis.json
```
1. Une fois que le flux est à l'état **actif** et que vous avez créé le rôle IAM, vous pouvez créer la politique de filtrage CloudWatch des abonnements aux journaux. La politique lance immédiatement le flux de données de journal en temps réel vers votre flux. Dans cet exemple, tous les événements du journal contenant la chaîne `ERROR` sont diffusés en continu, à l'exception de ceux des groupes de journaux nommés `LogGroupToExclude1` et`LogGroupToExclude2`.
```
aws logs put-account-policy \
--policy-name "ExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"RoleArn":"arn:aws:iam::123456789012:role/CWLtoKinesisRole", "DestinationArn":"arn:aws:kinesis:region:123456789012:stream/TestStream", "FilterPattern": "Test", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
1. Après avoir configuré le filtre d'abonnement, CloudWatch Logs transmet à votre stream tous les événements de journal entrants correspondant au modèle de filtre et aux critères de sélection.
Ce `selection-criteria` champ est facultatif, mais il est important pour exclure les groupes de journaux susceptibles de provoquer une récursivité infinie des journaux à partir d'un filtre d'abonnement. Pour plus d'informations sur ce problème et pour déterminer les groupes de journaux à exclure, consultez[Prévention de la récursivité dans les journaux](Subscriptions-recursion-prevention.md). NOT IN est actuellement le seul opérateur pris en charge pour`selection-criteria`.
Vous pouvez vérifier que le flux des événements du journal en utilisant un itérateur de partition Amazon Kinesis Data Streams et en utilisant la commande Amazon Kinesis `get-records` Data Streams pour récupérer certains enregistrements Amazon Kinesis Data Streams :
```
aws kinesis get-shard-iterator --stream-name TestStream --shard-id shardId-000000000000 --shard-iterator-type TRIM_HORIZON
```
```
{
"ShardIterator":
"AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiK2OSh0uP"
}
```
```
aws kinesis get-records --limit 10 --shard-iterator "AAAAAAAAAAFGU/kLvNggvndHq2UIFOw5PZc6F01s3e3afsSscRM70JSbjIefg2ub07nk1y6CDxYR1UoGHJNP4m4NFUetzfL+wev+e2P4djJg4L9wmXKvQYoE+rMUiFq+p4Cn3IgvqOb5dRA0yybNdRcdzvnC35KQANoHzzahKdRGb9v4scv+3vaq+f+OIK8zM5My8ID+g6rMo7UKWeI4+IWiK2OSh0uP"
```
Vous devrez peut-être utiliser cette commande plusieurs fois avant qu'Amazon Kinesis Data Streams ne commence à renvoyer des données.
Vous devriez obtenir une réponse constituée d'un tableau d'enregistrements. L'attribut **Data** d'un enregistrement Amazon Kinesis Data Streams est codé en base64 et compressé au format gzip. Vous pouvez examiner les données brutes à partir de la ligne de commande au moyen des commandes Unix suivantes :
```
echo -n "" | base64 -d | zcat
```
Les données codées et décompressées en base64 sont formatées au format JSON avec la structure suivante :
```
{
"messageType": "DATA_MESSAGE",
"owner": "123456789012",
"logGroup": "Example1",
"logStream": "logStream1",
"subscriptionFilters": [
"ExamplePolicy"
],
"logEvents": [
{
"id": "31953106606966983378809025079804211143289615424298221568",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221569",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221570",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
],
"policyLevel": "ACCOUNT_LEVEL_POLICY"
}
```
Les principaux éléments de la structure de données sont les suivants :
**messageType**
Les données de messages utiliseront le type « DATA\$1MESSAGE ». Parfois, CloudWatch Logs peut émettre des enregistrements Amazon Kinesis Data Streams de type « CONTROL\$1MESSAGE », principalement pour vérifier si la destination est accessible.
**owner**
L'ID de AWS compte des données du journal d'origine.
**logGroup**
Le nom du groupe de journaux des données du journal source.
**logStream**
Le nom du flux de journaux des données du journal source.
**subscriptionFilters**
La liste des noms de filtres d'abonnements qui correspondaient aux données du journal source.
**logEvents**
Les données du journal réelles, représentées sous la forme d'un tableau d'enregistrements d'événements du journal. La propriété « id » est un identifiant unique pour chaque événement de journal.
**Niveau de la politique**
Niveau auquel la politique a été appliquée. « ACCOUNT\$1LEVEL\$1POLICY » correspond à une politique de filtrage `policyLevel` d'abonnement au niveau du compte.
## Exemple 2 : filtres d'abonnement avec AWS Lambda
Dans cet exemple, vous allez créer une politique de filtrage d'abonnement au niveau du compte CloudWatch Logs qui envoie les données des journaux à votre AWS Lambda fonction.
**Avertissement**
Avant de créer la fonction Lambda, calculez le volume de données du journal qui sera généré. Veillez à créer une fonction qui peut gérer ce volume. Si la fonction ne peut pas gérer le volume, le flux du journal sera limité. Étant donné que les événements de journal de tous les groupes de journaux ou d'un sous-ensemble des groupes de journaux du compte sont transférés vers la destination, il existe un risque de limitation. Pour plus d'informations sur les limites Lambda, consultez [Limites AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/limits.html).
**Pour créer une politique de filtrage des abonnements au niveau du compte pour Lambda**
1. Créez la AWS Lambda fonction.
Assurez-vous d'avoir configuré le rôle d'exécution Lambda. Pour plus d'informations, consultez [Étape 2.2 : Créer un rôle IAM (rôle d'exécution)](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) dans le *Guide du développeur AWS Lambda *.
1. Ouvrez un éditeur de texte et créez un fichier nommé `helloWorld.js` avec le contenu suivant :
```
var zlib = require('zlib');
exports.handler = function(input, context) {
var payload = Buffer.from(input.awslogs.data, 'base64');
zlib.gunzip(payload, function(e, result) {
if (e) {
context.fail(e);
} else {
result = JSON.parse(result.toString());
console.log("Event Data:", JSON.stringify(result, null, 2));
context.succeed();
}
});
};
```
1. Zippez le fichier helloWorld.js et enregistrez-le sous le nom `helloWorld.zip`.
1. Utilisez la commande suivante, où le rôle correspond au rôle d'exécution Lambda que vous avez configuré à la première étape :
```
aws lambda create-function \
--function-name helloworld \
--zip-file fileb://file-path/helloWorld.zip \
--role lambda-execution-role-arn \
--handler helloWorld.handler \
--runtime nodejs18.x
```
1. Accordez à CloudWatch Logs l'autorisation d'exécuter votre fonction. Utilisez la commande suivante pour remplacer le compte fictif par votre propre compte.
```
aws lambda add-permission \
--function-name "helloworld" \
--statement-id "helloworld" \
--principal "logs.amazonaws.com" \
--action "lambda:InvokeFunction" \
--source-arn "arn:aws:logs:region:123456789012:log-group:*" \
--source-account "123456789012"
```
1. Créez une politique de filtrage des abonnements au niveau du compte à l'aide de la commande suivante, en remplaçant le compte réservé par votre propre compte. Dans cet exemple, tous les événements du journal contenant la chaîne `ERROR` sont diffusés en continu, à l'exception de ceux des groupes de journaux nommés `LogGroupToExclude1` et`LogGroupToExclude2`.
```
aws logs put-account-policy \
--policy-name "ExamplePolicyLambda" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:lambda:region:123456789012:function:helloWorld", "FilterPattern": "Test", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
Après avoir configuré le filtre d'abonnement, CloudWatch Logs transmet à votre stream tous les événements de journal entrants correspondant au modèle de filtre et aux critères de sélection.
Ce `selection-criteria` champ est facultatif, mais il est important pour exclure les groupes de journaux susceptibles de provoquer une récursivité infinie des journaux à partir d'un filtre d'abonnement. Pour plus d'informations sur ce problème et pour déterminer les groupes de journaux à exclure, consultez[Prévention de la récursivité dans les journaux](Subscriptions-recursion-prevention.md). NOT IN est actuellement le seul opérateur pris en charge pour`selection-criteria`.
1. (Facultatif) Testez au moyen d'un exemple d'événement de journal. A l'invite de commande, exécutez la commande suivante, qui mettra un message de journal simple dans le flux abonné.
Pour voir le résultat de votre fonction Lambda, accédez à la fonction Lambda où vous verrez le résultat dans/: aws/lambda/helloworld
```
aws logs put-log-events --log-group-name Example1 --log-stream-name logStream1 --log-events "[{\"timestamp\":CURRENT TIMESTAMP MILLIS , \"message\": \"Simple Lambda Test\"}]"
```
Vous devriez voir une réponse comportant un tableau de Lambda. L'attribut **Data** du registre Lambda est codé en base64 et compressé au format gzip. La charge utile réelle reçue par Lambda est au format suivant `{ "awslogs": {"data": "BASE64ENCODED_GZIP_COMPRESSED_DATA"} }`. Vous pouvez examiner les données brutes à partir de la ligne de commande au moyen des commandes Unix suivantes :
```
echo -n "" | base64 -d | zcat
```
Les données codées et décompressées en base64 sont formatées au format JSON avec la structure suivante :
```
{
"messageType": "DATA_MESSAGE",
"owner": "123456789012",
"logGroup": "Example1",
"logStream": "logStream1",
"subscriptionFilters": [
"ExamplePolicyLambda"
],
"logEvents": [
{
"id": "31953106606966983378809025079804211143289615424298221568",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221569",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
},
{
"id": "31953106606966983378809025079804211143289615424298221570",
"timestamp": 1432826855000,
"message": "{\"eventVersion\":\"1.03\",\"userIdentity\":{\"type\":\"Root\"}"
}
],
"policyLevel": "ACCOUNT_LEVEL_POLICY"
}
```
**Note**
Le filtre d'abonnement au niveau du compte ne sera pas appliqué au groupe de journaux de la fonction Lambda de destination. Cela permet d'éviter une récursivité infinie des logs susceptible d'entraîner une augmentation de la facturation d'ingestion. Pour plus d'informations sur ce problème, consultez[Prévention de la récursivité dans les journaux](Subscriptions-recursion-prevention.md).
Les principaux éléments de la structure de données sont les suivants :
**messageType**
Les données de messages utiliseront le type « DATA\$1MESSAGE ». Parfois, CloudWatch Logs peut émettre des enregistrements Amazon Kinesis Data Streams de type « CONTROL\$1MESSAGE », principalement pour vérifier si la destination est accessible.
**owner**
L'ID de AWS compte des données du journal d'origine.
**logGroup**
Le nom du groupe de journaux des données du journal source.
**logStream**
Le nom du flux de journaux des données du journal source.
**subscriptionFilters**
La liste des noms de filtres d'abonnements qui correspondaient aux données du journal source.
**logEvents**
Les données du journal réelles, représentées sous la forme d'un tableau d'enregistrements d'événements du journal. La propriété « id » est un identifiant unique pour chaque événement de journal.
**Niveau de la politique**
Niveau auquel la politique a été appliquée. « ACCOUNT\$1LEVEL\$1POLICY » correspond à une politique de filtrage `policyLevel` d'abonnement au niveau du compte.
## Exemple 3 : filtres d'abonnement avec Amazon Data Firehose
Dans cet exemple, vous allez créer une politique de filtrage d'abonnement au niveau du compte CloudWatch Logs qui envoie les événements de journal entrants correspondant aux filtres que vous avez définis à votre flux de diffusion Amazon Data Firehose. Les données envoyées par CloudWatch Logs à Amazon Data Firehose sont déjà compressées avec la compression gzip de niveau 6. Vous n'avez donc pas besoin d'utiliser la compression dans votre flux de diffusion Firehose. Vous pouvez ensuite utiliser la fonction de décompression de Firehose pour décompresser automatiquement les journaux. Pour plus d'informations, consultez la section [Écrire dans Kinesis Data CloudWatch Firehose à](https://docs.aws.amazon.com/firehose/latest/dev/writing-with-cloudwatch-logs.html) l'aide de journaux.
**Avertissement**
Avant de créer le flux Firehose, calculez le volume de données de journal qui sera généré. Assurez-vous de créer un flux Firehose capable de gérer ce volume. Si le flux ne peut pas traiter le volume, le flux de journaux sera limité. Pour plus d'informations sur les limites de volume de flux Firehose, consultez [Amazon Data Firehose Data](https://docs.aws.amazon.com/firehose/latest/dev/limits.html) Limits.
**Pour créer un filtre d'abonnement pour Firehose**
1. Créez un compartiment Amazon Simple Storage Service (Amazon S3). Nous vous recommandons d'utiliser un bucket créé spécifiquement pour CloudWatch Logs. Toutefois, si vous souhaitez utiliser un compartiment existant, passez directement à l'étape 2.
Exécutez la commande suivante en remplaçant l'espace réservé à la région par la région que vous voulez utiliser :
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket2 --create-bucket-configuration LocationConstraint=region
```
Voici un exemple de sortie :
```
{
"Location": "/amzn-s3-demo-bucket2"
}
```
1. Créez le rôle IAM qui autorise Amazon Data Firehose à placer des données dans votre compartiment Amazon S3.
Pour plus d'informations, consultez la section [Contrôler l'accès avec Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html) dans le manuel du développeur *Amazon Data Firehose*.
D'abord, utilisez un éditeur de texte pour créer une politique d'approbation dans un fichier `~/TrustPolicyForFirehose.json` comme suit :
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "firehose.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Utilisez la commande **create-role** pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation. Notez la valeur **Role.Arn** renvoyée, car vous en aurez besoin ultérieurement :
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
}
}
},
"RoleId": "EXAMPLE50GAB4HC5F431",
"CreateDate": "2023-05-29T13:46:29.431Z",
"RoleName": "FirehosetoS3Role",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/FirehosetoS3Role"
}
}
```
1. Créez une politique d'autorisation pour définir les actions que Firehose peut effectuer sur votre compte. D'abord, utilisez un éditeur de texte pour créer une stratégie d'autorisations dans un fichier `~/PermissionsForFirehose.json` :
```
{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:AbortMultipartUpload",
"s3:GetBucketLocation",
"s3:GetObject",
"s3:ListBucket",
"s3:ListBucketMultipartUploads",
"s3:PutObject" ],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket2",
"arn:aws:s3:::amzn-s3-demo-bucket2/*" ]
}
]
}
```
1. Associez la politique d’autorisations au rôle à la commande put-role-policy suivante :
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose --policy-document file://~/PermissionsForFirehose.json
```
1. Créez un flux de diffusion Firehose de destination comme suit, en remplaçant les valeurs d'espace réservé pour Rolearn **et BucketArn par le rôle et** le bucket que **vous avez** créés : ARNs
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::123456789012:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket2"}'
```
NFirehose utilise automatiquement un préfixe au format YYYY/MM/DD/HH UTC pour les objets Amazon S3 livrés. Vous pouvez spécifier un préfixe supplémentaire à ajouter devant le préfixe de format temporel. Si le préfixe se termine par une barre oblique (/), il apparaît comme un dossier dans le compartiment Amazon S3.
1. Patientez quelques minutes pour que le stream soit activé. **Vous pouvez utiliser la **describe-delivery-stream**commande Firehose pour vérifier le. DeliveryStreamDescription DeliveryStreamStatus**propriété. En outre, notez le **DeliveryStreamDescription. DeliveryStreamValeur de l'ARN**, dont vous aurez besoin ultérieurement :
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
{
"DeliveryStreamDescription": {
"HasMoreDestinations": false,
"VersionId": "1",
"CreateTimestamp": 1446075815.822,
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:123456789012:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamName": "my-delivery-stream",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"RoleARN": "delivery-stream-role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket2",
"BufferingHints": {
"IntervalInSeconds": 300,
"SizeInMBs": 5
}
}
}
]
}
}
```
1. Créez le rôle IAM qui autorise CloudWatch Logs à insérer des données dans votre flux de diffusion Firehose. D'abord, utilisez un éditeur de texte pour créer une stratégie d'approbation dans un fichier `~/TrustPolicyForCWL.json` :
Cette politique comprend une clé de contexte de condition `aws:SourceArn` globale pour aider à prévenir le problème de sécurité du député confus. Pour plus d'informations, consultez [Prévention du député confus](Subscriptions-confused-deputy.md).
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
}
```
1. Utilisez la commande **create-role** pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation. Notez la valeur **Role.Arn** renvoyée, car vous en aurez besoin ultérieurement :
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Condition": {
"StringLike": {
"aws:SourceArn": "arn:aws:logs:region:123456789012:*"
}
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2015-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisFirehoseRole",
"Path": "/",
"Arn": "arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole"
}
}
```
1. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte. D'abord, utilisez un éditeur de texte pour créer une stratégie d'autorisations dans un fichier (par exemple, `~/PermissionsForCWL.json`) :
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:PutRecord"],
"Resource":[
"arn:aws:firehose:region:account-id:deliverystream/delivery-stream-name"]
}
]
}
```
1. Associez la politique d'autorisations au rôle à l'aide de la put-role-policy commande :
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Une fois que le flux de diffusion Amazon Data Firehose est actif et que vous avez créé le rôle IAM, vous pouvez créer la politique de filtrage des abonnements au niveau du compte CloudWatch Logs. La politique lance immédiatement le flux de données de journal en temps réel du groupe de journaux choisi vers votre flux de diffusion Amazon Data Firehose :
```
aws logs put-account-policy \
--policy-name "ExamplePolicyFirehose" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"RoleArn":"arn:aws:iam::123456789012:role/CWLtoKinesisFirehoseRole", "DestinationArn":"arn:aws:firehose:us-east-1:123456789012:deliverystream/delivery-stream-name", "FilterPattern": "Test", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
1. Après avoir configuré le filtre d'abonnement, CloudWatch Logs transmet les événements de journal entrants correspondant au modèle de filtre à votre flux de diffusion Amazon Data Firehose.
Ce `selection-criteria` champ est facultatif, mais il est important pour exclure les groupes de journaux susceptibles de provoquer une récursivité infinie des journaux à partir d'un filtre d'abonnement. Pour plus d'informations sur ce problème et pour déterminer les groupes de journaux à exclure, consultez[Prévention de la récursivité dans les journaux](Subscriptions-recursion-prevention.md). NOT IN est actuellement le seul opérateur pris en charge pour`selection-criteria`.
Vos données commenceront à apparaître dans votre Amazon S3 en fonction de l'intervalle de temps défini sur votre flux de diffusion Amazon Data Firehose. Après un délai suffisant, vous pouvez consulter votre compartiment Amazon S3 pour vérifier vos données.
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket2' --prefix 'firehose/'
{
"Contents": [
{
"LastModified": "2023-10-29T00:01:25.000Z",
"ETag": "\"a14589f8897f4089d3264d9e2d1f1610\"",
"StorageClass": "STANDARD",
"Key": "firehose/2015/10/29/00/my-delivery-stream-2015-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250",
"Owner": {
"DisplayName": "cloudwatch-logs",
"ID": "1ec9cf700ef6be062b19584e0b7d84ecc19237f87b5"
},
"Size": 593
},
{
"LastModified": "2015-10-29T00:35:41.000Z",
"ETag": "\"a7035b65872bb2161388ffb63dd1aec5\"",
"StorageClass": "STANDARD",
"Key": "firehose/2023/10/29/00/my-delivery-stream-2023-10-29-00-35-40-EXAMPLE-7e66-49bc-9fd4-fc9819cc8ed3",
"Owner": {
"DisplayName": "cloudwatch-logs",
"ID": "EXAMPLE6be062b19584e0b7d84ecc19237f87b6"
},
"Size": 5752
}
]
}
```
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket2' --key 'firehose/2023/10/29/00/my-delivery-stream-2023-10-29-00-01-21-a188030a-62d2-49e6-b7c2-b11f1a7ba250' testfile.gz
{
"AcceptRanges": "bytes",
"ContentType": "application/octet-stream",
"LastModified": "Thu, 29 Oct 2023 00:07:06 GMT",
"ContentLength": 593,
"Metadata": {}
}
```
Les données dans l'objet Amazon S3 sont comprimées au format gzip. Vous pouvez examiner les données brutes à partir de la ligne de commande au moyen de la commande Unix suivante :
```
zcat testfile.gz
```
# Abonnements entre comptes et entre régions
Vous pouvez collaborer avec le propriétaire d'un autre AWS compte et recevoir ses événements de journal sur vos AWS ressources, comme un flux Amazon Kinesis ou Amazon Data Firehose (c'est ce que l'on appelle le partage de données entre comptes). Par exemple, les données de ce journal d'événements peuvent être lues à partir d'un flux Amazon Kinesis Data Streams ou Firehose centralisé pour effectuer un traitement et une analyse personnalisés. Le traitement personnalisé est particulièrement utile lorsque vous collaborez et analysez les données sur plusieurs comptes.
Par exemple, le groupe de sécurité des informations d'une société pourrait souhaiter analyser des données relatives à la détection d'intrusions en temps réel ou aux comportements anormaux. Il peut donc procéder à un audit des comptes de tous les services de la société en recueillant leurs journaux de production séparés afin de les traiter de manière centrale. Un flux en temps réel de données d'événements sur ces comptes peut être assemblé et transmis aux groupes de sécurité de l'information, qui peuvent utiliser Amazon Kinesis Data Streams pour associer les données à leurs systèmes d'analyse de sécurité existants.
**Note**
Le groupe de journaux et la destination doivent se trouver dans la même AWS région. Par contre, la ressource AWS vers laquelle pointe la destination peut être située dans une autre région. Dans les exemples des sections suivantes, toutes les ressources spécifiques à une région sont créées dans l'est des États-Unis (Virginie du Nord).
Si vous avez configuré AWS Organizations et utilisez des comptes membres, vous pouvez utiliser la centralisation des journaux pour collecter les données des journaux à partir des comptes sources vers un compte de surveillance central.
Lorsque vous travaillez avec des groupes de journaux centralisés, vous pouvez utiliser ces dimensions de champs système pour créer des filtres d'abonnement :
+ `@aws.account`- Cette dimension représente l'identifiant du AWS compte à l'origine de l'événement du journal.
+ `@aws.region`- Cette dimension représente la AWS région dans laquelle l'événement du journal a été généré.
Ces dimensions aident à identifier la source des données des journaux, ce qui permet un filtrage plus granulaire et une analyse des métriques dérivées des journaux centralisés.
**Topics**
+ [Partage de données de journal entre comptes et entre régions à l'aide d'Amazon Kinesis Data Streams](CrossAccountSubscriptions-Kinesis.md)
+ [Partage de données de journal entre comptes et entre régions à l'aide de Firehose](CrossAccountSubscriptions-Firehose.md)
+ [Abonnements entre comptes et entre régions à l'aide d'Amazon Kinesis Data Streams](CrossAccountSubscriptions-Kinesis-Account.md)
+ [Abonnements entre comptes et entre régions à l'aide de Firehose](CrossAccountSubscriptions-Firehose-Account.md)
# Partage de données de journal entre comptes et entre régions à l'aide d'Amazon Kinesis Data Streams
Lorsque vous créez un abonnement entre comptes, vous pouvez spécifier un seul compte ou une organisation comme expéditeur. Si vous spécifiez une organisation, cette procédure permet à tous les comptes de l'organisation d'envoyer des journaux au compte récepteur.
Pour partager des données du journal entre comptes, vous devez spécifier un expéditeur et un récepteur :
+ **Expéditeur des données de journal** : obtient les informations de destination auprès du destinataire et CloudWatch indique à Logs qu'il est prêt à envoyer ses événements de journal à la destination spécifiée. Dans les procédures décrites dans le reste de cette section, l'expéditeur des données du journal est indiqué avec un numéro de AWS compte fictif 111111111111.
Si plusieurs comptes dans une organisation doivent envoyer des journaux au compte d'un destinataire, vous pouvez créer une politique qui accorde à tous les comptes de l'organisation l'autorisation d'envoyer des journaux au compte du destinataire. Vous devez toujours configurer des filtres d'abonnement distincts pour chaque compte d'expéditeur.
+ **Destinataire des données de journal** : définit une destination qui encapsule un flux Amazon Kinesis Data Streams et indique à CloudWatch Logs que le destinataire souhaite recevoir des données de journal. Le destinataire partage ensuite les informations sur cette destination avec l'expéditeur. Dans les procédures décrites dans le reste de cette section, le destinataire des données du journal est indiqué avec un numéro de AWS compte fictif 999999999999.
Pour commencer à recevoir des événements de journal provenant d'utilisateurs multicomptes, le destinataire des données de journal crée d'abord une destination de CloudWatch journaux. Chaque destination comprend les éléments clés suivants :
**Nom de destination**
Le nom de la destination que vous souhaitez créer.
**ARN cible**
Le nom de ressource Amazon (ARN) de la AWS ressource que vous souhaitez utiliser comme destination du flux d'abonnement.
**Role ARN (ARN de rôle)**
Rôle Gestion des identités et des accès AWS (IAM) qui accorde à CloudWatch Logs les autorisations nécessaires pour placer des données dans le flux choisi.
**Stratégie d’accès**
Un document de politique IAM (au format JSON, écrit à l'aide de la syntaxe des politiques IAM) régissant l'ensemble des utilisateurs qui sont autorisés à écrire à votre destination.
**Note**
Le groupe de journaux et la destination doivent se trouver dans la même AWS région. Cependant, la AWS ressource pointée par la destination peut être située dans une autre région. Dans les exemples des sections suivantes, toutes les ressources spécifiques à la région sont créées dans USA Est (Virginie du Nord).
**Topics**
+ [Configurer un nouvel abonnement entre comptes](Cross-Account-Log_Subscription-New.md)
+ [Mise à jour d'un abonnement existant entre comptes](Cross-Account-Log_Subscription-Update.md)
# Configurer un nouvel abonnement entre comptes
Suivez les étapes décrites dans ces sections pour configurer un nouvel abonnement au journal entre comptes.
**Topics**
+ [Étape 1 : créer une destination](CreateDestination.md)
+ [Étape 2 : (uniquement si vous utilisez une organisation) créer un rôle IAM](CreateSubscriptionFilter-IAMrole.md)
+ [Étape 3 : autorisations Add/validate IAM pour la destination multi-comptes](Subscription-Filter-CrossAccount-Permissions.md)
+ [Étape 4 : créer un filtre d'abonnement](CreateSubscriptionFilter.md)
+ [Validation du flux des événements des journaux](ValidateLogEventFlow.md)
+ [Modification de l'appartenance à une destination au moment de l'exécution](ModifyDestinationMembership.md)
# Étape 1 : créer une destination
**Important**
Toutes les étapes de cette procédure doivent être réalisées dans le compte du destinataire des données du journal.
Dans cet exemple, le compte du destinataire des données du journal a un ID de compte 999999999999, tandis que l'identifiant du AWS compte de l'expéditeur AWS des données du journal est 111111111111.
Cet exemple crée une destination à l'aide d'un flux Amazon Kinesis Data Streams RecipientStream appelé, et d'un rôle qui CloudWatch permet à Logs d'y écrire des données.
Lorsque la destination est créée, CloudWatch Logs envoie un message test à la destination au nom du compte du destinataire. Lorsque le filtre d'abonnement est activé ultérieurement, CloudWatch Logs envoie les événements du journal à la destination au nom du compte source.
**Pour créer une destination**
1. Dans le compte du destinataire, créez un flux de destination dans Amazon Kinesis Data Streams. À l'invite de commande, saisissez :
```
aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
```
1. Patientez jusqu'à ce que le flux devienne actif. **Vous pouvez utiliser la commande **aws kinesis describe-stream** pour vérifier le. StreamDescription StreamStatus**propriété. Prenez également note de la valeur **StreamDescription.StreamArn,** car vous la transmettrez ultérieurement à CloudWatch Logs :
```
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"
}
}
]
}
}
```
Votre flux de données peut prendre une ou deux minutes avant d'apparaître avec le statut actif.
1. Créez le rôle IAM qui autorise CloudWatch Logs à insérer des données dans votre flux. Tout d'abord, vous devez créer une politique de confiance dans un fichier **\$1/ TrustPolicyFor CWL.json**. Utilisez un éditeur de texte pour créer ce fichier de politique, n'utilisez pas la console IAM.
Cette politique comprend une clé de contexte de condition globale `aws:SourceArn` qui spécifie le `sourceAccountId` pour aider à prévenir le problème de sécurité du député confus. Si vous ne connaissez pas encore l'ID du compte source lors du premier appel, nous vous recommandons de placer l'ARN de destination dans le champ ARN source. Dans les appels suivants, vous devez définir l'ARN source comme ARN source réel que vous avez recueilli lors du premier appel. Pour plus d'informations, consultez [Prévention du député confus](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. Utilisez la commande **aws iam create-role** pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation. Prenez note de la valeur Role.Arn renvoyée, car elle sera également transmise à CloudWatch Logs ultérieurement :
```
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. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte. Utilisez d'abord un éditeur de texte pour créer une politique d'autorisations dans un fichier **\$1/ PermissionsFor CWL.json** :
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
}
]
}
```
1. Associez la politique d'autorisation au rôle à l'aide de la put-role-policy commande **aws iam** :
```
aws iam put-role-policy \
--role-name CWLtoKinesisRole \
--policy-name Permissions-Policy-For-CWL \
--policy-document file://~/PermissionsForCWL.json
```
1. Une fois que le flux est actif et que vous avez créé le rôle IAM, vous pouvez créer la destination CloudWatch Logs.
1. Cette étape n'associe aucune stratégie d'accès à votre destination. Il s'agit uniquement de la première de deux étapes pour créer une destination. Notez **DestinationArn**ce qui est renvoyé dans la charge utile :
```
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. Une fois l'étape 7a terminée, dans le compte des données du journal du destinataire, associez une stratégie d'accès à la destination. Cette politique doit spécifier l'PutSubscriptionFilteraction **logs :** et autoriser le compte expéditeur à accéder à la destination.
La politique accorde l'autorisation au AWS compte qui envoie les journaux. Vous pouvez spécifier uniquement ce compte dans la politique. Si le compte de l'expéditeur est membre d'une organisation, la politique peut également spécifier l'ID de l'organisation. De cette façon, vous pouvez créer une seule politique pour autoriser plusieurs comptes d'une organisation à envoyer des journaux à ce compte de destination.
Utilisez un éditeur de texte pour créer un fichier nommé `~/AccessPolicy.json` avec l'une des déclarations de politique suivantes.
Ce premier exemple de politique autorise tous les comptes de l'organisation possédant un ID `o-1234567890` à envoyer les journaux au compte du destinataire.
------
#### [ 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"
]
}
}
}
]
}
```
------
Cet exemple suivant permet uniquement au compte des données du journal de l'expéditeur (111111111111) d'envoyer des journaux au compte du destinataire des données du journal.
------
#### [ 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. Associez la politique que vous avez créée à l'étape précédente à la destination.
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/AccessPolicy.json
```
Cette politique d'accès permet aux utilisateurs du AWS compte ayant l'ID 111111111111 d'appeler la destination avec l'ARN arn:aws:logs **PutSubscriptionFilter**::9999999999999999999999:destination:testDestination. *region* Toute tentative d' PutSubscriptionFilterappel de la part d'un autre utilisateur vers cette destination sera rejetée.
Pour valider les privilèges d'un utilisateur par rapport à une stratégie d'accès, consultez [Utilisation du programme de validation de politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html) dans le *Guide de l'utilisateur IAM*.
Lorsque vous avez terminé, si vous utilisez AWS Organizations pour vos autorisations multi-comptes, suivez les étapes décrites dans[Étape 2 : (uniquement si vous utilisez une organisation) créer un rôle IAM](CreateSubscriptionFilter-IAMrole.md). Si vous accordez des autorisations directement à l'autre compte au lieu d'utiliser des organisations, vous pouvez ignorer cette étape et passer à [Étape 4 : créer un filtre d'abonnement](CreateSubscriptionFilter.md).
# Étape 2 : (uniquement si vous utilisez une organisation) créer un rôle IAM
Dans la section précédente, si vous avez créé la destination à l'aide d'une stratégie d'accès qui accorde des autorisations à l'organisation dans laquelle ce compte `111111111111` se trouve, au lieu d'accorder des autorisations directement au compte `111111111111`, suivez les étapes de cette section. Sinon, vous pouvez passer à [Étape 4 : créer un filtre d'abonnement](CreateSubscriptionFilter.md).
Les étapes décrites dans cette section créent un rôle IAM, qui CloudWatch peut assumer et valider si le compte expéditeur est autorisé à créer un filtre d'abonnement par rapport à la destination du destinataire.
Suivez les étapes de cette section dans le compte de l'expéditeur. Le rôle doit exister dans le compte de l'expéditeur et vous devez spécifier l'ARN de ce rôle dans le filtre d'abonnement. Dans cet exemple, le compte de l'expéditeur est `111111111111`.
**Pour créer le rôle IAM nécessaire pour les abonnements aux journaux entre comptes à l'aide de AWS Organizations**
1. Créez la politique de confiance suivante dans un fichier `/TrustPolicyForCWLSubscriptionFilter.json`. Utilisez un éditeur de texte pour créer ce fichier de politique, n'utilisez pas la console IAM.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Créez le rôle IAM qui utilise cette politique. Notez la valeur `Arn` qui est renvoyée par la commande ; vous en aurez besoin ultérieurement dans cette procédure. Dans cet exemple, nous utilisons `CWLtoSubscriptionFilterRole` pour connaître le nom du rôle que nous créons.
```
aws iam create-role \
--role-name CWLtoSubscriptionFilterRole \
--assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
```
1. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte.
1. Utilisez d'abord un éditeur de texte pour créer la politique d'autorisations suivante dans un fichier nommé `~/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Saisissez la commande suivante pour associer la politique d'autorisations que vous venez de créer au rôle que vous avez créé à l'étape 2.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
Lorsque vous aurez terminé, vous pouvez passer à [Étape 4 : créer un filtre d'abonnement](CreateSubscriptionFilter.md).
# Étape 3 : autorisations Add/validate IAM pour la destination multi-comptes
Selon la logique d'évaluation des politiques AWS entre comptes, pour accéder à toute ressource intercomptes (telle qu'un flux Kinesis ou Firehose utilisé comme destination pour un filtre d'abonnement), vous devez disposer d'une politique basée sur l'identité dans le compte d'envoi qui fournit un accès explicite à la ressource de destination entre comptes. Pour plus d'informations sur la logique d'évaluation des politiques, consultez la section [Logique d'évaluation des politiques entre comptes](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).
Vous pouvez attacher la politique basée sur l'identité au rôle IAM ou à l'utilisateur IAM que vous utilisez pour créer le filtre d'abonnement. Cette politique doit être présente dans le compte de l'expéditeur. Si vous utilisez le rôle d'administrateur pour créer le filtre d'abonnement, vous pouvez ignorer cette étape et passer à [Étape 4 : créer un filtre d'abonnement](CreateSubscriptionFilter.md).
**Pour ajouter ou valider les autorisations IAM nécessaires pour les opérations entre comptes**
1. Entrez la commande suivante pour vérifier quel rôle ou utilisateur IAM est utilisé pour exécuter les commandes de AWS journalisation.
```
aws sts get-caller-identity
```
La commande renvoie un résultat semblable à ce qui suit :
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
Notez la valeur représentée par *RoleName* ou*UserName*.
1. Connectez-vous AWS Management Console au compte expéditeur et recherchez les politiques associées avec le rôle IAM ou l'utilisateur IAM renvoyé dans le résultat de la commande que vous avez saisie à l'étape 1.
1. Vérifiez que les politiques associées à ce rôle ou à cet utilisateur fournissent des autorisations explicites pour appeler `logs:PutSubscriptionFilter` au niveau de la ressource de destination entre comptes.
La politique suivante autorise la création d'un filtre d'abonnement sur n'importe quelle ressource de destination uniquement dans un seul AWS compte, un compte `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:*"
]
}
]
}
```
------
La politique suivante autorise la création d'un filtre d'abonnement uniquement sur une ressource de destination spécifique nommée `sampleDestination` dans un AWS compte unique, un compte `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"
]
}
]
}
```
------
# Étape 4 : créer un filtre d'abonnement
Une fois que vous avez créé une destination, le compte du destinataire des données du journal peut partager l'ARN de destination (arn:aws:logs:us-east-1:999999999999:destination:testDestination) avec d'autres comptes AWS afin qu'ils puissent envoyer des événements du journal vers la même destination. Les utilisateurs des autres comptes d'expédition créent ensuite un filtre d'abonnement sur leurs groupes de journaux respectifs par rapport à cette destination. Ce filtre d'abonnement lance immédiatement la transmission de données du journal en temps réel à partir du groupe de journaux choisi vers la destination spécifiée.
**Note**
Si vous accordez des autorisations pour le filtre d'abonnement à l'ensemble d'une organisation, vous devez utiliser l'ARN du rôle IAM que vous avez créé dans [Étape 2 : (uniquement si vous utilisez une organisation) créer un rôle IAM](CreateSubscriptionFilter-IAMrole.md).
Dans l'exemple suivant, un filtre d'abonnement est créé dans un compte d'envoi. Le filtre est associé à un groupe de journaux contenant des AWS CloudTrail événements afin que chaque activité enregistrée à l'aide des AWS informations d'identification « root » soit transmise à la destination que vous avez créée précédemment. Cette destination encapsule un flux appelé « RecipientStream ».
Les autres étapes décrites dans les sections suivantes supposent que vous avez suivi les instructions de la section [Envoyer des CloudTrail événements aux CloudWatch journaux](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) dans le *guide de l'AWS CloudTrail utilisateur* et que vous avez créé un groupe de journaux contenant vos CloudTrail événements. Ces étapes supposent que le nom de ce groupe de journaux est `CloudTrail/logs`.
Lorsque vous saisissez la commande suivante, assurez-vous d'être connecté en tant qu'utilisateur IAM ou que vous utilisez le rôle IAM pour lequel vous avez ajouté la politique, dans [Étape 3 : autorisations Add/validate IAM pour la destination multi-comptes](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"
```
Le groupe de journaux et la destination doivent se trouver dans la même AWS région. Toutefois, la destination peut pointer vers une AWS ressource telle qu'un flux Amazon Kinesis Data Streams situé dans une autre région.
# Validation du flux des événements des journaux
Après avoir créé le filtre d'abonnement, CloudWatch Logs transmet tous les événements de journal entrants correspondant au modèle de filtre au flux encapsulé dans le flux de destination appelé « **RecipientStream**». Le propriétaire de la destination peut vérifier que cela se produit en utilisant la get-shard-iterator commande **aws kinesis** pour récupérer une partition Amazon Kinesis Data Streams, et en utilisant **la commande aws kinesis get-records pour récupérer certains enregistrements Amazon Kinesis Data** Streams :
```
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"
```
**Note**
Il se peut que vous deviez réexécuter la commande get-records à quelques reprises avant qu'Amazon Kinesis Data Streams ne commence à renvoyer des données.
Vous devriez voir une réponse contenant un ensemble d'enregistrements Amazon Kinesis Data Streams. L'attribut de données de l'enregistrement Amazon Kinesis Data Streams est compressé au format gzip puis codé en base64. Vous pouvez examiner les données brutes à partir de la ligne de commande au moyen de la commande Unix suivante :
```
echo -n "" | base64 -d | zcat
```
Les données codées et décompressées en base64 sont formatées au format JSON avec la structure suivante :
```
{
"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\"}"
}
]
}
```
Les éléments clés de cette structure de données sont les suivants :
**owner**
L'ID de AWS compte des données du journal d'origine.
**logGroup**
Le nom du groupe de journaux des données du journal source.
**logStream**
Le nom du flux de journaux des données du journal source.
**subscriptionFilters**
La liste des noms de filtres d'abonnements qui correspondaient aux données du journal source.
**messageType**
Les données de messages utilisent le type « DATA\$1MESSAGE ». Parfois, CloudWatch Logs peut émettre des enregistrements Amazon Kinesis Data Streams de type « CONTROL\$1MESSAGE », principalement pour vérifier si la destination est accessible.
**logEvents**
Les données du journal réelles, représentées sous la forme d'un tableau d'enregistrements d'événements du journal. La propriété ID est un identifiant unique pour chaque événement de journal.
# Modification de l'appartenance à une destination au moment de l'exécution
Vous pouvez rencontrer des situations où vous devez ajouter ou supprimer l'adhésion de certains utilisateurs pour l'une de vos destinations. Vous pouvez utiliser la commande `put-destination-policy` sur votre destination avec une nouvelle stratégie d'accès. Dans l'exemple suivant, un compte précédemment ajouté **111111111111** est écarté de l'envoi de données du journal supplémentaires, et le compte **222222222222** est activé.
1. Récupérez la politique actuellement associée à la **destination TestDestination** et notez : **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. Mettez à jour la politique de façon à refléter l'arrêt du compte **111111111111** et l'activation du compte **222222222222**. Insérez cette politique dans le fichier **\$1/ NewAccessPolicy .json** :
------
#### [ 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. Appelez **PutDestinationPolicy**pour associer la politique définie dans le fichier **NewAccessPolicy.json** à la destination :
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Cela finira par désactiver les événements du journal à partir de l'ID de compte **111111111111**. Les événements du journal de l'ID de compte **222222222222** commencent à passer à la destination dès que le propriétaire du compte **222222222222** crée un filtre d'abonnement.
# Mise à jour d'un abonnement existant entre comptes
Si vous disposez actuellement d'un abonnement aux journaux entre comptes où le compte de destination n'accorde des autorisations qu'à des comptes d'expéditeur spécifiques et que vous souhaitez mettre à jour cet abonnement, afin que le compte de destination accorde l'accès à tous les comptes d'une organisation, suivez les étapes décrites dans cette section.
**Topics**
+ [Étape 1 : mettre à jour les filtres d'abonnement](Cross-Account-Log_Subscription-Update-filter.md)
+ [Étape 2 : mettre à jour la stratégie d'accès de la destination existante](Cross-Account-Log_Subscription-Update-policy.md)
# Étape 1 : mettre à jour les filtres d'abonnement
**Note**
Cette étape est nécessaire uniquement pour les abonnements entre comptes pour les journaux créés par les services répertoriés dans [Activer la journalisation à partir AWS des services](AWS-logs-and-resource-policy.md). Si vous ne travaillez pas avec les journaux créés par l'un de ces groupes de journaux, vous pouvez passer à [Étape 2 : mettre à jour la stratégie d'accès de la destination existante](Cross-Account-Log_Subscription-Update-policy.md).
Dans certains cas, vous devez mettre à jour les filtres d'abonnement dans tous les comptes d'expéditeur qui envoient des journaux au compte de destination. La mise à jour ajoute un rôle IAM, qui CloudWatch peut supposer et valider que le compte expéditeur est autorisé à envoyer des journaux au compte destinataire.
Suivez les étapes de cette section pour chaque compte d'expéditeur que vous souhaitez mettre à jour, afin qu'il utilise l'ID d'organisation pour les autorisations d'abonnement entre comptes.
Dans les exemples présentés dans cette section, deux comptes, `111111111111` et `222222222222`, disposent de filtres d'abonnement pour envoyer des journaux au compte `999999999999`. Les valeurs de filtre d'abonnement existantes sont les suivantes :
```
## 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"
```
Si vous devez rechercher les valeurs actuelles des paramètres de filtre d'abonnement, saisissez la commande suivante.
```
aws logs describe-subscription-filters
\ --log-group-name "my-log-group-name"
```
**Pour mettre à jour un filtre d'abonnement afin de commencer à utiliser l'organisation IDs pour les autorisations de journalisation entre comptes**
1. Créez la politique de confiance suivante dans un fichier `~/TrustPolicyForCWL.json`. Utilisez un éditeur de texte pour créer ce fichier de politique, n'utilisez pas la console IAM.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Créez le rôle IAM qui utilise cette politique. Notez la valeur `Arn` de la valeur `Arn` qui est renvoyée par la commande ; vous en aurez besoin ultérieurement dans cette procédure. Dans cet exemple, nous utilisons `CWLtoSubscriptionFilterRole` pour connaître le nom du rôle que nous créons.
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.json
```
1. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte.
1. Utilisez d'abord un éditeur de texte pour créer la politique d'autorisations suivante dans un fichier nommé `/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Saisissez la commande suivante pour associer la politique d'autorisations que vous venez de créer au rôle que vous avez créé à l'étape 2.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
1. Saisissez la commande suivante pour mettre à jour le filtre d'abonnement.
```
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"
```
# Étape 2 : mettre à jour la stratégie d'accès de la destination existante
Une fois que vous avez mis à jour les filtres d'abonnement dans tous les comptes d'expéditeur, vous pouvez mettre à jour la stratégie d'accès de la destination dans le compte du destinataire.
Dans les exemples suivants, le compte du destinataire est `999999999999` et la destination est nommée `testDestination`.
La mise à jour permet à tous les comptes qui font partie de l'organisation ayant un ID `o-1234567890` d'envoyer des journaux au compte du destinataire. Seuls les comptes avec des filtres d'abonnement envoient des journaux au compte du destinataire.
**Pour mettre à jour la stratégie d'accès de la destination dans le compte du destinataire, afin qu'il commence à utiliser un ID d'organisation pour les autorisations**
1. Dans le compte du destinataire, utilisez un éditeur de texte pour créer un fichier `~/AccessPolicy.json` avec le contenu suivant.
------
#### [ 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. Saisissez la commande suivante pour attacher la politique que vous venez de créer à la destination existante. Pour mettre à jour une destination afin d'utiliser une politique d'accès avec un identifiant d'organisation au lieu d'une politique d'accès répertoriant un AWS compte spécifique IDs, incluez le `force` paramètre.
**Avertissement**
Si vous travaillez avec des journaux envoyés par un AWS service répertorié dans[Activer la journalisation à partir AWS des services](AWS-logs-and-resource-policy.md), avant de procéder à cette étape, vous devez d'abord avoir mis à jour les filtres d'abonnement dans tous les comptes d'expéditeurs, comme expliqué dans[Étape 1 : mettre à jour les filtres d'abonnement](Cross-Account-Log_Subscription-Update-filter.md).
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Partage de données de journal entre comptes et entre régions à l'aide de Firehose
Pour partager des données du journal entre comptes, vous devez spécifier un expéditeur et un récepteur :
+ **Expéditeur des données de journal** : obtient les informations de destination auprès du destinataire et CloudWatch indique à Logs qu'il est prêt à envoyer ses événements de journal à la destination spécifiée. Dans les procédures décrites dans le reste de cette section, l'expéditeur des données du journal est indiqué avec un numéro de AWS compte fictif 111111111111.
+ **Destinataire des données de journal** : définit une destination qui encapsule un flux Amazon Kinesis Data Streams et indique à CloudWatch Logs que le destinataire souhaite recevoir des données de journal. Le destinataire partage ensuite les informations sur cette destination avec l'expéditeur. Dans les procédures décrites dans le reste de cette section, le destinataire des données du journal est indiqué avec un numéro de AWS compte fictif 222222222222.
L'exemple présenté dans cette section utilise un flux de diffusion Firehose avec un espace de stockage Amazon S3. Vous pouvez également configurer les flux de diffusion Firehose avec différents paramètres. Pour plus d'informations, consultez [Création d'un flux de diffusion Firehose](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).
**Note**
Le groupe de journaux et la destination doivent se trouver dans la même AWS région. Cependant, la AWS ressource pointée par la destination peut être située dans une autre région.
**Note**
Le filtre d'abonnement Firehose pour un ***même compte*** et un flux de diffusion ***interrégional*** sont pris en charge.
**Topics**
+ [Étape 1 : créer un flux de diffusion Firehose](CreateFirehoseStream.md)
+ [Étape 2 : créer une destination](CreateFirehoseStreamDestination.md)
+ [Étape 3 : autorisations Add/validate IAM pour la destination multi-comptes](Subscription-Filter-CrossAccount-Permissions-Firehose.md)
+ [Étape 4 : créer un filtre d'abonnement](CreateSubscriptionFilterFirehose.md)
+ [Validation du flux des événements de journaux](ValidateLogEventFlowFirehose.md)
+ [Modification de l'abonnement à la destination au moment de l'exécution](ModifyDestinationMembershipFirehose.md)
# Étape 1 : créer un flux de diffusion Firehose
**Important**
Avant d'effectuer les étapes suivantes, vous devez utiliser une politique d'accès afin que Firehose puisse accéder à votre compartiment Amazon S3. Pour plus d'informations, consultez [Controlling Access](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3) dans le manuel *Amazon Data Firehose Developer Guide*.
Toutes les étapes de cette section (Étape 1) doivent être réalisées dans le compte du destinataire des données du journal.
USA Est (Virginie du Nord) est utilisé dans les exemples de commandes suivants. Remplacez la région par la celle appropriée pour votre déploiement.
**Pour créer un flux de diffusion Firehose à utiliser comme destination**
1. Créez un compartiment Amazon S3 :
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. Créez le rôle IAM qui autorise Firehose à placer des données dans le bucket.
1. D'abord, utilisez un éditeur de texte pour créer une politique d'approbation dans un fichier `~/TrustPolicyForFirehose.json`.
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. Créez le rôle IAM, en spécifiant le fichier de politique d'approbation que vous venez de créer.
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. La sortie de cette commande ressemblera à ce qui suit. Notez le nom du rôle et l'ARN du rôle.
```
{
"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. Créez une politique d'autorisation pour définir les actions que Firehose peut effectuer sur votre compte.
1. Utilisez d'abord un éditeur de texte pour créer la politique d'autorisations suivante dans un fichier nommé `~/PermissionsForFirehose.json`. Selon votre cas d'utilisation, il se peut que vous deviez ajouter des autorisations supplémentaires à ce fichier.
```
{
"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. Saisissez la commande suivante pour associer la politique d'autorisation que vous venez de créer au rôle IAM.
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. Entrez la commande suivante pour créer le flux de diffusion Firehose. Remplacez *my-role-arn* et *amzn-s3-demo-bucket2-arn* par les valeurs correctes pour votre déploiement.
```
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"}'
```
La sortie doit ressembler à ce qui suit :
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# Étape 2 : créer une destination
**Important**
Toutes les étapes de cette procédure doivent être réalisées dans le compte du destinataire des données du journal.
Lorsque la destination est créée, CloudWatch Logs envoie un message test à la destination au nom du compte du destinataire. Lorsque le filtre d'abonnement est activé ultérieurement, CloudWatch Logs envoie les événements du journal à la destination au nom du compte source.
**Pour créer une destination**
1. Attendez que le stream Firehose que vous avez créé soit actif[Étape 1 : créer un flux de diffusion Firehose](CreateFirehoseStream.md). Vous pouvez utiliser la commande suivante pour vérifier le **StreamDescription. StreamStatus**propriété.
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
En outre, prenez note du **DeliveryStreamDescription. DeliveryStreamValeur ARN**, car vous devrez l'utiliser ultérieurement. Exemple de résultat de cette commande :
```
{
"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
}
}
```
Votre flux de diffusion peut prendre une ou deux minutes avant d'apparaître avec le statut actif.
1. Lorsque le flux de diffusion est actif, créez le rôle IAM qui autorisera CloudWatch Logs à insérer des données dans votre flux Firehose. Tout d'abord, vous devez créer une politique de confiance dans un fichier **\$1/ TrustPolicyFor CWL.json**. Utilisez un éditeur de texte créer cette stratégie. Pour plus d'informations sur les points de terminaison de CloudWatch Logs, consultez la section Points de [terminaison et quotas Amazon CloudWatch Logs](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html).
Cette politique comprend une clé de contexte de condition globale `aws:SourceArn` qui spécifie le `sourceAccountId` pour aider à prévenir le problème de sécurité du député confus. Si vous ne connaissez pas encore l'ID du compte source lors du premier appel, nous vous recommandons de placer l'ARN de destination dans le champ ARN source. Dans les appels suivants, vous devez définir l'ARN source comme ARN source réel que vous avez recueilli lors du premier appel. Pour plus d'informations, consultez [Prévention du député confus](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. Utilisez la commande **aws iam create-role** pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation que vous venez de créer.
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
Voici un exemple de sortie. Prenez note de la valeur `Role.Arn` retournée, car vous devrez l'utiliser dans une étape ultérieure.
```
{
"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. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte. Utilisez d'abord un éditeur de texte pour créer une politique d'autorisations dans un fichier **\$1/ PermissionsFor CWL.json** :
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. Associez la politique d'autorisations au rôle en entrant la commande suivante :
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Une fois que le flux de diffusion Firehose est actif et que vous avez créé le rôle IAM, vous pouvez créer la CloudWatch destination Logs.
1. Cette étape n'associera pas de stratégie d'accès à votre destination. Il s'agit uniquement de la première de deux étapes pour créer une destination. Notez l'ARN de la nouvelle destination qui est renvoyé dans la charge utile, car vous l'utiliserez comme `destination.arn` dans une étape ultérieure.
```
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. Une fois l'étape précédente terminée, dans le compte des données du journal du destinataire (222222222222), associez une stratégie d'accès à la destination.
Cette politique permet au compte de l'expéditeur des données du journal (111111111111) d'accéder à la destination dans le compte du destinataire des données du journal (222222222222). Vous pouvez utiliser un éditeur de texte pour mettre cette politique dans le fichier **\$1/ AccessPolicy .json** :
------
#### [ 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. Cela crée une stratégie définissant qui a accès en écriture à la destination. Cette politique doit spécifier les **logs : PutSubscriptionFilter** action pour accéder à la destination. Les utilisateurs multicomptes utiliseront l'**PutSubscriptionFilter**action pour envoyer les événements du journal à la destination :
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# Étape 3 : autorisations Add/validate IAM pour la destination multi-comptes
Selon la logique d'évaluation des politiques AWS entre comptes, pour accéder à toute ressource intercomptes (telle qu'un flux Kinesis ou Firehose utilisé comme destination pour un filtre d'abonnement), vous devez disposer d'une politique basée sur l'identité dans le compte d'envoi qui fournit un accès explicite à la ressource de destination entre comptes. Pour plus d'informations sur la logique d'évaluation des politiques, consultez la section [Logique d'évaluation des politiques entre comptes](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).
Vous pouvez attacher la politique basée sur l'identité au rôle IAM ou à l'utilisateur IAM que vous utilisez pour créer le filtre d'abonnement. Cette politique doit être présente dans le compte de l'expéditeur. Si vous utilisez le rôle d'administrateur pour créer le filtre d'abonnement, vous pouvez ignorer cette étape et passer à [Étape 4 : créer un filtre d'abonnement](CreateSubscriptionFilter.md).
**Pour ajouter ou valider les autorisations IAM nécessaires pour les opérations entre comptes**
1. Entrez la commande suivante pour vérifier quel rôle ou utilisateur IAM est utilisé pour exécuter les commandes de AWS journalisation.
```
aws sts get-caller-identity
```
La commande renvoie un résultat semblable à ce qui suit :
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
Notez la valeur représentée par *RoleName* ou*UserName*.
1. Connectez-vous AWS Management Console au compte expéditeur et recherchez les politiques associées avec le rôle IAM ou l'utilisateur IAM renvoyé dans le résultat de la commande que vous avez saisie à l'étape 1.
1. Vérifiez que les politiques associées à ce rôle ou à cet utilisateur fournissent des autorisations explicites pour appeler `logs:PutSubscriptionFilter` au niveau de la ressource de destination entre comptes.
La politique suivante autorise la création d'un filtre d'abonnement sur n'importe quelle ressource de destination uniquement dans un seul AWS compte, un compte `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:*"
]
}
]
}
```
------
La politique suivante autorise la création d'un filtre d'abonnement uniquement sur une ressource de destination spécifique nommée `sampleDestination` dans un AWS compte unique, un compte `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"
]
}
]
}
```
------
# Étape 4 : créer un filtre d'abonnement
Passez au compte d'envoi, qui est 111111111111 dans cet exemple. Vous allez maintenant créer le filtre d'abonnement dans le compte d'envoi. Dans cet exemple, le filtre est associé à un groupe de journaux contenant des AWS CloudTrail événements afin que chaque activité enregistrée avec les AWS informations d'identification « root » soit transmise à la destination que vous avez créée précédemment. Pour plus d'informations sur la façon d'envoyer AWS CloudTrail des événements aux CloudWatch journaux, consultez la section [Envoyer CloudTrail des événements aux CloudWatch journaux](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) dans le *guide de AWS CloudTrail l'utilisateur*.
Lorsque vous saisissez la commande suivante, assurez-vous d'être connecté en tant qu'utilisateur IAM ou que vous utilisez le rôle IAM pour lequel vous avez ajouté la politique, dans [Étape 3 : autorisations Add/validate IAM pour la destination multi-comptes](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"
```
Le groupe de journaux et la destination doivent se trouver dans la même AWS région. Cependant, la destination peut pointer vers une AWS ressource telle qu'un flux Firehose situé dans une autre région.
# Validation du flux des événements de journaux
Après avoir créé le filtre d'abonnement, CloudWatch Logs transmet tous les événements de journal entrants correspondant au modèle de filtre au flux de diffusion Firehose. Les données commencent à apparaître dans votre compartiment Amazon S3 en fonction de l'intervalle de temps défini dans le flux de diffusion Firehose. Après un délai suffisant, vous pouvez consulter le compartiment Amazon S3 pour vérifier vos données. Pour vérifier le compartiment, saisissez la commande suivante :
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
La sortie de cette commande sera similaire à ce qui suit :
```
{
"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"
}
}
]
}
```
Vous pouvez ensuite récupérer un objet spécifique du compartiment en entrant la commande suivante. Remplacez la valeur de `key` par la valeur que vous avez trouvée dans la commande précédente.
```
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
```
Les données dans l'objet Amazon S3 sont comprimées au format gzip. Vous pouvez examiner les données brutes à partir de la ligne de commande en utilisant l'une des commandes suivantes :
Linux :
```
zcat testfile.gz
```
macOS :
```
zcat
Vous pouvez rencontrer des situations où vous devez ajouter ou supprimer des expéditeurs de journaux d'une destination qui vous appartient. Vous pouvez utiliser l'**PutDestinationPolicy**action sur votre destination avec une nouvelle politique d'accès. Dans l'exemple suivant, un compte précédemment ajouté **111111111111** est écarté de l'envoi de données du journal supplémentaires, et le compte **333333333333** est activé.
1. Récupérez la politique actuellement associée à la **destination TestDestination** et notez : **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. Mettez à jour la politique de façon à refléter l'arrêt du compte **111111111111** et l'activation du compte **333333333333**. Insérez cette politique dans le fichier **\$1/ NewAccessPolicy .json** :
------
#### [ 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. Utilisez la commande suivante pour associer la politique définie dans le fichier **NewAccessPolicy.json** à la destination :
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Cela désactive éventuellement les événements du journal à partir de l'ID de compte **111111111111**. Les événements du journal de l'ID de compte **333333333333** commencent à passer à la destination dès que le propriétaire du compte **333333333333** crée un filtre d'abonnement.
# Abonnements entre comptes et entre régions à l'aide d'Amazon Kinesis Data Streams
Lorsque vous créez un abonnement entre comptes, vous pouvez spécifier un seul compte ou une organisation comme expéditeur. Si vous spécifiez une organisation, cette procédure permet à tous les comptes de l'organisation d'envoyer des journaux au compte récepteur.
Pour partager des données du journal entre comptes, vous devez spécifier un expéditeur et un récepteur :
+ **Expéditeur des données de journal** : obtient les informations de destination auprès du destinataire et CloudWatch indique à Logs qu'il est prêt à envoyer ses événements de journal à la destination spécifiée. Dans les procédures décrites dans le reste de cette section, l'expéditeur des données du journal est indiqué avec un numéro de AWS compte fictif 111111111111.
Si plusieurs comptes dans une organisation doivent envoyer des journaux au compte d'un destinataire, vous pouvez créer une politique qui accorde à tous les comptes de l'organisation l'autorisation d'envoyer des journaux au compte du destinataire. Vous devez toujours configurer des filtres d'abonnement distincts pour chaque compte d'expéditeur.
+ **Destinataire des données de journal** : définit une destination qui encapsule un flux Amazon Kinesis Data Streams et indique à CloudWatch Logs que le destinataire souhaite recevoir des données de journal. Le destinataire partage ensuite les informations sur cette destination avec l'expéditeur. Dans les procédures décrites dans le reste de cette section, le destinataire des données du journal est indiqué avec un numéro de AWS compte fictif 999999999999.
Pour commencer à recevoir des événements de journal provenant d'utilisateurs multicomptes, le destinataire des données de journal crée d'abord une destination de CloudWatch journaux. Chaque destination comprend les éléments clés suivants :
**Nom de destination**
Le nom de la destination que vous souhaitez créer.
**ARN cible**
Le nom de ressource Amazon (ARN) de la AWS ressource que vous souhaitez utiliser comme destination du flux d'abonnement.
**Role ARN (ARN de rôle)**
Rôle Gestion des identités et des accès AWS (IAM) qui accorde à CloudWatch Logs les autorisations nécessaires pour placer des données dans le flux choisi.
**Stratégie d’accès**
Un document de politique IAM (au format JSON, écrit à l'aide de la syntaxe des politiques IAM) régissant l'ensemble des utilisateurs qui sont autorisés à écrire à votre destination.
**Note**
Le groupe de journaux et la destination doivent se trouver dans la même AWS région. Cependant, la AWS ressource pointée par la destination peut être située dans une autre région. Dans les exemples des sections suivantes, toutes les ressources spécifiques à la région sont créées dans USA Est (Virginie du Nord).
**Topics**
+ [Configurer un nouvel abonnement entre comptes](Cross-Account-Log_Subscription-New-Account.md)
+ [Mise à jour d'un abonnement existant entre comptes](Cross-Account-Log_Subscription-Update-Account.md)
# Configurer un nouvel abonnement entre comptes
Suivez les étapes décrites dans ces sections pour configurer un nouvel abonnement au journal entre comptes.
**Topics**
+ [Étape 1 : créer une destination](CreateDestination-Account.md)
+ [Étape 2 : (uniquement si vous utilisez une organisation) créer un rôle IAM](CreateSubscriptionFilter-IAMrole-Account.md)
+ [Étape 3 : créer une politique de filtrage des abonnements au niveau du compte](CreateSubscriptionFilter-Account.md)
+ [Validation du flux des événements des journaux](ValidateLogEventFlow-Account.md)
+ [Modification de l'appartenance à une destination au moment de l'exécution](ModifyDestinationMembership-Account.md)
# Étape 1 : créer une destination
**Important**
Toutes les étapes de cette procédure doivent être réalisées dans le compte du destinataire des données du journal.
Dans cet exemple, le compte du destinataire des données du journal a un ID de compte 999999999999, tandis que l'identifiant du AWS compte de l'expéditeur AWS des données du journal est 111111111111.
Cet exemple crée une destination à l'aide d'un flux Amazon Kinesis Data Streams RecipientStream appelé, et d'un rôle qui CloudWatch permet à Logs d'y écrire des données.
Lorsque la destination est créée, CloudWatch Logs envoie un message test à la destination au nom du compte du destinataire. Lorsque le filtre d'abonnement est activé ultérieurement, CloudWatch Logs envoie les événements du journal à la destination au nom du compte source.
**Pour créer une destination**
1. Dans le compte du destinataire, créez un flux de destination dans Amazon Kinesis Data Streams. À l'invite de commande, saisissez :
```
aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
```
1. Patientez jusqu'à ce que le flux devienne actif. **Vous pouvez utiliser la commande **aws kinesis describe-stream** pour vérifier le. StreamDescription StreamStatus**propriété. Prenez également note de la valeur **StreamDescription.StreamArn,** car vous la transmettrez ultérieurement à CloudWatch Logs :
```
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"
}
}
]
}
}
```
Votre flux de données peut prendre une ou deux minutes avant d'apparaître avec le statut actif.
1. Créez le rôle IAM qui autorise CloudWatch Logs à insérer des données dans votre flux. Tout d'abord, vous devez créer une politique de confiance dans un fichier **\$1/ TrustPolicyFor CWL.json**. Utilisez un éditeur de texte pour créer ce fichier de politique, n'utilisez pas la console IAM.
Cette politique comprend une clé de contexte de condition globale `aws:SourceArn` qui spécifie le `sourceAccountId` pour aider à prévenir le problème de sécurité du député confus. Si vous ne connaissez pas encore l'ID du compte source lors du premier appel, nous vous recommandons de placer l'ARN de destination dans le champ ARN source. Dans les appels suivants, vous devez définir l'ARN source comme ARN source réel que vous avez recueilli lors du premier appel. Pour plus d'informations, consultez [Prévention du député confus](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. Utilisez la commande **aws iam create-role** pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation. Prenez note de la valeur Role.Arn renvoyée, car elle sera également transmise à CloudWatch Logs ultérieurement :
```
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. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte. Utilisez d'abord un éditeur de texte pour créer une politique d'autorisations dans un fichier **\$1/ PermissionsFor CWL.json** :
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
}
]
}
```
1. Associez la politique d'autorisation au rôle à l'aide de la put-role-policy commande **aws iam** :
```
aws iam put-role-policy \
--role-name CWLtoKinesisRole \
--policy-name Permissions-Policy-For-CWL \
--policy-document file://~/PermissionsForCWL.json
```
1. Une fois que le flux est actif et que vous avez créé le rôle IAM, vous pouvez créer la destination CloudWatch Logs.
1. Cette étape n'associe aucune stratégie d'accès à votre destination. Il s'agit uniquement de la première de deux étapes pour créer une destination. Notez **DestinationArn**ce qui est renvoyé dans la charge utile :
```
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. Une fois l'étape 7a terminée, dans le compte des données du journal du destinataire, associez une stratégie d'accès à la destination. Cette politique doit spécifier l'PutSubscriptionFilteraction **logs :** et autoriser le compte expéditeur à accéder à la destination.
La politique accorde l'autorisation au AWS compte qui envoie les journaux. Vous pouvez spécifier uniquement ce compte dans la politique. Si le compte de l'expéditeur est membre d'une organisation, la politique peut également spécifier l'ID de l'organisation. De cette façon, vous pouvez créer une seule politique pour autoriser plusieurs comptes d'une organisation à envoyer des journaux à ce compte de destination.
Utilisez un éditeur de texte pour créer un fichier nommé `~/AccessPolicy.json` avec l'une des déclarations de politique suivantes.
Ce premier exemple de politique autorise tous les comptes de l'organisation possédant un ID `o-1234567890` à envoyer les journaux au compte du destinataire.
------
#### [ 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"
]
}
}
}
]
}
```
------
Cet exemple suivant permet uniquement au compte des données du journal de l'expéditeur (111111111111) d'envoyer des journaux au compte du destinataire des données du journal.
------
#### [ 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. Associez la politique que vous avez créée à l'étape précédente à la destination.
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/AccessPolicy.json
```
Cette politique d'accès permet aux utilisateurs du AWS compte ayant l'ID 111111111111 d'appeler la destination avec l'ARN arn:aws:logs **PutSubscriptionFilter**::9999999999999999999999:destination:testDestination. *region* Toute tentative d' PutSubscriptionFilterappel de la part d'un autre utilisateur vers cette destination sera rejetée.
Pour valider les privilèges d'un utilisateur par rapport à une stratégie d'accès, consultez [Utilisation du programme de validation de politiques](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html) dans le *Guide de l'utilisateur IAM*.
Lorsque vous avez terminé, si vous utilisez AWS Organizations pour vos autorisations multi-comptes, suivez les étapes décrites dans[Étape 2 : (uniquement si vous utilisez une organisation) créer un rôle IAM](CreateSubscriptionFilter-IAMrole-Account.md). Si vous accordez des autorisations directement à l'autre compte au lieu d'utiliser des organisations, vous pouvez ignorer cette étape et passer à [Étape 3 : créer une politique de filtrage des abonnements au niveau du compte](CreateSubscriptionFilter-Account.md).
# Étape 2 : (uniquement si vous utilisez une organisation) créer un rôle IAM
Dans la section précédente, si vous avez créé la destination à l'aide d'une stratégie d'accès qui accorde des autorisations à l'organisation dans laquelle ce compte `111111111111` se trouve, au lieu d'accorder des autorisations directement au compte `111111111111`, suivez les étapes de cette section. Sinon, vous pouvez passer à [Étape 3 : créer une politique de filtrage des abonnements au niveau du compte](CreateSubscriptionFilter-Account.md).
Les étapes décrites dans cette section créent un rôle IAM, qui CloudWatch peut assumer et valider si le compte expéditeur est autorisé à créer un filtre d'abonnement par rapport à la destination du destinataire.
Suivez les étapes de cette section dans le compte de l'expéditeur. Le rôle doit exister dans le compte de l'expéditeur et vous devez spécifier l'ARN de ce rôle dans le filtre d'abonnement. Dans cet exemple, le compte de l'expéditeur est `111111111111`.
**Pour créer le rôle IAM nécessaire pour les abonnements aux journaux entre comptes à l'aide de AWS Organizations**
1. Créez la politique de confiance suivante dans un fichier `/TrustPolicyForCWLSubscriptionFilter.json`. Utilisez un éditeur de texte pour créer ce fichier de politique, n'utilisez pas la console IAM.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Créez le rôle IAM qui utilise cette politique. Notez la valeur `Arn` qui est renvoyée par la commande ; vous en aurez besoin ultérieurement dans cette procédure. Dans cet exemple, nous utilisons `CWLtoSubscriptionFilterRole` pour connaître le nom du rôle que nous créons.
```
aws iam create-role \
--role-name CWLtoSubscriptionFilterRole \
--assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
```
1. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte.
1. Utilisez d'abord un éditeur de texte pour créer la politique d'autorisations suivante dans un fichier nommé `~/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Saisissez la commande suivante pour associer la politique d'autorisations que vous venez de créer au rôle que vous avez créé à l'étape 2.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
Lorsque vous aurez terminé, vous pouvez passer à [Étape 3 : créer une politique de filtrage des abonnements au niveau du compte](CreateSubscriptionFilter-Account.md).
# Étape 3 : créer une politique de filtrage des abonnements au niveau du compte
Une fois que vous avez créé une destination, le compte du destinataire des données du journal peut partager l'ARN de destination (arn:aws:logs:us-east-1:999999999999:destination:testDestination) avec d'autres comptes AWS afin qu'ils puissent envoyer des événements du journal vers la même destination. Les utilisateurs des autres comptes d'expédition créent ensuite un filtre d'abonnement sur leurs groupes de journaux respectifs par rapport à cette destination. Ce filtre d'abonnement lance immédiatement la transmission de données du journal en temps réel à partir du groupe de journaux choisi vers la destination spécifiée.
**Note**
Si vous accordez des autorisations pour le filtre d'abonnement à l'ensemble d'une organisation, vous devez utiliser l'ARN du rôle IAM que vous avez créé dans [Étape 2 : (uniquement si vous utilisez une organisation) créer un rôle IAM](CreateSubscriptionFilter-IAMrole-Account.md).
Dans l'exemple suivant, une politique de filtrage d'abonnement au niveau du compte est créée dans un compte expéditeur. Le filtre est associé au compte expéditeur `111111111111` afin que chaque événement du journal correspondant au filtre et aux critères de sélection soit envoyé à la destination que vous avez créée précédemment. Cette destination encapsule un flux appelé « RecipientStream ».
Ce `selection-criteria` champ est facultatif, mais il est important pour exclure les groupes de journaux susceptibles de provoquer une récursivité infinie des journaux à partir d'un filtre d'abonnement. Pour plus d'informations sur ce problème et pour déterminer les groupes de journaux à exclure, consultez[Prévention de la récursivité dans les journaux](Subscriptions-recursion-prevention.md). NOT IN est actuellement le seul opérateur pris en charge pour`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"
```
Les groupes de journaux du compte expéditeur et la destination doivent se trouver dans la même AWS région. Toutefois, la destination peut pointer vers une AWS ressource telle qu'un flux Amazon Kinesis Data Streams situé dans une autre région.
# Validation du flux des événements des journaux
Une fois que vous avez créé la politique de filtrage des abonnements au niveau du compte, CloudWatch Logs transmet tous les événements de journal entrants qui correspondent au modèle de filtre et aux critères de sélection au flux encapsulé dans le flux de destination appelé « ». **RecipientStream** Le propriétaire de la destination peut vérifier que cela se produit en utilisant la get-shard-iterator commande **aws kinesis** pour récupérer une partition Amazon Kinesis Data Streams, et en utilisant **la commande aws kinesis get-records pour récupérer certains enregistrements Amazon Kinesis Data** Streams :
```
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"
```
**Note**
Vous devrez peut-être réexécuter la `get-records` commande plusieurs fois avant qu'Amazon Kinesis Data Streams ne commence à renvoyer des données.
Vous devriez voir une réponse contenant un ensemble d'enregistrements Amazon Kinesis Data Streams. L'attribut de données de l'enregistrement Amazon Kinesis Data Streams est compressé au format gzip puis codé en base64. Vous pouvez examiner les données brutes à partir de la ligne de commande au moyen de la commande Unix suivante :
```
echo -n "" | base64 -d | zcat
```
Les données codées et décompressées en base64 sont formatées au format JSON avec la structure suivante :
```
{
"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\"}"
}
]
}
```
Les principaux éléments de la structure de données sont les suivants :
**messageType**
Les données de messages utiliseront le type « DATA\$1MESSAGE ». Parfois, CloudWatch Logs peut émettre des enregistrements Amazon Kinesis Data Streams de type « CONTROL\$1MESSAGE », principalement pour vérifier si la destination est accessible.
**owner**
L'ID de AWS compte des données du journal d'origine.
**logGroup**
Le nom du groupe de journaux des données du journal source.
**logStream**
Le nom du flux de journaux des données du journal source.
**subscriptionFilters**
La liste des noms de filtres d'abonnements qui correspondaient aux données du journal source.
**logEvents**
Les données du journal réelles, représentées sous la forme d'un tableau d'enregistrements d'événements du journal. La propriété « id » est un identifiant unique pour chaque événement de journal.
**Niveau de la politique**
Niveau auquel la politique a été appliquée. « ACCOUNT\$1LEVEL\$1POLICY » correspond à une politique de filtrage `policyLevel` d'abonnement au niveau du compte.
# Modification de l'appartenance à une destination au moment de l'exécution
Vous pouvez rencontrer des situations où vous devez ajouter ou supprimer l'adhésion de certains utilisateurs pour l'une de vos destinations. Vous pouvez utiliser la commande `put-destination-policy` sur votre destination avec une nouvelle stratégie d'accès. Dans l'exemple suivant, un compte précédemment ajouté **111111111111** est écarté de l'envoi de données du journal supplémentaires, et le compte **222222222222** est activé.
1. Récupérez la politique actuellement associée à la **destination TestDestination** et notez : **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. Mettez à jour la politique de façon à refléter l'arrêt du compte **111111111111** et l'activation du compte **222222222222**. Insérez cette politique dans le fichier **\$1/ NewAccessPolicy .json** :
------
#### [ 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. Appelez **PutDestinationPolicy**pour associer la politique définie dans le fichier **NewAccessPolicy.json** à la destination :
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Cela finira par désactiver les événements du journal à partir de l'ID de compte **111111111111**. Les événements du journal de l'ID de compte **222222222222** commencent à passer à la destination dès que le propriétaire du compte **222222222222** crée un filtre d'abonnement.
# Mise à jour d'un abonnement existant entre comptes
Si vous disposez actuellement d'un abonnement aux journaux entre comptes où le compte de destination n'accorde des autorisations qu'à des comptes d'expéditeur spécifiques et que vous souhaitez mettre à jour cet abonnement, afin que le compte de destination accorde l'accès à tous les comptes d'une organisation, suivez les étapes décrites dans cette section.
**Topics**
+ [Étape 1 : mettre à jour les filtres d'abonnement](Cross-Account-Log_Subscription-Update-filter-Account.md)
+ [Étape 2 : mettre à jour la stratégie d'accès de la destination existante](Cross-Account-Log_Subscription-Update-policy-Account.md)
# Étape 1 : mettre à jour les filtres d'abonnement
**Note**
Cette étape est nécessaire uniquement pour les abonnements entre comptes pour les journaux créés par les services répertoriés dans [Activer la journalisation à partir AWS des services](AWS-logs-and-resource-policy.md). Si vous ne travaillez pas avec les journaux créés par l'un de ces groupes de journaux, vous pouvez passer à [Étape 2 : mettre à jour la stratégie d'accès de la destination existante](Cross-Account-Log_Subscription-Update-policy-Account.md).
Dans certains cas, vous devez mettre à jour les filtres d'abonnement dans tous les comptes d'expéditeur qui envoient des journaux au compte de destination. La mise à jour ajoute un rôle IAM, qui CloudWatch peut supposer et valider que le compte expéditeur est autorisé à envoyer des journaux au compte destinataire.
Suivez les étapes de cette section pour chaque compte d'expéditeur que vous souhaitez mettre à jour, afin qu'il utilise l'ID d'organisation pour les autorisations d'abonnement entre comptes.
Dans les exemples présentés dans cette section, deux comptes, `111111111111` et `222222222222`, disposent de filtres d'abonnement pour envoyer des journaux au compte `999999999999`. Les valeurs de filtre d'abonnement existantes sont les suivantes :
```
## Existing Subscription Filter parameter values
{
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"FilterPattern": "{$.userIdentity.type = Root}",
"Distribution": "Random"
}
```
Si vous devez rechercher les valeurs actuelles des paramètres de filtre d'abonnement, saisissez la commande suivante.
```
aws logs describe-account-policies \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-name "CrossAccountStreamsExamplePolicy"
```
**Pour mettre à jour un filtre d'abonnement afin de commencer à utiliser l'organisation IDs pour les autorisations de journalisation entre comptes**
1. Créez la politique de confiance suivante dans un fichier `~/TrustPolicyForCWL.json`. Utilisez un éditeur de texte pour créer ce fichier de politique, n'utilisez pas la console IAM.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Créez le rôle IAM qui utilise cette politique. Notez la valeur `Arn` de la valeur `Arn` qui est renvoyée par la commande ; vous en aurez besoin ultérieurement dans cette procédure. Dans cet exemple, nous utilisons `CWLtoSubscriptionFilterRole` pour connaître le nom du rôle que nous créons.
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.json
```
1. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte.
1. Utilisez d'abord un éditeur de texte pour créer la politique d'autorisations suivante dans un fichier nommé `/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Saisissez la commande suivante pour associer la politique d'autorisations que vous venez de créer au rôle que vous avez créé à l'étape 2.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
1. Entrez la commande suivante pour mettre à jour la politique de filtrage des abonnements.
```
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"
```
# Étape 2 : mettre à jour la stratégie d'accès de la destination existante
Une fois que vous avez mis à jour les filtres d'abonnement dans tous les comptes d'expéditeur, vous pouvez mettre à jour la stratégie d'accès de la destination dans le compte du destinataire.
Dans les exemples suivants, le compte du destinataire est `999999999999` et la destination est nommée `testDestination`.
La mise à jour permet à tous les comptes qui font partie de l'organisation ayant un ID `o-1234567890` d'envoyer des journaux au compte du destinataire. Seuls les comptes avec des filtres d'abonnement envoient des journaux au compte du destinataire.
**Pour mettre à jour la stratégie d'accès de la destination dans le compte du destinataire, afin qu'il commence à utiliser un ID d'organisation pour les autorisations**
1. Dans le compte du destinataire, utilisez un éditeur de texte pour créer un fichier `~/AccessPolicy.json` avec le contenu suivant.
------
#### [ 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. Saisissez la commande suivante pour attacher la politique que vous venez de créer à la destination existante. Pour mettre à jour une destination afin d'utiliser une politique d'accès avec un identifiant d'organisation au lieu d'une politique d'accès répertoriant un AWS compte spécifique IDs, incluez le `force` paramètre.
**Avertissement**
Si vous travaillez avec des journaux envoyés par un AWS service répertorié dans[Activer la journalisation à partir AWS des services](AWS-logs-and-resource-policy.md), avant de procéder à cette étape, vous devez d'abord avoir mis à jour les filtres d'abonnement dans tous les comptes d'expéditeurs, comme expliqué dans[Étape 1 : mettre à jour les filtres d'abonnement](Cross-Account-Log_Subscription-Update-filter-Account.md).
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Abonnements entre comptes et entre régions à l'aide de Firehose
Pour partager des données du journal entre comptes, vous devez spécifier un expéditeur et un récepteur :
+ **Expéditeur des données de journal** : obtient les informations de destination auprès du destinataire et CloudWatch indique à Logs qu'il est prêt à envoyer ses événements de journal à la destination spécifiée. Dans les procédures décrites dans le reste de cette section, l'expéditeur des données du journal est indiqué avec un numéro de AWS compte fictif 111111111111.
+ **Destinataire des données de journal** : définit une destination qui encapsule un flux Amazon Kinesis Data Streams et indique à CloudWatch Logs que le destinataire souhaite recevoir des données de journal. Le destinataire partage ensuite les informations sur cette destination avec l'expéditeur. Dans les procédures décrites dans le reste de cette section, le destinataire des données du journal est indiqué avec un numéro de AWS compte fictif 222222222222.
L'exemple présenté dans cette section utilise un flux de diffusion Firehose avec un espace de stockage Amazon S3. Vous pouvez également configurer les flux de diffusion Firehose avec différents paramètres. Pour plus d'informations, consultez [Création d'un flux de diffusion Firehose](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).
**Note**
Le groupe de journaux et la destination doivent se trouver dans la même AWS région. Cependant, la AWS ressource pointée par la destination peut être située dans une autre région.
**Note**
Le filtre d'abonnement Firehose pour un ***même compte*** et un flux de diffusion ***interrégional*** sont pris en charge.
**Topics**
+ [Étape 1 : créer un flux de diffusion Firehose](CreateFirehoseStream-Account.md)
+ [Étape 2 : créer une destination](CreateFirehoseStreamDestination-Account.md)
+ [Étape 3 : créer une politique de filtrage des abonnements au niveau du compte](CreateSubscriptionFilterFirehose-Account.md)
+ [Validation du flux des événements de journaux](ValidateLogEventFlowFirehose-Account.md)
+ [Modification de l'abonnement à la destination au moment de l'exécution](ModifyDestinationMembershipFirehose-Account.md)
# Étape 1 : créer un flux de diffusion Firehose
**Important**
Avant d'effectuer les étapes suivantes, vous devez utiliser une politique d'accès afin que Firehose puisse accéder à votre compartiment Amazon S3. Pour plus d'informations, consultez [Controlling Access](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3) dans le manuel *Amazon Data Firehose Developer Guide*.
Toutes les étapes de cette section (Étape 1) doivent être réalisées dans le compte du destinataire des données du journal.
USA Est (Virginie du Nord) est utilisé dans les exemples de commandes suivants. Remplacez la région par la celle appropriée pour votre déploiement.
**Pour créer un flux de diffusion Firehose à utiliser comme destination**
1. Créez un compartiment Amazon S3 :
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. Créez le rôle IAM qui autorise Firehose à placer des données dans le bucket.
1. D'abord, utilisez un éditeur de texte pour créer une politique d'approbation dans un fichier `~/TrustPolicyForFirehose.json`.
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. Créez le rôle IAM, en spécifiant le fichier de politique d'approbation que vous venez de créer.
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. La sortie de cette commande ressemblera à ce qui suit. Notez le nom du rôle et l'ARN du rôle.
```
{
"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. Créez une politique d'autorisation pour définir les actions que Firehose peut effectuer sur votre compte.
1. Utilisez d'abord un éditeur de texte pour créer la politique d'autorisations suivante dans un fichier nommé `~/PermissionsForFirehose.json`. Selon votre cas d'utilisation, il se peut que vous deviez ajouter des autorisations supplémentaires à ce fichier.
```
{
"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. Saisissez la commande suivante pour associer la politique d'autorisation que vous venez de créer au rôle IAM.
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. Entrez la commande suivante pour créer le flux de diffusion Firehose. Remplacez *my-role-arn* et *amzn-s3-demo-bucket2-arn* par les valeurs correctes pour votre déploiement.
```
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"}'
```
La sortie doit ressembler à ce qui suit :
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# Étape 2 : créer une destination
**Important**
Toutes les étapes de cette procédure doivent être réalisées dans le compte du destinataire des données du journal.
Lorsque la destination est créée, CloudWatch Logs envoie un message test à la destination au nom du compte du destinataire. Lorsque le filtre d'abonnement est activé ultérieurement, CloudWatch Logs envoie les événements du journal à la destination au nom du compte source.
**Pour créer une destination**
1. Attendez que le stream Firehose que vous avez créé soit actif[Étape 1 : créer un flux de diffusion Firehose](CreateFirehoseStream-Account.md). Vous pouvez utiliser la commande suivante pour vérifier le **StreamDescription. StreamStatus**propriété.
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
En outre, prenez note du **DeliveryStreamDescription. DeliveryStreamValeur ARN**, car vous devrez l'utiliser ultérieurement. Exemple de résultat de cette commande :
```
{
"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
}
}
```
Votre flux de diffusion peut prendre une ou deux minutes avant d'apparaître avec le statut actif.
1. Lorsque le flux de diffusion est actif, créez le rôle IAM qui autorisera CloudWatch Logs à insérer des données dans votre flux Firehose. Tout d'abord, vous devez créer une politique de confiance dans un fichier **\$1/ TrustPolicyFor CWL.json**. Utilisez un éditeur de texte créer cette stratégie. Pour plus d'informations sur les points de terminaison de CloudWatch Logs, consultez la section Points de [terminaison et quotas Amazon CloudWatch Logs](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html).
Cette politique comprend une clé de contexte de condition globale `aws:SourceArn` qui spécifie le `sourceAccountId` pour aider à prévenir le problème de sécurité du député confus. Si vous ne connaissez pas encore l'ID du compte source lors du premier appel, nous vous recommandons de placer l'ARN de destination dans le champ ARN source. Dans les appels suivants, vous devez définir l'ARN source comme ARN source réel que vous avez recueilli lors du premier appel. Pour plus d'informations, consultez [Prévention du député confus](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. Utilisez la commande **aws iam create-role** pour créer le rôle IAM, en spécifiant le fichier de politique d'approbation que vous venez de créer.
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
Voici un exemple de sortie. Prenez note de la valeur `Role.Arn` retournée, car vous devrez l'utiliser dans une étape ultérieure.
```
{
"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. Créez une politique d'autorisation pour définir les actions que CloudWatch Logs peut effectuer sur votre compte. Utilisez d'abord un éditeur de texte pour créer une politique d'autorisations dans un fichier **\$1/ PermissionsFor CWL.json** :
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. Associez la politique d'autorisations au rôle en entrant la commande suivante :
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Une fois que le flux de diffusion Firehose est actif et que vous avez créé le rôle IAM, vous pouvez créer la CloudWatch destination Logs.
1. Cette étape n'associera pas de stratégie d'accès à votre destination. Il s'agit uniquement de la première de deux étapes pour créer une destination. Notez l'ARN de la nouvelle destination qui est renvoyé dans la charge utile, car vous l'utiliserez comme `destination.arn` dans une étape ultérieure.
```
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. Une fois l'étape précédente terminée, dans le compte des données du journal du destinataire (222222222222), associez une stratégie d'accès à la destination. Cette politique permet au compte de l'expéditeur des données du journal (111111111111) d'accéder à la destination dans le compte du destinataire des données du journal (222222222222). Vous pouvez utiliser un éditeur de texte pour mettre cette politique dans le `~/AccessPolicy.json` fichier :
------
#### [ 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. Cela crée une stratégie définissant qui a accès en écriture à la destination. Cette politique doit spécifier les `logs:PutAccountPolicy` actions `logs:PutSubscriptionFilter` et pour accéder à la destination. Les utilisateurs multicomptes utiliseront les `PutAccountPolicy` actions `PutSubscriptionFilter` et pour envoyer les événements du journal à la destination.
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# Étape 3 : créer une politique de filtrage des abonnements au niveau du compte
Passez au compte d'envoi, qui est 111111111111 dans cet exemple. Vous allez maintenant créer la politique de filtrage des abonnements au niveau du compte dans le compte expéditeur. Dans cet exemple, le filtre fait en sorte que chaque événement de journal contenant la chaîne `ERROR` de tous les groupes de journaux sauf deux soit livré à la destination que vous avez créée précédemment.
```
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"
```
Les groupes de log du compte expéditeur et la destination doivent se trouver dans la même AWS région. Cependant, la destination peut pointer vers une AWS ressource telle qu'un flux Firehose situé dans une autre région.
# Validation du flux des événements de journaux
Après avoir créé le filtre d'abonnement, CloudWatch Logs transmet tous les événements de journal entrants qui correspondent au modèle de filtre et aux critères de sélection au flux de diffusion Firehose. Les données commencent à apparaître dans votre compartiment Amazon S3 en fonction de l'intervalle de temps défini dans le flux de diffusion Firehose. Après un délai suffisant, vous pouvez consulter le compartiment Amazon S3 pour vérifier vos données. Pour vérifier le compartiment, saisissez la commande suivante :
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
La sortie de cette commande sera similaire à ce qui suit :
```
{
"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"
}
}
]
}
```
Vous pouvez ensuite récupérer un objet spécifique du compartiment en entrant la commande suivante. Remplacez la valeur de `key` par la valeur que vous avez trouvée dans la commande précédente.
```
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
```
Les données dans l'objet Amazon S3 sont comprimées au format gzip. Vous pouvez examiner les données brutes à partir de la ligne de commande en utilisant l'une des commandes suivantes :
Linux :
```
zcat testfile.gz
```
macOS :
```
zcat
Vous pouvez rencontrer des situations où vous devez ajouter ou supprimer des expéditeurs de journaux d'une destination qui vous appartient. Vous pouvez utiliser les `PutAccountPolicy` actions **PutDestinationPolicy**et sur votre destination avec la nouvelle politique d'accès. Dans l'exemple suivant, un compte précédemment ajouté **111111111111** est écarté de l'envoi de données du journal supplémentaires, et le compte **333333333333** est activé.
1. Récupérez la politique actuellement associée à la **destination TestDestination** et notez : **AccessPolicy**
```
aws logs describe-destinations \
--destination-name-prefix "testFirehoseDestination"
```
Les données renvoyées peuvent ressembler à ceci.
```
{
"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. Mettez à jour la politique de façon à refléter l'arrêt du compte **111111111111** et l'activation du compte **333333333333**. Insérez cette politique dans le fichier **\$1/ NewAccessPolicy .json** :
------
#### [ 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. Utilisez la commande suivante pour associer la politique définie dans le fichier **NewAccessPolicy.json** à la destination :
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Cela désactive éventuellement les événements du journal à partir de l'ID de compte **111111111111**. Les événements du journal de l'ID de compte **333333333333** commencent à passer à la destination dès que le propriétaire du compte **333333333333** crée un filtre d'abonnement.
# Prévention du député confus
Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner la confusion des adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le service appelant) appelle un autre service (le service appelé). Le service appelant peut être manipulé et ses autorisations utilisées pour agir sur les ressources d’un autre client auxquelles on ne serait pas autorisé à accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services auprès des principaux fournisseurs de services qui ont obtenu l'accès aux ressources de votre compte.
Nous recommandons d'utiliser les clés [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid)contextuelles [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn),, et de condition [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgpaths)globale dans les politiques de ressources afin de limiter les autorisations qui accordent un autre service à la ressource. Utilisez `aws:SourceArn` pour associer une seule ressource à l’accès interservice. Utilisez `aws:SourceAccount` pour permettre à n’importe quelle ressource de ce compte d’être associée à l’utilisation interservice. Utilisez `aws:SourceOrgID` pour permettre à n’importe quelle ressource de n’importe quel compte au sein d’une organisation d’être associée à l’utilisation interservice. Utilisez `aws:SourceOrgPaths` pour associer n’importe quelle ressource des comptes d’un chemin d’accès AWS Organizations à l’utilisation interservice. Pour plus d'informations sur l'utilisation et la compréhension des chemins, voir [Comprendre le chemin de l' AWS Organizations entité](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_last-accessed-view-data-orgs.html#access_policies_last-accessed-viewing-orgs-entity-path).
Le moyen le plus efficace de se protéger contre le problème de député confus consiste à utiliser la clé de contexte de condition globale `aws:SourceArn` avec l’ARN complet de la ressource. Si vous ne connaissez pas l’ARN complet de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de contexte de condition globale `aws:SourceArn` avec des caractères génériques (`*`) pour les parties inconnues de l’ARN. Par exemple, `arn:aws:servicename:*:123456789012:*`.
Si la valeur `aws:SourceArn` ne contient pas l'ID du compte, tel qu'un ARN de compartiment Amazon S3, vous devez utiliser à la fois `aws:SourceAccount` et `aws:SourceArn` pour limiter les autorisations.
Pour se protéger contre le problème de l'adjoint confus à grande échelle, utilisez la clé de contexte de condition globale `aws:SourceOrgID` ou `aws:SourceOrgPaths` avec l'ID de l'organisation ou le chemin de l'organisation de la ressource dans vos politiques basées sur les ressources. Lorsque vous ajoutez, supprimez et déplacez des comptes dans votre organisation, les politiques qui contiennent la clé `aws:SourceOrgID` ou `aws:SourceOrgPaths` incluront automatiquement les bons comptes et vous n'avez pas besoin de mettre manuellement à jour les polices.
Les politiques documentées pour autoriser l'accès aux CloudWatch journaux afin d'y écrire des données [Étape 1 : créer une destination](CreateDestination.md) dans Amazon Kinesis Data Streams [Étape 2 : créer une destination](CreateFirehoseStreamDestination.md) et Firehose montrent comment vous pouvez utiliser la clé de contexte de condition globale pour éviter `aws:SourceArn` le problème de confusion lié aux adjoints.
# Prévention de la récursivité dans les journaux
Les filtres d'abonnement risquent de provoquer une récursivité infinie des journaux, ce qui peut entraîner une forte augmentation de la facturation d'ingestion, à la fois dans les CloudWatch journaux et dans votre destination, s'ils ne sont pas évités. Cela peut se produire lorsqu'un filtre d'abonnement est associé à un groupe de journaux qui reçoit les événements du journal à la suite du flux de livraison de votre abonnement. Les journaux ingérés dans le groupe de journaux seront livrés à la destination, ce qui obligera le groupe de journaux à ingérer davantage de journaux qui seront ensuite redirigés vers la destination, créant ainsi une boucle de récursivité.
Par exemple, imaginez un filtre d'abonnement dont la destination est Firehose, qui transmet les événements du journal à Amazon S3. En outre, il existe également une fonction Lambda qui traite les nouveaux événements transmis à Amazon S3 et produit elle-même certains journaux. Si le filtre d'abonnement est appliqué au groupe de journaux de la fonction Lambda, les événements de journal produits par la fonction seront transmis à Firehose et Amazon S3 à destination, qui invoqueront ensuite à nouveau la fonction, ce qui entraînera la production et le transfert d'autres journaux vers Firehose et Amazon S3, provoquant une nouvelle invocation de la fonction, etc. Cela se produira en boucle infinie, entraînant une augmentation inattendue de la facturation lors de l'ingestion des journaux, de Firehose et d'Amazon S3.
Si la fonction Lambda est attachée à un VPC dont les journaux de flux sont activés pour les journaux, le groupe de CloudWatch journaux du VPC peut également provoquer une récursivité des journaux.
Nous vous recommandons de ne pas appliquer de filtres d'abonnement aux groupes de journaux qui font partie du flux de livraison de vos abonnements. Pour les filtres d'abonnement au niveau du compte, utilisez le `selectionCriteria` paramètre de l'`PutAccountPolicy`API pour exclure ces groupes de journaux de la politique.
Lorsque vous excluez des groupes de journaux, considérez les AWS services suivants qui produisent des journaux et peuvent faire partie des flux de travail de livraison de vos abonnements :
+ Amazon EC2 avec Fargate
+ Lambda
+ AWS Step Functions
+ Journaux de flux Amazon VPC activés pour les journaux CloudWatch
**Note**
Les événements de journal produits par le groupe de journaux d'une destination Lambda ne seront pas renvoyés à la fonction Lambda pour une politique de filtrage des abonnements au niveau du compte. Dans ce cas, il n'`selectionCriteria`est pas nécessaire d'exclure l'utilisation du groupe de journaux par la fonction Lambda de destination pour les politiques d'abonnement au compte.