ITSG-33-controlemapping, GC Cloud Guardrails-compliance en SA&A-referentie voor Canadese federale overheidsafdelingen
Last updated: August 06, 2026 by Steve
GC-beveiligingscontrolesreferentie
Deze pagina is bedoeld voor Canadese federale overheidsafdelingen die een Security Assessment and Authorization (SA&A) uitvoeren voor AccessPoint. Ze brengt de beveiligingscontroles van AccessPoint in kaart met het ITSG-33-framework, GC Cloud Guardrails en gerelateerde TBS/CCCS-vereisten.
Voor de volledige technische architectuur, zie de pagina Technische architectuur.
Architectuursamenvatting voor toetsers
AccessPoint draait volledig binnen de eigen Microsoft 365- en Azure-tenant van de afdeling. De beveiligingsrelevante feiten die ten grondslag liggen aan de onderstaande mapping zijn:
- Backend — een ASP.NET Core Web API op Azure App Service (Linux), Azure SQL Database en Azure Blob Storage, allemaal geïmplementeerd in het eigen Azure-abonnement van de afdeling.
- Identiteit — Microsoft Entra ID is de enige identiteitsprovider (JWT bearer-tokens). De App Service authenticeert bij backend-services met een systeemtoegewezen beheerde identiteit; Azure SQL wordt Entra-first aangemaakt met Entra-only authenticatie — er bestaat nooit een SQL-referentie, dus er is niets op te slaan, te roteren of uit te schakelen.
- Toegangsbeheer — granulair, op machtigingen gebaseerd toegangsbeheer, serverside afgedwongen op elk API-eindpunt: een door het product gedefinieerde catalogus van atomaire machtigingscodes wordt gegroepeerd in per tenant configureerbare rollen, en PII-filtermiddleware verwijdert PII van de verzoeker uit antwoorden voor elke aanroeper die niet de machtiging voor het bekijken van PII van de verzoeker bezit.
- Versleuteling — TLS 1.3 aan de front door van de App Service (TLS 1.2+ op Azure SQL en Blob Storage); TDE op de database en AES-256 SSE op Blob Storage in rust.
- Audit — een onveranderlijke audittrail op veldniveau plus een hash-geketend (SHA-256), alleen-toevoegen auditlogboek met gerechtsklare zaakauditexports per verzoek (voorheen "bewijspakketten"); een opt-in WORM-blobcontainer (write-once) kan deze onveranderlijk maken op opslagniveau. Telemetrie in Application Insights / Log Analytics met standaard metrische waarschuwingsregels, en Microsoft Defender for SQL standaard ingeschakeld.
- Grens van de uitgever — licentievalidatie authenticeert met een Entra-token van de beheerde identiteit (de tenant-ID-claim in het token identificeert de tenant) en verzendt alleen de tenant-ID, API-versie en de eigen basis-URL van de API; het antwoord bevat ook de nieuwste gepubliceerde AccessPoint-versie, zodat het paneel Setup een melding "Update beschikbaar" kan tonen (alleen versienummers — geen gebruiks- of dossiergegevens). Er worden geen klantdossiergegevens verzonden naar of opgeslagen door de uitgever. De enige optionele uitgaande gegevensstroom is de payload van de Teams-activiteitenfeedmelding (routerings-GUID's plus, standaard, de titel/het voorbeeld van de melding en de naam van de handelende gebruiker — nooit PII van de verzoeker), gerelayed via de multi-tenant-app van de uitgever omdat Graph vereist dat de app die het manifest bezit deze verzendt. Een afdeling kan dit minimaliseren (een schakelaar verwijdert namen en vrije tekst, met alleen routeringsidentificatoren als restant) of volledig elimineren (de relay zelf hosten, zodat niets de uitgever bereikt); e-mail en de in-app-feed dragen dezelfde berichten binnen de tenant. Zie Teams Notification Data Sharing.
Afstemming op het GC-beveiligingsframework
| Framework | Hoe AccessPoint aansluit |
|---|---|
| ITSG-33 (PBMM-profiel) | Beveiligingscontroles in kaart gebracht voor alle ITSG-33-families. Zie de ITSG-33-controlefamiliemapping hieronder. |
| GC Cloud Guardrails | Alle 13 verplichte guardrails geadresseerd. Zie de tabel GC Cloud Guardrails-compliance. |
| Policy on Government Security | Systeem ontworpen voor formele SA&A. De autorisatiegrens is gedefinieerd in de sectie Autorisatiegrens hieronder. |
| Directive on Security Management | Audittrail, toegangsbeheer en mogelijkheden voor continue monitoring ondersteunen doorlopende compliance. |
| Directive on Service and Digital | Cloud-native architectuur afgestemd op de GC cloud-first-richtlijn. Wordt volledig geïmplementeerd binnen de bestaande M365- en Azure-tenant van de afdeling. |
| CCCS Cloud Security Risk Management | Gedeelde verantwoordelijkheid gedocumenteerd. Canadese Azure-regio's zijn door CCCS getoetst voor PBMM. |
Canadese gegevensresidentie
Voor implementaties bij Government of Canada wordt AccessPoint geïmplementeerd in Canadese Azure-regio's (Canada Central of Canada East). Alle gegevens — inclusief verzoekrecords, geüploade documenten, audittrails en telemetrie — bevinden zich binnen de geselecteerde Canadese regio. Er worden geen gegevens verzonden naar of opgeslagen in regio's buiten Canada, tenzij de afdeling hiervoor expliciet Azure geo-replicatie configureert.
De Canadese regio's van Microsoft Azure zijn getoetst door het Canadian Centre for Cyber Security (CCCS) en zijn goedgekeurd voor PBMM-workloads (Protected B, Medium Integrity, Medium Availability).
Wat PBMM betekent voor AccessPoint
- Protected B — AccessPoint verwerkt PII van verzoekers (naam, e-mail, telefoon, adres) en mogelijk gevoelige overheidsgegevens. De PII-filtermiddleware, het rolgebaseerde toegangsbeheer en de versleutelingscontroles van de applicatie zijn ontworpen voor Protected B-gegevens.
- Medium Integrity — Alle gegevenswijzigingen worden vastgelegd in een onveranderlijke audittrail, versterkt door een hash-geketend auditlogboek. Databasebeperkingen en validatie op API-niveau beschermen tegen ongeautoriseerde wijziging.
- Medium Availability — De applicatie is stateless, met alle status in Azure SQL en Blob Storage. Azure-platform-SLA's en door de klant configureerbare redundantie ondersteunen de vereisten voor medium beschikbaarheid.
ITSG-33-controlefamiliemapping
De onderstaande tabel brengt elke ITSG-33-controlefamilie in kaart met de relevante secties van de pagina Technische architectuur. Gebruik dit als uitgangspunt bij het evalueren van AccessPoint tegen het PBMM-beveiligingscontroleprofiel van uw afdeling.
| ITSG-33-familie | Controlegebied | Waar geadresseerd |
|---|---|---|
| AC — Access Control | Authenticatie, autorisatie, minimale bevoegdheden, serverside RBAC, PII-filtering, sessiebeheer | Authenticatie en identiteit, Autorisatie en RBAC, Privacy by Design |
| AU — Audit and Accountability | Logboeken, onveranderlijke audittrail, hash-geketend logboek, monitoring, logbewaring | Logboeken, monitoring en audit |
| CA — Security Assessment and Authorization | SA&A-proces, systeemgrens, continue monitoring | Autorisatiegrens (deze pagina); Platformoverzicht; continue monitoring via Logboeken, monitoring en audit |
| CM — Configuration Management | Basisconfiguratie, wijzigingsbeheer, standaard hardening | Implementatiemodel (standaard hardening, additieve DacPac-migraties) |
| CP — Contingency Planning | Back-up, noodherstel, bedrijfscontinuïteit | Stateless App Service (alle status in Azure SQL en Blob Storage); door Azure beheerde SQL-back-ups en Blob-redundantie geconfigureerd door de afdeling — zie Implementatiemodel |
| IA — Identification and Authentication | Entra ID-identiteitsprovider, MFA, beheerde identiteit, Entra-only SQL-authenticatie | Authenticatie en identiteit |
| IR — Incident Response | Incidentafhandeling, melding, rapportage aan CCCS | Onveranderlijke audittrail, hash-geketend logboek en Log Analytics ondersteunen onderzoek — zie Logboeken, monitoring en audit. Afdelingen rapporteren cybergebeurtenissen aan CCCS volgens de GC-vereisten. |
| MP — Media Protection | Versleuteling van gegevens in rust, mediasanering | Versleuteling, Gegevensresidentie en soevereiniteit |
| PE — Physical and Environmental Protection | Fysieke beveiliging van infrastructuur | Verantwoordelijkheid van Azure CSP — gedekt door de CCCS-toetsing van Microsoft voor PBMM |
| PL — Planning | Beveiligingsplannen, systeemautorisatiegrens | Platformoverzicht; Autorisatiegrens (deze pagina) |
| RA — Risk Assessment | Dreigings-/risicotoetsing, kwetsbaarheidsscanning | Door de afdeling uitgevoerde VAPT en TRA (zie Belangrijke documenten om op te vragen); scanning van het Azure-platform door Microsoft |
| SA — System and Services Acquisition | Toeleveringsketen, afhankelijkheden van derden, leverancierspraktijken | Componentinventaris, Wat de uitgever beheert; volledige afhankelijkheidsinventaris op aanvraag beschikbaar |
| SC — System and Communications Protection | Versleuteling tijdens transport, tenantisolatie, grensbescherming | Versleuteling, Gegevensresidentie en soevereiniteit. Single-tenant implementatie met dedicated resources; afdelingen kunnen Private Endpoints, VNet-integratie en WAF toevoegen. |
| SI — System and Information Integrity | Patching, kwetsbaarhedenbeheer, integriteit van invoer | Implementatiemodel (standaard hardening, additieve migraties). OS/runtime gepatcht door Azure; applicatiecode en afhankelijkheden gepatcht door de uitgever. |
GC Cloud Guardrails-compliance
De volgende tabel brengt de controles van AccessPoint in kaart met de GC Cloud Guardrails — de verplichte minimale beveiligingsconfiguraties voor GC-cloudadoptie.
| Guardrail | Hoe AccessPoint dit adresseert |
|---|---|
| 01 — Bescherm root-/Global Admin-accounts | AccessPoint gebruikt of vereist geen Global Admin-accounts tijdens runtime. Beheerdersrollen binnen de applicatie staan los van Azure/M365-beheerdersrollen. De initiële implementatie vereist beheerdersmachtigingen; doorlopende werking niet. |
| 02 — Beheer van beheerdersrechten | Granulair, op machtigingen gebaseerd toegangsbeheer, serverside afgedwongen op de API-laag bij elk verzoek: atomaire machtigingscodes gegroepeerd in rollen, met Administrator als enige ingebouwde rol (een serverside vangnet voorkomt dat de laatste actieve Administrator wordt verwijderd). Operationele rollen zijn per tenant configureerbaar en staan los van Administrator, en roltoewijzingen kunnen tijdgebonden zijn. De App Service authenticeert via een systeemtoegewezen beheerde identiteit zonder opgeslagen referenties, en Azure SQL wordt Entra-first aangemaakt met Entra-only authenticatie (er bestaat nooit een SQL-referentie). Zie Autorisatie en RBAC. |
| 03 — Toegang tot cloudconsole | AccessPoint benadert de Azure Portal of enige cloudbeheerconsole niet tijdens runtime. Azure-resourcebeheer blijft de verantwoordelijkheid van de afdeling. |
| 04 — Enterprise-monitoringaccounts | Alle telemetrie wordt opgeslagen in de Application Insights- en Log Analytics-werkruimte van de klant. Afdelingen kunnen CCCS/SSC alleen-lezen toegang verlenen volgens hun standaardprocedures. Zie Logboeken, monitoring en audit. |
| 05 — Gegevenslocatie | Alle gegevens bevinden zich in de Azure-tenant van de klant, in hun geselecteerde Canadese regio (Canada Central of Canada East) — inclusief de optionele AI Search-, Azure OpenAI- en Document Intelligence-resources, die worden geïmplementeerd in het eigen abonnement van de afdeling. Licentievalidatie verzendt alleen de tenant-ID (via een Entra-token van de beheerde identiteit), API-versie en de eigen basis-URL van de API — er worden geen klantdossiergegevens verzonden naar of opgeslagen door de uitgever. De ene optionele uitgaande gegevensstroom, de payload van de Teams-activiteitenfeedmelding, bevat geen PII van de verzoeker en kan worden geminimaliseerd tot routeringsidentificatoren of geëlimineerd door de relay zelf te hosten; e-mail en de in-app-feed dragen dezelfde berichten binnen de tenant. Zie Gegevensresidentie en soevereiniteit en Teams Notification Data Sharing. |
| 06 — Bescherming van gegevens in rust | Azure SQL TDE en Azure Blob Storage SSE (AES-256) standaard ingeschakeld. Klant-beheerde sleutels (CMK) worden ondersteund. Zie Versleuteling. |
| 07 — Bescherming van gegevens tijdens transport | TLS 1.3 afgedwongen aan de front door van de App Service (TLS 1.0/1.1/1.2 geweigerd); TLS 1.2+ op Azure SQL en Blob Storage. Geen plaintext-eindpunten. Zie Versleuteling. |
| 08 — Segmenteren en scheiden | Single-tenant implementatie met dedicated resources per klant — geen gedeelde compute, opslag of database. Blob-paden en databasequery's zijn tenant-scoped. Netwerksegmentatie (Private Endpoints, VNet-integratie) kan worden toegevoegd. Zie Gegevensresidentie en soevereiniteit. |
| 09 — Netwerkbeveiligingsservices | De standaardimplementatie gebruikt publieke Azure PaaS-eindpunten met platformbeheerde grensbescherming. De template biedt een ingebouwde hardeningsoptie (deployNetworkIsolation=true) die SQL en Blob Storage achter een virtueel netwerk plaatst dat alleen bereikbaar is voor de App Service; afdelingen kunnen daarnaast Private Endpoints, WAF (Application Gateway / Front Door) en NSG-regels toevoegen. |
| 10 — Cyberverdedigingsservices | Microsoft Defender for SQL is standaard ingeschakeld op de logische SQL-server. Application Insights- en Log Analytics-gegevens zijn toegankelijk voor integratie met GC-cyberverdedigingssensoren en het SIEM van de afdeling. Zie Logboeken, monitoring en audit. |
| 11 — Logboeken en monitoring | Onveranderlijke audittrail op veldniveau in Azure SQL plus een hash-geketend, alleen-toevoegen auditlogboek met zaakauditexports per verzoek; een opt-in WORM-blobcontainer maakt deze write-once op opslagniveau. Application Insights legt alle API-telemetrie vast, met standaard metrische waarschuwingsregels (HTTP 5xx, latentie). Log Analytics met configureerbare bewaartermijn (30–730 dagen). Zie Logboeken, monitoring en audit. |
| 12 — Configuratie van cloudmarktplaatsen | Het SPFx-webonderdeel en de Teams-app worden gedistribueerd via Microsoft AppSource. De Azure-backend wordt geïmplementeerd via een Bicep/ARM-template — met één klik vanuit de Azure Portal of via een PowerShell-script. Afdelingen keuren installaties goed via hun standaard App Catalog- en Azure-governanceprocessen. Zie Implementatiemodel. |
| 13 — Plan voor continuïteit | Geautomatiseerde Azure SQL-back-ups, redundantieopties voor Blob Storage en een stateless App Service maken snelle herimplementatie mogelijk (de API bundelt haar schema en past dit toe bij het opstarten). Zie Implementatiemodel. |
SA&A-procesrichtlijnen
Bij het uitvoeren van een Security Assessment and Authorization voor AccessPoint dienen afdelingen het volgende te overwegen.
Systeemcategorisering
AccessPoint wordt doorgaans gecategoriseerd als PBMM wanneer het wordt gebruikt voor ATIP-verzoekverwerking. Het systeem verwerkt:
| Gegevenscategorie | Classificatie | Motivering |
|---|---|---|
| PII van verzoeker (naam, e-mail, adres) | Protected B | Persoonlijke informatie — ernstige schade bij openbaarmaking |
| Verzoekrecords en -beschrijvingen | Protected B | Kan gevoelige onderwerpen beschrijven |
| Geüploade responsieve documenten | Tot Protected B | Classificatie hangt af van de documentinhoud |
| Uitzonderingsbeslissingen en motivering | Protected B | Openbaarmaking kan deliberatieve processen onthullen |
| Audittrail en auditlogboek | Protected B | Bevatten verwijzingen naar PII en verzoekdetails |
| Applicatieconfiguratie | Intern | Geen gevoelige gegevens in configuratie |
| Telemetrie en logboeken | Intern | Prestatiegegevens, geen PII in telemetrie |
Autorisatiegrens
De autorisatiegrens van AccessPoint omvat:
- De Azure App Service en de geïmplementeerde applicatiecode
- De Azure SQL Database en alle applicatiegegevens
- Het Azure Blob Storage-account en alle opgeslagen documenten
- De Application Insights- en Log Analytics-werkruimte
- De optionele Azure AI Search-, Azure OpenAI- en Azure AI Document Intelligence-resources, indien geïmplementeerd (allemaal in het eigen abonnement van de afdeling, met uitsluitend authenticatie via beheerde identiteit)
- De Entra ID-appregistratie en de beheerde identiteit van de App Service
- Het SPFx-webonderdeel dat is geïmplementeerd op SharePoint Online en het Teams-app-pakket
- Alle gegevensstromen tussen deze componenten
Het volgende valt buiten de autorisatiegrens van AccessPoint en valt onder de bredere Azure/M365 SA&A van de afdeling:
- Het Azure-abonnement en de resourcegroepconfiguratie
- Entra ID-tenantbeleid (MFA, Conditional Access, apparaatcompliance)
- Netwerkconfiguratie (VNet, NSG, Private Endpoints)
- Azure-platformservices beheerd door Microsoft
Benutten van bestaande toetsingen
- Azure-platformcontroles (PE, delen van SC en CP) worden gedekt door de CCCS-toetsing van Microsoft voor PBMM. Afdelingen kunnen verwijzen naar de CCCS-cloudserviceprovidertoetsing voor Azure in plaats van controles op platformniveau opnieuw te toetsen.
- Entra ID- en M365-controles worden gedekt door de bestaande M365 SA&A van de afdeling. AccessPoint erft MFA, Conditional Access en identiteitsgovernance van de tenantconfiguratie van de afdeling.
- Controles van AccessPoint op applicatieniveau (AC, AU, de applicatielaag van IA/CM/SI en IR) moeten door de afdeling worden getoetst. De pagina Technische architectuur biedt de gedetailleerde controledocumentatie.
Belangrijke documenten om op te vragen
Bij het evalueren van AccessPoint wil uw SA&A-team mogelijk het volgende opvragen:
| Document | Doel |
|---|---|
| Deze pagina + Technische architectuur | Documentatie van beveiligingscontroles |
| Resultaten van Vulnerability Assessment and Penetration Test (VAPT) | Applicatiebeveiligingstests |
| Implementatiehandleiding | Implementatieprocedure en hardening na implementatie |
| Afhankelijkheidsinventaris | Risicotoetsing van de toeleveringsketen (zie Componentinventaris; volledige afhankelijkheidsinventaris op aanvraag beschikbaar) |
| Incidentresponsprocedures | IR-toezeggingen van de uitgever (op aanvraag verkrijgbaar) |
| Privacyeffecttoetsing (PIA) | Stromen van persoonlijke informatie en privacycontroles (zie GC-privacyeffecttoetsing) |
| Gegevensstroomdiagrammen | Gegevensbeweging (zie Architectuurdiagram en Gegevensresidentie en soevereiniteit) |