Des mesures techniques qui soutiennent la conformité

Le Health Insurance Portability and Accountability Act exige la protection des données des patients, des contrôles d'accès et des pistes d'audit.

• Le chiffrement de bout en bout garantit que les données des patients ne sont jamais visibles pour les serveurs
• Historique d'écriture signé — chaque modification est signée en Ed25519, ce qui prouve qui a écrit quoi et quand
• Contrôle d'accès fin avec des clés nommées pour les différentes équipes soignantes
• Conservation des données — des stratégies fondées sur le sharding par période et sur l'archivage
• Fonctionnement hors ligne pour le personnel soignant sur le terrain et les cliniques isolées

⚠️ HIPAA exige aussi la journalisation des accès en lecture, des BAA, des mesures de sécurité administratives et une sécurité physique — c'est à vous de les mettre en place autour de MindooDB.

Voir les cas d'usage dans la santé → | Modèles détaillés →

Le Sarbanes-Oxley Act exige des pistes d'audit financières, des enregistrements immuables et des contrôles d'accès.

• Enregistrements immuables grâce à l'architecture append-only
• Intégrité cryptographique — le chaînage par empreintes prouve que les enregistrements n'ont pas été modifiés
• Historique complet des écritures avec signature de l'auteur, pour les exigences d'audit
• Voyage dans le temps pour reconstituer n'importe quel état passé
• Les modifications signées prouvent qui est l'auteur de chaque changement

⚠️ SOX exige aussi des contrôles internes, des attestations de la direction et une séparation des tâches — ce sont des responsabilités organisationnelles.

Voir les cas d'usage des services financiers → | Modèles détaillés →

Le règlement général sur la protection des données exige le droit à l'oubli, la portabilité des données, le suivi du consentement et la protection des données dès la conception.

• Effacement coordonné des données — purgeDocHistory() propage les demandes de suppression via la base de données d'annuaire à tous les clients synchronisés
• Portabilité des données grâce aux fonctions d'export de documents
• Protection des données dès la conception grâce au chiffrement de bout en bout
• Piste d'audit des écritures — historique append-only signé de toutes les modifications de données

⚠️ Les demandes de purge atteignent les clients à leur prochaine synchronisation d'annuaire — les appareils qui ne se reconnectent jamais conservent les données. Le RGPD exige aussi la gestion du consentement, la désignation d'un délégué à la protection des données et un registre des activités de traitement — cela relève de votre responsabilité.

Voir les modèles de conformité →

Le Payment Card Industry Data Security Standard exige la protection des données de cartes de paiement, des contrôles d'accès et des pistes d'audit.

• Chiffrement fort — AES-256-GCM au repos, RSA par utilisateur en transit, TLS sur le réseau
• Contrôles d'accès avec des clés nommées, pour restreindre l'accès aux données sensibles
• Piste d'audit des écritures — historique append-only signé de toutes les modifications de données

⚠️ PCI-DSS est une norme complète, qui couvre la segmentation réseau, la gestion des vulnérabilités, la surveillance et bien plus. MindooDB répond aux exigences de chiffrement et de contrôle d'accès — le reste relève de votre responsabilité. Demandez-vous si vous avez vraiment besoin de stocker des données de cartes.

Voir les modèles de conformité →

• ✅ Historique complet des écritures (append-only)
• ✅ Signatures cryptographiques (preuve de l'auteur)
• ✅ Enregistrements infalsifiables (chaînés par empreintes)
• ✅ Voyage dans le temps (reconstituer n'importe quel état)
• ✅ Modifications horodatées

• ✅ Chiffrement côté client (AES-256-GCM)
• ✅ Contrôle d'accès fin (clés nommées)
• ✅ Gestion des clés (KeyBag protégé par mot de passe)
• ✅ Effacement coordonné des données (purge propagée par l'annuaire)
• ✅ Souveraineté des données (tenants côté client)

• ⚙️ Journalisation des accès en lecture (couche applicative)
• ⚙️ Gestion du consentement (couche applicative)
• ⚙️ Contrôle d'accès basé sur les rôles (avec des clés nommées)
• ⚙️ Règles de conservation des données (avec le sharding par période)
• ⚙️ Reporting de conformité (avec les données d'audit)

• Chaque écriture est signée cryptographiquement avec la clé Ed25519 de son auteur
• Des horodatages figurent dans chaque entrée de modification
• L'historique du document peut être parcouru avec iterateDocumentHistory()
• Le voyage dans le temps permet de reconstituer n'importe quel état passé
• Les suppressions sont marquées par des tombstones (l'historique est préservé)

Remarque : MindooDB journalise automatiquement les écritures (qui a changé quoi). La journalisation des accès en lecture (qui a consulté quoi) doit être mise en œuvre au niveau applicatif.

• Prouver qui a modifié quoi et quand
• Reconstituer l'état à n'importe quel instant
• Démontrer l'intégrité des données aux auditeurs
• Construire par-dessus une journalisation des accès en lecture au niveau applicatif
• Soutenir les exigences de discovery judiciaire

Voir la documentation sur le voyage dans le temps →

• Sharding par période — Créer des bases de données par intervalle de temps (année, mois)
• Bases d'archives — Déplacer les anciennes données vers des bases d'archives en lecture seule
• Cycle de vie des documents — Marquer les documents comme archivés au lieu de les supprimer
• Purge coordonnée — Les demandes de purge signées par l'admin se propagent via la base de données d'annuaire ; les clients les exécutent à la prochaine synchronisation

Voir les modèles de modélisation des données →

• Le principe append-only fait que les données s'accumulent avec le temps
• Prévoir la gestion de cette croissance dès le départ
• Utiliser le sharding par période pour un archivage efficace
• Examiner les exigences de conservation par type de document
• La purge coordonnée se propage aux clients synchronisés ; les appareils hors ligne conservent les données

Voir les modèles de conformité →