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