Aujourd'hui je suis toujours surpris pas la complexité mise en place pour sécurisées des informations (bases de données, partages de fichiers, FTP…). Pour une même application, il y a les développeurs qui vont stocker 50 comptes qui ne sont utilisés que par l'application (ou le groupe d'applications qu'ils gèrent). Pour ne pas distribuer les mots de passe sur les serveurs, ou les pc clients, on se retrouve souvent avec trois solutions qui parfois se complètent:

• Le stockage de logins, mots de passe cryptés (dans l'application ou le fichier de configuration).
• L'utilisation d'un API tiers de sécurité pour stocker logins et mots de passe (parfois avec un mot de passe ou token d'accès qui lui n'est pas sécurisé)
• L'impersonation pour que le processus s'exécute avec des droits d'un autre utilisateur.

Il y a peut-être d'autres solutions que je n'ai pas croisées.

Dans tous les cas, on finira systématiquement avec un problème : « il y aura toujours un mot de passe qu'une personne devra conserver », ou « une personne qui aura accès à l'information sans restriction ».

Exemples absurdes, car l'utilisateur aura accès quoi qu'il soit décidé :

• Ne pas vouloir donner accès à un site SharePoint alors que l'utilisateur est administrateur de la collection contenant le site.
• Ne pas vouloir donner accès à un partage alors que l'utilisateur gère aussi le compte qui sert au backup de ce dossier (donc un compte qui lui aura accès quoi qu'il arrive)
• … etc ….

Chacun a connu dans sa carrière l'une de ses situations absurdes. Je sais d'expérience qu'il y a des personnes qui préfèrent ne pas expliquer la situation : « c'est sécure ! ». Personnellement, j'ai toujours bataillé pour que la situation soit claire. Il n'y a pas de sécurité dans l'opacité.

La solution simple :

1. L'humain

Ne pas prendre un responsable de votre société, car dans la plupart des cas, ils ne sont pas formés à la sécurité et risquent de compromettre l'information.

Exemple typique de ce type d'utilisateur :

• Téléphone sans verrouillage d'accès posé sur une table.
• PC laissé session ouverte lors de la pause pipi.
• Lien vers les mots de passe sur le bureau Windows.
• … etc…

Mettre en avant une personne « administrateur système » ou un « administrateur applicatif ». Cette personne a l'accès complet à l'outil et la sécurité fait partie de son métier. S'il faut conserver un mot de passe, c'est lui qui doit le faire.

2.  La technique simple

La quasi-totalité des applicatifs peut utiliser une authentification Windows (aussi appelée authentification intégrée sur certaines applications comme SQL Server). Ce qui permet aussi la centraliser la gestion des comptes dans l'Active Directory. Notre administrateur aillant accès à l'AD, il pourra immédiatement couper un compte si besoin. Ceci est très pratique dans le cas d'applications compromises, ou changer le mot de passe rapidement.

A partir du moment où l'on utilise ce mode d'authentification, il n'est plus utile de stocker des chaines de connexion avec mot de passe dans l'applicatif ou le fichier de configuration. Ni même de stocker un mot de passe. Le ou les processus lancés se feront avec les droits de l'utilisateur qui a lancé le processus.

Pour chaque type d'application, il y a une solution simple qui s'appuie sur un compte Windows:

• Application Windows classique : Le compte d'ouverture de session est utilisé
• Site Web : Le compte du pool IIS est utilisé.
• Planificateur de tâche : On peut déterminer un compte lors de la mise en place
• Service Windows : On peut déterminer un compte lors de la mise en place
• SharePoint : On a une liste de compte géré.

Note : On peut faire encore plus simple si l'on n'a pas besoin d'accéder aux ressources d'autres machines. On peut utiliser un compte système (ou un compte intégré à IIS par exemple)

3. La technique un peu plus évoluée

Si l'authentification Windows n'est pas disponible et qu'il faut sécuriser des données, on stocke les données cryptées dans un fichier de configuration. Mais avant de crypter les données, il faut commencer par extraire les clés machines qui serviront au cryptage.

Sans ces clés, votre fichier ne pourra pas être déployé hors de la machine qui a servi au cryptage. Ceci est très important pour une ferme IIS, ou pour un plan de reprise d'activité (PRA). Il s'agit là d'une erreur qui est malheureusement trop courante.

Il y a une documentation très claire que l'on peut trouver ici : http://msdn.microsoft.com/en-us/library/ff650304.aspx

Cette page date un peu, mais son contenu reste valable. Vous y trouverez le nécessaire pour sécuriser vos fichiers de configuration de manière fiable et portable.

Voilà. Vu que sécurité rime avec simplicité, j'espère que ces petites astuces vous seront utiles et vous faciliterons la tâche.