# Privacy by Design — CatrustDB RGPD Compliance

> Document destiné aux DPO, auditeurs et équipes conformité.
> Version 1.1 — Avril 2026

---

## 1. Vue d'ensemble

CatrustDB intègre la protection des données dès la conception (*Privacy by Design*, Art. 25 RGPD).
Chaque commande serveur est auditable, les données sont chiffrées au repos et en transit,
et les droits des personnes concernées sont couverts par des commandes dédiées.

## 2. Matrice de conformité RGPD

| Article | Exigence | Implémentation CatrustDB | Commande |
|---------|----------|--------------------------|----------|
| **Art. 5** | Limitation de conservation | `--audit-log-max-days`, `compact` purge physique | `compact` |
| **Art. 15** | Droit d'accès | Recherche cross-entité de toutes les données d'un sujet | `data_subject_access` |
| **Art. 16** | Droit de rectification | Mise à jour ciblée par attribut/entité | `update` |
| **Art. 17** | Droit à l'effacement | Suppression logique + compactage physique | `delete`, `delete_where`, `compact` |
| **Art. 20** | Droit à la portabilité | Export portable par sujet + formats ouverts CSV/JSONL/Parquet | `data_subject_export`, `export_csv`, `export_jsonl`, `export_parquet` |
| **Art. 25** | Privacy by Design | Architecture auditée, chiffrement par défaut | — |
| **Art. 32** | Sécurité du traitement | AES-256-GCM (WAL), Argon2id (clé), TLS, RBAC 3 niveaux, anonymisation | `anonymize` |
| **Art. 33** | Notification de violation | Journal d'audit horodaté avec granularité entité/attribut | `audit_log` |
| **Art. 35** | Analyse d'impact (DPIA) | Rapport de conformité automatisé | `compliance_report` |

## 3. Architecture de sécurité

### 3.1 Chiffrement au repos

Le WAL (Write-Ahead Log) est chiffré en **AES-256-GCM** avec une clé dérivée via **Argon2id**.
Paramètres Argon2id : m=19456 KiB, t=2 itérations, p=1 thread.

```
Clé utilisateur → Argon2id(salt) → AES-256-GCM(nonce) → WAL chiffré sur disque
```

### 3.2 Chiffrement en transit

TLS optionnel via `--tls-cert` / `--tls-key`. Le rapport de sécurité (`security_report`)
indique dynamiquement si TLS est actif.

### 3.3 Contrôle d'accès (RBAC)

Trois niveaux d'autorisation :

| Rôle | Commandes autorisées | Activation |
|------|---------------------|------------|
| **Admin** | Toutes | `--token-admin <secret>` |
| **Read-Write** | Lecture + écriture (sauf `rotate_wal_key`) | `--token-rw <secret>` |
| **Read-Only** | Lecture seule (`ping`, `stats`, `export_*`, `query`, `data_subject_access`, `compliance_report`) | `--token-ro <secret>` |

> **Mode serveur global lecture seule** (sans auth) : `--read-only`

### 3.4 Journal d'audit

Chaque commande est enregistrée avec :
- Horodatage Unix (u64 secondes, champ `"ts"`) — équivalent UTC, convertible en ISO 8601
- Commande exécutée
- Entité / attribut concernés (quand applicable)
- Résultat (succès/échec)
- Adresse IP du client (si TCP)
- `token_id` : empreinte xxh3-64 du token Bearer (traçabilité sans exposer le secret)

Le journal est **infalsifiable** : chaque entrée contient un champ `prev_hash`
(xxh3-64 de l'entrée précédente), formant une chaîne d'intégrité détectable en cas de suppression.

Rétention configurable via `--audit-log-max-days` (défaut : illimité).

## 4. Droits des personnes concernées

> **Édition requise** : les commandes RGPD (`anonymize`, `data_subject_access`,
> `data_subject_export`, `compliance_report`) nécessitent une **licence Enterprise**.
> En édition Community, ces commandes retournent `{"ok":false,"error":"...nécessite une licence Enterprise"}`.

### 4.1 Droit d'accès (Art. 15) — `data_subject_access`

Recherche exhaustive dans **toutes les entités** d'un attribut donné.
Retourne les lignes correspondantes groupées par entité.

```json
{"cmd": "data_subject_access", "subject_attr": "email", "subject_value": "alice@example.com"}
```

Réponse : toutes les lignes où `email = alice@example.com`, dans toutes les entités.

### 4.2 Droit à l'effacement (Art. 17)

```json
{"cmd": "delete_where", "entity": "Employee", "attr": "email", "eq": "alice@example.com"}
{"cmd": "compact", "path": "data/db.wal"}
```

La suppression est d'abord logique (`delete`), puis physique après `compact`.

### 4.3 Anonymisation (Art. 32) — `anonymize`

Trois stratégies irréversibles :

| Stratégie | Résultat | Réversible |
|-----------|----------|------------|
| `hash` | xxHash3-128 hexadécimal (32 caractères) | Non |
| `mask` | `***` | Non |
| `redact` | `null` | Non |

```json
{"cmd": "anonymize", "entity": "Employee", "attr": "email", "strategy": "hash"}
```

### 4.4 Portabilité (Art. 20)

Export ciblé par sujet (document portable Art. 20) :

```json
{"cmd": "data_subject_export", "subject_attr": "email", "subject_value": "alice@example.com"}
```

Réponse : document JSON autonome avec `request_id` traçable, `generated_at`, toutes les données
du sujet dans toutes les entités — conçu pour être transmis directement à la personne concernée.

Export en formats ouverts (pour les intégrations) :

```json
{"cmd": "export_csv",     "entity": "Employee"}
{"cmd": "export_jsonl",   "entity": "Employee"}
{"cmd": "export_parquet", "entity": "Employee"}
```

## 5. Rapport de conformité automatisé

La commande `compliance_report` retourne un JSON avec :
- Couverture article par article (statut `ok`, `partial`, `not_implemented`)
- Posture sécurité (TLS, WAL, RBAC, audit, chaîne `prev_hash`)
- Statistiques base de données (entités, lignes actives)
- **`pending_soft_deletes`** : lignes supprimées logiquement mais non encore compactées (« dette RGPD »)
  — un DPO doit surveiller que cette valeur reste proche de zéro
- `generated_at` (timestamp Unix) et `generated_by` (version du serveur) pour traçabilité

```json
{"cmd": "compliance_report"}
```

Peut être appelé régulièrement par un outil de monitoring pour vérifier la conformité en continu.

## 6. Procédure en cas de violation de données (Art. 33 & 34)

> **Obligation** : Notification à l'autorité de contrôle (CNIL) **dans les 72 heures**
> après avoir pris connaissance d'une violation (Art. 33-1). Si la violation est
> susceptible d'engendrer un risque élevé pour les droits et libertés des personnes,
> notification directe aux personnes concernées également requise (Art. 34).

### 6.1 Détection

L'audit log NDJSON enregistre **toutes les opérations** avec horodatage, IP source,
commande, entité/attribut, résultat et empreinte du token utilisé (`token_id` xxh3-64).

Exemples de signaux d'alerte à surveiller dans le journal :
```bash
# Connexions refusées répétées (brute-force)
grep '"ok":false,"error":"unauthorized"' audit.jsonl | wc -l

# Commandes d'export massif inhabituelles
grep '"cmd":"export_csv"' audit.jsonl

# Rotations de clé non planifiées
grep '"cmd":"rotate_wal_key"' audit.jsonl
```

### 6.2 Qualification de la violation

```python
from catrustdb import connect

with connect(port=7474, token="admin-token") as db:
    # Posture sécurité au moment de l'incident
    report = db.compliance_report()
    # Rapport inclut : generated_at, TLS, WAL cifré, audit log, RBAC
    print(report["generated_at"], report["rgpd_coverage"]["art_32_security"])
```

Évaluer :
- **Confidentialité** : des données personnelles étaient-elles accessibles sans chiffrement ?
- **Intégrité** : le WAL (checksum xxh3 par entrée) montre-t-il des entrées corrompues ?
- **Disponibilité** : le service a-t-il été interrompu ?

### 6.3 Contenu de la notification CNIL (Art. 33-3)

La notification doit contenir :

| Élément | Source CatrustDB |
|---------|-----------------|
| Nature de la violation | Type de commande dans l'audit log |
| Catégories et nombre approximatif de personnes | `data_subject_access` + `stats` |
| Catégories et nombre approximatif d'enregistrements | `compliance_report["database"]` |
| Coordonnées DPO | Registre des traitements (`docs/registre-traitements.md`) |
| Conséquences probables | Évaluation manuelle |
| Mesures prises ou proposées | Voir §6.4 |

### 6.4 Remédiation immédiate

```bash
# 1. Révoquer le token compromis et émettre un nouveau token admin
catrustdb --token-admin "$NEW_ADMIN_TOKEN" ...

# 2. Rotation de la clé WAL (re-chiffrement à chaud)
echo '{"cmd":"rotate_wal_key","auth":"'"$NEW_ADMIN_TOKEN"'","path":"data/db.wal","new_key":"'"$NEW_KEY"'"}' \
  | nc localhost 7474

# 3. Anonymiser les attributs potentiellement exposés
echo '{"cmd":"anonymize","entity":"Employee","attr":"email","strategy":"hash"}' \
  | nc localhost 7474

# 4. Compaction physique (purge des soft-deletes)
echo '{"cmd":"compact","path":"data/db.wal"}' | nc localhost 7474
```

### 6.5 Délai et documentation

| Action | Délai |
|--------|-------|
| Notifier la CNIL | **72h** après prise de connaissance |
| Notifier les personnes si risque élevé | **Sans délai indu** (Art. 34) |
| Archiver le rapport d'incident | Conserver 5 ans minimum |

---

## 7. Transferts de données hors Union Européenne (Art. 44–49)

> CatrustDB lui-même ne transfert aucune donnée. C'est le déployeur qui est
> responsable de l'infrastructure d'hébergement. Ce chapitre couvre les
> sous-traitants utilisés par Catrust et les règles à appliquer.

### 7.1 Principes

Tout transfert vers un pays tiers doit reposer sur l'un des mécanismes de l'Art. 46 :
- **Clauses Contractuelles Types (SCC)** — mécanisme le plus courant
- **Règles d'entreprise contraignantes (BCR)** — pour les groupes internationaux
- **Décision d'adéquation** — États-Unis via EU-US Data Privacy Framework (2023)

### 7.2 Cartographie des services et transferts

| Service | Fournisseur | Localisation des données | Mécanisme de conformité |
|---------|-------------|--------------------------|------------------------|
| **Hébergement démo** | Fly.io | Région `cdg` — Paris **🇫🇷 UE** | Aucun transfert hors UE |
| **CI/CD + Releases** | GitHub (Microsoft Azure) | États-Unis 🇺🇸 | EU-US DPF + SCC Microsoft |
| **Images Docker** | Docker Hub (Docker Inc.) | États-Unis 🇺🇸 | SCC Docker à signer |
| **Déploiement client** | Environnement du déployeur | **À définir par le déployeur** | **Responsabilité du déployeur** |

### 7.3 Recommandations de déploiement

Pour garantir la conformité Art. 44 :

```toml
# fly.toml — Forcer la région EU
[env]
  PRIMARY_REGION = "cdg"   # Paris

[[regions]]
  name = "cdg"             # Seule région autorisée
```

```bash
# Vérifier que Fly.io ne déploie pas en dehors de l'UE
fly regions list
# S'assurer que seules les régions EU sont listées : cdg, ams, fra, lhr, mad, waw
```

### 7.4 Clause de responsabilité pour les déployeurs

> Lorsque CatrustDB est déployé sur une infrastructure hors UE (AWS us-east-1,
> Azure East US, GCP us-central1, etc.), le déployeur est responsable de :
> 1. Identifier la base légale du transfert (Art. 46 SCC ou Art. 49 dérogation)
> 2. Conclure les accords DPA avec l'hébergeur
> 3. Documenter ce transfert dans le registre des traitements (Art. 30-2-c)
> 4. Informer les personnes concernées (mention légale / politique de confidentialité)



## 8. Python SDK

```python
from catrustdb import connect

db = connect("localhost", 7474)
db.load_schema(open("schema.cql").read())

# Droit d'accès (Art. 15)
result = db.data_subject_access("email", "alice@example.com")

# Anonymisation (Art. 32)
db.anonymize("Employee", "email", strategy="hash")

# Rapport de conformité (Art. 35)
report = db.compliance_report()
print(report["rgpd_coverage"])
```

> **Nota** : `data_subject_export` n'est pas encore exposé dans le SDK Python — utiliser
> directement le protocole NDJSON : `{"cmd": "data_subject_export", ...}`.

## 9. Checklist DPO

### Mise en production
- [ ] **Licence Enterprise** activée (`--license-key <clé>`)
- [ ] TLS activé (`--tls-cert`, `--tls-key`)
- [ ] Authentification RBAC activée (`--token-admin`, `--token-rw`, `--token-ro`)
- [ ] WAL chiffré (`--wal-key`) — nécessite licence Enterprise
- [ ] Audit log activé (`--audit-log <path>`) avec rétention (`--audit-log-max-days 90`)
- [ ] Mode lecture seule pour les accès analytiques (`--read-only`)
- [ ] Déploiement en région EU (Fly.io `cdg` ou équivalent)

### Conformité documentaire
- [ ] Registre des traitements complété (`docs/registre-traitements.md`)
- [ ] DPA signés avec les sous-traitants (Fly.io, GitHub, Docker Hub)
- [ ] Politique de confidentialité publiée (mention des traitements)
- [ ] Procédure de violation documentée et testée

### Contrôles périodiques
- [ ] `compliance_report` intégré au monitoring (idéalement quotidien) — surveiller `pending_soft_deletes`
- [ ] `rotate_wal_key` planifié trimestriellement
- [ ] Revue de l'audit log mensuelle (contrôler la chaîne `prev_hash`)
- [ ] Test de restauration du registre (`compact` + `from_wal`) semestriel
- [ ] `data_subject_access` testé sur données réelles