Två år med OneIdP: Att bygga noll förtroende bortom identitet

Det finns en fråga som alla IT-administratörer så småningom slutar ställa högt eftersom de har accepterat att det inte finns något tydligt svar.

"Varför vet jag allt om den här apparaten – och nästan ingenting om vem som faktiskt sitter framför den just nu?"

Du har patchstatus, efterlevnadsstatus, appinventering och plats. Du kan radera det på distans klockan 02:00 från din telefon. Men personen som loggar in klockan 09:00? Det är fortfarande till stor del ett handskakningsavtal och ett lösenord som någon förmodligen återanvände från tre andra konton.

Det är den klyftan som är anledningen till att OneIdP finns. Och två år senare, här är den ärliga berättelsen om vad som krävdes för att täppa till den.

Den värld IT-team faktiskt levde i

Det konventionella svaret var redan väletablerat: köp ett IAM-verktyg, montera det i din UEM, konfigurera SSO någonstans däremellan. 

Olika leverantörer, olika dashboards och olika platser för din policy att tyst motsäga sig själv i det ögonblick ett edge-fall kliver in genom dörren.

Det djupare problemet var att Skalfusion Erkända IT-miljöer för företag är inte byggda kring rena scenarier – de är byggda kring undantag. Delade enheter, fjärrintroduktion, entreprenörer på personliga bärbara datorer och distribuerade team över fem tidszoner, för att nämna några.

Det här var inte marginalfall att hantera. Det var de faktiska driftsförhållandena.

Ändå var de flesta åtkomststrategier fortfarande skrivna för en värld där alla dök upp på samma kontor, på samma hanterade enhet, varje dag. Så autentisering blev proxy för allting. Autentisering behandlades som ett löst problem. Verifiera lösenordet, bevilja sessionen. Klart.

De flesta åtkomstbeslut fattades fortfarande med bara en del av bilden. För att veta vem någon är säger nästan ingenting om vad de loggar in från. Om enheten har blivit uppdaterad. Om den tillhör organisationen. Om det är den registrerade maskinen från förra kvartalet eller en personlig bärbar dator i en hotellobby.

Det var den klyftan vi bestämde oss för att täppa till.

Vad vi levererade på dag ett – och varför det bara var början

När OneIdP lanserades gjorde vi ett medvetet val som de flesta produktteam inte gör. Vi levererade en grund istället för en funktionslista.

En molnkatalog. Villkorlig åtkomst via Keycard. MFA som fanns inuti samma instrumentpanel som IT-team redan använde varje dag. Grunden var medvetet solid innan den var funktionsrik. 

passerkort låter IT-team ställa in verkliga åtkomstvillkor – godkända platser, betrodda IP-intervall, specifika Wi-Fi-nätverk och tidsbaserade fönster. För team som arbetar med delade lösenord och kontextlösa inloggningar var även den första versionen ett annorlunda arbetssätt.

Fast mark, innan vi började bygga upp.

Och sedan hände något som berättade för oss att stiftelsen faktiskt hade etablerats. Och inom några månader frågade kunderna inte längre om OneIdP fungerade. De funderade redan på vad som skulle komma härnäst. 

• Hur man får in sin befintliga Okta- eller Entra-installation i bilden. 
• Hur man fattar åtkomstbeslut som återspeglar enhetens efterlevnad, inte bara identitet. 
• Hur man får det att fungera för skiftbaserade team som delar maskiner under en hel arbetsdag.

Det var kartan, och vi följde den.

Två år av byggande för den verkligheten

De flesta identitetsverktyg är byggda kring antaganden.

Att en giltig autentiseringsuppgift innebär en säker session. Att IT-team kommer att bygga om sin katalog för att passa en ny plattform. Att någon med djupgående IAM-expertis kommer att finnas tillgänglig för att underhålla allt.

Dessa antaganden har inbakats i företagsåtkomsthantering i åratal, eftersom ingen har stannat upp för att ifrågasätta dem.

Vi ifrågasatte alla tre.

1. Identitet räcker för att bevilja åtkomst

SSO, som branschen alltid har gjort, upphör i det ögonblick inloggningsuppgifterna checkas ut. Användaren är den de utger sig för att vara. Session beviljad.

Vad den aldrig frågade var vad som fanns bakom autentiseringsuppgifterna. Om enheten är uppdaterad. Om begäran kommer från en plats som är logisk. Om applikationen som används ens borde vara öppen på just den maskinen just då.

Vi byggde Utökade åtkomstpolicyer (XAP) att fråga just det.

Varje inloggning utvärderas mot en helhetsbild. Livesignaler om enhetsefterlevnad från Veltar matas direkt in i åtkomstbeslutet. Om något inte checkas ut stoppas åtkomsten innan något öppnas. Ingen manuell granskning. Inget administrativt ingripande. Policyn fungerar bara.

Sedan tittade vi på den andra sidan av samma problem.

På en enhet som OneIdP redan känner till och litar på, tillför det ingenting att be användaren skriva sitt lösenord igen. Bara friktion som tyst berättar för personen bakom skärmen att IT-avdelningen inte litar på dem. Förbättrad SSO på hanterade enheter tar bort det helt och hållet. Enhetens efterlevnadsstatus blir autentiseringsuppgifterna. Upplevelsen blir osynlig – på bästa möjliga sätt.

2. Du börjar om på nytt med din identitet

Varje "bara byt till vår plattform"-pitch har samma blinda fläck.

Det förutsätter att IT-teamen lämnar åratal av katalogkonfiguration, IdP-integrationer och åtkomstpolicyer, och bygger om från grunden i ett nytt verktyg. För ett team som hanterar 800 enheter över två kontinenter är det inte en enkel migrering.

Identitetsfederationen byggdes för den verkligheten.

OneIdP fungerar som åtkomstpolicylagret ovanpå den grund som redan finns. Entra, Google Workspace, Okta, PingOne eller lokala Active Directory-konfigurationer som föregår det nuvarande IT-teamet – allt detta förblir på plats. 

Vi tog det ännu längre med SCIM Inkommande och utgående. När någon ansluter tillhandahålls åtkomst automatiskt. När deras roll ändras anpassas åtkomsten. När de lämnar tas konton bort utan att ett ärende skapas eller ett manuellt steg missas. Personalrepresentationen i varje ansluten applikation förblir korrekt.

3. Någon kommer alltid att finnas där för att sköta det

Arkitekturbeslutet är den enkla delen. Att leva med plattformen är där identitetshantering oftast blir komplicerad.

Lokala administratörslösenord är ett bra exempel på ett problem som ligger tyst i bakgrunden tills det inte längre gör det. Identiska inloggningsuppgifter på hundratals maskiner, oförändrade i månader, eftersom manuell rotation är ett projekt som ingen har tid med. LAPS gjorde det automatiskt. Rotation sker enligt schema. Varje inloggningsuppgifter granskas. Risken försvinner utan att någon behöver agera på den.

Användarportalen gav medarbetarna en plats att hitta alla godkända ansökningar. IT-kuraterad, alltid aktuell, ingen tvetydighet om vad som är godkänt. Den typen av sak som inte genererar beröm men permanent eliminerar en specifik kategori av helpdesk-ärenden.

Enhetsbaserad SSO löste problemet med delade enheter som hade legat obesvarat sedan lanseringen. Alla registrerade användare på en hanterad maskin får åtkomst till sin app. Ingen omregistrering mellan arbetspassen. Åtkomsten följer personen. Enheten är redo för den som kommer nästa gång.

SSO-åtkomstloggar gav varje CISO den revisionslogg de begärde i sin första säkerhetsgranskning – automatiskt, utan att någon byggde den i ett kalkylblad.

Tre antaganden. Tre medvetna beslut att bygga annorlunda.

Men beslut på papper och beslut i produktion är två helt olika saker.

Så här utvecklade det sig faktiskt.

Tidslinjen, ärligt talat

Det hjälper att se hur detta utvecklades – inte som en produktplan, utan som en serie svar på vad vi lärde oss:

Hur OneIdP faktiskt ser ut idag

När vi lanserade handlade samtalen om att bygga rätt grund. Att få enhetsförtroende och identitet in i samma policylager. Att få villkorlig åtkomst att faktiskt återspegla vad som hände på slutpunkten i realtid.

Idag handlar samtalen om vad den grunden kan bära. Djupare integrationer, bredare flotttäckning, åtkomstpolicyer som sträcker sig längre över infrastrukturen – eftersom plattformen byggdes för att fungera där.

Den utvecklingen från grund till full plattform är precis dit vi ville ta den.

OneIdP Det är idag som identitet, enhetsförtroende och åtkomstpolicy utvärderas tillsammans – vid varje inloggning, i realtid, utan avbrott mellan den slutpunkt du hanterar och den åtkomst du kontrollerar. Enheten och personen bakom den lever äntligen i samma policyuniversum.

Det vi har hållit fast vid hela tiden är något som ständigt testas i produktutvecklingen: ”den mest sofistikerade åtkomstplattformen är bara så värdefull som IT-teamets förmåga att faktiskt köra den. Ett smidigt team som hanterar en distribuerad flotta borde inte behöva en dedikerad IAM-ingenjör för att hålla saker och ting igång.”

Varje utgåva under de senaste två åren har hållits efter det – tillräckligt kraftfull för en komplex miljö, tillräckligt användbar för de människor som faktiskt finns i den.

Den balansen är det vi är mest stolta över.

Vad kommer

Två år av att bygga tillsammans med IT-team lär dig något användbart: problemet är alltid större än det du just löst.

Enhetsförtroende ledde till frågor om nätverksåtkomst. Nätverksåtkomst ledde till frågor om infrastruktur. Stöd för molnbaserad RADIUS och identitetsbaserad SSH-åtkomst är nästa svar – redan på gång, formade av samma samtal som producerade allt ovanstående. 

Omfattningen av vad nollförtroende behöver styra fortsätter att utökas, och vi avser att utöka med det.

Redo att se var OneIdP står idag?

Registrera dig för en 14-dagars provperiod.

Utforska plattformen