diff options
author | ADRN <adrien@luxeylab.net> | 2024-12-08 11:58:31 +0100 |
---|---|---|
committer | Marion <marionz@deuxfleurs.fr> | 2024-12-08 17:33:54 +0100 |
commit | 322457d8e58c3dffe9f42931deebfd87be779d87 (patch) | |
tree | 069e639ee3ebc957f59bb5124589ae194768aab7 /content/infrastructures | |
parent | 67e63906eb83cf7e0abda13aaa1b5830e99d185e (diff) | |
download | guide.deuxfleurs.fr-322457d8e58c3dffe9f42931deebfd87be779d87.tar.gz guide.deuxfleurs.fr-322457d8e58c3dffe9f42931deebfd87be779d87.zip |
feat(infrastructure): relecture et modification de contenu
Diffstat (limited to 'content/infrastructures')
-rw-r--r-- | content/infrastructures/_index.md | 5 | ||||
-rw-r--r-- | content/infrastructures/energie.md | 2 | ||||
-rw-r--r-- | content/infrastructures/logiciels.md | 80 | ||||
-rw-r--r-- | content/infrastructures/machines.md | 48 | ||||
-rw-r--r-- | content/infrastructures/reseau.md | 2 | ||||
-rw-r--r-- | content/infrastructures/services.md | 16 |
6 files changed, 91 insertions, 62 deletions
diff --git a/content/infrastructures/_index.md b/content/infrastructures/_index.md index 6df4ee7..8478b5c 100644 --- a/content/infrastructures/_index.md +++ b/content/infrastructures/_index.md @@ -2,10 +2,15 @@ title: "Infrastructures" description: "Infrastructures" weight: 40 +sort_by: weight extra: parent: 'infrastructures/_index.md' --- Ce manuel documente la dimension matérielle du numérique chez Deuxfleurs. On y recense les ordinateurs, le lieu où ils sont, les connexions réseaux nécessaires, l'énergie consommée, l'impact de fabrication, de fin de vie, etc. +> Vu la quantité de logiciels et de machines impliquées (et la fâcheuse tendance de nos membres à déménager), il est fort probable que les informations présentées ici soient **obsolètes**. +> Cependant, ces pages ont été vraies il n'y a pas si longtemps : leur lecture vous informera quand même sur notre pratique de l'hébergement de services numériques.\ +> Pour connaître l'état précis de nos infrastructures, il faudrait plutôt lire notre dépôt [`nixcfg`](https://git.deuxfleurs.fr/Deuxfleurs/nixcfg) – qui décrit techniquement nos machines et services à tout instant. +> Bonne lecture ! diff --git a/content/infrastructures/energie.md b/content/infrastructures/energie.md index 2728825..51d56ee 100644 --- a/content/infrastructures/energie.md +++ b/content/infrastructures/energie.md @@ -3,7 +3,7 @@ title: "Énergie" description: "Consommation électrique" date: 2021-11-09T12:54:33.129Z dateCreated: 2021-11-09T12:54:30.985Z -weight: 20 +weight: 40 extra: parent: 'infrastructures/_index.md' --- diff --git a/content/infrastructures/logiciels.md b/content/infrastructures/logiciels.md index f931260..4b5e9bc 100644 --- a/content/infrastructures/logiciels.md +++ b/content/infrastructures/logiciels.md @@ -1,19 +1,25 @@ --- -title: Développement logiciel -description: Logiciels -weight: 90 +title: Nos créations +description: Les logiciels que l'on développe +weight: 30 sort_by: weight draft: false date: 2024-01-24 extra: - parent: infrastructures/_index.md + parent: infrastructures/services.md --- -Cette section recense les logiciels développés par Deuxfleurs pour les besoins spécifiques de son infra. +Cette section recense les logiciels développés par Deuxfleurs pour les besoins spécifiques de son infrastructure : [Garage](@infrastructures/garage.md), [Bottin](@infrastructures/bottin.md), [Guichet](@infrastructures/guichet.md), [Tricot](@infrastructures/tricot.md), [Diplonat](@infrastructures/diplonat.md)...\ +Cette page en particulier présente nos choix de conception. + # Principes de conception -Nou essayons de suivre plusieurs principes pour une conception qui correspond au besoin tout en ayant un ensemble de logiciels homogènes. +Deuxfleurs reconnaît l'importance sociale des choix techniques. +N'importe quel outil est imbibé de l'idéologie de la société qui l'a vu naître – et en retour, il impose son idéologie aux sociétés à venir. +Sachant cela, on arbitre nos choix techniques en regardant en premier lieu ce qu'ils vont impliquer socialement. +Cela fait de nos infrastructures une bizarrerie pour qui est habitué⋅e aux pratiques de l'informatique industrielle. +Nous essayons de suivre plusieurs principes pour une conception qui correspond au besoin tout en ayant un ensemble de logiciels homogènes. ## Vie privée @@ -23,48 +29,52 @@ Que ce soit à l'intérieur ou l'extérieur de l'association, des demandes pour Quelques propriétés en vrac qu'on peut, ou ne pas, désirer : -### Messagerie instantanée +#### Messagerie instantanée - - Je ne veux pas que le contenu de mes messages et des fichiers que je partage soient accessibles (eg. une photo que j'ai prise, mes réactions) - - Je ne veux pas que les métadonnées autour de mes messages soient accessibles (eg. les salons de discussions auxquels je prends pars, l'horodatage des messages, les personnes avec qui j'échange) - - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service, depuis où, si j'intéragis sur le réseau, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocole (autres personnes dans le salon de communication, horodatage, etc.) + - Je ne veux pas que le contenu de mes messages et des fichiers que je partage soient accessibles à des tiers (_e.g._ une photo que j'ai prise, mes réactions). + - Je ne veux pas que les métadonnées autour de mes actions soient accessibles à des tiers (_e.g._ les salons de discussions auxquels je prends part, l'horodatage des messages, les personnes avec qui j'échange). + - Je ne veux pas que mes métadonnées de communication soient accessibles (_e.g._ quand je me connecte à un service, depuis où, si j'intéragis sur le réseau, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocole (autres personnes dans le salon de communication, horodatage, etc.). -### Courrier électronique (de l'email au mixnet) +#### Courrier électronique (de l'e-mail au mixnet) - - Je ne veux pas que le contenu de mes emails et pièces jointes soit lisible (eg. le doc que j'ai joint) - - Je ne veux pas que les métadonnées autour de mon message soient accessibles (eg. le destinataire, l'expéditeur, l'horodatage, le client email utilisé, le sujet du mail, le dossier dans lequel il est stocké) - - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand je me connecte au service email, depuis où, quand j'intéragis sur le réseau), ces données permettent parfois d'inférer des métadonnées sur le protocole (destinataires, présence de pièce jointe, etc.) + - Je ne veux pas que le contenu de mes e-mails et pièces jointes soit lisibles par des tiers (_e.g._ le doc que j'ai joint). + - Je ne veux pas que les métadonnées autour de mon message soient accessibles (_e.g._ le destinataire, l'expéditeur, l'horodatage, le client e-mail utilisé, le sujet du mail, le dossier dans lequel il est stocké). + - Je ne veux pas que mes métadonnées de communication soient accessibles (_e.g._ quand je me connecte au service e-mail, depuis où, quand j'intéragis sur le réseau). + Ces données peuvent permettre d'inférer des informations importantes sur mes correspondant⋅es et moi-même (destinataires, présence de pièce jointe, etc.). -### Synchronisation et collaboration sur des fichiers - - Je ne veux pas que le contenu de mes fichiers soit accessible - - Je ne veux pas que les métadonnées de mon fichier soient accessibles (eg. nom du fichier, dossier, format, taille, hash, etc.) - - Je ne veux pas que les métadonnées de communication soient accessibles (eg. quand j'accède au document, depuis où, qui d'autre, combien de fois, etc.), ces données permettent parfois d'inférer des métadonnées sur le protocole (taille, collaborateurs, type, etc.) +#### Synchronisation et collaboration sur des fichiers + - Je ne veux pas que le contenu de mes fichiers soit accessible à des personnes non autorisées. + - Je ne veux pas que les métadonnées de mes fichiers soient accessibles (_e.g._ nom du fichier, dossier, format, taille, hash, etc.). + - Je ne veux pas que mes métadonnées de communication soient accessibles (_e.g._ quand j'accède au document, depuis où, qui d'autre, combien de fois, etc.). + Ces données peuvent permettre d'inférer des informations importantes sur mes correspondant⋅es et moi-même (taille, collaborateurs, type, etc.). -## Attaquants +## Modèles d'attaquants -Quelques attaquants que l'on peut, ou ne pas, considérer : +Dans le domaine de la sécurité, on commence toujours par décrire l'« attaquant » : ses capacités, le temps dont iel dispose... +Car il n'existe aucune défense qui protège de toutes les attaques : il faut donc savoir contre qui on est en mesure de se défendre, ou pas. +Suivent quelques attaquants potentiels : - - Hébergeur de la machine (eg. branche un clavier et un écran sur l'ordi et récupère un accès admin) - - Administrateur Système (eg. utilise ses accès privilégiés pour accéder volontairement ou non à du contenu privé) - - Développeurs (eg. ajout d'une porte dérobée au moment de l'écriture du code) - - Chaîne logistique (eg. ajout d'une porte dérobée au moment de déployer l'app sur les serveurs ou le terminal de l'utilisateur) - - Opérateur Internet (eg. Orange) - - Regroupement d'opérateurs internet (cf "Tor netflow") - - Personne externe via internet (eg. hacker) - - Personne externe physique (eg. voleur) - - Regroupement d'acteurs (eg. opérateurs internet, externe physique ET internet) - - Utilisateurs (eg. pas de chiffrement sur son téléphone) + - Administrateur Système (_e.g._ utilise ses accès privilégiés pour accéder volontairement ou non à du contenu privé) + - Hébergeur de la machine non administrateur (_e.g._ branche un clavier et un écran sur l'ordi et récupère un accès admin) + - Développeurs (_e.g._ ajout d'une porte dérobée au moment de l'écriture du code d'un logiciel qu'on utilise) + - Chaîne logistique (_e.g._ ajout d'une porte dérobée au moment de déployer un logiciel sur les serveurs ou le terminal de l'utilisateur) + - Opérateur Internet (_e.g._ Orange), voit passer une partie de notre trafic + - Regroupement d'opérateurs Internet (cf "Tor netflow") + - Personne externe via Internet (_e.g._ hacker) + - Personne externe physique (_e.g._ voleur) + - Regroupement d'acteurs (_e.g._ opérateurs internet, externe physique ET internet) + - Usager⋅es, qui peuvent se faire pirateur leurs données par ailleurs (_e.g._ téléphone non protégé) ## Un exemple de ce qu'on pourrait faire Prenons l'exemple de la messagerie instantanée. Pour l'instant, on peut définir les types de réseaux suivants : - centralisé, pas chiffré (Messenger) -- centralisé, chiffé de bout en bout (avec toute une gamme d'implems, la meilleure étant peut-être Signal) -- fédéré, pas chiffré (E-mail, IRC, XMPP sans omemo, Matrix sans E2EE) +- centralisé, chiffé de bout en bout (il y en a une grande quantité, la meilleure étant peut-être Signal) +- fédéré, pas chiffré (E-mail, IRC, Matrix sans chiffrement de boût en boût (E2EE), XMPP sans Omemo) - fédéré, chiffré (XMPP + Omemo, Matrix + E2EE) - distribué, chiffré (Tox, Retroshare) -- distribué avec des mécanisme d'anonymat fort (Freenet, Mix networks, ...) +- distribué avec des mécanisme d'anonymat fort (Freenet, Mix networks) Seule la dernière catégorie s'adresse au cas d'un "global passive attacker". On peut imaginer d'abandonner l'idée d'avoir une protection très efficace contre ce dernier car ça serait très contraignant sur le design et l'utilisabilité, et les cas où on en aurait vraiment besoin sont des cas particuliers où on peut faire l'effort d'utiliser une solution adaptée. @@ -92,5 +102,5 @@ Concernant la seconde approche, celle-ci semble beaucoup plus à notre portée : ## Ressources - - https://about.psyc.eu/Federation et https://about.psyc.eu/PSYC2 - - Définition d'un mixnet : https://www.youtube.com/watch?v=dQtk0NcTseg + - [https://about.psyc.eu/Federation](https://git.deuxfleurs.fr/Deuxfleurs/nixcfg) et [https://about.psyc.eu/PSYC2](https://about.psyc.eu/PSYC2) + - Définition d'un mixnet : [https://www.youtube.com/watch?v=dQtk0NcTseg](https://www.youtube.com/watch?v=dQtk0NcTseg) diff --git a/content/infrastructures/machines.md b/content/infrastructures/machines.md index f75590d..17c37f4 100644 --- a/content/infrastructures/machines.md +++ b/content/infrastructures/machines.md @@ -1,7 +1,7 @@ --- title: "Nos serveurs" description: "La salle des machines" -weight: 40 +weight: 10 sort_by: "weight" extra: parent: 'infrastructures/_index.md' @@ -9,31 +9,41 @@ extra: Ce coin du Guide présente les ordinateurs qui constituent notre infrastructure et leurs différents rôles. -# Différents clusters +Promouvant la **sobriété numérique**, on veille à ne pas consommer plus de ressources que nécessaire pour fournir les services de l'association. +On utilise par exemple exclusivement des ordinateurs de bureau datés de quelques années (souvent rachetées à bas prix au [domaine](https://encheres-domaine.gouv.fr/hermes/biens-mobiliers/high-tech)). +Car un serveur n'est jamais qu'un ordinateur qui exécute des logiciels fournissant des services. Votre téléphone pourrait tout aussi bien assurer cette mission. +Mais un serveur, ça doit être prêt à répondre aux requêtes à n'importe quelle heure. +Toutes les machines présentées ici sont donc branchées 24/7 dans l'attente que vous vous y connectiez. +Ça en fait de la [consommation électrique](@/infrastructures/energie.md) ! + +Notre approche vers la sobriété, c'est de **visibiliser la matérialité** du numérique. +C'est le but de ces pages : qu'on puisse constater ce qu'il en coûte matériellement que d'héberger vos e-mails et sites web de façon sobre et résiliente. -Nous avons mis en réseau une dizaine de machines, des ordinateurs de bureau, réunies en deux principaux rôles ou _clusters_ : +# Différents clusters +Parmi les machines directement géréees par Deuxfleurs, se trouvent deux principaux rôles ou _clusters_ : -Nous avons identifié 4 rôles pour nos serveurs, en fonction de la criticité des charges de travail -et des données qu'ils auront à gérer. +<!-- Nous avons mis en réseau une dizaine de machines, des ordinateurs de bureau, réunies en deux principaux rôles ou _clusters_ : --> -[Production](@/infrastructures/production.md) - Les serveurs de productions sont ceux qui font tourner les services accédés par les usager·es (eg. Plume, Matrix, Cryptpad). -Si ils sont inaccessibles, alors les services ne fonctionnent plus. Et si une personne malveillante y accède, elle peut avoir accès à des données -personnelles des usager·es. C'est donc le rôle le plus critique. +- [Production](@/infrastructures/production.md) - Les serveurs de productions sont ceux qui font tourner les services accédés par les usager·es (eg. Plume, Matrix, Cryptpad). + S'ils sont inaccessibles, alors les services ne fonctionnent plus. + Et si une personne malveillante y accède, elle peut avoir accès à des données personnelles des usager·es. C'est donc le rôle le plus critique. +- [Expérimentation](@/infrastructures/xp.md) - Les serveurs d'expérimentation servent à tester les nouvelles configurations, les nouveaux logiciels, et le nouveau matériel. + Ils permettent aux opérateur·ices de se familiariser avec leurs modifications et de minimiser l'impact d'un changement sur les serveurs de production, et donc sur la disponibilité des services. + Ces machines ne contiennent pas de données personnelles et ne sont pas critiques, elles n'ont pas besoin de rester tout le temps allumées. + Il n'est pas nécessaire d'être opérateur·ice pour gérer une de ces machines. -[Support](@/infrastructures/support.md) - Les serveurs de support servent pour les sauvegardes et la supervision des serveurs de production (eg. Grafana, Minio). -De par leur rôle, ils participent au bon fonctionnement de la production. -Ils n'ont pas de données personnelles brutes mais les métriques collectées peuvent refléter certains comportement des usager·es -et les sauvegardes, bien qu'elles soient chiffrées, contiennent tout de même des données personnelles. +Il est des fonctions annexes (comme les sauvegardes, le développement ou la supervision) qu'il convient de ne pas héberger directement sur les ordinateurs que l'on administre : +au cas où ce seraient justement nos logiciels d'administration qui déconnent, ainsi que pour éviter que les dysfonctionnements de ces machines n'impactent les services en production. +On compte deux clusters de ce type : -[Développement](@/infrastructures/developpement.md) - Les serveurs de développement hébergent les outils qui nous permettent de travailler sur le logiciel, -les configurations, les tickets, ou la compilation. Ils ne contiennent pas de données personnelles mais peuvent être utilisés pour -des attaques de chaîne d'approvisionnement (*supply chain attack*). À terme, ce rôle pourrait être fusionné avec la production. +- [Support](@/infrastructures/support.md) - Les serveurs de support servent pour les sauvegardes et la supervision des serveurs de production (eg. Grafana, Minio). + Ils participent au bon fonctionnement de la production. + Ils n'ont pas de données personnelles brutes mais contiennent des métriques qui reflètent le comportement des usager·es ; ainsi que nos sauvegardes régulières, qui sont chiffrées (et donc illisibles sans la bonne clé), mais contiennent tout de même des données personnelles. +- [Développement](@/infrastructures/developpement.md) - Les serveurs de développement hébergent les outils qui nous permettent de travailler sur le logiciel, les configurations, les tickets, ou la compilation. + Ils ne contiennent pas de données personnelles mais peuvent être utilisés pour des attaques de chaîne d'approvisionnement (*supply chain attack*). + À terme, ce rôle pourrait être fusionné avec la production. -[Expérimentation](@/infrastructures/xp.md) - Les serveurs d'expérimentation servent à tester les nouvelles configurations, les nouveaux logiciels, -et le nouveau matériel. Ils permettent aux opérateur·ices de se familiariser avec leurs modifications et de minimiser l'impact d'un changement sur les serveurs de production, -et donc sur la disponibilité des services. Ces machines ne contiennent pas de données personnelles et ne sont pas critiques, elles n'ont pas besoin de rester tout le temps allumées. -Il n'est pas nécessaire d'être opérateur·ice pour gérer une de ces machines. # Zones diff --git a/content/infrastructures/reseau.md b/content/infrastructures/reseau.md index 3e38f6f..5267bc1 100644 --- a/content/infrastructures/reseau.md +++ b/content/infrastructures/reseau.md @@ -3,7 +3,7 @@ title: "Réseau" description: "Réseau" date: 2021-11-09T12:55:03.277Z dateCreated: 2021-11-09T12:55:01.156Z -weight: 30 +weight: 50 extra: parent: 'infrastructures/_index.md' --- diff --git a/content/infrastructures/services.md b/content/infrastructures/services.md index b47dfdf..7c6412f 100644 --- a/content/infrastructures/services.md +++ b/content/infrastructures/services.md @@ -1,14 +1,18 @@ --- -title: "Services" -description: "Annuaire des services hébergés chez Deuxfleurs" -weight: 10 +title: "Les logiciels" +description: "Annuaire des logiciels utilisés par Deuxfleurs" +weight: 20 extra: parent: 'infrastructures/_index.md' --- -Cette page tente de recenser de façon exhaustive l'ensemble des services qui -fonctionnent actuellement sur les machines de Deuxfleurs, dans les différents -rôles identifiés : production, développement, expérimentation, etc. +Cette page tente de recenser de façon exhaustive l'ensemble des applications qui assurent le fonctionnement de Deuxfleurs, et leurs rôles respectifs (production, support...). +On détaille les logiciels que l'on développe nous-même à [la page suivante](@/infrastructures/logiciels.md). + +> On répète que cette liste est condamnée à être obsolète, n'étant pas mise à jour à chaque modification de nos infrastructures.\ +> Si vous voulez connaître l'état du monde à l'instant _t_, équipez-vous d'une personne technicienne et allez plutôt lire notre dépôt [`nixcfg`](https://git.deuxfleurs.fr/Deuxfleurs/nixcfg) – qui décrit formellement l'état de toutes nos machines. + +C'est parti pour la liste à la Prévert : | Service | Rôle | Site | Description | | -- | -- | -- | -- | |