L’attaque du registre foncier roumain met les sauvegardes à l’épreuve
L’incident de l’ANCPI rappelle que les registres critiques ont besoin de reprise isolée, de contrôles d’intégrité et de procédures de secours.
L'attaque contre le registre foncier roumain est grave sans qu'il soit nécessaire d'en faire un récit catastrophiste. La cible était l'ANCPI, l'agence chargée du cadastre et de la publicité immobilière. Quand e-Terra et des services liés sont devenus indisponibles mi-juillet, l'effet a touché les notaires, les banques, les acheteurs, les vendeurs et les citoyens qui avaient besoin de prouver un droit de propriété.

L'enquête continue. Risky Business rapporte qu'un attaquant aurait utilisé des identifiants valides, cartographié les systèmes internes, tenté une extorsion puis effacé des systèmes de production et des sauvegardes accessibles. Help Net Security et Romania Insider indiquent que l'ANCPI a d'abord parlé d'un incident technique majeur, avant de confirmer une cyberattaque et d'annoncer une réinstallation et un renforcement de l'infrastructure. Un communiqué archivé de l'agence affirme que des sauvegardes existaient dans plusieurs emplacements.
Distinguer faits et affirmations
L'indisponibilité d'e-Terra depuis le 14 juillet est observable. Les communiqués de l'ANCPI sont la base officielle. Les messages sur des données mises en vente dans des forums criminels sont un signal sérieux, mais les affirmations de l'attaquant sur les données citoyennes, le code source ou la suppression de sauvegardes doivent encore être confirmées.
Cette prudence ne minimise pas l'incident. Un registre foncier relie propriété, hypothèques, impôts, successions, permis, assurances et litiges. Quand il tombe, une transaction peut s'arrêter même si les données finissent par être récupérées.
La sauvegarde doit survivre à l'intrusion
La leçon n'est pas seulement “faire des backups”. Si le même chemin d'identifiants permet de supprimer la production et les sauvegardes, l'organisation n'a pas de vraie résilience. Il faut des snapshots immuables, des copies hors du rayon d'attaque, une séparation des comptes, du stockage WORM quand c'est adapté, et des exercices de restauration menés comme si le domaine principal était compromis.
Dire que des copies existent dans plusieurs lieux est rassurant, mais la question reste: qui peut les effacer, combien de temps elles sont conservées, comment prouver le dernier état propre, et combien de temps il faut pour reconstruire un service fiable.
La corruption silencieuse serait pire
L'effacement se voit. Une attaque plus dangereuse modifierait des titres de propriété, altérerait des horodatages et laisserait les mauvaises données entrer dans l'historique des sauvegardes. Les registres critiques ont donc besoin de journaux infalsifiables, de rapprochements indépendants, de signatures de snapshots, de double contrôle pour les opérations sensibles et de procédures juridiques de contestation.
La blockchain revient souvent dans ces débats. Elle ne résout pourtant pas l'identité, le consentement, la fraude, les limites cadastrales ou les décisions de justice. Si une donnée fausse entre, un registre immuable peut surtout conserver l'erreur. Le vrai besoin est un système de preuve, de contrôle et de reconstruction.
Le mode dégradé doit être prévu
La numérisation reste utile. Le problème apparaît quand elle supprime les anciens secours avant que le nouveau système ait prouvé sa capacité de reprise. Un registre national doit savoir quels services s'arrêtent, lesquels continuent manuellement, quelles données peuvent être lues depuis une réplique et qui certifie une restauration.
Pour toute base de données faisant autorité, la question est directe: un attaquant muni d'identifiants valides peut-il détruire à la fois le service et la preuve qui permet de le reconstruire? Si la réponse n'a pas été testée, la sauvegarde n'est encore qu'une promesse.
Comments
Sign in to comment.
No comments yet.