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 entre contas entre regiões
Você pode colaborar com um proprietário de uma AWS conta diferente e receber seus eventos de log em seus AWS recursos, como um stream do Amazon Kinesis ou do Amazon Data Firehose (isso é conhecido como compartilhamento de dados entre contas). Por exemplo, esses dados de eventos de log podem ser lidos de um stream centralizado do Amazon Kinesis Data Streams ou Firehose para realizar processamento e análise personalizados. O processamento personalizado é especialmente útil quando você colabora e analisa dados entre várias contas.
Por exemplo, um grupo de segurança de informações de uma empresa pode querer analisar dados de detecção de invasões em tempo real ou comportamentos anormais para que possa realizar uma auditoria de contas em todas as divisões da empresa, coletando seus logs de produção federados para processamento central. Um stream em tempo real de dados de eventos entre essas contas pode ser montado e entregue aos grupos de segurança da informação, que podem usar o Amazon Kinesis Data Streams para anexar os dados aos seus sistemas analíticos de segurança existentes.
**nota**
O grupo de registros e o destino devem estar na mesma AWS região. No entanto, o recurso da AWS 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 de região são criados no Leste dos EUA (N. da Virgínia).
Se você configurou AWS Organizations e está trabalhando com contas de membros, pode usar a centralização de registros para coletar dados de log das contas de origem em uma conta de monitoramento central.
Ao trabalhar com grupos de logs centralizados, você pode usar essas dimensões de campos do sistema ao criar filtros de assinatura:
+ `@aws.account`- Essa dimensão representa o ID da AWS conta da qual o evento de registro se originou.
+ `@aws.region`- Essa dimensão representa a AWS região em que o evento de log foi gerado.
Essas dimensões ajudam a identificar a origem dos dados de log, permitindo uma filtragem e análise mais granulares das métricas derivadas de logs centralizados.
**Topics**
+ [Compartilhamento de dados de log entre contas usando o Amazon Kinesis Data Streams](CrossAccountSubscriptions-Kinesis.md)
+ [Compartilhamento de dados de log entre contas e entre regiões usando o Firehose](CrossAccountSubscriptions-Firehose.md)
+ [Assinaturas multiregionais em nível de conta usando o Amazon Kinesis Data Streams](CrossAccountSubscriptions-Kinesis-Account.md)
+ [Assinaturas entre contas e entre regiões ao nível da conta usando o Firehose](CrossAccountSubscriptions-Firehose-Account.md)
# Compartilhamento de dados de log entre contas 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.md)
+ [Atualizar uma assinatura existente entre contas](Cross-Account-Log_Subscription-Update.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.md)
+ [Etapa 2: (somente se estiver usando uma organização) Crie uma função do IAM.](CreateSubscriptionFilter-IAMrole.md)
+ [Etapa 3: permissões Add/validate do IAM para o destino entre contas](Subscription-Filter-CrossAccount-Permissions.md)
+ [Etapa 4: criar um filtro de assinatura](CreateSubscriptionFilter.md)
+ [Validação do fluxo de eventos de logs](ValidateLogEventFlow.md)
+ [Modificar a associação de destino no runtime](ModifyDestinationMembership.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": "2015-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",
"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",
"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.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 4: criar um filtro de assinatura](CreateSubscriptionFilter.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 4: criar um filtro de assinatura](CreateSubscriptionFilter.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 4: criar um filtro de assinatura](CreateSubscriptionFilter.md).
# Etapa 3: permissões Add/validate do IAM para o destino entre contas
De acordo com a lógica de avaliação de políticas AWS entre contas, para acessar qualquer recurso entre contas (como um stream do Kinesis ou Firehose usado como destino para um filtro de assinatura), você deve ter uma política baseada em identidade na conta de envio que forneça acesso explícito ao recurso de destino entre contas. Para obter mais informações sobre a lógica de avaliação de política, consulte [Lógica de avaliação de política entre contas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).
Você pode associar a política baseada em identidade ao perfil do IAM ou ao usuário do IAM que você está usando para criar o filtro de assinatura. Essa política deve estar presente na conta de envio. Se você estiver usando a função de administrador para criar o filtro de assinatura, poderá ignorar esta etapa e prosseguir para [Etapa 4: criar um filtro de assinatura](CreateSubscriptionFilter.md).
**Para adicionar ou validar as permissões do IAM necessárias entre contas**
1. Insira o comando a seguir para verificar qual função do IAM ou usuário do IAM está sendo usado para executar comandos de AWS registros.
```
aws sts get-caller-identity
```
Esse comando retorna uma saída semelhante à seguinte:
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
Anote o valor representado por *RoleName* ou*UserName*.
1. Faça login Console de gerenciamento da AWS na conta de envio e pesquise as políticas anexadas com a função do IAM ou o usuário do IAM retornado na saída do comando inserido na etapa 1.
1. Verifique se as políticas vinculadas a esse perfil ou usuário fornecem permissões explícitas para chamar `logs:PutSubscriptionFilter` no recurso de destino entre contas.
A política a seguir fornece permissões para criar um filtro de assinatura em qualquer recurso de destino somente em uma única AWS conta, conta`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:*"
]
}
]
}
```
------
A política a seguir fornece permissões para criar um filtro de assinatura somente em um recurso de destino específico chamado `sampleDestination` em uma única AWS conta, conta`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"
]
}
]
}
```
------
# Etapa 4: criar um filtro de assinatura
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.md).
No exemplo a seguir, um filtro de assinatura é criado em uma conta de envio. O filtro é associado a um grupo de registros contendo AWS CloudTrail eventos para que todas as atividades registradas feitas pelas AWS credenciais “Root” sejam entregues ao destino que você criou anteriormente. Esse destino encapsula um fluxo chamado "”RecipientStream.
O restante das etapas nas seções a seguir pressupõe que você seguiu as instruções em [Enviar CloudTrail eventos para CloudWatch registros](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) no *Guia do AWS CloudTrail usuário* e criou um grupo de registros que contém seus CloudTrail eventos. Essas etapas pressupõem que o nome desse grupo de logs é `CloudTrail/logs`.
Ao inserir o comando a seguir, certifique-se de estar conectado como usuário do IAM ou usando o perfil do IAM para o qual você adicionou a política, em [Etapa 3: permissões Add/validate do IAM para o destino entre contas](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"
```
O grupo de registros e o destino devem estar na mesma AWS região. 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 o filtro de assinatura, o CloudWatch Logs encaminha todos os eventos de registro de entrada que correspondem ao padrão do filtro 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 comando get-records algumas vezes antes que o Amazon Kinesis Data Streams comece a retornar 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 nesta estrutura de dados são os seguintes:
**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.
**messageType**
As mensagens de dados usam 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.
**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.
# 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",
"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.md)
+ [Etapa 2: atualizar a política de acesso ao destino existente](Cross-Account-Log_Subscription-Update-policy.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.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
\ --log-group-name "my-log-group-name"
\ --filter-name "RecipientStream"
\ --filter-pattern "{$.userIdentity.type = Root}"
\ --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
```
Se você precisar encontrar os valores do parâmetro do filtro de assinatura atual, insira o seguinte comando.
```
aws logs describe-subscription-filters
\ --log-group-name "my-log-group-name"
```
**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 o filtro de assinatura.
```
aws logs put-subscription-filter
\ --log-group-name "my-log-group-name"
\ --filter-name "RecipientStream"
\ --filter-pattern "{$.userIdentity.type = Root}"
\ --destination-arn "arn:aws:logs:region:999999999999:destination:testDestination"
\ --role-arn "arn:aws:iam::111111111111:role/CWLtoSubscriptionFilterRole"
```
# 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",
"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.md).
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Compartilhamento de dados de log entre contas e entre regiões usando o Firehose
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.
+ **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 222222222222.
O exemplo desta seção usa um fluxo de entrega do Firehose com armazenamento do Amazon S3. Também é possível configurar fluxos de entrega do Firehose com configurações diferentes. Para obter mais informações, consulte [Criar um fluxo de entrega do Firehose](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).
**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.
**nota**
O filtro de assinatura do Firehose para um fluxo de entrega na ***mesma conta*** e ***entre regiões*** é compatível.
**Topics**
+ [Etapa 1: criar um fluxo de entrega do Firehose](CreateFirehoseStream.md)
+ [Etapa 2: Criar um destino](CreateFirehoseStreamDestination.md)
+ [Etapa 3: permissões Add/validate do IAM para o destino entre contas](Subscription-Filter-CrossAccount-Permissions-Firehose.md)
+ [Etapa 4: criar um filtro de assinatura](CreateSubscriptionFilterFirehose.md)
+ [Validação do fluxo de eventos de log](ValidateLogEventFlowFirehose.md)
+ [Modificação da associação de destino no runtime](ModifyDestinationMembershipFirehose.md)
# Etapa 1: criar um fluxo de entrega do Firehose
**Importante**
Antes de concluir as etapas a seguir, você deve usar uma política de acesso para que o Firehose possa acessar o bucket do Amazon S3. Para obter mais informações, consulte [Controlling Access](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3) no *Amazon Data Firehose Developer Guide*.
Todas as etapas desta seção (Etapa 1) devem ser realizadas na conta destinatária dos dados do log.
Leste dos EUA (N. da Virgínia) é a região usada nos exemplos de comando a seguir. Substitua essa região pela região correta da implantação.
**Para criar um fluxo de entrega do Firehose para ser usado como destino**
1. Criar um bucket do Amazon S3:
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. Crie o perfil do IAM que concede ao Firehose permissão para colocar dados no bucket.
1. Primeiro, use um editor de texto para criar uma política de confiança em um arquivo `~/TrustPolicyForFirehose.json`.
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. Crie a função do IAM, especificando o arquivo de política de confiança que você acabou de criar.
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. A saída deste comando será parecida com o exemplo a seguir. Anote os valores do nome da função e do ARN da função.
```
{
"Role": {
"Path": "/",
"RoleName": "FirehosetoS3Role",
"RoleId": "AROAR3BXASEKW7K635M53",
"Arn": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"CreateDate": "2021-02-02T07:53:10+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "222222222222"
}
}
}
}
}
}
```
1. Crie uma política de permissões para definir as ações que o Firehose 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 `~/PermissionsForFirehose.json`. Dependendo do caso de uso, pode ser necessário adicionar mais permissões a esse arquivo.
```
{
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}]
}
```
1. Insira o seguinte comando para associar a política de permissões que você acabou de criar ao perfil do IAM.
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. Insira o comando a seguir para criar o fluxo de entrega do Firehose. Substitua *my-role-arn* e *amzn-s3-demo-bucket2-arn* com os valores corretos para sua implantação.
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket"}'
```
A saída deve ser semelhante à seguinte:
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# Etapa 2: Criar um destino
**Importante**
As etapas deste procedimento devem ser processadas na conta destinatária dos dados do log.
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. Aguarde até o fluxo do Firehose que você criou em [Etapa 1: criar um fluxo de entrega do Firehose](CreateFirehoseStream.md) ficar ativo. Você pode usar o comando a seguir para verificar **StreamDescriptiono. StreamStatus**propriedade.
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
Além disso, anote **DeliveryStreamDescriptiono. DeliveryStreamValor do ARN**, porque você precisará usá-lo em uma etapa posterior. Exemplo de saída desse comando:
```
{
"DeliveryStreamDescription": {
"DeliveryStreamName": "my-delivery-stream",
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamEncryptionConfiguration": {
"Status": "DISABLED"
},
"DeliveryStreamType": "DirectPut",
"VersionId": "1",
"CreateTimestamp": "2021-02-01T23:59:15.567000-08:00",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
}
},
"ExtendedS3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
},
"S3BackupMode": "Disabled"
}
}
],
"HasMoreDestinations": false
}
}
```
Pode levar um ou dois minutos para seu fluxo de entrega ser exibido com estado ativo.
1. Quando o stream de entrega estiver ativo, crie a função do IAM que concederá a CloudWatch Logs a permissão para colocar dados em seu stream do Firehose. Primeiro, você precisará criar uma política de confiança em um arquivo **TrustPolicyFor\$1/CWL.json**. Use um editor de texto para criar esta política. Para obter mais informações sobre endpoints do CloudWatch Logs, consulte [Endpoints e cotas do Amazon CloudWatch Logs](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html).
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.region.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
```
1. Use o comando **aws iam create-role** para criar a função do IAM, especificando o arquivo de política de confiança que você acabou de criar.
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
Este é um exemplo de saída. Anote o valor `Role.Arn` retornado, pois será necessário utilizá-lo em uma etapa posterior.
```
{
"Role": {
"Path": "/",
"RoleName": "CWLtoKinesisFirehoseRole",
"RoleId": "AROAR3BXASEKYJYWF243H",
"Arn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"CreateDate": "2021-02-02T08:10:43+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.region.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
}
}
```
1. 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":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. Associe a política de permissões com a função inserindo o seguinte comando:
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Depois que o stream de entrega do Firehose 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 só é a primeira etapa das duas concluirá uma criação de destino. Anote o ARN do novo destino que for retornado na carga útil, pois você usará isso como `destination.arn` em uma etapa posterior.
```
aws logs put-destination \
--destination-name "testFirehoseDestination" \
--target-arn "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream" \
--role-arn "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole"
{
"destination": {
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"arn": "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"}
}
```
1. Depois que a etapa anterior for concluída, na conta destinatária dos dados de log (222222222222), associe uma política de acesso ao destino.
Essa política permite que a conta remetente dos dados de log (111111111111 conta) acesse o destino apenas na conta destinatária dos dados de log (222222222222). Você pode usar um editor de texto para colocar essa política no arquivo **AccessPolicy\$1/.json:**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "111111111111"
},
"Action" : "logs:PutSubscriptionFilter",
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. Isso cria uma política que define quem tem acesso de gravação ao destino. Essa política deve especificar os **registros: PutSubscriptionFilter** ação para acessar o destino. Os usuários entre contas usará a ação **PutSubscriptionFilter** para enviar eventos de log ao destino:
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# Etapa 3: permissões Add/validate do IAM para o destino entre contas
De acordo com a lógica de avaliação de políticas AWS entre contas, para acessar qualquer recurso entre contas (como um stream do Kinesis ou Firehose usado como destino para um filtro de assinatura), você deve ter uma política baseada em identidade na conta de envio que forneça acesso explícito ao recurso de destino entre contas. Para obter mais informações sobre a lógica de avaliação de política, consulte [Lógica de avaliação de política entre contas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).
Você pode associar a política baseada em identidade ao perfil do IAM ou ao usuário do IAM que você está usando para criar o filtro de assinatura. Essa política deve estar presente na conta de envio. Se você estiver usando a função de administrador para criar o filtro de assinatura, poderá ignorar esta etapa e prosseguir para [Etapa 4: criar um filtro de assinatura](CreateSubscriptionFilter.md).
**Para adicionar ou validar as permissões do IAM necessárias entre contas**
1. Insira o comando a seguir para verificar qual função do IAM ou usuário do IAM está sendo usado para executar comandos de AWS registros.
```
aws sts get-caller-identity
```
Esse comando retorna uma saída semelhante à seguinte:
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
Anote o valor representado por *RoleName* ou*UserName*.
1. Faça login Console de gerenciamento da AWS na conta de envio e pesquise as políticas anexadas com a função do IAM ou o usuário do IAM retornado na saída do comando inserido na etapa 1.
1. Verifique se as políticas vinculadas a esse perfil ou usuário fornecem permissões explícitas para chamar `logs:PutSubscriptionFilter` no recurso de destino entre contas.
A política a seguir fornece permissões para criar um filtro de assinatura em qualquer recurso de destino somente em uma única AWS conta, conta`999999999999`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnAnyResourceInOneSpecificAccount",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:*"
]
}
]
}
```
------
A política a seguir fornece permissões para criar um filtro de assinatura somente em um recurso de destino específico chamado `sampleDestination` em uma única AWS conta, conta`123456789012`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnSpecificResource",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:amzn-s3-demo-bucket"
]
}
]
}
```
------
# Etapa 4: criar um filtro de assinatura
Alterne para a conta de envio, que é 111111111111 neste exemplo. Agora, você criará o filtro de assinatura na conta de envio. Neste exemplo, o filtro está associado a um grupo de registros contendo AWS CloudTrail eventos para que todas as atividades registradas feitas pelas AWS credenciais “Raiz” sejam entregues ao destino que você criou anteriormente. Para obter mais informações sobre como enviar AWS CloudTrail eventos para CloudWatch registros, consulte [Enviar CloudTrail eventos para CloudWatch registros](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) no *Guia do AWS CloudTrail usuário*.
Ao inserir o comando a seguir, certifique-se de estar conectado como usuário do IAM ou usando o perfil do IAM para o qual você adicionou a política, em [Etapa 3: permissões Add/validate do IAM para o destino entre contas](Subscription-Filter-CrossAccount-Permissions-Firehose.md).
```
aws logs put-subscription-filter \
--log-group-name "aws-cloudtrail-logs-111111111111-300a971e" \
--filter-name "firehose_test" \
--filter-pattern "{$.userIdentity.type = AssumedRole}" \
--destination-arn "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
```
O grupo de registros e o destino devem estar na mesma AWS região. No entanto, o destino pode apontar para um AWS recurso, como um stream do Firehose, localizado em uma região diferente.
# Validação do fluxo de eventos de log
Depois de criar o filtro de assinatura, o CloudWatch Logs encaminha todos os eventos de registro de entrada que correspondem ao padrão do filtro para o stream de entrega do Firehose. Os dados começam a aparecer no bucket do Amazon S3 com base no intervalo de buffer de tempo definido no fluxo de entrega do Firehose. Quando tiver passado tempo suficiente, você poderá conferir seus dados verificando o bucket do Amazon S3. Para verificar o bucket, insira este comando:
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
A saída desse comando será semelhante a:
```
{
"Contents": [
{
"Key": "2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba",
"LastModified": "2021-02-02T09:00:26+00:00",
"ETag": "\"EXAMPLEa817fb88fc770b81c8f990d\"",
"Size": 198,
"StorageClass": "STANDARD",
"Owner": {
"DisplayName": "firehose+2test",
"ID": "EXAMPLE27fd05889c665d2636218451970ef79400e3d2aecca3adb1930042e0"
}
}
]
}
```
Em seguida, você pode recuperar um objeto específico do bucket digitando o comando a seguir. Substitua o valor de `key` pelo valor encontrado no comando anterior.
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket' --key '2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba' testfile.gz
```
Os dados no objeto do Amazon S3 são compactados com o formato gzip. É possível examinar os dados brutos na linha de comando usando os seguintes comandos:
Linux
```
zcat testfile.gz
```
macOS:
```
zcat
Pode haver situações em que você precise adicionar ou remover remetentes de log de um destino que você possua. Você pode usar a **PutDestinationPolicy**ação em seu destino com a 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 **333333333333** é habilitada.
1. **Busque a política atualmente associada ao testDestination de destino e anote: **AccessPolicy****
```
aws logs describe-destinations \
--destination-name-prefix "testFirehoseDestination"
{
"destinations": [
{
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam:: 222222222222:role/CWLtoKinesisFirehoseRole",
"accessPolicy": "{\n \"Version\" : \"2012-10-17\",\n \"Statement\" : [\n {\n \"Sid\" : \"\",\n \"Effect\" : \"Allow\",\n \"Principal\" : {\n \"AWS\" : \"111111111111 \"\n },\n \"Action\" : \"logs:PutSubscriptionFilter\",\n \"Resource\" : \"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination\"\n }\n ]\n}\n\n",
"arn": "arn:aws:logs:us-east-1: 222222222222:destination:testFirehoseDestination",
"creationTime": 1612256124430
}
]
}
```
1. Atualize a política para refletir que a conta **111111111111** foi interrompida e a conta **333333333333** está habilitada. Coloque essa política no arquivo **NewAccessPolicy\$1/.json:**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "333333333333 "
},
"Action" : "logs:PutSubscriptionFilter",
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. Use o comando a seguir para associar a política definida no **NewAccessPolicyarquivo.json** ao destino:
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Por fim, isso desativa os eventos de log do ID da conta **111111111111**. Os eventos de log da ID da conta **333333333333** começarão a fluir para o destino assim que o proprietário da conta **333333333333** criar um filtro de assinatura.
# 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
```
# Assinaturas entre contas e entre regiões ao nível da conta usando o Firehose
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.
+ **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 222222222222.
O exemplo desta seção usa um fluxo de entrega do Firehose com armazenamento do Amazon S3. Também é possível configurar fluxos de entrega do Firehose com configurações diferentes. Para obter mais informações, consulte [Criar um fluxo de entrega do Firehose](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).
**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.
**nota**
O filtro de assinatura do Firehose para um fluxo de entrega na ***mesma conta*** e ***entre regiões*** é compatível.
**Topics**
+ [Etapa 1: criar um fluxo de entrega do Firehose](CreateFirehoseStream-Account.md)
+ [Etapa 2: Criar um destino](CreateFirehoseStreamDestination-Account.md)
+ [Etapa 3: criar uma política de filtro de assinatura ao nível da conta](CreateSubscriptionFilterFirehose-Account.md)
+ [Validação do fluxo de eventos de log](ValidateLogEventFlowFirehose-Account.md)
+ [Modificação da associação de destino no runtime](ModifyDestinationMembershipFirehose-Account.md)
# Etapa 1: criar um fluxo de entrega do Firehose
**Importante**
Antes de concluir as etapas a seguir, você deve usar uma política de acesso para que o Firehose possa acessar o bucket do Amazon S3. Para obter mais informações, consulte [Controlling Access](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3) no *Amazon Data Firehose Developer Guide*.
Todas as etapas desta seção (Etapa 1) devem ser realizadas na conta destinatária dos dados do log.
Leste dos EUA (N. da Virgínia) é a região usada nos exemplos de comando a seguir. Substitua essa região pela região correta da implantação.
**Para criar um fluxo de entrega do Firehose para ser usado como destino**
1. Criar um bucket do Amazon S3:
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. Crie o perfil do IAM que concede ao Firehose permissão para colocar dados no bucket.
1. Primeiro, use um editor de texto para criar uma política de confiança em um arquivo `~/TrustPolicyForFirehose.json`.
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. Crie a função do IAM, especificando o arquivo de política de confiança que você acabou de criar.
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. A saída deste comando será parecida com o exemplo a seguir. Anote os valores do nome da função e do ARN da função.
```
{
"Role": {
"Path": "/",
"RoleName": "FirehosetoS3Role",
"RoleId": "AROAR3BXASEKW7K635M53",
"Arn": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"CreateDate": "2021-02-02T07:53:10+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "firehose.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "222222222222"
}
}
}
}
}
}
```
1. Crie uma política de permissões para definir as ações que o Firehose 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 `~/PermissionsForFirehose.json`. Dependendo do caso de uso, pode ser necessário adicionar mais permissões a esse arquivo.
```
{
"Statement": [{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::amzn-s3-demo-bucket",
"arn:aws:s3:::amzn-s3-demo-bucket/*"
]
}]
}
```
1. Insira o seguinte comando para associar a política de permissões que você acabou de criar ao perfil do IAM.
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. Insira o comando a seguir para criar o fluxo de entrega do Firehose. Substitua *my-role-arn* e *amzn-s3-demo-bucket2-arn* com os valores corretos para sua implantação.
```
aws firehose create-delivery-stream \
--delivery-stream-name 'my-delivery-stream' \
--s3-destination-configuration \
'{"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role", "BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket"}'
```
A saída deve ser semelhante à seguinte:
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# Etapa 2: Criar um destino
**Importante**
As etapas deste procedimento devem ser processadas na conta destinatária dos dados do log.
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. Aguarde até o fluxo do Firehose que você criou em [Etapa 1: criar um fluxo de entrega do Firehose](CreateFirehoseStream-Account.md) ficar ativo. Você pode usar o comando a seguir para verificar **StreamDescriptiono. StreamStatus**propriedade.
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
Além disso, anote **DeliveryStreamDescriptiono. DeliveryStreamValor do ARN**, porque você precisará usá-lo em uma etapa posterior. Exemplo de saída desse comando:
```
{
"DeliveryStreamDescription": {
"DeliveryStreamName": "my-delivery-stream",
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"DeliveryStreamStatus": "ACTIVE",
"DeliveryStreamEncryptionConfiguration": {
"Status": "DISABLED"
},
"DeliveryStreamType": "DirectPut",
"VersionId": "1",
"CreateTimestamp": "2021-02-01T23:59:15.567000-08:00",
"Destinations": [
{
"DestinationId": "destinationId-000000000001",
"S3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
}
},
"ExtendedS3DestinationDescription": {
"RoleARN": "arn:aws:iam::222222222222:role/FirehosetoS3Role",
"BucketARN": "arn:aws:s3:::amzn-s3-demo-bucket",
"BufferingHints": {
"SizeInMBs": 5,
"IntervalInSeconds": 300
},
"CompressionFormat": "UNCOMPRESSED",
"EncryptionConfiguration": {
"NoEncryptionConfig": "NoEncryption"
},
"CloudWatchLoggingOptions": {
"Enabled": false
},
"S3BackupMode": "Disabled"
}
}
],
"HasMoreDestinations": false
}
}
```
Pode levar um ou dois minutos para seu fluxo de entrega ser exibido com estado ativo.
1. Quando o stream de entrega estiver ativo, crie a função do IAM que concederá a CloudWatch Logs a permissão para colocar dados em seu stream do Firehose. Primeiro, você precisará criar uma política de confiança em um arquivo **TrustPolicyFor\$1/CWL.json**. Use um editor de texto para criar esta política. Para obter mais informações sobre endpoints do CloudWatch Logs, consulte [Endpoints e cotas do Amazon CloudWatch Logs](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html).
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"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
```
1. Use o comando **aws iam create-role** para criar a função do IAM, especificando o arquivo de política de confiança que você acabou de criar.
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
Este é um exemplo de saída. Anote o valor `Role.Arn` retornado, pois será necessário utilizá-lo em uma etapa posterior.
```
{
"Role": {
"Path": "/",
"RoleName": "CWLtoKinesisFirehoseRole",
"RoleId": "AROAR3BXASEKYJYWF243H",
"Arn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"CreateDate": "2023-02-02T08:10:43+00:00",
"AssumeRolePolicyDocument": {
"Statement": {
"Effect": "Allow",
"Principal": {
"Service": "logs.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:SourceArn": [
"arn:aws:logs:region:sourceAccountId:*",
"arn:aws:logs:region:recipientAccountId:*"
]
}
}
}
}
}
}
```
1. 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":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. Associe a política de permissões com a função inserindo o seguinte comando:
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Depois que o stream de entrega do Firehose 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 só é a primeira etapa das duas concluirá uma criação de destino. Anote o ARN do novo destino que for retornado na carga útil, pois você usará isso como `destination.arn` em uma etapa posterior.
```
aws logs put-destination \
--destination-name "testFirehoseDestination" \
--target-arn "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream" \
--role-arn "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole"
{
"destination": {
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam::222222222222:role/CWLtoKinesisFirehoseRole",
"arn": "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"}
}
```
1. Depois que a etapa anterior for concluída, na conta destinatária dos dados de log (222222222222), associe uma política de acesso ao destino. Essa política permite que a conta remetente dos dados de log (111111111111 conta) acesse o destino apenas na conta destinatária dos dados de log (222222222222). Você pode usar um editor de texto para colocar essa política no arquivo `~/AccessPolicy.json`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "111111111111"
},
"Action" : ["logs:PutSubscriptionFilter","logs:PutAccountPolicy"],
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. Isso cria uma política que define quem tem acesso de gravação ao destino. Essa política deve especificar as ações `logs:PutSubscriptionFilter` e `logs:PutAccountPolicy` para acessar o destino. Os usuários em contas diferentes usarão as ações `PutSubscriptionFilter` e `PutAccountPolicy` para enviar eventos de log ao destino.
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# Etapa 3: criar uma política de filtro de assinatura ao nível da conta
Alterne para a conta de envio, que é 111111111111 neste exemplo. Agora, você criará a política de filtro de assinatura ao nível da conta na conta de envio. Nesse exemplo, o filtro faz com que todos os eventos de log que contêm a string `ERROR` em todos os grupos de logs, exceto dois, sejam entregues ao destino que você criou anteriormente.
```
aws logs put-account-policy \
--policy-name "CrossAccountFirehoseExamplePolicy" \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-document '{"DestinationArn":"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination", "FilterPattern": "{$.userIdentity.type = AssumedRole}", "Distribution": "Random"}' \
--selection-criteria 'LogGroupName NOT IN ["LogGroupToExclude1", "LogGroupToExclude2"]' \
--scope "ALL"
```
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 Firehose, localizado em uma região diferente.
# Validação do fluxo de eventos de log
Depois de criar o filtro de assinatura, o CloudWatch Logs encaminha todos os eventos de registro de entrada que correspondam ao padrão do filtro e aos critérios de seleção para o stream de entrega do Firehose. Os dados começam a aparecer no bucket do Amazon S3 com base no intervalo de buffer de tempo definido no fluxo de entrega do Firehose. Quando tiver passado tempo suficiente, você poderá conferir seus dados verificando o bucket do Amazon S3. Para verificar o bucket, insira este comando:
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
A saída desse comando será semelhante a:
```
{
"Contents": [
{
"Key": "2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba",
"LastModified": "2023-02-02T09:00:26+00:00",
"ETag": "\"EXAMPLEa817fb88fc770b81c8f990d\"",
"Size": 198,
"StorageClass": "STANDARD",
"Owner": {
"DisplayName": "firehose+2test",
"ID": "EXAMPLE27fd05889c665d2636218451970ef79400e3d2aecca3adb1930042e0"
}
}
]
}
```
Em seguida, você pode recuperar um objeto específico do bucket digitando o comando a seguir. Substitua o valor de `key` pelo valor encontrado no comando anterior.
```
aws s3api get-object --bucket 'amzn-s3-demo-bucket' --key '2021/02/02/08/my-delivery-stream-1-2021-02-02-08-55-24-5e6dc317-071b-45ba-a9d3-4805ba39c2ba' testfile.gz
```
Os dados no objeto do Amazon S3 são compactados com o formato gzip. É possível examinar os dados brutos na linha de comando usando os seguintes comandos:
Linux
```
zcat testfile.gz
```
macOS:
```
zcat
Pode haver situações em que você precise adicionar ou remover remetentes de log de um destino que você possua. Você pode usar as `PutAccountPolicy` ações **PutDestinationPolicy**e em seu destino com a 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 **333333333333** é habilitada.
1. **Busque a política atualmente associada ao testDestination de destino e anote: **AccessPolicy****
```
aws logs describe-destinations \
--destination-name-prefix "testFirehoseDestination"
```
Os dados retornados podem ser assim.
```
{
"destinations": [
{
"destinationName": "testFirehoseDestination",
"targetArn": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream",
"roleArn": "arn:aws:iam:: 222222222222:role/CWLtoKinesisFirehoseRole",
"accessPolicy": "{\n \"Version\" : \"2012-10-17\",\n \"Statement\" : [\n {\n \"Sid\" : \"\",\n \"Effect\" : \"Allow\",\n \"Principal\" : {\n \"AWS\" : \"111111111111 \"\n },\n \"Action\" : \"logs:PutSubscriptionFilter\",\n \"Resource\" : \"arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination\"\n }\n ]\n}\n\n",
"arn": "arn:aws:logs:us-east-1: 222222222222:destination:testFirehoseDestination",
"creationTime": 1612256124430
}
]
}
```
1. Atualize a política para refletir que a conta **111111111111** foi interrompida e a conta **333333333333** está habilitada. Coloque essa política no arquivo **NewAccessPolicy\$1/.json:**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement" : [
{
"Sid" : "",
"Effect" : "Allow",
"Principal" : {
"AWS" : "333333333333 "
},
"Action" : ["logs:PutSubscriptionFilter","logs:PutAccountPolicy"],
"Resource" : "arn:aws:logs:us-east-1:222222222222:destination:testFirehoseDestination"
}
]
}
```
------
1. Use o comando a seguir para associar a política definida no **NewAccessPolicyarquivo.json** ao destino:
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Por fim, isso desativa os eventos de log do ID da conta **111111111111**. Os eventos de log da ID da conta **333333333333** começarão a fluir para o destino assim que o proprietário da conta **333333333333** criar um filtro de assinatura.