L lionbackup CLOUD
S'INSCRIRE LOGIN

La sécurité chez lionbackup

Comment nous protégeons vos données – expliqué clairement pour les décideurs et documenté en détail pour la technique et l’audit.

Aperçu pour la direction

lionbackup est conçu dès la base pour que personne d’autre que vous ne puisse lire vos contenus – pas même nous en tant qu’exploitant. C’est garanti par un concept de sécurité de bout en bout : chiffrement côté client, stockage immuable, zones strictement séparées et traçabilité complète.

Vos clés, vos données

Le chiffrement a lieu sur votre système, avant que les données ne quittent vos locaux. Les clés restent chez vous – nous n’avons pas accès au texte en clair.

Immuable (WORN)

Pendant la durée de rétention choisie, les sauvegardes ne peuvent être ni écrasées ni supprimées – une protection efficace contre les ransomwares.

Jetons écriture/lecture séparés

Un jeton d’accès a soit le droit d’écriture, soit le droit de lecture. Un jeton d’écriture ne peut que sauvegarder, jamais restaurer – il faut pour cela un jeton séparé avec droit de lecture.

Localisé en Europe

Stockage exclusivement dans des centres de données européens contrôlés, géographiquement séparés de la zone d’administration.

SSO & 2FA/TOTP

Connexion uniquement par single sign-on avec authentification à deux facteurs obligatoire (TOTP). Pas de connexions par mots de passe faibles.

Journalisation complète

Les événements de sécurité sont journalisés et analysés de façon centrale et résistante aux manipulations.

Détection d’anomalies

Les schémas d’envoi suspects sont détectés et signalés automatiquement – par exemple des données insuffisamment chiffrées.

En complément, les mesures techniques et organisationnelles (TOM), la description du service et le contrat de sous-traitance (AVV/DPA) documentent contractuellement les mesures de protection (en allemand).

Détails techniques

1. Chiffrement de bout en bout côté client

Le chiffrement s’effectue entièrement dans le client open source lionbackup, avant tout transfert. Chaque fichier reçoit une clé de données (DEK) fraîche et aléatoire ; les données utiles sont chiffrées par blocs de manière authentifiée avec XChaCha20-Poly1305. La DEK est encapsulée de façon hybride – classiquement via X25519 et de manière post-quantique via ML-KEM-768 (schéma hybride age). Les clés privées ne quittent jamais votre système et sont stockées localement avec des droits restrictifs. Conséquence : le serveur ne voit que du chiffré. Si votre clé est perdue, la restauration est techniquement impossible – c’est voulu.

2. Stockage immuable (WORN) avec durée de rétention

Les sauvegardes atterrissent dans un système de stockage durci et redondant. Pour les projets immuables, la plateforme elle-même garantit que chaque objet ne peut être ni écrasé ni supprimé pendant la durée de rétention configurée par le client (Write Once, Read Never) – indépendamment des composants de stockage individuels. Vos sauvegardes restent intactes même si un système compromis tente de les détruire.

3. Zones séparées & trafic intégralement chiffré

La plateforme est divisée en une zone de sauvegarde centrale (administration, portail, pilotage) et plusieurs zones de stockage géographiquement séparées. Les envois des clients vont directement au point de stockage (« Citadel ») de la zone choisie – pas par la zone d’administration. Le trafic de contrôle et de métadonnées entre zones (p. ex. synchronisation, transfert d’audit) passe exclusivement par un réseau d’interconnexion fortement chiffré et mutuellement authentifié avec une connexion séparée par zone. Chaque zone est isolée au niveau réseau.

4. Single sign-on central & authentification multifacteur obligatoire

La seule méthode de connexion est le single sign-on via une plateforme d’identité centrale et dédiée. Il n’y a pas de mots de passe locaux dans le portail. L’authentification à deux facteurs par TOTP est obligatoire et incontournable. Les utilisateurs et groupes sont gérés de façon centrale ; le portail n’évalue que des attestations d’autorisation signées cryptographiquement.

5. Accès à la base de données en moindre privilège

L’application se connecte avec un utilisateur de base de données dédié et non privilégié (pas de superutilisateur), dont les droits sont limités au schéma applicatif. Les requêtes de lecture sont dirigées si possible vers une réplique ; les écritures vont sur la base primaire. Les identifiants ne sont pas dans le code : ils sont récupérés à l’exécution depuis un coffre de secrets protégé et peuvent être renouvelés.

6. Journalisation d’audit centrale & détection d’anomalies

Les événements de sécurité et applicatifs (connexions, entrées d’audit, envois terminés) sont transmis sous forme d’enregistrements structurés à un système d’analyse central à accès protégé, où ils peuvent être exploités. De plus, le point de stockage vérifie chaque envoi de façon heuristique : une mesure d’entropie (Shannon, bits/octet) détecte si les données envoyées sont réellement chiffrées. Si l’entropie mesurée passe sous un seuil (suspicion de données non chiffrées ou faiblement chiffrées), un événement d’anomalie est déclenché. D’autres irrégularités comme des tailles inhabituelles ou un usage abusif de jetons alimentent la même analyse.

7. Segmentation réseau & egress contrôlé

Les zones sont divisées en segments réseau privés et séparés. Le trafic sortant est strictement contrôlé : les sources externes nécessaires ne sont fournies que par un intermédiaire contrôlé lié au réseau privé de la zone, et la sortie internet passe par un nœud de sortie dédié. La surface d’attaque vers l’extérieur reste minimale.

8. Transport chiffré & réplication

Tout le transport est chiffré : le transfert entre le client et le point de stockage passe par HTTPS/TLS, le trafic de contrôle entre zones par des connexions fortement chiffrées et mutuellement authentifiées. Dans le système de stockage, la clé de données encapsulée par fichier est en outre enveloppée côté serveur – vos contenus restent de toute façon illisibles grâce au chiffrement côté client.

Objectif de protectionMesure
ConfidentialitéChiffrement E2E côté client (XChaCha20-Poly1305, X25519 + ML-KEM-768) ; les clés restent chez le client
Intégrité & protection contre la manipulationChiffrement authentifié (Poly1305), stockage WORN immuable avec rétention
DisponibilitéZones de stockage géographiquement séparées, segments réseau isolés
Contrôle d’accèsSSO central, MFA TOTP obligatoire, accès base de données en moindre privilège
TraçabilitéJournalisation d’audit centrale, détection d’anomalies et d’entropie
Sécurité du transportHTTPS/TLS pour les envois, connexions fortement chiffrées pour le trafic de contrôle entre zones

Cette page décrit l’état actuel de l’architecture. Les déclarations contraignantes, garanties contractuellement, résultent des TOM, de la description du service et du contrat correspondant (en allemand).