Ces derniers mois, la Casa Hacker a mené un travail de durcissement de nos plateformes. Hardening, dans le jargon. En pratique : resserrer ce qui était lâche et fermer ce qui restait ouvert par habitude.
Cela a été fait de bout en bout — des serveurs que nous utilisons chaque jour jusqu’à la formation de l’équipe et à des changements considérables dans les systèmes. Ce n’était pas de la maintenance. C’était une condition.
Une condition, parce que nous voulions avancer avec nos projets d’intelligence artificielle et d’informatique cognitive, et qu’il n’était pas possible de le faire sur une base que personne n’avait révisée. Une plateforme d’IA construite sur des fondations lâches n’est pas une plateforme d’IA. C’est un risque avec une jolie interface.
L’ordre a donc été celui-ci : la maison d’abord, ensuite ce que nous voulons y mettre. Sécurité et vie privée dès la conception — et non comme une couche appliquée à la fin, car une couche appliquée à la fin est une rustine, et les rustines se décollent.
La Casa Hacker défend la protection des données depuis des années. Surtout celle de la personne concernée : celle à qui la donnée appartient. Ce n’est pas une posture de communication. C’est la façon dont la loi générale brésilienne de protection des données a été conçue, et nous sommes d’accord avec elle.
Et si nous jugeons cette loi assez importante pour la défendre au-dehors, le minimum est de l’appliquer ici même. Étape par étape. Y compris les étapes ennuyeuses, celles que personne ne voit et qui ne donnent lieu à aucune publication.
Ce que « chiffré » veut dire ici
Toute conversation entre le monde extérieur et la Casa Hacker passe chiffrée, par une seule entrée. Il n’y a pas de seconde porte, ni de raccourci pour un système particulier, ni d’exception « juste pour l’instant » — qui est précisément le type d’exception qui reste.
Passé la porte, nos systèmes se parlent sans toucher à l’internet. Ils parlent à l’intérieur de la machine elle-même.
Et il y a l’autre moitié, celle que presque personne n’interroge : la donnée au repos. Nos bases de données et les fichiers sensibles vivent dans un volume chiffré. Si quelqu’un emportait le disque, il emporterait du bruit.
Les copies
Ce que nous conservons est copié hors du Brésil tous les jours : trois pays, sur trois continents. Chiffré avant de sortir — le nom du fichier comme son contenu. Qui l’intercepterait ne saurait même pas comment le fichier s’appelle.
Deux décisions là-dedans méritent d’être dites, car toutes deux ont un prix.
Le serveur chiffre ses propres copies et ne parvient pas à les relire. La clé n’y réside pas. Qui compromet le serveur ne lit pas l’historique. Le prix est que nous dépendons désormais d’une garde de clé conservée ailleurs : clé perdue, sauvegarde perdue. Nous avons assumé ce risque les yeux ouverts, parce que l’autre risque est pire.
Les copies peuvent être écrites, jamais effacées. Quelqu’un disposant du contrôle total du serveur ne peut pas supprimer ce qui a déjà été conservé. C’est la différence entre avoir une sauvegarde et avoir une sauvegarde qui survit précisément au jour où l’on en a besoin.
Conserver ne suffit pas. Il faut répéter le retour.
Une sauvegarde jamais testée est une foi, pas une sauvegarde.
Chaque semaine, un processus automatique va chercher l’une des copies les plus lointaines, la télécharge pour de vrai — par l’internet, comme il le ferait un mauvais jour — et vérifie que le paquet est intact et qu’il s’ouvre avec la bonne clé.
Soyons exacts sur ce que cette répétition prouve et sur ce qu’elle ne prouve pas : elle prouve que la copie existe hors d’ici, qu’elle arrive entière et qu’elle est lisible par qui détient la clé. Ce n’est pas une restauration complète du système en fonctionnement. Celle-ci demeure un exercice à main humaine. Nous l’écrivons parce que « nous avons des sauvegardes testées » est une phrase que beaucoup d’organisations emploient quand ce qu’elles ont testé était le code de sortie d’un script.
Confiance zéro — y compris envers nous-mêmes
Cela s’appelle zero trust, la confiance zéro. Ce n’est pas notre invention : le concept est né dans un cabinet de conseil américain en 2010, est devenu une norme technique publiée par l’institut de normalisation des États-Unis, et constitue aujourd’hui une pratique courante de sécurité. Ce qu’il dit est simple et inconfortable — être à l’intérieur n’est pas un titre d’accès.
En pratique, ici : tout accès à une donnée est journalisé, et qui accède doit continuer de prouver qu’il est bien celui qu’il prétend être. Ce n’est pas une connexion le matin et libre circulation jusqu’au soir. C’est une identification à chaque fois, avec plus d’un facteur — et l’un de ces facteurs passe par une plateforme qui n’existe que pour les personnes de la Casa Hacker.
Ce dernier détail est ce qui réduit le plus le risque qui n’est pas technique. La plupart des attaques réussies aujourd’hui ne forcent rien : elles convainquent quelqu’un. Un facteur qu’on ne peut pas demander par téléphone, ni coller dans une conversation, ni reproduire quand on imite bien un badge écarte l’ingénierie sociale dans une bonne part des cas.
Ce qui soutient cela à notre bordure, c’est la plateforme d’accès de Cloudflare. Nos panneaux d’administration internes ne sont pas protégés seulement par le mot de passe de l’application : ils se trouvent derrière une vérification d’identité qui a lieu avant que la requête n’atteigne le système. Qui ne passe pas cette vérification ne parle jamais à l’application — elle n’a même pas connaissance de la tentative.
L’identité vient de notre annuaire d’entreprise, non d’un fichier parallèle. Cela compte plus qu’il n’y paraît : quand quelqu’un quitte l’organisation, désactiver le compte d’entreprise ferme l’accès à tout d’un coup. Il n’existe pas cette liste de systèmes où la personne « avait aussi un identifiant » — la liste que personne ne retrouve précisément le jour où elle en a besoin.
La session expire. Un accès accordé n’est pas un accès permanent. Et les comptes de machine — ceux qu’un programme utilise pour parler à un autre — ont leur propre règle, distincte de celle des personnes. Traiter un programme et une personne à la même aune, c’est ainsi qu’on perd le contrôle des deux.
L’équipement entre aussi en ligne de compte. Les appareils de l’équipe sont enrôlés avec un profil défini par l’organisation, et ce profil n’est pas négociable sur la machine de la personne : on ne peut pas couper la protection parce qu’elle a gêné ce jour-là. Une sécurité que l’utilisateur désactive en deux clics est une suggestion, pas un contrôle.
Chaque personne voit ce que son travail exige
Personne ici n’a accès à tout. Chaque personne a un rôle, et le rôle définit ce qu’elle atteint — le nom technique est séparation des tâches, ou contrôle d’accès fondé sur les rôles.
C’est pénible. Vraiment pénible : cela engendre des demandes d’accès, de l’attente, des « je n’arrive pas à ouvrir ça ». Nous avons choisi le pénible. Un accès large est confortable jusqu’au jour où un seul compte compromis devient l’organisation entière.
La bordure : le Projet Galileo
Il y a une chose à dire sans fausse modestie : les organisations comme la nôtre sont attaquées. Non par hasard, et non parce que nous aurions de l’argent — mais à cause de ce que nous disons, de qui nous accueillons et d’où nous sommes. La société civile, le journalisme, les droits humains et l’éducation en territoire périphérique sont visés régulièrement. Et presque aucune organisation de ce champ n’a le budget d’une sécurité de niveau entreprise.
Le Projet Galileo, de Cloudflare, existe précisément à cause de ce décalage. Créé en 2014, il offre gratuitement une protection de niveau entreprise aux organisations d’intérêt public en situation de vulnérabilité. La Casa Hacker en fait partie.
En pratique, cela a changé la conception de notre bordure — la frontière entre l’internet et nous. Il vaut la peine d’expliquer ce que fait chaque pièce, car « nous sommes protégés par Cloudflare » ne veut rien dire tout seul.
L’attaque n’arrive pas. Contre une attaque par déni de service — celle qui fait tomber un site par le volume, non par la faille —, la défense n’est pas d’encaisser le choc. C’est que le choc n’arrive pas. Le trafic malveillant est absorbé dans un réseau réparti dans le monde, avec une capacité que nous n’aurions jamais et qu’il n’aurait pas de sens de chercher à bâtir. Notre serveur ne devient pas plus fort : il se met hors du chemin.
Seul passe ce qui est légitime. Toute requête entrante est inspectée avant d’être transmise. Une requête portant un motif d’attaque connu meurt à la bordure, pas sur notre serveur. Ce qui tient la machine debout n’est pas notre capacité à résister à une requête malveillante — c’est qu’elle n’a jamais été livrée.
Le DNS est une porte lui aussi — et elle ouvre des deux côtés. Presque tout le monde pense la sécurité comme on surveille l’entrée. Mais un appareil compromis n’est pas dangereux parce que quelqu’un entrerait par lui : il est dangereux parce qu’il tente de sortir, à la recherche du serveur de celui qui l’a infecté. Nous utilisons un filtrage DNS supervisé exactement là. Avant qu’aucune connexion n’existe, au moment où un nom devient une adresse, les destinations reconnues comme malveillantes sont bloquées. C’est la défense la moins chère et la plus sous-estimée qui soit : elle agit avant que l’attaque n’ait où appeler.
La politique voyage avec la personne, pas avec le bureau. Les appareils de l’équipe exécutent le client de la plateforme d’accès de Cloudflare. Cela signifie que les mêmes règles valent au bureau, à la maison, dans un espace de coworking ou sur un téléphone dans le bus. C’est l’inverse de l’ancien modèle, où le réseau du bureau était « le lieu sûr » et tout le reste une exception — un modèle mort, et que beaucoup d’organisations font encore semblant de croire vivant.
Un pare-feu applicatif que nous auditons chaque jour. Un filtre de sécurité a un effet secondaire classique : bloquer de vraies personnes. Un formulaire qui ne part pas, une pièce jointe qui échoue, une personne qui renonce. Et personne ne l’apprend, car qui a été bloqué par erreur n’ouvre pas de ticket — il s’en va.
C’est pourquoi notre filtre n’est pas seulement allumé : il est audité. Chaque jour, un processus automatique examine ce qui a été bloqué durant les dernières heures et sépare ce qui relevait d’une attaque de ce qui a pu être quelqu’un de légitime, et le résultat tombe dans un canal interne où l’équipe le voit. Si ce moniteur devient muet, cela compte comme un incident — un moniteur silencieux est indiscernable de « tout va bien ».
Cette distinction est la différence entre sécurité et obstruction. Bloquer est facile. Savoir qui l’on a bloqué par erreur, c’est le travail.
Une vérification anti-robot sans péage pour les humains. Nos écrans publics — y compris le canal de signalement — utilisent une vérification anti-robot qui fonctionne sans casse-tête, sans « cliquez sur tous les feux tricolores » et sans pister la personne à travers l’internet. Ce n’est pas une question de confort : un canal de signalement doit résister à l’inondation automatisée et, en même temps, ne peut pas faire payer à qui signale le prix d’être identifié. Concilier les deux était difficile jusqu’à peu.
Deux pièces discrètes ferment le bloc. Notre domaine est signé cryptographiquement, ce qui empêche quiconque de convaincre l’internet que l’adresse de la Casa Hacker est un autre serveur. Et la connexion n’a lieu que dans des versions modernes du protocole de chiffrement, la bordure elle-même vérifiant le certificat de notre serveur avant de lui parler. Personne ne se glisse au milieu de cette conversation.
Notez que cette dernière pièce est la même idée que la section précédente. La confiance zéro n’est pas un produit qui s’achète : c’est la décision de n’avoir aucun lieu privilégié. La bordure est l’endroit où cette décision devient configuration.
Nous ne faisons pas d’économies sur la sécurité
C’est un choix budgétaire, et il se voit dans les outils.
Notre infrastructure tourne sur Red Hat Enterprise Linux 10. Ce n’est pas le système le moins cher à exploiter, ni le plus facile. C’est celui qui a un cycle de vie long et prévisible, des correctifs de sécurité avec un délai et un responsable, une politique cryptographique gérée de façon centrale et un écosystème de conformité qui permet d’auditer la machine contre une norme externe plutôt que contre notre propre opinion.
Et une bonne part de ce que nous développons — y compris le système où vivent les données sensibles de l’organisation — est écrite en Rust. La raison est directe et ce n’est pas une mode : une part énorme des failles graves de sécurité de l’histoire du logiciel provient d’erreurs de gestion mémoire, et Rust a été conçu pour rendre cette classe entière d’erreurs impossible à compiler. C’est une sécurité qui ne dépend pas de l’attention de celui qui écrivait ce jour-là.
Cela coûte plus cher en temps de développement. C’est un langage exigeant, qui discute avec qui écrit. Nous acceptons cette discussion, parce qu’elle a lieu avant que le code n’arrive en production — et non après, avec les données de personnes réelles au milieu.
Qu’une organisation sociale choisisse l’outil le plus robuste plutôt que le moins cher est une décision politique sur la question de savoir à qui ces données appartiennent.
Un logiciel sûr dès sa naissance
La sécurité d’une plateforme ne commence pas au serveur. Elle commence à la façon dont le logiciel y parvient.
Ici, trois principes la gouvernent.
Par défaut, rien ne s’exécute. La configuration de notre serveur refuse par principe toute image d’application. Chaque origine de logiciel doit être explicitement autorisée pour pouvoir être exécutée, et les pièces du système d’exploitation ne tournent que si leur signature cryptographique correspond à la clé de l’éditeur. La posture par défaut est « non », et chaque « oui » a été une décision consignée.
Version exacte, pas étiquette. Les applications tournent sur une version identifiée par l’empreinte du contenu, non par un surnom comme « la plus récente ». Le surnom change sous les pieds ; l’empreinte, non. Cela signifie que nous savons exactement ce qui tourne, et qu’une mise à jour est toujours un acte délibéré — jamais une surprise arrivée pendant la nuit.
Rien n’entre sans relecture. Une modification de code passe par une proposition relue et par une vérification automatique avant de devenir la production.
Comment nous savons que nous sommes en sécurité : en mesurant
C’est la partie qui sépare la sécurité du discours sur la sécurité.
Il existe une norme internationale de configuration sécurisée des serveurs, maintenue par une organisation indépendante, le CIS. C’est une liste longue et ennuyeuse de centaines de vérifications objectives — le genre de document que personne ne lit par plaisir et qui, précisément pour cette raison, sert : il n’a pas d’opinion sur nous.
Nous avons audité notre machine contre cette norme, au niveau recommandé pour un serveur de production, avant de commencer le travail. Puis nous avons audité de nouveau à chaque étape. Aujourd’hui, notre conformité se situe à un niveau élevé — bien au-dessus de ce que nous avions trouvé à la première mesure, et au-dessus de ce que l’on voit couramment dans l’infrastructure d’organisations de notre taille.
Ce qui importe ici n’est pas la note. Ce sont deux autres choses.
La première : la règle est venue avant le travail. La première mesure a été faite pour savoir où nous en étions, non pour prouver que nous allions bien. Sans cette ligne de base, « nous avons beaucoup amélioré la sécurité » serait une phrase sans rien derrière.
La seconde : nous ne sommes pas à 100 %, et nous n’entendons pas faire semblant. Une partie de ce qui manque relève d’écarts délibérés, documentés avec leur raison — des réglages que la norme recommande et qui casseraient le fonctionnement de la base de données ou des applications, et où nous avons consciemment choisi le fonctionnement, en consignant ce choix. Une sécurité sans service qui fonctionne n’est pas une sécurité : c’est un serveur éteint.
L’intelligence artificielle entre par la même porte que tout le monde
Retour au début : tout cela existait pour que nous puissions avancer avec l’IA sur une base défendable.
Quand cette base a tenu debout, l’IA est entrée en obéissant aux mêmes règles. Aucune exception n’a été ouverte pour elle — et cela vaut d’être dit, car ouvrir une exception pour le système nouveau est exactement ainsi que naissent les brèches.
En pratique : un assistant d’IA n’a ni compte propre ni permission propre. Il agit au nom d’une personne, avec son autorisation explicite, et l’accès accordé est obligatoirement inférieur ou égal à celui que cette personne aurait déjà à l’écran. Personne ne gagne de permission en connectant un assistant.
Chaque action que l’IA peut exécuter a été classée, une par une, selon ce qu’elle coûte. Une action réversible s’exécute et reste journalisée. Une action ayant un effet hors de l’organisation renvoie ce qui allait se produire et s’arrête, en attendant confirmation. Une action qui déplace de l’argent ou du patrimoine exige une répétition préalable consignée et une confirmation humaine.
Et toute donnée personnelle identifiable est substituée avant qu’un extrait ne parte vers un service externe, avec la trace de la quantité sortie.
Le récit complet de ce travail — y compris les six hypothèses qui nous étaient propres et que la mesure a démenties — se trouve dans la publication précédente.
Qui autorise un transfert de données
Un transfert de données vers l’extérieur n’a lieu qu’avec l’autorisation de notre directeur de la protection des données. Ce n’est pas une compétence partagée, ni une approbation par commodité de qui exécute la tâche.
Oui, cela crée un goulot d’étranglement. C’est le goulot que nous voulons. Une donnée qui sort de l’organisation sans que personne ne réponde de l’avoir laissée sortir est une donnée que personne ne saura expliquer ensuite — et « ensuite », c’est le plus souvent devant une personne concernée, un financeur ou une autorité.
Un exemple réel, car un principe sans exemple est un ornement.
Quand nous avons décidé de placer notre trafic derrière cette protection de bordure, un conflit est apparu qu’aucun manuel ne règle : faire passer le trafic par un réseau externe signifie que ce réseau voit ce qui passe. Pour la plupart de nos systèmes, c’est acceptable et encadré par un contrat de traitement des données. Pour le canal de signalement, ce ne l’était pas — car sa conception conserve l’adresse de qui signale de façon irréversible, exprès, pour que nous-mêmes ne puissions pas savoir de qui il s’agit.
La décision n’a pas été celle de l’équipe technique. Elle a été portée devant le directeur de la protection des données, tranchée sur une base légale et consignée par écrit dans notre documentation d’architecture, avec le contrat qui la soutient. Et le système le plus sensible de tous est resté délibérément hors de la bordure : nous avons accepté de perdre une protection contre l’attaque pour ne pas perdre l’anonymat.
J’écris ceci parce que c’est le type de décision où la sécurité et la vie privée tirent en sens contraires, et où quelqu’un doit avoir l’autorité de dire laquelle des deux cède. Si cette personne n’existe pas dans votre organisation, la décision sera prise tout de même — par celui qui configure, seul, à onze heures du soir.
Savoir où se trouve chaque donnée
Il y a une part de ce travail qui ne concerne aucun intrus. Elle concerne la personne à qui la donnée appartient.
Nous maintenons une plateforme qui centralise la cartographie des données personnelles et sensibles réparties dans nos systèmes — ce qui existe, où cela se trouve, pourquoi c’est là et comment c’est traité.
La raison est directe. La loi donne à la personne concernée le droit de demander l’accès, la rectification, la portabilité et l’effacement de ses propres données. Sauf que ce droit ne vaut rien si l’organisation ignore où sont les informations. Une organisation qui a besoin de trois semaines et d’une cellule de crise pour répondre à « quelles données détenez-vous sur moi ? » ne respecte pas la loi — elle fait semblant de la respecter, en comptant sur le fait que personne ne demandera.
Ici, quand une personne concernée demande, la réponse sort en quelques clics. C’est à cela que sert la cartographie : non pas à avoir une politique publiée, mais à pouvoir répondre.
La formation, parce que la défaillance n’est presque jamais celle de la machine
Chaque année, l’équipe reçoit une formation, et au fil de l’année des notes d’information — ce qui est permis, ce qui ne l’est pas, comment protéger la donnée de celles et ceux qui nous ont fait confiance, et comment reconnaître une tentative d’escroquerie.
Nous y insistons parce que presque aucun incident ne commence sur un serveur. Il commence chez quelqu’un de pressé, dans une demande qui semblait légitime, dans un message arrivé au bon moment. On peut tout chiffrer et tout perdre quand même pour un « confirme-moi ça vite fait ». Contre cela, il n’existe pas de configuration. Il existe des gens formés.
Ce qu’on peut emporter d’ici
Si ce texte sert à une autre organisation de notre champ, qu’il serve par ces cinq points — aucun ne dépend du budget :
Mesurez avant d’améliorer. Lancez un audit contre une norme externe avant de toucher à quoi que ce soit. Sans ligne de base, vous n’avez aucun moyen de savoir si vous avez progressé, ni de le prouver à qui vous finance.
Demandez de l’aide à qui en offre. Une protection de niveau entreprise existe gratuitement pour les organisations d’intérêt public. Le Projet Galileo est une voie réelle, et la plupart des organisations éligibles ignorent simplement son existence. Cela vaut pour davantage : identité d’entreprise, accès en confiance zéro et vérification anti-robot ont des offres gratuites qui couvrent une organisation de notre taille.
Traitez la sortie, pas seulement l’entrée. Le filtrage DNS est peu coûteux, rapide à activer, et couvre le scénario de compromission réelle le plus courant.
Décidez qui autorise quoi, par écrit. Des rôles définis et une personne responsable des transferts de données valent plus que n’importe quel outil. Cela ne coûte aucune licence — cela coûte une décision.
Publiez vos limites. Dire ce que vous ne faites pas encore est ce qui donne du poids à ce que vous dites faire.
Nous avons coutume de dire que les périphéries ne sont pas un lieu d’attente, mais un lieu de commencement. Cela vaut aussi ici. La sécurité de l’information est devenue, dans l’esprit de beaucoup, une affaire de banques et de multinationales — quelque chose qu’une organisation sociale n’atteint pas et n’essaie donc même pas.
Ce n’est pas vrai. Ce que l’essentiel de tout cela exige n’est pas de l’argent : c’est de décider que la donnée d’un jeune de la périphérie mérite le même soin que la donnée du client d’une banque.
Elle le mérite. Et c’est pour cela que nous avons mis de l’ordre dans la maison.
Références et lectures
- Slack — Security at Slack: how Slack protects your data. La publication qui a inspiré celle-ci. https://slack.com/intl/pt-br/blog/collaboration/security-at-slack-how-slack-protects-your-data
- Loi n° 13.709/2018 — Loi générale brésilienne de protection des données (LGPD). https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm
- Autorité nationale de protection des données (ANPD), Brésil. https://www.gov.br/anpd/pt-br
- Cloudflare — Projet Galileo. Protection gratuite de niveau entreprise pour les organisations d’intérêt public, depuis 2014. https://www.cloudflare.com/galileo/
- Cloudflare — Rapport anniversaire du Projet Galileo : cyberattaques contre la société civile. https://cfl.re/cyberattacks-against-civil-society-project-galileo-anniversary-report
- Cloudflare One — documentation de la plateforme d’accès et de filtrage. https://developers.cloudflare.com/cloudflare-one/
- Cloudflare Turnstile — vérification anti-robot sans pistage de l’utilisateur. https://developers.cloudflare.com/turnstile/
- NIST SP 800-207 — Zero Trust Architecture. La norme qui a formalisé le concept de confiance zéro. https://csrc.nist.gov/pubs/sp/800/207/final
- Forrester Research — No More Chewy Centers: Introducing the Zero Trust Model of Information Security (John Kindervag, 2010). Le travail qui a forgé le terme.
- Google — BeyondCorp. La première mise en œuvre à grande échelle du modèle. https://cloud.google.com/beyondcorp
- CIS Benchmarks — Center for Internet Security. La norme de configuration sécurisée contre laquelle nous auditons nos serveurs. https://www.cisecurity.org/cis-benchmarks
- Casa Hacker — L’IA qui nous intéresse ne répond pas aux courriels. Le récit du travail sur les données que cette publication vient soutenir. https://casahacker.org/publicacoes/a-ia-que-nos-interessa-nao-responde-e-mail/