# Sécurité applicative avancée (Bridge, v0.7.192)

Source : https://docs.berkios.online/studio/securite-avancee/ · Section : Studio · Documentation officielle BERKIOS (https://docs.berkios.online)


21 commandes système implémentées dans `bridge/security-advanced.mjs` (Node.js natif : `node:crypto`, `node:tls`), enregistrées dans le registre du Bridge et dans `compiler/src/system-command-registry.json`. Comme toutes les commandes système, elles sont **exécutées par le Bridge** (desktop/serveur), avec la permission indiquée accordée explicitement par l'hôte. `permission-verifier` existait déjà.

| Commande | Arguments | Résultat | Permission |
|---|---|---|---|
| `chiffrer-symetrique` | texte, clé (≥ 16 o), contexte? | `bkx1.…` (AES-256-GCM, clé dérivée par scrypt, sel et IV aléatoires) | `security.crypto` |
| `dechiffrer-symetrique` | texte chiffré, clé, contexte? | texte clair ; erreur `decryption_failed` si clé/contexte faux ou données altérées | `security.crypto` |
| `signer-donnee` | texte, clé, algorithme? | signature base64url. Algorithmes : `hmac-sha256` (défaut), `hmac-sha512`, `rsa-pss-sha256`, `rsa-sha256`, `ecdsa-p256` (IEEE P1363) | `security.crypto` |
| `verifier-signature` | texte, signature, clé, algorithme? | booléen (comparaison en temps constant pour HMAC ; clé publique ou privée PEM pour RSA/ECDSA) | `security.crypto` |
| `cle-signature-generer` | `ecdsa` (défaut) ou `rsa` | `{ publique, privee }` PEM (EC P-256, RSA 3072) — ajoutée pour rendre RSA/ECDSA utilisables | `security.generate` |
| `certificat-verifier` | url, empreinte SHA-256?, port?, exiger-chaine? (`non`) | `{ value, chaineValide, empreinteCorrespond, empreinte, sujet, emetteur, valideJusqu… }` | `network.read` |
| `secret-lire` / `secret-ecrire` | nom [, valeur] | valeur / `{ value, remplace }` | `security.vault` |
| `jeton-generer` | charge JSON, secret (≥ 32 o), durée? (s, défaut 3600, max 30 j) | JWT HS256 avec `iat`, `exp`, `jti` | `security.crypto` |
| `jeton-verifier` | jeton, secret | `{ value, charge }` ou `{ value:false, raison }` (`format`, `algorithme`, `signature`, `expire`, `pas_encore_valide`) | `security.crypto` |
| `jeton-renouveler` | jeton valide, secret, durée? | nouveau JWT (même charge, nouveau `jti`) ; refus si expiré ou invalide | `security.crypto` |
| `session-creer` | utilisateur, rôles? (`a,b` ou JSON), durée? (s, max 24 h) | `{ value: jeton opaque, expiresAt }` | `security.session` |
| `session-verifier` / `session-detruire` | jeton | `{ value, utilisateur, roles }` / booléen | `security.session` |
| `csrf-generer` | contexte | jeton lié au contexte (HMAC, horodaté) | `security.crypto` |
| `csrf-verifier` | jeton, contexte, âge max? (s, défaut 7200) | booléen | `security.crypto` |
| `limiter-tentatives` | clé, maximum, fenêtre (s) | `{ value: autorisé, restant, reinitialiseDansSecondes }` — fenêtre glissante, les refus ne prolongent pas le blocage | `security.session` |
| `verrouiller-compte` | identifiant, mode? (`verrouiller` défaut, `deverrouiller`, `statut`), durée? (s, défaut 900), raison? | `{ value: verrouillé, jusqua, raison }` | `security.session` |
| `role-verifier` | session ou liste de rôles, rôle, hiérarchie JSON? | booléen + rôles effectifs (héritage `{"admin":["editeur"]}`, cycles tolérés) | `security.session` |
| `audit-securite` | mode? (`ecrire` défaut, `lire`, `verifier`), événement, détails?, niveau? (`info`, `warn`, `alert`, `critical`) | écriture : `{ numero, empreinte }` ; lecture : N dernières entrées ; vérification : `{ value, entrees, premiereErreur }` | `security.audit` |
| `masquer-donnee` | texte, types? (liste) | `{ value, masques, total }` — types : `jeton, secret, email, iban, nir, carte, ip, telephone` | `security.crypto` |

## Comportements à connaître

- **Verrouillage ↔ sessions ↔ Passo** : un compte verrouillé voit ses sessions applicatives détruites, ne peut plus en créer, échoue à `role-verifier`, et `passo-authentifier` / `passo-mot-de-passe-changer` répondent par l'échec générique.
- **Coffre** : fichier `<workspace>/.berkios/vault.json` entièrement chiffré (AES-256-GCM). La clé maîtresse (≥ 20 caractères) vient de la variable d'environnement `BERKIOS_VAULT_KEY` du Bridge ; elle n'est jamais passée en argument de commande. Sans elle : `vault_locked`. Perdre la clé = perdre les secrets. 500 secrets et 8 Kio par secret au maximum.
- **Audit** : `<workspace>/.berkios/audit-securite.jsonl`, chaque entrée contient l'empreinte de la précédente ; `verifier` détecte toute modification ou suppression d'une entrée intermédiaire. Elle ne détecte pas la suppression des *dernières* entrées ni une réécriture complète de la chaîne par quelqu'un qui contrôle le fichier : pour cela, conserver l'empreinte de la dernière entrée ailleurs. Les détails sont masqués avant écriture (clés sensibles, e-mails, IBAN…). Plafond : 5 Mio.
- **État en mémoire** : sessions, verrous, compteurs de limitation et secret CSRF sont propres au dossier de travail et **perdus au redémarrage du Bridge** (les jetons CSRF émis deviennent invalides). Le coffre et l'audit sont persistants.
- **Épinglage TLS** : par défaut la chaîne doit être approuvée **et** l'empreinte correspondre. Avec `exiger-chaine = non`, seule l'empreinte compte (utile pour un certificat auto-signé épinglé). Sans empreinte, la commande valide seulement la chaîne et renvoie l'empreinte à épingler. Adresses privées refusées sauf `BERKIOS_SYSTEM_ALLOW_PRIVATE_NETWORK=1` ; la résolution DNS est contrôlée à la connexion.
- **JWT** : HS256 uniquement ; `alg: none` et toute autre valeur sont refusés. Pas de liste de révocation : pour invalider un jeton avant son expiration, changer le secret ou utiliser des sessions.
- Ne jamais journaliser clés, secrets, jetons ni sorties de `cle-signature-generer`.