Studio
Sécurité applicative avancée (Bridge, v0.7.192)
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, etpasso-authentifier/passo-mot-de-passe-changerrépondent par l'échec générique. - Coffre : fichier
<workspace>/.berkios/vault.jsonentièrement chiffré (AES-256-GCM). La clé maîtresse (≥ 20 caractères) vient de la variable d'environnementBERKIOS_VAULT_KEYdu 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 ;verifierdé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 saufBERKIOS_SYSTEM_ALLOW_PRIVATE_NETWORK=1; la résolution DNS est contrôlée à la connexion. - JWT : HS256 uniquement ;
alg: noneet 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.
Cette page en Markdown · llms.txt · documentation complète pour les IA