Bonjour,
Enough est un CHATONS mais c’est aussi une instance de l’infrastructure as code qui est au cœur du projet. Quand une organisation veut « utiliser Enough » elle a le choix entre utiliser l’instance publique https://enough.community et faire confiance aux personnes qui la maintiennent. Ou bien d’exécuter le code sur ses propres machines pour éliminer un intermédiaire technique susceptible de trahir leur confiance. Non seulement c’est une bonne idée pour éviter les fuites. Mais en plus c’est moins stressant pour les mainteneurs bénévoles d’un service public qui contiendrait beaucoup de données confidentielles, merci pour nous 
Ça ressemble à un équilibre idéal, mais ce serait trop beau si ça couvrait tous les cas de figure. Quand le modèle de menace et le degré de maturité d’une organisation se satisfait d’héberger des services sur des machines opérées par des tiers (i.e. les nuages), alors c’est parfait. A titre d’exemple, si une organisation utilise les services de Google et Zoom au quotidien, basculer sur une instance Enough qu’elle contrôle avec Nextcloud et Jitsi est une amélioration sensible, quel que soit son modèle de menace.
Mais une fois que cette indépendance est acquise et qu’on se penche de nouveau sur le modèle de menace, il est possible qu’on arrive à la conclusion qu’OVH ou Fuga (les deux fournisseurs de machines virtuelles OpenStack sur lesquels repose Enough) présentent un risque qu’il convient d’écarter. Quand on sait que le fournisseur de machines virtuelles a littéralement le contrôle du processeur et du disque de la machine, chiffrer les échanges n’est pas la solution. Il faut impérativement en sortir et migrer les services sur des machines physiques.
C’est pour ces cas, rares mais impossibles à écarter, que SecureDrop fait partie des services d’Enough. Pour l’installer il faut (en gros) acheter le matériel, trouver ou le brancher et suivre la procédure d’installation. On est loin de l’infrastructure as code et les deux peuvent co-exister dans une organisation en vivant leur vie sans aucun lien.
Mais, et j’en viens à ce qui me préoccupe, il devrait exister un chemin pour aller de l’un à l’autre, pour sortir du « nuage » et aller sur des machines physiques, sans que les méthodes soient totalement différentes. Par exemple on peut imaginer un collectif de journalistes qui se contente parfaitement d’être sur les machines virtuelles de Fuga pendant plusieurs années. Jusqu’au jour ou il s’engage dans une longue enquête dans laquelle Fuga est impliqué. Il décide de sortir de Fuga pendant ce temps et de déplacer tous ses services sur des machines physiques: l’effort est conséquent, il faut acheter le matériel, trouver un hébergement, et faire la migration. Et quand l’enquête est terminée, le collectif peut être tenté de se débarrasser des machines physiques pour retourner dans le « nuage ».
La voie dans laquelle j’envisage d’aller pour tracer ce chemin consiste à faire tourner des machines virtuelles sur les machines physiques en les gérant avec libvirt et KVM, parce qu’ils partagent avec OpenStack un format d’échange (qcow2) de machines virtuelles qui permet, justement, de passer de l’un à l’autre avec un minimum de friction. C’est bien sur plus lourd qu’utiliser des containers (LXC, Docker, K8S) mais cela permet de réutiliser à l’identique le code de l’infrastructure: l’environnement physique est compatible avec l’environnement virtualisé.
C’est une réflexion en cours et rien n’est encore vraiment définitif, même si je suis assez convaincu que c’est la bonne direction. Mais c’est aussi ce qui me motive a l’exposer ici, pour le cas ou j’ai raté un problème évident. Je serais assez déçu, je ne le cache pas. Mais j’aime autant y faire face plus tôt que plus tard
Qu’en dites vous ?