Kartläggning av ITSG-33-kontroller, efterlevnad av GC Cloud Guardrails och referens för SA&A för kanadensiska federala myndigheter
Last updated: July 12, 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 använder Entra-only-autentisering (SQL-lösenordsautentisering inaktiverad), så inga autentiseringsuppgifter lagras i applikationen.
- Åtkomstkontroll – server-side RBAC på applikationsnivå för varje API-ändpunkt, plus PII-filtermiddleware som tar bort den sökandes personuppgifter från svar för begränsade roller.
- 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) granskningsliggare med endast tillägg; telemetri i Application Insights/Log Analytics med standardlarmregler för mätvärden.
- Utgivarens gräns – licensvalidering överför endast klientorganisations-ID och licensnyckel; ingen kunddata överförs till eller lagras av utgivaren.
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 | RBAC på applikationsnivå med sex distinkta roller, tillämpat server-side i API-lagret vid varje förfrågan. Administratörsrollen är separat från operativa roller. App Service autentiserar via en systemtilldelad hanterad identitet utan lagrade autentiseringsuppgifter, och Azure SQL använder Entra-only-autentisering (SQL-lösenordsautentisering inaktiverad). 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). Licensvalidering överför endast klientorganisations-ID och licensnyckel — ingen kunddata överförs till eller lagras av utgivaren. Se Dataresidens och datasuveränitet. |
| 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. Myndigheter kan lägga till Private Endpoints, VNet-integration, WAF (Application Gateway/Front Door) och NSG-regler. |
| 10 — Cyber defense services | 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 granskningsliggare med endast tillägg. 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
- Azure AI Search, när den valfria fritextsökfunktionen distribueras
- 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) |