Mappatura dei controlli ITSG-33, conformità ai GC Cloud Guardrails e riferimento SA&A per i dipartimenti del governo federale canadese
Last updated: August 06, 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 viene creato con approccio Entra-first e autenticazione solo Entra — non esiste mai alcuna credenziale SQL, quindi non c'è nulla da archiviare, ruotare o disabilitare.
- Controllo degli accessi — controllo degli accessi granulare, basato sui permessi, applicato lato server su ogni endpoint API: un catalogo di codici di permesso atomici definito dal prodotto è raggruppato in ruoli configurabili a livello di tenant, e un middleware di filtro PII rimuove la PII del richiedente dalle risposte per qualsiasi chiamante che non detenga il permesso di visualizzazione della PII del richiedente.
- 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, con esportazioni di audit del caso per richiesta idonee in sede giudiziaria (in precedenza "pacchetti di prove"); un contenitore Blob WORM (write-once) opzionale può renderle immutabili a livello di archiviazione. Telemetria in Application Insights / Log Analytics con regole di avviso sulle metriche predefinite, e Microsoft Defender per SQL abilitato per impostazione predefinita.
- Confine dell'editore — la convalida della licenza si autentica con un token di identità gestita Entra (la rivendicazione dell'ID tenant del token identifica il tenant) e trasmette solo l'ID del tenant, la versione dell'API e l'URL di base dell'API stessa; nessun dato di caso del cliente viene trasmesso o archiviato dall'editore. L'unica via di uscita opzionale è il payload della notifica del feed attività di Teams (GUID di instradamento più, per impostazione predefinita, il titolo/anteprima della notifica e il nome dell'utente che ha eseguito l'azione — mai la PII del richiedente), instradato tramite l'app multi-tenant dell'editore poiché Graph richiede che sia l'app proprietaria del manifesto a inviarla. Un dipartimento può ridurla al minimo (un interruttore rimuove nomi e testo libero, lasciando solo gli identificatori di instradamento) oppure eliminarla del tutto (ospitando autonomamente il relay in modo che nulla raggiunga l'editore); l'e-mail e il feed nell'app recapitano gli stessi avvisi all'interno del tenant. Vedere Condivisione dei dati delle notifiche Teams.
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 | Controllo degli accessi granulare, basato sui permessi, applicato lato server a livello API su ogni richiesta: codici di permesso atomici raggruppati in ruoli, con Administrator come unico ruolo predefinito (una protezione lato server impedisce la rimozione dell'ultimo Administrator attivo). I ruoli operativi sono configurabili a livello di tenant e separati da Administrator, e le assegnazioni di ruolo possono essere limitate nel tempo. L'App Service si autentica tramite un'identità gestita assegnata dal sistema senza credenziali archiviate, e Azure SQL viene creato con approccio Entra-first e autenticazione solo Entra (non esiste mai alcuna credenziale SQL). 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) — comprese le risorse opzionali AI Search, Azure OpenAI e Document Intelligence, che vengono distribuite nell'abbonamento del dipartimento stesso. La convalida della licenza trasmette solo l'ID del tenant (tramite un token di identità gestita Entra), la versione dell'API e l'URL di base dell'API stessa — nessun dato di caso del cliente viene trasmesso o archiviato dall'editore. L'unica via di uscita opzionale, il payload della notifica del feed attività di Teams, non contiene alcuna PII del richiedente e può essere ridotta agli identificatori di instradamento oppure eliminata ospitando autonomamente il relay; l'e-mail e il feed nell'app recapitano gli stessi avvisi all'interno del tenant. Vedere Residenza e sovranità dei dati e Condivisione dei dati delle notifiche Teams. |
| 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. Il modello offre un'opzione di hardening integrata (deployNetworkIsolation=true) che colloca SQL e Blob Storage dietro una rete virtuale raggiungibile solo dall'App Service; i dipartimenti possono inoltre aggiungere Private Endpoints, WAF (Application Gateway / Front Door) e regole NSG. |
| 10 — Servizi di difesa informatica | Microsoft Defender per SQL è abilitato per impostazione predefinita sul server logico SQL. 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, con esportazioni di audit del caso per richiesta; un contenitore Blob WORM opzionale le rende write-once a livello di archiviazione. 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
- Le risorse opzionali Azure AI Search, Azure OpenAI e Azure AI Document Intelligence, quando distribuite (tutte nell'abbonamento del dipartimento stesso, con autenticazione esclusivamente tramite identità gestita)
- 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) |