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