ITSG-33-kontrolkortlægning, overholdelse af GC Cloud Guardrails og SA&A-reference for canadiske føderale myndigheder
Last updated: September 03, 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 oprettes Entra-first med Entra-only-godkendelse — der findes aldrig en SQL-legitimation, så der er intet at gemme, rotere eller deaktivere.
- Adgangskontrol — granuleret, tilladelsesbaseret adgangskontrol håndhævet server-side på hvert API-endepunkt: et produktdefineret katalog af atomare tilladelseskoder grupperes i lejerkonfigurerbare roller, og PII-filter-middleware fjerner rekvirent-PII fra svar for enhver kaldende, der ikke har tilladelsen til at se anmoderens PII.
- 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), kun-tilføjelig revisionslog med retsklare sagsrevisionseksporter (tidligere kaldet "bevispakker") pr. anmodning; en valgfri WORM-blobbeholder (write-once) kan gøre dem uforanderlige på lagringsniveau. Telemetri i Application Insights / Log Analytics med standard-metrik-alarmregler, Microsoft Defender for SQL aktiveret som standard, og valgfri Microsoft Defender for Storage-malware-scanning ved upload, der blokerer en markeret fil fra forhåndsvisning, afspilning, download og udlevering.
- Valgfrie processorer — Azure AI Speech (transskription), Azure AI Document Intelligence (OCR og tekst på skærmen) og et scale-to-zero Container Apps-mediejob installeres alle i myndighedens eget abonnement med udelukkende managed identity-adgang og nøgler deaktiveret. Ansigtsdetektion og regionssporing til videoredigering kører inde i App Service uden noget eksternt kald. Mediejobbets container-image er rent kode; myndigheder spejler det til deres eget Azure Container Registry til produktion, så ingen runtime-hentning afhænger af udgiveren.
- Udgivergrænse — licensvalidering godkender med et Entra managed identity-token (tokenets tenant-id-krav identificerer lejeren) og overfører kun tenant-id'et, API-versionen og API'ens egen basis-URL; svaret bærer også den senest udgivne AccessPoint-version, så Opsætning-panelet kan vise meddelelsen Opdatering tilgængelig (kun versionsnumre — ingen brugs- eller sagsdata). Ingen kunde-sagsdata overføres til eller lagres af udgiveren. Den eneste valgfrie udgang er payloaden til Teams-aktivitetsfeed-notifikationen (routing-GUID'er plus, som standard, notifikationens titel/preview og den handlende brugers navn — aldrig rekvirent-PII), der relæes gennem udgiverens multi-tenant-app, fordi Graph kræver, at den manifest-ejende app sender den. En myndighed kan minimere den (en til/fra-knap fjerner navne og fritekst og efterlader kun routing-identifikatorer) eller eliminere den helt (selv-hoste relæet, så intet når udgiveren); e-mail og den indbyggede feed bærer de samme meddelelser i lejeren. Se Teams-notifikationers datadeling.
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; integritetsverificeret API-pakke; spejlbart mediearbejder-image; 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 | Granuleret, tilladelsesbaseret adgangskontrol håndhævet server-side i API-laget ved hver anmodning: atomare tilladelseskoder grupperet i roller, hvor Administrator er den eneste indbyggede rolle (et serverside-værn forhindrer, at den sidste aktive Administrator fjernes). Operationelle roller er lejerkonfigurerbare og adskilt fra Administrator, og rolletildelinger kan tidsbegrænses. App Service godkender sig via en system-assigned managed identity uden lagrede legitimationsoplysninger, og Azure SQL oprettes Entra-first med Entra-only-godkendelse (der findes aldrig en SQL-legitimation). 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) — herunder de valgfrie AI Search-, Azure OpenAI-, Document Intelligence-, Azure AI Speech-, Defender for Storage- og Container Apps-medieforarbejdningsressourcer, som implementeres i myndighedens eget abonnement. Optagelser, transskriptioner og udleverede kopier forbliver i myndighedens egen storage-konto. Licensvalidering overfører kun tenant-id'et (via et Entra managed identity-token), API-versionen og API'ens egen basis-URL — ingen kunde-sagsdata overføres til eller lagres af udgiveren. Den ene valgfrie udgang, payloaden til Teams-aktivitetsfeed-notifikationen, indeholder ingen rekvirent-PII og kan minimeres til routing-identifikatorer eller elimineres ved at selv-hoste relæet; e-mail og den indbyggede feed bærer de samme meddelelser i lejeren. Se Datalokalitet og -suverænitet og Teams-notifikationers datadeling. |
| 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. Skabelonen tilbyder en indbygget hærdningsmulighed (deployNetworkIsolation=true), der placerer SQL og Blob Storage bag et virtuelt netværk, som kun App Service kan nå; myndigheder kan desuden tilføje Private Endpoints, WAF (Application Gateway / Front Door) og NSG-regler. |
| 10 — Cyberforsvarstjenester | Microsoft Defender for SQL er aktiveret som standard på den logiske SQL-server, og Microsoft Defender for Storage-malware-scanning ved upload kan aktiveres på dokumentkontoen (deployDefenderForStorage=true), hvor afgørelser håndhæves af applikationen, før en fil forhåndsvises, afspilles, downloades eller udleveres. 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, kun-tilføjelig revisionslog med sagsrevisionseksporter pr. anmodning; en valgfri WORM-blobbeholder gør dem write-once på lagringsniveau. 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 — med API-pakken verificeret mod dens publicerede SHA-256. Det valgfrie mediearbejder-image hentes som standard fra udgiverens registry og bør spejles til myndighedens eget Azure Container Registry (mediaWorkerImage + mediaWorkerRegistryResourceId), så jobbet henter med sin managed identity fra en kilde, myndigheden kontrollerer. 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
- De valgfrie ressourcer Azure AI Search, Azure OpenAI, Azure AI Document Intelligence og Azure AI Speech, Defender for Storage-planen på dokumentkontoen samt medieforarbejdningens Storage Queues, Container Apps-miljø og job, når de er implementeret (alle i myndighedens eget abonnement med udelukkende managed identity-godkendelse)
- 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) |