ITSG-33-kontrolkortlægning, overholdelse af GC Cloud Guardrails og SA&A-reference for canadiske føderale myndigheder
Last updated: July 12, 2026 by Steve
GC-reference for sikkerhedskontroller
Denne side er henvendt til canadiske føderale myndigheder, der gennemfører en Security Assessment and Authorization (SA&A) for AccessPoint. Den kortlægger AccessPoints sikkerhedskontroller i forhold til ITSG-33-rammeværket, GC Cloud Guardrails og relaterede krav fra TBS/CCCS.
For den fulde tekniske arkitektur henvises til siden Teknisk arkitektur.
Arkitekturresumé for bedømmere
AccessPoint kører udelukkende inden for myndighedens egen Microsoft 365- og Azure-tenant. De sikkerhedsrelevante fakta, der ligger til grund for kortlægningerne nedenfor, er:
- Backend — en ASP.NET Core Web API på Azure App Service (Linux), Azure SQL Database og Azure Blob Storage, alt sammen implementeret i myndighedens eget Azure-abonnement.
- Identitet — Microsoft Entra ID er den eneste identitetsudbyder (JWT bearer-tokens). App Service godkender sig over for backend-tjenester med en system-assigned managed identity; Azure SQL bruger Entra-only-godkendelse (SQL-adgangskodegodkendelse deaktiveret), så der lagres ingen legitimationsoplysninger i applikationen.
- Adgangskontrol — RBAC på applikationsniveau, server-side, på hvert API-endepunkt samt PII-filter-middleware, der fjerner rekvirent-PII fra svar for begrænsede roller.
- Kryptering — TLS 1.3 ved App Service-frontdøren (TLS 1.2+ på Azure SQL og Blob Storage); TDE på databasen og AES-256 SSE på Blob Storage i hvile.
- Revision — et uforanderligt revisionsspor på feltniveau samt en hash-kædet (SHA-256) revisionslog, der kun kan tilføjes til; telemetri i Application Insights / Log Analytics med standard-metrik-alarmregler.
- Udgivergrænse — licensvalidering overfører kun tenant-id'et og licensnøglen; ingen kundedata overføres til eller lagres af udgiveren.
Overensstemmelse med GC-sikkerhedsrammeværk
| Rammeværk | Sådan stemmer AccessPoint overens |
|---|---|
| ITSG-33 (PBMM-profil) | Sikkerhedskontroller kortlagt til alle ITSG-33-familier. Se ITSG-33-kortlægning af kontrolfamilier nedenfor. |
| GC Cloud Guardrails | Alle 13 obligatoriske guardrails er adresseret. Se tabellen Overholdelse af GC Cloud Guardrails. |
| Policy on Government Security | Systemet er designet til formel SA&A. Autorisationsgrænsen er defineret i afsnittet Autorisationsgrænse nedenfor. |
| Directive on Security Management | Revisionsspor, adgangskontrol og kontinuerlig overvågning understøtter løbende overholdelse. |
| Directive on Service and Digital | Cloud-native arkitektur i overensstemmelse med GC's cloud-first-direktiv. Implementeres udelukkende inden for myndighedens eksisterende M365- og Azure-tenant. |
| CCCS Cloud Security Risk Management | Delt ansvar er dokumenteret. Azures canadiske regioner er CCCS-vurderet til PBMM. |
Canadisk datalokalitet
Ved implementeringer for Government of Canada implementeres AccessPoint i canadiske Azure-regioner (Canada Central eller Canada East). Alle data — herunder anmodningsregistreringer, uploadede dokumenter, revisionsspor og telemetri — befinder sig inden for den valgte canadiske region. Ingen data overføres til eller lagres i regioner uden for Canada, medmindre myndigheden udtrykkeligt konfigurerer Azure geo-replikering til det.
Microsoft Azures canadiske regioner er blevet vurderet af Canadian Centre for Cyber Security (CCCS) og er godkendt til PBMM-arbejdsbelastninger (Protected B, Medium Integrity, Medium Availability).
Hvad PBMM betyder for AccessPoint
- Protected B — AccessPoint håndterer rekvirent-PII (navn, e-mail, telefon, adresse) og potentielt følsomme offentlige optegnelser. Applikationens PII-filter-middleware, rollebaserede adgangskontrol og krypteringskontroller er designet til Protected B-data.
- Medium Integrity — Alle dataændringer registreres i et uforanderligt revisionsspor, forstærket af en hash-kædet revisionslog. Databasebegrænsninger og validering på API-niveau beskytter mod uautoriseret ændring.
- Medium Availability — Applikationen er stateless, med al tilstand i Azure SQL og Blob Storage. Azure-platformens SLA'er og kundekonfigurerbar redundans understøtter krav om medium tilgængelighed.
ITSG-33-kortlægning af kontrolfamilier
Tabellen nedenfor kortlægger hver ITSG-33-kontrolfamilie til de relevante afsnit på siden Teknisk arkitektur. Brug den som udgangspunkt, når du evaluerer AccessPoint i forhold til din myndigheds PBMM-sikkerhedskontrolprofil.
| ITSG-33-familie | Kontrolområde | Hvor det adresseres |
|---|---|---|
| AC — Access Control | Godkendelse, autorisation, mindste privilegium, server-side RBAC, PII-filtrering, sessionsstyring | Godkendelse og identitet, Autorisation og RBAC, Indbygget privatliv |
| AU — Audit and Accountability | Logning, uforanderligt revisionsspor, hash-kædet log, overvågning, logopbevaring | Logning, overvågning og revision |
| CA — Security Assessment and Authorization | SA&A-proces, systemgrænse, kontinuerlig overvågning | Autorisationsgrænse (denne side); Platformsoverblik; kontinuerlig overvågning via Logning, overvågning og revision |
| CM — Configuration Management | Baseline-konfiguration, ændringsstyring, hærdede standardindstillinger | Implementeringsmodel (hærdede standardindstillinger, additive DacPac-migreringer) |
| CP — Contingency Planning | Backup, disaster recovery, forretningskontinuitet | Stateless App Service (al tilstand i Azure SQL og Blob Storage); Azure-administrerede SQL-backups og Blob-redundans konfigureret af myndigheden — se Implementeringsmodel |
| IA — Identification and Authentication | Entra ID som identitetsudbyder, MFA, managed identity, Entra-only SQL-godkendelse | Godkendelse og identitet |
| IR — Incident Response | Hændelseshåndtering, notifikation, rapportering til CCCS | Uforanderligt revisionsspor, hash-kædet log og Log Analytics understøtter undersøgelse — se Logning, overvågning og revision. Myndigheder rapporterer cyberhændelser til CCCS i henhold til GC-krav. |
| MP — Media Protection | Kryptering af data i hvile, mediesanering | Kryptering, Datalokalitet og -suverænitet |
| PE — Physical and Environmental Protection | Fysisk sikkerhed af infrastruktur | Azure CSP-ansvar — dækket af Microsofts CCCS-vurdering til PBMM |
| PL — Planning | Sikkerhedsplaner, systemets autorisationsgrænse | Platformsoverblik; Autorisationsgrænse (denne side) |
| RA — Risk Assessment | Trussels-/risikovurdering, sårbarhedsscanning | VAPT og TRA gennemført af myndigheden (se Nøgledokumenter, der bør indhentes); scanning af Azure-platformen udført af Microsoft |
| SA — System and Services Acquisition | Forsyningskæde, tredjepartsafhængigheder, leverandørpraksis | Komponentoversigt, Hvad udgiveren driver; fuld afhængighedsoversigt tilgængelig på anmodning |
| SC — System and Communications Protection | Kryptering under transport, tenant-isolation, grænsebeskyttelse | Kryptering, Datalokalitet og -suverænitet. Single-tenant-implementering med dedikerede ressourcer; myndigheder kan tilføje Private Endpoints, VNet-integration og WAF. |
| SI — System and Information Integrity | Patching, sårbarhedshåndtering, inputintegritet | Implementeringsmodel (hærdede standardindstillinger, additive migreringer). OS/runtime patches af Azure; applikationskode og afhængigheder patches af udgiveren. |
Overholdelse af GC Cloud Guardrails
Følgende tabel kortlægger AccessPoints kontroller til GC Cloud Guardrails — de obligatoriske minimumssikkerhedskonfigurationer for GC's cloud-anvendelse.
| Guardrail | Sådan adresserer AccessPoint det |
|---|---|
| 01 — Beskyt root-/global admin-konti | AccessPoint bruger eller kræver ikke Global Admin-konti under kørsel. Admin-roller i applikationen er adskilt fra Azure-/M365-admin-roller. Den indledende implementering kræver admin-tilladelser; den løbende drift gør ikke. |
| 02 — Styring af administrative privilegier | RBAC på applikationsniveau med seks distinkte roller, håndhævet server-side i API-laget ved hver anmodning. Administrator-rollen er adskilt fra operationelle roller. App Service godkender sig via en system-assigned managed identity uden lagrede legitimationsoplysninger, og Azure SQL bruger Entra-only-godkendelse (SQL-adgangskodegodkendelse deaktiveret). Se Autorisation og RBAC. |
| 03 — Adgang til cloud-konsol | AccessPoint tilgår ikke Azure Portal eller nogen cloud-administrationskonsol under kørsel. Administration af Azure-ressourcer forbliver myndighedens ansvar. |
| 04 — Enterprise-overvågningskonti | Al telemetri lagres i kundens Application Insights- og Log Analytics-workspace. Myndigheder kan give CCCS/SSC skrivebeskyttet adgang efter deres standardprocedurer. Se Logning, overvågning og revision. |
| 05 — Dataplacering | Alle data befinder sig i kundens Azure-tenant i deres valgte canadiske region (Canada Central eller Canada East). Licensvalidering overfører kun tenant-id'et og licensnøglen — ingen kundedata overføres til eller lagres af udgiveren. Se Datalokalitet og -suverænitet. |
| 06 — Beskyttelse af data i hvile | Azure SQL TDE og Azure Blob Storage SSE (AES-256) aktiveret som standard. Kundeadministrerede nøgler (CMK) understøttes. Se Kryptering. |
| 07 — Beskyttelse af data under transport | TLS 1.3 håndhæves ved App Service-frontdøren (TLS 1.0/1.1/1.2 afvises); TLS 1.2+ på Azure SQL og Blob Storage. Ingen klartekst-endepunkter. Se Kryptering. |
| 08 — Segmentér og adskil | Single-tenant-implementering med dedikerede ressourcer pr. kunde — ingen delt compute, lagring eller database. Blob-stier og databaseforespørgsler er tenant-afgrænsede. Netværkssegmentering (Private Endpoints, VNet-integration) kan tilføjes. Se Datalokalitet og -suverænitet. |
| 09 — Netværkssikkerhedstjenester | Standardimplementeringen bruger Azure PaaS-offentlige endepunkter med platformsadministreret grænsebeskyttelse. Myndigheder kan tilføje Private Endpoints, VNet-integration, WAF (Application Gateway / Front Door) og NSG-regler. |
| 10 — Cyberforsvarstjenester | Data fra Application Insights og Log Analytics er tilgængelige for integration med GC's cyberforsvarssensorer og myndighedens SIEM. Se Logning, overvågning og revision. |
| 11 — Logning og overvågning | Uforanderligt revisionsspor på feltniveau i Azure SQL samt en hash-kædet revisionslog, der kun kan tilføjes til. Application Insights opfanger al API-telemetri med standard-metrik-alarmregler (HTTP 5xx, latens). Log Analytics med konfigurerbar opbevaring (30–730 dage). Se Logning, overvågning og revision. |
| 12 — Konfiguration af cloud-marketplaces | SPFx-webdelen og Teams-appen distribueres via Microsoft AppSource. Azure-backenden implementeres via en Bicep/ARM-skabelon — med ét klik fra Azure-portalen eller scriptet med en PowerShell-script. Myndigheder godkender installationer via deres standard-App Catalog- og Azure-governance-processer. Se Implementeringsmodel. |
| 13 — Plan for kontinuitet | Azure SQL's automatiske backups, redundansmuligheder for Blob Storage og en stateless App Service muliggør hurtig genimplementering (API'en samler sit skema og anvender det ved opstart). Se Implementeringsmodel. |
Vejledning til SA&A-processen
Når myndigheder gennemfører en Security Assessment and Authorization for AccessPoint, bør de overveje følgende.
Systemkategorisering
AccessPoint kategoriseres typisk som PBMM, når det bruges til behandling af ATIP-anmodninger. Systemet håndterer:
| Datakategori | Klassifikation | Begrundelse |
|---|---|---|
| Rekvirent-PII (navn, e-mail, adresse) | Protected B | Personoplysninger — alvorlig skade ved videregivelse |
| Anmodningsregistreringer og -beskrivelser | Protected B | Kan beskrive følsomt emneindhold |
| Uploadede relevante dokumenter | Op til Protected B | Klassifikation afhænger af dokumentindhold |
| Undtagelsesafgørelser og begrundelse | Protected B | Videregivelse kunne afsløre beslutningsprocesser |
| Revisionsspor og revisionslog | Protected B | Indeholder referencer til PII og anmodningsdetaljer |
| Applikationskonfiguration | Internal | Ingen følsomme data i konfiguration |
| Telemetri og logs | Internal | Ydelsesdata, ingen PII i telemetri |
Autorisationsgrænse
AccessPoints autorisationsgrænse omfatter:
- Azure App Service og dens implementerede applikationskode
- Azure SQL Database og alle applikationsdata
- Azure Blob Storage-kontoen og alle lagrede dokumenter
- Application Insights- og Log Analytics-workspace
- Azure AI Search, når den valgfrie fuldtekstsøgningsfunktion er implementeret
- Entra ID-appregistreringen og App Service-managed identity
- SPFx-webdelen implementeret til SharePoint Online og Teams-apppakken
- Alle datastrømme mellem disse komponenter
Følgende er uden for AccessPoints autorisationsgrænse og hører under myndighedens bredere Azure-/M365-SA&A:
- Azure-abonnementet og resource-group-konfigurationen
- Entra ID-tenant-politikker (MFA, Conditional Access, enhedscompliance)
- Netværkskonfiguration (VNet, NSG, Private Endpoints)
- Azure-platformstjenester administreret af Microsoft
Udnyttelse af eksisterende vurderinger
- Azure-platformskontroller (PE, dele af SC og CP) er dækket af Microsofts CCCS-vurdering til PBMM. Myndigheder kan henvise til CCCS' cloud-service-provider-vurdering for Azure frem for at revurdere kontroller på platformsniveau.
- Entra ID- og M365-kontroller er dækket af myndighedens eksisterende M365-SA&A. AccessPoint arver MFA, Conditional Access og identitetsstyring fra myndighedens tenant-konfiguration.
- AccessPoints kontroller på applikationsniveau (AC, AU, applikationslaget af IA/CM/SI samt IR) skal vurderes af myndigheden. Siden Teknisk arkitektur indeholder den detaljerede kontroldokumentation.
Nøgledokumenter, der bør indhentes
Når I evaluerer AccessPoint, kan jeres SA&A-team ønske at indhente:
| Dokument | Formål |
|---|---|
| Denne side + Teknisk arkitektur | Dokumentation af sikkerhedskontroller |
| Resultater af Vulnerability Assessment and Penetration Test (VAPT) | Sikkerhedstest af applikationen |
| Implementeringsvejledning | Implementeringsprocedure og hærdning efter implementering |
| Afhængighedsoversigt | Vurdering af forsyningskæderisiko (se Komponentoversigt; fuld afhængighedsoversigt tilgængelig på anmodning) |
| Procedurer for hændelsesrespons | Leverandørens IR-forpligtelser (tilgængelige fra udgiveren på anmodning) |
| Privatlivskonsekvensvurdering | Strømme af personoplysninger og privatlivskontroller (se GC-privatlivskonsekvensvurdering) |
| Dataflowdiagrammer | Databevægelse (se Arkitekturdiagram og Datalokalitet og -suverænitet) |