Maven 3 permet de crypter les mots de passe serveurs stockés dans votre fichier settings.xml. C'est un net progrès pour ce fichier qui peut vite contenir tous les sésames de votre infrastructure. Cependant beaucoup (trop ?) de personnes semblent se contenter de la sécurité apparente de voir leur mot de passe remplacé par un obscur "{ABCDEF1234567890ABCDEF1234567890=}".
Un indice : Maven 3 est en mesure de retrouver vos mots de passe, sans vous demander quoi que ce soit : le cryptage est donc réversible sans votre intervention. Si vous utilisez un client ssh vous vous souvenez peut-être avoir mis en place un agent qui "cache" votre passphrase pour ne pas avoir à la retaper à chaque commande. Bien pratique, l'effet pervers de ces outils est qu'on finit par oublier où se situe la réelle sécurité dans le système.
Petit rappel donc : Maven utilise un mot de passe maître, stocké dans votre settings-security.xml, et lui même cryptée pour ne pas révéler de manière trop évidente cette info capitale. Cette clé sert pour crypter vos autres mots de passes. Si cette clé est inaccessible à un malveillant, vous êtes en sécurité (dans la limite du raisonnable, comme tout système cryptographique l'attaquant très bien armé et très patient pourra passer au travers - il peut aussi vous couper les orteils un a un pour vous faire révéler votre mot de passe c'est souvent plus simple)
On se retrouve donc avec deux fichiers bien obscurs qui donne un sentiment de sécurité. Seulement que ce passe t-il si un vilain pas bô peut accéder à ces deux fichiers ? Disons qu'il passe 2 minutes à regarder le code de maven et qu'il essaye un truc du genre :
PlexusCipher _cipher = new DefaultPlexusCipher();
String bare = _cipher.unDecorate( "{...=}" );
String master = _cipher.decryptDecorated("{...=}", SYSTEM_PROPERTY_SEC_LOCATION);
System.out.println( _cipher.decrypt(bare, master) );
Ne m'accusez pas de révéler une faille de sécurité, c'est vraiment à la portée du premier stagiaire venu de retrouver ce fragment de code à partir du code source Maven :P
La documentation de Maven vous le dit très clairement, le fichier settings-security.xml est la clé du système et doit donc être traité avec tous les égards. La solution recommandée consiste à renvoyer, dans le settings-security.xml par défaut, vers un autre fichier que vous placez sur une clé USB, disque réseau, ou tout autre ressource que vous pouvez "débrancher" en votre absence. On en revient donc au final à la bonne vielle sécurité physique.
La réelle sécurisation proposée par Maven consiste donc à déplacer le problème de sécurité des mots de passe. En fait, si on considère le scénario où vous placez votre fichier sensibles sur une clé USB à reconnaissance d'empreinte digitale, une simple redirection du fichier settings.xml donnerait une sécurité globalement équivalente. La sécurisation proposée par maven 3 est donc :
- d'éviter que vos mots de passe apparaissent en clair, par exemple lorsque vous ouvrez votre fichier settings.xml en plein pendant une démo lors d'une conférence (non, ça ne m'est pas arrivé :P)
- de vous permettre de séparer l'accès à vos mots de passe en deux fichiers. Un attaquant opportuniste qui vous piquerait l'un des deux éléments ne serait pas plus avancé.
C'est donc un réel progrès, mais le risque que je constate - risque général d'ailleurs - c'est qu'on est tenté d'utiliser son ID et le même mot de passe un peu partout. Résultat, dans le settings.xml utilisé par le serveur d'intégration continue je vais retrouver les clés du responsable technique du projet. Si celui-ci est conscient de ce risque (et c'est désormais le cas, vu qu'il lit forcément assidument ce blog) il aura créé un utilisateur dédié sur son Nexus / Artifactory / Archiva pour les déploiements maven.
Moralité, sortez couverts !
update :
si vous récupérez le mot de passe de session Windows de votre chef-de-projet-apprenti-responsable-technique par ce biais, merci d'envoyer de sa part un mail à toute l'équipe déclarant que la journée du 14 septembre sera chômée afin de tous vous envoyez au JugSummercamp à ses frais.
update :
si vous récupérez le mot de passe de session Windows de votre chef-de-projet-apprenti-responsable-technique par ce biais, merci d'envoyer de sa part un mail à toute l'équipe déclarant que la journée du 14 septembre sera chômée afin de tous vous envoyez au JugSummercamp à ses frais.
2 commentaires:
C'est déjà un pas dans la bonne direction, le fait de pouvoir sécuriser ses mots de passe (depuis Maven 2.1).
Mais hélas, il faut parfois utiliser des mots de passe dans de la configuration de plugins (on n'a pas toujours la main là dessus), et du coup, comment externaliser "proprement" un tel mot de passe ? Le plugin ne gérant pas le décryptage, on reste coincé. "Au mieux", on peut faire un fichier de propriétés qui sera lu par le plugin idoine, et qui proposera ensuite de mettre la valeur du mot de passe dans la configuration du plugin. Mais au final, le mot de passe reste en clair dans un fichier de configuration. Bref, c'est un simple jeu de pistes, pas très sécurisé...
Mais si vous avez une idée, n'hésitez pas à poster votre avis sur cette question sur StackOverflow.
Wow merci, c'est une nouvelle information pour moi. Après tout, quand je préfère me détendre, je viens ici 1depositcasinoukJe ne pense même pas à la modération des mots de passe. Maintenant, je vais y faire plus attention.
Enregistrer un commentaire