Kartläggning av ITSG-33-kontroller, efterlevnad av GC Cloud Guardrails och referens för SA&A för kanadensiska federala myndigheter
Last updated: August 06, 2026 by Steve
Referens för GC-säkerhetskontroller
Denna sida riktar sig till kanadensiska federala myndigheter som genomför en säkerhetsbedömning och auktorisering (Security Assessment and Authorization, SA&A) för AccessPoint. Den kartlägger AccessPoints säkerhetskontroller mot ramverket ITSG-33, GC Cloud Guardrails och relaterade TBS-/CCCS-krav.
För den fullständiga tekniska arkitekturen, se sidan Teknisk arkitektur.
Sammanfattning av arkitekturen för bedömare
AccessPoint körs helt inom myndighetens egen Microsoft 365- och Azure-klientorganisation. De säkerhetsrelevanta fakta som ligger till grund för kartläggningarna nedan är:
- Backend – ett ASP.NET Core Web API på Azure App Service (Linux), Azure SQL Database och Azure Blob Storage, samtliga distribuerade i myndighetens egen Azure-prenumeration.
- Identitet – Microsoft Entra ID är den enda identitetsleverantören (JWT-bearer-token). App Service autentiserar mot backend-tjänster med en systemtilldelad hanterad identitet; Azure SQL skapas Entra-först med enbart Entra-autentisering — det finns aldrig några SQL-autentiseringsuppgifter, så det finns inget att lagra, rotera eller inaktivera.
- Åtkomstkontroll – detaljerad, behörighetsbaserad åtkomstkontroll som tillämpas server-side vid varje API-ändpunkt: en produktdefinierad katalog av atomära behörighetskoder grupperas i klientkonfigurerbara roller, och PII-filtermiddleware tar bort den sökandes personuppgifter från svar för varje anropande som inte har behörigheten att visa sökandens personuppgifter.
- Kryptering – TLS 1.3 vid App Service-ingången (TLS 1.2+ på Azure SQL och Blob Storage); TDE på databasen och AES-256 SSE på Blob Storage i vila.
- Granskning – ett oföränderligt granskningsspår på fältnivå plus en hash-kedjad (SHA-256), tilläggsendast granskningsliggare med domstolsklara ärenderevisionsexporter (tidigare kallade "bevispaket") per förfrågan; en valfri WORM-blobbehållare (write-once) kan göra exporterad bevisning oföränderlig på lagringsnivå. Telemetri i Application Insights/Log Analytics med standardlarmregler för mätvärden, samt Microsoft Defender for SQL aktiverat som standard.
- Utgivarens gräns – licensvalidering autentiseras med en Entra-token för hanterad identitet (tokenens anspråk om klientorganisations-ID identifierar klientorganisationen) och överför endast klientorganisations-ID, API-version samt API:ets egen bas-URL; 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). Ingen kunddata om ärenden överförs till eller lagras av utgivaren. Den enda valfria utgående kanalen är payloaden för Teams-aktivitetsflödesaviseringar (dirigerings-GUID samt, som standard, aviseringens titel/förhandsgranskning och den agerande användarens namn — aldrig den sökandes personuppgifter), som reläas genom utgivarens flerklients-app eftersom Graph kräver att appen som äger manifestet skickar den. En myndighet kan minimera den (en växel tar bort namn och fritext och lämnar bara dirigeringsidentifierare) eller eliminera den helt (självhosta reläet så att ingenting når utgivaren); e-post och appflödet levererar samma meddelanden inom klientorganisationen. Se Delning av Teams-aviseringsdata.
Anpassning till GC:s säkerhetsramverk
| Ramverk | Hur AccessPoint anpassar sig |
|---|---|
| ITSG-33 (PBMM-profil) | Säkerhetskontroller kartlagda mot alla ITSG-33-familjer. Se Kartläggning av ITSG-33-kontrollfamiljer nedan. |
| GC Cloud Guardrails | Alla 13 obligatoriska skyddsåtgärder adresserade. Se tabellen Efterlevnad av GC Cloud Guardrails. |
| Policy on Government Security | Systemet är utformat för formell SA&A. Auktoriseringsgränsen definieras i avsnittet Auktoriseringsgräns nedan. |
| Directive on Security Management | Granskningsspår, åtkomstkontroll och funktioner för kontinuerlig övervakning stöder fortlöpande efterlevnad. |
| Directive on Service and Digital | Molnbaserad arkitektur i linje med GC:s molnförstadirektiv. Distribueras helt inom myndighetens befintliga M365- och Azure-klientorganisation. |
| CCCS Cloud Security Risk Management | Delat ansvar dokumenterat. Azures kanadensiska regioner är CCCS-bedömda för PBMM. |
Kanadensisk dataresidens
Vid driftsättningar för Government of Canada distribueras AccessPoint till kanadensiska Azure-regioner (Canada Central eller Canada East). All data — inklusive förfrågningsposter, uppladdade dokument, granskningsspår och telemetri — lagras inom den valda kanadensiska regionen. Ingen data överförs till eller lagras i regioner utanför Kanada om inte myndigheten uttryckligen konfigurerar Azure geo-replikering för detta.
Microsoft Azures kanadensiska regioner har bedömts av Canadian Centre for Cyber Security (CCCS) och är godkända för PBMM-arbetsbelastningar (Protected B, Medium Integrity, Medium Availability).
Vad PBMM innebär för AccessPoint
- Protected B — AccessPoint hanterar den sökandes personuppgifter (namn, e-post, telefon, adress) och potentiellt känsliga myndighetshandlingar. Applikationens PII-filtermiddleware, rollbaserade åtkomstkontroll och krypteringskontroller är utformade för Protected B-data.
- Medium Integrity — Alla dataändringar registreras i ett oföränderligt granskningsspår, förstärkt av en hash-kedjad granskningsliggare. Databasbegränsningar och validering på API-nivå skyddar mot obehörig ändring.
- Medium Availability — Applikationen är tillståndslös, med allt tillstånd i Azure SQL och Blob Storage. Azures plattforms-SLA:er och kundkonfigurerbar redundans stöder krav på medelhög tillgänglighet.
Kartläggning av ITSG-33-kontrollfamiljer
Tabellen nedan kartlägger varje ITSG-33-kontrollfamilj mot relevanta avsnitt på sidan Teknisk arkitektur. Använd detta som utgångspunkt när du utvärderar AccessPoint mot din myndighets PBMM-säkerhetskontrollprofil.
| ITSG-33-familj | Kontrollområde | Var det adresseras |
|---|---|---|
| AC — Access Control | Autentisering, auktorisering, minsta privilegium, server-side RBAC, PII-filtrering, sessionshantering | Autentisering och identitet, Auktorisering och RBAC, Inbyggt integritetsskydd |
| AU — Audit and Accountability | Loggning, oföränderligt granskningsspår, hash-kedjad liggare, övervakning, loggkvarhållning | Loggning, övervakning och granskning |
| CA — Security Assessment and Authorization | SA&A-process, systemgräns, kontinuerlig övervakning | Auktoriseringsgräns (denna sida); Plattformsöversikt; kontinuerlig övervakning via Loggning, övervakning och granskning |
| CM — Configuration Management | Baskonfiguration, ändringskontroll, härdade standardinställningar | Distributionsmodell (härdade standardinställningar, additiva DacPac-migreringar) |
| CP — Contingency Planning | Säkerhetskopiering, katastrofåterställning, verksamhetskontinuitet | Tillståndslös App Service (allt tillstånd i Azure SQL och Blob Storage); Azure-hanterade SQL-säkerhetskopior och Blob-redundans konfigureras av myndigheten — se Distributionsmodell |
| IA — Identification and Authentication | Entra ID som identitetsleverantör, MFA, hanterad identitet, Entra-only SQL-autentisering | Autentisering och identitet |
| IR — Incident Response | Incidenthantering, avisering, rapportering till CCCS | Oföränderligt granskningsspår, hash-kedjad liggare och Log Analytics stöder utredning — se Loggning, övervakning och granskning. Myndigheter rapporterar cyberhändelser till CCCS enligt GC:s krav. |
| MP — Media Protection | Kryptering av data i vila, mediasanering | Kryptering, Dataresidens och datasuveränitet |
| PE — Physical and Environmental Protection | Fysisk säkerhet för infrastrukturen | Azure CSP-ansvar — täcks av Microsofts CCCS-bedömning för PBMM |
| PL — Planning | Säkerhetsplaner, systemets auktoriseringsgräns | Plattformsöversikt; Auktoriseringsgräns (denna sida) |
| RA — Risk Assessment | Hot-/riskbedömning, sårbarhetsskanning | Myndighetsgenomförd VAPT och TRA (se Nyckeldokument att begära); Azure-plattformsskanning av Microsoft |
| SA — System and Services Acquisition | Leveranskedja, tredjepartsberoenden, leverantörspraxis | Komponentinventering, Vad utgivaren driver; fullständig beroendeförteckning tillgänglig på begäran |
| SC — System and Communications Protection | Kryptering under överföring, isolering mellan klientorganisationer, gränsskydd | Kryptering, Dataresidens och datasuveränitet. Distribution med en klientorganisation per kund och dedikerade resurser; myndigheter kan lägga till Private Endpoints, VNet-integration och WAF. |
| SI — System and Information Integrity | Patchning, sårbarhetshantering, integritet för indata | Distributionsmodell (härdade standardinställningar, additiva migreringar). OS/runtime patchas av Azure; applikationskod och beroenden patchas av utgivaren. |
Efterlevnad av GC Cloud Guardrails
Följande tabell kartlägger AccessPoints kontroller mot GC Cloud Guardrails – de obligatoriska minimikonfigurationerna för säkerhet vid GC:s molnadoption.
| Skyddsåtgärd | Hur AccessPoint adresserar den |
|---|---|
| 01 — Protect root/global admin accounts | AccessPoint använder eller kräver inte Global Admin-konton vid drift. Administratörsroller inom applikationen är separata från Azure/M365-administratörsroller. Den initiala distributionen kräver administratörsbehörigheter; löpande drift gör det inte. |
| 02 — Management of administrative privileges | Detaljerad, behörighetsbaserad åtkomstkontroll som tillämpas server-side i API-lagret vid varje förfrågan: atomära behörighetskoder grupperade i roller, där Administratör är den enda inbyggda rollen (en spärr på serversidan förhindrar borttagning av den sista aktiva administratören). Operativa roller är klientkonfigurerbara och separata från Administratör, och rolltilldelningar kan vara tidsbegränsade. App Service autentiserar via en systemtilldelad hanterad identitet utan lagrade autentiseringsuppgifter, och Azure SQL skapas Entra-först med enbart Entra-autentisering (det finns aldrig några SQL-autentiseringsuppgifter). Se Auktorisering och RBAC. |
| 03 — Cloud console access | AccessPoint använder inte Azure-portalen eller någon molnhanteringskonsol vid drift. Hantering av Azure-resurser förblir myndighetens ansvar. |
| 04 — Enterprise monitoring accounts | All telemetri lagras i kundens Application Insights- och Log Analytics-arbetsyta. Myndigheter kan ge CCCS/SSC skrivskyddad åtkomst enligt sina standardrutiner. Se Loggning, övervakning och granskning. |
| 05 — Data location | All data lagras i kundens Azure-klientorganisation i deras valda kanadensiska region (Canada Central eller Canada East) — inklusive de valfria resurserna AI Search, Azure OpenAI och Document Intelligence, som driftsätts i myndighetens egen prenumeration. Licensvalidering överför endast klientorganisations-ID (via en Entra-token för hanterad identitet), API-version samt API:ets egen bas-URL — ingen kunddata om ärenden överförs till eller lagras av utgivaren. Den enda valfria utgående kanalen, payloaden för Teams-aktivitetsflödesaviseringar, innehåller aldrig den sökandes personuppgifter och kan minimeras till dirigeringsidentifierare eller elimineras genom att självhosta reläet; e-post och appflödet levererar samma meddelanden inom klientorganisationen. Se Dataresidens och datasuveränitet och Delning av Teams-aviseringsdata. |
| 06 — Protection of data at rest | Azure SQL TDE och Azure Blob Storage SSE (AES-256) aktiverat som standard. Kundhanterade nycklar (CMK) stöds. Se Kryptering. |
| 07 — Protection of data in transit | TLS 1.3 tillämpas vid App Service-ingången (TLS 1.0/1.1/1.2 avvisas); TLS 1.2+ på Azure SQL och Blob Storage. Inga klartextändpunkter. Se Kryptering. |
| 08 — Segment and separate | Distribution med en klientorganisation per kund och dedikerade resurser — ingen delad beräkningskapacitet, lagring eller databas. Blob-sökvägar och databasfrågor är avgränsade per klientorganisation. Nätverkssegmentering (Private Endpoints, VNet-integration) kan läggas till. Se Dataresidens och datasuveränitet. |
| 09 — Network security services | Standarddistributionen använder Azure PaaS offentliga ändpunkter med plattformshanterat gränsskydd. Mallen erbjuder ett inbyggt härdningsalternativ (deployNetworkIsolation=true) som placerar SQL och Blob Storage bakom ett virtuellt nätverk som endast är nåbart för App Service; myndigheter kan också lägga till Private Endpoints, WAF (Application Gateway/Front Door) och NSG-regler. |
| 10 — Cyber defense services | Microsoft Defender for SQL är aktiverat som standard på den logiska SQL-servern. Application Insights- och Log Analytics-data är tillgänglig för integration med GC:s cyberförsvarssensorer och myndighetens SIEM. Se Loggning, övervakning och granskning. |
| 11 — Logging and monitoring | Oföränderligt granskningsspår på fältnivå i Azure SQL plus en hash-kedjad, tilläggsendast granskningsliggare med ärenderevisionsexporter per förfrågan; en valfri WORM-blobbehållare gör exporterad bevisning skriv-en-gång på lagringsnivå. Application Insights fångar all API-telemetri, med standardlarmregler för mätvärden (HTTP 5xx, latens). Log Analytics med konfigurerbar kvarhållning (30–730 dagar). Se Loggning, övervakning och granskning. |
| 12 — Configuration of cloud marketplaces | SPFx-webbdelen och Teams-appen distribueras via Microsoft AppSource. Azure-backend distribueras via en Bicep-/ARM-mall — med ett klick från Azure-portalen eller skriptat med ett PowerShell-skript. Myndigheter godkänner installationer genom sina standardprocesser för appkatalog och Azure-styrning. Se Distributionsmodell. |
| 13 — Plan for continuity | Automatiserade säkerhetskopior i Azure SQL, redundansalternativ för Blob Storage och en tillståndslös App Service möjliggör snabb omdistribution (API:et bäddar in sitt schema och tillämpar det vid uppstart). Se Distributionsmodell. |
Vägledning för SA&A-processen
Vid genomförande av en säkerhetsbedömning och auktorisering (SA&A) för AccessPoint bör myndigheter beakta följande.
Systemkategorisering
AccessPoint kategoriseras vanligtvis som PBMM vid användning för behandling av ATIP-förfrågningar. Systemet hanterar:
| Datakategori | Klassificering | Motivering |
|---|---|---|
| Den sökandes personuppgifter (namn, e-post, adress) | Protected B | Personuppgifter — allvarlig skada vid utlämnande |
| Förfrågningsposter och beskrivningar | Protected B | Kan beskriva känsligt ämne |
| Uppladdade relevanta dokument | Upp till Protected B | Klassificering beror på dokumentinnehåll |
| Undantagsbeslut och motivering | Protected B | Utlämnande kan avslöja överläggningsprocesser |
| Granskningsspår och granskningsliggare | Protected B | Innehåller referenser till personuppgifter och förfrågningsdetaljer |
| Applikationskonfiguration | Intern | Inga känsliga data i konfigurationen |
| Telemetri och loggar | Intern | Prestandadata, inga personuppgifter i telemetrin |
Auktoriseringsgräns
AccessPoints auktoriseringsgräns omfattar:
- Azure App Service och dess distribuerade applikationskod
- Azure SQL Database och all applikationsdata
- Azure Blob Storage-kontot och alla lagrade dokument
- Application Insights- och Log Analytics-arbetsytan
- De valfria resurserna Azure AI Search, Azure OpenAI och Azure AI Document Intelligence, när de driftsätts (samtliga i myndighetens egen prenumeration med autentisering enbart via hanterad identitet)
- Entra ID-appregistreringen och App Service hanterade identitet
- SPFx-webbdelen distribuerad till SharePoint Online och Teams-apppaketet
- Alla dataflöden mellan dessa komponenter
Följande ligger utanför AccessPoints auktoriseringsgräns och faller under myndighetens bredare Azure/M365 SA&A:
- Azure-prenumerationen och resursgruppskonfigurationen
- Entra ID-klientorganisationens policyer (MFA, Conditional Access, enhetsefterlevnad)
- Nätverkskonfiguration (VNet, NSG, Private Endpoints)
- Azure-plattformstjänster som hanteras av Microsoft
Att utnyttja befintliga bedömningar
- Azure-plattformskontroller (PE, delar av SC och CP) täcks av Microsofts CCCS-bedömning för PBMM. Myndigheter kan hänvisa till CCCS molntjänstleverantörsbedömning för Azure i stället för att ombedöma kontroller på plattformsnivå.
- Entra ID- och M365-kontroller täcks av myndighetens befintliga M365 SA&A. AccessPoint ärver MFA, Conditional Access och identitetsstyrning från myndighetens klientkonfiguration.
- AccessPoints kontroller på applikationsnivå (AC, AU, applikationslagret för IA/CM/SI samt IR) måste bedömas av myndigheten. Sidan Teknisk arkitektur innehåller den detaljerade kontrolldokumentationen.
Nyckeldokument att begära
Vid utvärdering av AccessPoint kan ditt SA&A-team vilja begära:
| Dokument | Syfte |
|---|---|
| Denna sida + Teknisk arkitektur | Dokumentation av säkerhetskontroller |
| Resultat från sårbarhetsbedömning och penetrationstest (VAPT) | Applikationssäkerhetstestning |
| Distributionsguide | Distributionsprocedur och härdning efter distribution |
| Beroendeförteckning | Riskbedömning av leveranskedjan (se Komponentinventering; fullständig beroendeförteckning tillgänglig på begäran) |
| Rutiner för incidenthantering | Leverantörens IR-åtaganden (tillgängligt från utgivaren på begäran) |
| Integritetskonsekvensbedömning (PIA) | Flöden av personuppgifter och integritetskontroller (se GC:s integritetskonsekvensbedömning (PIA)) |
| Dataflödesdiagram | Datarörelse (se Arkitekturdiagram och Dataresidens och datasuveränitet) |