Stockage : Cubixion ou votre propre bucket

Par défaut : Cubixion à Anvers

Chaque organisation reçoit à sa création sa propre destination dans le stockage Zekura : son propre préfixe dans le stockage objet de Cubixion, avec ses propres utilisateurs IAM et ses propres clés. Cubixion est un fournisseur belge de stockage objet S3, construit et exploité en Belgique et en Allemagne, avec object lock, versionnage et sans frais de trafic entrant ou sortant. Ce dernier point compte : c'est ce qui permet à Zekura de restaurer réellement chaque nuit sans que votre facture ne bouge.

La liste montre par destination la clé (managed ou souveraine), la conservation sous object lock, le résultat du test d'aptitude, le nombre de tâches qui y écrivent et la dernière maintenance.

Ce que signifie l'object lock en mode compliance

Chaque version de chaque objet est ineffaçable pendant la durée de verrouillage (trente jours par défaut). Ni pour l'agent, ni pour le worker, ni pour Zekura, ni pour Cubixion. Une suppression pendant cette période n'est qu'un marqueur ; la version verrouillée reste jusqu'à la fin de la période, où la règle de cycle de vie du bucket la supprime physiquement. C'est le cœur de la protection contre les rançongiciels : qui prend le contrôle de votre serveur et vole la clé de l'agent ne peut rien détruire.

Deux sites

Qui doit suivre strictement DORA ou NIS2 choisit deux sites : chaque exécution part vers deux destinations européennes indépendantes. Un incendie ou une panne sur l'une ne touche pas l'autre. Le tarif figure sur la liste de prix.

Votre propre bucket S3

Vous pouvez aussi utiliser votre propre bucket, chez n'importe quel fournisseur compatible S3 : Cubixion, AWS, Hetzner, Scaleway, votre propre MinIO. Nous n'avons alors même pas le stockage en main ; nous ne voyons que des blocs chiffrés que vous conservez vous-même.

Paramètres → Stockage → Ajouter un stockage S3 propre. Indiquez endpoint, bucket, préfixe et deux paires de clés, et Zekura teste le bucket immédiatement :

Contrôle	Pourquoi
Versionnage activé	sans versionnage, une suppression ne peut pas être annulée
Object lock en mode compliance	pour que même l'administrateur du bucket ne puisse rien effacer pendant la durée de conservation
Règle de cycle de vie	sinon le bucket grossit sans fin ; le nettoyage est fait par le bucket lui-même, jamais par l'agent
La clé de l'agent ne peut pas effacer	un attaquant avec root sur votre serveur a cette clé ; elle ne doit permettre que d'ajouter
Écriture et lecture réussissent	évident, mais testé

Une destination qui échoue au test reste utilisable (par exemple pendant la mise en place), mais elle apparaît en rouge et compte comme faible dans le Restore Assurance Score. Utilisez Tester après avoir ajusté le bucket.

Deux clés, deux rôles

La clé de l'agent vit sur vos serveurs et ne permet que d'ajouter et de lire. La clé du worker permet de supprimer et n'est utilisée que par la maintenance et la vérification sur notre infrastructure séparée, jamais sur votre serveur. Si vous ne fournissez qu'une clé d'agent, tout fonctionne sauf le nettoyage des instantanés expirés.

Maintenance

Un worker séparé entretient le dépôt : un passage léger chaque jour, un passage complet chaque semaine. Chaque passage est un enregistrement de chaîne avec le nombre de blobs supprimés. Chaque jour, Zekura compte aussi les marqueurs de suppression sous chaque destination et les compare à ce que la chaîne justifie. Des marqueurs inexpliqués déclenchent une alerte critique.