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à. # Controllo dell'accesso alla console con policy basate sulle risorse e policy di controllo delle risorse **Importante** L'accesso alla console è abilitato per impostazione predefinita. AWS Sign-In consente inizialmente l'accesso illimitato alla console. Per aggiungere restrizioni, abilita la configurazione dell'autorizzazione della console per il tuo account o la tua organizzazione. Le istruzioni di autorizzazione delle risorse create non hanno effetto finché non abiliti l'autorizzazione della console. Per informazioni, consulta [Guida introduttiva al controllo degli accessi alla console utilizzando le policy delle risorse](#console-access-control-getting-started). AWS Sign-In supporta politiche basate sulle risorse e politiche di controllo delle risorse (RCP) per controllare l'accesso a. AWS Sign-In Utilizza queste politiche per verificare l'identità dell'utente e la posizione della rete durante Console di gestione AWS l'accesso, prima, durante e dopo l'autenticazione. Per gli utenti root, queste politiche convalidano la posizione di rete e l'identità dell'utente prima che inizi la raccolta delle credenziali. Le credenziali possono essere inserite solo quando l'accesso proviene dalle reti previste. AWS Sign-In politiche basate sulle risorse: + Applica ai singoli account. AWS + Consenti agli amministratori degli account di limitare l'accesso alla console in base ai parametri di rete e alle identità principali. Politiche di controllo delle risorse (RCP): + Applica a livello di organizzazione tramite AWS Organizations. + Fornisci una governance centralizzata su tutti gli account dei membri. Entrambi i tipi di policy verificano l'accesso prima dell'autenticazione. Ciò impedisce ai principali destinatari di accedere alla pagina di accesso da reti impreviste. Queste politiche non sostituiscono le politiche basate sull'identità IAM, che continuano ad essere applicate. **Nota** Per una documentazione completa sulle politiche di controllo delle risorse, inclusa la configurazione e la gestione a livello di organizzazione, consulta [le policy di controllo delle risorse](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) nella *AWS* Organizations User Guide. Questa sezione si concentra principalmente sulle politiche basate sulle risorse. AWS Sign-In AWS Sign-In le politiche e gli RCP basati sulle risorse si applicano ai seguenti metodi di autenticazione: + **Console di gestione AWS**— Accesso diretto tramite la pagina di accesso della console. + **AWS IAM Identity Center**: accesso alla console tramite IAM Identity Center. + **Provider di identità federati**: Sign-in tramite federazione SAML o OIDC. + **Applicazioni integrate con AWS Sign-In**: Amazon Connect, Amazon QuickSight, AWS Health Dashboard, Amazon AppStream, Amazon Lightsail, AWS IQ. Questi controlli non si applicano all'accesso programmatico tramite chiavi di accesso (AWS SDK o chiamate API firmate con SigV4). ## In che modo AWS Sign-In valuta le politiche basate sulle risorse AWS Sign-In valuta le politiche basate sulle risorse o le politiche di controllo delle risorse (RCP) applicabili in due momenti durante l'accesso alla console: prima dell'autenticazione (fase di preautenticazione) e dopo l'autenticazione riuscita (fase post-autenticazione). Ogni valutazione verifica le chiavi di condizione definite nella politica. Le chiavi disponibili dipendono dalla fase e dall'azione. Per informazioni dettagliate, vedi [Chiavi di condizione supportate](#console-access-control-condition-keys). **Nota** Per l'accesso come utente root, un tentativo di accesso da reti impreviste viene bloccato prima che venga visualizzata la richiesta della password. Ciò impedisce l'invio di credenziali da reti impreviste. Dopo l'autenticazione, la valutazione considera anche le politiche basate sull'identità del principale. Una policy IAM che nega l'azione di accesso pertinente può impedire la concessione della sessione della console, anche quando sono soddisfatte le condizioni di rete. ## Azioni supportate AWS Sign-In le politiche relative alle risorse (politiche basate sulle risorse e RCP) supportano le seguenti azioni: `signin:Authenticate` Si tratta di un'azione di sola valutazione (non richiamabile) che viene valutata quando viene ricevuta una richiesta di accesso. Si tratta di un controllo di preautenticazione e viene eseguito quando il principale inserisce le credenziali nella pagina di accesso (utente root, utente IAM) o avvia l'accesso alla console utilizzando le credenziali di un provider di identità o AWS STS (utente federato, ruolo). **Chiavi di condizione supportate**:,,,,. `aws:SourceIp` `aws:SourceVpc` `aws:SourceVpce` `aws:VpcSourceIp` `aws:RequestedRegion` `signin:PrincipalArn` Principal-based le chiavi di condizione globali (`aws:PrincipalArn`,`aws:PrincipalAccount`) non sono disponibili per questa azione perché l'identità dell'utente non è stata ancora confermata. `signin:AuthorizeOAuth2Access` Utilizzato per la generazione del codice di autorizzazione OAuth. Dopo una corretta autenticazione, questa azione viene attivata quando il sistema genera un codice di autorizzazione OAuth. A questo punto, l'utente è autenticato e sono disponibili le chiavi di condizione basate sui principali. **Chiavi di condizione supportate:**`aws:SourceIp`,`aws:SourceVpc`,,`aws:SourceVpce`,`aws:VpcSourceIp`,`aws:RequestedRegion`. `aws:PrincipalArn` `aws:PrincipalAccount` `signin:CreateOAuth2Token` Questa azione post-autenticazione viene utilizzata per la creazione e lo scambio di token OAuth. Questa azione viene attivata quando si riscattano i codici di autorizzazione per i token di accesso, si aggiornano i token o si eseguono operazioni di scambio di token. Principal-based i tasti di condizione sono disponibili durante questa fase. **Chiavi di condizione supportate:** `aws:SourceIp` `aws:SourceVpc``aws:SourceVpce`,`aws:VpcSourceIp`,,`aws:RequestedRegion`,`aws:PrincipalArn`,`aws:PrincipalAccount`. **Importante** Quando crei AWS Sign-In policy (policy basate sulle risorse o RCP), includi tutte e tre le azioni della policy, in una dichiarazione di pre-autenticazione e `signin:Authenticate` `signin:AuthorizeOAuth2Access` in una dichiarazione post-autenticazione. `signin:CreateOAuth2Token` L'accesso alla console utilizza OAuth 2.0, che esegue tutte e tre le azioni in sequenza. Se la policy omette un'azione, la fase corrispondente non è protetta. Per le azioni relative alla policy degli endpoint VPC, tra cui, `signin:CreateAccount` consulta l'accesso privato alla [Console di gestione AWS](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-private-access.html). ## Chiavi di condizione supportate AWS Sign-In supporta le seguenti chiavi di condizione nelle politiche basate sulle risorse e nelle politiche di controllo delle risorse (RCP). Usa questi tasti per controllare l'accesso alla console in base alla posizione della rete e all'identità principale: + **Network-based (tutte le azioni):**`aws:SourceIp`,`aws:SourceVpc`,`aws:SourceVpce`,`aws:VpcSourceIp`,`aws:RequestedRegion`. + **Identity-based (azioni successive all'autenticazione):**`aws:PrincipalArn`,`aws:PrincipalAccount`. + **Service-specific (solo preautenticazione)**:. `signin:PrincipalArn` Per le regole di utilizzo dettagliate, la compatibilità degli operatori, le restrizioni sulle combinazioni e la matrice di disponibilità per azione, vedere[AWS Sign-In riferimento alle chiavi di condizione](reference-signin-condition-keys.md). ## Guida introduttiva al controllo degli accessi alla console utilizzando le policy delle risorse **Prerequisiti** + AWS CLI installata e configurata. + Autorizzazioni IAM appropriate (vedi[AWS politica gestita: AWSSignInResourcePolicyManagement](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSSignInResourcePolicyManagement)). + Perimetri di rete identificati (intervalli IP, VPC o endpoint VPC). + Principali esclusi designati per mantenere l'accesso (consigliato ma facoltativo). + Se la rete utilizza il filtro in uscita, inserite nella lista consentita l'endpoint del piano di AWS Sign-In controllo (vedi). [AWS Sign-In domini di amministrazione da inserire nella lista consentita](allowlist-domains.md#allowlist-domains-admin) **Importante** Prima di abilitare l'autorizzazione della console in produzione, AWS consiglia di configurare almeno un principale escluso per mantenere l'accesso al ripristino di emergenza. Tutti i principali, incluso l'utente root, sono soggetti alla politica a meno che non siano esplicitamente esclusi. I principali esclusi sono facoltativi, ma la loro omissione aumenta il rischio di blocco dell'account se le condizioni della rete cambiano inaspettatamente. Specificare `--region us-east-1` per tutte le operazioni di scrittura sulle politiche. AWS Sign-In AWS replica le politiche a livello globale da questa regione. Le operazioni di lettura possono riguardare qualsiasi regione. ### Fase 1: Creare dichiarazioni di autorizzazione alle risorse Crea dichiarazioni di autorizzazione che definiscono i controlli di accesso. Tutte le operazioni di scrittura richiedono `--region us-east-1` (il AWS Sign-In servizio accetta modifiche alle politiche solo in questa regione). I parametri rimanenti (`--source-vpc``--source-ip`,`--requested-region`,,`--excluded-principal`) definiscono le condizioni della politica. Ad esempio, `--requested-region us-west-2` aggiunge una condizione che limita l'accesso all'endpoint di accesso regionale us-west-2. **Esempio: limita l'accesso al VPC aziendale:** ``` aws signin put-resource-permission-statement \ --source-vpc vpc-0abc123def456789 \ --requested-region us-west-2 \ --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \ --client-token unique-request-id-12345 \ --region us-east-1 ``` **Esempio: limita l'accesso a un intervallo IP specifico:** ``` aws signin put-resource-permission-statement \ --source-ip "{{IP_ADDRESS}}" \ --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \ --region us-east-1 ``` **Nota** Il `--excluded-principal` parametro indica un principale escluso che aggira le restrizioni di rete, preservando l'accesso di emergenza in caso di modifica delle condizioni della rete. ### Passaggio 2: abilitare la configurazione dell'autorizzazione della console Il passaggio seguente attiva l'applicazione delle policy per la procedura di accesso alla console sull'account o sull'organizzazione. Le istruzioni di autorizzazione delle risorse possono essere create in qualsiasi momento, ma non vengono valutate finché non viene abilitata l'autorizzazione della console. **avvertimento** L'attivazione dell'autorizzazione alla console può bloccare i principali se le condizioni di rete non sono configurate correttamente o se una policy di controllo dei servizi (SCP) o una politica di controllo delle risorse (RCP) esistente nega le azioni. AWS Sign-In Prima di abilitare l'autorizzazione della console, verifica che le istruzioni di autorizzazione siano corrette e rimuovi o modifica eventuali SCP o RCP che negano o. `signin:Authenticate` `signin:AuthorizeOAuth2Access` `signin:CreateOAuth2Token` Per gli account autonomi: ``` aws signin put-console-authorization-configuration \ --target-id \ --region us-east-1 ``` Per AWS Organizations: ``` aws signin put-console-authorization-configuration \ --target-id \ --region us-east-1 ``` Verifica la configurazione: ``` aws signin get-console-authorization-configuration \ --target-id \ --region ``` Elimina la configurazione di autorizzazione della console: ``` aws signin delete-console-authorization-configuration \ --target-id \ --region us-east-1 ``` ### Fase 3: Verifica la tua politica Elenca tutte le dichiarazioni di autorizzazione: ``` aws signin list-resource-permission-statements \ --max-results 50 \ --region ``` Recupera la politica consolidata completa: ``` aws signin get-resource-policy \ --region ``` Il `get-resource-policy` comando restituisce la politica completa basata sulle risorse composta da tutte le dichiarazioni di autorizzazione. Esamina questa politica per confermare che rifletta i controlli di accesso previsti prima di testare l'accesso alla console. ### Disponibilità regionale Le API di autorizzazione della console sono disponibili in tutte le regioni AWS commerciali. Puoi chiamare queste API da qualsiasi regione in cui operi. **Importante** Le operazioni di scrittura (`put-console-authorization-configuration``put-resource-permission-statement`,`delete-console-authorization-configuration`,,`delete-resource-permission-statement`) devono essere eseguite nella `us-east-1` regione. Le politiche create `us-east-1` vengono replicate automaticamente a livello globale. Le operazioni di lettura (`get-console-authorization-configuration``list-resource-permission-statements`,,`get-resource-policy`) possono essere eseguite da qualsiasi regione. ### Comprensione della struttura delle politiche AWS Sign-In le policy contengono due dichiarazioni che proteggono diverse fasi del flusso di accesso alla console: + **Pre-authentication dichiarazione (Azione:`signin:Authenticate`):** valutata quando viene ricevuta la richiesta di accesso, prima del completamento dell'autenticazione. La chiave globale non `aws:PrincipalArn` è disponibile in questa fase perché l'identità del principale non è confermata. In questa fase `signin:PrincipalArn` è possibile esentare i principali specifici dalle restrizioni di rete. Network-based le chiavi delle condizioni sono disponibili per la valutazione in questa fase. + **Post-authentication dichiarazione (Azione:`signin:AuthorizeOAuth2Access`,`signin:CreateOAuth2Token`):** valutata dopo l'autenticazione, durante lo scambio di token OAuth. Viene utilizzato `aws:PrincipalArn` per esentare principi specifici. Tutte le chiavi di condizione basate sulla rete e sull'identità sono disponibili per la valutazione in questa fase. Entrambe le istruzioni sono obbligatorie perché l'accesso alla console utilizza OAuth 2.0, che esegue tutte e tre le azioni in sequenza. Una politica con una sola istruzione lascia l'altra fase non protetta. `signin:PrincipalArn`supporta i tipi di utente root, utente IAM e ruoli principali. `aws:PrincipalArn`supporta tutti i tipi principali (utente root, utente IAM, utente federato, ruolo). ## Esempi di policy ### Esempio 1: RCP con perimetro di rete e principali esclusi La seguente politica di controllo delle risorse (RCP) Console di gestione AWS nega l'accesso dall'esterno della rete aziendale a tutti gli account dell'organizzazione. I principali esclusi designati sono esentati dall'accesso di emergenza. Poiché gli ID VPC sono unici solo all'interno di una regione, la policy include una terza dichiarazione che associa VPC-based l'accesso alla regione prevista. La `EnforceNetworkPerimeterPreAuth` dichiarazione viene utilizzata `signin:PrincipalArn` per esentare i principali esclusi durante la fase di preautenticazione. La `EnforceNetworkPerimeterPostAuth` dichiarazione utilizza `aws:PrincipalArn` per esentare i principali esclusi dopo l'autenticazione. L'`EnforceSourceVPCRegion`istruzione garantisce che la regione richiesta corrisponda alla regione VPC, limitando l'accesso alla regione prevista per il VPC specificato. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "EnforceNetworkPerimeterPreAuth", "Effect": "Deny", "Principal": "*", "Action": ["signin:Authenticate"], "Resource": "*", "Condition": { "ArnNotEquals": { "signin:PrincipalArn": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root", "arn:aws:iam::777788889999:user/EmergencyUser", "arn:aws:iam::777788889999:role/OrgBreakGlassRole" ] }, "NotIpAddressIfExists": { "aws:SourceIp": "" }, "StringNotEquals": { "aws:SourceVpc": "" } } }, { "Sid": "EnforceNetworkPerimeterPostAuth", "Effect": "Deny", "Principal": "*", "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"], "Resource": "*", "Condition": { "ArnNotEquals": { "aws:PrincipalArn": [ "arn:aws:iam::111122223333:root", "arn:aws:iam::444455556666:root", "arn:aws:iam::777788889999:user/EmergencyUser", "arn:aws:iam::777788889999:role/OrgBreakGlassRole" ] }, "NotIpAddressIfExists": { "aws:SourceIp": "" }, "StringNotEquals": { "aws:SourceVpc": "" } } }, { "Sid": "EnforceSourceVPCRegion", "Effect": "Deny", "Principal": "*", "Action": [ "signin:Authenticate", "signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceVpc": "" }, "StringNotEqualsIfExists": { "aws:RequestedRegion": "" } } } ] } ``` Questa politica: + Nega l'accesso alla pagina di accesso a meno che la richiesta non provenga dall'intervallo IP aziendale o dal VPC aziendale. Gli account root e gli utenti IAM esclusi sono esentati tramite (preautenticazione). `signin:PrincipalArn` + Nega lo scambio di token OAuth a meno che non provenga dall'intervallo IP aziendale o dal VPC. Gli account root, gli utenti IAM e i ruoli esclusi sono esentati tramite `aws:PrincipalArn` (chiave globale post-autenticazione). + Se una richiesta proviene dal VPC specificato ma la Regione non corrisponde, l'accesso viene negato. AWS Gli ID VPC sono unici all'interno di una regione e lo stesso ID VPC può esistere in diverse regioni. + Si applica a livello globale in tutta la tua AWS Organization se configurata come RCP. ### Esempio 2: Resource-based policy di IP-based accesso con preside escluso La seguente politica basata sulle risorse nega l'accesso dalla console a tutti i principali che effettuano richieste al di fuori dell'intervallo IP specificato, con l'esenzione per un principale escluso. La policy contiene due istruzioni: una dichiarazione di pre-autenticazione che utilizza la `signin:PrincipalArn` chiave specifica del servizio e un'istruzione post-autenticazione che utilizza la chiave globale. `aws:PrincipalArn` ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": ["signin:Authenticate"], "Resource": "*", "Condition": { "ArnNotEquals": { "signin:PrincipalArn": "" }, "NotIpAddress": { "aws:SourceIp": "" }, "StringEquals": { "aws:ResourceAccount": "" } } }, { "Effect": "Deny", "Principal": { "AWS": "*" }, "Action": ["signin:CreateOAuth2Token", "signin:AuthorizeOAuth2Access"], "Resource": "*", "Condition": { "ArnNotEquals": { "aws:PrincipalArn": "" }, "NotIpAddress": { "aws:SourceIp": "" }, "StringEquals": { "aws:ResourceAccount": "" } } } ] } ``` Questa politica: + Nega l'accesso a tutti i principali a meno che non si connettano dall'intervallo IP. `` + Esonera il principale escluso dalle restrizioni di rete utilizzando `signin:PrincipalArn` (preautenticazione) e `aws:PrincipalArn` (post-autenticazione). + Si applica solo all'account specifico in cui è configurata la politica basata sulle risorse (identificata da). `` ## Best practice ### Configura i principali esclusi per l'accesso al ripristino di emergenza AWS consiglia di configurare almeno un utente escluso prima di applicare le politiche di autorizzazione della console in produzione. Nella fase di preautenticazione, la chiave `signin:PrincipalArn` condizionale esenta l'utente root, l'utente IAM e i responsabili del ruolo. Nella fase successiva all'autenticazione, la chiave `aws:PrincipalArn` condizionale esenta tutti i tipi principali (utente root, utente IAM, utente federato, ruolo). I principali esclusi sono facoltativi, ma la loro omissione aumenta il rischio di blocco dell'account se le condizioni di rete cambiano in modo imprevisto o se le politiche non sono configurate correttamente. Passaggi di configurazione principali esclusi consigliati: 1. Crea un ruolo IAM escluso (ad esempio,). `BreakGlassRole` 1. Per i ruoli esclusi, richiedi l'autenticazione a più fattori nella policy di fiducia dei ruoli. 1. Concedi all'identità esclusa solo le autorizzazioni minime necessarie per il ripristino di emergenza. 1. Includete l'ARN principale escluso nelle dichiarazioni di policy di pre-authentication (`signin:PrincipalArn`) e post-authentication (`aws:PrincipalArn`). 1. Documenta la procedura di ripristino e conservala in modo sicuro all'esterno. AWS 1. Verifica periodicamente l'accesso principale escluso per confermare che funzioni quando necessario. ### Mantieni i percorsi di accesso di ripristino Oltre al principio escluso sopra descritto, assicurati che siano disponibili metodi di accesso alternativi nel caso in cui le politiche di autorizzazione della console blocchino l'accesso in modo imprevisto: + **Role-based accesso programmatico:** le politiche di autorizzazione della console si applicano solo all'accesso interattivo alla console. Non si applicano alle richieste API firmate con SigV4. Se disponi di un accesso programmatico (ad esempio, chiavi di accesso esistenti, un ruolo tra più account), utilizzalo per richiamare `signin:DeleteConsoleAuthorizationConfiguration` e rimuovere la politica di restrizione. Le credenziali devono includere `signin:DeleteConsoleAuthorizationConfiguration` l'autorizzazione (inclusa nella politica gestita). `AWSSignInResourcePolicyManagement` AWS consiglia credenziali temporanee rispetto alle chiavi di accesso utente IAM a lungo termine. Per gli account membro, gli amministratori degli account di gestione possono assumere `OrganizationAccountAccessRole` nell'account membro (`aws sts assume-role`) di ottenere queste credenziali temporanee. + **AWS support recovery:** mantieni aggiornati l'email e il numero di telefono dell'account utente root. Se l'accesso principale escluso e l'accesso programmatico non sono entrambi disponibili, AWS Support può fornire un collegamento al portale di ripristino dopo la verifica dell'identità. Per il processo di ripristino completo, [L'accesso al mio account è bloccato dopo aver abilitato l'autorizzazione della console](#console-access-control-ts-lockout) consulta la sezione. ### Esegui il test prima dell'implementazione in produzione AWS consiglia di non applicare RCP restrittivi alla radice dell'organizzazione senza aver testato a fondo l'impatto che la policy ha sugli account. Create invece un'unità organizzativa in cui spostare i vostri account uno alla volta, o almeno in piccoli numeri, per assicurarvi di non impedire inavvertitamente agli utenti di accedere agli account chiave. Flusso di lavoro di test: 1. Crea un'unica dichiarazione di autorizzazione con le restrizioni di rete principali. 1. Abilita l'autorizzazione della console in un account non di produzione. 1. Verifica l'accesso alla console sia dalle reti consentite che da quelle negate. 1. Esamina CloudTrail i log di Amazon per confermare il comportamento di valutazione delle politiche. 1. Verifica l'accesso utilizzando il tuo principale escluso. 1. Espandi gradualmente a reti e account aggiuntivi. 1. Monitora prima di applicarlo negli account di produzione. ### Progetta con una difesa approfondita Utilizza le politiche AWS Sign-In basate sulle risorse e le politiche di controllo delle risorse come un unico livello all'interno di una strategia di sicurezza più ampia. AWS Sign-In le policy limitano l'accesso alla console in base alla posizione della rete e all'identità principale. Combinale con altri tipi di policy per creare controlli di accesso completi: + **AWS Sign-In policy (policy basate sulle risorse e RCP):** limita l'accesso alla console in base alla posizione della rete e all'identità principale prima, durante e dopo l'autenticazione. + **Politiche IAM:** controlla le azioni che gli utenti possono eseguire dopo l'accesso. + **Policy di controllo dei servizi (SCP):** applica barriere di autorizzazione a livello di organizzazione a tutti i responsabili. + **Policy degli endpoint VPC:** controlla a quali servizi e account è possibile accedere tramite gli endpoint VPC. ### Monitora e verifica continuamente AWS CloudTrail registra automaticamente tutte le valutazioni AWS Sign-In delle politiche e le modifiche alla configurazione. Visualizza questi eventi nella cronologia degli CloudTrail eventi per un massimo di 90 giorni. Per una conservazione più lunga, distribuisci eventi ad Amazon S3 creando un percorso (vedi [Creazione di un percorso](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)). Per gli avvisi in tempo reale, crea EventBridge regole Amazon che corrispondano AWS Sign-In agli eventi, configura il percorso da inviare a un gruppo di log CloudWatch Logs per gli allarmi basati su filtri metrici o inoltra gli eventi alla tua soluzione SIEM esistente. ## Casi d’uso Applicazione del perimetro di rete Limita l'accesso alla console ai VPC aziendali o agli intervalli IP approvati. Utilizza politiche basate sulle risorse per account individuali o politiche di controllo delle risorse (RCP) per applicarle a livello di organizzazione per garantire che gli utenti possano accedere solo da posizioni di rete affidabili, impedendo l'accesso non autorizzato da reti pubbliche o non attendibili. **Scenario di esempio:** un'azienda richiede che tutti gli accessi alla console provengano dalla propria rete aziendale o da VPC approvati. AWS Configurano una politica basata sulle risorse per un singolo account, o un RCP all'interno dell'organizzazione, che nega l'accesso da tutte le altre reti mantenendo al contempo l'accesso per il ripristino di emergenza per gli amministratori di emergenza. Requisiti di conformità Soddisfa i requisiti normativi per i controlli degli accessi basati sulla rete. Molti framework di conformità richiedono alle organizzazioni di limitare l'accesso ai sistemi sensibili in base alla posizione della rete. AWS Sign-In le politiche forniscono controlli verificabili e applicabili che dimostrano la conformità a questi requisiti. **Scenario di esempio:** una società di servizi finanziari deve rispettare le normative che richiedono l'accesso alla console solo da reti approvate. Utilizzano gli RCP per applicare le restrizioni di rete a livello di organizzazione e conservare AWS CloudTrail i log come prova di conformità. Multi-account governance Implementa policy di accesso alla console coerenti in AWS Organizations. Usa gli RCP per applicare le restrizioni di rete standard su tutti gli account dei membri, garantendo un livello di sicurezza coerente senza richiedere una configurazione a livello di account individuale. **Scenario di esempio:** un'azienda con più di 100 AWS account utilizza gli RCP per applicare una policy che richiede che tutti gli accessi alla console provengano dagli endpoint VPC all'interno dell'organizzazione, confermando controlli di rete coerenti su tutti gli account. Third-party controllo degli accessi Concedi l'accesso temporaneo alla console a partner o appaltatori da reti specifiche. Le organizzazioni possono creare un accesso alla console limitato nel tempo e limitato alla rete per parti esterne senza compromettere il livello di sicurezza generale. **Scenario di esempio:** un'azienda deve concedere a una società di consulenza l'accesso temporaneo alla console. Creano una policy basata sulle risorse che consente l'accesso solo dagli intervalli IP noti della società di consulenza e solo per i ruoli IAM assegnati ai consulenti. Limita l'accesso alla console a principali specifici Consenti solo a un insieme definito di principali di accedere a e nega tutti gli altri Console di gestione AWS, indipendentemente dalla posizione della rete. Ciò è utile per i clienti che non utilizzano endpoint VPC e desiderano restrizioni della console basate sull'identità. I principali a cui viene negato l'accesso alla console mantengono l'accesso programmatico; AWS Sign-In le policy limitano solo l'accesso alla console e solo i principali esentati possono accedere. **Scenario di esempio:** un'azienda desidera che solo i suoi amministratori utilizzino la console. Configurano un RCP che nega l'accesso alla console per tutti i principali server ad eccezione degli ARN principali dell'amministratore. Un ruolo di istanza Amazon EC2 con credenziali valide non può accedere alla console, perché non è un principale esente, anche se mantiene le sue autorizzazioni programmatiche. Questo risolve il caso comune in cui le credenziali del ruolo di istanza vengono utilizzate per l'accesso alla console. ## Risoluzione dei problemi di controllo dell'accesso alla console ### Non riesco ad accedere a causa delle condizioni di rete nelle politiche Sign-in basate sulle risorse È possibile che venga visualizzato uno dei seguenti messaggi di errore quando l'accesso viene negato da una politica: AWS Sign-In + «Le informazioni di autenticazione non sono corrette. Riprova.» (negazione della preautenticazione in base a una politica basata sulle risorse) + «Autenticazione fallita Richiesta non valida» (negazione della preautenticazione da parte di RCP) + «Autenticazione non riuscita: per accedere a questo account, accedi da una rete diversa o contatta l'amministratore per ulteriori informazioni» (rifiuto dopo l'autenticazione) Se riscontri uno di questi errori e ritieni che il tuo accesso debba essere consentito, contatta l'amministratore AWS . Possono esaminare CloudTrail i registri `ConsoleLogin` degli eventi con `errorMessage` «Autorizzazione negata a causa di una politica basata sulle risorse» o «Autorizzazione negata a causa di una politica di controllo delle risorse» per identificare a quale dichiarazione politica è stato negato l'accesso. **Possibili cause:** + L'indirizzo IP di origine non rientra nell'intervallo CIDR consentito. + Non sei connesso al VPC o all'endpoint VPC richiesto. + Stai accedendo a un endpoint di accesso regionale che non corrisponde alla regione prevista nella policy. + L'ARN principale non è elencato correttamente tra i principali esclusi della politica. + La politica è stata aggiornata di recente e la modifica non è stata ancora replicata a livello globale. **Risoluzione:** + Verifica di essere connesso alla rete aziendale o alla VPN. + Verifica che stai accedendo tramite l'endpoint VPC corretto se sono configurate le restrizioni basate sugli endpoint VPC. + Contatta l' AWS amministratore per verificare la configurazione delle policy e confermare quali reti sono autorizzate. + Se sei configurato come principale escluso, verifica che il tuo ARN principale sia configurato correttamente nell'elenco dei principali esclusi. + Se di recente sono state apportate modifiche alle policy, attendi qualche minuto per il completamento della replica globale. **Per gli amministratori che diagnosticano questo problema:** + AWS CloudTrail Esamina i registri degli eventi di valutazione delle politiche per identificare a quale dichiarazione politica è stato negato l'accesso. + Utilizzare `aws signin get-resource-policy` per esaminare la configurazione corrente delle politiche. + Verifica che la posizione di rete dell'utente corrisponda alle condizioni della politica. + Verifica che i principali esclusi siano configurati correttamente se l'utente deve essere esentato dalle restrizioni di rete. ### L'accesso al mio account è bloccato dopo aver abilitato l'autorizzazione della console Se hai configurato l'autorizzazione della console e non riesci più ad accedere al tuo account, potresti non aver configurato i principali esclusi prima di applicare la politica. Esistono diversi percorsi per riottenere l'accesso, a seconda del tipo di account e delle credenziali disponibili. **Opzione 1: utilizzare l'accesso programmatico (AWS CLI o SDK)** Le politiche di autorizzazione della console si applicano solo all'accesso interattivo alla console. Non si applicano alle richieste API firmate con SigV4. Se disponi di un accesso programmatico (ad esempio, chiavi di accesso esistenti, un ruolo tra più account), utilizzalo per richiamare `signin:DeleteConsoleAuthorizationConfiguration` e rimuovere la politica di restrizione. Le credenziali utilizzate devono disporre dell'autorizzazione per la chiamata. `signin:DeleteConsoleAuthorizationConfiguration` La politica `AWSSignInResourcePolicyManagement` gestita include questa autorizzazione. AWS consiglia credenziali temporanee anziché chiavi di accesso utente IAM a lungo termine. Per gli account membro, gli amministratori degli account di gestione possono assumere `OrganizationAccountAccessRole` nell'account membro di ottenere credenziali temporanee. Questo ruolo non viene creato automaticamente negli account che sono stati invitati a far parte dell'organizzazione. ``` aws signin delete-console-authorization-configuration \ --target-id \ --region us-east-1 ``` Oppure elimina dichiarazioni di autorizzazione specifiche: ``` # First, list statements to get the statement ID aws signin list-resource-permission-statements \ --region us-east-1 # Then delete the problematic statement aws signin delete-resource-permission-statement \ --statement-id \ --region us-east-1 ``` **Opzione 2: Contatta l' AWS assistenza** Se non disponi dell'accesso programmatico e non puoi utilizzarlo `OrganizationAccountAccessRole` per l'accesso all'account, contatta l' AWS assistenza per avviare il processo di ripristino del blocco. Il processo di ripristino funziona nel modo seguente: 1. Se non riesci a risolvere il problema utilizzando le opzioni sopra riportate, apri una richiesta di assistenza presso il AWS Support Center. AWS Support verificherà la tua identità prima di esaminare il tuo account. I metodi di verifica possono includere la conferma dell'indirizzo e-mail dell'account utente root, la risposta a una chiamata di verifica telefonica o la risposta alle domande di sicurezza dell'account. 1. AWS Support conferma che il problema di accesso alla console è causato da un blocco delle policy basato sulle risorse. 1. AWS Support condivide un link al portale di ripristino. Utilizza questo link per accedere con un responsabile IAM nell'account che dispone dell'`signin:DeleteConsoleAuthorizationConfiguration`autorizzazione. Questa autorizzazione consente al principale di eliminare la configurazione di autorizzazione della console che causa il blocco. **Importante** Il portale di ripristino rimuove l'intera configurazione di autorizzazione della console per l'account, incluse tutte le istruzioni di autorizzazione delle risorse. Il portale di ripristino non consente la riconfigurazione delle politiche basate AWS Sign-In sulle risorse. Il link al portale di ripristino scade 72 ore dopo la condivisione da parte di AWS Support. Se non completi il ripristino entro quella finestra, contatta l' AWS assistenza per riavviare il processo. **Dopo aver riacquistato l'accesso:** + Rivedi e aggiorna le istruzioni di autorizzazione delle risorse per includere i principali esclusi configurati correttamente. + Verifica l'accesso alla console dalle reti previste prima di riattivare l'autorizzazione della console. + Documenta le tue procedure di ripristino per riferimenti futuri. ### Le modifiche che apporto non sono sempre immediatamente visibili Le modifiche alle policy si replicano a livello globale, ma la replica può richiedere alcuni minuti. **Risoluzione:** + Dopo aver apportato le modifiche alle policy, attendi qualche minuto per completare la replica globale. + Verifica le modifiche utilizzando il `get-resource-policy` comando: ``` aws signin get-resource-policy --region ``` + Controlla AWS CloudTrail i log per verificare la presenza di eventi di valutazione delle politiche per confermare che la nuova politica è in fase di valutazione. + Conferma di utilizzare la regione corretta per le operazioni (le operazioni di scrittura devono essere utilizzate`us-east-1`). + Se utilizzi condizioni basate su endpoint VPC, verifica che anche le policy degli endpoint VPC siano configurate correttamente. **Problemi comuni di replica delle policy:** + Pagina di **accesso memorizzata nella cache: i browser possono memorizzare nella cache la pagina** di accesso. Svuota la cache del browser o utilizza una finestra di navigazione in incognito per testare le modifiche alle politiche. + **Dichiarazioni in conflitto:** se hai più istruzioni di autorizzazione, conferma che non siano in conflitto tra loro. Utilizzare `get-resource-policy` per rivedere la politica consolidata. + Policy **degli endpoint VPC: le policy** funzionano insieme AWS Sign-In alle policy degli endpoint VPC. Entrambe devono consentire l'accesso desiderato.