Déployer WALLIX Bastion : de l'image au premier accès tracé.

Un bastion d'accès à privilèges - un PAM, pour Privileged Access Management - répond à une question que la plupart des organisations ne savent pas trancher : qui s'est connecté sur ce serveur, avec quel compte, quand, et pour y faire quoi ? Tant que les administrateurs se connectent en direct avec des comptes partagés, la réponse est « on ne sait pas ». Le bastion ferme cette porte et n'en laisse qu'une seule, surveillée et enregistrée.

Ce pas à pas couvre le déploiement de WALLIX Bastion de l'image à la première connexion tracée : préparer le réseau, vérifier l'image, initialiser l'appliance, la durcir - car les réglages d'usine ne sont pas ceux d'une machine de production - puis poser le modèle fonctionnel qui décide qui accède à quoi.

Ce qu'il vous faut

• Un compte sur le portail de support WALLIX : les images et les licences ne sont pas en accès libre.
• Une plateforme de virtualisation supportée (VMware vSphere, Hyper-V, KVM, Nutanix AHV, OpenStack) ou un compte sur un des clouds supportés - ou une appliance physique.
• Les ouvertures de flux décrites plus bas, validées avec l'équipe réseau avant le déploiement.
• Un gestionnaire de secrets pour y déposer, au fur et à mesure, les mots de passe et phrases de passe créés pendant l'installation. Il y en a sept, et plusieurs sont irrécupérables.

1. Ce que le bastion change, et ce qu'il ne change pas

Le principe tient en une phrase : plus personne ne se connecte directement à un serveur. Toutes les sessions d'administration passent par le bastion, qui authentifie l'humain, vérifie son autorisation, ouvre la session vers la cible avec un compte que l'humain ne connaît pas nécessairement, et enregistre tout ce qui se passe.

Trois bénéfices en découlent, et ils ne sont pas interchangeables :

• La traçabilité nominative. Une session enregistrée est rattachée à une personne, pas à un compte root partagé par cinq administrateurs et un prestataire.
• La rupture du secret. Avec le coffre à mots de passe, l'administrateur n'a plus besoin de connaître le mot de passe de la cible - donc il ne peut plus le noter, le réutiliser, ni l'emporter en partant.
• Le point de contrôle unique. Retirer un accès se fait à un seul endroit, et prend effet immédiatement.

Ce que le bastion ne fait pas : empêcher un administrateur légitime de faire une bêtise, protéger une cible dont le mot de passe traîne encore ailleurs, ni couvrir les accès qui le contournent. C'est ce dernier point qui décide de la réussite du projet, et nous y revenons à la fin.

2. Choisir la forme de déploiement

WALLIX Bastion se déploie de trois façons, et le choix se fait avant tout le reste :

• Appliance physique - livrée montée et préconfigurée. Il ne reste qu'à la brancher et l'allumer ; on passe directement à l'initialisation.
• Appliance virtuelle - VMware vSphere (à partir d'ESXi 5.5), Microsoft Hyper-V, KVM, Nutanix AHV, OpenStack.
• Image cloud - Alibaba Cloud, AWS, Google Cloud, Microsoft Azure, Outscale. Azure et AWS passent par leur place de marché ; les autres images se demandent au support.

Pour le virtuel, l'éditeur fournit une image ISO générique et des images spécifiques par plateforme. Préférez toujours l'image spécifique quand elle existe : l'ISO générique est un repli, pas l'option recommandée.

Un détail Hyper-V qui coûte une réinstallation si on le manque : l'image .vhdx doit être importée pour créer une machine virtuelle de génération 1 ; c'est l'ISO qui sert pour une génération 2.

3. Ouvrir les bons flux, avant de déployer

Un bastion est par nature au milieu de tout : il parle à l'annuaire, aux cibles, au serveur de temps, au SIEM, au relais de messagerie. Faire valider ces ouvertures après coup transforme l'installation en semaine de tickets réseau.

Flux sortants, depuis le bastion :

Flux entrants, vers le bastion :

Le port 2242 mérite une attention particulière : c'est la console d'administration système du bastion. Il ne doit être joignable que depuis les postes d'administration, jamais depuis le réseau bureautique - au même titre qu'un accès à un contrôleur de domaine (voir notre partie sur le cloisonnement en paliers).

4. Dimensionner

Le dimensionnement dépend du nombre de sessions simultanées, pas du nombre d'utilisateurs déclarés. Les valeurs publiées par l'éditeur donnent l'ordre de grandeur :

Deux points comptent plus que les chiffres eux-mêmes :

• Sur vSphere, réservez. Un seul socket virtuel, les cœurs répartis dessus, Shares à High, et une réservation de CPU et de mémoire. Le nombre de sessions simultanées n'est garanti que si les ressources sont réservées, pas simplement allouées - sinon la première contention de l'hyperviseur se traduit par des sessions qui rament au pire moment.
• Le disque se calcule sur la rétention des enregistrements, pas sur la taille du produit. C'est l'enregistrement des sessions qui remplit le volume, et une politique de conservation à un an sur un parc actif dépasse largement le disque par défaut.

Si le disque doit être étendu plus tard, l'opération n'est pas un simple redimensionnement : le volume est chiffré (LUKS), il faut créer et ouvrir la partition chiffrée, l'enregistrer dans /etc/crypttab, l'ajouter au groupe de volumes, arrêter les services, puis redimensionner. La procédure exacte est dans le guide de déploiement : suivez-la à la lettre, elle passe par un arrêt de service.

5. Récupérer l'image, et vérifier sa signature

Cette étape se saute souvent. Elle ne devrait pas : vous êtes en train d'installer la machine qui détiendra les accès à privilèges de toute l'organisation. Une image altérée à ce stade est une compromission dont vous ne vous relèverez pas.

Les images se téléchargent depuis le portail de support, accompagnées de leurs fichiers de signature. La vérification se fait en deux temps : on valide la signature du fichier d'empreinte, puis on compare l'empreinte de l'image à celle qu'il contient.

Poste d'administration - importer la clé publique WALLIX

gpg --import ./<NOM_DE_LA_CLE>.pub.gpg

Vérifier la signature du fichier d'empreinte

gpg --verify ./<IMAGE>.iso.sha256sum.sig ./<IMAGE>.iso.sha256sum

La sortie doit indiquer Good signature et nommer la clé de l'équipe WALLIX. Puis, sous Linux :

sha256sum -c bastion-<VERSION>-<PLATEFORME>.<EXT>.sha256sum

Sous Windows, la comparaison se fait en PowerShell :

((Get-Content .\<IMAGE>.iso.sha256sum) -split ' ')[0] -eq (Get-FileHash .\<IMAGE>.iso).Hash

Le résultat doit être True. S'il ne l'est pas, l'image n'est pas valide : on ne l'installe pas, on la retélécharge, et si l'échec persiste on appelle le support.

6. L'initialisation : sept secrets à créer, et à ne pas perdre

Au premier démarrage, un assistant en mode console guide la configuration minimale. Il faut y arriver préparé : plusieurs des secrets créés à cette étape sont irrécupérables, et ils ne servent que le jour où plus rien d'autre ne fonctionne.

L'accès se fait par la console (écran et clavier, ou console de l'hyperviseur) ou par SSH sur le port 2242, à l'adresse d'usine 192.168.10.5/24 - il faut donc se donner temporairement une adresse dans ce sous-réseau.

L'assistant demande, dans l'ordre : la langue et la disposition du clavier, puis les mots de passe système.

Deux pièges : le compte wabbootadmin n'accepte que des caractères ASCII - si la phrase de passe de wabsuper contient des accents, il faut lui en donner une différente. Et sur AWS, le mot de passe d'usine du compte admin n'est pas admin mais admin-{instanceID}, construit sur l'identifiant de l'instance EC2.

Vient ensuite la configuration réseau minimale : nom d'hôte, adresse de eth0, passerelle, masque, FQDN. Hors cloud, n'utilisez pas DHCP - une adresse de bastion qui change casse tout ce qui pointe dessus. Tous ces paramètres restent modifiables ensuite.

7. Durcir le système : ce que les réglages d'usine ne font pas

C'est la section la plus importante de cette page, et celle que l'on saute le plus souvent parce que le produit fonctionne parfaitement sans elle.

a. La phrase de passe du disque

Le disque est chiffré, mais la phrase de passe d'usine est commune à toutes les appliances et stockée en clair dans un fichier ; sur les images cloud, la clé de volume est partagée entre toutes les instances d'une même plateforme. Autrement dit, tant que vous n'y touchez pas, le chiffrement protège contre le vol du disque par quelqu'un qui ignore le produit, et contre personne d'autre.

Connectez-vous en SSH sur le port 2242, puis passez root :

wabadmin$ super
wabsuper$ sudo -i

Sur une machine physique ou virtuelle sur site :

bastion-luks-update --interactive --change-passphrase

Sur une plateforme cloud autre qu'AWS, il faut aussi changer la clé de volume :

bastion-luks-update --reencrypt

L'opération de re-chiffrement prend plusieurs minutes et ne doit pas être interrompue. Sur AWS, le chiffrement de disque n'est pas géré de la même manière et l'étape ne s'applique pas.

b. Les clés SSH d'administration

Par défaut, la console d'administration accepte l'authentification par mot de passe. Déposez les clés publiques des administrateurs dans les fichiers ~/.ssh/authorized_keys de wabadmin et wabupgrade avant de fermer l'authentification par mot de passe - même règle que pour n'importe quel accès SSH exposé : on vérifie que la clé fonctionne depuis un autre terminal avant de couper le mot de passe.

c. Le niveau cryptographique

Une commande unique fixe le niveau des mécanismes cryptographiques de tous les services :

WABSecurityLevel

Choisissez le même niveau pour tous les services - le guide recommande l'ensemble SOG-IS. Panacher les niveaux crée des incompatibilités entre composants, et le symptôme (une session qui échoue sans message clair) est particulièrement pénible à diagnostiquer.

À noter : les clés privées RSA que vous installerez ensuite (SSH sur 2242, HTTPS, RDP) doivent faire au moins 3072 bits.

8. La configuration initiale par l'interface web

Ouvrez https://<adresse-du-bastion>/. Le navigateur avertit d'un certificat auto-signé : c'est normal à ce stade, nous le remplaçons plus bas.

1. Se connecter avec admin / admin, et changer ce mot de passe immédiatement.
2. Poser la phrase de passe de chiffrement applicative - distincte de celle du disque. Choisissez-en une personnalisée (12 caractères minimum, majuscule, minuscule, chiffre, caractère spécial) plutôt que celle par défaut, et rangez-la dans le coffre.
3. Installer la licence. Configuration → Licence → Télécharger le fichier de contexte, envoyer le license_context.json au support, puis déposer le wallix_license.json reçu en retour. Sans licence, le bastion ne fonctionne pas.
4. Configurer le temps. Système → Service de temps : fuseau horaire et serveurs NTP. Ce n'est pas cosmétique : une horloge décalée fausse l'horodatage des sessions enregistrées - donc leur valeur de preuve - et casse l'authentification Kerberos.
5. Créer un administrateur nominatif avec le profil product_administrator, une adresse e-mail valide et une méthode d'authentification.
6. Sauvegarder la configuration. Système → Sauvegarde/Restauration : définir une clé de sauvegarde d'au moins 16 caractères, la ranger dans le coffre, créer la sauvegarde et la télécharger. Sans cette clé, la sauvegarde est inexploitable.
7. Se reconnecter avec le compte nominatif, puis supprimer le compte admin. Il est recréable si besoin.
8. Changer le mot de passe de la base de données, qui est lui aussi un réglage d'usine :

   WABChangeDbRootPassword

9. Remplacer les certificats auto-signés

Trois services présentent des certificats ou clés générés à l'installation. Les remplacer par des éléments issus de votre PKI n'est pas cosmétique : c'est ce qui permet à un utilisateur de détecter qu'on lui présente un faux bastion.

Interface web : le certificat s'installe depuis l'interface d'administration.

Proxy RDP, depuis la console 2242 en root :

rdpcert --key --inkey=./cle_privee.key --x509 --inx509=./certificat.pem --force
systemctl restart redemption

Clé d'hôte du proxy SSH : déposez votre clé RSA (4096 bits recommandés) dans /var/wab/etc/ssh/server_rsa.key, ou une clé Ed25519 dans /var/wab/etc/ssh/server_ed25519.key. Pour en régénérer une :

rm /var/wab/etc/ssh/server_rsa.key /var/wab/etc/ssh/server_ed25519.key
WABSshServerGenRsaKey.sh

Changer la clé d'hôte SSH après la mise en production déclenchera un avertissement chez tous les utilisateurs, qui prendront l'habitude de l'ignorer. Faites-le maintenant, pas dans six mois.

10. Le modèle fonctionnel : qui accède à quoi

Le déploiement technique est terminé ; le produit ne sert encore à rien. Le modèle d'autorisation de WALLIX Bastion s'articule en sept objets, et l'ordre dans lequel on les crée n'est pas indifférent :

1. Utilisateurs (Utilisateurs → Comptes) - les personnes, nominativement.
2. Groupes d'utilisateurs - on n'autorise jamais une personne, on autorise un groupe. C'est ce qui rend l'arrivée et le départ d'un collaborateur gérables.
3. Domaines cibles (Cibles → Domaines) - les périmètres d'identités des machines administrées, et les comptes qui s'y rattachent.
4. Équipements cibles (Cibles → Équipements) - les serveurs, avec leurs services (SSH, RDP…).
5. Comptes cibles - les comptes utilisables sur chaque service. C'est ici que le coffre prend en charge les mots de passe.
6. Groupes de cibles - le pendant des groupes d'utilisateurs, éventuellement avec correspondance de comptes.
7. Autorisations (Autorisations → Gérer les autorisations) - le croisement : tel groupe d'utilisateurs, sur tel groupe de cibles, pour tel protocole.

La conséquence pratique de ce modèle : une autorisation est une matrice, pas une liste. Si vous créez un groupe par personne et un groupe par serveur, vous obtenez une matrice ingérable en trois mois. Réfléchissez aux groupes avant de déclarer la première cible - c'est la décision qui coûte le plus cher à défaire.

Côté utilisateur, Mes autorisations → Sessions liste les cibles joignables et Mes autorisations → Mots de passe les comptes dont on peut consulter le secret.

Vérifier que c'est en place

1. Une session complète de bout en bout : un utilisateur non administrateur ouvre une session SSH et une session RDP vers une cible, via le bastion. L'enregistrement doit être consultable et rattaché à son nom.
2. Le compte admin d'usine n'existe plus, et le mot de passe de la base de données a été changé.
3. Le disque : un redémarrage demande bien la phrase de passe - si ce n'est pas le cas, l'étape 7a n'a pas pris.
4. Les certificats : l'interface web, le proxy RDP et le proxy SSH présentent vos éléments, pas ceux générés à l'installation.
5. Les journaux partent : le SIEM reçoit bien les événements en syslog. Un bastion qui enregistre tout en local et rien ailleurs perd sa valeur de preuve le jour où il est lui-même compromis.
6. La restauration : la sauvegarde téléchargée se restaure réellement, sur une instance de test, avec la clé que vous avez rangée. Une sauvegarde jamais restaurée est une hypothèse - voir notre article sur les sauvegardes.

Sources

• WALLIX - Bastion 12.0.2 Deployment Guide (PDF officiel)
• WALLIX - Bastion Quick Start Guide (PDF officiel, valeurs de dimensionnement)
• WALLIX - portail de support (images, licences, guides d'administration)
• Kenawek - Durcir Active Directory : identités, privilèges et postes d'administration
• Kenawek - Durcir un accès SSH exposé
• Kenawek - Vous n'avez pas d'inventaire, vous avez une intuition