Oversigt over teknisk arkitektur for IT-teams, der evaluerer AccessPoint

Last updated: August 09, 2026 by Steve

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 (v2.0.67).

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
  • AI Assist (valgfri) — Azure OpenAI-baserede forslag og udkast, der kører udelukkende i kundens eget abonnement: dokumentresuméer, AI-overstregningsforslag, forankret udarbejdelse af udkast, modtagelsestriage, forududfyldning af vurderingssvar, semantisk søgning og dubletgenkendelse, en lovbevidst assistent pr. sag (Spørg AccessPoint — klikbare citater, gemte samtaler, en Min sagsmængde-tilstand), "Spørg AccessPoint"-datasvar, en jurisdiktionsplaybook, der forankrer procesvar, automatisk oversættelse og en daglig briefing — alt sammen tilvalg pr. lejer, kun logget som metadata, med AI-aktivitetsoplysning pr. post

Alle moduler er drevet af jurisdiktionspakker, 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 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)

Komponentoversigt

Komponent Teknologi Implementeres til Formål
SPFx-webdel TypeScript, React 17, Fluent UI 8, SPFx 1.23.2 Kundens SharePoint Online / Teams Brugergrænseflade for alle roller
Teams-app Teams-manifest v1.19, versionslåst sammen med SPFx-løsningen og ApiVersion.Current (stemplet af CI) Kundens Teams Admin Center Personlig app, konfigurerbar fane, aktivitetsfeed-notifikationer med deep linking
Web API C# / ASP.NET Core 10, .NET 10 (~103 controllere, ~124 tjenestegrænseflader) Kundens Azure App Service (Linux) Forretningslogik, dataadgang, dokumentbehandling
Database SQL Server (DacPac) Kundens Azure SQL Database Relationelt datalager (221 tabeller, 3.410 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 plus semantisk vektorsøgning (dokumenter + sagsindeks); provisioneres kun når deployAiSearch=true
Azure OpenAI (tilvalg) Azure OpenAI Service Kundens Azure-abonnement AI Assist — forankret udarbejdelse af udkast, forslag, semantisk søgning, sagsassistent (Spørg AccessPoint); managed identity-godkendelse (ingen API-nøgler), provisioneres kun når AI Assist er udrullet
Document Intelligence (tilvalg) Azure AI Document Intelligence (prebuilt-read) Kundens Azure-abonnement OCR til scanninger, der kun består af billeder, og som fodrer indholdssøgning, dubletgenkendelse, resuméer og overstregningsforslag; managed identity-godkendelse, provisioneres kun når deployDocumentIntelligence=true

Hvad udgiveren driver

Tjeneste Formål
Realizer Platform Licensvalidering, Teams-notifikationsproxy, SPFx API-URL-registreringsopslag, Teams' personlige fane-smart-router og siden Finish Setup efter implementering (ingen kundesagsdata overføres)
AppSource-listing Distribution af SPFx-pakke
Udrulningsskabelon Bicep/ARM-skabelon til Azure-backenden, udrullet med ét klik fra Azure-portalen til kundens abonnement
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, Min dag, revision, timer, gennemgangsarbejdsgang og rapportering. Hvert modul er datadrevet via jurisdiktionspakker.

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, mapper, e-mail-familier, læsesporing, gemte visninger, beslutningsbaseret dubletgenkendelse, Syncfusion-preview, sladringspipeline med undtagelser og XFDF-round-trip, Find & overstreg-mønstre, regelbaserede og AI-baserede overstregningsforslag, genbrug af overstregninger fra tidligere anmodninger, pakning af svar med brevhovedfletning.
Rekvirenter / kontakter Førsteklasses genanvendelig rekvirentidentitet, styring af modtagelsesflow, arbejdsområde for useriøs-eller-chikanøs adfærd, gebyrer & verifikation, fletning; høringer; korrespondanceværktøj med PII-firewall.
Privatlivsvurderinger Konfigurerbar PIA-/AIA-/sikkerhedsmotor: skabeloner, screeninger, afsnitstildeling, 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, katalogdrevet brugerdefineret rapportbygger (Report Studio-dashboards), statistiske årsrapporter, SLA-/ledelsesdashboards, hash-kædet revisionslog og retsklare sagsrevisionseksporter.
AI Assist (valgfri) Azure OpenAI-baserede forslag og udkast: resuméer, overstregningsforslag, forankret udarbejdelse af udkast, modtagelsestriage, forslag til varetagere, forududfyldning og konsistenstjek af vurderinger, semantisk søgning og dubletter, en lovbevidst sagsassistent — Spørg AccessPoint (klikbare citater, forbered-et-udkast, gemte samtaler) — samt en Min sagsmængde-/porteføljeassistent, en pakke-forudfyldt jurisdiktionsplaybook, Spørg AccessPoint-rapportering, daglig briefing og opsamlingsbriefing, risikoportefølje og adfærdsanalyse. Til/fra-knapper pr. funktion og lejer; kun metadata logges (assistenten kan desuden gemme ejer-private transskriptioner).
Konfiguration & platform Import af jurisdiktionspakker (1 Universal Baseline-pakke + 106 jurisdiktionspakker, herunder typeafgrænsede auto-statusser for anset afslag og valgfri AI-forankring), 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, plus de valgfrie AI Search-/Azure OpenAI-/Document Intelligence-ressourcer) 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. Et obligatorisk valg af installationstype styrer genimplementeringer: New installation opretter SQL-serveren Entra-first (den installerende principal bliver den indledende Entra-administrator, Entra-only-godkendelse fra fødslen — der findes aldrig en SQL-legitimation), mens Upgrade existing installation bevarer operatørens applikationsindstillinger og lader databaseadgangen være urørt. 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, genbekræfter SQL Entra-only-godkendelse (et sikkerhedsnet — skabelonen anvender den), bevilger Microsoft Graph-tilladelser til managed identity (den scriptede pendant til udgiverens Finish Setup-side), konfigurerer den valgfrie SharePoint storage-entity-tilsidesættelse af API-URL'en og godkender SPFx API-tilladelsesanmodninger. Hvert trin kan springes over uafhængigt.

Graph-tilladelser bevilges normalt gennem udgiverens Finish Setup-side — implementeringen udsender et finishSetupUrl-output, som en kundes Entra-administrator åbner for at bevilge alle managed identity-tilladelser i én idempotent omgang (køres igen efter opgraderinger for at få nye tilladelser med).

Implementeringen er sikkerhedshærdet som standard: TLS 1.3, FTPS deaktiveret, SCM/FTP basic authentication deaktiveret, HTTP/2 aktiveret, og Microsoft Defender for SQL slået til som standard (kan fravælges). 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 jurisdiktionspakke.

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. PermissionService:   │
     │                              │     resolve roles +      │
     │                              │     permission grants    │
     │                              │                          │
     │     ◄── 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 Enhver Entra-lejers issuer — formaterne https://login.microsoftonline.com/{tenantId}/v2.0 (v2) og https://sts.windows.net/{tenantId}/ (v1) valideres; tokenets tid-krav styrer lejerafgrænsningen
Appregistrering Udgiverdrevet multi-tenant-app, godkendt (consent) pr. kundelejer (ingen appregistrering pr. kunde at administrere eller rotere); eksponeret scope access_as_user; ingen client secret. Isolation mellem kundelejere håndhæves af det validerede tid-krav plus et licens-/abonnementstjek

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 (serveren oprettes Entra-first; der findes aldrig en SQL-legitimation)
  • Azure Blob Storage — DefaultAzureCredential (managed identity i produktion)
  • Microsoft Graph API — ManagedIdentityCredential med applikationstilladelser
  • Valgfrie AI-ressourcer (AI Search, Azure OpenAI, Document Intelligence) — udelukkende managed identity-godkendelse, med lokal/nøglebaseret godkendelse deaktiveret

Legitimationsoplysninger for managed identity roteres automatisk af Azure.

Autorisation og RBAC

AccessPoint implementerer en granuleret, lejerkonfigurerbar tilladelsesmodel, der er lagret i Azure SQL og håndhæves i API-laget ved hver eneste anmodning: et produktdefineret katalog af atomare tilladelseskoder (f.eks. request.modify, document.view, redaction.approve, request.view.pii) grupperes i roller, og hver controller-handling er spærret bag en tilladelseskode.

Rolletype Roller Bemærkninger
Systemrolle Administrator (den eneste indbyggede faste rolle) Opløses til alle katalogtilladelser — beregnet ud fra kataloget, ikke database-seeding — så den kan aldrig blive låst ude; uforanderlig og kan ikke slettes.
Relationsroller Kontrollant, Varetager, Bidragyder, Læser, Rådgiver Produktdefinerede tilladelsespakker, der tildeles automatisk og pr. mål ud fra arbejds-/samarbejdsrelationer (Varetager-tildeling, Bidragyder-opgave, gennemgang, Rådgiver-/Læser-medlemskab). Kan ikke tildeles direkte, er afgrænset til den tilknyttede post og indeholder aldrig anmoderens PII.
Lejerroller f.eks. Request Coordinator (leveret via Universal Baseline-pakken) samt eventuelle brugerdefinerede roller Fuldt redigerbare tilladelsespakker, der administreres under Indstillinger > Roller & tilladelser. Koordinator-/sagsbehandlerroller er fuldt ud lejerdefinerede — den pakkeleverede Request Coordinator er den de facto adgangs- og privatlivsansvarlige rolle.
Rolle Ser rekvirent-PII Typisk adgang Typisk bruger
Administrator Ja Alt (alle katalogtilladelser) IT-administrator, systemejer
Request Coordinator (lejerrolle) Ja Administrerer anmodninger, tildelinger, sladringer, korrespondance Aktindsigts- & privatlivsansvarlig
Kontrollant Nej Læse + markere/løse sladringsspørgsmål på anmodninger under gennemgang Juridisk rådgiver, QA
Rådgiver Nej Læse + se/markere sladringer (anvender eller godkender aldrig) Ekstern rådgiver, fagekspert
Varetager Nej Egne tildelinger og deres dokumenter Myndighedens dokumentansvarlig
Bidragyder Nej Egne opgaver og deres dokumenter Fagekspert
Læser Nej Skrivebeskyttet adgang til tilknyttede anmodninger og delte dokumenter Tilsyn, revision

Håndhævelsespunkter:

  1. [RequirePermission(code)]-attributter — en dynamisk policy-udbyder knytter hver controller-handling til en katalogtilladelseskode
  2. PermissionService — opløser den kaldendes effektive tilladelser (faste roller forenet med relationstildelinger pr. mål), med objektafgrænsede tjek på anmodnings-/dokument-/tildelings-/opgaveniveau
  3. Ressourceniveau-ejerskabstjek — f.eks. kan en Bidragyder kun tilgå sine egne opgaver; en Varetager kun sine egne tildelinger
  4. PiiFilterMiddleware — fjerner rekvirent-PII-felter fra JSON-svar for enhver kaldende, der ikke har tilladelsen til at se anmoderens PII

Alle API-skriveendepunkter håndhæver tilladelser 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). Faste rolletildelinger er afgrænsede (globalt, anmodnings-, tildelings- eller opgaveniveau), kan eventuelt være tidsbegrænsede, og relationsroller skrives aldrig som faste tildelinger — de udledes pr. mål fra de underliggende arbejdsposter. Den første bruger, der tilgår systemet, bootstrappes med Administrator-rollen, og et serverside-værn forhindrer, at den sidste aktive Administrator fjernes.

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
Tilsidesættelse af API-URL (valgfri) SharePoint Tenant Storage Entity Kundens M365-tenant (primær registrering sker via udgiverens API-registreringsendepunkt)
AI-søgeindekser, resuméer, OCR-output (tilvalg) Azure AI Search / Azure SQL Kundens Azure-abonnement

Hvad krydser tenant-grænser

Datastrøm Retning Hvad overføres Formål
Licensvalidering API → udgiverplatform Entra managed identity-token (tokenets tid-krav identificerer lejeren), API-version og API'ens egen basis-URL (selvregistrering til webdelsregistrering) Validere aktivt abonnement; svaret bærer også den senest udgivne AccessPoint-version, så Opsætning-panelet kan vise meddelelsen Opdatering tilgængelig (kun versionsnumre — ingen brugs- eller sagsdata)
Registrering af API-URL SPFx → udgiverplatform Bearer-token (kun tenant-id-krav) Finde kundens API-basis-URL, når ingen storage-entity-tilsidesættelse er angivet
E-mail-notifikationer API → Microsoft Graph E-mail-indhold via Mail.Send Sende notifikationer fra delt postkasse
Teams-notifikationer (valgfri — kan minimeres/elimineres) API → udgiverplatform → Microsoft Graph Aktivitetstype, modtager- + lejer-GUID'er, notifikationens titel/preview-tekst, den handlende brugers navn, anmodningsnummer, post-id (deep link) Sende Teams-aktivitetsfeed-notifikationer (proxyet gennem udgiverens multi-tenant-enterprise-app, fordi sendActivityNotification skal kaldes af den app, der ejer Teams-manifestet). Dette er den eneste notifikationskanal, der forlader lejeren — e-mail og den indbyggede feed leverer de samme meddelelser i lejeren. Se Teams-notifikationers datadeling
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
  • AI Assist-prompts og -svar — når AI Assist er udrullet, kører Azure OpenAI-ressourcen i kundens eget abonnement og region; Microsoft træner ikke modeller på indholdet, og prompt-/svarindhold gemmes ikke (kun brugsmetadata, til budgetmåleren og sagsrevisionseksportens oplysning om AI-involvering)
  • Indbygget feed og e-mail-/Outlook-notifikationer — den indbyggede feed leveres fra kundens egen API; e-mail sendes fra kundens egen delte postkasse via Mail.Send. Ingen af dem passerer udgiveren. Kun det valgfrie Teams-aktivitetsfeed sender nogen data uden for lejeren, og selv det kan minimeres eller elimineres (nedenfor)

Teams-notifikationers datadeling (valgfrit)

I overensstemmelse med løftet om datasuverænitet er de eneste lejerdata, der forlader grænsen af hensyn til notifikationer, en valgfri Teams-aktivitetspayload — og den kan minimeres eller fjernes helt. Hver notifikation leveres på op til tre kanaler; to er altid i lejeren (den indbyggede feed, leveret fra kundens API, og e-mail/Outlook, sendt fra kundens egen delte postkasse). Teams-aktivitetsfeedet er en bekvemmelighed: i sin standardtilstand POST'er kundens API en lille payload til udgiverens multi-tenant-app, som kalder Graph sendActivityNotification (som skal kaldes af den app, der ejer Teams-manifestet). Udgiveren gemmer intet af det og logger kun modtager- + lejer-GUID'erne.

Felter i den standard (udgiver-relæede) Teams-payload — og hvad Minimér-knappen fjerner:

Felt Indeholder Personoplysninger? Fjernet af Minimér?
tenantId / recipientUserId Lejer- + modtager-Entra-GUID'er Nej — identifikatorer Nej (routing)
activityType Fast manifest-enum (f.eks. assignmentCreated) Nej Nej
previewText / topicText Preview + titel (tildelings-/opgavenavn, notifikationstekst) Muligvis (fritekst) Ja → pladsholder
actorName Den handlende medarbejders visningsnavn Ja — personnavn Ja → "AccessPoint"
requestNumber Anmodningens referencekode Nej — reference Nej (kontekst)
relatedEntity + relatedRecordId Posttype + GUID (deep link) Nej — identifikatorer Nej (deep link)

Rekvirent-PII findes aldrig i payloaden — der er intet felt til rekvirentens navn/e-mail, og notifikationer til Custodian/Contributor er under alle omstændigheder PII-tømt i forvejen. To kontroller strammer dette yderligere:

  • Minimér (Notifications:TeamsMinimalPayload, en lejer-til/fra-knap) erstatter previewText, topicText og actorName med neutrale pladsholdere, så navne, titler og fritekst aldrig forlader lejeren — kun routing-/deep-link-identifikatorer gør. Ingen manifestændring krævet.
  • Eliminér (Notifications:TeamsRelayMode=Direct) lader kundens API selv kalde Graph sendActivityNotification med sin managed identity, så ingen payload nogensinde når udgiveren. Det kræver app-rollen TeamsActivity.Send på API'ens managed identity, og at Teams-manifestets webApplicationInfo.id peger på kundens egen app — se Installationsvejledningen.
Tilstand Payload til udgiveren PII/fritekst forlader lejeren Opsætningsindsats
Standardrelæ Ja (felter ovenfor) Navne/titler, medmindre minimeret Ingen
Minimér-knap Ja (kun identifikatorer) Ingen Én til/fra-knap
Direct (selv-hostet) relæ Ingen Ingen MI-bevilling + manifestredigering
Teams deaktiveret Ingen Ingen (kun e-mail + indbygget) Ingen

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, server-side, for enhver kaldende, der ikke har tilladelsen til at se anmoderens PII (Varetagere, Bidragydere, Læsere, Kontrollanter og Rådgivere har den aldrig), uanset hvad klienten anmoder om. Felter, der fjernes: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, samt repræsentantens identitets-/kontaktfelter og noter om identitetsverifikation.

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 sagsrevisionseksport (tidligere kaldet "bevispakke") kan genereres 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 RetentionService-motor kasserer udløbne poster på tværs af fem registre — anmodninger, vurderinger, hændelser, klager og selvstændige privatlivsrisici — drevet af en pr.-type RetentionPeriodMonths + RetentionStartPoint (NULL = opbevares på ubestemt tid, standard). Poster, der ikke må udløbe, er udelukket af konstruktion (en vurdering, der er Trådt i kraft, en Accepteret risiko, en risiko, der er tilknyttet en sag), og en udløbet post, som en anden åben sag stadig afhænger af, afvises server-side; berettigelsen genvurderes på kassationstidspunktet. Når en post kasseres, sletter motoren dokument-blobs, konverterede PDF'er, annotationer og eksportpakker fra Blob Storage ud over databaseposterne. RetentionPurgeLog registrerer, hvad der blev slettet, hvornår og af hvem — EntityName identificerer, hvilket register det stammer fra, sammen med et øjebliksbillede af dets nummer, type, afslutningsdato og antal dokumenter — et compliance-egnet spor, der overlever datafjernelsen og aldrig selv kasseres.

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.

←
Previous Kom godt i gang med AccessPoint
Next GC-reference for sikkerhedskontroller
→