Sécurité et Maven : Pourquoi s’en priver ?

Nous sommes poussés de plus en plus chaque jour à sécuriser nos données et autres accès confidentiels, alors pourquoi laissons-nous encore nos informations d'accès en clair sur nos postes de développement ou environnements de pré-production et tout particulièrement les codes d'accès qui s'y rattachent? Je vous l'accorde, s'il s'agit d'un serveur "perso" de développement où est le problème, mais s'il s'agit d'un serveur central, hébergeant de plusieurs applications avec politique de sécurité et tutti quanti, là, cette question se pose. Heureusement Maven est là pour nous aider à ne plus cacher la clef sous le paillasson.

Maven propose de façon native depuis la version 2.1 une gestion sécurisée de mot passe, concernant les définitions de serveurs dans le fichier de configuration settings.xml. Ce fichier, bien souvent personnel, peux également être partagé, d'où la nécessité de masquer les informations sensibles de connexion.

Ce mécanisme repose sur deux actions complémentaires :

Premièrement, Maven permet la génération d'une clef principale, qui servira pour l'encryption de tous les mots de passes consécutifs. Cette clef est stockée dans un fichier nommé settings-security.xml, à placer dans le répertoire .m2.

La commande suivante génère donc cette clef principale :

mvn --encrypt-master-password monMot2PasseS3cret

Le résultat s'affiche alors sur votre console :

{hE4dMhApieYH0PkYV7cXQJ/T8U73IFhzy6xcNf1KiHYNVhVPE3Q8Zotpi0SR2Oz9}

Il ne reste plus qu'à créer votre fichier 'settings-security.xml', et d'y insérer votre clef de la façon suivante :

<settingsSecurity>
  <master>{hE4dMhApieYH0PkYV7cXQJ/T8U73IFhzy6xcNf1KiHYNVhVPE3Q8Zotpi0SR2Oz9}</master>
</settingsSecurity>

Oui, mais vous me direz, si cette information de clef principale est si secrète, pourquoi la conserver ainsi, au risque d'une intrusion dans vos fichiers personnels ? Eh bien Maven vous permet de la stocker de façon "mobile", en indiquant alors un emplacement de stockage plus sûr, comme un volume amovible ou une clef USB, en indiquant la configuration suivante :

<settingsSecurity>
<relocation>D:\MobileDev\SuperSecure\settings-security.xml</relocation>
</settingsSecurity>

Note : Il n'y a pas d'invite de saisie de ce mot de passe donc, en environnement type Unix, n'oubliez pas de vider votre historique de commandes de ces informations sensibles 😉

Deuxièmement, maintenant que nous avons notre clef principale, nous pouvons encoder tous les mots de passe de connexion serveur.

La commande suivante encrypte donc notre mot de passe de connexion :

mvn --encrypt-password monMot2PasseTomcat

Le résultat s'affiche alors sur votre console :

{SOwXVa1uSnUHlAEFbg8SW71gYg/Vhudsht0zrhu7rX4SN7z9MZr+rfiKItJhCXj4}

Il ne nous reste plus qu'à coller notre mot de passe crypté dans le fichier settings.xml, dans la section server, dédiée à notre machine cible :

<settings>
...
  <servers>
...
    <server>
      <id>monRepoCentrale</id>
      <username>Nestor</username>
      <password>{SOwXVa1uSnUHlAEFbg8SW71gYg/Vhudsht0zrhu7rX4SN7z9MZr+rfiKItJhCXj4}</password>
    </server>
...
  </servers>
...
</settings>

Désormais, vos informations de connexion sont cryptées, sans impacter vos développements. Ainsi, pour déployer un nouvel artifact sur votre serveur, la commande de déploiement reste la même :

mvn deploy:deploy-file -Durl=https://mamachine.mondomaine.fr/repo -DrepositoryId=monRepoCentrale -Dfile=mon-super-artifact-1.0.jar

... sauf que cette fois ci vos informations de connexion ne sont plus lisibles à l'oeil nu (implants bioniques exclus).

Alors à vos mots de passe et votre Maven pour "cacher cette clef que je ne saurai voir" 😉

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *