De ce să protejezi o parolă, dacă poți renunța la ea?

O problemă pe care am ajuns să o considerăm normală

Practic, orice aplicație web are un panou de administrare. Iar un panou de administrare are, de regulă, o adresă de autentificare, un formular de conectare, un nume de utilizator și o parolă.

Ne-am obișnuit atât de mult cu această structură, încât aproape că am încetat să ne întrebăm: oare totul trebuie să funcționeze neapărat așa?

Când ai un singur site, problema nu pare importantă. Creezi o parolă complexă, activezi autentificarea în doi pași, configurezi limitarea încercărilor de conectare — și îți vezi de treabă.

Dar ce se întâmplă când ajungi să ai zece, douăzeci sau treizeci de proiecte?

În cazul meu, este vorba despre ecosistemul DigiMeld, care reunește peste treizeci de proiecte software independente. Fiecare are propria arhitectură, propria logică de server și propria interfață de administrare.

Prin urmare, fiecare are nevoie de un mecanism de acces administrativ.

Mult timp am folosit o abordare cât se poate de obișnuită: date de autentificare administrative separate, parole complexe și salvarea lor în browser.

Funcționa.

Dar, la un moment dat, m-am întrebat: de ce ar trebui să păstrez atâtea parole administrative? De ce trebuie să protejez nu doar serverele, ci și mijloacele prin care obțin acces la ele?

Și nu aș putea renunța la această necesitate?

Am ajuns la o idee care, în cele din urmă, a devenit baza soluției mele:

Poate că ar trebui să protejăm nu o cale de acces permanentă, ci dreptul de a obține acces temporar.

Și dacă nu ar exista deloc pagina obișnuită de autentificare?

Am decis să renunț la modelul tradițional de autentificare administrativă în proiectele mele.

Nu doar să ascund formularul de autentificare.

Nu să schimb adresa.

Nu să înlocuiesc parola cu una și mai complexă.

Ci să elimin însăși necesitatea unei autentificări permanente cu parolă.

Desigur, interfețele de administrare nu au dispărut nicăieri. Ele sunt în continuare necesare pentru gestionarea aplicațiilor.

S-a schimbat modul în care se obține accesul la ele.

Acum, pentru a intra în panourile de administrare ale proiectelor conectate, nu este nevoie să introduci un nume de utilizator și o parolă salvate.

În schimb, folosesc propriul meu sistem de identificare și gestionare a accesului, MeldID.

Ideea este destul de simplă: accesul administrativ se acordă doar atunci când este cu adevărat necesar, unui anumit utilizator și pentru un anumit proiect.

Mai mult, simplul fapt că există un cont nu înseamnă că titularul are dreptul să deschidă panoul de administrare.

Acest drept trebuie acordat separat.

Un acces care nu exista cu un minut în urmă

Probabil aceasta este cea mai interesantă parte a întregului concept.

În modelul tradițional, administratorul are permanent la dispoziție mijloacele de autentificare. Le poate folosi astăzi, mâine sau peste o lună, atât timp cât acestea rămân valabile.

Am decis să schimb acest principiu.

În locul datelor de autentificare administrative permanente, folosesc o posibilitate temporară de a iniția autentificarea.

Aceasta este creată la cerere, prin intermediul unui dispozitiv mobil de încredere, include o componentă aleatorie rezistentă criptografic și are o perioadă de valabilitate limitată.

Dar nici simpla deținere a unui astfel de link temporar nu înseamnă că ai obținut acces.

Acesta este un aspect esențial.

Să presupunem că cineva obține linkul într-un fel sau altul. Într-un sistem obișnuit, bazat exclusiv pe secretizarea adresei, o astfel de scurgere ar putea deveni o problemă serioasă.

În modelul meu, linkul permite doar inițierea procedurii de confirmare.

Pentru a continua, este necesară o aprobare separată, prin intermediul unui dispozitiv mobil de încredere cu MeldID.

Fără confirmarea corespunzătoare, sesiunea administrativă nu este creată.

De aceea, consider linkul temporar nu un înlocuitor pentru parolă, ci unul dintre elementele procedurii de acordare a accesului.

A ști unde să te adresezi și a avea dreptul să intri sunt lucruri complet diferite.

Telefonul devine un instrument de gestionare a accesului

În acest model, dispozitivul mobil joacă un rol mult mai important decât cel al unui generator obișnuit de coduri de unică folosință.

Este folosit pentru confirmarea acțiunilor legate de accesul administrativ.

Când vreau să deschid panoul de administrare, sistemul solicită o confirmare prin MeldID.

Văd solicitarea corespunzătoare pe dispozitivul de încredere și confirm acțiunea.

Abia după verificarea cu succes, sistemul permite continuarea procedurii de autentificare.

În același timp, confirmarea este legată de o anumită acțiune, nu doar de faptul că telefonul a fost deblocat.

Biometria de pe dispozitivul mobil verifică utilizatorul la nivel local, iar partea de server verifică confirmarea criptografică provenită de la dispozitivul înregistrat.

Astfel, nu trebuie să ne bazăm exclusiv pe o parolă sau pe un mesaj care pretinde că utilizatorul a confirmat autentificarea.

Aici apare și un alt avantaj: dispozitivele de încredere pot fi gestionate.

Dacă un dispozitiv nu mai trebuie folosit pentru confirmarea accesului, statutul său de dispozitiv de încredere poate fi revocat.

După aceea, nu mai poate fi folosit pentru autorizarea operațiunilor respective.

Un singur sistem — o mulțime de proiecte independente

Când am început să dezvolt acest mecanism, unul dintre obiectivele principale a fost să păstrez independența fiecărui proiect.

Nu am vrut să unesc toate panourile de administrare într-o singură aplicație uriașă.

Fiecare serviciu DigiMeld trebuie să își gestioneze în continuare propria logică, propriile setări, utilizatori și date.

De aceea, am separat cele două responsabilități.

MeldID se ocupă de identificare și de acordarea accesului administrativ.

Proiectul în sine se ocupă de propriile funcții administrative și de verificarea permisiunilor active.

Astfel, am obținut un model centralizat de gestionare a accesului, fără a fi nevoie să centralizez aplicațiile în sine.

În plus, permisiunile se acordă separat.

Un administrator al unui proiect nu primește automat acces la celelalte doar pentru că are un cont MeldID.

Pentru fiecare zonă administrativă poate fi definit propriul grup de utilizatori autorizați.

În același timp, drepturile utilizatorilor obișnuiți și privilegiile administrative sunt separate.

Acest lucru s-a dovedit deosebit de util pentru un ecosistem format din zeci de servicii.

De ce prefer accesul temporar celui permanent

Există un alt principiu pe care l-am inclus în mod deliberat în sistem.

Accesul administrativ nu ar trebui să dureze la nesfârșit.

Permisiunea este valabilă o perioadă limitată și expiră indiferent dacă utilizatorul continuă sau nu să lucreze în browser.

Pentru a continua lucrul după expirarea termenului, este necesară o nouă procedură de confirmare.

Astfel, o autentificare efectuată o singură dată nu se transformă într-un drept permanent.

Dar limitarea în timp, de una singură, nu este suficientă.

Este important să poți încheia mai devreme accesul deja acordat.

De aceea, MeldID include posibilitatea de a revoca centralizat permisiunile administrative.

Când o permisiune este revocată, proiectele conectate primesc evenimentul corespunzător și anulează sesiunile administrative asociate.

Astfel, gestionarea accesului nu se încheie în momentul în care utilizatorul s-a autentificat cu succes.

Posibilitatea de a revoca privilegiile este pentru mine la fel de importantă ca posibilitatea de a le acorda.

În același timp, un sistem distribuit trebuie să țină cont de întârzierile în transmiterea evenimentelor, de indisponibilitatea temporară a unor componente și de alte situații operaționale. Limitarea duratei sesiunilor oferă o măsură suplimentară de siguranță.

Și ce s-a schimbat în activitatea de zi cu zi?

În primul rând, nu mai este nevoie să apelez constant la parole administrative salvate.

Nu mai trebuie să păstrez în browser un set de date de autentificare pentru fiecare panou de administrare conectat.

În schimb, gestionez permisiunile printr-un mecanism unic.

Aleg proiectul necesar, confirm accesul și îmi văd de treabă.

Când nu mai este nevoie de acces administrativ, acesta poate fi revocat.

Este deosebit de util faptul că, atunci când apare un proiect nou, nu trebuie să reproiectez de la zero întregul sistem de autentificare administrativă.

Este suficient să îl conectez la modelul existent și să definesc permisiunile necesare.

Desigur, asta nu înseamnă că au dispărut toate riscurile de securitate.

Permisiunile temporare, dispozitivele de încredere, sesiunile de server și infrastructura centrală trebuie, la rândul lor, protejate.

Dar nu mai trebuie să rezolv separat, pentru fiecare aplicație, aceeași problemă a gestionării parolelor administrative.

Iar acesta a fost unul dintre obiectivele mele inițiale.

Nu există deja tehnologii de acest fel?

Ba da, există.

Autentificarea fără parolă, gestionarea accesului privilegiat, permisiunile temporare și confirmarea prin dispozitive de încredere sunt cunoscute de mult timp în industria securității informațiilor.

Astfel de abordări sunt întâlnite în sistemele de gestionare a identității și accesului (Identity and Access Management), de gestionare a accesului privilegiat (Privileged Access Management) și în conceptele Zero Trust.

Nu pretind că am inventat aceste principii.

Obiectivul meu a fost altul.

Aveam nevoie să creez un sistem integrat propriu, care să rezolve problemele concrete ale infrastructurii DigiMeld și să permită gestionarea accesului administrativ pentru numeroase proiecte independente.

În cele din urmă, am reunit mai multe abordări cunoscute într-o singură arhitectură, adaptată cerințelor mele.

Și consider că valoarea muncii de inginerie nu constă neapărat în inventarea unei tehnologii complet noi.

Uneori, constă în formularea corectă a problemei și găsirea unei soluții potrivite.

MeldID nu este doar pentru panourile de administrare

Aici merită să fac o precizare separată.

MeldID nu a fost creat exclusiv ca instrument pentru accesul meu administrativ.

Le oferă și dezvoltatorilor un SDK pentru integrarea mecanismelor de identificare și confirmare a autentificării în propriile aplicații.

Mai mult, acest SDK este disponibil gratuit.

De exemplu, un dezvoltator terț poate folosi MeldID ca nivel suplimentar de confirmare a autentificării utilizatorilor.

Chiar dacă aplicația păstrează metoda tradițională de autentificare cu nume de utilizator și parolă, introducerea corectă a acestor date poate să nu fie suficientă pentru finalizarea autentificării.

Utilizatorul primește o solicitare pe dispozitivul mobil de încredere, unde poate confirma sau respinge încercarea de autentificare.

Astfel, riscul accesului neautorizat poate fi redus în cazul compromiterii datelor de autentificare.

Este important să distingem această funcționalitate MeldID, disponibilă publicului larg, de modelul de acces administrativ pe care l-am dezvoltat pentru proiectele DigiMeld.

Ambele folosesc principii comune de încredere și confirmare a acțiunilor, dar rezolvă probleme diferite.

Securitatea nu înseamnă doar protejarea a ceea ce există

Lucrul la acest sistem m-a făcut să privesc altfel mecanismele de autentificare cu care eram obișnuit.

Încercăm adesea să protejăm lucruri care există din motive istorice.

Adăugăm verificări noi, restricții, parole suplimentare și straturi de protecție.

Uneori, acest lucru este cu adevărat necesar.

Dar, uneori, este mai util să punem o altă întrebare:

Este oare obligatoriu ca mecanismul pe care încercăm să îl protejăm să existe în continuare în forma sa actuală?

În cazul meu, răspunsul a fost negativ.

Nu aveam nevoie de un formular de autentificare administrativă disponibil permanent.

Aveam nevoie de posibilitatea de a obține în siguranță privilegii administrative exact atunci când sunt necesare.

Sunt două probleme diferite.

Iar trecerea de la prima la a doua a schimbat nu doar arhitectura tehnică, ci și activitatea de zi cu zi cu proiectele.

Nu un punct final, ci o direcție aleasă

Astăzi, această arhitectură funcționează deja într-o mare parte a ecosistemului DigiMeld.

Proiectele rămase sunt transferate treptat la noul model de acces administrativ.

Fac migrarea etapizat, verificând funcționarea fiecărei aplicații, iar după încheierea tranziției plănuiesc un audit suplimentar al întregului sistem.

Unele elemente ale interfeței și regulile de gestionare a sesiunilor se mai pot schimba.

Însă ideea de bază este deja stabilită.

Nu vreau să mă întorc la modelul în care, pentru a gestiona zeci de proiecte proprii, trebuie să păstrez și să folosesc în permanență zeci de parole administrative.

În același timp, nu consider că implementarea mea este o soluție universală pentru toată lumea.

Organizațiile au cerințe, infrastructuri, modele de amenințări și metode de administrare diferite.

Ceea ce este convenabil și justificat pentru ecosistemul DigiMeld s-ar putea să nu fie optim pentru un alt dezvoltator.

Cu toate acestea, principiul acordării temporare a privilegiilor merită atenție.

În loc de concluzie

Am decis să împărtășesc această experiență nu pentru că mă consider inventatorul unei noi metode de autentificare.

Și nici pentru că vreau să prezint încă un sistem drept complet sigur.

Securitatea absolută nu există.

Pur și simplu, mi se pare interesantă însăși formularea problemei.

În loc să protejăm la nesfârșit o cale permanentă de acces administrativ, putem regândi necesitatea existenței ei.

În loc să păstrăm o mulțime de parole, putem folosi permisiuni temporare.

În loc să acordăm automat încredere după prima autentificare, putem confirma acordarea unor privilegii concrete.

În loc să așteptăm expirarea sesiunii, putem prevedea posibilitatea revocării centralizate a accesului.

Și, în cele din urmă, în loc să avem un mecanism separat de autentificare pentru fiecare proiect, putem construi un sistem unic de gestionare a accesului administrativ, păstrând totodată independența aplicațiilor.

Nu susțin că această abordare elimină posibilitatea unei compromiteri.

Pur și simplu, mută accentul de la protejarea unor date de autentificare existente permanent la acordarea și revocarea controlată a privilegiilor.

Poate că, uneori, cel mai eficient mod de a reduce suprafața de atac nu este să adăugăm încă un mecanism de protecție, ci să renunțăm la ceva de care sistemul se poate lipsi.

De la acest gând a început, pentru mine, povestea MeldID Admin Gateway.