Lignes directrices pour les adminsys

L'administration système pour une association est un passe-temps formidable autant qu'indispensable, mais il faut respecter quelques règles pour rendre cette activité pérenne et protéger au mieux les données personnelles que nous hébergeons.

Idée : écrire des lignes directrices génériques, qui ne dictent pas d'outils en particuliers mais une politique à suivre et de grands objectifs à viser. Elles pourraient être revues/discutées périodiquement (tous les X mois).

Travail en cours !

• Documenter ce qu'on met en place pour les utilisateurs et les autres adminsys : si un autre adminsys ne sait pas comment fonctionne le service, il ne voudra pas y toucher ou bien cassera tout en y touchant ;
• Prévenir les autres adminsys avant d'agir : quelqu'un d'autre a peut-être déjà résolu le problème, a une idée différente sur la façon de faire, ou encore soulèvera un problème auquel on n'a pas pensé ;
• Posséder une clé PGP et faire signer cette clé par les autres adminsys, pour l'échange d'informations importantes ;
• Produire une recette de gestionnaire de configuration pour chaque service mis en place (le gestionnaire utilisé actuellement est Ansible) : cela aidera les autres admins à comprendre ce qui est mis en place, à travailler collaborativement l'administration et à plus facilement transférer la configuration d'une machine à l'autre ;
• Résister aux pressions extérieures qui viseraient à forcer un adminsys à révéler indûment des données sur l'association ou ses adhérents (ne pas hésiter à en parler aux autres, ou bien demander la suppression de ses propres droits si le cas est plus sérieux).

• Avoir une séparation logique entre bases de données et services exposés publiquement, d'une part pour réduire l'impact si ces derniers sont compromis et d'autre part pour faciliter le déplacement d'un composant ou d'un autre ;
• Avoir des listes de contrôle d'accès claires concernant l'accès aux données non publiques, en s'assurant que les accès effectifs sont cohérents avec ce que souhaite l'association ;
• Rendre traçable les accès aux données personnelles ;
• Ne pas dupliquer des données non publiques identiques dans plusieurs bases sauf dans le cas des copies de sauvegarde ou de fichiers partagés entre tous les membres (typiquement les dépôts git) ;
• Héberger toute donnée non publique exclusivement sur des machines de l'association
• Proposer une connexion chiffrée pour tous les services qui soit à jour vis-à-vis des dernières menaces connues, tout en prenant en compte les contraintes d'utilisabilité (exemple : anciens navigateurs et algorithmes de chiffrements jugés un peu trop faibles) et de coût (exemple : la certification TLS coûte un peu d'argent) ;
• Décentraliser et redonder tout service qui ne pose pas de question de données personnelles ;
• Sécuriser les serveurs contre les accès illégitimes avec des méthodes jugées appropriées (pare-feus, vérification de rootkits, chiffrement de disque, etc.) et en s'assurant que les services installés sont à jour.