Commençons par une mise en situation. C’est un lundi matin, on commence la semaine en se connectant à notre VPN. On peut ensuite accéder à nos mails, les salons Teams, se connecter à la console AWS, etc. Un lundi matin banal, me direz-vous ? Une heure passe, et plus de connexion. “Mince, j’ai dû être déconnecté du VPN…” , je suis sûr que cette phrase résonne dans vos oreilles.
Eh oui, le VPN, cet outil que quasiment tout le monde utilise. Et si je vous disais qu’il ne servait plus à rien sur AWS ? Imaginez un monde où l’on peut se connecter de façon sécurisée à nos applications sans passer par un client lourd ? Imaginez si, en plus de ça, on appliquait le principe du zero trust ? Ce n’est pas tout, encore plus loin, si l’on pouvait mettre des restrictions sur le type de support depuis lequel on se connecte, depuis la zone géographique ?
C’est désormais possible, depuis quelques mois, AWS a annoncé son nouveau service AWS Verified Access et je vais aujourd’hui essayer de le décortiquer pour vous.
VPN, qu'est-ce que c'est et pourquoi tout le monde l’utilise ?
Un VPN (Virtual Private Network ou Réseau Privé Virtuel en français), est un service qui permet d’acheminer le trafic web d’un utilisateur vers une destination située sur Internet en passant par un serveur distant sécurisé. Ce serveur distant, sécurisé agit comme un intermédiaire entre l’utilisateur et le réseau internet.
Le fonctionnement d’un VPN n’est pas très compliqué (sauf si l’on rentre vraiment dans les détails).
Lors de l’activation du VPN, une connexion au serveur VPN s’établit. Toutes les données entrantes et sortantes de votre appareil transitent alors dans un tunnel chiffré via un processus d’encapsulation. Le chiffrement permet de sécuriser la connexion en rendant votre trafic illisible. Les données sont effectivement indéchiffrables – sauf pour ceux qui possèdent la clé de chiffrement.
Aucune entreprise ne souhaite que l'accès à ses applications internes soit possible sans restriction. Le protocole https ne suffisant pas ici, on souhaite ajouter une couche de sécurité supplémentaire. En plus de ça, lorsque l’on va désormais arriver sur Internet, l’adresse IP de la personne utilisant le VPN ne sera pas son adresse IP. En effet, la requête de la personne passe par le serveur du VPN. Il y a donc eu un changement d’adresse IP indiquant que la personne est passée par le VPN.
Il est donc possible de restreindre l’accès à nos applications en bridant les adresses IPs entrantes à celle du ou des serveur(s) VPN.
On remarque bien qu’il est super intéressant d’avoir un VPN aujourd’hui. Mais il y a quand même quelques désavantages. En effet, une fois connecté au VPN, il est beaucoup plus facile de nuire à une infrastructure, bien qu’il reste quand même des gardes-fou, mais pas tout le temps (authentification via user/password ou via un SSO). Si une personne mal intentionnée réussit à s’introduire sur un de vos serveurs, qu’en est-il du reste ?
En plus de ça, il est quand même embêtant de tout le temps devoir démarrer son client VPN, se connecter dessus. Sans parler du moment où ce VPN ne fonctionne plus ou alors se déconnecte aléatoirement (timeout de session côté serveur, souci réseau quelconque, etc).
La solution proposée par AWS : Verified Access
L’utilisateur envoie une requête pour accéder à une application. Verified Access va évaluer la requête à l’aide de règles d'accès qui seront attachées soit à une application soit à un groupe d’applications. Si jamais toutes les polices d’accès sont respectées, la requête de l’utilisateur sera acceptée et envoyée vers l’application par un point d’accès géré par Verified Access.
La différence notable entre Verified Access et un VPN est qu’ici chaque requête est évaluée indépendamment de celle d’avant et de la prochaine selon des polices d’accès définies par l’équipe de sécurité.
Verified Access est constitué de plusieurs briques. Voici un schéma tiré de la documentation du service qui décrit une vue de haut niveau du service :
Verified Access instance (1) - Instance qui évalue les requêtes d’applications et autorise ou non l’accès en fonction des critères de sécurité fixés.
Verified Access endpoint (2) - Chaque point de terminaison représente une application.Il existe deux types de point de terminaison possibles, un Load Balancer ou une ENI (Elastic Network Interface).
Verified Access group (3) - Collection de points de terminaison de Verified Access. Il est recommandé de grouper les applications possédant les mêmes critères de sécurité dans un même groupe. Par exemple, les applications pour la partie marketing dans un groupe marketing.
Access Policies (4) - Un ensemble de polices d’accès définies par le client qui permettent de déterminer l’accès ou non à une application. Cela peut être une combinaison de différentes choses comme l’identité de l’utilisateur souhaitant accéder à l'application, les propriétés du support qu’il utilise (OS, navigateurs, mise à jour,...), la localisation de la personne par exemple. On peut attribuer une police d’accès à un groupe pour qu’elle englobe un ensemble d’applications et par la suite, appliquer une police à une application spécifique de ce groupe pour avoir plus de finesse sur celle-ci.
Trust Providers (5) - Un service qui se charge de l’identité des utilisateurs (comme IAM identity center par exemple ou vôtre IdP (identity provider ou fournisseur d’identité) on prem) ou de la compliance pour la sécurité des appareils. AWS travaille d’ailleurs avec ses propres services évidemment, mais aussi avec des services tiers (dont vous, possiblement en tant qu’IdP) et d'autres notamment pour les metadatas concernant la compliance du support utilisé notamment. Il est obligatoire pour utiliser le service d’avoir un Trust Provider que l’on attache à une Verified Access instance.
Trust data (4) - La donnée qui transite entre le Trust Provider et AWS Verified Access. Cette donnée peut être une adresse mail, une adresse IP, le navigateur utilisé, votre localisation,...
Verified Access va ensuite confronter cette donnée avec les polices d’accès définies par l’utilisateur quand il reçoit une demande d’accès à une application.
Pour la suite de l’article, j’aimerais rentrer dans les détails sur quatre points qui m'ont parus importants du point de vue d’une entreprise qui souhaiterait faire une migration vers AWS Verified Access : les Access Policies, les Trust Providers, le monitoring et la sécurité. En effet, les VPN étant déjà souvent en place dans les entreprises, on aimerait savoir comment coupler ce qui existe déjà avec le service. De plus, quelques lignes sont aussi nécessaires sur la façon d’écrire les polices d’accès et leur formalisme ainsi que la partie monitoring et sécurité.
Il est vrai que je n’ai même pas parlé de la partie gestion de l’infrastructure, on crée une Verified Access Instance et après ? Et bien après, c’est AWS qui s’occupe de tout derrière. C’est un service managé, donc voici pourquoi je ne parlerais pas de ce sujet.
Vous payez d’ailleurs seulement à ce que vous consommez. Pour les endpoints, je ne vais pas m’attarder dessus. C’est AWS qui se charge de gérer la redirection vers votre application depuis le service. Un CNAME sera créé par AWS en interne pour faire la redirection entre l’endpoint et votre application si la requête est autorisée.
Trust Providers, comment migrer le legacy ?
Nous avons vu qu’il fallait obligatoirement un trust provider pour pouvoir utiliser le service Verified Access. Ce trust provider pouvait prendre deux formes, une pour l’identité des utilisateurs (Identity Provider, IdP par la suite) ou une pour la gestion des supports utilisés pour acceder à nos applications (ordinateurs, tablettes, smartphones,...).
Concentrons-nous dans un premier temps sur la partie identité des utilisateurs, c’est souvent celle qui nous intéresse le plus.
Trois cas différents peuvent exister quand il s’agit de l’identité des utilisateurs pour pouvoir utiliser le service Verified Access :
- Vous utilisez déjà IAM Identity Center (successeur de AWS Single Sign-on) et vous utilisez déjà ce service en tant qu’IdP. Il vous faut juste connecter IAM Identity Center avec Verified Access et le tour est joué.
- Vous n’utilisez pas IAM Identity Center et vous avez déjà un IdP on-prem. Il n’y a rien de plus simple, il vous faudra créer votre espace sous IAM Identity Center. Vous pourrez ensuite connecter le service avec votre IdP on-prem facilement. Il est aussi possible d’utiliser un Active Directory en tant qu’IdP. Il ne vous reste plus qu’à connecter Verified Access avec IAM Identity Center et le tour est joué.
- Vous ne souhaitez pas utiliser le service IAM Identity Center et vous avez déjà un IdP on-prem ? Très bien, pas de problème encore une fois, si cet IdP est compatible avec le protocole OpenID Connect (OIDC), vous pouvez directement connecter le service Verified Access avec votre IdP on-prem via le protocole OIDC. Cela demandera un petit peu de configuration, mais c’est possible.
Qu’en est-il désormais de la gestion des supports ?
Verified Access permet la gestion des supports à l’aide de services externes. A l’écriture de cet article, 2 services sont supportés pour le moment : Jamf et CrowdStrike.
Cette liste va certainement s’agrandir, car lors de la présentation du service à Re:Invent (https://www.youtube.com/watch?v=Kkxn-bAIlnI), un point fort du service que AWS a voulu faire ressortir est qu’il souhaite en faire un service “open”. Soit intégrer le plus de solution externe fiable possible, car ce besoin est très souvent remonté aux oreilles d’AWS. Nous y reviendrons plus tard, mais la partie monitoring est remplie d’intégration avec des solutions externes utilisées partout.
Access Policies, à quoi ça ressemble ?
Les polices d’accès utilisées dans le service Verified Access sont écrites dans un langage propriétaire d’AWS : Cedar (https://www.cedarpolicy.com/).
Avant même de voir des exemples de police d’accès, il est important de dire que si vous créez une application et que vous commencez à utiliser Verified Access, la règle par défaut est celle du Zero Trust Policy : tout est refusé par défaut. En effet, à l’image du principe du moindre privilège des polices IAM, on souhaite que nôtre utilisateur ait accès seulement à ce dont il a besoin et pas plus. On ne veut pas qu’une personne puisse escalader certains privilèges, car nous avons des stratégies d’accès trop permissives.
Maintenant que les bases sont posées, il est temps de découvrir comment est structurée une police d’accès écrite en Cedar.
Effect - Permet de savoir si la police qui suit permet d'autoriser (ALLOW) ou non (DENY) au regard de la suite de la police.
Scope - C’est ici qu’on va spécifier le principal, les actions et les ressources sur lesquelles la police va faire effet.
Condition clause - Spécifie le contexte dans lequel les effets s’appliquent
Il est très important de noter que dans le cadre des polices d’accès, le champ scope doit toujours être laissé vide. Tout ce qui va nous intéresser est dans la partie “condition clause”, c’est ici que nous aurons accès à l’identité de l’utilisateur ainsi qu’au support qu’il utilise.
On se retrouve avec une police d’accès qui ressemble à cela :
permit(principal,action,resource)
when{
context.<policy-reference-name>.<attribute> &&
context.<policy-reference-name>.<attribute2>
};
On remarque la possibilité d'utiliser des opérateurs, voici la liste de ceux qui sont disponibles :
!, ==, !=, <, <=, >, >=, in, &&, ||, .exists(), has, like, .contains(), .containsAll(), .containsAny()
Si l’on souhaite avoir accès à certaines informations notamment sur le support utilisé par l’utilisateur, il est nécessaire pour celui-ci d’avoir une extension sur son navigateur pour pouvoir transmettre les informations à Verified Access. Néanmoins, pour tout ce qui est une information liée à l’identité de l’utilisateur, il n’y a pas besoin de cette extension de navigateur.
Voyons-voir ce que l’on peut faire au travers de 2 exemples tirés de la documentation d’AWS.
permit(principal,action,resource)
when {
context.identity.groups.contains("finance") &&
context.identity.email_verified == true &&
ip(context.http_request.client_ip).isInRange(ip("10.0.0.0/8"))
};
Ici, on accède à la donnée qui nous intéresse via le mot-clé “context”. Par la suite, il faut savoir que tout ce qui est ajouté dans le champ “http_request” sera présent tout le temps. Il contient certaines informations concernant la requête HTTP tel que l’adresse IP¨du client, la méthode HTTP utilisée, etc (la documentation sur ce sujet est ici : https://docs.aws.amazon.com/verified-access/latest/ug/trust-data-default-context.html)
Le champ “identity” nous permet de savoir que la donnée provient du service IAM Identity Center (et donc, que vous l’utilisez comme IdP). Si vous n’utilisez pas cet IdP, la documentation ne cite pas comment récupérer les champs (sauf pour les services permettant de gérer des supports comme Jamf et CrowdStrike).
Revenons-en à notre exemple, on voit donc ici que l’on va vérifier que le groupe de la personne (récupérer grâce à IAM Identity Center) pour vérifier s'il est bien du groupe “finance”, ensuite s’assurer que le mail qu’il utilise est vérifié et pour finir, que son adresse IP est dans la range 10.0.0.0/8. Si toutes ces informations sont évaluées positivement, la requête de la personne sera acceptée (grâce au mot-clé “permit” tout en haut).
permit(principal,action,resource)
when {
context.crwd.assessment.overall > 50
&& context.jamf.risk == "LOW"
};
Second exemple qui est en fait un combiné de deux exemples de la documentation. On voit ici l’utilisation des mots-clés “crwd” et “jamf”. Ils correspondent au deux services tiers autorisés par AWS pour la partie gestion des supports.
Le premier étant CrowdStrike, caractérisé par le mot-clé “crwd”, dans cet exemple, on va vérifier que la note globale du support utilisé est supérieure à 50. Pour le second qui n’est d’autre que Jamf, lui-même caractérisé par “jamf”, ici on va vérifier que le risque associé au support est égale à “LOW”.
On s’aperçoit donc que le service permet de couvrir une grosse partie de ce que les entreprises souhaitent avoir comme possibilités pour sécuriser l’accès à leurs applications.
Comment on surveille tout ça ? Et la sécurité dans l’histoire ?
Il reste encore un point très important dont nous n’avons pas encore discuté. Parlons de l’aspect monitoring et sécurité. Un VPN étant souvent un goulot d’étranglement et la porte d’entrée pour l’ensemble du trafic vers tout le réseau interne d’une entreprise, il est nécessaire que celui-ci soit très bien monitoré avec une sécurité hermétique.
Pour la partie sécurité, toutes les données dites au repos (“at rest”) sont chiffrées par KMS avec une clé détenue et gérée par le service lui-même. On peut utiliser CloudTrail pour faire un audit de l’utilisation du service. Pour la donnée en transit, le service utilise TLS 1.2 pour la partie chiffrement.
Pour ce qui est de la partie trafic entre plusieurs réseaux, il est possible de configurer Verified Access pour restreindre l’accès à des ressources spécifiques dans un VPC (Virtual Private Cloud). Il est aussi possible de restreindre l’accès à des portions du réseau en fonction du groupe auquel appartient l’utilisateur.
Parlons maintenant de monitoring. AWS a sorti en Août 2022 l’Open Cybersecurity Schema Framework (OCSF). En collaboration avec différents acteurs de l’industrie, ils ont défini un schéma standard de log permettant de mettre ceux qui produisent les logs sur la même vision que ceux qui les consomment. AWS Verified Access utilise aujourd’hui ce format de log pour pouvoir permettre une intégration simplifiée avec des services de monitoring mondialement reconnu, dont voici la liste des solutions partenaires (à l’heure actuelle) :
- Datadog
- IBM
- netskope
- new relic
- RAPID7
- sumo logic
- Trellix
- Splunk
Combien ça coûte ?
Certainement l’un des sujets sensibles concernant ce service reste son prix. La facture est divisée en deux, d’un côté, les charges horaires pour chaque application et de l’autre, la donnée qui aura transité pendant l’utilisation du service.
Le prix du service à l’heure par application, sur la région Irlande (eu-west-1), revient à 0,31$/heure par application jusqu’à 148 800 heure par application (ce qui correspond à environ 200 applications par mois, qui tournent tout le temps). Le tarif est inférieur pour les heures par application supérieures à 148 800 et coûte 0.23$/heure ensuite.
La donnée traitée coûte 0,02$/GB.
Si on prend un exemple avec 210 applications qui traite chacune 1 GB de donnée pendant 31 jours, on arrive au calcul suivant :
148 800 * 0,31 + 7 400 * 0,23 + 1 * 210 * 0,02 = 47 834,2 $
Pour conclure
Pour ajouter un avis personnel à ce service, je pense que c’est un service super utile. Je pense qu’il y a de grandes chances que ce genre de service prenne le pas sur les solutions de VPN que l’on connaît actuellement. Au vu de la complexité de maintenir un VPN aujourd’hui, il y a ici un gros gain à apporter (car oui, le VPN qui tombe, c’est une grosse partie du CA de la journée qui part en l’air pour beaucoup d’entreprises avec la démocratisation du télétravail). Ici, le VPN est managé par AWS, on a plus à se soucier de sa robustesse. En plus de ça, la partie police d’accès à l’air d’être très simple d’utilisation, c’est beaucoup plus facile de centraliser les polices et de gérer l’accès à celles-ci à l’aide d’IAM. Donc, forcément, tous ces avantages viennent avec un coût.
Pouvons-nous dire que le VPN ne sert plus à rien ? Pas vraiment. En effet, certains cas d’utilisations seront encore d’actualités je pense. Qu’en est-il de l’accès par SSH à une base de données (une très bonne alternative étant AWS SSM avec le session manager si la ressource est sur AWS) ? L’accès à un NAS ? Le service n’a pas l’air d’être fait pour encore. Reste à voir ce que l’avenir nous réserve.
Si jamais vous êtes intéressé par la mise en place de ce service, j’ai trouvé cet article très bien détaillé : https://medium.com/@chaim_sanders/a-visual-guide-to-setting-up-aws-verified-access-1333466f7222
