Autenticação no AWS Client VPN: as permissões do IAM não são um método de login
As permissões da consola não autenticam um túnel. Compare os métodos de certificado, AD e SAML e depois veja quando o encaminhamento de portas por SSM se adequa a uma única base de dados privada.
Conceder a um utilizador permissão para criar ou descrever um endpoint do AWS Client VPN não lhe permite ligar-se a ele. São dois tipos distintos de identidade: o IAM governa as chamadas à API da AWS e o endpoint só aceita os métodos de autenticação de cliente configurados nele. Assim, um utilizador pode ter direitos amplos na consola e ainda assim não ter nada que o cliente VPN possa apresentar. Decida em que método o endpoint confia e depois decida se um túnel completo é a forma correta para o acesso que está a conceder.
Uma identidade de API não é uma identidade de túnel
Quando alguém diz «a função do IAM está anexada, porque é que a VPN continua a falhar», a resposta costuma ser que nenhum passo do fluxo de ligação lê essa função. O cliente apresenta um certificado, um nome de utilizador e palavra-passe do AD, ou uma asserção SAML. O endpoint valida um deles e depois atribui um endereço.
O IAM continua a importar, só que mais tarde e noutro lugar: criar o endpoint, associar sub-redes, publicar rotas e escrever regras de autorização são ações de API. Mantenha essas permissões limitadas aos operadores que delas precisam em vez de dar a cada utilizador a capacidade de reescrever as regras de acesso do endpoint.
Escolha entre os métodos que o endpoint suporta
O AWS Client VPN aceita autenticação mútua baseada em certificado, autenticação do Active Directory e autenticação federada baseada em SAML. É necessário um certificado de servidor independentemente do método de cliente escolhido, e uma configuração que combine métodos exige o sucesso de ambos, não de um.
| 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 são os mais baratos de implementar e os mais fáceis de errar em escala, porque cada utilizador precisa de uma credencial e cada saída exige uma revogação. A autenticação por diretório transfere esse ciclo de vida para um sistema existente. A federação transfere-o para um fornecedor de identidade e acrescenta um passo de navegador ao cliente.
Leia a configuração do próprio endpoint antes de depurar o cliente. Se a autenticação mútua estiver ativada ao lado de um método baseado no utilizador, um cliente com um certificado válido mas sem conta de diretório continuará a falhar, e o erro costuma parecer um problema genérico de handshake.
A federação não é passar chaves de acesso
Uma configuração SAML não introduz chaves de acesso do IAM nem um token de função assumida no túnel. O fornecedor de identidade autentica a pessoa, devolve uma asserção e o endpoint aceita-a no âmbito da confiança que configurou. A sessão resultante é uma sessão VPN, não uma sessão da API da AWS.
Essa distinção decide quem pode diagnosticar o quê. Os problemas do IdP aparecem como um erro de navegador ou de cliente antes de existir qualquer túnel, enquanto os problemas do túnel aparecem depois de uma asserção bem-sucedida. Pergunte qual dos dois está a observar antes de abrir qualquer das duas consolas.
Depois do início de sessão, as rotas e a autorização continuam a decidir
A autenticação dá um endereço a uma sessão; não dá um destino à sessão. As rotas do endpoint dizem ao cliente para que sub-redes enviar, as regras de autorização decidem que utilizadores podem alcançar quais dessas sub-redes, e os grupos de segurança e as próprias permissões do alvo decidem o resto.
É por isso que um utilizador que se autentica com sucesso pode ainda assim não alcançar uma base de dados. Verifique a associação da tabela de rotas à sub-rede, a regra de autorização para o grupo do utilizador e o grupo de segurança no alvo por essa ordem, porque cada um produz um tipo diferente de tempo limite.
Para uma base de dados privada, compare com o encaminhamento de portas
Se a tarefa real é uma ligação aprovada a uma única base de dados privada, um túnel de rede completo é uma escolha e não um requisito. O AWS Systems Manager Session Manager pode abrir uma sessão de encaminhamento de portas para um nó gerido através do IAM, e esse nó alcança a base de dados na rede privada. O utilizador nunca recebe um endereço VPC. O nó gerido torna-se o único anfitrião capaz de alcançar a porta da base de dados, que é normalmente o que a revisão de segurança pedia. Os utilizadores passam então a precisar de um cliente local e de um comando de sessão em vez de um perfil VPN.
O compromisso é alcance contra pré-requisitos. O encaminhamento de portas exige o agente SSM no nó gerido, acessibilidade de rede desse nó até à base de dados, o plugin Session Manager na máquina do utilizador e permissão para iniciar essa sessão específica. Não é uma rota para todas as sub-redes e não transporta protocolos arbitrários como um túnel.
Em qualquer caso, mantenha a identidade própria da base de dados. A verificação TLS e a autenticação da base de dados não desaparecem porque o caminho foi autorizado pelo IAM, e uma sessão aprovada não diz nada sobre que tabelas o utilizador pode ler.
Escolha com base no alcance e no ciclo de vida: um túnel quando muitos utilizadores precisam de muitos destinos e pode gerir o ciclo de vida de certificados ou de diretório; uma sessão de encaminhamento quando um punhado de pessoas precisa de um único serviço e prefere não distribuir endereços de rede. Em qualquer caso, registe o método de autenticação, a regra de autorização e o início de sessão na base de dados como três factos separados, porque falham em separado.