Machine-to-machine gestione delle identità

Machine-to-machine L'autenticazione (M2M) consente ai servizi e alle applicazioni eseguiti su AWS di comunicare in modo sicuro tra loro per accedere a risorse e dati. Invece di utilizzare credenziali statiche a lungo termine, i sistemi di autenticazione delle macchine emettono credenziali o token temporanei per identificare macchine affidabili. Consentono un controllo preciso su quali macchine possono accedere a parti specifiche dell'ambiente senza l'intervento umano. Un'autenticazione automatica ben progettata aiuta a migliorare il livello di sicurezza limitando l'ampia esposizione delle credenziali, abilitando la revoca dinamica delle autorizzazioni e semplificando la rotazione delle credenziali. I metodi tipici per l'autenticazione automatica includono i profili di EC2 istanza, la concessione delle credenziali del client Amazon Cognito, le connessioni TLS (MTLS) con autenticazione reciproca e IAM Roles Anywhere. Questa sezione fornisce indicazioni sull'implementazione di flussi di autenticazione M2M sicuri e scalabili su AWS.

EC2 profili di istanza

Per gli scenari in cui hai un'applicazione o un servizio in esecuzione su Amazon Elastic Compute Cloud (Amazon EC2) che deve chiamare AWS APIs, prendi in considerazione l'utilizzo di profili di EC2 istanza. I profili di istanza consentono alle applicazioni eseguite su EC2 istanze di accedere in modo sicuro ad altri servizi AWS senza richiedere chiavi di accesso IAM statiche e di lunga durata. Invece, dovresti assegnare un ruolo IAM alla tua istanza per fornire le autorizzazioni richieste tramite il profilo dell'istanza. L' EC2 istanza può quindi ottenere automaticamente credenziali di sicurezza temporanee dal profilo dell'istanza per accedere ad altri servizi AWS. 

Il diagramma seguente illustra questo scenario.

1. Un'applicazione sull' EC2 istanza che deve chiamare un'API AWS recupera le credenziali di sicurezza fornite dal ruolo dall'elemento di metadati dell'istanza. iam/security-credentials/<role-name> 

2. L'applicazione riceve il AccessKeyIdSecretAccessKey, e un token segreto che può essere utilizzato per firmare le richieste API AWS.

3. L'applicazione richiama un'API AWS. Se il ruolo consente l'azione dell'API, la richiesta ha esito positivo.

Per ulteriori informazioni sull'utilizzo di credenziali temporanee con le risorse AWS, consulta Using temporary credentials with AWS resources nella documentazione IAM.

Vantaggi

• Sicurezza migliorata. Questo metodo evita la distribuzione di credenziali a lungo termine alle EC2 istanze. Le credenziali vengono fornite temporaneamente tramite il profilo dell'istanza. 

• Integrazione semplice. Le applicazioni eseguite sull'istanza possono ottenere automaticamente le credenziali senza alcuna codifica o configurazione aggiuntiva. AWS utilizza SDKs automaticamente le credenziali del profilo dell'istanza.

• Autorizzazioni dinamiche. Puoi modificare le autorizzazioni disponibili per l'istanza aggiornando il ruolo IAM assegnato al profilo dell'istanza. Le nuove credenziali che riflettono le autorizzazioni aggiornate vengono ottenute automaticamente. 

• Rotazione. AWS ruota automaticamente le credenziali temporanee per ridurre il rischio di compromissione delle credenziali. 

• Revoca. È possibile revocare immediatamente le credenziali rimuovendo l'assegnazione del ruolo dal profilo dell'istanza.

Considerazioni di natura progettuale

• A un' EC2 istanza può essere associato un solo profilo di istanza.

• Utilizza i ruoli IAM con privilegi minimi. Assegna solo le autorizzazioni richieste dall'applicazione al ruolo IAM per il profilo dell'istanza. Inizia con le autorizzazioni minime e aggiungi altre autorizzazioni in un secondo momento, se necessario. 

• Utilizza le condizioni IAM nella politica del ruolo per limitare le autorizzazioni in base a tag, intervalli di indirizzi IP, ora del giorno e così via. Ciò limita i servizi e le risorse a cui l'applicazione può accedere.

• Considerate quanti profili di istanza avete bisogno. Tutte le applicazioni eseguite su un' EC2 istanza condividono lo stesso profilo e dispongono delle stesse autorizzazioni AWS. Puoi applicare lo stesso profilo di istanza a più EC2 istanze, in modo da ridurre il sovraccarico amministrativo riutilizzando i profili di istanza ove appropriato.

• Monitora l'attività. Utilizza strumenti come AWS CloudTrail per monitorare le chiamate API che utilizzano le credenziali del profilo di istanza. Fai attenzione alle attività insolite che potrebbero indicare credenziali compromesse. 

• Elimina le credenziali non necessarie. Rimuovi le assegnazioni di ruolo dai profili di istanza non utilizzati per impedire l'uso di credenziali. Puoi utilizzare IAM Access Advisor per identificare i ruoli non utilizzati. 

• Utilizza l'PassRoleautorizzazione per limitare il ruolo che un utente può assegnare a un' EC2 istanza quando avvia l'istanza. Ciò impedisce all'utente di eseguire applicazioni con più autorizzazioni di quelle concesse all'utente.

• Se la tua architettura si estende su più account AWS, considera in che modo EC2 le istanze di un account potrebbero dover accedere alle risorse di un altro account. Usa i ruoli tra account in modo appropriato per garantire un accesso sicuro senza dover incorporare credenziali di sicurezza AWS a lungo termine.

• Per gestire i profili delle istanze su larga scala, puoi utilizzare una di queste opzioni:

  • Usa i runbook di AWS Systems Manager Automation per automatizzare l'associazione dei profili di istanza alle EC2 istanze. Questa operazione può essere eseguita al momento del lancio o dopo l'esecuzione di un'istanza.

  • Usa AWS CloudFormation per applicare i profili di istanza alle EC2 istanze in modo programmatico al momento della creazione, anziché configurarle tramite la console AWS.

• È buona norma utilizzare gli endpoint VPC per connettersi privatamente ai servizi AWS supportati come Amazon S3 e Amazon DynamoDB da applicazioni eseguite su istanze. EC2 

Concessione delle credenziali del cliente Amazon Cognito

Amazon Cognito è un servizio gestito di gestione delle identità e degli accessi dei clienti. Amazon Cognito fornisce flussi OAuth di autenticazione conformi, inclusa la possibilità di autenticare macchine o applicazioni anziché utenti tramite il tipo di concessione delle credenziali client. Questa concessione consente a un'applicazione di recuperare direttamente le credenziali AWS temporanee per accedere ai servizi AWS. Le credenziali del client Amazon Cognito sono un modo sicuro per fornire autorizzazioni AWS alle applicazioni senza l'interazione umana dell'utente. Le applicazioni presentano l'ID client e il segreto del client all'endpoint del token Amazon Cognito. In cambio, ricevono un token di accesso, che possono utilizzare per autenticare le richieste successive a varie risorse e servizi. L'ambito di questo accesso è dettato dalle autorizzazioni associate all'ID client. L'applicazione che riceve la richiesta deve convalidare il token controllandone la firma, il timestamp di scadenza e il pubblico. Dopo questi controlli, l'applicazione verifica che l'azione richiesta sia consentita convalidando le attestazioni nel token.

Il diagramma seguente illustra questo metodo.

1. L'applicazione (App Client) che desidera richiedere risorse da un server (Resource Server) richiede un token da Amazon Cognito.

2. I pool di utenti di Amazon Cognito restituiscono un token di accesso.

3. App Client invia una richiesta a Resource Server e include il token di accesso.

4. Resource Server convalida il token con Amazon Cognito.

5. Se la convalida ha esito positivo e l'azione richiesta è consentita, Resource Server risponde con la risorsa richiesta.

Vantaggi

• Autenticazione della macchina. Questo metodo non richiede il contesto o gli accessi dell'utente. L'applicazione si autentica direttamente con i token.

• Credenziali a breve termine. Le applicazioni possono ottenere prima un token di accesso da Amazon Cognito e quindi utilizzare il token di accesso temporizzato per accedere ai dati dal server di risorse.

• OAuth2 supporto. Questo metodo riduce le incongruenze e aiuta lo sviluppo di applicazioni perché segue lo standard stabilito OAuth2 .

• Sicurezza avanzata. L'utilizzo della concessione delle credenziali del client offre una maggiore sicurezza, poiché l'ID client e il segreto del client non vengono trasferiti al server di risorse, a differenza di un meccanismo di autorizzazione delle chiavi API. L'ID client e il segreto vengono condivisi e utilizzati solo quando si effettuano chiamate ad Amazon Cognito per ottenere token di accesso limitati nel tempo.

• Controllo granulare degli accessi tramite scope. L'applicazione può definire e richiedere ambiti e rivendicazioni aggiuntive per limitare l'accesso solo a risorse specifiche.

• Traccia di controllo. Puoi utilizzare le informazioni raccolte da CloudTrail per determinare la richiesta effettuata ad Amazon Cognito, l'indirizzo IP da cui è stata effettuata la richiesta, chi ha effettuato la richiesta, quando è stata effettuata e ulteriori dettagli. 

Considerazioni di natura progettuale

• Definisci e limita attentamente l'ambito di accesso per ogni ID client al minimo richiesto. Gli ambiti ristretti aiutano a ridurre le potenziali vulnerabilità e garantiscono che i servizi abbiano accesso solo alle risorse necessarie. 

• Proteggi client IDs e segreti utilizzando servizi di storage sicuri come AWS Secrets Manager per archiviare le credenziali. Non inserire le credenziali nel codice sorgente.

• Monitora e verifica le richieste e l'utilizzo dei token con strumenti come CloudTrail e CloudWatch. Presta attenzione ai modelli di attività imprevisti che potrebbero indicare problemi. 

• Automatizza la rotazione dei segreti dei clienti secondo una pianificazione regolare. Ad ogni rotazione, crea un nuovo client applicativo, elimina il vecchio client e aggiorna l'ID e il segreto del client. Facilita queste rotazioni senza interrompere le comunicazioni di servizio. 

• Applica limiti di velocità alle richieste degli endpoint dei token per aiutare a prevenire attacchi di abuso e denial of service (DoS). 

• Prepara una strategia per revocare i token in caso di violazione della sicurezza. Sebbene i token abbiano una vita breve, i token compromessi devono essere invalidati immediatamente.

• Usa AWS CloudFormation per creare in modo programmatico i pool di utenti Amazon Cognito e i client di applicazioni che rappresentano le macchine che devono autenticarsi su altri servizi.

• Se del caso, memorizza i token nella cache per garantire l'efficienza delle prestazioni e l'ottimizzazione dei costi.

• Assicurati che la scadenza dei token di accesso sia in linea con il livello di sicurezza della tua organizzazione.

• Se utilizzi un server di risorse personalizzato, verifica sempre il token di accesso per assicurarti che la firma sia valida, che il token non sia scaduto e che siano presenti gli ambiti corretti. Se necessario, verifica eventuali reclami aggiuntivi.

• Per gestire le credenziali dei clienti su larga scala, puoi utilizzare una di queste opzioni:

  • Centralizza la gestione di tutte le credenziali dei clienti in un'unica istanza centralizzata di Amazon Cognito. Ciò può ridurre il sovraccarico di gestione di più istanze di Amazon Cognito e semplificare la configurazione e il controllo. Tuttavia, assicurati di pianificare la scalabilità e di considerare le quote del servizio Amazon Cognito.

  • Federa la responsabilità delle credenziali dei clienti agli account di carico di lavoro e consenti più istanze di Amazon Cognito. Questa opzione favorisce la flessibilità ma può aumentare i costi generali e la complessità complessiva rispetto all'opzione centralizzata.

Connessioni MTLS

L'autenticazione TLS reciproca (mTLS) è un meccanismo che consente al client e al server di autenticarsi tra loro prima di comunicare utilizzando certificati con TLS. I casi d'uso più comuni per gli MTL includono settori con normative elevate, applicazioni Internet of Things (IoT) e applicazioni business-to-business (B2B). Amazon API Gateway attualmente supporta MTL oltre alle opzioni di autorizzazione esistenti. Puoi abilitare gli MTL su domini personalizzati per l'autenticazione con REST e HTTP regionali. APIs Le richieste possono essere autorizzate utilizzando Bearer, JSON Web Tokens (JWTs) o firmare le richieste con autorizzazione basata su IAM. 

Il diagramma seguente mostra il flusso di autenticazione mTLS per un'applicazione in esecuzione su un' EC2 istanza e un'API configurata su Amazon API Gateway.

1. API Gateway richiede un certificato pubblicamente affidabile direttamente da AWS Certificate Manager (ACM).

2. ACM genera il certificato dalla propria autorità di certificazione (CA).

3. Il client che chiama l'API presenta un certificato con la richiesta API.

4. API Gateway verifica il bucket di Amazon S3 trust store che hai creato. Questo bucket contiene i certificati X.509 di cui ti fidi per accedere alla tua API. Affinché API Gateway proceda con la richiesta, l'emittente del certificato e l'intera catena di fiducia fino al certificato CA principale devono trovarsi nel tuo trust store.

5. Se il certificato dei client è attendibile, API Gateway approva la richiesta e chiama il metodo.

6. L'azione API associata (in questo caso, una funzione AWS Lambda) elabora la richiesta e restituisce una risposta che viene inviata al richiedente.

Vantaggi

• Autenticazione M2M. I servizi si autenticano l'un l'altro direttamente invece di utilizzare segreti o token condivisi. Ciò elimina la necessità di archiviare e gestire credenziali statiche.

• Protezione contro le manomissioni. La crittografia TLS protegge i dati in transito tra i servizi. Le comunicazioni non possono essere lette o alterate da terze parti. 

• Integrazione semplice. Il supporto mTLS è integrato nei principali linguaggi e framework di programmazione. I servizi possono abilitare gli MTL con modifiche minime al codice. 

• Autorizzazioni granulari. I servizi si affidano solo a certificati specifici, il che consente un controllo granulare sui chiamanti autorizzati. 

• Revoca. I certificati compromessi possono essere revocati immediatamente in modo che non siano più affidabili, impedendo ulteriori accessi. 

Considerazioni di natura progettuale

• Quando utilizzi API Gateway:

  • Per impostazione predefinita, i client possono chiamare la tua API utilizzando l'execute-apiendpoint generato da API Gateway per la tua API. Per garantire che i clienti possano accedere alla tua API solo utilizzando un nome di dominio personalizzato con MTL, disabilita questo endpoint predefinito. Per ulteriori informazioni, consulta Disabilitazione dell'endpoint predefinito per un'API REST nella documentazione di API Gateway.

  • API Gateway non verifica se i certificati sono stati revocati.

  • Per configurare MTL per un'API REST, devi utilizzare un nome di dominio personalizzato regionale per la tua API, con una versione TLS minima di 1.2. mTLS non è supportato per le applicazioni private. APIs

• Puoi emettere certificati per API Gateway dalla tua CA o importarli da AWS Private Certificate Authority.

• Crea processi per emettere, distribuire, rinnovare e revocare in modo sicuro i certificati di servizio. Automatizza l'emissione e il rinnovo ove possibile. Se un lato della tua comunicazione M2M è un gateway API, puoi integrarlo con AWS Private CA.

• Proteggi l'accesso alla CA privata. La compromissione della CA compromette la fiducia in tutti i certificati emessi.

• Archivia le chiavi private in modo sicuro e separato dai certificati. Ruota periodicamente i tasti per limitare l'impatto in caso di compromissione.

• Revoca immediatamente i certificati quando non sono più necessari o se sono compromessi. Distribuisci gli elenchi di revoca dei certificati ai servizi. 

• Ove possibile, emetti certificati destinati solo a scopi o risorse specifici per limitarne l'utilità in caso di compromissione.

• Predisponi di piani di emergenza per le scadenze e le interruzioni dei certificati dell'infrastruttura CA o della lista di revoca dei certificati (CRL). 

• Monitora il sistema per individuare eventuali errori e interruzioni dei certificati. Fai attenzione ai picchi di errori che potrebbero indicare problemi.

• Se utilizzi AWS Certificate Manager (ACM) con AWS Private CA, puoi usare AWS CloudFormation per richiedere in modo programmatico certificati pubblici e privati.

• Se utilizzi ACM, usa AWS Resource Access Manager (AWS RAM) per condividere il certificato da un account di sicurezza all'account del carico di lavoro.

IAM Roles Anywhere

Ti consigliamo di utilizzare IAM Roles Anywhere per la gestione delle identità M2M quando macchine o sistemi devono connettersi ai servizi AWS ma non supportano i ruoli IAM. IAM Roles Anywhere è un'estensione di IAM che utilizza un'infrastruttura a chiave pubblica (PKI) per concedere l'accesso ai carichi di lavoro utilizzando credenziali di sicurezza temporanee. Puoi utilizzare i certificati X.509, che possono essere emessi tramite una CA o da AWS Private CA, per stabilire un ancoraggio di fiducia tra CA e IAM Roles Anywhere. Come per i ruoli IAM, il carico di lavoro può accedere ai servizi AWS in base alla sua politica di autorizzazione, allegata al ruolo. 

Il diagramma seguente mostra come utilizzare IAM Roles Anywhere per connettere AWS con risorse esterne.

1. Crei un ancoraggio di fiducia per stabilire un rapporto di fiducia tra il tuo account AWS e la CA che emette i certificati per i tuoi carichi di lavoro locali. I certificati vengono emessi da una CA che registri come trust anchor (root of trust) in IAM Roles Anywhere. La CA può far parte del tuo sistema di infrastruttura a chiave pubblica (PKI) esistente oppure può essere una CA creata con AWS Private Certificate Authority e gestita con ACM. In questo esempio, utilizziamo ACM.

2. L'applicazione effettua una richiesta di autenticazione a IAM Roles Anywhere e invia la sua chiave pubblica (codificata in un certificato) e una firma firmata dalla chiave privata corrispondente. L'applicazione specifica anche il ruolo da assumere nella richiesta.

3. Quando IAM Roles Anywhere riceve la richiesta, prima convalida la firma con la chiave pubblica, quindi verifica che il certificato sia stato emesso da un trust anchor. Dopo che entrambe le convalide hanno avuto esito positivo, l'applicazione viene autenticata e IAM Roles Anywhere crea una nuova sessione di ruolo per il ruolo specificato nella richiesta chiamando AWS Security Token Service (AWS STS).

4. Utilizzi lo strumento di supporto alle credenziali fornito da IAM Roles Anywhere per gestire il processo di creazione di una firma con il certificato e per chiamare l'endpoint per ottenere le credenziali di sessione. Lo strumento restituisce le credenziali al processo di chiamata in un formato JSON standard.

5. Utilizzando questo modello di fiducia a ponte tra IAM e PKI, i carichi di lavoro locali utilizzano queste credenziali temporanee (chiave di accesso, chiave segreta e token di sessione) per assumere il ruolo IAM di interagire con le risorse AWS senza bisogno di credenziali a lungo termine. Puoi anche configurare queste credenziali utilizzando l'interfaccia a riga di comando di AWS o AWS. SDKs

Vantaggi

• Nessuna credenziale permanente. Le applicazioni non necessitano di chiavi di accesso AWS a lungo termine con autorizzazioni ampie. 

• Accesso granulare. Le policy determinano quale ruolo IAM può essere assunto per un'entità specifica. 

• Ruoli sensibili al contesto. Il ruolo può essere personalizzato in base ai dettagli dell'entità autenticata.

• Revoca. La revoca delle autorizzazioni di trust impedisce immediatamente a un'entità di assumere un ruolo.

Considerazioni di natura progettuale

• I server devono essere in grado di supportare l'autenticazione basata su certificati. 

• È buona norma bloccare la policy di fiducia da utilizzare aws:SourceArn o aws:SourceAccount per l'account in cui è stato configurato il trust anchor. 

• I tag principali vengono riportati dai dettagli del certificato. Questi includono il nome comune (CN), il nome alternativo dell'oggetto (SAN), l'oggetto e l'emittente.

• Se utilizzi ACM, usa AWS RAM per condividere il certificato da un account di sicurezza all'account del carico di lavoro.

• Utilizza le autorizzazioni del file system del sistema operativo (OS) per limitare l'accesso in lettura all'utente proprietario.

• Non inserire mai le chiavi nel controllo del codice sorgente. Archiviatele separatamente dal codice sorgente per ridurre il rischio di includerle accidentalmente in un set di modifiche. Se possibile, prendi in considerazione l'utilizzo di un meccanismo di archiviazione sicuro.

• Assicurati di disporre di una procedura per ruotare e revocare i certificati.