BrainVault

Un seif de secrete scris în Rust — produs MSSP Braincap, aflat în dezvoltare.

Ce îl deosebește: broker de capabilități, nu depozit de credențiale

Majoritatea seifurilor (HashiCorp Vault, Infisical, OpenBao) păstrează un secret și îl predau la cerere. Asta mută problema, nu o rezolvă — clientul ajunge tot cu secretul în memoria lui.

• Depozit: clientul cere cheia SMTP → seiful o predă → clientul trimite emailul
• Broker: clientul cere „trimite acest email“ → seiful trimite, cu cheia lui

BrainVault face brokerul calea implicită. Compromiterea unei aplicații expune capacitatea (o acțiune limitată, auditată, revocabilă în secunde), nu credențiala (care ar funcționa de oriunde, la nesfârșit). Depozitul rămâne suportat, ca excepție documentată.

Ce e construit deja

• mTLS + identitate din certificat — tenant din emitent, rol din OU, subiect din SAN
• Criptare de plic — master → tenant → element → secret, cu rotație fără downtime
• Jurnal de audit înlănțuit — SHA-256; detectează modificarea, ruperea de legătură și ștergerea
• Broker de e-mail — model generic, extensibil dincolo de mail
• API de citire + RBAC + audit — depozitul, ca punte documentată
• Persistență redb — pur-Rust, fără C; secretele și lanțul de audit supraviețuiesc repornirii (discul ține doar ciphertext)
• Rotația cheii de tenant prin API — re-wrappează cheile de element fără a atinge secretele, atomic
• Dual-control (2P) — propunere și aprobare de identități diferite (separare a responsabilităților, BNR Norma 9)
• Rotația masterului prin 2P, cu keyring rezistent la crash
• Deblocare Shamir (k-din-n) — masterul e împărțit în share-uri

Al doilea factor: OTP (TOTP, RFC 6238)

Un certificat compromis singur nu e de-ajuns. OTP intră ca al doilea factor, legat de authenticator-ul unui om:

• La citire — seed-ul se întoarce o singură dată (pentru authenticator), e criptat la rest și nu iese niciodată către aplicație; citirea cere apoi codul. Un cert furat singur nu poate citi secretul.
• Pe operații privilegiate — instalarea, rotirea cheii de tenant și exportul cer codul din authenticator; citirea de rutină rămâne automată, ca să nu se rupă workload-ul.
• Impus la onboarding pentru tier reglementat — un tenant reglementat pornește cu OTP activ; instalarea/rotirea/exportul cer codul din prima zi.
• Break-glass cu aprobare în doi — dacă se pierde authenticator-ul, resetarea cere o propunere (TenantAdmin) + o aprobare de identitate diferită (SoD); seed-ul nou merge la aprobator, nu la proponent. Un cert de admin compromis singur nu poate reseta.
• Alertă loud în SIEM — evenimentele de break-glass pleacă cu severitate ridicată și un MSGID dedicat, ca o regulă de corelație să le prindă imediat — nu se pierd în zgomotul de audit.

Limite, spuse pe față

Root pe hostul seifului rămâne nerezolvabil. Cine are root și răbdare poate citi cheia master deblocată din memoria procesului (/proc/<pid>/mem). Vault are exact aceeași limitare; o scriem pe față. Ce facem ca să reducem fereastra și să ridicăm pragul de detecție:

• Secretele nu ajung pe disc — swap dezactivat sau mlock pe paginile sensibile; core dumps oprite (RLIMIT_CORE=0), ca un crash să nu scrie spațiul de adrese pe disc.
• zeroize + secrecy peste tot — copiile din memorie sunt șterse imediat ce nu mai sunt necesare; reduce fereastra, nu o închide.
• Master împărțit (Shamir) — nu există un master deblocat persistat; e reconstruit doar în memorie, la quorum.
• Detectabil, nu tăcut — jurnalul de audit înlănțuit (SHA-256) face vizibilă orice modificare, iar operațiile de excepție pleacă loud în SIEM. Un operator MSSP rău-intenționat e detectabil, chiar dacă nu prevenibil.

Garanția corectă: compromiterea aplicației expune capacitatea, nu credențiala — o acțiune limitată, auditată, revocabilă în secunde — pe durata împrumutului, cu audit complet.