Sauvegarde externalisée souveraine en Ukraine : une copie de secours immuable pour vos charges de travail cloud

En 2022, de nombreux organismes publics, entreprises d’État et sociétés réglementées en Ukraine ont migré leurs systèmes d’information vers Microsoft Azure, AWS et d’autres clouds publics à l’étranger pour assurer leur continuité sous la loi martiale. Le pari a été tenu — mais la plupart de ces systèmes sont toujours sauvegardés dans le même cloud, chez le même fournisseur et souvent dans la même région. Si le compte est bloqué, si la région tombe en panne ou si un attaquant obtient des droits d’administrateur, la production et tous les points de récupération disparaissent en même temps.

Une réserve de secours indépendante comble cette faille : une copie immuable et chiffrée de chaque système critique, conservée dans un centre de données certifié en Ukraine, actualisée chaque jour et testée selon un calendrier défini. Cet article présente l’architecture de référence que nous déployons, la manière de la dimensionner, ce qu’elle coûte et comment la mettre en place en 40 jours environ.

Pourquoi la sauvegarde native du cloud n’est pas une réserve indépendante

Les services de sauvegarde natifs sont excellents pour les restaurations du quotidien, mais ils partagent le sort de la plateforme qu’ils protègent. Azure Backup conserve les points de récupération dans un Recovery Services vault rattaché au même abonnement et au même tenant ; avec le stockage localement redondant (LRS), toutes les copies résident dans une seule région. Les coffres AWS Backup suivent le même modèle.

• Même fournisseur, même domaine de défaillance. Une suspension de compte, un litige de facturation, une décision de sanctions ou une panne régionale mettent la production et les sauvegardes hors ligne au même instant.
• Mêmes identités. Un administrateur général compromis peut modifier les stratégies de sauvegarde, raccourcir la rétention ou purger les éléments supprimés de manière réversible, à moins que chaque garde-fou ne soit parfaitement configuré.
• Aucune possibilité d’export. Les points de récupération Azure Backup ne peuvent pas être exportés sous forme de fichiers. La seule façon d’en extraire les données consiste à restaurer les disques d’un point de récupération, puis à les télécharger intégralement — à chaque fois.

Ce dernier point conditionne tout le projet : impossible de simplement « transférer les sauvegardes existantes » vers un autre centre de données. Une réserve indépendante exige sa propre chaîne de sauvegarde — une copie complète, puis des incrémentielles quotidiennes — écrite sur un stockage que le fournisseur cloud ne contrôle pas.

Ce que la réglementation ukrainienne exige des systèmes à fort impact

La réglementation ukrainienne va dans le même sens. Les exigences obligatoires applicables aux systèmes d’information, approuvées par la résolution n° 205 du Cabinet des ministres du 21 février 2025, prévoient que les propriétaires de systèmes de catégories I et II conservent une réserve de secours indépendante de l’environnement d’exploitation principal.

La résolution n° 263 du Cabinet des ministres du 12 mars 2022 autorise l’hébergement des ressources informationnelles de l’État dans des clouds à l’étranger pendant la loi martiale, et oblige les organismes publics à y mettre fin dans les six mois suivant sa levée. Une copie à jour en Ukraine est la condition préalable concrète de ce rapatriement.

Le lieu d’hébergement de la réserve est lui aussi encadré. En vertu de la loi ukrainienne « Sur les services cloud » et de la résolution n° 154 du Cabinet des ministres du 11 février 2025, les organismes publics recourent aux services cloud et de centres de données de fournisseurs inscrits sur la liste officielle tenue par le Service d’État des communications spéciales et de la protection de l’information d’Ukraine (SSSCIP). À la mi-2026, cette liste comprenait De Novo, GigaCloud, DataPark et UCloud, qui exploitent tous une infrastructure cloud disposant d’une attestation KSZI (système ukrainien de protection intégrée de l’information).

Architecture de référence : deux copies immuables en Ukraine

L’architecture laisse intacte la sauvegarde native du cloud et y ajoute une chaîne distincte et indépendante, qui aboutit en Ukraine.

1. Agents de sauvegarde dans le cloud. Des agents Veeam (ou Veeam Backup for Microsoft Azure) s’exécutent au plus près de chaque VM protégée et produisent des copies cohérentes au niveau applicatif des bases Oracle, Microsoft SQL Server et PostgreSQL. Les données sont compressées et chiffrées en AES-256 avant de quitter la VM.
2. Transport chiffré. Les copies transitent en TLS 1.2+ vers un point de terminaison compatible S3 en Ukraine. La première copie complète est transférée en deux semaines au plus ; ensuite, seules les modifications quotidiennes sont envoyées.
3. Copie principale immuable. Un bucket S3 doté d’Object Lock en mode conformité (WORM) rend chaque point de restauration inaltérable pendant toute la durée de rétention — même un administrateur ne peut pas le supprimer.
4. Seconde copie dans une autre région. Les points de restauration sont répliqués vers un centre de données situé dans une autre région d’Ukraine : perdre un site ne signifie pas perdre la réserve.
5. Ressources de restauration. Un pool de vCPU, de RAM et de disque, adossé au stockage, sert aux tests de restauration planifiés et, si nécessaire, au redémarrage des systèmes en Ukraine, sans le cloud.

Les identités sont cloisonnées à dessein : les comptes de sauvegarde disposent de leur propre authentification multifacteur et ne sont pas fédérés avec le Microsoft Entra ID du client, si bien qu’un tenant cloud compromis n’ouvre aucun chemin vers les copies. Les clés de chiffrement restent entre les mains du client.

Politique de rétention et dimensionnement du stockage

La capacité dépend de la taille d’une copie complète, du taux de modification quotidien et de la politique de rétention. Un schéma grand-père-père-fils (GFS) de 30 points de restauration quotidiens, 8 hebdomadaires et 12 mensuels est une cible courante pour les systèmes de catégorie I ; une politique plus légère de 14 jours / 4 semaines convient aux charges de travail moins critiques.

L’erreur la plus fréquente consiste à dimensionner la réserve comme « une copie des disques ». Avec une politique sur 12 mois, l’historique peut peser autant que la copie complète elle-même. Notre guide de dimensionnement pas à pas détaille les formules et un exemple de calcul.

Ce qui détermine le coût

Une réserve en Ukraine comporte quatre postes de coût. Les identifier dès le départ garantit une demande budgétaire sincère.

• Le stockage, au To et par mois, dans le cloud certifié KSZI du fournisseur, pour la copie principale comme pour la seconde. La facturation suit généralement le volume mensuel moyen réellement occupé.
• Les prestations ponctuelles : conception et mise en place de la chaîne de sauvegarde, transfert initial de la copie complète et première campagne de tests de restauration.
• Les ressources de restauration, par mois d’utilisation — pour les tests comme pour une reprise d’urgence.
• Les frais de sortie du cloud (egress), facturés par le fournisseur cloud. Aux tarifs publics d’Azure pour l’Europe, les 10 premiers To mensuels coûtent 0,087 $ par Go et les 40 To suivants 0,083 $ par Go : comptez donc environ 2 100 $ pour le transfert initial de 25 To, et de 500 à 1 300 $ pour 6 à 15 To de modifications mensuelles.

La compression, la déduplication et la tarification avec préférence de routage peuvent réduire ce poste d’un tiers, voire davantage. Si l’abonnement cloud bénéficie d’un programme de sponsoring, l’egress est peut-être déjà pris en charge.

Tests de restauration et ressources de reprise

Une copie qui n’a jamais été restaurée n’est qu’un espoir, pas une réserve. Nous restaurons chaque système protégé après le transfert initial et renouvelons des tests complets au moins une fois par an, en consignant le temps de reprise (RTO) et le point de reprise (RPO) effectivement mesurés.

Pour les systèmes les plus volumineux — typiquement une GED répartie sur deux serveurs ou une base de données ERP —, le pool de restauration doit offrir assez de disque pour l’ensemble des données et faire tourner deux VM simultanément. Un pool de 32 vCPU, 128 Go de RAM et 20 To de disque couvre la plupart des organisations de taille moyenne et fait office de site de repli d’urgence si le cloud devient indisponible.

Plan de déploiement en 40 jours

1. Jours 0 à 5. Accès, buckets de stockage avec Object Lock, serveur de sauvegarde, chiffrement, MFA et journalisation d’audit.
2. Jours 5 à 19. Copie complète initiale de chaque VM protégée ; les incrémentielles quotidiennes démarrent dès que la première copie de chaque VM est terminée.
3. Jours 19 à 26. Réplication vers la seconde région et vérification de la chaîne de copies.
4. Jours 26 à 40. Tests de restauration de chaque système, procès-verbaux de test, politique de sauvegarde et plan de reprise d’activité.
5. Chaque mois ensuite. Supervision, contrôles d’intégrité et rapport sur la réussite des tâches, les volumes et les incidents.

Ce que vous apporte Corvus Intelligence

• Une architecture et une politique de sauvegarde documentées, conformes à l’exigence de réserve de secours des systèmes de catégories I et II.
• Des copies principale et secondaire immuables, dans les clouds certifiés KSZI de fournisseurs inscrits sur la liste du SSSCIP.
• Des tests de restauration assortis de procès-verbaux et un plan de reprise d’activité que vos équipes peuvent dérouler.
• Une supervision 24/7 des tâches de sauvegarde et un SLA garantissant une réponse en une heure aux incidents critiques.
• Une tarification unitaire transparente — au To, au mois de ressources de restauration et par prestation ponctuelle —, prête à intégrer une demande budgétaire.

Cette réserve se marie naturellement avec une surveillance de sécurité continue : notre SOC managé sur Security Onion surveille les événements de sauvegarde au même titre que le reste de l’infrastructure et alerte à la moindre tentative de manipulation.