=======Guide de l'admin sys=======


====== 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 ! :-)


===== Organisation =====

  * **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 [[http://www.liberation.fr/societe/2013/04/07/la-dcri-accusee-d-avoir-fait-supprimer-sous-la-menace-un-article-sur-wikipedia_894252|plus sérieux]]).


===== Nos systèmes =====

  * **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-feux, vérification de //rootkits//, chiffrement de disque, etc.) et en s'assurant que les services installés sont à jour.