Identity & Access Management

Identity & Access Management is de controlelaag die bepaalt wie er op het platform bestaat en wat ieder van hen mag doen. De module beheert de volledige levenscyclus van een principal, vanaf het moment waarop een account wordt aangemaakt tot en met authenticatie, roltoewijzing, sessieactiviteit en uiteindelijke deactivering, en dwingt die beslissingen uniform af in elke module van de suite. Omdat Nashua 360 zowel mensen als AI Workers als volwaardige gebruikers behandelt, beheert deze module menselijke medewerkers en autonome agents via één consistente autoriteit.

Het bedrijfsprobleem dat deze module beheert, is vertrouwen: bewijzen dat een verzoek afkomstig is van wie het beweert te zijn, en bevestigen dat de actor gerechtigd is tot de bewerking voordat er gegevens worden gelezen of gewijzigd. De module vormt het fundament van het platform, onder de bedrijfsmodules in plaats van ernaast. Elke boekhoudkundige boeking, wagenparkbeweging, verkoopofferte en kennisbankbewerking passeert dezelfde identiteitscontrole en dezelfde rechtenafweging, zodat beveiliging een eigenschap is van het platform zelf en niet iets dat elke module opnieuw implementeert.

Wat de module doet

Identity & Access Management levert de volledige set functies die een onderneming van een centrale toegangsautoriteit verwacht. De module maakt gebruikersaccounts aan en beheert ze, met profielgegevens, contactinformatie en de accountstatus, en maakt een duidelijk onderscheid tussen het administratieve beheer van een willekeurig account en het zelf bewerken van het eigen profiel. Authenticatie is gebaseerd op inloggegevens met sterke wachtwoordhashing, aangevuld met tijdsgebonden tweefactorauthenticatie en een set eenmalige herstelcodes die versleuteld worden bewaard voor het geval een tweede factor verloren gaat.

Voorbij het moment van aanmelden onderhoudt de module actieve sessiecontrole, zodat lopende sessies zichtbaar zijn, toe te wijzen zijn aan een principal, begrensd zijn door een vervaltijd en afzonderlijk kunnen worden ingetrokken. Autorisatie wordt uitgedrukt via benoemde rollen die fijnmazige rechten dragen, en die rechten reiken tot in elk onderwerp dat het platform blootstelt. Single sign-on is beschikbaar via connectoren met identity providers, waardoor de organisatie authenticatie kan federeren naar haar bestaande directory terwijl autorisatiebeslissingen lokaal binnen de suite blijven. Rol- en rechtenbeheer maakt deel uit van deze module en geeft beheerders één plek om te definiëren wat elke klasse gebruikers mag doen.

Het domein en het datamodel

In het hart van het domein staat de principal: een geverifieerde actor op het platform, of dat nu een met naam genoemde medewerker of een AI Worker is, met een unieke identiteit, contactgegevens en een accountstatus die bepaalt of deze überhaupt mag handelen. Elke principal is gebonden aan precies één rol, en het is de rol, niet het individu, die de rechten draagt. Deze bewuste scheiding houdt toegangsbeslissingen consistent en controleerbaar: wijzig een rol en elke principal die deze rol heeft, verschuift mee, in plaats van af te dwalen naar een lappendeken van individuele uitzonderingen.

Een rol wordt gedefinieerd door zijn rechtenset, een gestructureerde uitdrukking van welke acties de rol mag uitvoeren op welke onderdelen van het platform. Acties zoals lezen, aanmaken, bijwerken, verwijderen en benaderen worden gekoppeld aan de bedrijfsonderwerpen waarop ze van toepassing zijn, en het platform herkent onderwerpen voor elk functioneel gebied dat het bestrijkt. Ingebouwde rollen variëren van een onbeperkte beheerder via functionele en technische managers tot een alleen-lezen standaardgebruiker, en deze fundamentele rollen zijn beveiligd tegen verwijdering zodat het systeem altijd een coherente basis behoudt. Het laatste concept is de sessie, het record van de geauthenticeerde aanwezigheid van een principal, met een eigen token, een eigenaar en een vervaltijd. Samen beschrijven deze vier begrippen, helder en volledig, wie iemand is, wat diegene mag doen en of diegene op dit moment is aangemeld.

Session Controllive sessions, expiry and revocationAuthorisationroles and fine-grained permissionsAuthenticationpassword, two-factor and single sign-onIdentitypeople and AI Workers as verified principals
The access control plane, resolved from identity upward to every session it authorises.

Workflows rond principals

De meest voorkomende workflow is het aanmaken van accounts. Een beheerder maakt een account aan, stelt het initiële profiel in en wijst een rol toe, en de nieuwe principal wordt onmiddellijk beheerd door de rechten van die rol, zonder verdere configuratie. Wachtwoordresets volgen hetzelfde administratieve pad, terwijl gewone gebruikers hun eigen profiel onderhouden en hun tweede factor via zelfbediening instellen. Bij het instellen van tweefactorauthenticatie wordt een authenticator-app aan het account gekoppeld en worden er herstelcodes uitgegeven, en de accounthouder kan die codes opnieuw genereren of de factor opnieuw configureren wanneer de omstandigheden veranderen.

Toegangsbeoordeling is een workflow op zichzelf. Beheerders bekijken wie welke rol heeft, passen de rechtenset van een rol aan via een editor die onderwerpen groepeert onder de bijbehorende module, en zien die wijzigingen van kracht worden op het hele platform zonder dat er iets opnieuw hoeft te worden uitgerold. Sessietoezicht stelt een beheerder in staat actieve sessies te bekijken en elke sessie die niet langer mag blijven bestaan in te trekken, wat de directe reactie is op een verloren apparaat of een vertrekkende medewerker. Deactivering sluit de cirkel: een account kan worden uitgeschakeld zodat het zijn historie en auditspoor behoudt terwijl het de mogelijkheid tot authenticatie verliest, waarbij het record behouden blijft zonder de toegang te behouden.

Functionele diepgang die ertoe doet

Het autorisatiemodel is attribuutgebaseerd in plaats van een grofmazige lijst van rechten. Rechten worden bewaard als expliciete regels die een actie koppelen aan een onderwerp, en het platform draagt een rijk register van onderwerpen dat elke module omvat, zodat rechten zo breed kunnen zijn als volledige controle over een functioneel gebied of zo eng als alleen-lezen zicht op één enkel onderwerp. Deze granulariteit is wat het mogelijk maakt dat een technisch manager en een functioneel manager naast elkaar bestaan, elk met autoriteit over hun eigen domein en alleen-lezen inzicht in dat van de ander. Wanneer een principal zich authenticeert, wordt de effectieve rechtenset bepaald en meegedragen in een ondertekend token, en dat token wordt in een korte cyclus vernieuwd zodat een wijziging in een rol zich binnen enkele minuten naar lopende sessies verspreidt in plaats van te blijven hangen tot de volgende aanmelding.

De module is gebouwd volgens gevestigde beveiligingsmaatregelen. Inloggegevens worden nooit onversleuteld opgeslagen, herstelmateriaal wordt versleuteld in rust bewaard, en sessiecookies worden uitgegeven met de beschermende vlaggen die toegang vanaf de client en cross-site-verzending voorkomen. Aanmelden is rate-limited om bruteforcepogingen af te zwakken, en elke toegangsbeslissing wordt afgedwongen op de interfacegrens zodat een rechtencontrole niet kan worden omzeild door een bewerking rechtstreeks aan te roepen. Omdat dezelfde afdwinging zowel interactief gebruik als programmatische toegang dekt, gelden de garanties ongeacht of een verzoek afkomstig is van een browser, een integratie of een autonome agent.

Hoe het past binnen de Nashua 360-suite

Identity & Access Management is de afhankelijkheid die elke andere module deelt. De module werkt hand in hand met Security Management, dat de beveiligingshouding van het platform auditeert en het toegangsmodel gebruikt bij het redeneren over blootstelling, en met Privacy Management en Compliance Management, die erop vertrouwen om aan te tonen dat toegang tot persoonlijke en gereguleerde gegevens beperkt blijft tot gerechtigde principals. Connector Management levert de integraties met identity providers die single sign-on mogelijk maken en authenticatie federeren naar de directory van de organisatie. De Notification Engine brengt de beveiligingsrelevante gebeurtenissen die deze module genereert, zoals een nieuwe sessie of een rolwijziging, naar de mensen die ze moeten zien.

Elke bedrijfsmodule, van Accounting & Control via Marketing & Sales, Fleet Management, Human Resource Management en de Knowledge Base, drukt zijn eigen toegangsregels uit als onderwerpen binnen het rechtenmodel van deze module, zodat er één autoriteit en één vocabulaire voor rechten bestaat over de hele suite. Module Management en het bredere System Administration-gebied behandelen identiteit als het substraat waarop alle administratieve activiteit wordt geautoriseerd.

Hoe AI Workers erin opereren

AI Workers zijn hier principals zoals alle andere, aangemaakt met hun eigen identiteit, gebonden aan een rol en beperkt tot precies de rechten die die rol verleent, wat betekent dat een agent nooit kan handelen buiten de autoriteit die hem is verleend. In een gesprek kan een beheerder een AI Worker vragen te rapporteren wie een bepaalde rol heeft, welke accounts tweefactorauthenticatie hebben ingeschakeld, of welke sessies op dit moment actief zijn, en de Worker antwoordt door de eigen gegevens van de module te bevragen. Met het juiste recht voert de Worker ook acties uit: een account aanmaken, een rol toewijzen of aanpassen, inloggegevens resetten of op verzoek een sessie intrekken.

De Workers kijken toe én handelen. Ze brengen afwijkingen en uitzonderingen aan het licht, signaleren accounts zonder tweede factor, sessies die zich ongewoon gedragen of rollen waarvan de rechten zijn afgedwaald van het beleid, en brengen deze via het notificatiepad onder de aandacht van mensen. Ze halen structuur uit ondersteunende documenten, waarbij ze een lijst van in- en uitdiensttreders of een toegangsaanvraagformulier omzetten in concrete voorstellen voor het aanmaken en intrekken van accounts, en ze bieden beslissingsondersteuning wanneer een rolwijziging wordt overwogen door uit te leggen wat een bepaalde rechtenset zou toestaan. Het belangrijkste is dat een AI Worker kan optreden als goedkeurings- of beoordelingsknooppunt in een toegangsworkflow, zodat een gevoelige roltoewijzing of een aanvraag voor een geprivilegieerd account pauzeert voor zijn toetsing, waarbij elke beoordeling wordt vastgelegd op naam van de eigen identiteit van de Worker in het auditspoor.