Ça nécessite une analyse complète de la surface d'attaque, analyse qui est en cours. Mon idée actuelle, c'est :
architecture mono-serveur (voire bare-metal) : les données et l'appli web sur le même système (le SGBD n'écoutant pas sur le réseau, uniquement en local). Car en pratique, la compromission de l'appli web a les mêmes effets que la compromission que le SGBD, donc les 2 doivent être aussi bien protégés.
partir du mode d'emploi stockage chiffré intégral sur serveur distant proposé Aeris. Il reste deux problèmes liés au déchiffrement : 1/ sa version est pas user-friendly (il faut avoir un accès SSH pour déchiffrer les disques donc démarrer le service ... ça nécessite que ça soit un informaticien qui le fasse, notre but serait plutôt de confier cette mission et ces secrets à des personnes de confiance non informaticiennes). 2/ A priori, ça ne résiste pas à une attaque active (dans laquelle l'attaquant a accès à la machine physique, dumpe le /boot donc la clé privée du serveur SSH dropbear, puis remet tout en place et écoute le réseau pour regarder l'admin entrer la phrase de passe).
Pour répondre au 1, coder une interface web pour entrer les clés à distance, et embarquer un mini-serveur web en initramfs, permettrait de rendre le déchiffrement user-friendly (-> ça ferait un bon projet en libre, ça, rétroversé vers Debian !)
Pour répondre au 2, je n'ai pas de réponse pour le moment, mais je me demande si un système à base de nitrokey ou équivalent (HSM) n'apporterait pas la solution définitive.
Enfin, le jour où les circonstances politiques rendent les menaces de tentatives d'atteinte à la confidentialité des données davantage plausibles : planquer l'appli derrière tor (avec une passerelle depuis l'internet classique, passerelle elle-même hébergée loin d'ici) ajoute un niveau de protection & confier les clés de déchiffrement à des personnes de confiance qui ne dépendent pas des juridictions françaises.
[^] # Re: Un beau défi de conception
Posté par Samuel (site web personnel) . En réponse au message Recherche informaticien·ne·s-militant·e·s pour aide aux personnes exilées. Évalué à 2.
Ça nécessite une analyse complète de la surface d'attaque, analyse qui est en cours. Mon idée actuelle, c'est :
architecture mono-serveur (voire bare-metal) : les données et l'appli web sur le même système (le SGBD n'écoutant pas sur le réseau, uniquement en local). Car en pratique, la compromission de l'appli web a les mêmes effets que la compromission que le SGBD, donc les 2 doivent être aussi bien protégés.
partir du mode d'emploi stockage chiffré intégral sur serveur distant proposé Aeris. Il reste deux problèmes liés au déchiffrement : 1/ sa version est pas user-friendly (il faut avoir un accès SSH pour déchiffrer les disques donc démarrer le service ... ça nécessite que ça soit un informaticien qui le fasse, notre but serait plutôt de confier cette mission et ces secrets à des personnes de confiance non informaticiennes). 2/ A priori, ça ne résiste pas à une attaque active (dans laquelle l'attaquant a accès à la machine physique, dumpe le /boot donc la clé privée du serveur SSH dropbear, puis remet tout en place et écoute le réseau pour regarder l'admin entrer la phrase de passe).
Pour répondre au 1, coder une interface web pour entrer les clés à distance, et embarquer un mini-serveur web en initramfs, permettrait de rendre le déchiffrement user-friendly (-> ça ferait un bon projet en libre, ça, rétroversé vers Debian !)
Pour répondre au 2, je n'ai pas de réponse pour le moment, mais je me demande si un système à base de nitrokey ou équivalent (HSM) n'apporterait pas la solution définitive.
Enfin, le jour où les circonstances politiques rendent les menaces de tentatives d'atteinte à la confidentialité des données davantage plausibles : planquer l'appli derrière tor (avec une passerelle depuis l'internet classique, passerelle elle-même hébergée loin d'ici) ajoute un niveau de protection & confier les clés de déchiffrement à des personnes de confiance qui ne dépendent pas des juridictions françaises.