Pourquoi adopter une approche Confiance nulle (Zero Trust)?

Avec la montée fulgurante des cyberattaques, du télétravail ainsi que le transfert des serveurs vers des fournisseurs cloud, il est de plus en plus difficile de sécuriser l’accès aux données et aux ressources requises par les utilisateurs.

Que sont les principes de la Confiance nulle (Zero Trust) ?

Voici les trois principes fondamentaux qui régissent le modèle Confiance nulle (Zero Trust) :

1. Accordez le moins de privilèges possible

En accordant le moins de privilèges et d’accès possible sans affecter la capacité d’une personne à accomplir ses tâches, vous n’accordez l’accès aux ressources qu’au cas par cas, juste ce qui est nécessaire et rien d’autre.

2. N’ayez jamais confiance, vérifiez toujours

Aucune action ou utilisateur n’est intrinsèquement fiable dans un modèle de sécurité Confiance nulle (Zero Trust). Chaque nouvelle entrée dans un système ou demande d’accès à de nouvelles données doit être accompagnée d’une forme d’authentification pour vérifier l’identité de l’utilisateur.

3. Surveillez toujours

Le modèle Confiance nulle (Zero Trust) nécessite une surveillance et une évaluation cohérentes du comportement des utilisateurs, des mouvements de données, des modifications du réseau et des modifications des données. Bien que l’authentification et les restrictions de privilèges soient l’épine dorsale, il est toujours préférable de vérifier toutes les actions effectuées au sein de l’infrastructure de votre organisation.

Est-ce accessible à tous les types d’entreprises?

Il existe plusieurs solutions sur le marché qui permettent de répondre à l’approche Confiance nulle (Zero Trust), certaines plus couteuse que d’autres. Aujourd’hui, nous allons nous concentrer sur une solution qui est accessible à tous, peu importe la taille de votre entreprise.

Voici un graphique qui explique la solution qui sera déployée :

En combinant 3 produits qui offrent des versions gratuites ou à très faible coût, nous seront en mesure de mettre en place une solution à Confiance nulle (Zero Trust).

HashiCorp Vault

HashiCorp Vault permet aux entreprises de stocker, d’accéder et de distribuer de manière centralisée des secrets dynamiques comme les jetons, les mots de passe, les certificats et les clés de chiffrement dans n’importe quel environnement cloud public ou privé. Contrairement aux lourds systèmes basés sur l’ITIL, les solutions HashiCorp fournissent des informations d’identification aux personnes et aux machines de manière dynamique, en créant une solution sûre, efficace et véritablement multi-cloud adaptée au monde de plus en plus incertain d’aujourd’hui.

HashiCorp Boundary

Les solutions traditionnelles de sécurisation des accès des utilisateurs vous demandaient habituellement de distribuer et de gérer des clés SSH, des identifiants VPN et des hôtes bastion, ce qui crée des risques de prolifération des informations d’identification et d’accès des utilisateurs à des réseaux et des systèmes entiers. HashiCorp Boundary sécurise l’accès à des applications et à des systèmes critiques avec des autorisations détaillées qui ne nécessitent pas de gérer les identifiants ou d’exposer l’intégralité de votre réseau.

Microsoft Entra ID (aussi connu sous le nom Microsoft Azure Active Directory)

La majorité des entreprises utilisent maintenant des solutions cloud pour la gestion de leur courriels, calendriers, documents, etc. Afin de s’assurer d’avoir une authentification multi-facteurs à la solution Confiance nulle (Zero Trust), nous allons utiliser Microsoft Entra ID combiné à Microsoft Authenticator installé sur les cellulaires des employés pour valider que l’appareil utilisé par l’utilisateur est bien en sa possession. Il serait également possible d’utiliser un autre fournisseur tel qu’Okta, Google, AWS ou autres.

Que dois-je mettre en place pour déployer la solution?

1. Avoir un fournisseur d’identité pour authentifier les utilisateurs (Microsoft dans le cas présent)
2. Déployer un serveur Boundary et un serveur Vault
3. Déployer des worker Boundary dans chaque réseau interne auquel nous devons nous connecter
4. Déployer Boundary Desktop sur les stations de travail des utilisateurs

Hashicorp offre une version cloud de Boundary et Vault. Il serait donc possible d’utiliser cette version au lieu d’avoir à déployer une instance mais pour les fins de ce document nous allons utiliser les versions gratuites open source de leurs produits.

Exemple de déploiement

Afin de démontrer l’approche Confiance nulle (Zero Trust) dans un environnement mixte, nous allons déployer les éléments suivant :

1. Un serveur principal qui sera déployé chez AWS en utilisant une instance EC2 m6i.large exécutant Ubuntu 24.04 Serveur LTS sur laquelle nous allons installer Boundary Controller, Worker et Vault
2. Une instance t3a.medium exécutant Ubuntu 24.04 Serveur LTS chez AWS sur laquelle nous allons configurer vault-ssh-helper pour tester la connexion SSH avec un mot de passe à usage unique
3. Une machine virtuelle exécutant Ubuntu 24.04 Serveur LTS sur un serveur physique Windows Serveur 2019 utilisant le rôle Hyper-V sur laquelle nous allons installer Boundary Worker
4. Une machine virtuelle Windows Server 2019 sur un serveur physique Windows Serveur 2019 utilisant le rôle Hyper-V qui servira à tester l’utilisation d’un compte Active Directory dynamique pour la connexion RDP

Les étapes pour configurer l’environnement sont disponible ici.

Objectifs

1. Démontrer une connexion SSH en utilisant Vault OTP

2. Démontrer une connexion RDP en utilisant Vault Dynamic Credentials

Configuration de l’environnement

Please refer to this procedure to configure Boundary and Vault before proceeding.

Utilisation de Vault OTP avec Boundary Desktop

Nous allons ici prendre en considération que vous avez déjà déployé l’environnement suivant incluant l’installation de vault-ssh-helper sur votre instance et que vous avez Boundary Desktop d’installé sur votre poste de travail.

1. Connectez-vous à votre serveur Boundary via l’interface web et authentifié vous avec un compte qui a les droits administrateurs

2. Sélectionnez votre organisation, votre projet et allez dans la section “Credentials Stores” qui devrait déjà avoir une librairie de type Vault

3. Cliquer sur votre librairie Vault et allez dans la section “Credentials Librairies”

4. Cliquer sur New, entrer un nom en lien avec votre instance dans la section Name

5. Dans la section Vault path entrer la valeur suivante :

ssh/creds/otp_key_role

6. Modifier la section HTTP Method de GET à POST et entrer l’adresse IPv4 interne de votre instance de la façon suivante :

{"ip": "X.X.X.X"}

7. Vous devriez obtenir quelque chose similaire à cette capture d’écran. Si c’est le cas appuyer sur le bouton Save

8. Allez maintenant dans la section Targets à gauche et appuyer sur New

9. Entrer le nom que vous désirez qui s’affichera dans Boundary Desktop pour déterminer de quel type de service ainsi que de quelle instance nous allons nous connecter. Dans le cas présent comme nous voulons tester une connexion SSH, il est préférable de le mentionner.

10. Entrer l’adresse IPv4 interne de votre instance dans la section Target Address ainsi que le port 22 dans la section Default Port. Prendre note que dans la version cloud d’Hashicorp au lieu du type Generic TCP, il existe SSH comme type de protocole mais dans la version self-hosted, seulement le type Generic TCP est disponible et ce peu importe le protocole de connexion utilisé.

11. Avant d’aller dans la section Workers, valider les informations qui devrait ressembler à ceci

12. Si vous avez plusieurs Workers de connecté à votre serveur Boundary, il faut activer la section Egress worker filter et entrer une information en lien avec les tags que vous avez défini dans le fichier de configuration de vos workers. Dans le cas présent comme mon instance ce trouve du côté AWS, je vais préciser ceci dans la section Filter mais si votre instance était ailleurs ou si vous aviez plusieurs worker dans différentes régions AWS, vous pourriez utiliser un autre type de tag :

"aws" in "/tags/type"

13. Vous devriez avoir quelque chose similaire à ceci. Si c’est le cas sauvegarder le

14. Ensuite allez dans la section Brokered Credentials et cliquer sur Add Brokered Credentials

15. Vous devriez voir ce que vous avez créé précédemment. Sélectionnez le et appuyer sur Add Brokered Credentials

16. Ouvrez maintenant Boundary Desktop sur votre poste et entrer l’adresse de votre serveur Boundary

17. Si vous avez configuré correctement votre serveur avec Microsoft Entra ID, il devrait automatiquement être sélectionné par défaut pour l’authentification. Cliquer sur le bouton Sign In et suivez les étapes pour vous authentifier avec votre compte Microsoft. C’est à cette étape que l’authentification à 2 facteurs entre en jeu. Si vous avez configuré Microsoft Authenticator sur votre cellulaire, vous devrez approuver la connexion avant que la connexion soit fonctionnelle.

18. Vous devriez par la suite être authentifié. Si vous ne voyez pas de target, c’est que votre compte n’a pas les autorisations pour les voir.

19. Si c’est le cas, retourner sur l’interface de gestion web de votre serveur Boundary avec un compte qui a les droits administrateurs et assurez-vous que votre compte Microsoft a les droits dans le projet auquel vous avez ajouter le target. Créer un nouveau role, ajouter votre compte Microsoft dans la section Principals et ajouter les accès suivants dans la section Grants :

ids=*;type=*;actions=read,list,authorize-session
ids=*;type=session;actions=cancel:self

20. Vous devriez par la suite voir le target s’afficher dans Boundary Desktop. Si vous ne le voyez pas, quitter et relancer le.

21. Connectez-le et vous devriez avoir une fenêtre qui indique le port à utiliser pour la connexion SSH ainsi que le mot de passe à usage unique qui vous a été généré pour cette instance seulement. Prendre note que le mot de passe qui s’affiche fonctionnera qu’une seule fois et seulement pour cette instance. Si vous perdez la connexion SSH ou si vous vous déconnectez, il faudra déconnecter la session et en créer une nouvelle dans Boundary Desktop pour générer un nouveau mot de passe à usage unique.

22. Ouvre votre terminal ou votre client SSH et connectez-vous à votre instance. Utilisez le mot de passe disponible dans la section Key de Boundary Desktop pour vous y connecter au lieu d’utiliser une clé PEM.

23. Si la connexion SSH fonctionne avec le mot de passe c’est que votre serveur Boundary, votre serveur Vault ainsi que votre instance sont en mesure de communiquer entre eux. Si la connexion SSH est refusée, assurez-vous que votre worker est en mesure de se connecter à votre instance et que vous avez sélectionné le bon worker lors de la configuration du target dans votre serveur Boundary.

24. Rappel : Si vous fermez votre session SSH et que vous essayez de l’ouvrir à nouveau le mot de passe à usage unique sera refusé, il faudra donc terminer votre session en appuyant sur le bouton End Session dans Boundary Desktop et connecter une nouvelle session pour obtenir un nouveau mot de passe à usage unique pour se connecter à cette instance.

Utilisation de Vault Dynamic Credentials avec Boundary Desktop

1. Assurez-vous en premier lieu que l’instance auquel vous voulez vous connecter permet l’accès au groupe VaultUsers en RDP

2. Connectez-vous à votre serveur Boundary via l’interface web et authentifié vous avec un compte qui a les droits administrateurs

3. Sélectionnez votre organisation, votre projet et allez dans la section “Credentials Stores” qui devrait déjà avoir une librairie de type Vault

4. Cliquer sur votre librairie Vault et allez dans la section “Credentials Librairies”

5. Cliquer Manage et sélectionner New Credential Library

6. Entrer un nom du type Dynamic AD Credentials

7. Dans la section Vault path entrer le chemin suivant :

/ldap/creds/dynamic-role

8. Laissez la section HTTP Method à Get et cliquer sur Save. Vous devriez obtenir quelque chose de similaire à ceci :

9. Allez dans la section Targets et cliquer sur New Target. Entrer un nom, l’adresse IPv4 de votre machine virtuelle Windows 2019 ainsi que le port 3389.

10. Si vous avez plusieurs Workers de connecté à votre serveur Boundary, il faut activer la section Egress worker filter et entrer une information en lien avec les tags que vous avez défini dans le fichier de configuration de vos workers. Dans le cas présent comme ma machine virtuelle ce trouve du côté du réseau interne du siège social de l’entreprise, je vais préciser ceci dans la section Filter mais si votre instance était ailleurs ou si vous aviez plusieurs worker dans différentes régions AWS, vous pourriez utiliser un autre type de tag

"mainoffice" in "/tags/type"

11. Sauvegarder votre target et allez dans la section Brokered Credentials.

12. Appuyer sur le bouton Add Brokered Credentials, sélectionner Dynamic AD Credentials et appuyer sur Add Brokered Credentials

13. Ouvrez maintenant Boundary Desktop sur votre poste de travail et authentifiez vous avec votre compte Microsoft ou appuyer sur le bouton Refresh s’il est déjà ouvert. Vous devriez voir votre second target dans la liste.

14. Appuyer sur le bouton Connect et si la connexion avec votre worker fonctionne correctement vous devriez voir les informations du compte s’afficher ainsi que le port local à utiliser pour la connexion RDP

15. Il reste maintenant à utiliser un logiciel pour tester la connexion RDP sur votre poste de travail. Nous allons ici utiliser Microsoft Remote Desktop disponible gratuitement sur l’App Store d’Apple ou sur le Windows Store de Microsoft mais Remote Desktop Connection qui vient avec Windows ou tout autres logiciels qui permet des connexions RDP fonctionnera également.

16. Lancer la connexion et vous devriez avoir une fenêtre vous demandant d’entrer les informations du compte

17. Récupérer le nom d’usager dans la section username de Boundary Desktop et le mot de passe dans la section password

18. Vous devriez être en mesure de vous connecter en RDP. Si vous êtes sur un domaine différent, il sera peut-être nécessaire d’ajouter le domaine au nom d’usager dans le style de YourDomain\Username ou username@yourdomain pour que la connexion fonctionne.

19. Prendre note que ce compte sera automatiquement supprimé du domaine au bout de 8h et qu’un nouveau compte sera automatiquement créé lorsqu’une nouvelle session sera connectée dans Boundary Desktop.

Conclusion

Nous avons été en mesure de démontrer qu’une approche combinant HashiCorp Boundary, Hashicorp Vault et Microsoft Entra ID permet une connexion sécurisée à 2 types d’instances. Que ce soit une instance Linux ou Windows, il est possible de permettre l’accès à distance sans devoir mettre en place un VPN ou avoir à créer des accès permanents pour chacun des usagers.

À la différence d’un VPN qui donne un accès complet au réseau distant, Boundary permet de connecter un seul service à la fois via un tunnel sécurisé entre votre poste de travail et le worker distant. Vous aurez accès seulement aux services auquel vous avez besoins et seulement pour une courte période. Combiné à Vault il est également possible d’utiliser des comptes et mots de passe à usage unique afin de ne pas avoir à gérer continuellement de nouveaux accès.

Nous avons testé un accès SSH et RDP mais il serait possible de permettre d’autres type d’accès.

Par exemple si vous avez un serveur Filemaker sous Ubuntu et que vous désirez permettre un accès temporaire à la console d’administration à certains employés, vous pourriez le connecter à votre contrôleur de domaine Active Directory et permettre l’accès en configurant la section “Paramètres du service d’annuaire” et en ajoutant le groupe VaultUsers dans la section “Comptes externes pour la connexion à l’Admin Console”. Il resterait par la suite qu’à créer un target HTTPS dans votre serveur Boundary auquel vous attaché le Dynamic AD Credentials que nous avons créé ici pour générer un compte temporaire qui permettra l’accès à la console.