Doi ani de OneIdP: Construirea încrederii zero dincolo de identitate

Există o întrebare pe care fiecare administrator IT încetează în cele din urmă să o pună cu voce tare, pentru că a acceptat că nu are un răspuns clar.

„De ce știu totul despre acest dispozitiv — și aproape nimic despre cine stă de fapt în fața lui chiar acum?”

Ai starea patch-urilor, statutul de conformitate, inventarul aplicațiilor și locația. Poți șterge datele de la distanță la ora 2 dimineața de pe telefon. Dar persoana care se conectează la ora 9 dimineața? Aceasta este în mare parte o strângere de mână și o parolă pe care cineva probabil a reutilizat-o din alte trei conturi.

Această lacună este motivul pentru care există OneIdP. Și, după doi ani, iată povestea sinceră a ceea ce a fost necesar pentru a o elimina.

Lumea în care trăiau de fapt echipele IT

Răspunsul convențional era deja bine stabilit: cumpărați un instrument IAM, integrați-l în UEM-ul dvs., configurați SSO undeva între acestea. 

Furnizori diferiți, tablouri de bord diferite și locuri diferite în care politica dvs. se poate contrazice în liniște în momentul în care un caz extrem intră pe ușă.

Problema mai profundă era că Scalefusion Mediile IT recunoscute pentru întreprinderi nu sunt construite în jurul unor scenarii clare - sunt construite în jurul unor excepții. Dispozitive partajate, integrare de la distanță, contractori pe laptopuri personale și echipe distribuite pe cinci fusuri orare, ca să numim doar câteva.

Acestea nu erau cazuri limită în jurul cărora să se gestioneze. Erau condițiile reale de operare.

Totuși, majoritatea strategiilor de acces erau încă scrise pentru o lume în care toată lumea se prezenta la același birou, pe același dispozitiv gestionat, în fiecare zi. Așadar, autentificarea a devenit proxy-ul pentru orice. Autentificarea era tratată ca o problemă rezolvată. Verificați parola, acordați sesiunea. Gata.

Majoritatea deciziilor privind accesul erau încă luate având în vedere doar o parte din imagine. Deoarece cunoașterea identității cuiva nu spune aproape nimic despre de pe ce se conectează. Dacă dispozitivul respectiv a fost actualizat. Dacă aparține organizației. Fie că este vorba de mașina înscrisă în trimestrul trecut sau de un laptop personal din holul unui hotel.

Acesta a fost decalajul pe care ne-am propus să-l închidem.

Ce am livrat în prima zi — și de ce a fost doar începutul

Când s-a lansat OneIdP, am făcut o alegere deliberată pe care majoritatea echipelor de produs nu o fac. Am lansat o listă de funcționalități în loc de o listă de funcționalități.

Un director în cloud. Acces condiționat prin Keycard. MFA care se afla în același tablou de bord folosit deja de echipele IT în fiecare zi. Fundația era deliberat solidă înainte de a fi bogată în funcții. 

keycard permite echipelor IT să seteze condiții reale de acces - locații aprobate, intervale IP de încredere, rețele Wi-Fi specifice și ferestre bazate pe timp. Pentru echipele care rulau cu parole partajate și autentificări fără context, chiar și prima versiune reprezenta un mod de lucru diferit.

Teren solid, înainte să începem să construim.

Și apoi s-a întâmplat ceva care ne-a spus că fundația chiar a aterizat. Și în câteva luni, clienții nu mai întrebau dacă OneIdP funcționa. Se gândeau deja la ce urma. 

• Cum să integreze configurația existentă Okta sau Entra. 
• Cum să luați decizii de acces care să reflecte conformitatea dispozitivului, nu doar identitatea. 
• Cum să faci să funcționeze pentru echipele care lucrează în ture și care își împart mașinile pe parcursul unei zile întregi de lucru.

Aceea era harta și am urmat-o.

Doi ani de construcție pentru acea realitate

Majoritatea instrumentelor de identitate sunt construite în jurul unor presupuneri.

Că o acreditare validă înseamnă o sesiune sigură. Că echipele IT își vor reconstrui directorul pentru a se potrivi unei noi platforme. Că cineva cu expertiză vastă în IAM va fi disponibil pentru a le întreține pe toate.

Aceste presupuneri au fost integrate în managementul accesului la nivel de întreprindere timp de ani de zile, pentru că, ei bine, nimeni nu s-a oprit să le pună la îndoială.

I-am interogat pe toți trei.

1. Identitatea este suficientă pentru a acorda acces

SSO, așa cum l-a reprezentat întotdeauna industria, se oprește în momentul în care se verifică acreditările. Utilizatorul este cine pretinde că este. Sesiune permisă.

Ceea ce nu a întrebat niciodată a fost ce se află în spatele acreditării. Dacă dispozitivul este actualizat. Dacă solicitarea provine dintr-o locație logică. Dacă aplicația accesată ar trebui să fie deschisă pe acel computer în acel moment.

Am construit Politici de acces extins (XAP) să întrebi exact asta.

Fiecare conectare este evaluată în raport cu imaginea completă. Semnalele de conformitate live ale dispozitivelor de la Veltar sunt influențate direct decizia de acces. Dacă ceva nu este verificat, accesul se oprește înainte de a se deschide ceva. Fără verificare manuală. Fără intervenție administrativă. Politica pur și simplu funcționează.

Apoi am privit și cealaltă față a aceleiași probleme.

Pe un dispozitiv pe care OneIdP îl cunoaște deja și în care are încredere, solicitarea utilizatorului să își introducă din nou parola nu adaugă nimic. Este vorba doar de o fricțiune care îi spune discret persoanei din spatele ecranului că departamentul IT nu are încredere în el. SSO-ul îmbunătățit pe dispozitivele gestionate elimină complet acest lucru. Starea de conformitate a dispozitivului devine acreditările. Experiența devine invizibilă - în cel mai bun mod posibil.

2. Vei începe de la zero cu identitatea

Fiecare prezentare de genul „treci pur și simplu pe platforma noastră” are același punct mort.

Presupune că echipele IT vor renunța la ani de configurare a directoarelor, integrări IdP și politici de acces și vor reconstrui de la zero în cadrul unui instrument nou. Pentru o echipă care gestionează 800 de dispozitive pe două continente, aceasta nu este o migrare ușoară.

Federația de Identități a fost construită pentru această realitate.

OneIdP se află ca strat de politică de acces peste orice fundație deja existentă. Entra, Google Workspace, Okta, PingOne sau configurații Active Directory locale care datează dinaintea actualei echipe IT - toate acestea rămân neschimbate. 

Am mers și mai departe cu SCIM Intrare și ieșire. Când cineva se alătură, accesul este furnizat automat. Când rolul său se schimbă, accesul se adaptează. Când pleacă, conturile sunt eliminate fără a fi generat un tichet sau a fi omis un pas manual. Reprezentarea forței de muncă în fiecare aplicație conectată rămâne precisă.

3. Cineva va fi mereu acolo să îl conducă

Decizia privind arhitectura este partea ușoară. Conviețuirea cu platforma este locul în care gestionarea identității devine de obicei complicată.

Parole de administrator local sunt un bun exemplu de problemă care stă discret în fundal până când nu mai este. Acreditări identice pe sute de mașini, neschimbate timp de luni de zile, deoarece rotirea lor manuală este un proiect pentru care nimeni nu are timp. LAPS a automatizat acest lucru. Rotația are loc la timp. Fiecare acreditare este auditată. Riscul dispare fără a fi nevoie ca cineva să acționeze în consecință.

Portalul utilizatorilor le-a oferit angajaților un singur loc unde să găsească fiecare aplicație aprobată. Organizat de IT, mereu actualizat, fără ambiguitate cu privire la ce este aprobat. Genul de lucru care nu generează laude, dar elimină definitiv o anumită categorie de tichet de asistență.

SSO bazat pe dispozitiv a rezolvat problema dispozitivelor partajate, care rămăsese fără răspuns de la lansare. Orice utilizator înscris pe o mașină gestionată primește acces la aplicație. Nu este necesară reînscrierea între ture. Accesul urmează persoana. Dispozitivul rămâne pregătit pentru oricine urmează.

Jurnalele de acces SSO au oferit fiecărui CISO pista de audit solicitată în prima analiză de securitate — automat, fără ca cineva să o creeze într-o foaie de calcul.

Trei presupuneri. Trei decizii deliberate de a construi diferit.

Însă deciziile pe hârtie și deciziile în producție sunt două lucruri foarte diferite.

Iată cum s-a desfășurat, de fapt.

Cronologia, sincer

Este util să vedem cum s-a desfășurat acest lucru - nu ca o foaie de parcurs a produsului, ci ca o serie de răspunsuri la ceea ce învățam:

Cum arată OneIdP astăzi

Când am lansat soluția, discuțiile s-au concentrat pe construirea fundației corecte. Integrarea încrederii și identității dispozitivelor în același nivel de politici. Asigurarea că accesul condiționat reflectă ceea ce se întâmpla pe terminal în timp real.

Astăzi, discuțiile se concentrează pe ceea ce poate susține această fundație. Integrări mai profunde, acoperire mai largă a flotei, politici de acces care se extind mai departe pe întreaga infrastructură - deoarece platforma a fost construită pentru a merge acolo.

Această progresie de la stadiul de bază la platforma completă este exact direcția în care am intenționat să o ducem.

OneIdP Astăzi, identitatea, încrederea dispozitivelor și politica de acces sunt evaluate împreună - la fiecare conectare, în timp real, fără nicio pauză între endpoint-ul pe care îl gestionați și accesul pe care îl controlați. Dispozitivul și persoana din spatele lui trăiesc în sfârșit în același univers de politici.

Ceea ce ne-am agățat de-a lungul timpului este ceva ce este testat constant în dezvoltarea produsului: „cea mai sofisticată platformă de acces este la fel de valoroasă ca și capacitatea echipei IT de a o rula efectiv. O echipă eficientă care gestionează o flotă distribuită nu ar trebui să aibă nevoie de un inginer IAM dedicat pentru a menține totul în funcțiune.”

Fiecare lansare din ultimii doi ani a fost limitată la acest aspect - suficient de puternică pentru un mediu complex, suficient de operabilă pentru oamenii care se află efectiv în el.

De acel echilibru suntem cel mai mândri.

Ce vine

Doi ani de lucru alături de echipe IT te învață ceva util: problema este întotdeauna mai mare decât cea pe care tocmai ai rezolvat-o.

Încrederea dispozitivelor a dus la întrebări despre accesul la rețea. Accesul la rețea a dus la întrebări despre infrastructură. Suportul Cloud RADIUS și accesul SSH bazat pe identitate sunt următoarele răspunsuri - deja în lucru, modelate de aceleași conversații care au produs tot ce a fost menționat mai sus. 

Domeniul de aplicare al accesului zero trust trebuie să guverneze continuă să se extindă și intenționăm să ne extindem odată cu acesta.

Ești gata să vezi unde se află OneIdP astăzi?

Înscrie-te pentru o perioadă de probă de 14 zile.

Explorează platforma