Natuurlijk! Hier is een voorstel voor het ontwerpen van een contextueel Identity & Access Management (IAM) systeem dat gebruikmaakt van de door u genoemde factoren: 1. Analyse en doelstellingen - Doel: Dynamisch reguleren van toegang op basis van locatie, tijdstip, apparaatstatus en netwerkveiligheid. - Beveiligingsdoel: Voorkomen van ongeautoriseerde toegang, terwijl legitiem gebruik soepel blijft verlopen. 2. Basisopbouw van het systeem - Integratie met bestaande Active Directory (AD) voor centrale gebruikersbeheer. - Implementatie van een Context-Aware Access Management module (bijvoorbeeld op basis van Identity-as-a-Service (IDaaS) of een custom oplossing). 3. Verzamelen van contextuele gegevens - Locatie: Gebruik van IP-adressen, GPS-gegevens (bij mobiele apparaten) of Wi-Fi-netwerkinformatie. - Tijdstip: Toegangsregels instellen voor kantooruren (bijvoorbeeld 08:00 - 18:00). - Apparaatstatus: Controle op apparaatveiligheid, bijvoorbeeld of het apparaat up-to-date is, ge-encrypt is en een beveiligingssoftware draait. - Netwerkveiligheid: Detectie of de verbinding via een veilig bedrijfsnetwerk of VPN loopt. 4. Toegangscontroleregels - Alleen toegang tot kritieke systemen toegestaan tijdens kantooruren (bijvoorbeeld 08:00 - 18:00). - Toegang wordt geweigerd indien de gebruiker zich buiten het kantoorgebied bevindt of buiten kantooruren. - Alleen apparaten die voldoen aan beveiligingscriteria krijgen toegang. - Bij twijfel over netwerkveiligheid (bijvoorbeeld onveilig Wi-Fi), wordt toegang beperkt of extra verificatie gevraagd. 5. Technische implementatie - Gebruik van een Identity Provider (IdP) die contextuele informatie kan verwerken (bijvoorbeeld Microsoft Azure AD Conditional Access, Okta, Ping Identity). - Configuratie van condities en regels gebaseerd op de verzamelde contextuele gegevens. - Multifactor authenticatie blijft als extra beveiligingslaag actief bij afwijkingen of risicovolle situaties. 6. Monitoring en logging - Logs van toegangspogingen en gebruikte contextuele data voor audit en analyse. - Regelmatige evaluatie van regels en beleid op basis van incidenten. 7. Gebruikerservaring en beheer - Communiceer duidelijk over toegangsregels. - Zorg voor een gebruiksvriendelijk proces voor verificatie en toegang. Door deze aanpak te combineren met uw bestaande AD en MFA, creëert u een flexibel en veilig IAM-systeem dat zich aanpast aan de context, waardoor ongeautoriseerde toegang effectief wordt voorkomen.

Zeker, ik help u graag een contextueel IAM-systeem te ontwerpen. Hier is een gedetailleerd ontwerp op basis van uw specificaties. ### **Architectuur Overzicht: Contextueel IAM Systeem** Dit ontwerp breidt uw bestaande Active Directory (AD) en MFA-infrastructuur uit met een **Policy Decision Point (PDP)** en **Policy Enforcement Points (PEPs)** die contextuele regels evalueren en afdwingen. **Kerncomponenten:** 1. **Policy Administration Point (PAP):** Het centrale beheerpunt. Dit wordt geïntegreerd in of naast uw AD. Hier definieert u de contextuele beleidsregels (bijv. "Toegang tot financiële systemen alleen vanaf het bedrijfsnetwerk tussen 09:00-17:00"). 2. **Policy Decision Point (PDP):** De "hersenen" van het systeem. Deze service beoordeelt toegangsverzoeken in real-time door gebruikersrechten (uit AD), authenticatiestatus (MFA) en contextuele data te combineren. 3. **Policy Enforcement Point (PEP):** De "poortwachters" die de beslissing van de PDP afdwingen. Voorbeelden zijn: * Netwerktoegangscontrollers (NAC) voor Wi-Fi/VPN. * Federation Gateway (zoals ADFS of Azure AD) voor cloud-applicaties. * Gebruikersportal of applicatieproxies. 4. **Context Handler:** Een component die real-time contextuele informatie verzamelt van verschillende bronnen en deze in een gestandaardiseerd formaat aan de PDP aanbiedt. --- ### **Implementatie van Uw Specifieke Vereiste: Toegang Beperken tot Kantoorgebieden tijdens Kantooruren** Dit vereist een combinatie van fysieke en logische toegangscontrole. **1. Contextuele Factoren en Data Bronnen:** * **Gebruikersidentiteit & Groepslidmaatschap:** Uit Active Directory. * **Tijdstip:** Uit de interne systeemklok van de PDP/server. * **Locatie (Fysiek - Kantoorgebied):** Verzameld via: * **Badge-lezer logs:** Integreer uw bestaande fysieke toegangssysteem (badges) met het IAM-systeem. * **Wi-Fi triangulatie/BLE-beacons:** Detecteert of het apparaat van een gebruiker zich daadwerkelijk in een specifiek kantoorgebied bevindt. **2. Beleidsregel Formulering (in de PAP):** ```plaintext REGEL: "Toegang_Kantoorapplicaties_Tijdens_Werkuren" ALS { Gebruiker.isLidVan("Alle_Medewerkers") EN Context.Tijdstip.isTussen("08:00", "18:00", "Maandag-Vrijdag") EN Context.Locatie.isGelijkAan("Kantoor_Amsterdam") // Verkregen via badge-inlog of apparaatlocatie } DAN { Beslissing: "PERMIT" // Toegang verlenen } ANDERS { Beslissing: "DENY" OF "STEP_UP_AUTH" // Toegang blokkeren of extra authenticatie eisen } ``` **3. Technische Integratie & Dataflow:** * **Stap 1: Aanvraag.** Een medewerker probeert in te loggen op een gevoelig intern systeem (bijv. de financiële applicatie). * **Stap 2: Context Verzameling.** De PEP (bijv. de applicatieproxy) stuurt een verzoek naar de PDP. De Context Handler verzamelt simultaan: * Gebruikersinformatie uit AD. * Heeft de gebruiker vandaag om 08:30 ingecheckt met zijn badge bij de voordeur? (via integratie met fysiek toegangssysteem). * Is het huidige tijdstip 14:30 op een dinsdag? * **Stap 4: Beslissing.** De PDP evalueert de regel. **Scenario A (in kantoor):** Alle voorwaarden zijn `True` → Toegang wordt verleend. **Scenario B (thuis):** Locatie-voorwaarde is `False` → Toegang wordt geweigerd of er wordt om extra MFA gevraagd. * **Stap 5: Afdwinging.** De PDP retourneert de beslissing (`Permit`/`Deny`) naar de PEP, die de gebruiker al dan niet toegang geeft tot de applicatie. --- ### **Uitbreiding met Andere Contextuele Factoren** Uw ontwerp kan eenvoudig worden uitgebreid: * **Apparaatstatus:** Integreer met een Mobile Device Management (MDM) oplossing zoals Microsoft Intune. Beleid: "Toegang alleen toegestaan vanaf apparaten die voldoen aan bedrijfsbeleid (geëncrypteerd, wachtwoord ingesteld, geen jailbreak)." * **Netwerkveiligheid:** Integreer met firewalls of netwerkmonitoringtools. Beleid: "Toegang tot het HR-systeem alleen vanaf het vertrouwde bedrijfsnetwerk, niet via publieke WiFi." ### **Aanbevolen Implementatiestappen voor 50 Medewerkers** 1. **Fase 1: Assessment & Beleid.** * Inventariseer alle applicaties en data. * Definieer formele beleidsregels op basis van "need-to-know" en uw beveiligingsdoelen. 2. **Fase 2: Pilootproject.** * Kies één kritische applicatie (bijv. uw financiële software). * Implementeer de PDP/PEP-architectuur voor deze ene app. Gebruik een cloudgebaseerde oplossing zoals **Azure Active Directory Conditional Access** (bouwt direct voort op uw AD) om de contextuele regels te configureren. Dit is zeer schaalbaar en kosteneffectief voor een organisatie van uw grootte. 3. **Fase 3: Uitrol en Integratie.** * Breid de regels geleidelijk uit naar andere applicaties. * Integreer de fysieke toegangssystemen (badgelezer) met uw identiteitsprovider. 4. **Fase 4: Monitoring & Optimalisatie.** * Controleer logs op valse positieven (gebruikers die ten onrechte worden geweigerd). * Pas beleid aan op basis van gebruikersfeedback en beveiligingsincidenten. ### **Concrete Tools & Platformen (Praktisch Advies)** Gezien uw startpunt (AD + MFA) en grootte, is de meest pragmatische aanpak: * **Microsoft Azure AD Premium + Conditional Access:** Dit is de logische keuze. Het fungeert als uw PDP en PEP voor cloud- en (via Azure AD Application Proxy) on-premises applicaties. U kunt daar direct regels maken op basis van locatie (gebaseerd op IP-adres), apparaatstatus (via Intune-integratie), tijd, en gebruikersrisico. Dit ontwerp biedt een robuust kader dat uw beveiligingspostuur aanzienlijk versterkt door toegang dynamisch en risicogestuurd te maken, precies zoals u voor ogen heeft.