Autenticación de AWS Client VPN: os permisos de IAM non son un método de inicio de sesión
Os permisos da consola non autentican un túnel. Compare os métodos de certificado, AD e SAML e despois vexa cando encaixa o redireccionamento de portos por SSM nunha única base de datos privada.
Conceder a un usuario permiso para crear ou describir un punto de conexión de AWS Client VPN non lle permite conectarse a el. Son dous tipos distintos de identidade: IAM goberna as chamadas á API de AWS e o punto de conexión só acepta os métodos de autenticación de cliente configurados nel. Así, un usuario pode ter amplos dereitos na consola e aínda así non ter nada que o cliente VPN poida presentar. Decida que método confía o punto de conexión e despois decida se un túnel completo é a forma axeitada para o acceso que concede.
Unha identidade de API non é unha identidade de túnel
Cando alguén di «o rol de IAM está adxunto, por que segue fallando a VPN», a resposta adoita ser que ningún paso do fluxo de conexión le nunca ese rol. O cliente presenta un certificado, un nome de usuario e un contrasinal de AD, ou unha aserción SAML. O punto de conexión valida un deles e despois asigna un enderezo.
IAM segue importando, só que máis tarde e noutro lugar: crear o punto de conexión, asociar subredes, publicar rutas e escribir regras de autorización son accións de API. Manteña eses permisos limitados aos operadores que os necesitan en lugar de dar a cada usuario a capacidade de reescribir as regras de acceso do punto de conexión.
Elixa entre os métodos que admite o punto de conexión
AWS Client VPN acepta autenticación mutua baseada en certificado, autenticación de Active Directory e autenticación federada baseada en SAML. Requírese un certificado de servidor independentemente do método de cliente que elixa, e unha configuración que combine métodos esixe que ambos teñan éxito, non un.
| 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 |
Os certificados son os máis baratos de implantar e os máis fáciles de equivocar a escala, porque cada usuario necesita unha credencial e cada saída necesita unha revocación. A autenticación de directorio traslada ese ciclo de vida a un sistema existente. A federación trasládao a un provedor de identidade e engade un paso de navegador ao cliente.
Lea a configuración do propio punto de conexión antes de depurar o cliente. Se a autenticación mutua está activada xunto cun método baseado en usuario, un cliente cun certificado válido pero sen conta de directorio seguirá fallando, e o erro adoita parecer un problema xenérico de negociación.
A federación non é pasar claves de acceso
Unha configuración SAML non introduce claves de acceso de IAM nin un token de rol asumido no túnel. O provedor de identidade autentica a persoa, devolve unha aserción e o punto de conexión acéptaa baixo a confianza que vostede configurou. A sesión resultante é unha sesión VPN, non unha sesión da API de AWS.
Esa distinción decide quen pode diagnosticar que. Os problemas do IdP aparecen como un erro de navegador ou de cliente antes de que exista ningún túnel, mentres que os problemas do túnel aparecen despois dunha aserción correcta. Pregunte cal dos dous está a mirar antes de abrir calquera das dúas consolas.
Despois do inicio de sesión, as rutas e a autorización seguen decidindo
A autenticación dálle un enderezo á sesión; non lle dá un destino. As rutas do punto de conexión dinlle ao cliente a que subredes enviar, as regras de autorización deciden que usuarios poden chegar a cales desas subredes, e os grupos de seguridade e os propios permisos do destino deciden o resto.
Por iso un usuario que se autentica correctamente pode seguir sen chegar a unha base de datos. Comprobe a asociación da táboa de rutas para a subrede, a regra de autorización para o grupo do usuario e o grupo de seguridade no destino nesa orde, porque cada un produce un tipo distinto de tempo de espera.
Para unha base de datos privada, compare co redireccionamento de portos
Se a tarefa real é unha conexión aprobada a unha única base de datos privada, un túnel de rede completo é unha opción e non un requisito. AWS Systems Manager Session Manager pode abrir unha sesión de redireccionamento de portos cara a un nodo xestionado mediante IAM, e ese nodo chega á base de datos na rede privada. O usuario nunca recibe un enderezo VPC. O nodo xestionado convértese no único host que pode chegar ao porto da base de datos, que adoita ser o que pedía a revisión de seguridade. Despois, os usuarios necesitan un cliente local e un comando de sesión en lugar dun perfil de VPN.
O intercambio é alcance fronte a requisitos previos. O redireccionamento de portos necesita o axente SSM no nodo xestionado, accesibilidade de rede desde ese nodo ata a base de datos, o complemento de Session Manager na máquina do usuario e permiso para iniciar esa sesión concreta. Non é unha ruta cara a todas as subredes e non transportará protocolos arbitrarios como o fai un túnel.
En calquera caso, manteña a identidade propia da base de datos. A verificación TLS e a autenticación da base de datos non desaparecen porque a ruta fose autorizada mediante IAM, e unha sesión aprobada non di nada sobre que táboas pode ler o usuario.
Elixa segundo o alcance e o ciclo de vida: un túnel cando moitos usuarios necesitan moitos destinos e pode xestionar o ciclo de vida de certificados ou de directorio; unha sesión de redireccionamento cando unha manchea de persoas necesitan un só servizo e prefire non repartir enderezos de rede. En calquera caso, rexistre o método de autenticación, a regra de autorización e o inicio de sesión da base de datos como tres feitos separados, porque fallan por separado.