Mappatura dei controlli ITSG-33, conformità ai GC Cloud Guardrails e riferimento SA&A per i dipartimenti del governo federale canadese
Last updated: July 12, 2026 by Steve
Riferimento controlli di sicurezza GC
Questa pagina è destinata ai dipartimenti del governo federale canadese che conducono una Security Assessment and Authorization (SA&A) per AccessPoint. Mappa i controlli di sicurezza di AccessPoint al framework ITSG-33, ai GC Cloud Guardrails e ai requisiti correlati di TBS/CCCS.
Per l'architettura tecnica completa, consulta la pagina Architettura tecnica.
Riepilogo dell'architettura per i valutatori
AccessPoint viene eseguito interamente all'interno del tenant Microsoft 365 e Azure del dipartimento. I fatti rilevanti ai fini della sicurezza su cui si basano le mappature seguenti sono:
- Backend — una Web API ASP.NET Core su Azure App Service (Linux), Azure SQL Database e Azure Blob Storage, tutti distribuiti nell'abbonamento Azure del dipartimento.
- Identità — Microsoft Entra ID è l'unico provider di identità (token JWT bearer). L'App Service si autentica ai servizi backend con un'identità gestita assegnata dal sistema; Azure SQL utilizza l'autenticazione solo Entra (autenticazione con password SQL disabilitata), pertanto nell'applicazione non vengono archiviate credenziali.
- Controllo degli accessi — RBAC lato server a livello applicazione su ogni endpoint API, oltre a un middleware di filtro PII che rimuove la PII del richiedente dalle risposte per i ruoli con accesso limitato.
- Crittografia — TLS 1.3 al punto di ingresso di App Service (TLS 1.2+ su Azure SQL e Blob Storage); TDE sul database e SSE AES-256 su Blob Storage per i dati a riposo.
- Audit — un registro di audit immutabile a livello di campo, oltre a un registro di audit concatenato tramite hash (SHA-256) e a sola aggiunta; telemetria in Application Insights / Log Analytics con regole di avviso sulle metriche predefinite.
- Confine dell'editore — la convalida della licenza trasmette solo l'ID del tenant e la chiave di licenza; nessun dato del cliente viene trasmesso o archiviato dall'editore.
Allineamento al framework di sicurezza GC
| Framework | Come si allinea AccessPoint |
|---|---|
| ITSG-33 (profilo PBMM) | Controlli di sicurezza mappati su tutte le famiglie ITSG-33. Vedere la Mappatura delle famiglie di controllo ITSG-33 di seguito. |
| GC Cloud Guardrails | Tutti i 13 guardrail obbligatori sono affrontati. Vedere la tabella Conformità ai GC Cloud Guardrails. |
| Politica sulla sicurezza del governo | Sistema progettato per una SA&A formale. Il perimetro di autorizzazione è definito nella sezione Perimetro di autorizzazione di seguito. |
| Direttiva sulla gestione della sicurezza | Le funzionalità di registro di audit, controllo degli accessi e monitoraggio continuo supportano la conformità continuativa. |
| Direttiva su Servizi e Digitale | Architettura cloud-native allineata alla direttiva cloud-first del GC. Si distribuisce interamente all'interno del tenant M365 e Azure esistente del dipartimento. |
| Gestione del rischio di sicurezza cloud del CCCS | Responsabilità condivisa documentata. Le regioni canadesi di Azure sono valutate dal CCCS per PBMM. |
Residenza dei dati in Canada
Per le implementazioni del Governo del Canada, AccessPoint viene distribuito in regioni Azure canadesi (Canada Central o Canada East). Tutti i dati — comprese le registrazioni delle richieste, i documenti caricati, i registri di audit e la telemetria — risiedono nella regione canadese selezionata. Nessun dato viene trasmesso o archiviato in regioni al di fuori del Canada, a meno che il dipartimento non configuri esplicitamente la geo-replicazione di Azure per farlo.
Le regioni canadesi di Microsoft Azure sono state valutate dal Centro canadese per la cybersicurezza (CCCS) e sono approvate per carichi di lavoro PBMM (Protected B, Medium Integrity, Medium Availability).
Cosa significa PBMM per AccessPoint
- Protected B — AccessPoint gestisce la PII del richiedente (nome, email, telefono, indirizzo) e registrazioni governative potenzialmente sensibili. Il middleware di filtro PII dell'applicazione, il controllo degli accessi basato sui ruoli e i controlli di crittografia sono progettati per dati di livello Protected B.
- Medium Integrity — Tutte le modifiche ai dati vengono registrate in un registro di audit immutabile, rafforzato da un registro di audit concatenato tramite hash. I vincoli del database e la convalida a livello API proteggono da modifiche non autorizzate.
- Medium Availability — L'applicazione è stateless, con tutto lo stato in Azure SQL e Blob Storage. Gli SLA della piattaforma Azure e la ridondanza configurabile dal cliente supportano i requisiti di disponibilità media.
Mappatura delle famiglie di controllo ITSG-33
La tabella seguente mappa ciascuna famiglia di controllo ITSG-33 alle sezioni pertinenti della pagina Architettura tecnica. Utilizzarla come punto di partenza nella valutazione di AccessPoint rispetto al profilo di controllo di sicurezza PBMM del proprio dipartimento.
| Famiglia ITSG-33 | Area di controllo | Dove viene affrontato |
|---|---|---|
| AC — Controllo degli accessi | Autenticazione, autorizzazione, privilegio minimo, RBAC lato server, filtro PII, gestione delle sessioni | Autenticazione e identità, Autorizzazione e RBAC, Privacy by Design |
| AU — Audit e responsabilità | Registrazione, registro di audit immutabile, registro concatenato tramite hash, monitoraggio, conservazione dei log | Registrazione, monitoraggio e audit |
| CA — Security Assessment and Authorization | Processo SA&A, perimetro del sistema, monitoraggio continuo | Perimetro di autorizzazione (questa pagina); Panoramica della piattaforma; monitoraggio continuo tramite Registrazione, monitoraggio e audit |
| CM — Gestione della configurazione | Configurazione di base, controllo delle modifiche, impostazioni predefinite di hardening | Modello di distribuzione (impostazioni predefinite di hardening, migrazioni DacPac additive) |
| CP — Pianificazione della continuità operativa | Backup, ripristino di emergenza, continuità operativa | App Service stateless (tutto lo stato in Azure SQL e Blob Storage); backup SQL gestiti da Azure e ridondanza Blob configurati dal dipartimento — vedere Modello di distribuzione |
| IA — Identificazione e autenticazione | Provider di identità Entra ID, MFA, identità gestita, autenticazione SQL solo Entra | Autenticazione e identità |
| IR — Risposta agli incidenti | Gestione degli incidenti, notifica, segnalazione al CCCS | Il registro di audit immutabile, il registro concatenato tramite hash e Log Analytics supportano le indagini — vedere Registrazione, monitoraggio e audit. I dipartimenti segnalano gli eventi informatici al CCCS secondo i requisiti del GC. |
| MP — Protezione dei supporti | Crittografia dei dati a riposo, sanificazione dei supporti | Crittografia, Residenza e sovranità dei dati |
| PE — Protezione fisica e ambientale | Sicurezza fisica dell'infrastruttura | Responsabilità del CSP Azure — coperta dalla valutazione CCCS di Microsoft per PBMM |
| PL — Pianificazione | Piani di sicurezza, perimetro di autorizzazione del sistema | Panoramica della piattaforma; Perimetro di autorizzazione (questa pagina) |
| RA — Valutazione dei rischi | Valutazione delle minacce/dei rischi, scansione delle vulnerabilità | VAPT e TRA condotti dal dipartimento (vedere Documenti chiave da richiedere); scansione della piattaforma Azure a cura di Microsoft |
| SA — Acquisizione di sistemi e servizi | Catena di fornitura, dipendenze di terze parti, prassi del fornitore | Inventario dei componenti, Cosa gestisce l'editore; inventario completo delle dipendenze disponibile su richiesta |
| SC — Protezione dei sistemi e delle comunicazioni | Crittografia in transito, isolamento del tenant, protezione perimetrale | Crittografia, Residenza e sovranità dei dati. Distribuzione a tenant singolo con risorse dedicate; i dipartimenti possono aggiungere Private Endpoints, integrazione VNet e WAF. |
| SI — Integrità dei sistemi e delle informazioni | Patching, gestione delle vulnerabilità, integrità degli input | Modello di distribuzione (impostazioni predefinite di hardening, migrazioni additive). Il sistema operativo/runtime viene sottoposto a patch da Azure; il codice applicativo e le dipendenze vengono sottoposti a patch dall'editore. |
Conformità ai GC Cloud Guardrails
La tabella seguente mappa i controlli di AccessPoint ai GC Cloud Guardrails — le configurazioni di sicurezza minime obbligatorie per l'adozione del cloud da parte del GC.
| Guardrail | Come lo affronta AccessPoint |
|---|---|
| 01 — Proteggere gli account amministratore root/globali | AccessPoint non utilizza né richiede account Global Admin in fase di esecuzione. I ruoli di amministrazione all'interno dell'applicazione sono separati dai ruoli di amministrazione Azure/M365. La distribuzione iniziale richiede permessi di amministratore; il funzionamento continuativo no. |
| 02 — Gestione dei privilegi amministrativi | RBAC a livello applicazione con sei ruoli distinti, applicato lato server a livello API su ogni richiesta. Il ruolo Administrator è separato dai ruoli operativi. L'App Service si autentica tramite un'identità gestita assegnata dal sistema senza credenziali archiviate, e Azure SQL utilizza l'autenticazione solo Entra (autenticazione con password SQL disabilitata). Vedere Autorizzazione e RBAC. |
| 03 — Accesso alla console cloud | AccessPoint non accede al Portale Azure né ad alcuna console di gestione cloud in fase di esecuzione. La gestione delle risorse Azure resta responsabilità del dipartimento. |
| 04 — Account di monitoraggio aziendale | Tutta la telemetria è archiviata nel workspace Application Insights e Log Analytics del cliente. I dipartimenti possono concedere a CCCS/SSC un accesso in sola lettura secondo le proprie procedure standard. Vedere Registrazione, monitoraggio e audit. |
| 05 — Ubicazione dei dati | Tutti i dati risiedono nel tenant Azure del cliente, nella regione canadese selezionata (Canada Central o Canada East). La convalida della licenza trasmette solo l'ID del tenant e la chiave di licenza — nessun dato del cliente viene trasmesso o archiviato dall'editore. Vedere Residenza e sovranità dei dati. |
| 06 — Protezione dei dati a riposo | TDE di Azure SQL e SSE di Azure Blob Storage (AES-256) abilitati per impostazione predefinita. Supportate le chiavi gestite dal cliente (CMK). Vedere Crittografia. |
| 07 — Protezione dei dati in transito | TLS 1.3 applicato al punto di ingresso di App Service (TLS 1.0/1.1/1.2 rifiutati); TLS 1.2+ su Azure SQL e Blob Storage. Nessun endpoint in chiaro. Vedere Crittografia. |
| 08 — Segmentare e separare | Distribuzione a tenant singolo con risorse dedicate per ciascun cliente — nessun compute, archiviazione o database condivisi. I percorsi Blob e le query al database sono limitati al tenant. È possibile aggiungere la segmentazione di rete (Private Endpoints, integrazione VNet). Vedere Residenza e sovranità dei dati. |
| 09 — Servizi di sicurezza di rete | La distribuzione predefinita utilizza endpoint pubblici PaaS di Azure con protezione perimetrale gestita dalla piattaforma. I dipartimenti possono aggiungere Private Endpoints, integrazione VNet, WAF (Application Gateway / Front Door) e regole NSG. |
| 10 — Servizi di difesa informatica | I dati di Application Insights e Log Analytics sono accessibili per l'integrazione con i sensori di difesa informatica del GC e con il SIEM dipartimentale. Vedere Registrazione, monitoraggio e audit. |
| 11 — Registrazione e monitoraggio | Registro di audit immutabile a livello di campo in Azure SQL, oltre a un registro di audit concatenato tramite hash e a sola aggiunta. Application Insights rileva tutta la telemetria API, con regole di avviso sulle metriche predefinite (HTTP 5xx, latenza). Log Analytics con conservazione configurabile (30-730 giorni). Vedere Registrazione, monitoraggio e audit. |
| 12 — Configurazione dei marketplace cloud | La web part SPFx e l'app Teams sono distribuite tramite Microsoft AppSource. Il backend Azure si distribuisce tramite un modello Bicep/ARM — con un clic dal Portale Azure oppure tramite script PowerShell. I dipartimenti approvano le installazioni attraverso i propri processi standard di App Catalog e di governance di Azure. Vedere Modello di distribuzione. |
| 13 — Pianificare la continuità | I backup automatici di Azure SQL, le opzioni di ridondanza di Blob Storage e un App Service stateless consentono una ridistribuzione rapida (l'API include il proprio schema e lo applica all'avvio). Vedere Modello di distribuzione. |
Guida al processo SA&A
Nel condurre una Security Assessment and Authorization per AccessPoint, i dipartimenti dovrebbero considerare quanto segue.
Categorizzazione del sistema
AccessPoint viene tipicamente categorizzato come PBMM quando utilizzato per l'elaborazione delle richieste ATIP. Il sistema gestisce:
| Categoria di dati | Classificazione | Motivazione |
|---|---|---|
| PII del richiedente (nome, email, indirizzo) | Protected B | Informazioni personali — danno grave in caso di divulgazione |
| Registrazioni e descrizioni delle richieste | Protected B | Possono descrivere argomenti sensibili |
| Documenti pertinenti caricati | Fino a Protected B | La classificazione dipende dal contenuto del documento |
| Decisioni di esenzione e relative motivazioni | Protected B | La divulgazione potrebbe rivelare processi deliberativi |
| Registro di audit e registro di audit concatenato | Protected B | Contengono riferimenti a PII e dettagli delle richieste |
| Configurazione dell'applicazione | Interno | Nessun dato sensibile nella configurazione |
| Telemetria e log | Interno | Dati sulle prestazioni, nessuna PII nella telemetria |
Perimetro di autorizzazione
Il perimetro di autorizzazione di AccessPoint comprende:
- L'Azure App Service e il codice applicativo distribuito
- L'Azure SQL Database e tutti i dati dell'applicazione
- L'account Azure Blob Storage e tutti i documenti archiviati
- Il workspace Application Insights e Log Analytics
- Azure AI Search, quando è distribuita la funzionalità opzionale di ricerca full-text
- La registrazione dell'app Entra ID e l'identità gestita dell'App Service
- La web part SPFx distribuita su SharePoint Online e il pacchetto dell'app Teams
- Tutti i flussi di dati tra questi componenti
I seguenti elementi sono al di fuori del perimetro di autorizzazione di AccessPoint e rientrano nella SA&A Azure/M365 più ampia del dipartimento:
- L'abbonamento Azure e la configurazione del gruppo di risorse
- I criteri del tenant Entra ID (MFA, Accesso Condizionale, conformità dei dispositivi)
- La configurazione di rete (VNet, NSG, Private Endpoints)
- I servizi della piattaforma Azure gestiti da Microsoft
Sfruttare le valutazioni esistenti
- I controlli della piattaforma Azure (PE, porzioni di SC e CP) sono coperti dalla valutazione CCCS di Microsoft per PBMM. I dipartimenti possono fare riferimento alla valutazione CCCS del fornitore di servizi cloud per Azure anziché rivalutare i controlli a livello di piattaforma.
- I controlli di Entra ID e M365 sono coperti dalla SA&A M365 esistente del dipartimento. AccessPoint eredita MFA, Accesso Condizionale e governance dell'identità dalla configurazione del tenant del dipartimento.
- I controlli a livello applicazione di AccessPoint (AC, AU, il livello applicativo di IA/CM/SI, e IR) devono essere valutati dal dipartimento. La pagina Architettura tecnica fornisce la documentazione dettagliata dei controlli.
Documenti chiave da richiedere
Nella valutazione di AccessPoint, il team SA&A potrebbe voler richiedere:
| Documento | Scopo |
|---|---|
| Questa pagina + Architettura tecnica | Documentazione dei controlli di sicurezza |
| Risultati della Vulnerability Assessment and Penetration Test (VAPT) | Test di sicurezza dell'applicazione |
| Guida alla distribuzione | Procedura di distribuzione e hardening successivo alla distribuzione |
| Inventario delle dipendenze | Valutazione del rischio della catena di fornitura (vedere Inventario dei componenti; inventario completo delle dipendenze disponibile su richiesta) |
| Procedure di risposta agli incidenti | Impegni IR del fornitore (disponibili su richiesta presso l'editore) |
| Valutazione d'impatto sulla privacy | Flussi di informazioni personali e controlli di privacy (vedere Valutazione dell'impatto sulla privacy del GC) |
| Diagrammi di flusso dei dati | Movimento dei dati (vedere Diagramma dell'architettura e Residenza e sovranità dei dati) |