Technisch architectuuroverzicht voor IT-teams die AccessPoint evalueren

Last updated: July 12, 2026 by Steve

Technische architectuur

Dit document biedt een technisch overzicht van het AccessPoint-platform voor solution architects, cyberbeveiligingsingenieurs en IT-directeuren die het product voor hun organisatie evalueren. Het is gebaseerd op de AccessPoint Solution Architecture Guide (v1.4.1).

Platformoverzicht

AccessPoint is een platform voor toegang tot informatie en privacybeheer, gebouwd op Microsoft 365 en Azure. Het begon als een hulpmiddel voor het beheer van subject access requests (SAR) en is uitgegroeid tot een geïntegreerde ATIP/privacy-officesuite die de volledige levenscyclus van verzoeken en het bredere privacyprogramma omvat. Het draait volledig binnen de eigen Microsoft 365- en Azure-tenant van uw organisatie: er zijn tijdens runtime geen externe servers, databases of clouddiensten van derden, en alle gegevens blijven in uw omgeving onder uw controle.

Het platform is georganiseerd in modules die één identiteits-, RBAC-, meldings-, audit- en rapportageruggengraat delen:

  • Toegangsverzoeken — ATI/FOIA/GDPR-intake, taaktoewijzing aan Custodians, documentbeoordeling en -redactie, antwoordverpakking en wettelijke rapportage
  • Privacy-assessments — een configureerbare PIA/AIA/Security-assessmentengine
  • Privacyincidenten en datalekken — intake, inperking, risico-op-schade-beoordeling en workflows voor melding van datalekken
  • Klachten en beroepen — levenscyclus van klachten met partijen, wettelijke termijnen en onderzoek
  • Privacyrisicoregister — risico's in ISO 31000-stijl, behandelplannen en kernrisico-indicatoren
  • Verwerkingsregisters (ROPA) — GDPR Article 30-records en registerexport
  • Verplichtingenregister — opgevolgde privacyverplichtingen met cadans en check-ins

Alle modules worden aangestuurd door configuratiepakketten, zonder statische seed-data.

Belangrijkste kenmerken:

  • Tenant-native — wordt geïmplementeerd als een SharePoint Framework (SPFx)-oplossing en Azure PaaS-services binnen uw bestaande tenant
  • Geen Power Platform-afhankelijkheden — geen Dataverse-, Power Automate- of Power Apps-licenties vereist
  • Gegevenssoevereiniteit — alle gegevens bevinden zich in de geconfigureerde geografie van uw Azure-tenant
  • Geen runtime-toegang voor de uitgever — de uitgever heeft tijdens normale werking geen toegang tot uw gegevens
  • Licenties tegen een vast tarief — afdelingslicenties zonder meting per gebruiker
  • Privacy by design — Custodian- en Contributor-rollen zijn structureel afgeschermd van PII van verzoekers en betrokkenen
  • Configuratie boven code — verzoektypes, uitzonderingscodes en keuzevelden zijn gegevensgestuurd
  • Meertalig ontwerp — een drielaags vertaalsysteem dat 11 talen ondersteunt

Architectuurdiagram

Customer's Microsoft 365 Tenant          Customer's Azure Subscription
┌──────────────────────────────┐         ┌─────────────────────────────────────────┐
│                              │         │                                         │
│  SPFx Web Part               │         │  Azure App Service (Linux)              │
│  (SharePoint Online /        │──HTTPS──│  ASP.NET Core 10 Web API               │
│   Teams Personal App /       │  (JWT)  │    ├─ Entra ID JWT validation          │
│   Teams Tab)                 │         │    ├─ Role-based authorization          │
│                              │         │    ├─ PII filter middleware             │
│  Installed from AppSource    │         │    ├─ User upsert from JWT claims      │
│  or Tenant App Catalog       │         │    ├─ License validation middleware    │
│                              │         │    └─ Syncfusion document conversion   │
│                              │         │                                         │
│  SharePoint Tenant Storage   │         │  Azure SQL Database                     │
│  (API URL + Client ID)       │         │  (~186 tables, ~2,900 fields)          │
│                              │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.Read.All       │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         └─────────────────────────────────────────┘
        │  Calendars.Read      │
        │  AiEnterprise…Read   │  ← M365 record capture (delegated + app-only Copilot)
        └──────────────────────┘

Componentinventaris

Component Technologie Geïmplementeerd op Doel
SPFx-webonderdeel TypeScript, React 17, Fluent UI 8, SPFx 1.22.1 SharePoint Online / Teams van klant Gebruikersinterface voor alle rollen
Teams-app Teams manifest v1.19, app-versie 1.0.0 Teams-beheercentrum van klant Persoonlijke app, configureerbaar tabblad, activiteitenfeedmeldingen met deep linking
Web API C# / ASP.NET Core 10, .NET 10 (~87 controllers, ~88 services) Azure App Service (Linux) van klant Bedrijfslogica, gegevenstoegang, documentverwerking
Database SQL Server (DacPac) Azure SQL Database van klant Relationele gegevensopslag (~186 tabellen, ~2.900 velden)
Blob Storage Azure Blob Storage Azure Storage Account van klant Opslag van documentbestanden
Monitoring Application Insights + Log Analytics Azure-abonnement van klant Telemetrie, diagnostiek, waarschuwingen
AI Search (opt-in) Azure AI Search Azure-abonnement van klant Volledige-tekst zoeken in documentinhoud; alleen ingericht wanneer deployAiSearch=true

Wat de uitgever beheert

Service Doel
Realizer Platform Uitgifte en validatie van licentiesleutels (geen klantgegevens verzonden)
AppSource Listing Distributie van SPFx-pakket
Azure Marketplace Listing Implementatietemplate voor Azure-infrastructuur
Teams App Package Distributie van Teams-manifest (sideload of organisatie-app-store)

Er worden geen klantgegevens verzonden naar of opgeslagen door enige door de uitgever beheerde service.

Functionele modules

Alle modules draaien binnen dezelfde Web API / hetzelfde SPFx-webonderdeel en delen één identiteits-, RBAC-, opmerkingen-, meldings-, Mijn dag-, audit-, uren- en beoordelingsworkflow- en rapportageruggengraat. Elke module is gegevensgestuurd via configuratiepakketten.

Module Samenvatting
Verzoeken (ATIP/SAR) Verzoekintake → taaktoewijzing aan Custodians → verzameling → antwoord. Configureerbare types, statussen, nummering, kalenders en SLA's.
Documenten en redactie Facet-gestuurde documentwerkruimte: tags, e-mailfamilies, leestracking, opgeslagen weergaven, Syncfusion-voorbeeldweergave, redactiepijplijn met uitzonderingen en XFDF-round-trip, antwoordverpakking.
Verzoekers / Contacten Volwaardige herbruikbare verzoekersidentiteit, sturing van de intakeflow, kosten en verificatie, samenvoegen; raadplegingen; correspondentie-opsteller met PII-firewall.
Privacy-assessments Configureerbare PIA/AIA/Security-engine: sjablonen, screenings, delegatie van onderdelen, scoring/niveau-indeling, risicoregister, afsluitings- en toezichthoudersamenvattingen.
Privacyincidenten / datalekken Incidentintake, inperking, risico-op-schade-beoordeling, meldingsregels voor datalekken per rechtsgebied, remediatie.
Klachten en beroepen Levenscyclus van klachten: partijen, wettelijke termijnen, ontvankelijkheid, onderzoek, beoordeling van zienswijzen.
Risico's en verplichtingen ISO 31000-risicoregister met risicobereidheid, KRI's en behandeltaken; verplichtingenregister met cadans en check-ins.
ROPA / privacyonderwerpen Herbruikbare programma's/systemen met GDPR Article 30-records en registerexport.
Beoordelingen Configureerbare sequentiële/parallelle beoordelings- en goedkeuringsengine, hergebruikt over alle dossierentiteiten.
Rapportage en audit Vaste rapporten, aangepaste rapportbouwer, statistische jaarverslagen, SLA-/managementdashboards, hash-geketend auditlogboek en gerechtsklare bewijspakketten.
Configuratie en platform Import van configuratiepakketten, tenantinstellingen, aangepaste rollen/machtigingen, functieschakelaars, aangepaste velden, vertaaltabellen voor 11 talen.

Implementatiemodel

AccessPoint gebruikt een gesplitst implementatiemodel. Het SPFx-webonderdeel wordt geïnstalleerd vanuit Microsoft AppSource (of een tenant App Catalog), het Teams-app-pakket wordt geïnstalleerd via sideloading of de app-store van de organisatie, en de Azure-backend wordt op een van twee manieren geïmplementeerd in het eigen abonnement van de klant:

  • Azure Portal (aanbevolen) — implementatie met één klik van alle Azure-resources (App Service, SQL, Blob Storage, Application Insights) via ARM/Bicep. De API wordt geïmplementeerd via zipdeploy tijdens de ARM-implementatie; code wordt eenmalig gedownload vanaf de CDN van de uitgever en opgeslagen in de App Service van de klant, zonder externe runtime-afhankelijkheid. De klant behoudt volledig eigenaarschap van de resourcegroep.
  • Bicep-template + PowerShell-script (handmatig) — voor organisaties met strikt wijzigingsbeheer. Een knop Deploy to Azure of Deploy-AccessPoint.ps1 implementeert de infrastructuur, configureert Entra-only authenticatie voor SQL, verleent Microsoft Graph-machtigingen aan de beheerde identiteit, configureert SharePoint tenant storage entities en keurt SPFx API-machtigingsverzoeken goed. Elke stap kan afzonderlijk worden overgeslagen.

De implementatie is standaard beveiligingsgehard: TLS 1.3, FTPS uitgeschakeld, SCM/FTP-basisauthenticatie uitgeschakeld en HTTP/2 ingeschakeld. De API bundelt haar database-DacPac en past deze bij het opstarten toe via een migratieservice met DacServices.Deploy(upgradeExisting: true) — een no-op bij een reeds actueel schema, en een additieve, niet-destructieve delta na een schemawijziging (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). Het resultaat van de migratie wordt weergegeven via /api/health. Na de implementatie verleent een beheerder toestemming voor de Realizer enterprise-app (Teams-meldingen), configureert het verzendende postvak en importeert een rechtsgebiedspecifiek configuratiepakket.

Authenticatie en identiteit

AccessPoint gebruikt Microsoft Entra ID als enige identiteitsprovider. Er zijn geen applicatiespecifieke gebruikersaccounts of wachtwoorden. Het SPFx-webonderdeel verkrijgt een JWT voor de API-doelgroep via AadHttpClient; de API valideert de uitgever, doelgroep, handtekening en vervaldatum bij elk verzoek. MFA- en Conditional Access-beleid dat is geconfigureerd in de tenant is volledig van toepassing.

User (Browser)                SharePoint Online           AccessPoint API
     │                              │                          │
     │  1. Load SPFx web part       │                          │
     │─────────────────────────────►│                          │
     │                              │                          │
     │  2. AadHttpClient.getClient()│                          │
     │  (SPFx acquires token for    │                          │
     │   api://<client-id> audience)│                          │
     │                              │                          │
     │  3. API call + Bearer token  │                          │
     │──────────────────────────────┼─────────────────────────►│
     │                              │                          │
     │                              │  4. Validate JWT:        │
     │                              │     - Issuer (Entra ID)  │
     │                              │     - Audience (api://)  │
     │                              │     - Signature          │
     │                              │     - Expiry             │
     │                              │                          │
     │                              │  5. UserUpsertMiddleware: │
     │                              │     Extract claims →     │
     │                              │     Upsert Users table   │
     │                              │                          │
     │                              │  6. RoleAuthorization:   │
     │                              │     Check UserRoles table│
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│
Parameter Waarde
Identiteitsprovider Microsoft Entra ID (Azure AD)
Protocol OAuth 2.0 / OpenID Connect
Tokentype JWT Bearer
Doelgroep api://<client-id> en <client-id> (zowel v1- als v2-tokens geaccepteerd)
Uitgever https://login.microsoftonline.com/{tenantId}/v2.0 en https://sts.windows.net/{tenantId}/
App-registratie Single-tenant (AzureADMyOrg); blootgestelde scope access_as_user; geen clientgeheim

Beheerde identiteit

De App Service gebruikt een systeemtoegewezen beheerde identiteit om te authenticeren bij backend-services, zodat er geen clientgeheimen of certificaten worden opgeslagen in de applicatie:

  • Azure SQL Database — Entra-only authenticatie (SQL-wachtwoordauthenticatie is uitgeschakeld)
  • Azure Blob Storage — DefaultAzureCredential (beheerde identiteit in productie)
  • Microsoft Graph API — ManagedIdentityCredential met applicatiemachtigingen

Referenties van de beheerde identiteit worden automatisch geroteerd door Azure.

Autorisatie en RBAC

AccessPoint implementeert rolgebaseerd toegangsbeheer op applicatieniveau, opgeslagen in Azure SQL en afgedwongen op de API-laag bij elk verzoek.

Rol Ziet PII van verzoeker Beheert verzoeken Beheert toewijzingen Dient documenten in Typische gebruiker
Administrator Ja Alleen configuratie Nee Nee IT-beheerder, systeemeigenaar
SAO Ja Ja Ja Nee Toegangs- en privacyfunctionaris
Reviewer Ja Alleen lezen Alleen lezen Nee Juridisch adviseur, QA
Custodian Nee Nee Eigen toewijzingen Nee Archiefbeheerder van de afdeling
Contributor Nee Nee Nee Eigen taken Vakinhoudelijk expert
Reader Nee Alleen lezen Alleen lezen Nee Toezicht, audit

Afdwingingspunten:

  1. API-autorisatiebeleid — ASP.NET Core [Authorize(Policy = "...")]-attributen op elke controlleractie
  2. RoleAuthorizationHandler — controleert de UserRoles-tabel op rollidmaatschap van de geauthenticeerde gebruiker
  3. ResourceOwnerAuthorizationHandler — valideert eigenaarschap op resourceniveau (bijv. een Contributor kan alleen zijn eigen taken benaderen)
  4. PiiFilterMiddleware — verwijdert PII-velden van de verzoeker uit JSON-antwoorden voor beperkte rollen (Custodian, Contributor, Reader)

Alle API-schrijfeindpunten dwingen rollen serverside af op controllerniveau. Herclassificatie van documenten is bereikbewust — de gebruiker die een document heeft verzameld, is degene die het kan herclassificeren — en zodra een verzoek is gesloten, geven mutaties op de objectgraaf ervan HTTP 409 terug, met een kleine set bewuste uitzonderingen (correspondentie na afsluiting, retentieverwijdering en heropening). Rollen zijn bereikgericht en kunnen worden beperkt tot specifieke resources (globaal, verzoek-, toewijzings- of taakbereik). De eerste gebruiker die toegang krijgt tot het systeem, krijgt via bootstrap zowel de Administrator- als de SAO-rol toegewezen.

Gegevensresidentie en soevereiniteit

Alle gegevens bevinden zich in de Azure-tenant van de klant, in de regio die tijdens de implementatie is geselecteerd. Er worden geen gegevens verzonden naar of opgeslagen in andere regio's, tenzij de klant expliciet Azure geo-replicatie configureert.

Canadese federale afdelingen: Voor GC-specifieke gegevensresidentievereisten, ITSG-33-controlemapping en GC Cloud Guardrails-compliance, zie de GC-beveiligingscontrolesreferentie.

Gegevenslocaties van klant

Gegevenstype Opslaglocatie Beheerd door
Verzoekrecords, gebruikersgegevens, audittrail Azure SQL Database Azure-abonnement van klant
Geüploade documenten Azure Blob Storage Azure-abonnement van klant
Applicatietelemetrie Application Insights / Log Analytics Azure-abonnement van klant
SPFx-webonderdeel-assets SharePoint CDN M365-tenant van klant
Tenantconfiguratie (API-URL, Client ID) SharePoint Tenant Storage Entities M365-tenant van klant

Wat de tenantgrenzen overschrijdt

Gegevensstroom Richting Wat wordt verzonden Doel
Licentievalidatie API → Publisher Platform Licentiesleutel (opaque string), tenant-ID Actief abonnement valideren
E-mailmeldingen API → Microsoft Graph E-mailinhoud via Mail.Send Meldingen verzenden vanuit gedeeld postvak
Teams-meldingen API → Publisher Platform → Microsoft Graph Activiteitstype, voorbeeldtekst, ontvanger-ID, templateparameters Teams-activiteitenfeedmeldingen verzenden (geproxied via de multi-tenant enterprise-app van de uitgever omdat sendActivityNotification moet worden aangeroepen door de app die het Teams-manifest bezit)
Gebruikersprofielopzoeken SPFx → Microsoft Graph Gebruikerszoekopdrachten Personenkiezer, gebruikersresolutie

Wat nooit de tenant verlaat

  • Verzoekrecords en PII van verzoekers
  • Geüploade documenten
  • Auditgeschiedenis
  • Configuratiegegevens (verzoektypes, templates, nummering)
  • Roltoewijzingen

Versleuteling

Tijdens transport

Verbinding Protocol Minimum TLS
Browser → App Service HTTPS (afgedwongen, httpsOnly: true) TLS 1.3
SPFx → App Service HTTPS (afgedwongen door SharePoint-context) TLS 1.3
App Service → Azure SQL TDS met versleuteling (Encrypt=True) TLS 1.2+
App Service → Blob Storage HTTPS (beheerde identiteit) TLS 1.2+
App Service → Microsoft Graph HTTPS TLS 1.2+

De App Service dwingt TLS 1.3 af als minimum aan de front door (TLS 1.0/1.1/1.2 geweigerd); uitgaande verbindingen naar Azure backend-services onderhandelen over TLS 1.2 of hoger.

In rust

Gegevensopslag Versleuteling Sleutelbeheer
Azure SQL Database Transparent Data Encryption (TDE) Microsoft-beheerde sleutels (standaard) of klant-beheerde sleutels (CMK)
Azure Blob Storage Storage Service Encryption (SSE), AES-256 Microsoft-beheerde sleutels (standaard) of klant-beheerde sleutels (CMK)
Application Insights Platformversleuteling Microsoft-beheerde sleutels

Op applicatieniveau

Functie Mechanisme
Documentviewer-tokens ASP.NET Core Data Protection (WOPI-stijl token, 15 minuten TTL, tenant-kruiscontrole bij elke anonieme viewer-aanroep)
Attestatie-e-handtekeningen SHA-256-hash van ondertekenaar en tijdstempel, opgeslagen in auditvelden

Privacy by design

AccessPoint implementeert structurele privacycontroles die worden afgedwongen op de API-laag, niet alleen in de UI.

PII-filtermiddleware

Een middleware op antwoordniveau onderschept alle JSON-antwoorden en verwijdert PII-velden voor gebruikers met beperkte rollen (Custodian, Contributor, Reader), serverside, ongeacht wat de client opvraagt. Verwijderde velden: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

PII-maskering in meldingen

Wanneer meldingen worden verzonden naar Custodians of Contributors, wordt PII van de verzoeker vervangen door plaatsvervangende tekst in de meldingsinhoud zelf — zelfs als het meldingstemplate PII-samenvoegvelden bevat.

Custodian/Contributor-isolatie

  • Custodians zien alleen hun toegewezen verzoeken en werken op basis van geanonimiseerde instructies
  • Contributors zien alleen hun toegewezen taken
  • Geen van beide rollen kan verzoeken buiten hun bereik doorzoeken, doorbladeren of benaderen

Logboeken, monitoring en audit

Application Insights

Alle API-telemetrie wordt verzonden naar de Application Insights-instantie van de klant:

Signaal Wat wordt vastgelegd
Verzoektraces HTTP-methode, pad, statuscode, duur, correlatie-ID
Afhankelijkheidsregistratie SQL-query's, Blob-bewerkingen, Graph API-aanroepen (duur, succes/falen)
Uitzonderingen Niet-afgehandelde uitzonderingen met stack traces
Aangepaste metrieken Verwerkingstijden van verzoeken, duur van documentconversie

Audittrail

AccessPoint onderhoudt een uitgebreide audittrail in de AuditHistory-tabel (Azure SQL), waarin het entiteitstype, de entiteits-ID, de actie (Create, Update, Delete, StatusChange), de veldnaam, de oude/nieuwe waarden, een optionele wijzigingsreden (vastgelegd bij statusovergangen zoals sluiten en heropenen), de geauthenticeerde gebruiker en een UTC-tijdstempel worden geregistreerd. Auditrecords zijn onveranderlijk — ze kunnen niet worden gewijzigd of verwijderd via de API.

Hash-geketend auditlogboek

Naast de audittrail op veldniveau registreert een manipulatiebestendig, alleen-toevoegen AuditLedger (SHA-256-hashketen) acties over alle modules heen. De integriteit kan serverside worden geverifieerd, en voor een verzoek kan een gerechtsklaar bewijspakket worden geëxporteerd.

Optimistic concurrency

Entiteiten met veel gelijktijdige toegang (Requests, Documents, CustodianAssignments) dragen elk een SQL Server ROWVERSION-concurrencytoken. De client stuurt de rijversie terug bij het bijwerken; als een andere schrijver de rij in de tussentijd heeft gewijzigd, wordt het opslaan geweigerd met HTTP 409 ("Concurrent edit detected") in plaats van stilzwijgend te overschrijven.

Bewaarlogboek voor retentie

Wanneer records worden verwijderd op grond van het bewaarbeleid, verwijdert de purge naast de databaserecords ook documentblobs, geconverteerde PDF's, annotaties en exportpakketten uit Blob Storage. De RetentionPurgeLog-tabel registreert wat is verwijderd, wanneer en door wie — een compliance-waardig spoor dat de gegevensverwijdering overleeft.

Log Analytics en waarschuwingen

Application Insights wordt ondersteund door een Log Analytics-werkruimte met configureerbare bewaartermijn (standaard 90 dagen; configureerbaar 30–730 dagen). Gegevens kunnen worden geëxporteerd naar Microsoft Sentinel of een bestaand SIEM. De Bicep-implementatie bevat twee standaard metrische waarschuwingen op de App Service:

Waarschuwing Ernst Voorwaarde Venster
Serverfouten 2 (Waarschuwing) HTTP 5xx-telling > 5 5 minuten
Hoge latentie 3 (Informatief) Gemiddelde antwoordtijd > 5 seconden 15 minuten

Klanten kunnen drempelwaarden aanpassen en actiegroepen toevoegen (e-mail, sms, webhook) in de Azure Portal.

←
Previous Aan de slag met AccessPoint
Next GC-beveiligingscontrolesreferentie
→