Ce guide aborde le périmètre Bastion 12. Les menus, options et compatibilités peuvent évoluer avec les correctifs et la version d’Access Manager : vérifiez la documentation correspondant à votre environnement avant une configuration.
Comprendre le fonctionnement
WAAPM permet à des scripts et applications d’obtenir des secrets du coffre sans intervention à chaque exécution. Son usage requiert le périmètre et la licence adaptés. L’enrôlement seal prépare la relation avec Bastion et le nombre d’entrées applicatives ; les premiers checkouts enregistrent leurs empreintes pendant une fenêtre limitée.
L’empreinte peut inclure les bibliothèques chargées. Une mise à jour de DLL ou SO peut donc modifier ce qui est reconnu. Réduire la vérification au nom ou retirer ces modules change la propriété de contrôle : ce n’est pas une simple correction de confort.
Construire et vérifier la configuration
- Préparer Password Manager et un compte primaire autorisé uniquement aux secrets nécessaires à l’application.
- Installer la version WAAPM compatible et choisir le répertoire de stockage local protégé pour ses éléments d’enrôlement.
- Effectuer le seal et les premiers checkouts dans la fenêtre prévue. Enregistrer les applications réellement autorisées et leur identité d’exécution.
- Tester le renouvellement du secret et une mise à jour de dépendance. Définir une procédure d’actualisation des empreintes plutôt qu’une désactivation automatique.
- Étudier PasswordFS pour la substitution à la lecture des configurations et les modes SSH/SCP/SFTP disponibles dans la version. Vérifier sortie, logs et permissions pour éviter une nouvelle fuite de secrets.
Les choix à retenir
Reliez chaque réglage à son effet sur l’accès et à la vérification associée.
| Élément | Rôle ou effet | Vérification |
|---|---|---|
| Seal | Enrôle le client | Compte, Bastion et nombre d’entrées |
| Checkout | Récupère le secret autorisé | Identité de l’application et droits |
| Empreinte | Contrôle l’application et ses modules | Effet des mises à jour connu |
| PasswordFS | Substitue à la lecture | Processus consommateur et permissions |
Diagnostiquer sans masquer le problème
Une empreinte refusée après mise à jour n’est pas nécessairement un mauvais mot de passe. Examiner le processus appelant, les modules, le répertoire local et l’état d’enrôlement.
Un secret absent du fichier de configuration peut encore être exposé par la sortie standard, une trace ou le consommateur. Prévoir aussi reset des entrées, extension maîtrisée de leur nombre et récupération en cas de changement de client.
Exercice de compréhension
Le script fonctionne puis échoue après une mise à jour de bibliothèque. Quel mécanisme examinez-vous avant de réenrôler ?
Voir le corrigé
La composition de l’empreinte et les modules chargés. Comparer avec l’état autorisé et la politique de mise à jour ; ne retirer la vérification qu’après un choix explicite de protection.
Pour approfondir
- Documentation des produits WALLIX — choisir la version applicable
- Portail support WALLIX — guides et compatibilité par version