Technisch architectuuroverzicht voor IT-teams die AccessPoint evalueren

Last updated: August 09, 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 (v2.0.67).

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-toetsing 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
  • AI Assist (optioneel) — door Azure OpenAI ondersteunde suggesties en conceptvorming, volledig draaiend in het eigen abonnement van de klant: documentsamenvattingen, AI-redactiesuggesties, gefundeerd opstellen van concepten, intaketriage, vooraf invullen van assessmentantwoorden, semantisch zoeken en detectie van duplicaten, een wetsbewuste assistent per zaak (Ask AccessPoint — klikbare citaten, opgeslagen gesprekken, een modus My caseload), gegevensantwoorden via "Ask AccessPoint", een jurisdiction playbook dat procesantwoorden onderbouwt, automatische vertaling en een dagelijks overzicht — alles per tenant opt-in, uitsluitend gelogd op metadataniveau, met openbaarmaking van AI-activiteit per record

Alle modules worden aangestuurd door rechtsgebiedpakketten, 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 override,          │         │  (222 tables, 3,410 fields)            │
│   optional)                  │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.ReadBasic.All  │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         │  (opt-in) Azure OpenAI                  │
        │  Calendars.Read      │         │  (opt-in) Azure Document Intelligence   │
        │  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.23.2 SharePoint Online / Teams van klant Gebruikersinterface voor alle rollen
Teams-app Teams manifest v1.19, versiegelijkloop met de SPFx-oplossing en ApiVersion.Current (gestempeld door CI) Teams-beheercentrum van klant Persoonlijke app, configureerbaar tabblad, activiteitenfeedmeldingen met deep linking
Web API C# / ASP.NET Core 10, .NET 10 (~103 controllers, ~124 service-interfaces) Azure App Service (Linux) van klant Bedrijfslogica, gegevenstoegang, documentverwerking
Database SQL Server (DacPac) Azure SQL Database van klant Relationele gegevensopslag (221 tabellen, 3.410 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 plus semantisch vectorzoeken (documenten- en dossierindex); alleen ingericht wanneer deployAiSearch=true
Azure OpenAI (opt-in) Azure OpenAI Service Azure-abonnement van klant AI Assist — gefundeerd opstellen van concepten, suggesties, semantisch zoeken, zaakassistent (Ask AccessPoint); verificatie via beheerde identiteit (geen API-sleutels), alleen ingericht wanneer AI Assist is geïmplementeerd
Document Intelligence (opt-in) Azure AI Document Intelligence (prebuilt-read) Azure-abonnement van klant OCR voor scans die alleen als afbeelding beschikbaar zijn, ten behoeve van inhoudszoeken, detectie van duplicaten, samenvattingen en redactiesuggesties; verificatie via beheerde identiteit, alleen ingericht wanneer deployDocumentIntelligence=true

Wat de uitgever beheert

Service Doel
Realizer Platform Licentievalidatie, Teams-meldingsproxy, SPFx API-URL-discovery, de smart router voor het persoonlijke Teams-tabblad, en de Finish Setup-pagina na implementatie (er worden geen klantdossiergegevens verzonden)
AppSource Listing Distributie van SPFx-pakket
Implementatietemplate Bicep/ARM-template voor de Azure-backend, met één klik geïmplementeerd vanuit de Azure-portal in het abonnement van de klant
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 rechtsgebiedpakketten.

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, mappen, e-mailfamilies, leestracking, opgeslagen weergaven, beslissingsgestuurde detectie van duplicaten, Syncfusion-voorbeeldweergave, redactiepijplijn met uitzonderingen en XFDF-round-trip, zoek-en-redigeer-patronen, regelgestuurde en AI-redactiesuggesties, hergebruik van redacties uit eerdere verzoeken, antwoordverpakking met briefhoofdsamenvoeging.
Verzoekers / Contacten Volwaardige herbruikbare verzoekersidentiteit, sturing van de intakeflow, gedragswerkruimte (F&V), kosten en verificatie, samenvoegen; raadplegingen; correspondentie-opsteller met PII-firewall.
Privacy-assessments Configureerbare PIA/AIA/Security-engine: sjablonen, screenings, toewijzing van onderdelen, scoring/niveau-indeling, risicoregister, afsluitings- en toezichthoudersamenvattingen.
Privacyincidenten / datalekken Incidentintake, inperking, risico-op-schade-toetsing, 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, catalogusgestuurde aangepaste rapportbouwer (Report Studio-dashboards), statistische jaarverslagen, SLA-/managementdashboards, hash-geketend auditlogboek en gerechtsklare zaakauditexports.
AI Assist (optioneel) Door Azure OpenAI ondersteunde suggesties en conceptvorming: samenvattingen, redactiesuggesties, gefundeerd opstellen van concepten, intaketriage, suggesties voor Custodians, vooraf invullen en consistentiecontrole van assessments, semantisch zoeken en duplicaten, een wetsbewuste case-assistent — Ask AccessPoint (klikbare citaten, conceptvoorbereiding, opgeslagen gesprekken) — plus een My-caseload-/portfolio-assistent, een pakket-aangeleverd jurisdiction playbook, Ask AccessPoint-rapportage, dagelijks overzicht en inhaaloverzicht, risicoportfolio- en gedragsanalyse. Functieschakelaars per tenant; uitsluitend gelogd op metadataniveau (de assistent kan daarnaast eigenaarsprivétranscripten opslaan).
Configuratie en platform Import van rechtsgebiedpakketten (1 Universal Baseline + 106 rechtsgebiedpakketten, inclusief type-gebonden automatische statussen voor geachte weigering en optionele AI-onderbouwing), 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, plus de opt-in AI Search-, Azure OpenAI- en Document Intelligence-resources) 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. Een verplichte keuze voor het implementatietype beschermt tegen herimplementaties: Nieuwe installatie maakt de SQL-server Entra-first aan (de uitvoerende principal wordt de eerste Entra-beheerder, Entra-only-authenticatie vanaf het begin — er bestaat nooit een SQL-referentie), terwijl Bestaande installatie upgraden de app-instellingen van de operator behoudt en de databasetoegang ongemoeid laat. 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, herbevestigt Entra-only-authenticatie voor SQL (een vangnet — de template past dit al toe), verleent Microsoft Graph-machtigingen aan de beheerde identiteit (het scriptmatige alternatief voor de Finish Setup-pagina van de uitgever), configureert de optionele API-URL-override via de SharePoint storage entity en keurt SPFx API-machtigingsverzoeken goed. Elke stap kan afzonderlijk worden overgeslagen.

Graph-machtigingen worden doorgaans verleend via de Finish Setup-pagina van de uitgever — de implementatie genereert een finishSetupUrl-uitvoer die een Entra-beheerder van de klant opent om elke machtiging van de beheerde identiteit in één idempotente stap te verlenen (opnieuw uit te voeren na upgrades om nieuwe machtigingen te verwerken).

De implementatie is standaard beveiligingsgehard: TLS 1.3, FTPS uitgeschakeld, SCM/FTP-basisauthenticatie uitgeschakeld, HTTP/2 ingeschakeld, en Microsoft Defender voor SQL standaard ingeschakeld (opt-out). 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 rechtsgebiedpakket.

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. PermissionService:   │
     │                              │     resolve roles +      │
     │                              │     permission grants    │
     │                              │                          │
     │     ◄── 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 Uitgever van elke willekeurige Entra-tenant — de formaten https://login.microsoftonline.com/{tenantId}/v2.0 (v2) en https://sts.windows.net/{tenantId}/ (v1) worden gevalideerd; de tid-claim in het token stuurt de tenant-scoping
App-registratie Door de uitgever beheerde multi-tenant app, per klanttenant geautoriseerd (geen app-registratie per klant om te beheren of te roteren); blootgestelde scope access_as_user; geen clientgeheim. Isolatie tussen klanttenants wordt afgedwongen door de gevalideerde tid-claim plus een licentie-/abonnementscontrole

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
  • Optionele AI-resources (AI Search, Azure OpenAI, Document Intelligence) — uitsluitend beheerde identiteit, met lokale/sleutelauthenticatie uitgeschakeld

Referenties van de beheerde identiteit worden automatisch geroteerd door Azure.

Autorisatie en RBAC

AccessPoint implementeert een granulair, per tenant configureerbaar machtigingsmodel dat is opgeslagen in Azure SQL en bij elk verzoek wordt afgedwongen op de API-laag: een door het product gedefinieerde catalogus van atomaire machtigingscodes (bijv. request.modify, document.view, redaction.approve, request.view.pii) wordt gegroepeerd in rollen, en elke controlleractie wordt bewaakt door een machtigingscode.

Roltype Rollen Opmerkingen
Systeemrol Administrator (de enige ingebouwde standingrol) Krijgt elke catalogusmachtiging toegewezen — berekend vanuit de catalogus, niet via database-seeding — zodat deze nooit buitengesloten kan raken; onveranderlijk en onverwijderbaar.
Relatierollen Reviewer, Custodian, Contributor, Reader, Advisor Door het product gedefinieerde machtigingsbundels die automatisch en per doelrecord worden toegekend op basis van werk-/samenwerkingsrelaties (Custodian-toewijzing, Contributor-taak, beoordeling, Advisor-/Reader-lidmaatschap). Niet rechtstreeks toewijsbaar, beperkt tot het gerelateerde record, en bevatten nooit PII van de verzoeker.
Tenantrollen bijv. Request Coordinator (geleverd via het Universal Baseline-pakket), plus eventuele aangepaste rollen Volledig bewerkbare machtigingsbundels, beheerd in Instellingen > Rollen & machtigingen. Coördinator-/functionarisrollen zijn volledig tenant-gedefinieerd — de via het pakket geleverde Request Coordinator is de facto de rol van toegangs- en privacyfunctionaris.
Rol Ziet PII van verzoeker Typische toegang Typische gebruiker
Administrator Ja Alles (alle catalogusmachtigingen) IT-beheerder, systeemeigenaar
Request Coordinator (tenantrol) Ja Beheert verzoeken, toewijzingen, redacties, correspondentie Toegangs- en privacyfunctionaris
Reviewer Nee Lezen + redactieproblemen markeren/oplossen bij verzoeken in beoordeling Juridisch adviseur, QA
Advisor Nee Lezen + redacties bekijken/markeren (nooit toepassen of goedkeuren) Extern adviseur, vakspecialist
Custodian Nee Eigen toewijzingen en de bijbehorende documenten Archiefbeheerder van de afdeling
Contributor Nee Eigen taken en de bijbehorende documenten Vakinhoudelijk expert
Reader Nee Alleen-lezen op gekoppelde verzoeken en gedeelde documenten Toezicht, audit

Afdwingingspunten:

  1. [RequirePermission(code)]-attributen — een dynamische policy provider koppelt elke controlleractie aan een catalogusmachtigingscode
  2. PermissionService — bepaalt de effectieve machtigingen van de aanroeper (standingrollen samengevoegd met per-doelrecord toegekende relatiemachtigingen), met objectgebonden controles op het niveau van verzoek/document/toewijzing/taak
  3. Controles van eigenaarschap op resourceniveau — bijv. een Contributor kan alleen zijn eigen taken benaderen; een Custodian alleen zijn eigen toewijzingen
  4. PiiFilterMiddleware — verwijdert PII-velden van de verzoeker uit JSON-antwoorden voor elke aanroeper die niet de machtiging voor het bekijken van PII van de verzoeker bezit

Alle API-schrijfeindpunten dwingen machtigingen 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). Standingroltoewijzingen zijn bereikgericht (globaal, verzoek, toewijzing of taak), optioneel tijdgebonden, en relatierollen worden nooit als standingtoewijzing vastgelegd — ze worden per doelrecord afgeleid uit de onderliggende werkrecords. De eerste gebruiker die toegang krijgt tot het systeem, krijgt via bootstrap de Administrator-rol toegewezen, en een serverside vangnet voorkomt dat de laatste actieve Administrator wordt verwijderd.

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
API-URL-override (optioneel) SharePoint Tenant Storage Entity M365-tenant van klant (primaire discovery verloopt via het API-discovery-eindpunt van de uitgever)
AI-zoekindexen, samenvattingen, OCR-uitvoer (opt-in) Azure AI Search / Azure SQL Azure-abonnement van klant

Wat de tenantgrenzen overschrijdt

Gegevensstroom Richting Wat wordt verzonden Doel
Licentievalidatie API → Publisher Platform Entra-token van de beheerde identiteit (de tid-claim in het token identificeert de tenant), API-versie, en de eigen basis-URL van de API (zelfregistratie voor discovery van het webonderdeel) Actief abonnement valideren; het antwoord bevat ook de nieuwste gepubliceerde AccessPoint-versie, zodat het paneel Setup een melding "Update beschikbaar" kan tonen (alleen versienummers — geen gebruiks- of dossiergegevens)
API-URL-discovery SPFx → Publisher Platform Bearer-token (alleen tenant-ID-claim) De basis-URL van de klant-API oplossen wanneer er geen storage-entity-override is ingesteld
E-mailmeldingen API → Microsoft Graph E-mailinhoud via Mail.Send Meldingen verzenden vanuit gedeeld postvak
Teams-meldingen (optioneel — schakelbaar/elimineerbaar) API → Publisher Platform → Microsoft Graph Activiteitstype, ontvanger- + tenant-GUID's, titel/voorbeeldtekst van de melding, naam van de handelende gebruiker, verzoeknummer, record-id (deep link) 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). Dit is het enige meldingskanaal dat de tenant verlaat — e-mail en de in-app-feed bezorgen dezelfde berichten binnen de tenant. Zie Teams Notification Data Sharing
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
  • AI Assist-prompts en -responses — wanneer AI Assist is geïmplementeerd, draait de Azure OpenAI-resource in het eigen abonnement en de eigen regio van de klant; Microsoft traint geen modellen op de inhoud, en prompt-/responsinhoud wordt niet opgeslagen (alleen gebruiksmetadata, voor de budgetmeter en de openbaarmaking van AI-betrokkenheid in de zaakauditexport)
  • In-app- en e-mail/Outlook-meldingen — de in-app-feed wordt bediend vanuit de eigen API van de klant; e-mail wordt verzonden vanuit het eigen gedeelde postvak van de klant via Mail.Send. Geen van beide passeert de uitgever. Alleen de optionele Teams-activiteitenfeed verzendt gegevens buiten de tenant, en zelfs dat kan worden geminimaliseerd of geëlimineerd (hieronder)

Gegevensdeling bij Teams-meldingen (optioneel)

In lijn met de belofte van gegevenssoevereiniteit geldt: de enige tenantgegevens die de grens verlaten voor meldingen, zijn een optionele Teams-activiteitspayload — en die kan worden geminimaliseerd of volledig verwijderd. Elke melding wordt bezorgd op maximaal drie kanalen; twee blijven altijd binnen de tenant (de in-app-feed, bediend vanuit de API van de klant, en e-mail/Outlook, verzonden vanuit het eigen gedeelde postvak van de klant). De Teams-activiteitenfeed is een gemak: in de standaardmodus POST't de API van de klant een klein bericht naar de multi-tenant-app van de uitgever, die Graph sendActivityNotification aanroept (wat moet worden aangeroepen door de app die het Teams-manifest bezit). De uitgever slaat er niets van op en registreert alleen de ontvanger- + tenant-GUID's.

Velden in de standaard (via de uitgever gerelayde) Teams-payload — en wat de schakelaar Minimaliseren verwijdert:

Veld Bevat Persoonsgegevens? Verwijderd door Minimaliseren?
tenantId / recipientUserId Tenant- + ontvanger-Entra-GUID's Nee — identificatoren Nee (routering)
activityType Vaste manifest-enum (bijv. assignmentCreated) Nee Nee
previewText / topicText Voorbeeld + titel (naam van toewijzing/taak, meldingstekst) Mogelijk (vrije tekst) Ja → plaatsvervanger
actorName Weergavenaam van de handelende medewerker Ja — persoonsnaam Ja → "AccessPoint"
requestNumber Referentiecode van het verzoek Nee — referentie Nee (context)
relatedEntity + relatedRecordId Recordtype + GUID (deep link) Nee — identificatoren Nee (deep link)

PII van de verzoeker staat nooit in de payload — er is geen veld voor naam/e-mail van de verzoeker, en meldingen aan Custodians/Contributors worden hoe dan ook stroomopwaarts van PII ontdaan. Twee instellingen verscherpen dit verder:

  • Minimaliseren (Notifications:TeamsMinimalPayload, een tenantschakelaar) vervangt previewText, topicText en actorName door neutrale plaatsvervangers, zodat namen, titels en vrije tekst nooit de tenant verlaten — alleen routerings-/deep-link-identificatoren doen dat wel. Geen manifestwijziging vereist.
  • Elimineren (Notifications:TeamsRelayMode=Direct) laat de API van de klant Graph sendActivityNotification zelf aanroepen met de eigen beheerde identiteit, zodat er helemaal geen payload bij de uitgever aankomt. Dit vereist de app-rol TeamsActivity.Send op de beheerde identiteit van de API en dat de webApplicationInfo.id van het Teams-manifest naar de eigen app van de klant wijst — zie de Implementatiehandleiding.
Modus Payload naar uitgever PII/vrije tekst verlaat de tenant Installatie-inspanning
Standaardrelay Ja (velden hierboven) Namen/titels, tenzij geminimaliseerd Geen
Schakelaar Minimaliseren Ja (alleen identificatoren) Geen Eén schakelaar
Direct (zelf gehost) relay Geen Geen MI-toekenning + manifestwijziging
Teams uitgeschakeld Geen Geen (alleen e-mail + in-app) Geen

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 elke aanroeper die niet de machtiging voor het bekijken van PII van de verzoeker bezit (Custodians, Contributors, Readers, Reviewers en Advisors bezitten deze nooit), serverside, ongeacht wat de client opvraagt. Verwijderde velden: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, plus velden voor identiteit/contactgegevens van vertegenwoordigers en notities over identiteitsverificatie.

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 gerechtsklare zaakauditexport (voorheen "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

Eén RetentionService-engine schoont verouderde records op over vijf registers — verzoeken, toetsingen, incidenten, klachten en zelfstandige privacyrisico's — aangestuurd door een RetentionPeriodMonths + RetentionStartPoint per type (NULL = voor onbepaalde tijd bewaren, de standaardinstelling). Records die niet mogen verouderen, zijn door de constructie zelf uitgesloten (een toetsing die Van kracht is, een Geaccepteerd risico, een risico dat aan een zaak is verankerd), en een verlopen record waarvan een andere openstaande zaak nog afhankelijk is, wordt serverzijdig geweigerd; de geschiktheid wordt opnieuw beoordeeld op het moment van opschonen. Wanneer een record wordt opgeschoond, verwijdert de engine naast de databaserecords ook documentblobs, geconverteerde PDF's, annotaties en exportpakketten uit Blob Storage. De RetentionPurgeLog registreert wat is verwijderd, wanneer en door wie — EntityName geeft aan uit welk register het afkomstig was, samen met een momentopname van het nummer, type, sluitingsdatum en documentaantal — een compliance-waardig spoor dat de gegevensverwijdering overleeft en dat zelf nooit wordt opgeschoond.

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
→