Par défaut, les dataSources déclarées dans Tomcat affichent le mot de passe jdbc en clair dans conf/server.xml.
Dans pas mal d’entreprises, le répertoire de tomcat est accessible en lecture à de nombreuses personnes. C’est très pratique pour diagnostiquer, mais pose un problème de sécurité en exposant ce mot de passe.
Voici quelques pistes d’amélioration que j’ai investiguées, en essayant de trouver un équilibre entre les besoins des développeurs et ceux de l’exploitation (oui, ça ressemble à de la démarche devops ).
Voici des comportements que j’ai souvent vus en entreprise. Ils ont tous une logique certaine, mais cachent en général une négligence (et parfois méconnaissance) de la sécurité informatique.
Il faut dire que sécuriser, c’est des contraintes à court terme, pour (peut-être) réduire un risque à moyen terme. Donc ça va souvent à contre-courant.
La faille POODLE a entraîné la désactivation du protocole SSLv3 dans tous les navigateurs récents.
Problème : que faire pour de vieux services HTTPS qui ne savent pas faire mieux que du SSLv3?
Les navigateurs récents refusent d’y accéder, donc il faudrait les patcher/reconfigurer pour qu’ils prennent en charge des protocoles plus sécurisés. Mais ce n’est pas toujours possible : soit parce que ces applications web ne sont plus supportées, soit parce que ce serait trop risqué ou coûteux.
Une solution de contournement peut être de mettre en place un reverse-proxy entre ces services et les navigateurs des utilisateurs.
).