Teknisk arkitektur

Dette dokument giver et teknisk overblik over AccessPoint-platformen for løsningsarkitekter, cybersikkerhedsingeniører og IT-direktører, der evaluerer produktet til deres organisation. Det er baseret på AccessPoint Solution Architecture Guide (v1.4.1).

Platformsoverblik

AccessPoint er en platform til aktindsigt og forvaltning af privatliv bygget på Microsoft 365 og Azure. Den startede som et værktøj til håndtering af subject access requests (SAR) og er vokset til en integreret ATIP-/privatlivssuite, der dækker hele anmodningslivscyklussen og det omkringliggende privatlivsprogram. Den kører udelukkende inden for din organisations egen Microsoft 365- og Azure-tenant: der er ingen eksterne servere, databaser eller tredjeparts-cloud-afhængigheder under kørsel, og alle data forbliver i dit miljø under din kontrol.

Platformen er organiseret i moduler, der deler én fælles rygrad for identitet, RBAC, notifikation, revision og rapportering:

• Aktindsigtsanmodninger — modtagelse efter ATI/FOIA/GDPR, tildeling til varetagere, dokumentgennemgang og sladring, pakning af svar og lovpligtig rapportering
• Privatlivsvurderinger — en konfigurerbar motor til PIA-/AIA-/sikkerhedsvurderinger
• Privatlivshændelser og -brud — arbejdsgange for modtagelse, inddæmning, skadesrisiko og bruddanmeldelse
• Klager og anker — klagelivscyklus med parter, lovbestemte tidsfrister og undersøgelse
• Privatlivsrisikoregister — risici i ISO 31000-stil, behandlingsplaner og nøglerisikoindikatorer
• Fortegnelser over behandlingsaktiviteter (ROPA) — GDPR Article 30-registreringer og eksport af fortegnelse
• Forpligtelsesregister — sporede privatlivsforpligtelser med kadence og opfølgninger

Alle moduler er drevet af konfigurationspakker, uden statiske seed-data.

Nøglekarakteristika:

• Tenant-native — implementeres som en SharePoint Framework (SPFx)-løsning og Azure PaaS-tjenester inden for din eksisterende tenant
• Ingen Power Platform-afhængigheder — ingen licenser til Dataverse, Power Automate eller Power Apps påkrævet
• Datasuverænitet — alle data befinder sig i den geografi, der er konfigureret for din Azure-tenant
• Ingen leverandøradgang under kørsel — udgiveren kan ikke tilgå dine data under normal drift
• Fast licenspris — licensering på myndighedsniveau uden måling pr. bruger
• Indbygget privatliv — Varetager- og Bidragyder-roller er strukturelt afskærmet fra PII om rekvirenter og registrerede
• Konfiguration frem for kode — anmodningstyper, undtagelseskoder og valgfelter er datadrevne
• Flersproget fra bunden — et tre-lags oversættelsessystem, der understøtter 11 sprog

Arkitekturdiagram

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)
        └──────────────────────┘

Komponentoversigt

Komponent	Teknologi	Implementeres til	Formål
SPFx-webdel	TypeScript, React 17, Fluent UI 8, SPFx 1.22.1	Kundens SharePoint Online / Teams	Brugergrænseflade for alle roller
Teams-app	Teams-manifest v1.19, app-version 1.0.0	Kundens Teams Admin Center	Personlig app, konfigurerbar fane, aktivitetsfeed-notifikationer med deep linking
Web API	C# / ASP.NET Core 10, .NET 10 (~87 controllere, ~88 tjenester)	Kundens Azure App Service (Linux)	Forretningslogik, dataadgang, dokumentbehandling
Database	SQL Server (DacPac)	Kundens Azure SQL Database	Relationelt datalager (~186 tabeller, ~2.900 felter)
Blob Storage	Azure Blob Storage	Kundens Azure Storage Account	Lagring af dokumentfiler
Overvågning	Application Insights + Log Analytics	Kundens Azure-abonnement	Telemetri, diagnostik, alarmering
AI Search (tilvalg)	Azure AI Search	Kundens Azure-abonnement	Fuldtekstsøgning i dokumentindhold; provisioneres kun når deployAiSearch=true

Hvad udgiveren driver

Tjeneste	Formål
Realizer Platform	Udstedelse og validering af licensnøgler (ingen kundedata overføres)
AppSource-listing	Distribution af SPFx-pakke
Azure Marketplace-listing	Skabelon til implementering af Azure-infrastruktur
Teams-apppakke	Distribution af Teams-manifest (sideload eller organisationens app-store)

Ingen kundedata overføres til eller lagres af nogen tjeneste, der drives af udgiveren.

Funktionelle moduler

Alle moduler kører inde i den ene Web API / SPFx-webdel og deler én fælles rygrad for identitet, RBAC, kommentarer, notifikation, My Day, revision, timer, gennemgangsarbejdsgang og rapportering. Hvert modul er datadrevet via konfigurationspakker.

Modul	Resumé
Anmodninger (ATIP/SAR)	Modtagelse af anmodning → tildeling til varetager → indsamling → svar. Konfigurerbare typer, statusser, nummerering, kalendere og SLA'er.
Dokumenter & sladring	Facetteret dokumentarbejdsområde: tags, e-mail-familier, læsesporing, gemte visninger, Syncfusion-preview, sladringspipeline med undtagelser og XFDF-round-trip, pakning af svar.
Rekvirenter / kontakter	Førsteklasses genanvendelig rekvirentidentitet, styring af modtagelsesflow, gebyrer & verifikation, fletning; høringer; korrespondanceværktøj med PII-firewall.
Privatlivsvurderinger	Konfigurerbar PIA-/AIA-/sikkerhedsmotor: skabeloner, screeninger, sektionsdelegering, scoring/niveaudeling, risikoregister, afslutnings-/tilsynsresuméer.
Privatlivshændelser / brud	Modtagelse af hændelser, inddæmning, skadesrisiko, regler for bruddanmeldelse efter regelsæt, afhjælpning.
Klager & anker	Klagelivscyklus: parter, lovbestemte tidsfrister, antagelighed, undersøgelse, gennemgang af indlæg.
Risiko & forpligtelser	ISO 31000-risikoregister med risikoappetit, KRI'er og behandlingsopgaver; forpligtelsesregister med kadence og opfølgninger.
ROPA / registrerede	Genanvendelige programmer/systemer med GDPR Article 30-registreringer og eksport af fortegnelse.
Gennemgange	Konfigurerbar sekventiel/parallel gennemgangs- og godkendelsesmotor, der genbruges på tværs af alle sagsentiteter.
Rapportering & revision	Faste rapporter, brugerdefineret rapportbygger, statistiske årsrapporter, SLA-/ledelsesdashboards, hash-kædet revisionslog og retsklare bevispakker.
Konfiguration & platform	Import af konfigurationspakker, tenant-indstillinger, brugerdefinerede roller/tilladelser, feature toggles, brugerdefinerede felter, oversættelsestabeller for 11 sprog.

Implementeringsmodel

AccessPoint bruger en opdelt implementeringsmodel. SPFx-webdelen installeres fra Microsoft AppSource (eller et tenant-App Catalog), Teams-apppakken installeres via sideloading eller organisationens app-store, og Azure-backenden implementeres i kundens eget abonnement via en af to metoder:

• Azure-portal (anbefales) — implementering med ét klik af alle Azure-ressourcer (App Service, SQL, Blob Storage, Application Insights) via ARM/Bicep. API'en implementeres med zipdeploy under ARM-implementeringen; koden downloades én gang fra udgiverens CDN og lagres i kundens App Service, uden ekstern afhængighed under kørsel. Kunden bevarer det fulde ejerskab over resource-gruppen.
• Bicep-skabelon + PowerShell-script (manuelt) — for organisationer med streng ændringsstyring. En Deploy to Azure-knap eller Deploy-AccessPoint.ps1 implementerer infrastrukturen, konfigurerer SQL Entra-only-godkendelse, tildeler Microsoft Graph-tilladelser til managed identity, konfigurerer SharePoint tenant storage-entiteter og godkender SPFx API-tilladelsesanmodninger. Hvert trin kan springes over uafhængigt.

Implementeringen er sikkerhedshærdet som standard: TLS 1.3, FTPS deaktiveret, SCM/FTP basic authentication deaktiveret og HTTP/2 aktiveret. API'en samler sin database-DacPac og anvender den ved opstart via en migreringstjeneste, der bruger DacServices.Deploy(upgradeExisting: true) — en no-op på et allerede aktuelt skema og en additiv, ikke-destruktiv delta efter en skemaændring (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). Migreringsresultatet vises via /api/health. Efter implementering giver en administrator samtykke til Realizer-enterprise-appen (Teams-notifikationer), konfigurerer afsenderpostkassen og importerer en jurisdiktionsspecifik konfigurationspakke.

Godkendelse og identitet

AccessPoint bruger Microsoft Entra ID som sin eneste identitetsudbyder. Der er ingen applikationsspecifikke brugerkonti eller adgangskoder. SPFx-webdelen henter en JWT til API-audiencen via AadHttpClient; API'en validerer issuer, audience, signatur og udløb ved hver anmodning. MFA- og Conditional Access-politikker konfigureret i tenanten gælder fuldt ud.

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	Værdi
Identitetsudbyder	Microsoft Entra ID (Azure AD)
Protokol	OAuth 2.0 / OpenID Connect
Tokentype	JWT Bearer
Audience	api://<client-id> og <client-id> (både v1- og v2-tokens accepteres)
Issuer	https://login.microsoftonline.com/{tenantId}/v2.0 og https://sts.windows.net/{tenantId}/
Appregistrering	Single-tenant (AzureADMyOrg); eksponeret scope access_as_user; ingen client secret

Managed identity

App Service bruger en system-assigned managed identity til at godkende sig over for backend-tjenester, så der lagres ingen client secrets eller certifikater i applikationen:

• Azure SQL Database — Entra-only-godkendelse (SQL-adgangskodegodkendelse er deaktiveret)
• Azure Blob Storage — DefaultAzureCredential (managed identity i produktion)
• Microsoft Graph API — ManagedIdentityCredential med applikationstilladelser

Legitimationsoplysninger for managed identity roteres automatisk af Azure.

Autorisation og RBAC

AccessPoint implementerer rollebaseret adgangskontrol på applikationsniveau, lagret i Azure SQL og håndhævet i API-laget ved hver anmodning.

Rolle	Ser rekvirent-PII	Administrerer anmodninger	Administrerer tildelinger	Indsender dokumenter	Typisk bruger
Administrator	Ja	Kun konfiguration	Nej	Nej	IT-administrator, systemejer
SAO	Ja	Ja	Ja	Nej	Aktindsigts- & privatlivsansvarlig
Kontrollant	Ja	Skrivebeskyttet	Skrivebeskyttet	Nej	Juridisk rådgiver, QA
Varetager	Nej	Nej	Egne tildelinger	Nej	Myndighedens dokumentansvarlig
Bidragyder	Nej	Nej	Nej	Egne opgaver	Fagekspert
Læser	Nej	Skrivebeskyttet	Skrivebeskyttet	Nej	Tilsyn, revision

Håndhævelsespunkter:

1. API-autorisationspolitikker — ASP.NET Core [Authorize(Policy = "...")]-attributter på hver controller-handling
2. RoleAuthorizationHandler — kontrollerer UserRoles-tabellen for den godkendte brugers rollemedlemskab
3. ResourceOwnerAuthorizationHandler — validerer ejerskab på ressourceniveau (f.eks. kan en Bidragyder kun tilgå sine egne opgaver)
4. PiiFilterMiddleware — fjerner rekvirent-PII-felter fra JSON-svar for begrænsede roller (Varetager, Bidragyder, Læser)

Alle API-skriveendepunkter håndhæver roller server-side på controller-niveau. Omklassificering af dokumenter er scope-bevidst — den bruger, der indsamlede et dokument, er den, der kan omklassificere det — og når en anmodning er lukket, returnerer ændringer på dens objektgraf HTTP 409, med et lille sæt bevidste undtagelser (korrespondance efter lukning, opbevaringssletning og genåbning). Roller er afgrænsede og kan begrænses til specifikke ressourcer (globalt, anmodnings-, tildelings- eller opgave-scope). Den første bruger, der tilgår systemet, bootstrappes med både Administrator- og SAO-rollen.

Datalokalitet og -suverænitet

Alle data befinder sig i kundens Azure-tenant i den region, der vælges under implementeringen. Ingen data overføres til eller lagres i andre regioner, medmindre kunden udtrykkeligt konfigurerer Azure geo-replikering.

Canadiske føderale myndigheder: For GC-specifikke krav til datalokalitet, ITSG-33-kontrolkortlægning og overholdelse af GC Cloud Guardrails henvises til GC-reference for sikkerhedskontroller.

Placering af kundedata

Datatype	Lagringsplacering	Kontrolleres af
Anmodningsregistreringer, brugerdata, revisionsspor	Azure SQL Database	Kundens Azure-abonnement
Uploadede dokumenter	Azure Blob Storage	Kundens Azure-abonnement
Applikationstelemetri	Application Insights / Log Analytics	Kundens Azure-abonnement
SPFx-webdelsaktiver	SharePoint CDN	Kundens M365-tenant
Tenant-konfiguration (API-URL, Client ID)	SharePoint Tenant Storage Entities	Kundens M365-tenant

Hvad krydser tenant-grænser

Datastrøm	Retning	Hvad overføres	Formål
Licensvalidering	API → udgiverplatform	Licensnøgle (opaque streng), tenant-id	Validere aktivt abonnement
E-mail-notifikationer	API → Microsoft Graph	E-mail-indhold via Mail.Send	Sende notifikationer fra delt postkasse
Teams-notifikationer	API → udgiverplatform → Microsoft Graph	Aktivitetstype, preview-tekst, modtager-id, skabelonparametre	Sende Teams-aktivitetsfeed-notifikationer (proxyet gennem udgiverens multi-tenant-enterprise-app, fordi sendActivityNotification skal kaldes af den app, der ejer Teams-manifestet)
Opslag af brugerprofil	SPFx → Microsoft Graph	Brugersøgeforespørgsler	People picker, brugeropløsning

Hvad forlader aldrig tenanten

• Anmodningsregistreringer og rekvirent-PII
• Uploadede dokumenter
• Revisionshistorik
• Konfigurationsdata (anmodningstyper, skabeloner, nummerering)
• Rolletildelinger

Kryptering

Under transport

Forbindelse	Protokol	Minimum-TLS
Browser → App Service	HTTPS (håndhævet, httpsOnly: true)	TLS 1.3
SPFx → App Service	HTTPS (håndhævet af SharePoint-kontekst)	TLS 1.3
App Service → Azure SQL	TDS med kryptering (Encrypt=True)	TLS 1.2+
App Service → Blob Storage	HTTPS (managed identity)	TLS 1.2+
App Service → Microsoft Graph	HTTPS	TLS 1.2+

App Service håndhæver TLS 1.3 som sit minimum ved frontdøren (TLS 1.0/1.1/1.2 afvises); udgående forbindelser til Azure-backend-tjenester forhandler TLS 1.2 eller højere.

I hvile

Datalager	Kryptering	Nøglehåndtering
Azure SQL Database	Transparent Data Encryption (TDE)	Microsoft-administrerede nøgler (standard) eller kundeadministrerede nøgler (CMK)
Azure Blob Storage	Storage Service Encryption (SSE), AES-256	Microsoft-administrerede nøgler (standard) eller kundeadministrerede nøgler (CMK)
Application Insights	Platformskryptering	Microsoft-administrerede nøgler

På applikationsniveau

Funktion	Mekanisme
Tokens til dokumentfremviser	ASP.NET Core Data Protection (WOPI-lignende token, 15-minutters TTL, tenant-krydstjek ved hvert anonymt fremviserkald)
Attest-e-signaturer	SHA-256-hash af underskriver og tidsstempel lagret i revisionsfelter

Indbygget privatliv

AccessPoint implementerer strukturelle privatlivskontroller, der håndhæves i API-laget, ikke kun i brugergrænsefladen.

PII-filter-middleware

En middleware på svarniveau opfanger alle JSON-svar og fjerner PII-felter for brugere med begrænsede roller (Varetager, Bidragyder, Læser), server-side, uanset hvad klienten anmoder om. Felter, der fjernes: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

Fjernelse af PII i notifikationer

Når notifikationer sendes til Varetagere eller Bidragydere, erstattes rekvirent-PII med pladsholdertekst i selve notifikationsindholdet — også selvom notifikationsskabelonen indeholder PII-flettefelter.

Isolation af Varetager/Bidragyder

• Varetagere ser kun deres tildelte anmodninger og arbejder ud fra renset instruktion
• Bidragydere ser kun deres tildelte opgaver
• Ingen af rollerne kan søge i, gennemse eller tilgå anmodninger uden for deres scope

Logning, overvågning og revision

Application Insights

Al API-telemetri sendes til kundens Application Insights-instans:

Signal	Hvad opfanges
Anmodningsspor	HTTP-metode, sti, statuskode, varighed, correlation ID
Afhængighedssporing	SQL-forespørgsler, Blob-operationer, Graph API-kald (varighed, succes/fejl)
Undtagelser	Uhåndterede undtagelser med stack traces
Brugerdefinerede metrikker	Behandlingstider for anmodninger, varigheder for dokumentkonvertering

Revisionsspor

AccessPoint vedligeholder et omfattende revisionsspor i tabellen AuditHistory (Azure SQL), som registrerer entitetstypen, entitets-id'et, handlingen (Create, Update, Delete, StatusChange), feltnavnet, gamle/nye værdier, en valgfri ændringsårsag (opfanget ved statusovergange som lukning og genåbning), den godkendte bruger og et UTC-tidsstempel. Revisionsregistreringer er uforanderlige — de kan ikke ændres eller slettes via API'en.

Hash-kædet revisionslog

Ud over revisionssporet på feltniveau registrerer en manipulationsafslørende AuditLedger (SHA-256-hashkæde), der kun kan tilføjes til, handlinger på tværs af alle moduler. Integriteten kan verificeres server-side, og en retsklar bevispakke kan eksporteres for en anmodning.

Optimistisk samtidighed

Entiteter med høj samtidighedskonflikt (Requests, Documents, CustodianAssignments) bærer hver et SQL Server ROWVERSION-samtidighedstoken. Klienten gengiver row-versionen ved opdatering; hvis en anden skriver har ændret rækken i mellemtiden, afvises gemningen med HTTP 409 ("Concurrent edit detected") frem for stiltiende at overskrive.

Log over opbevaringssletning

Når registreringer slettes under opbevaringspolitik, sletter sletningen dokument-blobs, konverterede PDF'er, annotationer og eksportpakker fra Blob Storage ud over databaseregistreringerne. Tabellen RetentionPurgeLog registrerer hvad der blev slettet, hvornår og af hvem — et compliance-egnet spor, der overlever datafjernelsen.

Log Analytics og alarmer

Application Insights understøttes af et Log Analytics-workspace med konfigurerbar opbevaring (standard 90 dage; konfigurerbar 30–730 dage). Data kan eksporteres til Microsoft Sentinel eller et eksisterende SIEM. Bicep-implementeringen indeholder to standard-metrik-alarmer på App Service:

Alarm	Alvorlighed	Betingelse	Vindue
Server Errors	2 (Warning)	HTTP 5xx-antal > 5	5 minutter
High Latency	3 (Informational)	Gennemsnitlig svartid > 5 sekunder	15 minutter

Kunder kan tilpasse tærskler og tilføje handlingsgrupper (e-mail, SMS, webhook) i Azure Portal.