Översikt över den tekniska arkitekturen för IT-team som utvärderar AccessPoint

Last updated: July 12, 2026 by Steve

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 (v1.4.1).

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

Alla moduler är konfigurationspaketstyrda, 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 + 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)
        └──────────────────────┘

Komponentinventering

Komponent Teknik Driftsätts till Syfte
SPFx-webbdel TypeScript, React 17, Fluent UI 8, SPFx 1.22.1 Kundens SharePoint Online/Teams Användargränssnitt för alla roller
Teams-app Teams manifest v1.19, appversion 1.0.0 Kundens Teams-administrationscenter Personlig app, konfigurerbar flik, aviseringar i aktivitetsflödet med djuplänkning
Web API C#/ASP.NET Core 10, .NET 10 (~87 controllers, ~88 tjänster) Kundens Azure App Service (Linux) Affärslogik, dataåtkomst, dokumentbearbetning
Databas SQL Server (DacPac) Kundens Azure SQL Database Relationsdatalager (~186 tabeller, ~2 900 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; etableras endast när deployAiSearch=true

Vad utgivaren driver

Tjänst Syfte
Realizer Platform Utfärdande och validering av licensnycklar (ingen kunddata överförs)
AppSource-listning Distribution av SPFx-paket
Azure Marketplace-listning Distributionsmall för Azure-infrastruktur
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 konfigurationspaket.

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, e-postfamiljer, lässpårning, sparade vyer, Syncfusion-förhandsgranskning, maskeringsflöde med undantag och XFDF-tur och retur, paketering av svar.
Sökande/kontakter Fullvärdig återanvändbar identitet för sökande, styrning av mottagningsflödet, 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, delegering av avsnitt, 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, anpassningsbar rapportbyggare, statistiska årsrapporter, SLA- och ledningsinstrumentpaneler, hash-kedjad granskningsliggare och domstolsklara bevispaket.
Konfiguration och plattform Import av konfigurationspaket, 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) 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. 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, konfigurerar Entra-only-autentisering för SQL, beviljar Microsoft Graph-behörigheter till den hanterade identiteten, konfigurerar SharePoints klientlagringsentiteter och godkänner SPFx:s API-behörighetsförfrågningar. Varje steg kan hoppas över separat.

Distributionen är säkerhetshärdad som standard: TLS 1.3, FTPS inaktiverat, grundläggande autentisering för SCM/FTP inaktiverad och HTTP/2 aktiverat. 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 jurisdiktionsspecifikt konfigurationspaket.

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. RoleAuthorization:   │
     │                              │     Check UserRoles table│
     │                              │                          │
     │     ◄── 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 https://login.microsoftonline.com/{tenantId}/v2.0 och https://sts.windows.net/{tenantId}/
Appregistrering Enkel klientorganisation (AzureADMyOrg); exponerat scope access_as_user; ingen klienthemlighet

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 (SQL-lösenordsautentisering är inaktiverad)
  • Azure Blob Storage – DefaultAzureCredential (hanterad identitet i produktion)
  • Microsoft Graph API – ManagedIdentityCredential med applikationsbehörigheter

Autentiseringsuppgifter för hanterad identitet roteras automatiskt av Azure.

Auktorisering och RBAC

AccessPoint implementerar rollbaserad åtkomstkontroll på applikationsnivå, lagrad i Azure SQL och tillämpad i API-lagret vid varje förfrågan.

Roll Ser den sökandes personuppgifter Hanterar förfrågningar Hanterar tilldelningar Skickar in dokument Typisk användare
Administratör Ja Endast konfiguration Nej Nej IT-admin, systemägare
SAO Ja Ja Ja Nej Handläggare för åtkomst och integritet
Granskare Ja Skrivskyddat Skrivskyddat Nej Juridisk rådgivare, kvalitetssäkring
Förvaltare Nej Nej Egna tilldelningar Nej Avdelningens arkivansvarige
Medarbetare Nej Nej Nej Egna uppgifter Ämnesexpert
Läsare Nej Skrivskyddat Skrivskyddat Nej Tillsyn, granskning

Tillämpningspunkter:

  1. API-auktoriseringspolicyer — ASP.NET Core [Authorize(Policy = "...")]-attribut på varje controller-åtgärd
  2. RoleAuthorizationHandler — kontrollerar tabellen UserRoles för den autentiserade användarens rollmedlemskap
  3. ResourceOwnerAuthorizationHandler — validerar ägandeskap på resursnivå (t.ex. kan en medarbetare bara komma åt sina egna uppgifter)
  4. PiiFilterMiddleware — tar bort den sökandes personuppgiftsfält från JSON-svar för begränsade roller (förvaltare, medarbetare, läsare)

Alla API-skrivändpunkter tillämpar roller 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). Roller är omfångsbestämda och kan begränsas till specifika resurser (globalt omfång, förfrågningsomfång, tilldelningsomfång eller uppgiftsomfång). Den första användaren som får åtkomst till systemet tilldelas automatiskt både rollerna administratör och SAO.

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
Klientkonfiguration (API-URL, klient-ID) SharePoint Tenant Storage Entities Kundens M365-klientorganisation

Vad som passerar klientorganisationens gränser

Dataflöde Riktning Vad som överförs Syfte
Licensvalidering API → utgivarens plattform Licensnyckel (opak sträng), klientorganisations-ID Validera aktiv prenumeration
E-postaviseringar API → Microsoft Graph E-postinnehåll via Mail.Send Skicka aviseringar från delad brevlåda
Teams-aviseringar API → utgivarens plattform → Microsoft Graph Aktivitetstyp, förhandsgranskningstext, mottagar-ID, mallparametrar Skicka aviseringar i Teams aktivitetsflöde (proxat genom utgivarens flerklients-enterprise-app eftersom sendActivityNotification måste anropas av appen som äger Teams-manifestet)
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

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 användare med begränsade roller (förvaltare, medarbetare, läsare), server-side, oavsett vad klienten begär. Fält som tas bort: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

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 ett domstolsklart bevispaket kan exporteras 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.

Raderingslogg för bevarande

När poster raderas enligt bevarandepolicy tar raderingen bort dokumentblobbar, konverterade PDF-filer, anteckningar och exportpaket från Blob Storage utöver databasposterna. Tabellen RetentionPurgeLog registrerar vad som raderades, när och av vem – ett spår av efterlevnadskvalitet som finns kvar efter att uppgifterna tagits bort.

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.

←
Previous Komma igång med AccessPoint
Next Referens för GC-säkerhetskontroller
→