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. # 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.