la-dessus je ne te rejoins pas djay. un accès « root » c’est avant tout une histoire de confiance et aussi d’engagement.
Si ces mots ont encore un sens pour certains …
Le pouvoir (tout comme le savoir) au contraire cela DOIT se partager … surtout , et avant toute chose ,si celui-ci est grand.
On me parle souvent de partage dans le logiciel libre ? … alors ok , donc à tout les niveaux.
Les 1% justement ne partagent pas le pouvoir et « on » sait tous que dans ce système de valeur , que je trouve médiocre, que le pouvoir c’est avant tout , et tristement … l’argent. (Money It’s a crime !)
Où je bosse on a des Techos, peu adminSys (parfois des buses), qui ont l’accès admin du domaine (c’est le root Windaube sur un annuaire) … yep monsieur, on ou plutot j’ai bien pris soin d’expliquer 3 choses :
en mode admin on peut tout casser donc on lis et réfléchis bien avant de cliquer (oui on clique sur Windaube) plutôt 3 fois qu’une,
il n y’a pas de honte à ne pas savoir : alors on demande de l’aide quand on ne sait pas (j’ai demandé quand j’ai monté le chatons … car je ne savais pas, et je ne regrette absolument pas !),
communiquer : l’humain fait des erreurs et c’est pour ça qu’il est intéressant, attachant … alors si on en fait une (même très grosse) on le dit, on ne cache pas … car tout se répare ! (si on ne sait pas réparer les conneries des"petites mains" on change de job … et oui, plus le level augmente plus les conneries sont chaudes à rattraper …) :
Ah, dernière chose, d’un vieux con , comme moi : quand on escalade on DOIT être sure d’être assuré solidement …
… eh bien le matin quand on arrive sur une prod. (quelle que soit sa taille, j’insiste) , quelque soit la taille : de la TPE à la tolle de plus de 280 000 comptes user … on demande l’état des sauvegardes : « dit camille on est dans le vert , orange ou rouge ce matin ? »
Ensuite on peut bosser, en tout état de cause, pas avant.
Sans vouloir faire les rabats-joie, ce que j’attends de vous, c’est des propositions de formulation (merci @djayroma pour la tienne), pas un débat de fond, qui a déjà eu lieu au début de ce post !
Le chaton DOIT avoir l’accès au plus haut niveau de droit (accès root) sur son serveur afin de garder un contrôle total sur les logiciels et données hébergés.
t’inquiètes je ne compte pas « dicter » à alolise (un seul gars avec le root donc …) sa politique de sécurité … j’ai déjà assez à faire avec une PSSI qui m’attend pour plus de 6000 personnes … ou je délègue déjà « le root » à 6 personnes de confiance …
Pour revenir à la charte : oui un accès root sur les serveurs ou vm ou conteneur semble être un critère minimum.
Mais : il doit être recommandé sur l’infrastructure, sinon on perd trop de monde.
Pareil… avec un ajout: la nécessaire transparence du chaton à ce sujet.
Nécessaire car comme on a des cas variables (root sur l’infra complète, root sur serveur dédié, root sur VM ou conteneur), il faut que chaque chaton annonce clairement la couleur.
Bon alors je vais essayer de « préciser » ma pensée pour ceux qui suivent pas au fond,
Cas n°1 : Tu me demande un serveur, je te donne des accès « user », tu casses : je répare
Cas n°2 : Tu me demande un serveur, je te donne des accès « user », tu me demandes des accès « root », je te les donnes, tu casses : TU répares
Y a pas à sortir de là, tout le reste va conduire invariablement à des prises de têtes sur qui a fait quoi dans quelles conditions et ça va finir en récupération de la sauvegarde (sauf qu’on saura pas forcément à quelle date à eu lieu le problème)… #My2coinsAdvice : Il y a UN root (personne, entité, entreprise, association whatever) mais pas de partage.
Pour le reste oui le chaton doit faire foi d’avoir accès au plus haut niveau root possible selon son infrasctructure (non partagé avec une autre structure).
Tout ceux qui prône le partage du root en mode bisounours n’ont jamais eu à démêler un problème grave de configuration d’infra implanté par un mec qui n’aurait jamais dû avoir l’accès root. (au hasard du chmod 777, de l’install de paquetage #oneagain, de l’ouverture (ou de la fermeture) de port à l’arrache et autres joyeusetés ou tout ça à la fois le tout non documenté bien sûr sinon c’est pas drôle)
@djayroma
Cas n°1 […] Cas n°2 […] Y a pas à sortir de là
Je pense, djayroma, que tu n’as pas saisi de qui on parle (parce que ça m’étonnerait que qui que ce soit soit en désaccord avec toi là-dessus, en particulier @cquest ou @anon6747921). On parle du chaton pas de ses usagers.
En effet, la phrase en question :
est« le CHATON doit avoir le contrôle total de l’infrastructure, des logiciels et des données associées (accès root) »
n’est pas« le CHATON doit donner [à ses usagers] le contrôle total de l’infrastructure, des logiciels et des données associées (accès root) »
Pour éviter cette confusion, je propose « le chaton (en minuscule) doit avoir le contrôle total de son infrastructure, des logiciels et des données associées. »
De plus, j’ajouterai : « Cela implique que :
Les droits d’administration (dits root) sur l’ordinateur sont requis.
L’accès physique à l’ordinateur (voire la propriété de l’ordinateur) est recommandé (cas de l’auto-hébergement) ».
En résumé, je propose :
Le chaton doit contrôler pleinement son infrastructure (matériels, logiciels et données associées). Cela implique que :
Les droits d’administration (dits root) sur l’ordinateur sont requis.
L’accès physique à l’ordinateur (voire la propriété de l’ordinateur) est recommandé (cas de l’auto-hébergement) ».
(EDITLOG: doit avoir le contrôle total → contrôler pleinement ; des logiciels et des données associées → matériels, logiciels et données associées.)
le CHATON doit publier sur une page des explications sur le degré de contrôle qu’il a sur son infrastructure.
le CHATON doit au minimum avoir les accès administrateur (accès root) sur le système d’exploitation faisant fonctionner les services en ligne finaux, ce qui exclu de facto l’usage d’un hébergement mutualisé loué.
le CHATON doit s’assurer de la localisation géographique de ses données (sauvegardes comprises)
En cas de location de serveur (virtuels ou dédiés), le CHATON doit s’assurer que le fournisseur s’engage contractuellement à ne pas accéder aux données OU doit s’assurer qu’il n’est pas facile techniquement d’y accéder (disques dur physiques dédiés et/ou chiffrement).
Critère recommandé:
le CHATON doit avoir le contrôle total de l’infrastructure , des logiciels et des données associées (accès root, hyperviseur compris). Il doit être le seul à pouvoir accéder techniquement aux données.
Note: il y a déjà des critères sur les fournisseurs qui doivent pas être en désaccord majeur avec la charte + un critère sur le logiciel libre (traités séparément)
EDIT: je me rend compte que nflqt m’a doublé !
Le chaton doit contrôler pleinement son infrastructure
==> va dire cela à Framasoft qui sont chez Heztner … ils ne contrôlent RIEN de l’infrastructure qui les héberge. (et heureusement pour les autres clients de Heztner !!) (ou alors je t’ai mal compris ;-))
je reformule :
Pour revenir à la charte : oui un accès root sur les serveurs ou vm ou conteneur semble être un critère minimum .
Mais : il doit être recommandé sur l’infrastructure , sinon on perd trop de monde.
nflqt:
Le chaton doit contrôler pleinement son infrastructure
==> va dire cela à Framasoft qui sont chez Heztner … ils ne contrôlent RIEN de l’infrastructure qui les héberge. (et heureusement pour les autres clients de Heztner !!) (ou alors je t’ai mal compris ;-))
Pour moi, la formulation « contrôler pleinement » arrondissait justement les angles de la formulation proposée un peu plus haut « avoir le contrôle total ».
De toute manière, il faut bien considérer que :
Je souhaite une charte qui décrit clairement un idéal… à atteindre un jour… ça presse pas tant qu’on va dans le bon sens… bon sens justement bien indiqué par une charte succinte et sans compromis.
Je ne souhaite pas qu’on affaiblisse les critères de la charte juste pour prendre en compte plus de cas litigieux, sous prétexte qu’on arrive pas à être souple dans l’application du texte.
Sinon, j’apprécie bien cette idée de distinctions entre :
Critères requis. Soient les « exigences », « les obligations », les « conditions » pour devenir un chaton. En bref, le minimum.
Critères recommandés. Soient les « préconisations », les « suggestions » pour devenir un superchaton ! En bref, le maximum.
Je vire la partie « …ce qui exclue de facto les serveurs mutualisés » (puisqu’ils sont exclus de facto )
Je vire la partie « localisation géographique » : c’est intéressant, mais on en a jamais discuté jusqu’à présent, et il faudrait rouvrir un nouveau débat (pourquoi pas, mais pas à l’arrache)
Je vire « …OU doit s’assurer qu’il n’est pas facile techniquement d’y accéder (disques dur physiques dédiés et/ou chiffrement). » : c’est trop flou pour un critère « requis ».
Je déplace « le CHATON doit publier sur une page des explications sur le degré de contrôle qu’il a sur son infrastructure. » : je serai pour que ça devienne un critère requis, mais il faudrait là encore avoir un débat sur la forme que devrait prendre cette publication. Là encore, c’est trop flou, donc ça ne peux pas devenir demain un critère « requis ». Par contre, en le mettant en « recommandé », on amorce la bonne pratique, et ça ouvre la voie pour le passer en « requis » lors d’une prochaine révision.
je précise « contrôle total de l’infrastructure » en indiquant « (serveurs et réseau) », car contrôle total de l’infrastructure pourrait aller jusqu’au contrôle de sa production énergétique, par exemple (panneaux solaires ? groupe electrogène ? etc) et ça me paraît too much pour CHATONS aujourd’hui.
Merci pour le résumé !
Cette formulation me semble exclure par exemple la possibilité d’avoir des backups sur un endroit non contrôlé, par exemple un prestataire externe, ou alors il faut être plus clair sur la définition de « services en ligne finaux ».
Avoir ses services sur un serveur à soi mais exporter des backups (chiffrées) vers un tiers « loin » de soi me semble un scénario tout à fait acceptable et souhaitable, notamment en cas de catastrophe…
je serai pour que ça devienne un critère requis, mais il faudrait là encore avoir un débat sur la forme que devrait prendre cette publication. Là encore, c’est trop flou, donc ça ne peux pas devenir demain un critère “requis”. Par contre, en le mettant en “recommandé”, on amorce la bonne pratique, et ça ouvre la voie pour le passer en “requis” lors d’une prochaine révision.
Je suis aussi pour que ça passe en « requis », mais pour une v3.
Parce que là, si on met en « requis » avec cette simple phrase, on va avoir plein de soucis avec :
les membres actuels qui, dans le flou, ne vont pas savoir où et comment rédiger cette partie
les membres à venir qui, dans le flou, vont venir nous poser plein de question sur « Comment informer », ou ce qui définit le « degré de contrôle ».
Ha ben service en ligne finaux signifiait justement pour moi « ceux accessibles aux utilisateurs » (justement pour pouvoir gérer le cas de la sauvegarde)
D’accord je vois, merci. Mais qu’en est-il par exemple si je propose un service nextcloud, backupé donc auprès d’un tiers (chiffré/sauvegarde incrémentale) et qu’un utilisateur vient chez moi parce que justement il a besoin de cette offre avec un backup « raisonnablement safe » et versionnning, est-ce que ça fait du service « backup » un service final dont du coup il est exclu d’avoir affaire à un tiers ? (là je pars dans l’hypothétique)
soit ton service CHATON, c’est de proposer du backup, et tes bénéficiaires peuvent (avec les accès nécéssaires) aller directement rechercher/remonter leurs sauvegardes. C’est un « service final ». Tu dois avoir l’accès root et t’assurer de la sécurisation des données.
soit (ton exemple) tu propose un service final (Nextcloud) avec une capacité de backups chiffrés (« ailleurs », type https://www.rsync.net/ ), mais c’est toi qui remonte les backups en cas de souci. Alors, dans ce cas, ce n’est pas un service final (le bénéficiaire n’y a pas accès).
Cela me paraît indispensable de préciser les critère requis/recommandés (et c’est un des gros points de cette révision).
)