Imaginez vous faites partie d'une asso, et de fil en aiguille vous vous rendez compte que beaucoup de choses sont faites à la main, sur un coin de table, et que ça fait surtout trois AG de suite que personne ne sait qui gère quel compte ou que la personne en charge des mails a disparu de la circulation et avec les identifiants des boîtes mail. Pire encore, les identifiants des sites web sont partagées sur une page non répertoriée (mais bien accessible) sur le site de l'asso, et vous soupçonnez déjà du monde de s'en servir pour récupérer des infos ou vous nuire.
Sans aller jusque là, je l'ai fait (plusieurs fois), donc je vous évite d'avoir à le faire aussi.
Ce guide n'a pas vocation à couvrir tous les cas, ni à s'appliquer à toutes les structures associatives. Celui-ci en particulier n'aura d'intérêt que pour une structure ayant au-moins quelques milliers d'adhérents avec une certaine présence en ligne (les assez grosses fédés ou leurs antennes régionales), qui souhaite développer et utiliser ses propres outils, ou qui souhaite être particulièrement prudente vis à vis de ses adhérents. Ce guide n'est pas non plus un remplacement d'une politique de gestion des utilisateurs en entreprise, qui peuvent bénéficier d'outils plus adéquats. Cependant si vous l'utilisez en entreprise, pensez à le signaler !
Dans ce guide, on décrit notamment le cycle de vie des identifiants partagés (comptes de service, boîtes mail...), les rôles, les reponsabilités que peuvent prendre certains adhérents. Les comptes nominatifs ne sont pas décrits mais peuvent suivre ces recommanations.
Rôles et responsabilités
Ce guide fait référence aux rôles suivants et à leurs responsabilités :
- Responsable des contrôles d'accès
- Utilisateur
Moyens de stockage
Base de données d'identifiants
Pour des raisons de robustesse et d'intéropérabilité, les identifiants des différents services, sites et boîtes mails sous la responsabilité du responsable des contrôles d'accès sont stockés dans des bases de données Keepass. Celles-ci offrent un niveau de protection nettement suffisant et fonctionnent avec suffisamment de clients disponibles sur tous les systèmes d'exploitation.
Il est fortement recommandé de séparer les bases d'identifiants selon les niveaux d'accès (adhérents mandatés ou admins avec comptes privilégiés), en les protégeant avec des mots de passe ou des clés différentes à chaque fois.
Stockage de la base de données
La base de données au format Keepass doit être stockée [[TODO: Quelque-part]]. Son accès doit être réservé aux utilisateurs potentiels de cette base de mots de passe, et donc être accessible depuis une page spécifique, un répertoire partagé, ou partagée par un autre canal.
Cycle de vie de la base d'identifiants
Création
Avant de créer la base de données, les identifiants qui y seront stockés doivent être énumérés (sans les divulguer), afin d'éviter des oublis dans la version en cours, et d'identifier de quelle manière ils seront transmis jusque dans la base de données. La base de données est initialement créée par le ou la camarade mandaté·e pour la gestion des identifiants sur un PC le plus sain possible [[NOTE: on pousse jusqu'à utiliser Tails et une clé USB chiffrée ?]] possédant un client Keepass.
La base Keepass doit répondre aux critères suivants :
| Mot de passe principal | 16+ caractères alphanumériques et spéciaux |
| ou KeyFile | Généré par Keepass |
| Chiffrement | AES |
| Dérivation de clé | AES-KDF 60000 itérations |
| Forcer le changement de la clé maître | 365 jours |
Il s'agit des options par défaut, avec en plus l'obligation de changer la clé maître tous les ans.
Une fois le fichier initial créé, la base de données est alimentée à partir des identifiants précédemment énumérés de la manière décrite au chapitre [#Identifiants].
Une fois les identifiants initiaux inscrits dans la base de données, ils sont immédiatement renouvelés (les versions des identifiants antérieures à la création de cette base devenant ainsi obsolètes) de la manière prévue au chaputre [#Renouvellement].
Une fois tous les identifiants inscrits et renouvellés une première fois, la base de données est validée, stockée, diffusée aux personnes devant y accéder, et sa première version inscrite dans le tableau de [#Gestion de versions].
Identifiants
Chaque identifiant stocké dans la base de données doit répondre aux critères suivants :
| Nom de l'entrée | Nom du site ou du service et éventuelle fonction du compte (admin, user, service...) |
| Identifiant | L'identifiant |
| Mot de passe | Généré automatiquement avec le pattern décrit ci-après |
| URL | Rensignée pour les sites web |
| Notes | Informations supplémentaires pour le renouvellement (besoin de confirmer sur une adresse mail, ou méthode de récupération) |
| Expiration | Définie par [#Récurrence] |
La génération de mots de passe doit utiliser le pattern suivant par défaut :
- 20 caractères
- Casse haute (A, B, C...)
- Casse basse (a, b, c...)
- Numériques (0, 1, 2...)
- Spéciaux (!, ?, $...)
Gestion de versions
A chaque renouvellement quelle qu'en soit la raison, une nouvelle version se voit être publiée. Lorsque c'est fait, le tableau de gestion des versions en bas de la page doit être mis à jour afin de garder une trace de la modification. Dans ce tableau doivent figurer la personne mandatée pour coordonner le renouvellement des identifiants et la publication de la nouvelle version, la date de publication, ainsi que la date prévue d'expiration tel que prévue dans le chapitre [#Renouvellement].
Accès
La base d'identifiants et son mot de passe ou sa clé ne doivent jamais être transmis sur le même canal ou stockés sur le même support.
Après sa création, la base d'identifiants est stockée [[TODO: Quelque-part]]. L'accès doit être restreint aux seuls utilisateurices autorisés à accéder aux comptes dans la base de données, et donc la base de données ne peut être rendue accessible depuis une page publique.
Dans le même temps, le mot de passe principal ou la clé de la base sont partagés individuellement. Les utilisateurices sont alors encouragé·e·s à remplacer le mot de passe prévu initialement par leur propre mot de passe si la base vient à être stockée localement.
Renouvellement
C'est l'heure du ménage de printemps.
Récurrence
Les opérations de renouvellement se font ordinairement tous les six mois. Si un renouvellement extra-ordinaire doit avoir lieu, il termine prématurément la période en cours et relance une nouvelle période de six mois.
Renouvellement des identifiants dans la base
Lors du renouvellement des identifiants, un nouveau mot de passe doit être généré à partir du pattern décrit dans [#Identifiants]. Si une confirmaiton de modification est demandée par mail, il faudra se coordoner avec un·e camarade ayant accès à la boîte mail dédiée.
Lorsque le nouveau mot de passe est confirmé, l'entrée dans la base peut être enregistrée.
Renouvellement des clés de la base d'identifiants
De la même manière que les identifiants qu'elle contient sont renouvelés, la clé principale de la base de données doit être renouvelée.
| Mot de passe principal | 16+ caractères alphanumériques et spéciaux |
| ou KeyFile | Généré par Keepass |
Cette modification marque alors la nouvelle version de la base de données qui annule et remplace la version précédente et ne sera plus d'aucune utilité.
Révocation
La révocation de l'accès à la base de mots de passe se fait lorsqu'un·e adhérent·e quitte le rôle de responsable des contrôles d'accès, ou lors d'une compromission avérée ou suspectée d'au-moins un identifiant. La clé de la base de données ainsi que les identifiants qu'elle contient sont alors tous renouvelés au titre d'un [#Renouvellement].
Compromission de la base d'identifiants
Si la base d'identifiants venait à être compromise, il devient une nécessité urgente de modifier immédiatement les identifiants stockés dans la base d'identifiants ainsi que les clés de la base. Un ou plusieur membres responsables des contrôles d'accès peuvent se réunir de manière extraordinaire pour coordonner la modification des identifiants en suivant la procédure de [#Révocation] décrite plus haut, et la mise à jour de la nouvelle base avec les nouveaux identifiants des utilisateurs.
Si un identifiant est compromis, il faudra aussi s'assurer qu'il puisse être récupéré dans un premier temps, et comprendre les raisons de sa compromission pour éviter de le reproduire. Si un compte est définitivement perdu, il faudra s'assurer qu'il soit dissocié de l'asso.
Versions de la base d'identifiants
Ci-dessous une proposition d'historique des versions de la base de données.
| Ver. | Publication | Expiration | Mandaté | Commentaires |
|---|---|---|---|---|
| 1.0 | yyyy-mm-dd | yyyy-mm-dd | Smith | Première version de la base de données. |