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à. # Delega temporanea IAM per AWS i partner ## Panoramica di La delega temporanea IAM consente AWS ai clienti di and/or integrare senza problemi i prodotti AWS Partner nel loro AWS ambiente attraverso flussi di lavoro interattivi e guidati. I clienti possono concedere ai AWS partner un accesso limitato e temporaneo per configurare AWS i servizi richiesti, riducendo le difficoltà legate all'onboarding e accelerando il time-to-value. La delega temporanea IAM consente ai partner di: + Semplifica l'onboarding dei clienti con il provisioning automatico delle risorse + Riduci la complessità dell'integrazione eliminando le fasi di configurazione manuali + Crea fiducia attraverso autorizzazioni trasparenti e approvate dal cliente + Abilita le operazioni continue con modelli di accesso a lungo termine utilizzando limiti di autorizzazione ## Come funziona 1. *Il partner crea una richiesta di delega*: i partner creano una richiesta specificando di quali autorizzazioni hanno bisogno e per quanto tempo 1. *Recensioni dei clienti su AWS Console*: il cliente vede esattamente quali autorizzazioni richiede il partner e perché 1. *Il cliente approva*: il cliente approva la richiesta e rilascia un token di scambio. Il token viene inviato al partner su questo argomento SNS specificato. 1. *Il partner riceve credenziali temporanee*: i partner scambiano il token con credenziali temporanee AWS 1. *Il partner configura le risorse*: i partner utilizzano le credenziali per configurare le risorse necessarie nell'account del cliente ## Qualifica del partner Per qualificarsi per l'integrazione con delega temporanea, un partner deve soddisfare i seguenti requisiti: + *Partecipazione a ISV Accelerate*: devi essere iscritto al programma [ISV Accelerate (ISVA](https://aws.amazon.com/partners/programs/isv-accelerate/)). + *AWS Inserzione nel Marketplace*: il tuo prodotto deve essere pubblicato nel AWS Marketplace con il badge «Deployed on AWS». ## Processo di onboarding Completa i seguenti passaggi per integrare la delega temporanea nel tuo prodotto: 1. *Fase 1: Rivedere i requisiti* Consulta questa documentazione per comprendere i requisiti di qualificazione e completa il questionario per i partner riportato di seguito. 1. *Fase 2: Invia la richiesta di onboarding* Invia un'e-mail a aws-iam-partner-onboarding @amazon .com o contatta il tuo AWS rappresentante. Includi il questionario per i partner compilato con tutti i campi obbligatori della tabella seguente. 1. *Fase 3: AWS convalida e revisione* AWS provvederà a: + Conferma di soddisfare i criteri di qualificazione + Rivedi i modelli di policy e i limiti di autorizzazione + Fornisci un feedback sugli artefatti inviati 1. *Fase 4: Perfeziona le tue politiche* Rispondi al AWS feedback e invia modelli di policy o limiti di autorizzazione aggiornati, se necessario. 1. *Fase 5: Completa la registrazione* Una volta approvato, AWS dovrà: + Abilita l'accesso all'API per gli account specificati + Condividi in ARNs base al modello di policy e al limite delle autorizzazioni (se applicabile) Riceverai una conferma al termine dell'onboarding. Potrai quindi accedere alla APIs delega temporanea CreateDelegationRequest e GetDelegatedAccessToken dai tuoi account registrati e iniziare a integrare i flussi di lavoro di richiesta di delega nel tuo prodotto. ## Questionario per i partner La tabella seguente elenca le informazioni richieste per l'onboarding dei partner: | Informazioni | Description | Richiesto | | --- | --- | --- | | AccountID di Partner Central | ID account dell' AWS account registrato su [AWS Partner Central](https://partnercentral.awspartner.com/partnercentral2/s/login). | Sì | | PartnerId | ID partner fornito da [AWS Partner Central](https://partnercentral.awspartner.com/partnercentral2/s/login). | No | | AWS ID prodotto Marketplace | ID del prodotto fornito da [AWS Partner Central](https://partnercentral.awspartner.com/partnercentral2/s/login). | Sì | | AWS accountIDs | L'elenco del tuo AWS account IDs che desideri utilizzare per chiamare una delega temporanea APIs. Questo dovrebbe includere sia i tuoi account di produzione che quelli non di produzione/test. | Sì | | Nome del partner | Questo nome viene visualizzato ai clienti nella console di AWS gestione quando esaminano la richiesta di delega temporanea. | Sì | | E-mail di contatto | Uno o più indirizzi e-mail che possiamo utilizzare per contattarti in merito alla tua integrazione. | Sì | | Richiedente o dominio | Il tuo dominio (ad esempio, www.example.com) | Sì | | Integration description (Descrizione dell'integrazione) | Breve descrizione del caso d'uso che desideri risolvere utilizzando questa funzionalità. Puoi includere link di riferimento alla tua documentazione o ad altro materiale pubblico. | Sì | | Diagramma architetturale | Diagramma dell'architettura che illustra i casi d'uso dell'integrazione. | No | | Modello di policy | È necessario registrare almeno un modello di policy per questa funzionalità. Il modello di policy definisce le autorizzazioni temporanee che desideri richiedere negli account dei clienti AWS . Per ulteriori informazioni, consulta la sezione Modello di policy. | Sì | | Nome del modello di policy | Nome del modello di policy che si desidera registrare. | Sì | | Limite delle autorizzazioni | Se desideri creare ruoli IAM negli account dei clienti utilizzando autorizzazioni temporanee, devi registrare un limite di autorizzazione con IAM. I limiti di autorizzazione verranno assegnati ai ruoli IAM che crei per limitare le autorizzazioni massime per il ruolo. Puoi utilizzare politiche AWS gestite selezionate come limite di autorizzazione o registrare un nuovo limite di autorizzazione personalizzato (JSON). Per ulteriori informazioni, consulta la sezione Limiti delle autorizzazioni. | No | | Nome del limite di autorizzazione | Il nome del limite di autorizzazione. Il formato è: arn:aws:iam: :partner:policy/permission\$1boundary//\$1 Il nome della policy deve includere la data di creazione come suffisso. Il nome non può essere aggiornato una volta creato il limite di autorizzazione. Se utilizzi una policy AWS gestita esistente, fornisci invece l'ARN della policy gestita. | No | | Descrizione del limite dell'autorizzazione | Descrizione del limite di autorizzazione. Questa descrizione non può essere aggiornata una volta creato il limite di autorizzazione. | No | # Comprendere la tua integrazione Dopo aver completato il processo di onboarding, puoi creare la tua integrazione con la delega temporanea IAM. Un'integrazione completa prevede in genere tre categorie principali di lavoro: ## 1. Esperienza utente e progettazione del flusso di lavoro Crea un'esperienza front-end nell'applicazione partner che guidi i clienti attraverso il flusso di lavoro di delega temporanea. L'applicazione partner deve: + Presentare un flusso di onboarding o configurazione chiaro in cui i clienti possano concedere un accesso temporaneo. Etichetta chiaramente questa azione, ad esempio «Implementa con delega temporanea IAM». + Reindirizza i clienti alla console di AWS gestione per esaminare e approvare la richiesta di delega utilizzando il collegamento alla console restituito dall'API CreateDelegationRequest + Fornisci messaggi appropriati su quali autorizzazioni vengono richieste e perché. I clienti possono visualizzare questo messaggio nella pagina dei dettagli della richiesta di delega. + Gestisci il ritorno del cliente alla tua applicazione dopo aver completato l'approvazione in AWS. ## 2. Integrazione delle API Utilizza la APIs delega temporanea IAM per inviare e gestire le richieste di delega. Una volta registrati AWS gli account, puoi accedere a quanto segue APIs: + *IAM CreateDelegationRequest*: crea una richiesta di delega per l' AWS account di un cliente. Questa API restituisce un collegamento alla console a cui reindirizzi i clienti per la revisione e l'approvazione della richiesta. + *AWS STS GetDelegatedAccessToken*— Recupera AWS le credenziali temporanee dopo che un cliente ha approvato la richiesta di delega. Utilizza queste credenziali per eseguire azioni nell'account del cliente. L'integrazione dovrebbe gestire l'intero ciclo di vita delle richieste di delega, inclusa la creazione di richieste, il monitoraggio del loro stato e il recupero delle credenziali temporanee una volta approvate. ## 3. Configurazione e orchestrazione delle risorse Una volta ottenute le credenziali temporanee, orchestrate i flussi di lavoro necessari per configurare le risorse nell'account del cliente. AWS Ciò può includere: + Chiamare APIs direttamente il AWS servizio per creare e configurare risorse + Implementazione dell'infrastruttura tramite modelli AWS CloudFormation + Creazione di ruoli IAM per l'accesso continuo (richiede l'utilizzo dei limiti di autorizzazione) La logica di orchestrazione deve essere idempotente e gestire gli errori con garbo, poiché i clienti potrebbero dover riprovare o modificare le approvazioni delle deleghe. # Informazioni sulle autorizzazioni Come parte del processo di onboarding delle funzionalità, dovrai registrare delle politiche con IAM che definiscano le autorizzazioni che desideri richiedere negli account dei clienti. AWS Il processo di registrazione offre un'esperienza più coerente per i clienti e aiuta a evitare gli errori più comuni nella redazione delle policy. Durante la registrazione, AWS valuta le tue politiche rispetto a una serie di convalide. Queste convalide hanno lo scopo di standardizzare la formattazione e la struttura delle politiche e fornire protezioni di base contro gli anti-modelli noti. Le convalide riducono inoltre il rischio di aumento dei privilegi, di accessi involontari tra account e di ampio accesso a risorse di alto valore negli account dei clienti. ## Tipi di autorizzazione AWS prenderà in considerazione due categorie di autorizzazioni: temporanee e a lungo termine. ### Autorizzazioni temporanee Le autorizzazioni temporanee limitano le autorizzazioni assegnate a qualsiasi sessione temporanea di accesso delegato. Le autorizzazioni temporanee sono descritte nei modelli di policy applicati alla sessione delegata. I modelli supportano i parametri forniti quando si crea una richiesta di delega. Questi valori dei parametri vengono quindi associati alla sessione. Le autorizzazioni temporanee funzionano allo stesso modo delle politiche di sessione disponibili AWS STS oggi: le politiche limitano la capacità dell'utente sottostante, ma non garantiscono alcun accesso aggiuntivo. Per ulteriori informazioni, consulta la AWS STS documentazione sulle politiche di sessione. ### Autorizzazioni a lungo termine Le autorizzazioni a lungo termine limitano le autorizzazioni di tutti i ruoli creati o gestiti tramite accesso temporaneo. Le autorizzazioni a lungo termine sono implementate come limiti delle autorizzazioni IAM. Puoi specificare uno o più limiti di autorizzazione AWS come parte dell'onboarding. Una volta approvata, AWS condividerà con te un ARN della politica a cui puoi fare riferimento nelle tue politiche. Queste politiche delimitative hanno due caratteristiche degne di nota. Innanzitutto, sono immutabili. Se desideri aggiornare le autorizzazioni, puoi registrare un nuovo limite di autorizzazioni. Puoi quindi collegare il nuovo limite di autorizzazioni ai ruoli dei tuoi clienti inviando una nuova richiesta di delega. In secondo luogo, le politiche non sono basate su modelli. Poiché la stessa politica di confine è condivisa a livello globale, non può essere modificata in base al cliente. **Importante** I limiti di autorizzazione hanno un limite di dimensione massima di 6.144 caratteri. **Nota** Se desideri aggiornare un limite di autorizzazione o un modello di policy, contatta IAM all'indirizzo aws-iam-partner-onboarding @amazon .com. Una volta registrato il nuovo limite di autorizzazione, puoi inviare una richiesta di delega ai clienti per aggiornare il ruolo IAM e allegare il limite di autorizzazione appena registrato. Consulta la sezione Esempi per maggiori dettagli. ## Caso d'uso di esempio: carico di lavoro per l'elaborazione dei dati Prendiamo in considerazione un fornitore di prodotti che esegua un carico di lavoro di elaborazione dei dati negli account dei clienti. Il provider deve configurare l'infrastruttura durante l'onboarding iniziale, ma richiede anche un accesso continuo per gestire il carico di lavoro. *Autorizzazioni temporanee (per la configurazione iniziale):* + Crea EC2 istanze Amazon, VPC e gruppi di sicurezza + Crea un bucket Amazon S3 per i dati elaborati + Crea un ruolo IAM per le operazioni in corso + Associa un limite di autorizzazione al ruolo IAM *Autorizzazioni a lungo termine (ruolo IAM con limite di autorizzazione per le operazioni in corso):* + Avvia e arresta EC2 le istanze Amazon per eseguire processi di elaborazione + Leggi i dati di input dal bucket Amazon S3 + Scrivi i risultati elaborati nel bucket Amazon S3 Le autorizzazioni temporanee vengono utilizzate una sola volta durante l'onboarding per configurare l'infrastruttura. Il ruolo IAM creato durante questo processo ha un limite di autorizzazione che limita le autorizzazioni massime solo alle operazioni necessarie per la gestione continua del carico di lavoro. Ciò garantisce che, anche se le politiche del ruolo vengono modificate, non possano superare le autorizzazioni definite nel limite. # Linee guida di valutazione delle politiche AWS valuterà le politiche inviate rispetto a una serie di linee guida. Le stesse linee guida di valutazione si applicano sia ai modelli di policy che ai limiti di autorizzazione, con lievi differenze, laddove opportuno, segnalate. Ai fini della valutazione, separiamo i servizi in gruppi distinti. La distinzione più importante riguarda i servizi sensibili alla sicurezza, che gestiscono l'accesso, le credenziali e le chiavi. Le politiche che garantiscono l'accesso a questi servizi devono essere strettamente incentrate sul lavoro svolto. I servizi sensibili alla sicurezza includono: AWS Identity and Access Management (IAM), AWS Key Management Service (KMS), Resource Access Manager AWS (RAM), IAM AWS Identity Center, AWS Organizations e Secrets Manager. AWS Una distinzione secondaria sono i servizi che possono accedere ai dati attraverso i confini degli account. Le politiche relative a questi servizi devono includere protezioni per impedire accessi involontari tra account. ## Convalide comuni Tutte le dichiarazioni politiche devono seguire queste linee guida: + Tutte le istruzioni devono includere i campi Effetto, Azione (o NotAction), Risorsa e Condizione in quest'ordine + Tutte le azioni all'interno di una singola istruzione devono essere elencate in ordine alfabetico + Tutte le informazioni ARNs incluse nella politica devono seguire la sintassi definita nella documentazione pubblica per i servizi pertinenti + NotAction i campi possono essere utilizzati solo nelle dichiarazioni Deny + Le azioni nelle istruzioni Allow devono includere un codice di servizio. I caratteri jolly generici («\$1») non sono consentiti ## Restrizioni relative ai servizi sensibili alla sicurezza Le seguenti restrizioni si applicano ai servizi sensibili alla sicurezza sopra menzionati: + Le azioni nelle istruzioni Allow devono essere più specifiche di [service] :\$1 + Le azioni nelle istruzioni Allow per i modelli di policy di accesso temporaneo non devono contenere caratteri jolly + Le azioni sensibili, come iam: PassRole o iam:CreateServiceLinkedRole, richiedono un ambito aggiuntivo, come risorse specifiche o controlli condizionali. Queste azioni includono: + Passaggio di ruoli IAM + Azioni di modifica del ruolo IAM + Azioni di modifica delle politiche IAM + AWS Operazioni di scrittura o crittografia KMS + AWS Operazioni di scrittura o condivisione della RAM + AWS Operazioni di Secrets Manager per il recupero o la modifica dei segreti o la modifica delle politiche delle risorse + Altre azioni possono utilizzare una risorsa wildcard, come iam: o iam: ListUsers GetPolicy + Le azioni che gestiscono le credenziali, come iam:CreateAccessKey, sono bloccate ## Restrizioni specifiche di IAM Per IAM: + Per i ruoli e le policy IAM sono consentite solo operazioni di scrittura limitate. Non puoi richiedere autorizzazioni su altre risorse IAM come utenti, gruppi e certificati. + Le azioni di allegamento delle policy o di gestione delle policy in linea sono limitate ai ruoli con un limite di autorizzazione. I limiti di autorizzazione devono essere forniti dai partner o inclusi in un elenco di politiche gestite consentite. AWS AWS le politiche gestite possono essere consentite se non concedono autorizzazioni amministrative o altamente privilegiate. Ad esempio, le politiche AWS gestite per funzioni lavorative specifiche o la SecurityAudit politica possono essere accettabili. AWS esaminerà ogni politica AWS gestita su case-by-case base regolare durante il processo di onboarding. + La gestione delle policy è consentita solo per le policy con un percorso specifico per i partner: arn:aws:iam: :@ \$1\$1 :policy/partner\$1domain.com/ [feature] \$1 AccountId + I tag possono essere applicati solo durante la creazione delle risorse e solo per ruoli e politiche + iam: PassRole i controlli devono corrispondere a un nome o a un prefisso di percorso specifico ## AWS STS-restrizioni specifiche Per AWS STS: + sts: AssumeRole deve essere limitato a un ruolo specifico ARN, prefisso ARN del ruolo o limitato a un set di account o unità organizzative ID/organizational ## Restrizioni di IAM Identity Center Per AWS IAM Identity Center, le seguenti azioni sono bloccate: + Tutte le azioni relative alla gestione delle autorizzazioni (ad esempio, sso:) AttachCustomerManagedPolicyReferenceToPermissionSet + Modifiche a utenti, gruppi e appartenenze per Identity Store AWS + Gestione dei tag ## AWS Restrizioni delle Organizzazioni Per AWS Organizations, saranno consentite solo le azioni di lettura. ## Validazioni aggiuntive specifiche del servizio + Le azioni che acquisiscono segreti o credenziali, come glue: GetConnection o redshift:GetClusterCredentials, devono avere condizioni che corrispondano a full, ai prefissi ARNs ARN o ai tag + Per Amazon Redshift: redshift: GetClusterCredentials è consentito solo su un nome di database specifico e redshift: GetClusterCredentialsWith IAM è consentito solo su un nome di gruppo di lavoro specifico **Nota** Quando gestisci le risorse IAM nell'account, ti consigliamo di utilizzare un percorso che indichi il tuo nome, ad esempio arn:aws:iam: :111122223333:. role/partner.com/rolename Ciò contribuirà a differenziare le risorse associate all'integrazione e a semplificare l'individuazione, l'audit e l'analisi per i clienti. ## Requisiti di accesso a più account Le dichiarazioni che potenzialmente consentono l'accesso su più account devono includere almeno uno dei seguenti elementi: + Una condizione che specifica l'account o l'organizzazione per la risorsa (ad esempio, aws: ResourceOrgId corrispondenza di uno o più valori previsti) + Un campo Resource che include un account specifico (ad esempio, arn:aws:sqs: \$1:111122223333: \$1) + Un campo Resource che include un account non jolly e un nome completo di risorsa (ad esempio, arn:aws:s3:::) full-bucket-name **Nota** L'accesso tra account diversi è una funzionalità delicata che richiede una chiara giustificazione aziendale. AWS esaminerà attentamente la necessità di accedere a più account durante il processo di onboarding. # Modelli di policy I modelli di policy sono un nuovo costrutto IAM progettato per definire le autorizzazioni temporanee che i partner richiedono negli account dei clienti. Come le normali policy IAM, definiscono le autorizzazioni utilizzando istruzioni con elementi Effect, Action, Resource e Condition. La differenza principale è che i modelli di policy includono parametri (come @ \$1bucketName\$1) che vengono sostituiti con valori effettivi quando si crea una richiesta di delega. ## Come funzionano i modelli di policy Come parte del processo di onboarding, registri i tuoi modelli di polizza con. AWS AWS assegna a ogni modello un ARN univoco a cui si fa riferimento durante la creazione delle richieste di delega. Quando si crea una richiesta di delega, si specifica: + Il modello di policy ARN + Valori dei parametri da sostituire nel modello AWS combina il modello con i valori dei parametri per generare una policy IAM standard. I clienti esaminano questa politica finale renderizzata al momento dell'approvazione della richiesta di delega, per vedere esattamente quali autorizzazioni verranno concesse. **Nota** La politica renderizzata finale ha un limite di dimensione massima di 2048 caratteri. Ecco un semplice esempio che mostra come funziona la sostituzione dei modelli. Modello di policy: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::@{bucketName}/*" } ] } ``` Parametri forniti nella richiesta di delega: ``` { "Name": "bucketName", "Values": ["customer-data-bucket"], "Type": "String" } ``` Politica finale visualizzata (cosa vedono i clienti): ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::customer-data-bucket/*" } ] } ``` ## Sintassi del modello I modelli di policy utilizzano due funzionalità chiave per garantire flessibilità: la sostituzione dei parametri e le istruzioni condizionali. La sostituzione dei parametri consente di definire segnaposti nel modello che vengono sostituiti con valori effettivi durante la creazione di una richiesta di delega. Le istruzioni condizionali consentono di includere o escludere intere dichiarazioni di policy basate sui valori dei parametri. ### Sostituzione e tipi di parametri Utilizzate la sintassi @ \$1parameterName\$1 per definire i parametri nel modello di policy. Quando si crea una richiesta di delega, è necessario specificare il tipo di ciascun parametro. #### Stringa Un singolo valore che viene sostituito direttamente nel modello. Modello: ``` "Resource": "arn:aws:s3:::@{bucketName}/*" ``` Parametri: ``` { "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" } ``` Risultato renderizzato: ``` "Resource": "arn:aws:s3:::my-bucket/*" ``` #### StringList Valori multipli che generano più voci di risorse. Quando un StringList parametro viene utilizzato in un ARN di risorse, si espande per creare voci di risorse separate per ogni valore. Modello: ``` "Resource": "arn:aws:s3:::@{bucketNames}/*" ``` Parametri: ``` { "Name": "bucketNames", "Values": ["bucket-1", "bucket-2"], "Type": "StringList" } ``` Risultato renderizzato: ``` "Resource": [ "arn:aws:s3:::bucket-1/*", "arn:aws:s3:::bucket-2/*" ] ``` #### Comportamento tra prodotti Quando vengono utilizzati più parametri nella stessa risorsa ARN, StringList i parametri creano un prodotto incrociato di tutte le combinazioni. Modello: ``` "Resource": "arn:aws:s3:::@{bucketNames}/@{prefix}/*" ``` Parametri: ``` [ { "Name": "bucketNames", "Values": ["bucket-1", "bucket-2"], "Type": "StringList" }, { "Name": "prefix", "Values": ["data"], "Type": "String" } ] ``` Risultato renderizzato: ``` "Resource": [ "arn:aws:s3:::bucket-1/data/*", "arn:aws:s3:::bucket-2/data/*" ] ``` ### Dichiarazioni condizionali Utilizzate la direttiva @Enabled per includere o escludere in modo condizionale intere istruzioni basate sui valori dei parametri. Sintassi: + @Enabled: «ParameterName» - Include l'istruzione quando il valore del parametro è «True» + @Enabled: «\$1 ParameterName» - Include l'istruzione quando il valore del parametro NON è «True» (negazione) Modello: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" }, { "@Enabled": "ENABLE_S3_WRITE", "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::@{bucketName}/*" } ] } ``` Parametri (quando ENABLE\$1S3\$1WRITE è «True»): ``` [ { "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" }, { "Name": "ENABLE_S3_WRITE", "Values": ["True"], "Type": "String" } ] ``` Risultato renderizzato: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" }, { "Effect": "Allow", "Action": ["s3:PutObject"], "Resource": "arn:aws:s3:::my-bucket/*" } ] } ``` Parametri (quando ENABLE\$1S3\$1WRITE è «False»): ``` [ { "Name": "bucketName", "Values": ["my-bucket"], "Type": "String" }, { "Name": "ENABLE_S3_WRITE", "Values": ["False"], "Type": "String" } ] ``` Risultato renderizzato: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": "*" } ] } ``` Quando ENABLE\$1S3\$1WRITE è impostato su «True», viene inclusa l'istruzione condizionale. Quando è impostata su «False», l'istruzione viene esclusa dalla politica renderizzata. ## Esempi aggiuntivi Gli esempi seguenti mostrano modelli comuni per l'utilizzo dei modelli di policy nella delega temporanea. Si concentrano sulla creazione di ruoli IAM con limiti di autorizzazione per l'accesso a lungo termine e mostrano diverse strategie per l'ambito delle autorizzazioni a risorse specifiche. Questi esempi illustrano come bilanciare flessibilità e sicurezza utilizzando tecniche come prefissi ARN, codifica delle risorse e aggiornamenti dei limiti delle autorizzazioni. ### Esempio 1: concessione dell'accesso a lungo termine a risorse specifiche Il seguente limite di autorizzazione viene inviato come "SQSAccessorLimite» per «partner.com»: ``` { "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } } ``` **Nota** Ciò include la condizione dello stesso account per evitare di concedere l'accesso alle code di altri account con politiche relative alle risorse aperte. Non è possibile includere un riferimento diretto all'ID dell'account del cliente perché il limite è condiviso tra tutti i clienti e non può essere modellato. Poiché questa è la prima versione di questa politica, il suo ARN è arn:aws:iam: :partner: \$12025\$101\$115 policy/permissions-boundary/partner.com/SQSAccessorBoundary Il seguente modello di policy viene inviato per le autorizzazioni di accesso temporanee: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sqs:ListQueues" ], "Resource": "arn:aws:sqs:*:*:*" }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15" } } } ] } ``` ### Esempio 2: utilizzo dei prefissi ARN Il limite di autorizzazione può specificare un prefisso ARN della risorsa per limitare l'accesso: ``` "Resource": "arn:aws:sqs:*:@{AccountId}:PartnerPrefix*" ``` Ciò limita l'accesso solo alle risorse con quel prefisso, riducendo l'ambito delle risorse accessibili. ### Esempio 3: utilizzo dei tag per il controllo dell'accesso alle risorse È possibile etichettare le risorse durante l'accesso delegato temporaneo e fare affidamento su tali tag per il controllo degli accessi a lungo termine. Limite di autorizzazione che consente l'accesso alle risorse contrassegnate: ``` { "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "Null": { "aws:ResourceTag/ManagedByPartnerDotCom": "false" }, "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } } ``` Modello di policy per etichettare nuove code al momento della creazione: ``` { "Effect": "Allow", "Action": [ "sqs:CreateQueue", "sqs:TagQueue" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "Null": { "aws:RequestTag/ManagedByPartnerDotCom": "false" } } } ``` Modello di policy per etichettare le code preesistenti e creare il ruolo: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sqs:TagQueue" ], "Resource": "arn:aws:sqs:*:@{AccountId}:@{QueueName}", "Condition": { "ForAllValues:StringEquals": { "aws:TagKeys": "ManagedByPartnerDotCom" } } }, { "Effect": "Allow", "Action": [ "iam:CreateRole", "iam:PutRolePermissionsBoundary", "iam:PutRolePolicy" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_15" } } } ] } ``` Questo approccio consente ai clienti di confermare esplicitamente a quali risorse specifiche è possibile accedere a lungo termine. ### Esempio 4: aggiornamento del limite di autorizzazione Per aggiornare un limite di autorizzazione, registra una nuova versione con un nuovo suffisso di data e richiedi l'autorizzazione per sostituirlo. Limite di autorizzazione aggiornato con autorizzazioni aggiuntive: ``` { "Effect": "Allow", "Action": [ "sqs:DeleteMessage", "sqs:PurgeQueue", "sqs:ReceiveMessage", "sqs:SendMessage" ], "Resource": "arn:aws:sqs:*:*:*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } } ``` Come seconda versione, questa politica ha l'ARN: arn:aws:iam: :partner: \$12025\$101\$120 policy/permissions-boundary/partner.com/SQSAccessorBoundary Modello di policy per aggiornare il limite di autorizzazione sul ruolo esistente: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:PutRolePermissionsBoundary" ], "Resource": "arn:aws:iam::@{AccountId}:role/partner.com/SQSAccessor", "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::partner:policy/permissions-boundary/partner.com/SQSAccessorBoundary_2025_01_20" } } } ] } ``` I clienti devono approvare questa richiesta di delega per aggiornare il limite di autorizzazione sul ruolo esistente. # Sviluppa la tua integrazione ## Comprensione del ciclo di vita delle richieste Prima di creare l'integrazione, è importante capire in che modo le richieste di delega procedono dalla creazione al completamento. ### Stati della richiesta Una richiesta di delega procede attraverso i seguenti stati: | Stato | Description | | --- | --- | | Non assegnato | Richiesta creata ma non ancora associata a un account cliente e a un responsabile IAM. La richiesta potrebbe essere stata creata senza specificare un account di destinazione o con un ID di account di destinazione ma non essere stata ancora richiesta dal proprietario dell'account. | | Assegnato | Richiesta associata a un account cliente e in attesa di revisione | | In attesa di approvazione | Il cliente ha inoltrato la richiesta a un amministratore per l'approvazione | | Accettato | Richiesta approvata dal cliente ma il token di scambio non è ancora stato rilasciato | | Finalizzato | Token di scambio rilasciato al fornitore del prodotto. Il periodo di delega (validità del token di scambio) inizia quando la richiesta raggiunge lo stato Finalizzato | | Rifiutato | Richiesta rifiutata dal cliente | | Scaduto | Richiesta scaduta per inattività o timeout | ### Transizioni di stato *Flusso normale (percorso di approvazione)* + Non assegnato → Assegnato: il cliente associa la richiesta al proprio account + Assegnato → Accettato OPPURE Assegnato → In attesa di approvazione: il cliente approva la richiesta direttamente OPPURE la inoltra all'amministratore per la revisione + Approvazione in sospeso → Accettata: l'amministratore approva la richiesta + Accettato → Finalizzato: il cliente rilascia il token di scambio *Percorso di rifiuto* + Assegnato → Rifiutato: il cliente rifiuta la richiesta + Approvazione in sospeso → Rifiutata: l'amministratore rifiuta la richiesta + Accettata → Rifiutata: il cliente revoca l'approvazione prima di rilasciare il token *Percorso di scadenza* Le richieste scadono automaticamente se non viene intrapresa alcuna azione entro il periodo di tempo specificato: + Non assegnato → Scaduto (1 giorno) + Assegnato → Scaduto (7 giorni) + In attesa di approvazione → Scaduto (7 giorni) + Accettato → Scaduto (7 giorni) + Rifiutato → Scaduto (7 giorni) + Finalizzato → Scaduto (7 giorni) *Stati terminali* I seguenti stati sono terminali (senza ulteriori transizioni): + Finalizzato: Exchange Token inviato + Rifiutata: la richiesta è stata rifiutata + Scaduta: la richiesta è scaduta o il periodo di delega è terminato Le richieste scadute vengono infine eliminate dal sistema dopo il periodo di conservazione. ### Gestione degli stati delle richieste di delega nell'applicazione In qualità di partner, dovete tenere traccia degli stati delle richieste di delega nel sistema e comunicarli ai clienti. Quando ricevi notifiche SNS sui cambiamenti di stato, archivia questi aggiornamenti nel tuo backend e inseriscili nell'interfaccia utente rivolta ai clienti. Presta particolare attenzione allo stato In sospeso di approvazione: quando un cliente inoltra una richiesta a un amministratore per la revisione, ti invia una notifica di approvazione in sospeso. AWS Le richieste possono rimanere in questo stato per un massimo di 7 giorni in attesa dell'intervento dell'amministratore. Durante questo periodo, mostra ai clienti che la loro richiesta è in attesa dell'approvazione dell'amministratore nella tua applicazione. Prendi in considerazione la possibilità di fornire un collegamento diretto alla AWS Console in cui i clienti possano verificare lo stato della richiesta o contattare l'amministratore. Gestire correttamente la macchina a stati nel backend e fornire ai clienti le informazioni corrette sullo stato in ogni fase sono importanti per una buona esperienza di integrazione. ![\[alt text not found\]](http://docs.aws.amazon.com/it_it/IAM/latest/UserGuide/images/delegation-states.png) ## Configurazione delle notifiche IAM utilizza Amazon Simple Notification Service (SNS) per comunicarti le modifiche allo stato della richiesta di delega. Quando crei una richiesta di delega, devi fornire un ARN per argomento SNS dal tuo AWS account registrato. IAM pubblicherà messaggi su questo argomento per eventi importanti, incluso quando i clienti approvano o rifiutano le richieste e quando il token di scambio è pronto. **Nota** Gli argomenti SNS non possono essere inclusi nelle regioni che accettano l'adesione. AWS L'argomento SNS deve trovarsi in una AWS regione abilitata per impostazione predefinita. Per un elenco delle regioni che hanno aderito, consulta Gestione delle AWS regioni nella guida alla gestione degli AWS account. ### Configurazione dell'argomento SNS Per ricevere notifiche di richiesta di delega, devi configurare l'argomento SNS in modo da concedere a IAM le autorizzazioni per pubblicare messaggi su di esso. Aggiungi la seguente dichiarazione politica alla tua policy tematica SNS: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowIAMServiceToPublish", "Effect": "Allow", "Principal": { "Service": "iam.amazonaws.com" }, "Action": "SNS:Publish", "Resource": "arn:aws:sns:REGION:ACCOUNT-ID:TOPIC-NAME" } ] } ``` **Importante** L'argomento SNS deve trovarsi in uno dei tuoi account registrati AWS . IAM non accetterà argomenti SNS da altri account. Se la policy dell'argomento non è configurata correttamente, non riceverai le notifiche di modifica dello stato o il token di scambio. ### Tipi di notifica IAM invia due tipi di notifiche: *StateChange Notifiche* Inviata quando una richiesta di delega passa a un nuovo stato (Assegnata, In attesa di approvazione, Accettata, Finalizzata, Rifiutata, Scaduta). *ExchangeToken Notifiche* Inviato quando un cliente rilascia il token di delega (stato Finalizzato). Questa notifica include il token di scambio necessario per ottenere le credenziali. ### Stati di notifica Riceverai notifiche per i seguenti stati di richiesta di delega: | Stato | Tipo di notifica | Description | | --- | --- | --- | | ASSEGNATO | StateChange | La richiesta è stata associata a un account cliente | | IN ATTESA DI APPROVAZIONE | StateChange | Il cliente ha inoltrato la richiesta a un amministratore per l'approvazione | | ACCETTATI | StateChange | Il cliente ha approvato la richiesta ma non ha ancora rilasciato il token | | FINALIZZATI | StateChange | Il cliente ha rilasciato il token di scambio | | FINALIZZATI | ExchangeToken | Questa notifica contiene l'Exchange Token | | REJECTED | StateChange | Il cliente ha rifiutato la richiesta | | SCADUTO | StateChange | La richiesta è scaduta prima del completamento | ### Formato del messaggio di notifica IAM pubblica notifiche SNS standard. Le informazioni sulla richiesta di delega sono contenute nel campo Messaggio come stringa JSON. *Campi comuni (tutte le notifiche)* | Campo | Tipo | Description | | --- | --- | --- | | Tipo | Stringa | O "StateChange" o "ExchangeToken» | | RequestId | Stringa | L'ID della richiesta di delega IAM | | RequestorWorkflowId | Stringa | L'ID del flusso di lavoro che hai fornito durante la creazione della richiesta | | Stato | Stringa | Stato attuale della richiesta | | OwnerAccountId | Stringa | ID dell' AWS account del cliente | | UpdatedAt | Stringa | Timestamp in cui lo stato è cambiato (formato ISO 8601) | *Campi aggiuntivi (solo notifiche) ExchangeToken * | Campo | Tipo | Description | | --- | --- | --- | | ExchangeToken | Stringa | Il token da scambiare con le credenziali tramite l'API AWS STS GetDelegatedAccessToken | | ExpiresAt | Stringa | Alla scadenza dell'accesso delegato (formato ISO 8601) | ### Esempi di notifiche *StateChange Notifica* ``` { "Type": "Notification", "MessageId": "61ee8ad4-6eec-56b5-8f3d-eba57556aa13", "TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications", "Message": "{\"RequestorWorkflowId\":\"workflow-12345\",\"Type\":\"StateChange\",\"RequestId\":\"dr-abc123\",\"State\":\"ACCEPTED\",\"OwnerAccountId\":\"111122223333\",\"UpdatedAt\":\"2025-01-15T10:30:00.123Z\"}", "Timestamp": "2025-01-15T10:30:00.456Z", "SignatureVersion": "1", "Signature": "...", "SigningCertURL": "...", "UnsubscribeURL": "..." } ``` *ExchangeToken Notifica* ``` { "Type": "Notification", "MessageId": "e44e5435-c72c-5333-aba3-354406782f5b", "TopicArn": "arn:aws:sns:us-east-1:123456789012:partner-notifications", "Message": "{\"RequestId\":\"dr-abc123\",\"RequestorWorkflowId\":\"workflow-12345\",\"State\":\"FINALIZED\",\"OwnerAccountId\":\"111122223333\",\"ExchangeToken\":\"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...\",\"ExpiresAt\":\"2025-01-15T18:30:00.123Z\",\"UpdatedAt\":\"2025-01-15T10:30:00.456Z\",\"Type\":\"ExchangeToken\"}", "Timestamp": "2025-01-15T10:30:00.789Z", "SignatureVersion": "1", "Signature": "...", "SigningCertURL": "...", "UnsubscribeURL": "..." } ``` ## Token di scambio Un token di scambio o un token di permuta viene emesso da IAM quando un cliente accetta e finalizza una richiesta di delega. Il fornitore del prodotto utilizza questo token di scambio o permuta per chiamare l' AWS AWS STS GetDelegatedAccessToken API e ottenere AWS credenziali temporanee con le autorizzazioni approvate dai clienti. Il token di scambio in sé non garantisce l'accesso alle AWS risorse dell'utente; deve essere scambiato con credenziali effettive tramite STS. AWS Il token di scambio può essere riscattato solo dall'account del fornitore del prodotto che ha creato la richiesta di delega. L'account richiedente è incorporato nel token, garantendo che solo il fornitore del prodotto autorizzato possa ottenere le credenziali per accedere all'account del cliente. ### Durata dell'accesso Il periodo di delega inizia quando il cliente rilascia il token di scambio, non quando il fornitore del prodotto lo riscatta. Una volta che il cliente ha rilasciato il token: + Il fornitore del prodotto riceve il token tramite notifica SNS + Possono scambiarlo immediatamente con credenziali + Le credenziali scadono a: data di rilascio \$1 durata approvata + Il fornitore del prodotto può scambiare il token più volte prima della scadenza per ottenere nuove credenziali, se necessario ### Rimborsi multipli I fornitori di prodotti possono scambiare il token più volte durante il periodo di validità per ottenere nuove credenziali. Tuttavia, tutte le credenziali ottenute dallo stesso token di scambio scadono contemporaneamente, in base a quando è stato rilasciato il token. Esempio: se approvi una richiesta di delega di 2 ore e rilasci il token alle 10:00: | Ora di rilascio del token | Ora di scambio dei token | Scadenza delle credenziali | Tempo utilizzabile | | --- | --- | --- | --- | | 10:00 | ore 10:00 | 12:00 | 2 ore | | ore 10:00 | ore 10:20 | 12:00 | 1 ora e 40 minuti | | 10:00 | 11:40 | 12:00 | 20 minuti | | ore 10:00 | 12:10 | Fallito (token scaduto) | 0 minuti | Come mostrato nella tabella, lo scambio del token in una fase successiva del periodo di validità comporta una riduzione del tempo di utilizzo per il fornitore del prodotto.