Unde trebuie să stea datele de autentificare

Orice panou de control găzduit pentru automatizarea serverelor vă cere același lucru în asistentul său de configurare: adresa hipervizorului dumneavoastră, un jeton de API, datele de root ale panoului dumneavoastră de găzduire web. Apoi le stochează, pentru că are nevoie de ele la fiecare cerere.

Este rezonabil ca software-ul să ceară asta și este sincer inconfortabil să fi fost de acord. Tocmai ați dat bazei de date a unui terț puterea de a șterge fiecare mașină pe care o dețineți. Nu printr-un defect și nu din rea-voință: acesta este comportamentul normal, documentat și corect al produsului.

Merită să fim preciși în privința a ceea ce vă aduc de fapt alternativele, pentru că „le criptăm în repaus” este răspunsul pe care îl dă toată lumea și, de unul singur, nu înseamnă mai nimic.

Criptate în repaus, decriptate de cine

Dacă un SaaS vă stochează criptat jetonul de hipervizor, cheia trebuie să fie undeva unde ajunge același SaaS, pentru că el trebuie să folosească jetonul în numele dumneavoastră cât timp dormiți. Criptarea în repaus protejează împotriva unui disc furat și a unei copii de siguranță scurse. Nu protejează împotriva lucrului de care vă temeți de fapt, adică platforma însăși compromisă.

Acesta nu este un argument împotriva criptării în repaus. Este un argument că întrebarea „unde este cheia” este singura întrebare și că un plan de control care poate decripta este un plan de control care poate fi pus să decripteze.

Alternativa structurală este al treilea rând: să nu aveți deloc secretul. Ceea ce sună facil, până când vă uitați cât costă să fie aranjat așa.

Țineți secretul acolo unde este mașina

Forma care funcționează: un agent mic rulează în rețeaua proprie a clientului, ține local datele de autentificare și se conectează spre exterior la platformă. Platforma trimite instrucțiuni. Agentul ține cheile.

Asta inversează raza de explozie. O compromitere a planului de control poate acum emite comenzi, ceea ce este rău și la care vom reveni, dar nu poate pleca cu un fișier plin de jetoane de hipervizor pentru fiecare client, pentru că nu există un asemenea fișier.

Părțile care fac lucrul acesta real nu au nimic spectaculos.

Seiful și împotriva a ce protejează el, sincer

Agentul nostru stochează datele de autentificare într-un fișier local criptat cu XChaCha20-Poly1305. Cheia nu este fișierul de pe disc: ea este derivată cu HKDF dintr-un fișier de cheie amestecat cu identitatea proprie a mașinii, iar datele autentificate suplimentare leagă textul cifrat de versiunea formatului și de ID-ul agentului.

Consecința practică este cea pentru care merită să proiectați. Copiați fișierul de cheie și seiful pe altă mașină și nu se deschide. Restaurați pe altă gazdă copia de siguranță de luna trecută a directorului de date și nu se deschide. Fiecare mod de eșec, cheie greșită, alt agent, octeți modificați, produce aceeași eroare imposibil de deosebit, iar asta este tocmai ideea.

Iată partea care își are locul în documentația oricărui produs care face asta și care de obicei nu se află acolo. Asta nu protejează împotriva unui root pe gazdă. Nici nu poate, și nici nu are nevoie: clientul deține gazda și deține datele de autentificare. Seiful protejează împotriva unui fișier scurs, nu împotriva proprietarului mașinii. Un furnizor care sugerează altceva vă vinde o senzație.

Datele de autentificare nu ating niciodată baza de date a platformei

Aceasta este partea ușor de greșit în timp ce credeți că ați nimerit-o, pentru că, în oricare dintre variante, codul arată bine.

Când cineva tastează un jeton de hipervizor în panoul nostru, rândul care ajunge în tabelul de comenzi conține doar numele câmpurilor. Valorile călătoresc într-un mesaj tranzitoriu separat, care nu este stocat, și intră direct în livrarea către agent. Dispecerul nu le consemnează niciodată în jurnal și nu le păstrează niciodată.

Dacă evaluați un produs după acest criteriu, întrebarea de pus nu este „stocați date de autentificare”. Este „ce se află în jurnalul dumneavoastră de audit și ce se află în coada dumneavoastră”. O coadă care poartă secretul este o bază de date care poartă secretul, cu pași în plus.

Ștergerea unui secret este o altă problemă decât păstrarea lui

Eliminarea unei integrări din panou trebuie să ducă la dispariția datelor de autentificare de pe o mașină pe care nu o controlați, ceea ce este o problemă mai grea decât pare.

Implementarea evidentă este o reconciliere: întrebați agentul ce are, comparați cu ce spune baza de date că ar trebui să aibă, ștergeți diferența. Este mai scurtă și este periculoasă, pentru că scăderea eșuează înspre totul a dispărut. O citire eșuată, o listă trunchiată, și ați generat o instrucțiune de a șterge fiecare integrare funcțională de pe acea gazdă, iar acele date de autentificare nu se pot recupera fără ca clientul să le tasteze din nou.

Așa că instrucțiunea vine numai din cunoaștere pozitivă: un rând există pentru că cineva chiar a șters o integrare. O citire eșuată produce zero rânduri și, prin urmare, zero instrucțiuni, iar secretul rămâne unde era, adică exact starea în care erați înainte.

Este livrată de două ori: imediat pe magistrala de evenimente și din nou la fiecare inițiere de sesiune, pentru agentul care era deconectat, pentru mesajul pierdut, pentru gateway-ul care a repornit. Ambele trasee citesc același tabel, așa că nu există un al doilea adevăr și nici o a doua ordonare.

Ce poate și ce nu poate face un certificat de agent furat

Dacă agentul se autentifică cu un certificat de client, întrebarea sinceră este ce se întâmplă când cineva îl ia. A fi concret aici este mai util decât o pagină despre securitate.

Poate uzurpa identitatea acelui singur agent. Portul de sesiune cere TLS mutual, iar peste verificarea TLS amprenta certificatului partenerului este căutată în tabelul agenților, care are un indice unic. O amprentă indică deci exact un agent, iar identitatea pretinsă la inițierea sesiunii este comparată cu el. Un atacator care are certificatul devine acel agent și poate trimite orice are voie să trimită un agent: evenimente de stare, rezultate, telemetrie.

Nu poate citi datele altor clienți. Totul este delimitat de organizația căreia îi aparține agentul, rezolvată din certificat și nu din ceva ce spune clientul despre sine.

Nu dă de la sine datele de autentificare. Certificatul este identitatea folosită pentru a vorbi cu platforma. Cheia seifului este separată, trăiește pe gazdă și este legată de identitatea de mașină a acelei gazde. Cine le are pe amândouă are root pe mașină, iar în acel punct certificatul este cea mai mică dintre griji.

Încetează să funcționeze când spuneți dumneavoastră, în vreun minut. Revocarea este o stare în baza de date, nu un CRL și nu OCSP. O conexiune nouă este refuzată imediat. O conexiune existentă este reverificată la un interval de un minut, așa că un atacator deja conectat are cel mult atât. Dacă verificarea de stare eșuează ea însăși în continuare, sesiunea este închisă după trei eșecuri consecutive, în loc să fie ținută deschisă la nesfârșit, ceea ce mărginește cazul cel mai rău la aproximativ trei minute.

Iar agentul face curat după el. La revocare șterge seiful, cheia seifului, identitatea sa, starea sesiunii și cozile, în această ordine, mai întâi datele de autentificare. Fiecare pas se face după puteri și este consemnat separat în jurnal, pentru că o jumătate de ștergere este mai bună decât nicio ștergere.

Certificatele sunt și de scurtă durată, nouăzeci de zile, reînnoite automat la jumătatea drumului, cu o verificare din oră în oră. Aceasta nu este atât o apărare împotriva furtului, cât o margine pentru cât timp mai rămâne util un furt pe care nu l-a observat nimeni.

Ce nu rezolvă asta

Trei lucruri, spuse pe șleau, pentru că un model de amenințare fără risc rezidual este o pagină de marketing.

Un plan de control compromis poate în continuare emite comenzi. Nu vă poate fura jetoanele, dar poate spune agentului dumneavoastră să șteargă o mașină, iar agentul o va face. Mutarea secretelor mută raza de explozie; nu o elimină. Ce primiți înapoi este că paguba este mărginită de ce poate exprima API-ul și este vizibilă într-un traseu de audit, în loc să fie un atacator cu datele dumneavoastră de autentificare care face ce vrea, direct pe hipervizorul dumneavoastră, la trei dimineața.

Un root pe gazda agentului citește tot. Prin proiectare. Dacă acea gazdă este compromisă, aveți o mașină compromisă în propria dumneavoastră rețea, iar ea are datele dumneavoastră de autentificare pentru hipervizor, pentru că acolo trebuie să fie.

Ștergerea depinde de întoarcerea agentului. Dacă o gazdă nu se mai reconectează niciodată, instrucțiunea de a-i uita datele de autentificare rămâne deschisă. Asta este vizibilă în panou, în loc să fie marcată în tăcere drept încheiată, ceea ce este compromisul corect, dar este o limitare reală și merită știută înainte să vă bazați pe ea.

Întrebări care merită puse unui furnizor

Orice ați cumpăra până la urmă, aceste cinci despart produsele care s-au gândit la asta de cele care au scris un paragraf:

1. 01Unde este cheia de decriptare, fizic? Dacă răspunsul este „în platforma noastră”, criptarea în repaus protejează împotriva furtului de disc și a nimic altceva.
2. 02Ce se află în jurnalul de audit și în coada de sarcini? Secretele se scurg în amândouă mult mai des decât în tabelul cu care a fost cineva atent.
3. 03Ce se întâmplă cu datele de autentificare când șterg o integrare și pot vedea dacă s-a întâmplat cu adevărat?
4. 04Cât durează revocarea accesului și se aplică sesiunilor deja deschise?
5. 05Are nevoie ceva de un port de intrare? O regulă de firewall care lasă intervalul de adrese al unui furnizor să ajungă la interfața de administrare a hipervizorului dumneavoastră este o a doua versiune, mai tăcută, a aceleiași probleme.

Așa l-am construit la Provibr: agentul rulează pe hardware-ul propriu al clientului, ține local datele de autentificare și se conectează numai spre exterior.