Autenticazione di AWS Client VPN: le autorizzazioni IAM non sono un metodo di accesso
Le autorizzazioni della console non autenticano un tunnel. Confrontate i metodi con certificato, AD e SAML, poi vedete quando l’inoltro di porta via SSM è adatto a un’unica base di dati privata.
Concedere a un utente l’autorizzazione a creare o descrivere un endpoint di AWS Client VPN non gli consente di connettersi. Sono due tipi diversi di identità: IAM governa le chiamate all’API di AWS e l’endpoint accetta solo i metodi di autenticazione client configurati su di esso. Un utente può quindi avere ampi diritti nella console e comunque non avere nulla che il client VPN possa presentare. Decidete di quale metodo si fida l’endpoint, poi decidete se un tunnel completo sia la forma giusta per l’accesso che state concedendo.
Un’identità API non è un’identità di tunnel
Quando qualcuno dice «il ruolo IAM è collegato, perché la VPN continua a fallire», la risposta di solito è che nessun passaggio del flusso di connessione legge mai quel ruolo. Il client presenta un certificato, un nome utente e una password AD, oppure un’asserzione SAML. L’endpoint convalida uno di questi e poi assegna un indirizzo.
IAM conta ancora, solo più tardi e altrove: creare l’endpoint, associare le sottoreti, pubblicare le rotte e scrivere regole di autorizzazione sono azioni API. Mantenete queste autorizzazioni limitate agli operatori che ne hanno bisogno invece di dare a ogni utente la possibilità di riscrivere le regole di accesso dell’endpoint.
Scegliete tra i metodi supportati dall’endpoint
AWS Client VPN accetta l’autenticazione reciproca basata su certificato, l’autenticazione di Active Directory e l’autenticazione federata basata su SAML. Un certificato server è richiesto indipendentemente dal metodo client scelto, e una configurazione che combina metodi richiede il successo di entrambi, non di uno solo.
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
I certificati sono i più economici da impostare e i più facili da sbagliare su larga scala, perché ogni utente ha bisogno di una credenziale e ogni uscita richiede una revoca. L’autenticazione tramite directory sposta quel ciclo di vita in un sistema esistente. La federazione lo sposta verso un provider di identità e aggiunge un passaggio nel browser al client.
Leggete la configurazione dell’endpoint stesso prima di eseguire il debug del client. Se l’autenticazione reciproca è abilitata accanto a un metodo basato sull’utente, un client con un certificato valido ma senza account di directory fallirà comunque, e l’errore di solito sembra un problema generico di handshake.
La federazione non è il passaggio di chiavi di accesso
Una configurazione SAML non inserisce chiavi di accesso IAM né un token di ruolo assunto nel tunnel. Il provider di identità autentica la persona, restituisce un’asserzione e l’endpoint la accetta nell’ambito della fiducia configurata. La sessione risultante è una sessione VPN, non una sessione dell’API di AWS.
Questa distinzione decide chi può diagnosticare cosa. I problemi di IdP compaiono come errore del browser o del client prima che esista un tunnel, mentre i problemi di tunnel compaiono dopo un’asserzione riuscita. Chiedetevi quale dei due state guardando prima di aprire una delle due console.
Dopo l’accesso, rotte e autorizzazione decidono ancora
L’autenticazione dà un indirizzo a una sessione; non dà una destinazione alla sessione. Le rotte dell’endpoint dicono al client verso quali sottoreti inviare, le regole di autorizzazione decidono quali utenti possono raggiungere quali di queste sottoreti, e i gruppi di sicurezza più le autorizzazioni della destinazione decidono il resto.
Ecco perché un utente che si autentica correttamente può comunque non raggiungere un database. Controllate l’associazione della tabella di routing per la sottorete, la regola di autorizzazione per il gruppo dell’utente e il gruppo di sicurezza sulla destinazione in questo ordine, perché ciascuno produce un tipo diverso di timeout.
Per un’unica base di dati privata, confrontate con l’inoltro di porta
Se il compito reale è una connessione approvata a un’unica base di dati privata, un tunnel di rete completo è una scelta e non un requisito. AWS Systems Manager Session Manager può aprire una sessione di inoltro di porta verso un nodo gestito tramite IAM, e quel nodo raggiunge il database sulla rete privata. L’utente non riceve mai un indirizzo VPC. Il nodo gestito diventa l’unico host in grado di raggiungere la porta del database, che di solito è ciò che la revisione di sicurezza chiedeva. Gli utenti hanno quindi bisogno di un client locale e di un comando di sessione invece di un profilo VPN.
Il compromesso è portata contro prerequisiti. L’inoltro di porta richiede l’agente SSM sul nodo gestito, la raggiungibilità di rete da quel nodo al database, il plugin Session Manager sulla macchina dell’utente e l’autorizzazione ad avviare quella specifica sessione. Non è una rotta verso ogni sottorete e non trasporta protocolli arbitrari come fa un tunnel.
In ogni caso mantenete l’identità propria del database. La verifica TLS e l’autenticazione del database non svaniscono perché il percorso è stato autorizzato da IAM, e una sessione approvata non dice nulla su quali tabelle l’utente possa leggere.
Scegliete in base a portata e ciclo di vita: un tunnel quando molti utenti hanno bisogno di molte destinazioni e potete gestire il ciclo di vita dei certificati o della directory; una sessione di inoltro quando poche persone hanno bisogno di un solo servizio e preferite non distribuire indirizzi di rete. In ogni caso, registrate il metodo di autenticazione, la regola di autorizzazione e l’accesso al database come tre fatti separati, perché falliscono separatamente.