As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Assinaturas multiregionais em nível de conta usando o Amazon Kinesis Data Streams
Ao criar uma assinatura entre contas, você pode especificar uma única conta ou organização para ser o remetente. Se você especificar uma organização, esse procedimento permitirá que todas as contas da organização enviem logs para a conta do receptor.
Para compartilhar dados de log entre contas, você precisa estabelecer um remetente e um destinatário dos dados de log:
+ **Remetente dos dados de registro** — obtém as informações de destino do destinatário e informa ao CloudWatch Logs que ele está pronto para enviar seus eventos de registro para o destino especificado. Nos procedimentos do restante desta seção, o remetente dos dados de log é mostrado com um número de AWS conta fictício de 111111111111.
Se você quiser que várias contas em uma organização enviem logs para uma conta de destinatário, você pode criar uma política que conceda a todas as contas da organização a permissão para enviar logs para a conta do destinatário. Você ainda precisa configurar filtros de assinatura diferentes para cada conta de remetente.
+ **Destinatário dos dados de log** — configura um destino que encapsula um stream do Amazon Kinesis Data Streams CloudWatch e informa ao Logs que o destinatário deseja receber dados de log. O destinatário, então, compartilha as informações sobre esse destino com o remetente. Nos procedimentos do restante desta seção, o destinatário dos dados de registro é mostrado com um número de AWS conta fictício de 999999999999.
Para começar a receber eventos de registro de usuários de várias contas, o destinatário dos dados de registro primeiro cria um destino de CloudWatch registros. Cada destino consiste nos seguintes elementos-chave:
**Nome do destino**
O nome do destino que você deseja criar.
**ARN de destino**
O Amazon Resource Name (ARN) do AWS recurso que você deseja usar como destino do feed de assinatura.
**ARN de função**
Uma função AWS Identity and Access Management (IAM) que concede aos CloudWatch Logs as permissões necessárias para colocar dados no stream escolhido.
**Política de acesso**
Documento de políticas do IAM (no formato JSON, gravado usando a gramática de políticas do IAM) que controla o conjunto de usuários que têm permissão para gravar em seu destino.
**nota**
O grupo de registros e o destino devem estar na mesma AWS região. No entanto, o AWS recurso para o qual o destino aponta pode estar localizado em uma região diferente. Nos exemplos das seções a seguir, todos os recursos específicos da região são criados no Leste dos EUA (Virgínia do Norte).
**Topics**
+ [
# Como configurar uma nova assinatura entre contas
](Cross-Account-Log_Subscription-New-Account.md)
+ [
# Atualizar uma assinatura existente entre contas
](Cross-Account-Log_Subscription-Update-Account.md)
# Como configurar uma nova assinatura entre contas
Siga as etapas nestas seções para configurar uma nova assinatura de log entre contas.
**Topics**
+ [
# Etapa 1: criar um destino
](CreateDestination-Account.md)
+ [
# Etapa 2: (somente se estiver usando uma organização) Crie uma função do IAM.
](CreateSubscriptionFilter-IAMrole-Account.md)
+ [
# Etapa 3: criar uma política de filtro de assinatura ao nível da conta
](CreateSubscriptionFilter-Account.md)
+ [
# Validação do fluxo de eventos de logs
](ValidateLogEventFlow-Account.md)
+ [
# Modificar a associação de destino no runtime
](ModifyDestinationMembership-Account.md)
# Etapa 1: criar um destino
**Importante**
As etapas deste procedimento devem ser processadas na conta destinatária dos dados do log.
Neste exemplo, a conta do destinatário dos dados de registro tem uma ID de conta de 999999999999, enquanto a ID da AWS conta do remetente dos dados de registro é 111111111111. AWS
Este exemplo cria um destino usando um stream do Amazon Kinesis Data RecipientStream Streams chamado, e uma função CloudWatch que permite que a Logs grave dados nele.
Quando o destino é criado, o CloudWatch Logs envia uma mensagem de teste para o destino em nome da conta do destinatário. Quando o filtro de assinatura é ativado posteriormente, o CloudWatch Logs envia eventos de registro para o destino em nome da conta de origem.
**Para criar um destino**
1. Na conta do destinatário, crie um stream de destino no Amazon Kinesis Data Streams. Em um prompt de comando, digite:
```
aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
```
1. Aguarde até que o fluxo do fique ativo. **Você pode usar o comando **aws kinesis describe-stream** para verificar o. StreamDescription StreamStatus**propriedade. Além disso, anote o valor **StreamDescription.streamArn** porque você o passará para CloudWatch o Logs posteriormente:
```
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"
}
}
]
}
}
```
Pode levar um ou dois minutos para o seu stream aparecer no estado ativo.
1. Crie a função do IAM que concede a CloudWatch Logs a permissão para colocar dados em seu stream. Primeiro, você precisará criar uma política de confiança em um arquivo **TrustPolicyFor\$1/CWL.json**. Use um editor de texto para criar esse arquivo de política, não use o console do IAM.
Esta política inclui uma chave de contexto de condição global `aws:SourceArn` que especifica o `sourceAccountId` para evitar o problema de segurança confused deputy. Se você ainda não souber o ID da conta de origem na primeira chamada, recomendamos que você coloque o ARN de destino no campo ARN de origem. Nas chamadas subsequentes, você deve definir o ARN de origem como o ARN de origem real que você coletou da primeira chamada. Para obter mais informações, consulte [Prevenção de ‘confused deputy’](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. Use o comando **aws iam create-role** para criar a função do IAM especificando o arquivo de política de confiança. Anote o valor Role.Arn retornado porque ele também será passado para Logs posteriormente: CloudWatch
```
aws iam create-role \
--role-name CWLtoKinesisRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
{
"Role": {
"AssumeRolePolicyDocument": {
"Statement": {
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
},
"Principal": {
"Service": "logs.amazonaws.com"
}
}
},
"RoleId": "AAOIIAH450GAB4HC5F431",
"CreateDate": "2023-05-29T13:46:29.431Z",
"RoleName": "CWLtoKinesisRole",
"Path": "/",
"Arn": "arn:aws:iam::999999999999:role/CWLtoKinesisRole"
}
}
```
1. Crie uma política de permissões para definir quais ações o CloudWatch Logs pode realizar na sua conta. Primeiro, use um editor de texto para criar uma política de permissões em um arquivo **PermissionsFor\$1/CWL.json**:
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
}
]
}
```
1. Associe a política de permissões à função usando o put-role-policy comando **aws iam**:
```
aws iam put-role-policy \
--role-name CWLtoKinesisRole \
--policy-name Permissions-Policy-For-CWL \
--policy-document file://~/PermissionsForCWL.json
```
1. Depois que o stream estiver no estado ativo e você tiver criado a função do IAM, você poderá criar o destino dos CloudWatch registros.
1. Esta etapa não associará uma política de acesso ao seu destino e é apenas a primeira etapa de duas que concluirá uma criação de destino. Anote o **DestinationArn** que for retornado na carga útil:
```
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. Depois que a etapa 7a for concluída, na conta destinatária dos dados de log, associe uma política de acesso ao destino. Essa política deve especificar os **registros: PutSubscriptionFilter** ação e concede permissão à conta do remetente para acessar o destino.
A política concede permissão à AWS conta que envia os registros. Você pode especificar apenas essa conta na política ou, se a conta de remetente for parte de uma organização, a política poderá especificar o ID da organização. Dessa forma, você pode criar apenas uma política para permitir que várias contas em uma organização enviem logs para essa conta de destino.
Use um editor de texto para criar um arquivo chamado `~/AccessPolicy.json` com uma das seguintes declarações de política.
Este primeiro exemplo de política permite que todas as contas na organização que tenham um ID de `o-1234567890` enviem logs à conta do destinatário.
------
#### [ 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"
]
}
}
}
]
}
```
------
Este próximo exemplo permite que apenas a conta remetente dos dados de log (111111111111) envie logs à conta destinatária dos dados de log.
------
#### [ 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. Anexe a política criada na etapa anterior ao destino.
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/AccessPolicy.json
```
Essa política de acesso permite que os usuários da AWS Conta com ID 111111111111 liguem para o destino com o ARN arn:aws:logs **PutSubscriptionFilter**::999999999999:destination:testDestination. *region* A tentativa de qualquer outro usuário de ligar PutSubscriptionFilter para esse destino será rejeitada.
Para validar os privilégios de um usuário com base em uma política de acesso, consulte [Usar o validador de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html) no *Manual do usuário do IAM*.
Ao terminar, se estiver usando AWS Organizations suas permissões entre contas, siga as etapas em[Etapa 2: (somente se estiver usando uma organização) Crie uma função do IAM.](CreateSubscriptionFilter-IAMrole-Account.md). Se você estiver concedendo permissões diretamente para a outra conta em vez de usar Organizations, você pode pular essa etapa e prosseguir para [Etapa 3: criar uma política de filtro de assinatura ao nível da conta](CreateSubscriptionFilter-Account.md).
# Etapa 2: (somente se estiver usando uma organização) Crie uma função do IAM.
Na seção anterior, se você criou o destino usando uma política de acesso que concede permissões à organização em que está a conta `111111111111`, em vez de conceder permissões diretamente para a conta `111111111111`, siga as etapas nesta seção. Caso contrário, pule para [Etapa 3: criar uma política de filtro de assinatura ao nível da conta](CreateSubscriptionFilter-Account.md).
As etapas desta seção criam uma função do IAM, que CloudWatch pode assumir e validar se a conta do remetente tem permissão para criar um filtro de assinatura em relação ao destino do destinatário.
Siga as etapas nesta seção na conta do remetente. A função deve existir na conta do remetente e você especifica o ARN dessa função no filtro de assinatura. Neste exemplo, a conta de remetente é `111111111111`.
**Para criar a função do IAM necessária para assinaturas de registro entre contas usando AWS Organizations**
1. Crie a seguinte política de confiança em um arquivo `/TrustPolicyForCWLSubscriptionFilter.json`. Use um editor de texto para criar esse arquivo de política; não use o console do IAM.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Crie uma função do IAM que use essa política. Anote o valor `Arn` retornado pelo comando, pois você precisará dele posteriormente nesse procedimento. Neste exemplo, usamos `CWLtoSubscriptionFilterRole` como o nome da função que estamos criando.
```
aws iam create-role \
--role-name CWLtoSubscriptionFilterRole \
--assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
```
1. Crie uma política de permissões para definir as ações que o CloudWatch Logs pode realizar na sua conta.
1. Primeiro, use um editor de texto para criar a seguinte política de permissões em um arquivo chamado `~/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Insira o seguinte comando para associar a política de permissões que você acabou de criar à função criada na etapa 2.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
Quando terminar, você pode prosseguir para [Etapa 3: criar uma política de filtro de assinatura ao nível da conta](CreateSubscriptionFilter-Account.md).
# Etapa 3: criar uma política de filtro de assinatura ao nível da conta
Depois de criar um destino, a conta destinatária dos dados de log pode compartilhar o ARN do destino (arn:aws:logs:us-east-1:999999999999:destination:testDestination) com outras contas da AWS para que elas possam enviar seus eventos de log para o mesmo destino. Esses outros usuários de contas de envio criam um filtro de assinatura em seus respectivos grupos de log para esse destino. O filtro de assinatura filtrar inicia imediatamente o fluxo de dados de log em tempo real a partir do grupo de logs escolhido para o destino especificado.
**nota**
Se você estiver concedendo permissões para o filtro de assinatura a uma organização inteira, precisará usar o ARN do perfil do IAM que criou em [Etapa 2: (somente se estiver usando uma organização) Crie uma função do IAM.](CreateSubscriptionFilter-IAMrole-Account.md).
No exemplo a seguir, uma política de filtro de assinatura ao nível da conta é criada em uma conta de envio. O filtro é associado à conta de envio `111111111111` de modo que todos os eventos de log que corresponderem ao filtro e aos critérios de seleção sejam entregues ao destino que você criou anteriormente. Esse destino encapsula um fluxo chamado "”RecipientStream.
O campo `selection-criteria` é opcional, mas é importante para excluir de um filtro de assinatura os grupos de logs que possam causar uma repetição infinita de logs. Para obter mais informações sobre esse problema e determinar quais grupos de logs devem ser excluídos, consulte [Prevenção de repetição de logs](Subscriptions-recursion-prevention.md). Atualmente, NOT IN é o único operador compatível com `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"
```
Os grupos de logs da conta de envio e o destino devem estar na mesma região da AWS . No entanto, o destino pode apontar para um AWS recurso, como um stream do Amazon Kinesis Data Streams, localizado em uma região diferente.
# Validação do fluxo de eventos de logs
Depois de criar a política de filtro de assinatura em nível de conta, o CloudWatch Logs encaminha todos os eventos de registro de entrada que correspondam ao padrão de filtro e aos critérios de seleção para o stream encapsulado no stream de destino chamado "”. **RecipientStream** O proprietário do destino pode verificar se isso está acontecendo usando o get-shard-iterator comando **aws kinesis** para obter um fragmento do Amazon Kinesis Data Streams e usando o comando **aws kinesis get-records para buscar alguns registros do 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"
```
**nota**
Talvez seja necessário executar novamente o `get-records` comando algumas vezes antes que o Amazon Kinesis Data Streams comece a retornar os dados.
Você deve ver uma resposta com uma matriz de registros do Amazon Kinesis Data Streams. O atributo de dados no registro do Amazon Kinesis Data Streams é compactado no formato gzip e, em seguida, codificado em base64. Você pode examinar os dados brutos na linha de comando usando o seguinte comando Unix:
```
echo -n "" | base64 -d | zcat
```
Os dados base64 decodificados e descompactados têm o formato JSON com a seguinte estrutura:
```
{
"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\"}"
}
]
}
```
Os principais elementos da estrutura de dados são os seguintes:
**messageType**
As mensagens de dados usarão o tipo "DATA\$1MESSAGE". Às vezes, CloudWatch os Logs podem emitir registros do Amazon Kinesis Data Streams com o tipo “CONTROL\$1MESSAGE”, principalmente para verificar se o destino está acessível.
**proprietário**
O ID da AWS conta dos dados de registro de origem.
**logGroup**
O nome do grupo de logs dos dados de log de origem.
**logStream**
O nome do stream de log dos dados de log de origem.
**subscriptionFilters**
A lista de nomes de filtro de assinatura que corresponderam aos dados de log de origem.
**logEvents**
Os dados de log reais, representados como um conjunto de registros de eventos de log. A propriedade "id" é um identificador exclusivo de cada evento de log.
**policyLevel**
O nível em que a política foi aplicada. "ACCOUNT\$1LEVEL\$1POLICY" é a `policyLevel` para uma política de filtro de assinatura ao nível da conta.
# Modificar a associação de destino no runtime
Pode haver situações em que você precise adicionar ou remover a associação de alguns usuários de um destino que você possua. Você pode usar o comando `put-destination-policy` em seu destino com uma nova política de acesso. No exemplo a seguir, uma conta **111111111111** recém-adicionada é impedida de enviar mais dados de log e a conta **222222222222** é ativada.
1. **Busque a política atualmente associada ao testDestination de destino e anote: **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. Atualize a política para refletir que a conta **111111111111** foi interrompida e a conta **222222222222** está habilitada. Coloque essa política no arquivo **NewAccessPolicy\$1/.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. Ligue **PutDestinationPolicy**para associar a política definida no **NewAccessPolicyarquivo.json** ao destino:
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Por fim, isso desativará os eventos de log do ID da conta **111111111111**. Os eventos de log da ID da conta **222222222222** começarão a fluir para o destino assim que o proprietário da conta **222222222222** criar um filtro de assinatura.
# Atualizar uma assinatura existente entre contas
Se você atualmente tiver uma assinatura de logs entre contas em que a conta de destino concede permissões apenas para contas de remetente específicas e quiser atualizar essa assinatura para que a conta de destino conceda acesso a todas as contas em uma organização, siga as etapas desta seção.
**Topics**
+ [
# Etapa 1: atualizar os filtros de assinatura
](Cross-Account-Log_Subscription-Update-filter-Account.md)
+ [
# Etapa 2: atualizar a política de acesso ao destino existente
](Cross-Account-Log_Subscription-Update-policy-Account.md)
# Etapa 1: atualizar os filtros de assinatura
**nota**
Essa etapa é necessária apenas para assinaturas entre contas para logs criados pelos serviços listados em [Habilitar o registro a partir de AWS serviços](AWS-logs-and-resource-policy.md). Se você não estiver trabalhando com logs criados por um desses grupos de log, pule para [Etapa 2: atualizar a política de acesso ao destino existente](Cross-Account-Log_Subscription-Update-policy-Account.md).
Em determinados casos, você deve atualizar os filtros de assinatura em todas as contas de remetente que estão enviando logs para a conta de destino. A atualização adiciona uma função do IAM, que CloudWatch pode assumir e validar que a conta do remetente tem permissão para enviar registros para a conta do destinatário.
Siga as etapas desta seção para cada conta de remetente que você deseja atualizar para usar o ID da organização para as permissões de assinatura entre contas.
Nos exemplos desta seção, duas contas, `111111111111` e `222222222222` já têm filtros de assinatura criados para enviar logs para a conta `999999999999`. Os valores de filtro de assinatura existentes são os seguintes:
```
## Existing Subscription Filter parameter values
{
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"FilterPattern": "{$.userIdentity.type = Root}",
"Distribution": "Random"
}
```
Se você precisar encontrar os valores do parâmetro do filtro de assinatura atual, insira o seguinte comando.
```
aws logs describe-account-policies \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-name "CrossAccountStreamsExamplePolicy"
```
**Para atualizar um filtro de assinatura para começar a usar a organização IDs para obter permissões de registro entre contas**
1. Crie a seguinte política de confiança em um arquivo `~/TrustPolicyForCWL.json`. Use um editor de texto para criar esse arquivo de política; não use o console do IAM.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Crie uma função do IAM que use essa política. Observe o valor `Arn` do valor `Arn` que for retornado pelo comando, pois você precisará dele posteriormente nesse procedimento. Neste exemplo, usamos `CWLtoSubscriptionFilterRole` como o nome da função que estamos criando.
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.json
```
1. Crie uma política de permissões para definir as ações que o CloudWatch Logs pode realizar na sua conta.
1. Primeiro, use um editor de texto para criar a seguinte política de permissões em um arquivo chamado `/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Insira o seguinte comando para associar a política de permissões que você acabou de criar à função criada na etapa 2.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
1. Insira o comando a seguir para atualizar a política de filtro de assinatura.
```
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"
```
# Etapa 2: atualizar a política de acesso ao destino existente
Depois de atualizar os filtros de assinatura em todas as contas de remetente, você poderá atualizar a política de acesso de destino na conta do destinatário.
Nos exemplos a seguir, a conta do destinatário é `999999999999` e o destino é chamado de `testDestination`.
A atualização habilita todas as contas que fazem parte da organização com ID de `o-1234567890` a enviar logs à conta destinatária. Somente as contas que tiverem filtros de assinatura criados enviarão logs para a conta do destinatário.
**Atualizar a política de acesso de destino na conta do destinatário para começar a usar um ID de organização para permissões**
1. Na conta destinatária, use um editor de texto para criar um arquivo `~/AccessPolicy.json` com o seguinte conteúdo.
------
#### [ 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. Insira o seguinte comando para anexar a política que você acabou de criar ao destino existente. Para atualizar um destino para usar uma política de acesso com uma ID da organização em vez de uma política de acesso que lista uma AWS conta específica IDs, inclua o `force` parâmetro.
**Atenção**
Se você estiver trabalhando com registros enviados por um AWS serviço listado em[Habilitar o registro a partir de AWS serviços](AWS-logs-and-resource-policy.md), antes de executar essa etapa, você deve primeiro atualizar os filtros de assinatura em todas as contas do remetente, conforme explicado em[Etapa 1: atualizar os filtros de assinatura](Cross-Account-Log_Subscription-Update-filter-Account.md).
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```