Teknisk arkitektur

Detta dokument ger en teknisk översikt av AccessPoint-plattformen för lösningsarkitekter, cybersäkerhetstekniker och IT-direktörer som utvärderar produkten för sin organisation. Det är hämtat från AccessPoint Solution Architecture Guide (v2.0.67).

Plattformsöversikt

AccessPoint är en plattform för hantering av tillgång till information och integritet, byggd på Microsoft 365 och Azure. Den började som ett verktyg för hantering av subject access request (SAR) och har vuxit till en integrerad svit för ATIP och integritetsfrågor som täcker förfrågans hela livscykel och det omgivande integritetsprogrammet. Den körs helt inom din organisations egen Microsoft 365- och Azure-klientorganisation: det finns inga externa servrar, databaser eller tredjepartsmolnberoenden vid drift, och all data finns kvar i din miljö under din kontroll.

Plattformen är organiserad i moduler som delar en gemensam kärna för identitet, RBAC, aviseringar, granskning och rapportering:

• Åtkomstförfrågningar – mottagning enligt ATI/FOIA/GDPR, tilldelning till förvaltare, dokumentgranskning och maskering, paketering av svar samt lagstadgad rapportering
• Integritetsbedömningar – en konfigurerbar motor för PIA-, AIA- och säkerhetsbedömningar
• Integritetsincidenter och personuppgiftsincidenter – mottagning, begränsning, skaderiskbedömning och arbetsflöden för anmälan om personuppgiftsincidenter
• Klagomål och överklaganden – klagomålets livscykel med parter, lagstadgade tidsfrister och utredning
• Riskregister för integritetsfrågor – risker enligt ISO 31000, åtgärdsplaner och nyckelriskindikatorer
• Register över behandling (ROPA) – GDPR Article 30-register och registerexport
• Register över åtaganden – spårade integritetsåtaganden med frekvens och avstämningar
• AI Assist (valfri) – Azure OpenAI-baserade förslag och utkast som körs helt inom kundens egen prenumeration: dokumentsammanfattningar, AI-maskeringsförslag, grundade utkast, mottagningstriage, förifyllnad av bedömningssvar, semantisk sökning och dubblettidentifiering, en lagstiftningsmedveten assistent per ärende (Fråga AccessPoint — klickbara hänvisningar, sparade konversationer, ett läge Min ärendemängd), datasvar via "Fråga AccessPoint", en jurisdiktionshandbok som grundar processvar, automatisk översättning och en daglig sammanfattning — allt valbart per klientorganisation, endast metadata loggas, med redovisning av AI-aktivitet per post

Alla moduler är jurisdiktionspaketstyrda, utan statisk startdata.

Huvudegenskaper:

• Inbyggd i klientorganisationen – distribueras som en SharePoint Framework (SPFx)-lösning och Azure PaaS-tjänster inom din befintliga klientorganisation
• Inga Power Platform-beroenden – ingen licensiering av Dataverse, Power Automate eller Power Apps krävs
• Datasuveränitet – all data lagras i din Azure-klientorganisations konfigurerade geografi
• Ingen leverantörsåtkomst vid drift – utgivaren kan inte komma åt dina data vid normal drift
• Licensiering till fast pris – avdelningslicensiering utan mätning per användare
• Inbyggt integritetsskydd – rollerna förvaltare och medarbetare är strukturellt avskilda från personuppgifter om sökande och registrerade
• Konfiguration i stället för kod – förfrågningstyper, undantagskoder och valfält är datadrivna
• Flerspråkig från grunden – ett system för översättning i tre nivåer som stöder 11 språk

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)

Komponentinventering

Komponent	Teknik	Driftsätts till	Syfte
SPFx-webbdel	TypeScript, React 17, Fluent UI 8, SPFx 1.23.2	Kundens SharePoint Online/Teams	Användargränssnitt för alla roller
Teams-app	Teams manifest v1.19, versionslåst tillsammans med SPFx-lösningen och ApiVersion.Current (stämplad av CI)	Kundens Teams-administrationscenter	Personlig app, konfigurerbar flik, aviseringar i aktivitetsflödet med djuplänkning
Web API	C#/ASP.NET Core 10, .NET 10 (~103 controllers, ~124 tjänstegränssnitt)	Kundens Azure App Service (Linux)	Affärslogik, dataåtkomst, dokumentbearbetning
Databas	SQL Server (DacPac)	Kundens Azure SQL Database	Relationsdatalager (221 tabeller, 3 410 fält)
Blob Storage	Azure Blob Storage	Kundens Azure Storage-konto	Dokumentfillagring
Övervakning	Application Insights + Log Analytics	Kundens Azure-prenumeration	Telemetri, diagnostik, larm
AI Search (valfri)	Azure AI Search	Kundens Azure-prenumeration	Fritextsökning i dokumentinnehåll samt semantisk vektorsökning (dokument- och ärendeindex); etableras endast när deployAiSearch=true
Azure OpenAI (valfri)	Azure OpenAI Service	Kundens Azure-prenumeration	AI Assist — grundade utkast, förslag, semantisk sökning, ärendeassistent (Fråga AccessPoint); autentisering via hanterad identitet (inga API-nycklar), etableras endast när AI Assist är driftsatt
Document Intelligence (valfri)	Azure AI Document Intelligence (prebuilt-read)	Kundens Azure-prenumeration	OCR för bildbaserade skanningar som förser innehållssökning, dubblettidentifiering, sammanfattningar och maskeringsförslag; autentisering via hanterad identitet, etableras endast när deployDocumentIntelligence=true

Vad utgivaren driver

Tjänst	Syfte
Realizer Platform	Licensvalidering, proxy för Teams-aviseringar, SPFx API-URL-identifiering, den smarta routern för Teams personliga flik samt sidan för att slutföra konfigurationen efter driftsättning (ingen kunddata överförs)
AppSource-listning	Distribution av SPFx-paket
Distributionsmall	Bicep/ARM-mall för Azure-backenden, distribueras med ett klick från Azure-portalen till kundens prenumeration
Teams App Package	Distribution av Teams-manifest (sidoladdning eller organisationens appbutik)

Ingen kunddata överförs till eller lagras av någon tjänst som drivs av utgivaren.

Funktionella moduler

Alla moduler körs inom samma Web API/SPFx-webbdel och delar en gemensam kärna för identitet, RBAC, kommentarer, aviseringar, Min dag, granskning, tidrapportering, granskningsarbetsflöde och rapportering. Var och en är datadriven via Jurisdiktionspaket.

Modul	Sammanfattning
Förfrågningar (ATIP/SAR)	Mottagning av förfrågan → tilldelning till förvaltare → insamling → svar. Konfigurerbara typer, statusar, numrering, kalendrar och SLA:er.
Dokument och maskering	Facetterad dokumentarbetsyta: taggar, mappar, e-postfamiljer, lässpårning, sparade vyer, beslutsbaserad dubblettidentifiering, Syncfusion-förhandsgranskning, maskeringsflöde med undantag och XFDF-tur och retur, mönster för sök och maskera, regelbaserade och AI-genererade maskeringsförslag, återanvändning av tidigare förfrågans maskeringar, paketering av svar med brevhuvudsammanslagning.
Sökande/kontakter	Fullvärdig återanvändbar identitet för sökande, styrning av mottagningsflödet, arbetsytan för uppförande (grundlöst eller trakasserande beteende), avgifter och verifiering, sammanslagning; samråd; korrespondensverktyg med brandvägg för personuppgifter.
Integritetsbedömningar	Konfigurerbar motor för PIA, AIA och säkerhet: mallar, screeningformulär, avsnittstilldelning, poängsättning/nivåindelning, riskregister, avslutnings-/tillsynsmyndighetssammanfattningar.
Integritetsincidenter/personuppgiftsincidenter	Mottagning av incidenter, begränsning, skaderiskbedömning, regler för anmälan om personuppgiftsincidenter per regelverk, åtgärdande.
Klagomål och överklaganden	Klagomålets livscykel: parter, lagstadgade tidsfrister, tillåtlighet, utredning, granskning av yttranden.
Risk och åtaganden	Riskregister enligt ISO 31000 med riskaptit, KRI:er och åtgärdsuppgifter; register över åtaganden med frekvens och avstämningar.
ROPA/integritetsobjekt	Återanvändbara program/system med GDPR Article 30-register och registerexport.
Granskningar	Konfigurerbar motor för sekventiell/parallell granskning och godkännande, återanvänd över alla ärendetyper.
Rapportering och granskning	Fördefinierade rapporter, katalogstyrd rapportredigerare (Report Studio-instrumentpaneler), statistiska årsrapporter, SLA- och ledningsinstrumentpaneler, hash-kedjad granskningsliggare och domstolsklara ärenderevisionsexporter.
AI Assist (valfri)	Azure OpenAI-baserade förslag och utkast: sammanfattningar, maskeringsförslag, grundade utkast, mottagningstriage, förslag för förvaltare, förifyllnad och konsekvenskontroller för bedömningar, semantisk sökning och dubbletter, en lagstiftningsmedveten ärendeassistent — Fråga AccessPoint (klickbara hänvisningar, förbered ett brevutkast, sparade konversationer) — plus en Min ärendemängd-/portföljassistent, en paketifylld jurisdiktionshandbok, Fråga AccessPoint-rapportering, daglig sammanfattning och sammanfattning vid återkomst, riskportfölj och uppförandeanalys. Reglage per klientorganisation för varje funktion; endast metadata loggas (assistenten kan dessutom spara ägarprivata transkript).
Konfiguration och plattform	Import av jurisdiktionspaket (1 Universal Baseline-paket + 106 jurisdiktionspaket, inklusive typspecifika automatiska statusar för underförstått avslag och valfri AI-grundning), klientinställningar, anpassade roller/behörigheter, funktionsväxlar, anpassade fält, översättningstabeller för 11 språk.

Distributionsmodell

AccessPoint använder en delad distributionsmodell. SPFx-webbdelen installeras från Microsoft AppSource (eller en klientorganisations appkatalog), Teams-apppaketet installeras via sidoladdning eller organisationens appbutik, och Azure-backend distribueras till kundens egen prenumeration på ett av två sätt:

• Azure-portalen (rekommenderas) – distribution med ett klick av alla Azure-resurser (App Service, SQL, Blob Storage, Application Insights, plus de valfria resurserna AI Search/Azure OpenAI/Document Intelligence) via ARM/Bicep. API:et distribueras med zipdeploy under ARM-distributionen; koden hämtas en gång från utgivarens CDN och lagras i kundens App Service, utan externt beroende vid drift. Ett obligatoriskt val av driftsättningstyp skyddar omdistributioner: Ny installation skapar SQL-servern Entra-först (den driftsättande huvudmannen blir den första Entra-administratören, med enbart Entra-autentisering från start — det finns aldrig några SQL-autentiseringsuppgifter), medan Uppgradera befintlig installation bevarar operatörens programinställningar och lämnar databasåtkomsten orörd. Kunden behåller fullt ägandeskap av resursgruppen.
• Bicep-mall + PowerShell-skript (manuellt) – för organisationer med strikta ändringsrutiner. En Deploy to Azure-knapp eller Deploy-AccessPoint.ps1 distribuerar infrastrukturen, återbekräftar Entra-only-autentisering för SQL (en säkerhetsspärr — mallen tillämpar den redan), beviljar Microsoft Graph-behörigheter till den hanterade identiteten (skriptmotsvarigheten till utgivarens sida för att slutföra konfigurationen), konfigurerar den valfria SharePoint-lagringsentiteten för API-URL-åsidosättning och godkänner SPFx:s API-behörighetsförfrågningar. Varje steg kan hoppas över separat.

Graph-behörigheter beviljas normalt via utgivarens sida för att slutföra konfigurationen — driftsättningen ger ut en utdata finishSetupUrl som en Entra-administratör hos kunden öppnar för att bevilja varje behörighet den hanterade identiteten behöver i en enda idempotent omgång (körs igen efter uppgraderingar för att fånga upp nya behörigheter).

Distributionen är säkerhetshärdad som standard: TLS 1.3, FTPS inaktiverat, grundläggande autentisering för SCM/FTP inaktiverad, HTTP/2 aktiverat och Microsoft Defender for SQL påslaget som standard (kan väljas bort). API:et bäddar in sin databas-DacPac och tillämpar den vid uppstart via en migreringstjänst som använder DacServices.Deploy(upgradeExisting: true) – utan effekt om schemat redan är aktuellt, och en additiv, icke-destruktiv delta-uppdatering efter en schemaändring (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). Migreringsresultatet visas via /api/health. Efter distributionen ger en administratör samtycke för Realizer enterprise-appen (Teams-aviseringar), konfigurerar avsändarens brevlåda och importerar ett jurisdiktionspaket.

Autentisering och identitet

AccessPoint använder Microsoft Entra ID som sin enda identitetsleverantör. Det finns inga applikationsspecifika användarkonton eller lösenord. SPFx-webbdelen hämtar en JWT för API-audiensen via AadHttpClient; API:et validerar utfärdare, audience, signatur och utgångsdatum vid varje förfrågan. MFA- och Villkorsstyrd åtkomst-policyer (Conditional Access) som konfigurerats i klientorganisationen tillämpas fullt ut.

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ärde
Identitetsleverantör	Microsoft Entra ID (Azure AD)
Protokoll	OAuth 2.0/OpenID Connect
Tokentyp	JWT Bearer
Audience	api://<client-id> och <client-id> (både v1- och v2-token accepteras)
Issuer	Valfri Entra-klientorganisations utfärdare — formaten https://login.microsoftonline.com/{tenantId}/v2.0 (v2) och https://sts.windows.net/{tenantId}/ (v1) valideras; tokenens tid-anspråk styr avgränsningen per klientorganisation
Appregistrering	Utgivarstyrd app för flera klientorganisationer, samtyckt per kundklientorganisation (ingen appregistrering per kund att hantera eller rotera); exponerat scope access_as_user; ingen klienthemlighet. Isolering mellan kundklientorganisationer upprätthålls av det validerade tid-anspråket samt en licens-/prenumerationskontroll

Hanterad identitet

App Service använder en systemtilldelad hanterad identitet för att autentisera mot backend-tjänster, så inga klienthemligheter eller certifikat lagras i applikationen:

• Azure SQL Database – Entra-only-autentisering (servern skapas Entra-först; det finns aldrig några SQL-autentiseringsuppgifter)
• Azure Blob Storage – DefaultAzureCredential (hanterad identitet i produktion)
• Microsoft Graph API – ManagedIdentityCredential med applikationsbehörigheter
• Valfria AI-resurser (AI Search, Azure OpenAI, Document Intelligence) – enbart hanterad identitet, med lokal autentisering/nyckelautentisering inaktiverad

Autentiseringsuppgifter för hanterad identitet roteras automatiskt av Azure.

Auktorisering och RBAC

AccessPoint implementerar en detaljerad, klientkonfigurerbar behörighetsmodell som lagras i Azure SQL och tillämpas i API-lagret vid varje förfrågan: en produktdefinierad katalog av atomära behörighetskoder (t.ex. request.modify, document.view, redaction.approve, request.view.pii) grupperas i roller, och varje controller-åtgärd spärras med en behörighetskod.

Rolltyp	Roller	Anmärkningar
Systemroll	Administratör (den enda inbyggda stående rollen)	Ger alla behörigheter i katalogen — beräknas utifrån katalogen, inte databasfrön — så den kan aldrig låsas ute; oföränderlig och kan inte tas bort.
Relationsroller	Granskare, Förvaltare, Medarbetare, Läsare, Rådgivare	Produktdefinierade behörighetspaket som tilldelas automatiskt och per mål utifrån arbets-/samarbetsrelationer (förvaltaruppdrag, medarbetaruppgift, granskning, rådgivar-/läsarmedlemskap). Kan inte tilldelas direkt, är begränsade till den anknutna posten och innehåller aldrig sökandens personuppgifter.
Klientroller	t.ex. Request Coordinator (levereras via Universal Baseline-paketet), samt eventuella anpassade roller	Fullt redigerbara behörighetspaket som hanteras under Inställningar > Roller och behörigheter. Samordnar-/handläggarroller är helt definierade av klientorganisationen — den paketlevererade Request Coordinator är den de facto-roll som fungerar som handläggare för tillgång och integritet.

Roll	Ser sökandens personuppgifter	Typisk åtkomst	Typisk användare
Administratör	Ja	Allt (alla behörigheter i katalogen)	IT-admin, systemägare
Request Coordinator (klientroll)	Ja	Hanterar förfrågningar, uppdrag, maskeringar, korrespondens	Handläggare för åtkomst och integritet
Granskare	Nej	Läsa samt flagga/lösa maskeringsfrågor på förfrågningar under granskning	Juridisk rådgivare, kvalitetssäkring
Rådgivare	Nej	Läsa samt visa/flagga maskeringar (aldrig tillämpa eller godkänna)	Konsulterande jurist, ämnesexpert
Förvaltare	Nej	Egna uppdrag och deras dokument	Avdelningens arkivansvarige
Medarbetare	Nej	Egna uppgifter och deras dokument	Ämnesexpert
Läsare	Nej	Skrivskyddad åtkomst till anknutna förfrågningar och delade dokument	Tillsyn, granskning

Tillämpningspunkter:

1. Attributen [RequirePermission(code)] — en dynamisk policyleverantör kopplar varje controller-åtgärd till en behörighetskod i katalogen
2. PermissionService — löser ut den anropandes faktiska behörigheter (stående roller kombinerade med relationsbaserade tilldelningar per mål), med objektbegränsade kontroller på förfrågnings-/dokument-/uppdrags-/uppgiftsnivå
3. Ägandekontroller på resursnivå — t.ex. kan en Medarbetare bara komma åt sina egna uppgifter; en Förvaltare bara sina egna uppdrag
4. PiiFilterMiddleware — tar bort sökandens personuppgiftsfält från JSON-svar för varje anropande som inte har behörigheten att visa sökandens personuppgifter

Alla API-skrivändpunkter tillämpar behörigheter server-side på controllernivå. Dokumentomklassificering är omfångsmedveten — det är den användare som samlade in ett dokument som kan omklassificera det — och när en förfrågan väl är avslutad returnerar ändringar i dess objektgraf HTTP 409, med ett litet antal avsiktliga undantag (korrespondens efter avslutning, radering enligt bevarandepolicy och återöppning). Stående rolltilldelningar är omfångsbestämda (globalt, förfrågan, uppdrag eller uppgift), kan vara tidsbegränsade, och relationsroller skrivs aldrig som stående tilldelningar — de härleds per mål från de underliggande arbetsposterna. Den första användaren som får åtkomst till systemet tilldelas automatiskt rollen Administratör, och en spärr på serversidan förhindrar borttagning av den sista aktiva administratören.

Dataresidens och datasuveränitet

All data lagras i kundens Azure-klientorganisation i den region som väljs vid distribution. Ingen data överförs till eller lagras i andra regioner om inte kunden uttryckligen konfigurerar Azure geo-replikering.

Kanadensiska federala myndigheter: För GC-specifika krav på dataresidens, kartläggning av ITSG-33-kontroller och efterlevnad av GC Cloud Guardrails, se Referens för GC-säkerhetskontroller.

Kundens dataplatser

Datatyp	Lagringsplats	Kontrolleras av
Förfrågningsposter, användardata, granskningsspår	Azure SQL Database	Kundens Azure-prenumeration
Uppladdade dokument	Azure Blob Storage	Kundens Azure-prenumeration
Applikationstelemetri	Application Insights/Log Analytics	Kundens Azure-prenumeration
SPFx-webbdelens tillgångar	SharePoint CDN	Kundens M365-klientorganisation
API-URL-åsidosättning (valfritt)	SharePoint Tenant Storage Entity	Kundens M365-klientorganisation (primär identifiering sker via utgivarens API-identifieringsslutpunkt)
AI-sökindex, sammanfattningar, OCR-utdata (valfri)	Azure AI Search/Azure SQL	Kundens Azure-prenumeration

Vad som passerar klientorganisationens gränser

Dataflöde	Riktning	Vad som överförs	Syfte
Licensvalidering	API → utgivarens plattform	Entra-token för hanterad identitet (tokenens tid-anspråk identifierar klientorganisationen), API-version samt API:ets egen bas-URL (självregistrering för identifiering av webbdelen)	Validera aktiv prenumeration; svaret bär också med sig den senast publicerade AccessPoint-versionen, så att panelen Grundkonfiguration kan visa en avisering om "Uppdatering tillgänglig" (enbart versionsnummer — ingen använda- eller ärendedata)
Identifiering av API-URL	SPFx → utgivarens plattform	Bearer-token (endast anspråk om klientorganisations-ID)	Slå upp kundens API-bas-URL när ingen åsidosättning via lagringsentitet är angiven
E-postaviseringar	API → Microsoft Graph	E-postinnehåll via Mail.Send	Skicka aviseringar från delad brevlåda
Teams-aviseringar (valfritt — kan minimeras/elimineras)	API → utgivarens plattform → Microsoft Graph	Aktivitetstyp, mottagar- + klientorganisations-GUID, aviseringens titel/förhandsgranskningstext, den agerande användarens namn, förfrågningsnummer, post-ID (djuplänk)	Skicka aviseringar i Teams aktivitetsflöde (proxat genom utgivarens flerklients-enterprise-app eftersom sendActivityNotification måste anropas av appen som äger Teams-manifestet). Detta är den enda aviseringskanal som lämnar klientorganisationen — e-post och appflödet levererar samma meddelanden inom klientorganisationen. Se Delning av Teams-aviseringsdata
Uppslag av användarprofil	SPFx → Microsoft Graph	Användarsökfrågor	Personväljare, användarupplösning

Vad som aldrig lämnar klientorganisationen

• Förfrågningsposter och den sökandes personuppgifter
• Uppladdade dokument
• Granskningshistorik
• Konfigurationsdata (förfrågningstyper, mallar, numrering)
• Rolltilldelningar
• AI Assist-prompter och -svar — när AI Assist är driftsatt körs Azure OpenAI-resursen i kundens egen prenumeration och region; Microsoft tränar inte modeller på innehållet, och prompt-/svarsinnehåll lagras inte (endast användningsmetadata, för budgetmätaren och ärenderevisionsexportens redovisning av AI-medverkan)
• Appflödet och e-post-/Outlook-aviseringar — appflödet levereras från kundens egen API, och e-post skickas från kundens egen delade brevlåda via Mail.Send. Ingen av dem passerar utgivaren. Endast det valfria Teams-aktivitetsflödet skickar någon data utanför klientorganisationen, och även det kan minimeras eller elimineras (nedan)

Delning av Teams-aviseringsdata (valfritt)

I linje med löftet om datasuveränitet är den enda klientorganisationsdata som lämnar gränsen för aviseringar en valfri Teams-aktivitetspayload — och den kan minimeras eller tas bort helt. Varje avisering levereras på upp till tre kanaler; två är alltid inom klientorganisationen (appflödet, som levereras från kundens API, och e-post/Outlook, som skickas från kundens egen delade brevlåda). Teams aktivitetsflöde är en bekvämlighet: i standardläget POSTar kundens API en liten payload till utgivarens flerklients-app, som anropar Graph sendActivityNotification (vilket måste anropas av appen som äger Teams-manifestet). Utgivaren lagrar ingenting av det och loggar endast mottagar- och klientorganisations-GUID.

Fält i standardpayloaden (utgivarrelä) för Teams — och vad växeln Minimera tar bort:

Fält	Innehåller	Personuppgifter?	Tas bort av Minimera?
tenantId / recipientUserId	Klientorganisations- och mottagar-GUID i Entra	Nej — identifierare	Nej (dirigering)
activityType	Fast manifest-enum (t.ex. assignmentCreated)	Nej	Nej
previewText / topicText	Förhandsgranskning + titel (uppdrags-/uppgiftsnamn, aviseringstext)	Eventuellt (fritext)	Ja → platshållare
actorName	Den agerande medarbetarens visningsnamn	Ja — personnamn	Ja → "AccessPoint"
requestNumber	Förfrågans referenskod	Nej — referens	Nej (sammanhang)
relatedEntity + relatedRecordId	Posttyp + GUID (djuplänk)	Nej — identifierare	Nej (djuplänk)

Den sökandes personuppgifter finns aldrig i payloaden — det finns inget fält för den sökandes namn/e-post, och aviseringar till förvaltare/medarbetare är personuppgiftsblankade redan uppströms oavsett. Två kontroller stramar åt detta ytterligare:

• Minimera (Notifications:TeamsMinimalPayload, en klientorganisationsväxel) ersätter previewText, topicText och actorName med neutrala platshållare, så att namn, titlar och fritext aldrig lämnar klientorganisationen — endast identifierare för dirigering/djuplänkning gör det. Ingen manifeständring krävs.
• Eliminera (Notifications:TeamsRelayMode=Direct) gör att kundens API själv anropar Graph sendActivityNotification med sin hanterade identitet, så att ingen payload någonsin når utgivaren. Det kräver approllen TeamsActivity.Send på API:ets hanterade identitet och att Teams-manifestets webApplicationInfo.id pekar på kundens egen app — se Driftsättningsguiden.

Läge	Payload till utgivaren	Personuppgifter/fritext lämnar klientorganisationen	Installationsinsats
Standardrelä	Ja (fälten ovan)	Namn/titlar, om inte minimerat	Ingen
Växeln Minimera	Ja (endast identifierare)	Ingen	En växel
Direkt (självhostat) relä	Ingen	Ingen	MI-beviljande + manifestredigering
Teams inaktiverat	Ingen	Ingen (endast e-post + appflöde)	Ingen

Kryptering

Under överföring

Anslutning	Protokoll	Lägsta TLS
Webbläsare → App Service	HTTPS (tillämpat, httpsOnly: true)	TLS 1.3
SPFx → App Service	HTTPS (tillämpat av SharePoint-kontext)	TLS 1.3
App Service → Azure SQL	TDS med kryptering (Encrypt=True)	TLS 1.2+
App Service → Blob Storage	HTTPS (hanterad identitet)	TLS 1.2+
App Service → Microsoft Graph	HTTPS	TLS 1.2+

App Service tillämpar TLS 1.3 som lägsta nivå vid ingången (TLS 1.0/1.1/1.2 avvisas); utgående anslutningar till Azure-backend-tjänster förhandlar TLS 1.2 eller högre.

I vila

Datalager	Kryptering	Nyckelhantering
Azure SQL Database	Transparent Data Encryption (TDE)	Microsoft-hanterade nycklar (standard) eller kundhanterade nycklar (CMK)
Azure Blob Storage	Storage Service Encryption (SSE), AES-256	Microsoft-hanterade nycklar (standard) eller kundhanterade nycklar (CMK)
Application Insights	Plattformskryptering	Microsoft-hanterade nycklar

På applikationsnivå

Funktion	Mekanism
Token för dokumentvisning	ASP.NET Core Data Protection (WOPI-liknande token, 15 minuters TTL, kontroll mot klientorganisationen vid varje anonymt visningsanrop)
E-signaturer för intygande	SHA-256-hash av undertecknare och tidsstämpel lagrad i granskningsfält

Inbyggt integritetsskydd

AccessPoint implementerar strukturella integritetskontroller som tillämpas i API-lagret, inte bara i användargränssnittet.

PII-filtermiddleware

En middleware på svarsnivå fångar upp alla JSON-svar och tar bort personuppgiftsfält för varje anropande som inte har behörigheten att visa sökandens personuppgifter (Förvaltare, Medarbetare, Läsare, Granskare och Rådgivare har den aldrig), server-side, oavsett vad klienten begär. Fält som tas bort: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, samt fält för ombuds identitet/kontaktuppgifter och anteckningar om identitetsverifiering.

Blankning av personuppgifter i aviseringar

När aviseringar skickas till förvaltare eller medarbetare ersätts den sökandes personuppgifter med platshållartext i själva aviseringsinnehållet – även om aviseringsmallen innehåller sammanslagningsfält för personuppgifter.

Isolering av förvaltare/medarbetare

• Förvaltare ser bara sina tilldelade förfrågningar och arbetar utifrån sanerade instruktioner
• Medarbetare ser bara sina tilldelade uppgifter
• Ingen av rollerna kan söka, bläddra i eller komma åt förfrågningar utanför sitt omfång

Loggning, övervakning och granskning

Application Insights

All API-telemetri skickas till kundens Application Insights-instans:

Signal	Vad som fångas
Förfrågningsspårningar	HTTP-metod, sökväg, statuskod, varaktighet, korrelations-ID
Beroendespårning	SQL-frågor, Blob-åtgärder, Graph API-anrop (varaktighet, lyckat/misslyckat)
Undantag	Ohanterade undantag med stackspårningar
Anpassade mätvärden	Bearbetningstider för förfrågningar, varaktighet för dokumentkonvertering

Granskningsspår

AccessPoint upprätthåller ett omfattande granskningsspår i tabellen AuditHistory (Azure SQL), som registrerar entitetstyp, entitets-ID, åtgärd (Create, Update, Delete, StatusChange), fältnamn, gamla/nya värden, en valfri ändringsorsak (registreras vid statusövergångar som avslutning och återöppning), den autentiserade användaren och en UTC-tidsstämpel. Granskningsposter är oföränderliga — de kan inte ändras eller tas bort genom API:et.

Hash-kedjad granskningsliggare

Utöver granskningsspåret på fältnivå registrerar en manipulationssäker AuditLedger med endast tillägg (SHA-256-hashkedja) åtgärder över alla moduler. Integriteten kan verifieras server-side, och en domstolsklar ärenderevisionsexport (tidigare kallad "bevispaket") kan genereras för en förfrågan.

Optimistisk samtidighet

Entiteter med hög samtidig åtkomst (Requests, Documents, CustodianAssignments) bär vardera en samtidighetstoken av typen SQL Server ROWVERSION. Klienten skickar tillbaka radversionen vid uppdatering; om en annan skrivare har ändrat raden under tiden avvisas sparandet med HTTP 409 ("Concurrent edit detected") i stället för att skriva över tyst.

Gallringslogg

En motor, RetentionService, gallrar bort inaktuella poster över fem register — förfrågningar, bedömningar, incidenter, klagomål och fristående integritetsrisker — styrd av ett kvarhållandepar per typ, RetentionPeriodMonths + RetentionStartPoint (NULL = bevaras på obestämd tid, standardvärdet). Poster som aldrig får bli gallringsbara utesluts genom konstruktion (en bedömning som är I kraft, en accepterad risk, en risk kopplad till ett ärende), och en utgången post som ett annat öppet ärende fortfarande beror på nekas server-side; gallringsbarheten omprövas vid gallringstillfället. När en post gallras tar motorn även bort dokumentblobbar, konverterade PDF-filer, anteckningar och exportpaket från Blob Storage utöver databasposterna. RetentionPurgeLog registrerar vad som gallrades, när och av vem — EntityName anger vilket register posten kom från, tillsammans med en ögonblicksbild av dess nummer, typ, avslutsdatum och antal dokument — ett efterlevnadsspår som finns kvar efter att uppgifterna tagits bort och som aldrig gallras bort självt.

Log Analytics och larm

Application Insights backas av en Log Analytics-arbetsyta med konfigurerbar kvarhållning (standard 90 dagar; konfigurerbart 30–730 dagar). Data kan exporteras till Microsoft Sentinel eller ett befintligt SIEM. Bicep-distributionen innehåller två standardlarm för mätvärden på App Service:

Larm	Allvarlighetsgrad	Villkor	Fönster
Serverfel	2 (Varning)	Antal HTTP 5xx > 5	5 minuter
Hög latens	3 (Informationell)	Genomsnittlig svarstid > 5 sekunder	15 minuter

Kunder kan anpassa tröskelvärden och lägga till åtgärdsgrupper (e-post, SMS, webhook) i Azure-portalen.