Er is een vraag die elke IT-beheerder uiteindelijk niet meer hardop stelt, omdat ze hebben geaccepteerd dat er geen eenduidig antwoord op is.
“Waarom weet ik alles over dit apparaat, maar bijna niets over wie er op dit moment daadwerkelijk voor zit?”
Je hebt toegang tot de patchstatus, de nalevingsstatus, de app-inventaris en de locatie. Je kunt alles op afstand wissen, zelfs om 2 uur 's nachts, via je telefoon. Maar de persoon die om 9 uur 's ochtends inlogt? Dat is nog steeds grotendeels gebaseerd op een mondelinge overeenkomst en een wachtwoord dat waarschijnlijk al voor drie andere accounts is gebruikt.
Die kloof is de reden waarom OneIdP bestaat. En twee jaar later volgt hier het eerlijke verhaal over wat er nodig was om die kloof te dichten.
De wereld waarin IT-teams daadwerkelijk leefden
Het conventionele antwoord was alom bekend: koop een IAM-tool, koppel deze aan je UEM en configureer SSO ergens daartussenin.
Verschillende leveranciers, verschillende dashboards en verschillende plekken waar uw beleid zichzelf stilletjes kan tegenspreken zodra er een uitzonderlijk geval opduikt.
Het diepere probleem was dat Schaalfusie Erkende IT-omgevingen binnen bedrijven zijn niet gebouwd rond ideale scenario's, maar rond uitzonderingen. Denk bijvoorbeeld aan gedeelde apparaten, onboarding op afstand, externe medewerkers die met hun eigen laptop werken en teams die verspreid zijn over vijf tijdzones.
Dit waren geen uitzonderlijke gevallen waar rekening mee gehouden moest worden. Dit waren de feitelijke bedrijfsomstandigheden.
De meeste toegangsstrategieën waren echter nog steeds geschreven voor een wereld waarin iedereen elke dag op hetzelfde kantoor en met hetzelfde beheerde apparaat werkte. Authenticatie werd daardoor de standaard voor alles. Authenticatie werd behandeld als een opgelost probleem. Wachtwoord verifiëren, sessie verlenen. Klaar.
De meeste toegangsbeslissingen werden nog steeds genomen op basis van slechts een deel van het plaatje. Want als je weet wie iemand is, zeg je bijna niets over waarmee die persoon inlogt. Of het apparaat wel is bijgewerkt. Of het wel van de organisatie is. Of het de computer is die vorig kwartaal is geregistreerd of een persoonlijke laptop in een hotellobby.
Dat was de kloof die we wilden dichten.
Wat we op de eerste dag verstuurden – en waarom dat nog maar het begin was.
Toen OneIdP werd gelanceerd, maakten we een bewuste keuze die de meeste productteams niet maken. We leverden een basis in plaats van een lijst met functies.
Een clouddirectory. Voorwaardelijke toegang via een toegangskaart. MFA (Multi-Factor Authentication) geïntegreerd in hetzelfde dashboard dat IT-teams al dagelijks gebruikten. De basis was bewust solide voordat er veel functionaliteit aan werd toegevoegd.
keycard Hiermee kunnen IT-teams daadwerkelijke toegangsvoorwaarden instellen: goedgekeurde locaties, vertrouwde IP-bereiken, specifieke wifi-netwerken en tijdsvensters. Voor teams die werken met gedeelde wachtwoorden en inlogprocedures zonder context, was zelfs die eerste versie al een andere manier van werken.
Een solide ondergrond, voordat we begonnen met bouwen.
En toen gebeurde er iets waardoor we beseften dat de basis echt gelegd was. Binnen enkele maanden vroegen klanten niet meer of OneIdP werkte. Ze dachten al na over wat er daarna zou komen.
- Hoe kunnen we hun bestaande Okta- of Entra-configuratie integreren?
- Hoe neem je toegangsbeslissingen die niet alleen de identiteit, maar ook de naleving van apparaatrichtlijnen weerspiegelen?
- Hoe zorg je ervoor dat het werkt voor ploegendiensten waarin computers de hele werkdag door gedeeld worden?
Dat was de kaart, en die hebben we gevolgd.
Twee jaar lang hebben we aan die realiteit gewerkt.
De meeste identiteitstools zijn gebaseerd op aannames.
Dat een geldige inloggegevens een veilige sessie garanderen. Dat IT-teams hun directory opnieuw zullen opbouwen om deze aan te passen aan een nieuw platform. Dat er iemand met diepgaande IAM-expertise beschikbaar zal zijn om alles te onderhouden.
Deze aannames zijn al jarenlang ingebouwd in toegangsbeheer voor bedrijven, simpelweg omdat niemand ze ooit ter discussie heeft gesteld.
We hebben ze alle drie ondervraagd.
1. Identiteit is voldoende om toegang te verlenen
SSO, zoals de industrie het altijd heeft geleverd, stopt zodra de inloggegevens zijn geverifieerd. De gebruiker is wie hij/zij zegt te zijn. Sessie verleend.
Wat er nooit gevraagd werd, was wat er achter de inloggegevens schuilgaat. Of het apparaat gepatcht is. Of het verzoek afkomstig is van een logische locatie. Of de applicatie die wordt benaderd überhaupt wel op die specifieke machine geopend zou moeten zijn op dat specifieke moment.
We hebben gebouwd Uitgebreide toegangsbeleid (XAP) om precies dat te vragen.
Elke inlogpoging wordt beoordeeld aan de hand van het volledige plaatje. Live apparaatconformiteitssignalen van Veltar worden direct meegenomen in de toegangsbeslissing. Als er iets niet klopt, wordt de toegang geblokkeerd voordat er iets geopend kan worden. Geen handmatige controle. Geen tussenkomst van de beheerder. Het beleid werkt gewoon.
Vervolgens bekeken we de andere kant van hetzelfde probleem.
Op een apparaat dat OneIdP al kent en vertrouwt, voegt het opnieuw invoeren van het wachtwoord door de gebruiker niets toe. Het zorgt alleen maar voor wrijving en laat de persoon achter het scherm stilletjes weten dat IT het apparaat niet vertrouwt. Verbeterde SSO op beheerde apparaten elimineert dit volledig. De nalevingsstatus van het apparaat wordt de authenticatiegegevens. De ervaring wordt onzichtbaar – op de best mogelijke manier.
2. Je begint met een schone lei en een nieuwe identiteit.
Elke verkooppraatje met de boodschap "stap gewoon over op ons platform" heeft dezelfde blinde vlek.
Het gaat ervan uit dat IT-teams jarenlange configuratie van directory's, IdP-integraties en toegangsbeleid achter zich laten en alles volledig opnieuw opbouwen in een nieuwe tool. Voor een team dat 800 apparaten beheert op twee continenten, is dat geen eenvoudige migratie.
Identity Federation is voor die realiteit ontworpen.
OneIdP fungeert als de toegangsbeleidslaag bovenop de bestaande infrastructuur. Entra, Google Workspace, Okta, PingOne of on-premise Active Directory-configuraties die dateren van vóór het huidige IT-team – alles blijft gewoon bestaan.
We gingen nog een stap verder met SCIM Inkomend en uitgaand verkeer. Wanneer iemand zich aanmeldt, wordt de toegang automatisch verleend. Wanneer hun rol verandert, wordt de toegang aangepast. Wanneer ze vertrekken, worden accounts verwijderd zonder dat er een ticket wordt aangemaakt of een handmatige stap wordt overgeslagen. De personeelsgegevens in alle gekoppelde applicaties blijven accuraat.
3. Er zal altijd wel iemand zijn om het te besturen.
De architectuurkeuze is het makkelijke deel. Het gebruik van het platform is waar identiteitsbeheer meestal ingewikkeld wordt.
Lokale beheerderswachtwoorden zijn een goed voorbeeld van een probleem dat onopgemerkt op de achtergrond blijft sluimeren totdat het dat niet meer is. Identieke inloggegevens op honderden machines, maandenlang ongewijzigd, omdat het handmatig roteren ervan een project is waar niemand tijd voor heeft. LAPS automatiseerde dat. De rotatie vindt volgens schema plaats. Elke inloggegeven wordt gecontroleerd. Het risico verdwijnt zonder dat iemand er iets aan hoeft te doen.
Het gebruikersportaal bood medewerkers één centrale plek waar alle goedgekeurde applicaties te vinden waren. Beheerd door IT, altijd actueel en zonder enige onduidelijkheid over wat wel en niet was goedgekeurd. Zo'n portaal dat misschien niet direct lof oogst, maar wel een specifieke categorie helpdeskvragen definitief overbodig maakt.
Apparaatgebaseerde SSO loste het probleem van gedeelde apparaten op, een probleem dat sinds de lancering onopgelost was gebleven. Elke geregistreerde gebruiker op een beheerd apparaat krijgt toegang tot de app. Geen herregistratie tussen diensten nodig. De toegang volgt de gebruiker. Het apparaat blijft klaar voor de volgende gebruiker.
SSO Access Logs gaf elke CISO het auditspoor waar ze om hadden gevraagd tijdens hun eerste beveiligingsaudit — automatisch, zonder dat iemand het in een spreadsheet hoefde bij te werken.
Drie uitgangspunten. Drie weloverwogen beslissingen om het anders aan te pakken.
Maar beslissingen op papier en beslissingen in de productie zijn twee heel verschillende dingen.
Zo is het daadwerkelijk gegaan.
De tijdlijn, eerlijk gezegd.
Het helpt om te zien hoe dit zich heeft ontwikkeld – niet als een productroadmap, maar als een reeks reacties op wat we leerden:
OneIdP-lancering
Telefoongids, Single Sign-on, Toegangskaart.
Integraties met identiteitsproviders
GWS, Entra, Okta, PingOne, on-premise Active Directory, enz.
Gebruikersportaal & identiteitsfederatie
Een gecureerd, door IT beheerd portaal voor elke goedgekeurde aanvraag.
SCIM v2.0 — Provisioning op grote schaal
Gebruikers worden gesynchroniseerd. Vertrokken medewerkers worden automatisch gedeactiveerd.
Uitgebreide toegangsbeleid (XAP)
Verleen SSO-toegang op basis van apparaatcompatibiliteit, locatie, IP-adres en aanwezigheid van de app.
Apparaatgebaseerde SSO + LAPS
Hiermee kunnen conforme beheerde apparaten toegang krijgen tot apps, ongeacht de ingelogde gebruiker.
Op gebruikersgroepen gebaseerde SSO-toewijzingen
Voeg uitzonderingen toe aan voorwaardelijke toegang in SSO-configuraties of wijs gebruikers in bulk toe aan SSO-configuraties met behulp van gebruikersgroepen.
Wachtwoorden
Aanmelden zonder wachtwoord met biometrie, beveiligingssleutels en vertrouwde apparaten. Centraal beheerd door IT, zelfservice voor gebruikers.
Hoe OneIdP er vandaag de dag daadwerkelijk uitziet
Bij de lancering gingen de gesprekken over het leggen van de juiste basis. Het integreren van apparaatvertrouwen en identiteit in dezelfde beleidslaag. Ervoor zorgen dat voorwaardelijke toegang daadwerkelijk weergeeft wat er in realtime op het eindpunt gebeurt.
Vandaag de dag gaat het gesprek over wat die basis allemaal kan dragen. Diepere integraties, een bredere dekking van het wagenpark, toegangsbeleid dat zich verder uitstrekt over de infrastructuur – want het platform is daarvoor gebouwd.
Die ontwikkeling van basis naar volledig platform is precies waar we het naartoe wilden brengen.
OneIdP Vandaag de dag worden identiteit, apparaatvertrouwen en toegangsbeleid gezamenlijk geëvalueerd — bij elke aanmelding, in realtime, zonder kloof tussen het eindpunt dat u beheert en de toegang die u controleert. Het apparaat en de gebruiker erachter bevinden zich eindelijk in hetzelfde beleidsuniversum.
Wat we steeds hebben vastgehouden, is iets dat constant op de proef wordt gesteld tijdens productontwikkeling: "Het meest geavanceerde toegangsbeheerplatform is slechts zo waardevol als het IT-team in staat is om het daadwerkelijk te beheren. Een klein team dat een gedistribueerd netwerk beheert, zou geen speciale IAM-engineer nodig moeten hebben om alles draaiende te houden."
Elke release van de afgelopen twee jaar is aan datzelfde principe getoetst: krachtig genoeg voor een complexe omgeving, maar ook gebruiksvriendelijk genoeg voor de mensen die er daadwerkelijk mee werken.
Dat evenwicht is waar we het meest trots op zijn.
Wat komt eraan?
Twee jaar lang meebouwen met IT-teams leer je iets nuttigs: het probleem is altijd groter dan het probleem dat je net hebt opgelost.
Het vertrouwen in apparaten leidde tot vragen over netwerktoegang. Netwerktoegang leidde tot vragen over infrastructuur. Cloud RADIUS-ondersteuning en identiteitsgebaseerde SSH-toegang zijn de volgende antwoorden — die al in ontwikkeling zijn en voortkomen uit dezelfde gesprekken die aan al het bovenstaande ten grondslag lagen.
De reikwijdte van wat zero trust-toegang moet reguleren, blijft zich uitbreiden, en wij zijn van plan mee te groeien.
