Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Abbonamenti tra più account e più regioni
Puoi collaborare con il proprietario di un altro AWS account e ricevere i relativi eventi di registro sulle tue AWS risorse, ad esempio uno stream Amazon Kinesis o Amazon Data Firehose (questa operazione è nota come condivisione di dati tra account). Ad esempio, i dati di questi eventi di registro possono essere letti da un flusso centralizzato di Amazon Kinesis Data Streams o Firehose per eseguire elaborazioni e analisi personalizzate. L'elaborazione personalizzata è particolarmente utile quando collabori e analizzi dati tra più account.
Ad esempio, il gruppo di sicurezza di informazioni di un'azienda, potrebbe voler analizzare i dati per il rilevamento delle intrusioni in tempo reale o i comportamenti anomali, per poter condurre un'ispezione degli account in tutte le divisioni dell'azienda raccogliendo i log di produzione federata per l'elaborazione centralizzata. Un flusso in tempo reale di dati sugli eventi su tali account può essere assemblato e distribuito ai gruppi di sicurezza delle informazioni, che possono utilizzare Amazon Kinesis Data Streams per collegare i dati ai sistemi di analisi della sicurezza esistenti.
**Nota**
Il gruppo di log e la destinazione devono trovarsi nella stessa regione. AWS Tuttavia, la risorsa AWS a cui punta la destinazione può trovarsi in una Regione diversa. Negli esempi delle sezioni seguenti, tutte le risorse specifiche della regione vengono create negli Stati Uniti orientali (Virginia settentrionale).
Se hai configurato AWS Organizations e stai lavorando con gli account dei membri, puoi utilizzare la centralizzazione dei log per raccogliere i dati di registro dagli account di origine in un account di monitoraggio centralizzato.
Quando si lavora con gruppi di log centralizzati, è possibile utilizzare le seguenti dimensioni dei campi di sistema per creare filtri di abbonamento:
+ `@aws.account`- Questa dimensione rappresenta l'ID dell' AWS account da cui ha avuto origine l'evento di registro.
+ `@aws.region`- Questa dimensione rappresenta la AWS regione in cui è stato generato l'evento di registro.
Queste dimensioni aiutano a identificare l'origine dei dati di registro, consentendo un filtraggio e un'analisi più granulari delle metriche derivate dai log centralizzati.
**Topics**
+ [Condivisione dei dati di log tra più account tra diverse regioni con Amazon Kinesis Data Streams](CrossAccountSubscriptions-Kinesis.md)
+ [Condivisione dei dati di registro tra più account tra regioni tramite Firehose](CrossAccountSubscriptions-Firehose.md)
+ [Abbonamenti a livello di account tra più account con Amazon Kinesis Data Streams](CrossAccountSubscriptions-Kinesis-Account.md)
+ [Abbonamenti a livello di account per più account con più account che utilizzano Firehose](CrossAccountSubscriptions-Firehose-Account.md)
# Condivisione dei dati di log tra più account tra diverse regioni con Amazon Kinesis Data Streams
Durante la creazione di una sottoscrizione tra più account, è possibile specificare un singolo account o un'organizzazione come mittente. Nel caso in cui si specifichi un'organizzazione, la procedura illustrata di seguito consente a tutti gli account dell'organizzazione di inviare log all'account del destinatario.
Per condividere dati di log tra diversi account, è necessario stabilire un mittente e un ricevitore di dati di log:
+ **Registra il mittente dei dati**: ottiene le informazioni sulla destinazione dal destinatario e comunica a CloudWatch Logs che è pronto a inviare gli eventi di registro alla destinazione specificata. Nelle procedure illustrate nel resto di questa sezione, il mittente dei dati di registro viene visualizzato con un numero di account fittizio pari a 1111 AWS .
Nel caso in cui più account all'interno di un'organizzazione inviano log a un account del destinatario, è possibile creare una policy che conceda a tutti gli account dell'organizzazione l'autorizzazione per eseguire tale operazione. Devi comunque impostare filtri di sottoscrizione separati per ciascun account del mittente.
+ **Destinatario dei dati di log**: configura una destinazione che incapsula un flusso Amazon Kinesis Data Streams CloudWatch e comunica a Logs che il destinatario desidera ricevere dati di log. Il destinatario quindi condivide le informazioni su questa destinazione con il mittente. Nelle procedure illustrate nel resto di questa sezione, il destinatario dei dati di registro viene mostrato con un numero di account fittizio di 9999. AWS
Per iniziare a ricevere gli eventi di registro da utenti con più account, il destinatario dei dati di registro crea innanzitutto una destinazione Logs. CloudWatch Ogni destinazione è formata dai seguenti elementi chiave:
**Nome della destinazione**
Il nome della destinazione che intendi creare.
**ARN di destinazione**
L'Amazon Resource Name (ARN) della AWS risorsa che desideri utilizzare come destinazione del feed di abbonamento.
**ARN del ruolo**
Un ruolo AWS Identity and Access Management (IAM) che concede a CloudWatch Logs le autorizzazioni necessarie per inserire i dati nel flusso scelto.
**Policy di accesso**
Un documento della policy IAM (in formato JSON, scritto utilizzando la grammatica delle policy IAM) che controlla l'insieme degli utenti ai quali è concesso scrivere nella tua destinazione.
**Nota**
Il gruppo di log e la destinazione devono trovarsi nella stessa regione. AWS Tuttavia, la AWS risorsa a cui punta la destinazione può trovarsi in una regione diversa. Negli esempi delle sezioni seguenti, tutte le risorse specifiche della Regione vengono create in Stati Uniti orientali (Virginia settentrionale).
**Topics**
+ [Configurazione di una nuova sottoscrizione tra più account](Cross-Account-Log_Subscription-New.md)
+ [Aggiornamento di una sottoscrizione tra più account esistente](Cross-Account-Log_Subscription-Update.md)
# Configurazione di una nuova sottoscrizione tra più account
Segui la procedura riportata in queste sezioni per configurare una nuova sottoscrizione del log tra più account.
**Topics**
+ [Passaggio 1: creazione di una destinazione](CreateDestination.md)
+ [Fase 2: creazione di un ruolo IAM (solo se si utilizza un'organizzazione)](CreateSubscriptionFilter-IAMrole.md)
+ [Fase 3: autorizzazioni Add/validate IAM per la destinazione tra più account](Subscription-Filter-CrossAccount-Permissions.md)
+ [Passaggio 4: creazione di un filtro di sottoscrizione](CreateSubscriptionFilter.md)
+ [Convalida del flusso dei log eventi](ValidateLogEventFlow.md)
+ [Modifica dell'appartenenza alla destinazione in fase di runtime](ModifyDestinationMembership.md)
# Passaggio 1: creazione di una destinazione
**Importante**
Tutte le fasi di questa procedura devono essere eseguite nell'account del destinatario dei dati di log.
Per questo esempio, l'account del destinatario dei dati di registro ha un ID AWS account di 9999, mentre l'ID dell'account mittente AWS dei dati di registro è 1111.
Questo esempio crea una destinazione utilizzando un flusso Amazon Kinesis Data RecipientStream Streams chiamato e un ruolo CloudWatch che consente a Logs di scrivere dati su di esso.
Quando viene creata la destinazione, CloudWatch Logs invia un messaggio di prova alla destinazione per conto dell'account del destinatario. Quando il filtro di sottoscrizione è attivo in un secondo momento, CloudWatch Logs invia gli eventi di registro alla destinazione per conto dell'account di origine.
**Creazione di una destinazione**
1. Nell'account del destinatario, crea un flusso di destinazione in Amazon Kinesis Data Streams. Al prompt dei comandi, digita:
```
aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
```
1. Attendi finché il flusso non diventa attivo. **Puoi usare il **comando aws kinesis describe-stream** per controllare. StreamDescription StreamStatus**proprietà. Inoltre, prendi nota del valore **StreamDescription.StreamArn** perché lo passerai a Logs in un secondo CloudWatch momento:
```
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"
}
}
]
}
}
```
Potrebbero essere necessari uno o due minuti perché il flusso sia in stato attivo.
1. Crea il ruolo IAM che concede a CloudWatch Logs l'autorizzazione a inserire dati nel tuo stream. Per prima cosa, devi creare una politica di fiducia in un file **TrustPolicyFor\$1/** CWL.json. Utilizza un editor di testo per creare questo file di policy, non utilizzare la console IAM.
Questa policy include una chiave di contesto della condizione globale `aws:SourceArn` che specifica il `sourceAccountId` per prevenire il problema di sicurezza noto come "confused deputy". Se non conosci ancora l'ID dell'account di origine nella prima chiamata, consigliamo di inserire l'ARN di destinazione nel campo ARN di origine. Nelle chiamate successive, è necessario impostare l'ARN di origine come l'ARN di origine effettivo raccolto dalla prima chiamata. Per ulteriori informazioni, consulta [Prevenzione del "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. Utilizza il comando **aws iam create-role** per creare il ruolo IAM, specificando il file della policy di attendibilità. Prendi nota del valore Role.Arn restituito perché verrà passato anche a Logs in un secondo momento: 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. Crea una politica di autorizzazioni per definire quali azioni i CloudWatch log possono eseguire sul tuo account. **Innanzitutto, usa un editor di testo per creare una politica di autorizzazioni in un file \$1/ CWL.json: PermissionsFor**
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
}
]
}
```
1. **Associa la politica delle autorizzazioni al ruolo utilizzando il comando aws iam: put-role-policy**
```
aws iam put-role-policy \
--role-name CWLtoKinesisRole \
--policy-name Permissions-Policy-For-CWL \
--policy-document file://~/PermissionsForCWL.json
```
1. Dopo che lo stream è nello stato attivo e hai creato il ruolo IAM, puoi creare la destinazione CloudWatch Logs.
1. In questa fase alla tua destinazione non si associa una policy d'accesso predefinita e costituisce solo la prima delle due fasi necessarie per completare la creazione della destinazione. Prendi nota di **DestinationArn**ciò che viene restituito nel payload:
```
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. Dopo aver completato la fase 7, nell'account del destinatario dei dati di log associa alla destinazione una policy d'accesso predefinita. Questa politica deve specificare **i log: PutSubscriptionFilter** action e concede l'autorizzazione all'account mittente di accedere alla destinazione.
La politica concede l'autorizzazione all' AWS account che invia i log. Puoi specificare solo questo account nella policy oppure, se l'account del mittente è membro di un'organizzazione, la policy può specificare l'ID dell'organizzazione. In questo modo, puoi creare una sola policy per consentire a più account di un'organizzazione di inviare log a questo account di destinazione.
Utilizza un editor di testo per creare un file denominato `~/AccessPolicy.json` con una delle seguenti istruzioni di policy.
Questa prima policy di esempio consente a tutti gli account dell'organizzazione che hanno un ID di `o-1234567890` di inviare log all'account del destinatario.
------
#### [ 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"
]
}
}
}
]
}
```
------
Nell'esempio seguente, solo l'account del mittente dei dati di log (111111111111) può inviare log all'account del destinatario dei dati di 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. Collega la policy creata nel passaggio precedente alla destinazione.
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/AccessPolicy.json
```
Questa politica di accesso consente agli utenti dell' AWS account con ID 1111 di effettuare chiamate **PutSubscriptionFilter**verso la destinazione con ARN arn:aws:logs ::9999:destination:testDestination. *region* Qualsiasi tentativo di chiamata da parte di un altro utente verso questa destinazione verrà rifiutato. PutSubscriptionFilter
Per convalidare i privilegi di un utente su una policy d'accesso predefinita, consulta [Utilizzo dello strumento di validazione delle policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html) nella *guida per l'utente IAM*.
Al termine, se utilizzi le autorizzazioni AWS Organizations per più account, segui la procedura riportata di seguito. [Fase 2: creazione di un ruolo IAM (solo se si utilizza un'organizzazione)](CreateSubscriptionFilter-IAMrole.md) Se le autorizzazioni vengono concesse direttamente all'altro account anziché utilizzare Organizations, puoi saltare tale passaggio e procedere alla sezione [Passaggio 4: creazione di un filtro di sottoscrizione](CreateSubscriptionFilter.md).
# Fase 2: creazione di un ruolo IAM (solo se si utilizza un'organizzazione)
Se nella sezione precedente hai creato la destinazione utilizzando una policy di accesso che concede le autorizzazioni all'organizzazione in cui è presente l'account `111111111111`, invece di concederle direttamente all'account `111111111111`, segui i passaggi descritti di seguito. In caso contrario, passa alla sezione [Passaggio 4: creazione di un filtro di sottoscrizione](CreateSubscriptionFilter.md).
I passaggi descritti in questa sezione creano un ruolo IAM, che CloudWatch può presupporre e verificare se l'account mittente è autorizzato a creare un filtro di sottoscrizione in base alla destinazione del destinatario.
Per l'account mittente, segui la procedura descritta in questa sezione. Il ruolo deve esistere nell'account mittente e devi specificare l'ARN di questo ruolo nel filtro di sottoscrizione. In questo esempio, l'account mittente è denominato `111111111111`.
**Per creare il ruolo IAM necessario per le sottoscrizioni di log tra account utilizzando AWS Organizations**
1. Crea la policy di attendibilità seguente in un file `/TrustPolicyForCWLSubscriptionFilter.json`. Utilizza un editor di testo per creare questo file di policy; non utilizzare la console IAM.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Crea il ruolo IAM che utilizza questa policy. Prendi nota del valore `Arn` restituito dal comando, sarà necessario in seguito in questa procedura. In questo esempio, il ruolo in fase di creazione è denominato `CWLtoSubscriptionFilterRole`.
```
aws iam create-role \
--role-name CWLtoSubscriptionFilterRole \
--assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
```
1. Crea una politica di autorizzazioni per definire le azioni che CloudWatch Logs può eseguire sul tuo account.
1. In primo luogo, utilizza un editor di testo per creare la policy di autorizzazione seguente in un file denominato `~/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Inserisci il comando seguente per associare la policy di autorizzazione appena creata al ruolo creato nella fase 2.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
Al termine dell'operazione, passa alla sezione [Passaggio 4: creazione di un filtro di sottoscrizione](CreateSubscriptionFilter.md).
# Fase 3: autorizzazioni Add/validate IAM per la destinazione tra più account
In base alla AWS logica di valutazione dei criteri tra account, per accedere a qualsiasi risorsa tra account (ad esempio uno stream Kinesis o Firehose utilizzato come destinazione per un filtro di abbonamento) è necessario disporre di una politica basata sull'identità nell'account di invio che fornisca l'accesso esplicito alla risorsa di destinazione tra account diversi. Per ulteriori informazioni sulla logica di valutazione delle policy, consulta la pagina [Cross-account policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).
Puoi collegare la policy basata sull'identità al ruolo IAM o all'utente IAM che stai utilizzando per creare il filtro di sottoscrizione. Questa policy deve essere presente nell'account mittente. Se utilizzi il ruolo di amministratore per creare il filtro di sottoscrizione, puoi saltare questo passaggio e passare a [Passaggio 4: creazione di un filtro di sottoscrizione](CreateSubscriptionFilter.md).
**Aggiunta o convalida delle autorizzazioni IAM necessarie per più account**
1. Immettete il seguente comando per verificare quale ruolo IAM o utente IAM viene utilizzato per eseguire i comandi di log. AWS
```
aws sts get-caller-identity
```
Il comando restituisce un output simile al seguente:
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
Prendi nota del valore rappresentato da *RoleName* o*UserName*.
1. Console di gestione AWS Accedi all'account di invio e cerca le policy allegate con il ruolo IAM o l'utente IAM restituito nell'output del comando che hai inserito nel passaggio 1.
1. Verifica che le policy associate a questo ruolo o utente forniscano autorizzazioni esplicite per richiamare `logs:PutSubscriptionFilter` sulla risorsa di destinazione multi-account.
La seguente politica fornisce le autorizzazioni per creare un filtro di sottoscrizione su qualsiasi risorsa di destinazione solo in un singolo AWS account, account`999999999999`:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowSubscriptionFiltersOnAccountResources",
"Effect": "Allow",
"Action": "logs:PutSubscriptionFilter",
"Resource": [
"arn:aws:logs:*:*:log-group:*",
"arn:aws:logs:*:123456789012:destination:*"
]
}
]
}
```
------
La seguente politica fornisce le autorizzazioni per creare un filtro di sottoscrizione solo su una risorsa di destinazione specifica denominata `sampleDestination` in AWS account singolo, account: `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"
]
}
]
}
```
------
# Passaggio 4: creazione di un filtro di sottoscrizione
Una volta creata una destinazione, l'account del destinatario dei dati di log può condividere l'ARN di destinazione (arn:aws:logs:us-east-1:999999999999:destination:testDestination) con altri account AWS , perché questi possano inviare eventi di log alla stessa destinazione. Tali utenti di questi account di invio possono creare un filtro di sottoscrizione sui rispettivi gruppi di log sulla destinazione. Il filtro di sottoscrizione avvia immediatamente il flusso di dati di log in tempo reale dal gruppo di log selezionato alla destinazione specificata.
**Nota**
Se stai concedendo le autorizzazioni per il filtro di sottoscrizione a un'intera organizzazione, dovrai utilizzare l'ARN del ruolo IAM che hai creato in [Fase 2: creazione di un ruolo IAM (solo se si utilizza un'organizzazione)](CreateSubscriptionFilter-IAMrole.md).
Nell'esempio seguente, viene creato un filtro di sottoscrizione in un account di invio. Il filtro è associato a un gruppo di log contenente AWS CloudTrail eventi in modo che ogni attività registrata effettuata dalle AWS credenziali «Root» venga consegnata alla destinazione creata in precedenza. Tale destinazione incapsula un flusso chiamato "». RecipientStream
Il resto dei passaggi descritti nelle sezioni seguenti presuppone che l'utente abbia seguito le istruzioni riportate in [Invio di CloudTrail eventi ai CloudWatch registri](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) nella *Guida per l'AWS CloudTrail utente* e abbia creato un gruppo di log contenente gli eventi. CloudTrail Questi passaggi presuppongono che il nome di questo gruppo di log sia `CloudTrail/logs`.
Quando inserisci il comando seguente, assicurati di aver effettuato l'accesso come utente IAM o di utilizzare il ruolo IAM per cui hai aggiunto la policy in [Fase 3: autorizzazioni Add/validate IAM per la destinazione tra più account](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"
```
Il gruppo di log e la destinazione devono trovarsi nella stessa AWS regione. Tuttavia, la destinazione può puntare a una AWS risorsa come un flusso Amazon Kinesis Data Streams che si trova in una regione diversa.
# Convalida del flusso dei log eventi
Dopo aver creato il filtro di sottoscrizione, CloudWatch Logs inoltra tutti gli eventi di registro in entrata che corrispondono al modello di filtro allo stream incapsulato nel flusso di destinazione denominato "». **RecipientStream** Il proprietario della destinazione può verificare che ciò stia accadendo utilizzando il get-shard-iterator comando **aws kinesis** per acquisire uno shard Amazon Kinesis Data Streams e utilizzando il comando **aws kinesis get-records per recuperare alcuni record di 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**
Potrebbe essere necessario eseguire nuovamente il comando get-records alcune volte prima che Amazon Kinesis Data Streams inizi a restituire dati.
Dovresti ricevere una risposta con una serie di record di Amazon Kinesis Data Streams. L'attributo di dati nel record Amazon Kinesis Data Streams viene compresso in formato gzip e quindi codificato in base64. Puoi esaminare i dati non elaborati dalla riga di comando utilizzando i seguenti comandi Unix:
```
echo -n "" | base64 -d | zcat
```
I dati con codifica base64 e decompressi sono in formato JSON con la seguente struttura:
```
{
"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\"}"
}
]
}
```
Gli elementi chiave della struttura di dati sono i seguenti:
**owner**
L'ID dell' AWS account dei dati di log di origine.
**logGroup**
Nome del gruppo di log dei dati di log originari.
**logStream**
Nome del flusso di log dei dati di log originari.
**subscriptionFilters**
Elenco dei nomi di filtro sottoscrizione che corrispondono con i dati di log originari.
**messageType**
I messaggi di dati usano il tipo "DATA\$1MESSAGE". A volte CloudWatch i log possono emettere record Amazon Kinesis Data Streams di tipo «CONTROL\$1MESSAGE», principalmente per verificare se la destinazione è raggiungibile.
**logEvents**
I dati di log effettivi, rappresentati come una varietà di record di eventi di log. La proprietà ID è un identificatore univoco per ogni eventi di log.
# Modifica dell'appartenenza alla destinazione in fase di runtime
Potrebbero verificarsi situazioni in cui potresti dover aggiungere o rimuovere l'adesione di alcuni utenti da una destinazione da te posseduta. Puoi utilizzare il commando `put-destination-policy` sulla destinazione con una nuova policy di accesso. Nell'esempio seguente, si impedisce a un account aggiunto in precedenza **111111111111** di inviare ulteriori dati di log, mentre l'account **222222222222** viene abilitato.
1. Recupera la politica attualmente associata alla destinazione **TestDestination** e prendi nota di: **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. Aggiorna la policy per riflettere l'arresto di tale account **111111111111**, mentre l'account **222222222222** viene abilitato. Inserisci questa politica nel file **\$1/ .json: NewAccessPolicy**
------
#### [ 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. Chiama **PutDestinationPolicy**per associare la politica definita nel **NewAccessPolicyfile.json** alla destinazione:
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Alla fine ciò disabiliterà gli eventi di log dall'ID account **111111111111**. I log eventi provenienti dall'ID account **222222222222** iniziano a fluire verso la destinazione non appena il proprietario dell'account **222222222222** crea un filtro di sottoscrizione.
# Aggiornamento di una sottoscrizione tra più account esistente
Se hai una sottoscrizione del log tra più account in cui l'account di destinazione concede le autorizzazioni solo a specifici account del mittente e desideri aggiornare questa sottoscrizione in modo che l'account di destinazione conceda l'accesso a tutti gli account di un'organizzazione, segui la procedura descritta in questa sezione.
**Topics**
+ [Fase 1: aggiornamento dei filtri di sottoscrizione](Cross-Account-Log_Subscription-Update-filter.md)
+ [Fase 2: aggiornamento della policy di accesso alla destinazione esistente](Cross-Account-Log_Subscription-Update-policy.md)
# Fase 1: aggiornamento dei filtri di sottoscrizione
**Nota**
Questo passaggio è necessario solo per le sottoscrizioni tra più account per i log creati dai servizi elencati in [Abilita la registrazione dai servizi AWS](AWS-logs-and-resource-policy.md). Se non stai lavorando con log creati da uno di questi gruppi di log, puoi passare alla sezione [Fase 2: aggiornamento della policy di accesso alla destinazione esistente](Cross-Account-Log_Subscription-Update-policy.md).
In alcuni casi, devi aggiornare i filtri di sottoscrizione in tutti gli account del mittente che inviano log all'account di destinazione. L'aggiornamento aggiunge un ruolo IAM, che CloudWatch può presupporre e convalidare che l'account mittente sia autorizzato a inviare i log all'account del destinatario.
Segui la procedura descritta in questa sezione per ogni account del mittente che desideri aggiornare in modo da utilizzare l'ID dell'organizzazione per le autorizzazioni di sottoscrizione tra più account.
Negli esempi di questa sezione sono già stati creati dei filtri di sottoscrizione negli account `111111111111` e `222222222222` per l'invio di log all'account `999999999999`. I valori del filtro di sottoscrizione esistenti sono i seguenti:
```
## 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 è necessario trovare i valori dei parametri del filtro di sottoscrizione correnti, digita il comando seguente.
```
aws logs describe-subscription-filters
\ --log-group-name "my-log-group-name"
```
**Per aggiornare un filtro di sottoscrizione e iniziare a utilizzare l'organizzazione IDs per le autorizzazioni di registro tra più account**
1. Crea la policy di attendibilità seguente in un file `~/TrustPolicyForCWL.json`. Utilizza un editor di testo per creare questo file di policy; non utilizzare la console IAM.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Crea il ruolo IAM che utilizza questa policy. Prendi nota del valore `Arn` del valore `Arn` restituito dal comando, sarà necessario in seguito in questa procedura. In questo esempio, il ruolo in fase di creazione è denominato `CWLtoSubscriptionFilterRole`.
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.json
```
1. Crea una politica di autorizzazioni per definire le azioni che CloudWatch Logs può eseguire sul tuo account.
1. In primo luogo, utilizza un editor di testo per creare la policy di autorizzazione seguente in un file denominato `/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Inserisci il comando seguente per associare la policy di autorizzazione appena creata al ruolo creato nella fase 2.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
1. Inserisci il comando seguente per aggiornare il filtro di sottoscrizione.
```
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"
```
# Fase 2: aggiornamento della policy di accesso alla destinazione esistente
Dopo aver aggiornato i filtri di sottoscrizione in tutti gli account del mittente, è possibile aggiornare la policy di accesso alla destinazione nell'account del destinatario.
Negli esempi seguenti, l'account del destinatario è `999999999999` e la destinazione è denominata `testDestination`.
L'aggiornamento abilita tutti gli account che fanno parte dell'organizzazione con ID `o-1234567890` per l'invio di log all'account del destinatario. Solo gli account con filtri di sottoscrizione creati invieranno effettivamente log all'account del destinatario.
**Aggiornamento della policy di accesso alla destinazione nell'account del destinatario per iniziare a utilizzare un ID dell'organizzazione per le autorizzazioni**
1. Nell'account del destinatario, utilizza un editor di testo per creare un file `~/AccessPolicy.json` con i seguenti contenuti.
------
#### [ 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. Digita il seguente comando per collegare la policy appena creata alla destinazione esistente. Per aggiornare una destinazione in modo da utilizzare una politica di accesso con un ID dell'organizzazione anziché una politica di accesso che elenca un AWS account specifico IDs, includi il `force` parametro.
**avvertimento**
Se utilizzi i log inviati da un AWS servizio elencato in[Abilita la registrazione dai servizi AWS](AWS-logs-and-resource-policy.md), prima di eseguire questo passaggio devi aver aggiornato i filtri di abbonamento in tutti gli account mittente, come spiegato in. [Fase 1: aggiornamento dei filtri di sottoscrizione](Cross-Account-Log_Subscription-Update-filter.md)
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Condivisione dei dati di registro tra più account tra regioni tramite Firehose
Per condividere dati di log tra diversi account, è necessario stabilire un mittente e un ricevitore di dati di log:
+ **Mittente dei dati di registro**: ottiene le informazioni sulla destinazione dal destinatario e comunica a CloudWatch Logs che è pronto a inviare gli eventi di registro alla destinazione specificata. Nelle procedure illustrate nel resto di questa sezione, il mittente dei dati di registro viene visualizzato con un numero di account fittizio pari a 1111 AWS .
+ **Destinatario dei dati di log**: configura una destinazione che incapsula un flusso Amazon Kinesis Data Streams CloudWatch e comunica a Logs che il destinatario desidera ricevere dati di log. Il destinatario quindi condivide le informazioni su questa destinazione con il mittente. Nelle procedure descritte nel resto di questa sezione, il destinatario dei dati di registro viene mostrato con un numero di account fittizio di 222222222222. AWS
L'esempio in questa sezione utilizza un flusso di distribuzione Firehose con storage Amazon S3. È inoltre possibile configurare i flussi di distribuzione di Firehose con impostazioni diverse. Per ulteriori informazioni, vedere [Creating a Firehose Delivery Stream](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).
**Nota**
Il gruppo di log e la destinazione devono trovarsi nella stessa AWS regione. Tuttavia, la AWS risorsa a cui punta la destinazione può trovarsi in una regione diversa.
**Nota**
È supportato il filtro di abbonamento Firehose per ***lo stesso account*** e lo stesso flusso di distribuzione ***tra regioni***.
**Topics**
+ [Fase 1: Creare un flusso di distribuzione Firehose](CreateFirehoseStream.md)
+ [Fase 2: creazione di una destinazione](CreateFirehoseStreamDestination.md)
+ [Fase 3: autorizzazioni Add/validate IAM per la destinazione tra più account](Subscription-Filter-CrossAccount-Permissions-Firehose.md)
+ [Passaggio 4: creazione di un filtro di sottoscrizione](CreateSubscriptionFilterFirehose.md)
+ [Convalida del flusso dei log eventi](ValidateLogEventFlowFirehose.md)
+ [Modifica dell'appartenenza alla destinazione durante il runtime](ModifyDestinationMembershipFirehose.md)
# Fase 1: Creare un flusso di distribuzione Firehose
**Importante**
Prima di completare i seguenti passaggi, è necessario utilizzare una policy di accesso, in modo che Firehose possa accedere al bucket Amazon S3. Per ulteriori informazioni, consulta [Controlling Access](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3) nella *Amazon Data Firehose Developer Guide*.
Tutti i passaggi in questa sezione (Fase 1) devono essere eseguiti nell'account del destinatario dei dati di log.
La regione Stati Uniti orientali (Virginia settentrionale) viene utilizzata nei comandi di esempio. Sostituiscila con la Regione corretta per l'implementazione.
**Per creare un flusso di distribuzione Firehose da utilizzare come destinazione**
1. Crea un bucket Amazon S3:
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. Crea il ruolo IAM che concede a Firehose l'autorizzazione a inserire dati nel bucket.
1. In primo luogo, utilizza un editor di testo per creare una policy di attendibilità in un file `~/TrustPolicyForFirehose.json`.
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. Crea il ruolo IAM, specificando il file della policy di attendibilità appena creato.
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. L'output di questo comando risulterà simile al seguente: Annotare i Nome ruolo e ARN ruolo.
```
{
"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. Crea una politica di autorizzazioni per definire le azioni che Firehose può eseguire sul tuo account.
1. In primo luogo, utilizza un editor di testo per creare la policy di autorizzazione seguente in un file denominato `~/PermissionsForFirehose.json`. A seconda del caso d'uso, potresti dover aggiungere altre autorizzazioni a questo file.
```
{
"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. Inserisci il comando seguente per associare la policy di autorizzazioni appena creata con il ruolo IAM.
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. Immettete il seguente comando per creare il flusso di distribuzione di Firehose. Sostituisci *my-role-arn* e *amzn-s3-demo-bucket2-arn* con i valori corretti per la tua implementazione.
```
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"}'
```
L’output visualizzato dovrebbe essere simile al seguente:
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# Fase 2: creazione di una destinazione
**Importante**
Tutte le fasi di questa procedura devono essere eseguite nell'account del destinatario dei dati di log.
Quando viene creata la destinazione, CloudWatch Logs invia un messaggio di prova alla destinazione per conto dell'account del destinatario. Quando il filtro di sottoscrizione è attivo in un secondo momento, CloudWatch Logs invia gli eventi di registro alla destinazione per conto dell'account di origine.
**Creazione di una destinazione**
1. Attendi che lo stream Firehose in cui hai creato [Fase 1: Creare un flusso di distribuzione Firehose](CreateFirehoseStream.md) diventi attivo. **È possibile utilizzare il seguente comando per controllare ilStreamDescription. StreamStatus**proprietà.
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
Inoltre, prendi nota del **DeliveryStreamDescription. DeliveryStreamValore ARN**, perché sarà necessario utilizzarlo in un passaggio successivo. Esempio di output di questo 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
}
}
```
Potrebbero essere necessari uno o due minuti che il flusso di consegna venga visualizzato nello stato attivo.
1. Quando il flusso di distribuzione è attivo, crea il ruolo IAM che concederà a CloudWatch Logs l'autorizzazione a inserire dati nel tuo flusso Firehose. Per prima cosa, devi creare una policy di fiducia in un file **TrustPolicyFor\$1/** CWL.json. Utilizza un editor di testo per creare questa policy. Per ulteriori informazioni sugli endpoint di Amazon CloudWatch Logs, consulta Endpoints e quote di [Amazon CloudWatch Logs.](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html)
Questa policy include una chiave di contesto della condizione globale `aws:SourceArn` che specifica il `sourceAccountId` per prevenire il problema di sicurezza noto come "confused deputy". Se non conosci ancora l'ID dell'account di origine nella prima chiamata, consigliamo di inserire l'ARN di destinazione nel campo ARN di origine. Nelle chiamate successive, è necessario impostare l'ARN di origine come l'ARN di origine effettivo raccolto dalla prima chiamata. Per ulteriori informazioni, consulta [Prevenzione del "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. Utilizza il comando **aws iam create-role** per creare il ruolo IAM, specificando il file della policy di attendibilità appena creato.
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
Di seguito è riportato un output di esempio. Prendi nota del valore `Role.Arn` restituito, perché dovrai usarlo in una fase successiva.
```
{
"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. Crea una politica di autorizzazioni per definire quali azioni CloudWatch Logs può eseguire sul tuo account. **Innanzitutto, usa un editor di testo per creare una politica di autorizzazioni in un file \$1/ CWL.json: PermissionsFor**
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. Associa la policy di autorizzazioni al ruolo inserendo il comando seguente:
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Dopo che il flusso di distribuzione di Firehose è nello stato attivo e hai creato il ruolo IAM, puoi creare la destinazione CloudWatch Logs.
1. In questa fase alla tua destinazione non verrà associata una policy d'accesso predefinita e costituisce solo la prima delle due fasi necessarie per completare la creazione della destinazione. Annota dell'ARN della nuova destinazione restituito nel payload, perché lo utilizzerai come `destination.arn` in una fase successiva.
```
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. Dopo aver completato la fase precedente, nell'account del destinatario dei dati di log (222222222222) associa alla destinazione una policy d'accesso.
Questa policy consente all'account mittente dei dati di log (111111111111) di accedere alla destinazione all'interno dell'account destinatario dei dati di log (222222222222). Puoi usare un editor di testo per inserire questa policy nel file **\$1/ AccessPolicy .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. In questo modo viene creata una policy che definisce chi ha accesso in scrittura alla destinazione. Questa politica deve specificare i **log: PutSubscriptionFilter** action per accedere alla destinazione. Gli utenti con più account utilizzeranno l'**PutSubscriptionFilter**azione per inviare gli eventi di registro alla destinazione:
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# Fase 3: autorizzazioni Add/validate IAM per la destinazione tra più account
In base alla AWS logica di valutazione dei criteri tra account, per accedere a qualsiasi risorsa tra account (ad esempio uno stream Kinesis o Firehose utilizzato come destinazione per un filtro di abbonamento) è necessario disporre di una politica basata sull'identità nell'account di invio che fornisca l'accesso esplicito alla risorsa di destinazione tra account diversi. Per ulteriori informazioni sulla logica di valutazione delle policy, consulta la pagina [Cross-account policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic-cross-account.html).
Puoi collegare la policy basata sull'identità al ruolo IAM o all'utente IAM che stai utilizzando per creare il filtro di sottoscrizione. Questa policy deve essere presente nell'account mittente. Se utilizzi il ruolo di amministratore per creare il filtro di sottoscrizione, puoi saltare questo passaggio e passare a [Passaggio 4: creazione di un filtro di sottoscrizione](CreateSubscriptionFilter.md).
**Aggiunta o convalida delle autorizzazioni IAM necessarie per più account**
1. Immettete il seguente comando per verificare quale ruolo IAM o utente IAM viene utilizzato per eseguire i comandi di log. AWS
```
aws sts get-caller-identity
```
Il comando restituisce un output simile al seguente:
```
{
"UserId": "User ID",
"Account": "sending account id",
"Arn": "arn:aws:sending account id:role/user:RoleName/UserName"
}
```
Prendi nota del valore rappresentato da *RoleName* o*UserName*.
1. Console di gestione AWS Accedi all'account di invio e cerca le policy allegate con il ruolo IAM o l'utente IAM restituito nell'output del comando che hai inserito nel passaggio 1.
1. Verifica che le policy associate a questo ruolo o utente forniscano autorizzazioni esplicite per richiamare `logs:PutSubscriptionFilter` sulla risorsa di destinazione multi-account.
La seguente politica fornisce le autorizzazioni per creare un filtro di sottoscrizione su qualsiasi risorsa di destinazione solo in un singolo AWS account, account`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:*"
]
}
]
}
```
------
La seguente politica fornisce le autorizzazioni per creare un filtro di sottoscrizione solo su una risorsa di destinazione specifica denominata `sampleDestination` in AWS account singolo, account: `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"
]
}
]
}
```
------
# Passaggio 4: creazione di un filtro di sottoscrizione
Passare all'account di invio, che in questo esempio è 111111111111. Verrà ora creato il filtro di sottoscrizione nell'account di invio. In questo esempio, il filtro è associato a un gruppo di log contenente AWS CloudTrail eventi in modo che ogni attività registrata effettuata dalle AWS credenziali «Root» venga consegnata alla destinazione creata in precedenza. *Per ulteriori informazioni su come inviare AWS CloudTrail eventi ai CloudWatch registri, vedere [Invio di CloudTrail eventi ai CloudWatch registri nella Guida per](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/send-cloudtrail-events-to-cloudwatch-logs.html) l'utente.AWS CloudTrail *
Quando inserisci il comando seguente, assicurati di aver effettuato l'accesso come utente IAM o di utilizzare il ruolo IAM per cui hai aggiunto la policy in [Fase 3: autorizzazioni Add/validate IAM per la destinazione tra più account](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"
```
Il gruppo di log e la destinazione devono trovarsi nella stessa AWS regione. Tuttavia, la destinazione può puntare a una AWS risorsa come un flusso Firehose che si trova in una regione diversa.
# Convalida del flusso dei log eventi
Dopo aver creato il filtro di sottoscrizione, CloudWatch Logs inoltra tutti gli eventi di registro in entrata che corrispondono allo schema di filtro al flusso di distribuzione di Firehose. I dati iniziano a comparire nel bucket Amazon S3 in base all'intervallo di tempo impostato nel flusso di distribuzione di Firehose. Quando è trascorso tempo sufficiente, puoi verificare i dati controllando il bucket Amazon S3. Per controllare il bucket, inserisci il comando seguente:
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
L'output di questo comando sarà simile al seguente:
```
{
"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"
}
}
]
}
```
È quindi possibile recuperare un oggetto specifico dal bucket inserendo il seguente comando. Sostituisci il valore di `key` con il valore trovato nel comando precedente.
```
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
```
I dati nell'oggetto di Amazon S3 vengono compressi nel formato gzip. Puoi esaminare i dati non elaborati dalla riga di comando utilizzando uno dei seguenti comandi:
Linux:
```
zcat testfile.gz
```
macOS:
```
zcat
Potrebbero verificarsi situazioni in cui devi aggiungere o rimuovere mittenti di log da una destinazione da te posseduta. Puoi utilizzare l'**PutDestinationPolicy**azione sulla tua destinazione con una nuova politica di accesso. Nell'esempio seguente, si impedisce a un account aggiunto in precedenza **111111111111** di inviare ulteriori dati di log, mentre l'account **333333333333** viene abilitato.
1. Recupera la politica attualmente associata alla destinazione **TestDestination** e prendi nota di: **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. Aggiorna la policy per riflettere che l'account **111111111111** è stoppato, mentre l'account **333333333333** viene abilitato. Inserisci questa politica nel file **\$1/ .json: NewAccessPolicy**
------
#### [ 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. Usa il seguente comando per associare la politica definita nel **NewAccessPolicyfile.json** alla destinazione:
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Questo alla fine disabilita il log eventi dall'ID account **111111111111**. I log eventi provenienti dall'ID account **333333333333** iniziano a fluire verso la destinazione non appena il proprietario dell'account **333333333333** crea un filtro di sottoscrizione.
# Abbonamenti a livello di account tra più account con Amazon Kinesis Data Streams
Durante la creazione di una sottoscrizione tra più account, è possibile specificare un singolo account o un'organizzazione come mittente. Nel caso in cui si specifichi un'organizzazione, la procedura illustrata di seguito consente a tutti gli account dell'organizzazione di inviare log all'account del destinatario.
Per condividere dati di log tra diversi account, è necessario stabilire un mittente e un ricevitore di dati di log:
+ **Registra il mittente dei dati**: ottiene le informazioni sulla destinazione dal destinatario e comunica a CloudWatch Logs che è pronto a inviare gli eventi di registro alla destinazione specificata. Nelle procedure illustrate nel resto di questa sezione, il mittente dei dati di registro viene visualizzato con un numero di account fittizio pari a 1111 AWS .
Nel caso in cui più account all'interno di un'organizzazione inviano log a un account del destinatario, è possibile creare una policy che conceda a tutti gli account dell'organizzazione l'autorizzazione per eseguire tale operazione. Devi comunque impostare filtri di sottoscrizione separati per ciascun account del mittente.
+ **Destinatario dei dati di log**: configura una destinazione che incapsula un flusso Amazon Kinesis Data Streams CloudWatch e comunica a Logs che il destinatario desidera ricevere dati di log. Il destinatario quindi condivide le informazioni su questa destinazione con il mittente. Nelle procedure illustrate nel resto di questa sezione, il destinatario dei dati di registro viene mostrato con un numero di account fittizio di 9999. AWS
Per iniziare a ricevere gli eventi di registro da utenti con più account, il destinatario dei dati di registro crea innanzitutto una destinazione Logs. CloudWatch Ogni destinazione è formata dai seguenti elementi chiave:
**Nome della destinazione**
Il nome della destinazione che intendi creare.
**ARN di destinazione**
L'Amazon Resource Name (ARN) della AWS risorsa che desideri utilizzare come destinazione del feed di abbonamento.
**ARN del ruolo**
Un ruolo AWS Identity and Access Management (IAM) che concede a CloudWatch Logs le autorizzazioni necessarie per inserire i dati nel flusso scelto.
**Policy di accesso**
Un documento della policy IAM (in formato JSON, scritto utilizzando la grammatica delle policy IAM) che controlla l'insieme degli utenti ai quali è concesso scrivere nella tua destinazione.
**Nota**
Il gruppo di log e la destinazione devono trovarsi nella stessa regione. AWS Tuttavia, la AWS risorsa a cui punta la destinazione può trovarsi in una regione diversa. Negli esempi delle sezioni seguenti, tutte le risorse specifiche della Regione vengono create in Stati Uniti orientali (Virginia settentrionale).
**Topics**
+ [Configurazione di una nuova sottoscrizione tra più account](Cross-Account-Log_Subscription-New-Account.md)
+ [Aggiornamento di una sottoscrizione tra più account esistente](Cross-Account-Log_Subscription-Update-Account.md)
# Configurazione di una nuova sottoscrizione tra più account
Segui la procedura riportata in queste sezioni per configurare una nuova sottoscrizione del log tra più account.
**Topics**
+ [Passaggio 1: creazione di una destinazione](CreateDestination-Account.md)
+ [Fase 2: creazione di un ruolo IAM (solo se si utilizza un'organizzazione)](CreateSubscriptionFilter-IAMrole-Account.md)
+ [Passaggio 3: Crea una politica di filtro degli abbonamenti a livello di account](CreateSubscriptionFilter-Account.md)
+ [Convalida del flusso dei log eventi](ValidateLogEventFlow-Account.md)
+ [Modifica dell'appartenenza alla destinazione in fase di runtime](ModifyDestinationMembership-Account.md)
# Passaggio 1: creazione di una destinazione
**Importante**
Tutte le fasi di questa procedura devono essere eseguite nell'account del destinatario dei dati di log.
Per questo esempio, l'account del destinatario dei dati di registro ha un ID AWS account di 9999, mentre l'ID dell'account mittente AWS dei dati di registro è 1111.
Questo esempio crea una destinazione utilizzando un flusso Amazon Kinesis Data RecipientStream Streams chiamato e un ruolo CloudWatch che consente a Logs di scrivere dati su di esso.
Quando viene creata la destinazione, CloudWatch Logs invia un messaggio di prova alla destinazione per conto dell'account del destinatario. Quando il filtro di sottoscrizione è attivo in un secondo momento, CloudWatch Logs invia gli eventi di registro alla destinazione per conto dell'account di origine.
**Creazione di una destinazione**
1. Nell'account del destinatario, crea un flusso di destinazione in Amazon Kinesis Data Streams. Al prompt dei comandi, digita:
```
aws kinesis create-stream --stream-name "RecipientStream" --shard-count 1
```
1. Attendi finché il flusso non diventa attivo. **Puoi usare il **comando aws kinesis describe-stream** per controllare. StreamDescription StreamStatus**proprietà. Inoltre, prendi nota del valore **StreamDescription.StreamArn** perché lo passerai a Logs in un secondo CloudWatch momento:
```
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"
}
}
]
}
}
```
Potrebbero essere necessari uno o due minuti perché il flusso sia in stato attivo.
1. Crea il ruolo IAM che concede a CloudWatch Logs l'autorizzazione a inserire dati nel tuo stream. Per prima cosa, devi creare una politica di fiducia in un file **TrustPolicyFor\$1/** CWL.json. Utilizza un editor di testo per creare questo file di policy, non utilizzare la console IAM.
Questa policy include una chiave di contesto della condizione globale `aws:SourceArn` che specifica il `sourceAccountId` per prevenire il problema di sicurezza noto come "confused deputy". Se non conosci ancora l'ID dell'account di origine nella prima chiamata, consigliamo di inserire l'ARN di destinazione nel campo ARN di origine. Nelle chiamate successive, è necessario impostare l'ARN di origine come l'ARN di origine effettivo raccolto dalla prima chiamata. Per ulteriori informazioni, consulta [Prevenzione del "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. Utilizza il comando **aws iam create-role** per creare il ruolo IAM, specificando il file della policy di attendibilità. Prendi nota del valore Role.Arn restituito perché verrà passato anche a Logs in un secondo momento: 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. Crea una politica di autorizzazioni per definire quali azioni i CloudWatch log possono eseguire sul tuo account. **Innanzitutto, usa un editor di testo per creare una politica di autorizzazioni in un file \$1/ CWL.json: PermissionsFor**
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "kinesis:PutRecord",
"Resource": "arn:aws:kinesis:region:999999999999:stream/RecipientStream"
}
]
}
```
1. **Associa la politica delle autorizzazioni al ruolo utilizzando il comando aws iam: put-role-policy**
```
aws iam put-role-policy \
--role-name CWLtoKinesisRole \
--policy-name Permissions-Policy-For-CWL \
--policy-document file://~/PermissionsForCWL.json
```
1. Dopo che lo stream è nello stato attivo e hai creato il ruolo IAM, puoi creare la destinazione CloudWatch Logs.
1. In questa fase alla tua destinazione non si associa una policy d'accesso predefinita e costituisce solo la prima delle due fasi necessarie per completare la creazione della destinazione. Prendi nota di **DestinationArn**ciò che viene restituito nel payload:
```
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. Dopo aver completato la fase 7, nell'account del destinatario dei dati di log associa alla destinazione una policy d'accesso predefinita. Questa politica deve specificare **i log: PutSubscriptionFilter** action e concede l'autorizzazione all'account mittente di accedere alla destinazione.
La politica concede l'autorizzazione all' AWS account che invia i log. Puoi specificare solo questo account nella policy oppure, se l'account del mittente è membro di un'organizzazione, la policy può specificare l'ID dell'organizzazione. In questo modo, puoi creare una sola policy per consentire a più account di un'organizzazione di inviare log a questo account di destinazione.
Utilizza un editor di testo per creare un file denominato `~/AccessPolicy.json` con una delle seguenti istruzioni di policy.
Questa prima policy di esempio consente a tutti gli account dell'organizzazione che hanno un ID di `o-1234567890` di inviare log all'account del destinatario.
------
#### [ 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"
]
}
}
}
]
}
```
------
Nell'esempio seguente, solo l'account del mittente dei dati di log (111111111111) può inviare log all'account del destinatario dei dati di 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. Collega la policy creata nel passaggio precedente alla destinazione.
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/AccessPolicy.json
```
Questa politica di accesso consente agli utenti dell' AWS account con ID 1111 di effettuare chiamate **PutSubscriptionFilter**verso la destinazione con ARN arn:aws:logs ::9999:destination:testDestination. *region* Qualsiasi tentativo di chiamata da parte di un altro utente verso questa destinazione verrà rifiutato. PutSubscriptionFilter
Per convalidare i privilegi di un utente su una policy d'accesso predefinita, consulta [Utilizzo dello strumento di validazione delle policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/policies_policy-validator.html) nella *guida per l'utente IAM*.
Al termine, se utilizzi le autorizzazioni AWS Organizations per più account, segui la procedura riportata di seguito. [Fase 2: creazione di un ruolo IAM (solo se si utilizza un'organizzazione)](CreateSubscriptionFilter-IAMrole-Account.md) Se le autorizzazioni vengono concesse direttamente all'altro account anziché utilizzare Organizations, puoi saltare tale passaggio e procedere alla sezione [Passaggio 3: Crea una politica di filtro degli abbonamenti a livello di account](CreateSubscriptionFilter-Account.md).
# Fase 2: creazione di un ruolo IAM (solo se si utilizza un'organizzazione)
Se nella sezione precedente hai creato la destinazione utilizzando una policy di accesso che concede le autorizzazioni all'organizzazione in cui è presente l'account `111111111111`, invece di concederle direttamente all'account `111111111111`, segui i passaggi descritti di seguito. In caso contrario, passa alla sezione [Passaggio 3: Crea una politica di filtro degli abbonamenti a livello di account](CreateSubscriptionFilter-Account.md).
I passaggi descritti in questa sezione creano un ruolo IAM, che CloudWatch può presupporre e verificare se l'account mittente è autorizzato a creare un filtro di sottoscrizione in base alla destinazione del destinatario.
Per l'account mittente, segui la procedura descritta in questa sezione. Il ruolo deve esistere nell'account mittente e devi specificare l'ARN di questo ruolo nel filtro di sottoscrizione. In questo esempio, l'account mittente è denominato `111111111111`.
**Per creare il ruolo IAM necessario per le sottoscrizioni di log tra account utilizzando AWS Organizations**
1. Crea la policy di attendibilità seguente in un file `/TrustPolicyForCWLSubscriptionFilter.json`. Utilizza un editor di testo per creare questo file di policy; non utilizzare la console IAM.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Crea il ruolo IAM che utilizza questa policy. Prendi nota del valore `Arn` restituito dal comando, sarà necessario in seguito in questa procedura. In questo esempio, il ruolo in fase di creazione è denominato `CWLtoSubscriptionFilterRole`.
```
aws iam create-role \
--role-name CWLtoSubscriptionFilterRole \
--assume-role-policy-document file://~/TrustPolicyForCWLSubscriptionFilter.json
```
1. Crea una politica di autorizzazioni per definire le azioni che CloudWatch Logs può eseguire sul tuo account.
1. In primo luogo, utilizza un editor di testo per creare la policy di autorizzazione seguente in un file denominato `~/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Inserisci il comando seguente per associare la policy di autorizzazione appena creata al ruolo creato nella fase 2.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
Al termine dell'operazione, passa alla sezione [Passaggio 3: Crea una politica di filtro degli abbonamenti a livello di account](CreateSubscriptionFilter-Account.md).
# Passaggio 3: Crea una politica di filtro degli abbonamenti a livello di account
Una volta creata una destinazione, l'account del destinatario dei dati di log può condividere l'ARN di destinazione (arn:aws:logs:us-east-1:999999999999:destination:testDestination) con altri account AWS , perché questi possano inviare eventi di log alla stessa destinazione. Tali utenti di questi account di invio possono creare un filtro di sottoscrizione sui rispettivi gruppi di log sulla destinazione. Il filtro di sottoscrizione avvia immediatamente il flusso di dati di log in tempo reale dal gruppo di log selezionato alla destinazione specificata.
**Nota**
Se stai concedendo le autorizzazioni per il filtro di sottoscrizione a un'intera organizzazione, dovrai utilizzare l'ARN del ruolo IAM che hai creato in [Fase 2: creazione di un ruolo IAM (solo se si utilizza un'organizzazione)](CreateSubscriptionFilter-IAMrole-Account.md).
Nell'esempio seguente, in un account di invio viene creato un criterio di filtro di sottoscrizione a livello di account. Il filtro è associato all'account mittente in `111111111111` modo che ogni evento di registro che corrisponde al filtro e ai criteri di selezione venga inviato alla destinazione creata in precedenza. Tale destinazione incapsula un flusso chiamato "». RecipientStream
Il `selection-criteria` campo è facoltativo, ma è importante per escludere i gruppi di log che possono causare una ricorsione infinita dei log da un filtro di sottoscrizione. Per ulteriori informazioni su questo problema e per determinare quali gruppi di log escludere, vedere. [Registra la prevenzione della ricorsione](Subscriptions-recursion-prevention.md) Attualmente, NOT IN è l'unico operatore supportato per`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"
```
I gruppi di log dell'account mittente e la destinazione devono trovarsi nella stessa AWS regione. Tuttavia, la destinazione può puntare a una AWS risorsa come un flusso Amazon Kinesis Data Streams che si trova in una regione diversa.
# Convalida del flusso dei log eventi
Dopo aver creato la politica di filtro dell'abbonamento a livello di account, CloudWatch Logs inoltra tutti gli eventi di registro in entrata che corrispondono al modello di filtro e ai criteri di selezione allo stream incapsulato nel flusso di destinazione denominato "». **RecipientStream** Il proprietario della destinazione può verificare che ciò stia accadendo utilizzando il get-shard-iterator comando **aws kinesis** per acquisire uno shard Amazon Kinesis Data Streams e utilizzando il comando **aws kinesis get-records per recuperare alcuni record di 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**
Potrebbe essere necessario eseguire nuovamente il `get-records` comando alcune volte prima che Amazon Kinesis Data Streams inizi a restituire dati.
Dovresti ricevere una risposta con una serie di record di Amazon Kinesis Data Streams. L'attributo di dati nel record Amazon Kinesis Data Streams viene compresso in formato gzip e quindi codificato in base64. Puoi esaminare i dati non elaborati dalla riga di comando utilizzando i seguenti comandi Unix:
```
echo -n "" | base64 -d | zcat
```
I dati con codifica base64 e decompressi sono in formato JSON con la seguente struttura:
```
{
"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\"}"
}
]
}
```
Gli elementi chiave della struttura dei dati sono i seguenti:
**messageType**
I messaggi di dati utilizzeranno il tipo "DATA\$1MESSAGE". A volte CloudWatch i log possono emettere record Amazon Kinesis Data Streams di tipo «CONTROL\$1MESSAGE», principalmente per verificare se la destinazione è raggiungibile.
**owner**
L' AWS ID dell'account dei dati di log di origine.
**logGroup**
Nome del gruppo di log dei dati di log originari.
**logStream**
Nome del flusso di log dei dati di log originari.
**subscriptionFilters**
Elenco dei nomi di filtro sottoscrizione che corrispondono con i dati di log originari.
**logEvents**
I dati di log effettivi, rappresentati come una varietà di record di eventi di log. La proprietà "id" è un identificatore univoco per ogni log eventi.
**Livello di politica**
Il livello al quale è stata applicata la politica. «ACCOUNT\$1LEVEL\$1POLICY» è il criterio di filtro degli abbonamenti a livello `policyLevel` di account.
# Modifica dell'appartenenza alla destinazione in fase di runtime
Potrebbero verificarsi situazioni in cui potresti dover aggiungere o rimuovere l'adesione di alcuni utenti da una destinazione da te posseduta. Puoi utilizzare il commando `put-destination-policy` sulla destinazione con una nuova policy di accesso. Nell'esempio seguente, si impedisce a un account aggiunto in precedenza **111111111111** di inviare ulteriori dati di log, mentre l'account **222222222222** viene abilitato.
1. Recupera la politica attualmente associata alla destinazione **TestDestination** e prendi nota di: **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. Aggiorna la policy per riflettere l'arresto di tale account **111111111111**, mentre l'account **222222222222** viene abilitato. Inserisci questa politica nel file **\$1/ .json: NewAccessPolicy**
------
#### [ 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. Chiama **PutDestinationPolicy**per associare la politica definita nel **NewAccessPolicyfile.json** alla destinazione:
```
aws logs put-destination-policy \
--destination-name "testDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Alla fine ciò disabiliterà gli eventi di log dall'ID account **111111111111**. I log eventi provenienti dall'ID account **222222222222** iniziano a fluire verso la destinazione non appena il proprietario dell'account **222222222222** crea un filtro di sottoscrizione.
# Aggiornamento di una sottoscrizione tra più account esistente
Se hai una sottoscrizione del log tra più account in cui l'account di destinazione concede le autorizzazioni solo a specifici account del mittente e desideri aggiornare questa sottoscrizione in modo che l'account di destinazione conceda l'accesso a tutti gli account di un'organizzazione, segui la procedura descritta in questa sezione.
**Topics**
+ [Fase 1: aggiornamento dei filtri di sottoscrizione](Cross-Account-Log_Subscription-Update-filter-Account.md)
+ [Fase 2: aggiornamento della policy di accesso alla destinazione esistente](Cross-Account-Log_Subscription-Update-policy-Account.md)
# Fase 1: aggiornamento dei filtri di sottoscrizione
**Nota**
Questo passaggio è necessario solo per le sottoscrizioni tra più account per i log creati dai servizi elencati in [Abilita la registrazione dai servizi AWS](AWS-logs-and-resource-policy.md). Se non stai lavorando con log creati da uno di questi gruppi di log, puoi passare alla sezione [Fase 2: aggiornamento della policy di accesso alla destinazione esistente](Cross-Account-Log_Subscription-Update-policy-Account.md).
In alcuni casi, devi aggiornare i filtri di sottoscrizione in tutti gli account del mittente che inviano log all'account di destinazione. L'aggiornamento aggiunge un ruolo IAM, che CloudWatch può presupporre e convalidare che l'account mittente sia autorizzato a inviare i log all'account del destinatario.
Segui la procedura descritta in questa sezione per ogni account del mittente che desideri aggiornare in modo da utilizzare l'ID dell'organizzazione per le autorizzazioni di sottoscrizione tra più account.
Negli esempi di questa sezione sono già stati creati dei filtri di sottoscrizione negli account `111111111111` e `222222222222` per l'invio di log all'account `999999999999`. I valori del filtro di sottoscrizione esistenti sono i seguenti:
```
## Existing Subscription Filter parameter values
{
"DestinationArn": "arn:aws:logs:region:999999999999:destination:testDestination",
"FilterPattern": "{$.userIdentity.type = Root}",
"Distribution": "Random"
}
```
Se è necessario trovare i valori dei parametri del filtro di sottoscrizione correnti, digita il comando seguente.
```
aws logs describe-account-policies \
--policy-type "SUBSCRIPTION_FILTER_POLICY" \
--policy-name "CrossAccountStreamsExamplePolicy"
```
**Per aggiornare un filtro di sottoscrizione e iniziare a utilizzare l'organizzazione IDs per le autorizzazioni di registro tra più account**
1. Crea la policy di attendibilità seguente in un file `~/TrustPolicyForCWL.json`. Utilizza un editor di testo per creare questo file di policy; non utilizzare la console IAM.
```
{
"Statement": {
"Effect": "Allow",
"Principal": { "Service": "logs.amazonaws.com" },
"Action": "sts:AssumeRole"
}
}
```
1. Crea il ruolo IAM che utilizza questa policy. Prendi nota del valore `Arn` del valore `Arn` restituito dal comando, sarà necessario in seguito in questa procedura. In questo esempio, il ruolo in fase di creazione è denominato `CWLtoSubscriptionFilterRole`.
```
aws iam create-role
\ --role-name CWLtoSubscriptionFilterRole
\ --assume-role-policy-document file://~/TrustPolicyForCWL.json
```
1. Crea una politica di autorizzazioni per definire le azioni che CloudWatch Logs può eseguire sul tuo account.
1. In primo luogo, utilizza un editor di testo per creare la policy di autorizzazione seguente in un file denominato `/PermissionsForCWLSubscriptionFilter.json`.
```
{
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutLogEvents",
"Resource": "arn:aws:logs:region:111111111111:log-group:LogGroupOnWhichSubscriptionFilterIsCreated:*"
}
]
}
```
1. Inserisci il comando seguente per associare la policy di autorizzazione appena creata al ruolo creato nella fase 2.
```
aws iam put-role-policy
--role-name CWLtoSubscriptionFilterRole
--policy-name Permissions-Policy-For-CWL-Subscription-filter
--policy-document file://~/PermissionsForCWLSubscriptionFilter.json
```
1. Inserisci il seguente comando per aggiornare la politica di filtro degli abbonamenti.
```
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"
```
# Fase 2: aggiornamento della policy di accesso alla destinazione esistente
Dopo aver aggiornato i filtri di sottoscrizione in tutti gli account del mittente, è possibile aggiornare la policy di accesso alla destinazione nell'account del destinatario.
Negli esempi seguenti, l'account del destinatario è `999999999999` e la destinazione è denominata `testDestination`.
L'aggiornamento abilita tutti gli account che fanno parte dell'organizzazione con ID `o-1234567890` per l'invio di log all'account del destinatario. Solo gli account con filtri di sottoscrizione creati invieranno effettivamente log all'account del destinatario.
**Aggiornamento della policy di accesso alla destinazione nell'account del destinatario per iniziare a utilizzare un ID dell'organizzazione per le autorizzazioni**
1. Nell'account del destinatario, utilizza un editor di testo per creare un file `~/AccessPolicy.json` con i seguenti contenuti.
------
#### [ 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. Digita il seguente comando per collegare la policy appena creata alla destinazione esistente. Per aggiornare una destinazione in modo da utilizzare una politica di accesso con un ID dell'organizzazione anziché una politica di accesso che elenca un AWS account specifico IDs, includi il `force` parametro.
**avvertimento**
Se utilizzi i log inviati da un AWS servizio elencato in[Abilita la registrazione dai servizi AWS](AWS-logs-and-resource-policy.md), prima di eseguire questo passaggio devi aver aggiornato i filtri di abbonamento in tutti gli account mittente, come spiegato in. [Fase 1: aggiornamento dei filtri di sottoscrizione](Cross-Account-Log_Subscription-Update-filter-Account.md)
```
aws logs put-destination-policy
\ --destination-name "testDestination"
\ --access-policy file://~/AccessPolicy.json
\ --force
```
# Abbonamenti a livello di account per più account con più account che utilizzano Firehose
Per condividere dati di log tra diversi account, è necessario stabilire un mittente e un ricevitore di dati di log:
+ **Mittente dei dati di registro**: ottiene le informazioni sulla destinazione dal destinatario e comunica a CloudWatch Logs che è pronto a inviare gli eventi di registro alla destinazione specificata. Nelle procedure illustrate nel resto di questa sezione, il mittente dei dati di registro viene visualizzato con un numero di account fittizio pari a 1111 AWS .
+ **Destinatario dei dati di log**: configura una destinazione che incapsula un flusso Amazon Kinesis Data Streams CloudWatch e comunica a Logs che il destinatario desidera ricevere dati di log. Il destinatario quindi condivide le informazioni su questa destinazione con il mittente. Nelle procedure descritte nel resto di questa sezione, il destinatario dei dati di registro viene mostrato con un numero di account fittizio di 222222222222. AWS
L'esempio in questa sezione utilizza un flusso di distribuzione Firehose con storage Amazon S3. È inoltre possibile configurare i flussi di distribuzione di Firehose con impostazioni diverse. Per ulteriori informazioni, vedere [Creating a Firehose Delivery Stream](https://docs.aws.amazon.com/firehose/latest/dev/basic-create.html).
**Nota**
Il gruppo di log e la destinazione devono trovarsi nella stessa AWS regione. Tuttavia, la AWS risorsa a cui punta la destinazione può trovarsi in una regione diversa.
**Nota**
È supportato il filtro di abbonamento Firehose per ***lo stesso account*** e lo stesso flusso di distribuzione ***tra regioni***.
**Topics**
+ [Fase 1: Creare un flusso di distribuzione Firehose](CreateFirehoseStream-Account.md)
+ [Fase 2: creazione di una destinazione](CreateFirehoseStreamDestination-Account.md)
+ [Passaggio 3: Creare una politica di filtro degli abbonamenti a livello di account](CreateSubscriptionFilterFirehose-Account.md)
+ [Convalida del flusso dei log eventi](ValidateLogEventFlowFirehose-Account.md)
+ [Modifica dell'appartenenza alla destinazione durante il runtime](ModifyDestinationMembershipFirehose-Account.md)
# Fase 1: Creare un flusso di distribuzione Firehose
**Importante**
Prima di completare i seguenti passaggi, è necessario utilizzare una policy di accesso, in modo che Firehose possa accedere al bucket Amazon S3. Per ulteriori informazioni, consulta [Controlling Access](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3) nella *Amazon Data Firehose Developer Guide*.
Tutti i passaggi in questa sezione (Fase 1) devono essere eseguiti nell'account del destinatario dei dati di log.
La regione Stati Uniti orientali (Virginia settentrionale) viene utilizzata nei comandi di esempio. Sostituiscila con la Regione corretta per l'implementazione.
**Per creare un flusso di distribuzione Firehose da utilizzare come destinazione**
1. Crea un bucket Amazon S3:
```
aws s3api create-bucket --bucket amzn-s3-demo-bucket --create-bucket-configuration LocationConstraint=us-east-1
```
1. Crea il ruolo IAM che concede a Firehose l'autorizzazione a inserire dati nel bucket.
1. In primo luogo, utilizza un editor di testo per creare una policy di attendibilità in un file `~/TrustPolicyForFirehose.json`.
```
{ "Statement": { "Effect": "Allow", "Principal": { "Service": "firehose.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId":"222222222222" } } } }
```
1. Crea il ruolo IAM, specificando il file della policy di attendibilità appena creato.
```
aws iam create-role \
--role-name FirehosetoS3Role \
--assume-role-policy-document file://~/TrustPolicyForFirehose.json
```
1. L'output di questo comando risulterà simile al seguente: Annotare i Nome ruolo e ARN ruolo.
```
{
"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. Crea una politica di autorizzazioni per definire le azioni che Firehose può eseguire sul tuo account.
1. In primo luogo, utilizza un editor di testo per creare la policy di autorizzazione seguente in un file denominato `~/PermissionsForFirehose.json`. A seconda del caso d'uso, potresti dover aggiungere altre autorizzazioni a questo file.
```
{
"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. Inserisci il comando seguente per associare la policy di autorizzazioni appena creata con il ruolo IAM.
```
aws iam put-role-policy --role-name FirehosetoS3Role --policy-name Permissions-Policy-For-Firehose-To-S3 --policy-document file://~/PermissionsForFirehose.json
```
1. Immettete il seguente comando per creare il flusso di distribuzione di Firehose. Sostituisci *my-role-arn* e *amzn-s3-demo-bucket2-arn* con i valori corretti per la tua implementazione.
```
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"}'
```
L’output visualizzato dovrebbe essere simile al seguente:
```
{
"DeliveryStreamARN": "arn:aws:firehose:us-east-1:222222222222:deliverystream/my-delivery-stream"
}
```
# Fase 2: creazione di una destinazione
**Importante**
Tutte le fasi di questa procedura devono essere eseguite nell'account del destinatario dei dati di log.
Quando viene creata la destinazione, CloudWatch Logs invia un messaggio di prova alla destinazione per conto dell'account del destinatario. Quando il filtro di sottoscrizione è attivo in un secondo momento, CloudWatch Logs invia gli eventi di registro alla destinazione per conto dell'account di origine.
**Creazione di una destinazione**
1. Attendi che lo stream Firehose in cui hai creato [Fase 1: Creare un flusso di distribuzione Firehose](CreateFirehoseStream-Account.md) diventi attivo. **È possibile utilizzare il seguente comando per controllare ilStreamDescription. StreamStatus**proprietà.
```
aws firehose describe-delivery-stream --delivery-stream-name "my-delivery-stream"
```
Inoltre, prendi nota del **DeliveryStreamDescription. DeliveryStreamValore ARN**, perché sarà necessario utilizzarlo in un passaggio successivo. Esempio di output di questo 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
}
}
```
Potrebbero essere necessari uno o due minuti che il flusso di consegna venga visualizzato nello stato attivo.
1. Quando il flusso di distribuzione è attivo, crea il ruolo IAM che concederà a CloudWatch Logs l'autorizzazione a inserire dati nel tuo flusso Firehose. Per prima cosa, devi creare una policy di fiducia in un file **TrustPolicyFor\$1/** CWL.json. Utilizza un editor di testo per creare questa policy. Per ulteriori informazioni sugli endpoint di Amazon CloudWatch Logs, consulta Endpoints e quote di [Amazon CloudWatch Logs.](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html)
Questa policy include una chiave di contesto della condizione globale `aws:SourceArn` che specifica il `sourceAccountId` per prevenire il problema di sicurezza noto come "confused deputy". Se non conosci ancora l'ID dell'account di origine nella prima chiamata, consigliamo di inserire l'ARN di destinazione nel campo ARN di origine. Nelle chiamate successive, è necessario impostare l'ARN di origine come l'ARN di origine effettivo raccolto dalla prima chiamata. Per ulteriori informazioni, consulta [Prevenzione del "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. Utilizza il comando **aws iam create-role** per creare il ruolo IAM, specificando il file della policy di attendibilità appena creato.
```
aws iam create-role \
--role-name CWLtoKinesisFirehoseRole \
--assume-role-policy-document file://~/TrustPolicyForCWL.json
```
Di seguito è riportato un output di esempio. Prendi nota del valore `Role.Arn` restituito, perché dovrai usarlo in una fase successiva.
```
{
"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. Crea una politica di autorizzazioni per definire quali azioni CloudWatch Logs può eseguire sul tuo account. **Innanzitutto, usa un editor di testo per creare una politica di autorizzazioni in un file \$1/ CWL.json: PermissionsFor**
```
{
"Statement":[
{
"Effect":"Allow",
"Action":["firehose:*"],
"Resource":["arn:aws:firehose:region:222222222222:*"]
}
]
}
```
1. Associa la policy di autorizzazioni al ruolo inserendo il comando seguente:
```
aws iam put-role-policy --role-name CWLtoKinesisFirehoseRole --policy-name Permissions-Policy-For-CWL --policy-document file://~/PermissionsForCWL.json
```
1. Dopo che il flusso di distribuzione di Firehose è nello stato attivo e hai creato il ruolo IAM, puoi creare la destinazione CloudWatch Logs.
1. In questa fase alla tua destinazione non verrà associata una policy d'accesso predefinita e costituisce solo la prima delle due fasi necessarie per completare la creazione della destinazione. Annota dell'ARN della nuova destinazione restituito nel payload, perché lo utilizzerai come `destination.arn` in una fase successiva.
```
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. Dopo aver completato la fase precedente, nell'account del destinatario dei dati di log (222222222222) associa alla destinazione una policy d'accesso. Questa policy consente all'account mittente dei dati di log (111111111111) di accedere alla destinazione all'interno dell'account destinatario dei dati di log (222222222222). È possibile utilizzare un editor di testo per inserire questa politica nel `~/AccessPolicy.json` file:
------
#### [ 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. In questo modo viene creata una policy che definisce chi ha accesso in scrittura alla destinazione. Questa politica deve specificare le `logs:PutAccountPolicy` azioni `logs:PutSubscriptionFilter` e per accedere alla destinazione. Gli utenti con più account utilizzeranno `PutAccountPolicy` le azioni `PutSubscriptionFilter` e per inviare gli eventi di registro alla destinazione.
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/AccessPolicy.json
```
# Passaggio 3: Creare una politica di filtro degli abbonamenti a livello di account
Passare all'account di invio, che in questo esempio è 111111111111. Ora creerai la politica di filtro degli abbonamenti a livello di account nell'account di invio. In questo esempio, il filtro fa sì che ogni evento di registro contenente la stringa `ERROR` in tutti i gruppi di log tranne due venga recapitato alla destinazione creata in precedenza.
```
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"
```
I gruppi di log dell'account mittente e la destinazione devono trovarsi nella stessa AWS regione. Tuttavia, la destinazione può puntare a una AWS risorsa come un flusso Firehose che si trova in una regione diversa.
# Convalida del flusso dei log eventi
Dopo aver creato il filtro di sottoscrizione, CloudWatch Logs inoltra tutti gli eventi di registro in entrata che corrispondono allo schema di filtro e ai criteri di selezione al flusso di distribuzione di Firehose. I dati iniziano a comparire nel bucket Amazon S3 in base all'intervallo di tempo impostato nel flusso di distribuzione di Firehose. Quando è trascorso tempo sufficiente, puoi verificare i dati controllando il bucket Amazon S3. Per controllare il bucket, inserisci il comando seguente:
```
aws s3api list-objects --bucket 'amzn-s3-demo-bucket'
```
L'output di questo comando sarà simile al seguente:
```
{
"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"
}
}
]
}
```
È quindi possibile recuperare un oggetto specifico dal bucket inserendo il seguente comando. Sostituisci il valore di `key` con il valore trovato nel comando precedente.
```
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
```
I dati nell'oggetto di Amazon S3 vengono compressi nel formato gzip. Puoi esaminare i dati non elaborati dalla riga di comando utilizzando uno dei seguenti comandi:
Linux:
```
zcat testfile.gz
```
macOS:
```
zcat
Potrebbero verificarsi situazioni in cui devi aggiungere o rimuovere mittenti di log da una destinazione da te posseduta. Puoi utilizzare le `PutAccountPolicy` azioni **PutDestinationPolicy**e sulla tua destinazione con la nuova politica di accesso. Nell'esempio seguente, si impedisce a un account aggiunto in precedenza **111111111111** di inviare ulteriori dati di log, mentre l'account **333333333333** viene abilitato.
1. Recupera la politica attualmente associata alla destinazione **TestDestination** e prendi nota di: **AccessPolicy**
```
aws logs describe-destinations \
--destination-name-prefix "testFirehoseDestination"
```
I dati restituiti potrebbero avere questo aspetto.
```
{
"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. Aggiorna la policy per riflettere che l'account **111111111111** è stoppato, mentre l'account **333333333333** viene abilitato. Inserisci questa politica nel file **\$1/ NewAccessPolicy .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. Usa il seguente comando per associare la politica definita nel **NewAccessPolicyfile.json** alla destinazione:
```
aws logs put-destination-policy \
--destination-name "testFirehoseDestination" \
--access-policy file://~/NewAccessPolicy.json
```
Questo alla fine disabilita il log eventi dall'ID account **111111111111**. I log eventi provenienti dall'ID account **333333333333** iniziano a fluire verso la destinazione non appena il proprietario dell'account **333333333333** crea un filtro di sottoscrizione.