Authentification AWS Client VPN : les autorisations IAM ne sont pas une méthode de connexion

Accorder à un utilisateur l’autorisation de créer ou de décrire un point de terminaison AWS Client VPN ne lui permet pas de s’y connecter. Ce sont deux types d’identité différents : IAM régit les appels à l’API AWS, et le point de terminaison n’accepte que les méthodes d’authentification client configurées sur lui. Un utilisateur peut donc disposer de droits étendus dans la console et n’avoir malgré tout rien que le client VPN puisse présenter. Décidez à quelle méthode le point de terminaison fait confiance, puis décidez si un tunnel complet est la bonne forme pour l’accès que vous accordez.

Une identité d’API n’est pas une identité de tunnel

Quand quelqu’un dit « le rôle IAM est attaché, pourquoi le VPN échoue-t-il encore », la réponse est généralement qu’aucune étape du flux de connexion ne lit jamais ce rôle. Le client présente un certificat, un nom d’utilisateur et un mot de passe AD, ou une assertion SAML. Le point de terminaison valide l’un de ces éléments, puis attribue une adresse.

IAM reste important, mais plus tard et ailleurs : créer le point de terminaison, associer des sous-réseaux, publier des routes et écrire des règles d’autorisation sont des actions d’API. Gardez ces autorisations limitées aux opérateurs qui en ont besoin au lieu de donner à chaque utilisateur la possibilité de réécrire les règles d’accès du point de terminaison.

Choisissez parmi les méthodes que le point de terminaison prend en charge

AWS Client VPN accepte l’authentification mutuelle par certificat, l’authentification Active Directory et l’authentification fédérée basée sur SAML. Un certificat de serveur est requis quelle que soit la méthode client choisie, et une configuration qui combine des méthodes exige la réussite des deux, pas d’une seule.

Les certificats sont les moins chers à mettre en place et les plus faciles à rater à grande échelle, car chaque utilisateur a besoin d’un justificatif et chaque départ exige une révocation. L’authentification par annuaire déplace ce cycle de vie vers un système existant. La fédération le déplace vers un fournisseur d’identité et ajoute une étape de navigateur au client.

Lisez la configuration du point de terminaison lui-même avant de déboguer le client. Si l’authentification mutuelle est activée à côté d’une méthode basée sur l’utilisateur, un client doté d’un certificat valide mais sans compte d’annuaire échouera quand même, et l’erreur ressemble généralement à un problème de poignée de main générique.

La fédération n’est pas le passage de clés d’accès

Une configuration SAML n’injecte pas de clés d’accès IAM ni de jeton de rôle assumé dans le tunnel. Le fournisseur d’identité authentifie la personne, renvoie une assertion, et le point de terminaison l’accepte dans le cadre de la confiance que vous avez configurée. La session qui en résulte est une session VPN, pas une session de l’API AWS.

Cette distinction détermine qui peut diagnostiquer quoi. Les problèmes d’IdP apparaissent comme une erreur de navigateur ou de client avant même qu’un tunnel existe, tandis que les problèmes de tunnel apparaissent après une assertion réussie. Demandez lequel des deux vous regardez avant d’ouvrir l’une ou l’autre console.

Après la connexion, les routes et l’autorisation décident encore

L’authentification donne une adresse à une session ; elle ne donne pas de destination à la session. Les routes du point de terminaison indiquent au client vers quels sous-réseaux envoyer, les règles d’autorisation décident quels utilisateurs peuvent atteindre lesquels de ces sous-réseaux, et les groupes de sécurité ainsi que les autorisations propres à la cible décident du reste.

C’est pourquoi un utilisateur qui s’authentifie correctement peut malgré tout échouer à atteindre une base de données. Vérifiez l’association de la table de routage pour le sous-réseau, la règle d’autorisation pour le groupe de l’utilisateur et le groupe de sécurité sur la cible dans cet ordre, car chacun produit un type de délai d’attente différent.

Pour une seule base de données privée, comparez avec la redirection de port

Si la tâche réelle est une connexion approuvée à une seule base de données privée, un tunnel réseau complet est un choix et non une obligation. AWS Systems Manager Session Manager peut ouvrir une session de redirection de port vers un nœud géré via IAM, et ce nœud atteint la base de données sur le réseau privé. L’utilisateur ne reçoit jamais d’adresse VPC. Le nœud géré devient le seul hôte capable d’atteindre le port de la base de données, ce qui est généralement ce que la revue de sécurité demandait. Les utilisateurs ont alors besoin d’un client local et d’une commande de session plutôt que d’un profil VPN.

L’arbitrage oppose la portée aux prérequis. La redirection de port exige l’agent SSM sur le nœud géré, une accessibilité réseau de ce nœud vers la base de données, le plugin Session Manager sur la machine de l’utilisateur et l’autorisation de démarrer cette session précise. Ce n’est pas une route vers chaque sous-réseau, et elle ne transportera pas de protocoles arbitraires comme le fait un tunnel.

Dans tous les cas, conservez l’identité propre à la base de données. La vérification TLS et l’authentification de la base de données ne disparaissent pas parce que le chemin a été autorisé par IAM, et une session approuvée ne dit rien des tables que l’utilisateur peut lire.

Choisissez selon la portée et le cycle de vie : un tunnel quand de nombreux utilisateurs ont besoin de nombreuses destinations et que vous pouvez gérer le cycle de vie des certificats ou de l’annuaire ; une session de redirection quand une poignée de personnes a besoin d’un seul service et que vous préférez ne pas distribuer d’adresses réseau. Dans tous les cas, consignez la méthode d’authentification, la règle d’autorisation et la connexion à la base de données comme trois faits distincts, car ils échouent séparément.