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