Mappage des contrôles ITSG-33, conformité aux balises de sécurité infonuagique du GC et référence d'EAS pour les ministères fédéraux canadiens
Last updated: July 12, 2026 by Steve
Référence des contrôles de sécurité du GC
Cette page s'adresse aux ministères fédéraux canadiens qui effectuent une évaluation de sécurité et autorisation (EAS) pour AccessPoint. Elle établit la correspondance entre les contrôles de sécurité d'AccessPoint et le cadre ITSG-33, les balises de sécurité infonuagique du GC, ainsi que les exigences connexes du SCT et du CCCS.
Pour l'architecture technique complète, consultez la page Architecture technique.
Résumé de l'architecture à l'intention des évaluateurs
AccessPoint fonctionne entièrement dans le locataire Microsoft 365 et Azure propre au ministère. Les faits pertinents en matière de sécurité qui sous-tendent les correspondances ci-dessous sont les suivants :
- Backend — une API Web ASP.NET Core sur Azure App Service (Linux), Azure SQL Database et Azure Blob Storage, le tout déployé dans l'abonnement Azure propre au ministère.
- Identité — Microsoft Entra ID est l'unique fournisseur d'identité (jetons porteurs JWT). L'App Service s'authentifie auprès des services principaux au moyen d'une identité managée attribuée par le système; Azure SQL utilise l'authentification Entra uniquement (l'authentification par mot de passe SQL est désactivée), de sorte qu'aucun identifiant n'est stocké dans l'application.
- Contrôle d'accès — un RBAC au niveau applicatif, appliqué côté serveur sur chaque point de terminaison de l'API, complété par un intergiciel de filtrage des RPI qui supprime les RPI du demandeur des réponses destinées aux rôles restreints.
- Chiffrement — TLS 1.3 en périphérie de l'App Service (TLS 1.2 ou supérieur sur Azure SQL et Blob Storage); TDE sur la base de données et SSE AES-256 sur Blob Storage au repos.
- Audit — une piste d'audit immuable au niveau des champs, complétée par un registre d'audit chaîné par hachage (SHA-256) et à ajout seul; télémétrie dans Application Insights / Log Analytics avec des règles d'alerte métriques par défaut.
- Limite de l'éditeur — la validation de licence ne transmet que l'ID du locataire et la clé de licence; aucune donnée client n'est transmise à l'éditeur ni stockée par celui-ci.
Alignement avec le cadre de sécurité du GC
| Cadre | Comment AccessPoint s'aligne |
|---|---|
| ITSG-33 (profil PBMM) | Contrôles de sécurité correspondant à toutes les familles ITSG-33. Voir le mappage des familles de contrôles ITSG-33 ci-dessous. |
| Balises de sécurité infonuagique du GC | Les 13 balises obligatoires sont toutes traitées. Voir le tableau Conformité aux balises de sécurité infonuagique du GC. |
| Politique sur la sécurité du gouvernement | Système conçu pour une EAS formelle. Le périmètre d'autorisation est défini dans la section Périmètre d'autorisation ci-dessous. |
| Directive sur la gestion de la sécurité | Les capacités de piste d'audit, de contrôle d'accès et de surveillance continue soutiennent la conformité continue. |
| Directive sur les services et le numérique | Architecture infonuagique native, alignée sur la directive « infonuagique d'abord » du GC. Se déploie entièrement dans le locataire M365 et Azure existant du ministère. |
| Gestion des risques liés à la sécurité infonuagique du CCCS | Responsabilité partagée documentée. Les régions canadiennes d'Azure sont évaluées par le CCCS pour PBMM. |
Résidence des données au Canada
Pour les déploiements du gouvernement du Canada, AccessPoint est déployé dans des régions Azure canadiennes (Canada Centre ou Canada Est). Toutes les données — y compris les dossiers de demandes, les documents téléversés, les pistes d'audit et la télémétrie — résident dans la région canadienne sélectionnée. Aucune donnée n'est transmise ou stockée dans des régions hors du Canada, sauf si le ministère configure explicitement la géoréplication Azure à cette fin.
Les régions canadiennes de Microsoft Azure ont été évaluées par le Centre canadien pour la cybersécurité (CCCS) et sont approuvées pour les charges de travail PBMM (Protégé B, intégrité moyenne, disponibilité moyenne).
Ce que signifie PBMM pour AccessPoint
- Protégé B — AccessPoint traite les RPI du demandeur (nom, courriel, téléphone, adresse) ainsi que des dossiers gouvernementaux potentiellement sensibles. L'intergiciel de filtrage des RPI, le contrôle d'accès basé sur les rôles et les contrôles de chiffrement de l'application sont conçus pour les données Protégé B.
- Intégrité moyenne — Toutes les modifications de données sont consignées dans une piste d'audit immuable, renforcée par un registre d'audit chaîné par hachage. Les contraintes de base de données et la validation au niveau de l'API protègent contre les modifications non autorisées.
- Disponibilité moyenne — L'application est sans état, tout l'état résidant dans Azure SQL et Blob Storage. Les ententes de niveau de service de la plateforme Azure et la redondance configurable par le client répondent aux exigences de disponibilité moyenne.
Mappage des familles de contrôles ITSG-33
Le tableau ci-dessous établit la correspondance entre chaque famille de contrôles ITSG-33 et les sections pertinentes de la page Architecture technique. Utilisez-le comme point de départ pour évaluer AccessPoint par rapport au profil de contrôles de sécurité PBMM de votre ministère.
| Famille ITSG-33 | Domaine de contrôle | Où il est traité |
|---|---|---|
| AC — Contrôle d'accès | Authentification, autorisation, moindre privilège, RBAC côté serveur, filtrage des RPI, gestion des sessions | Authentification et identité, Autorisation et RBAC, Protection de la vie privée dès la conception |
| AU — Audit et responsabilisation | Journalisation, piste d'audit immuable, registre chaîné par hachage, surveillance, rétention des journaux | Journalisation, surveillance et audit |
| CA — Évaluation de sécurité et autorisation | Processus d'EAS, périmètre du système, surveillance continue | Périmètre d'autorisation (cette page); Aperçu de la plateforme; surveillance continue via Journalisation, surveillance et audit |
| CM — Gestion de la configuration | Configuration de référence, contrôle des changements, paramètres de sécurisation par défaut | Modèle de déploiement (paramètres de sécurisation par défaut, migrations DacPac additives) |
| CP — Planification des mesures d'urgence | Sauvegarde, reprise après sinistre, continuité des activités | App Service sans état (tout l'état est dans Azure SQL et Blob Storage); sauvegardes SQL gérées par Azure et redondance Blob configurées par le ministère — voir Modèle de déploiement |
| IA — Identification et authentification | Fournisseur d'identité Entra ID, AMF, identité managée, authentification Entra uniquement pour SQL | Authentification et identité |
| IR — Réponse aux incidents | Gestion des incidents, notification, signalement au CCCS | La piste d'audit immuable, le registre chaîné par hachage et Log Analytics soutiennent les enquêtes — voir Journalisation, surveillance et audit. Les ministères signalent les événements cybernétiques au CCCS conformément aux exigences du GC. |
| MP — Protection des supports | Chiffrement des données au repos, assainissement des supports | Chiffrement, Résidence et souveraineté des données |
| PE — Protection physique et environnementale | Sécurité physique de l'infrastructure | Responsabilité du FSC Azure — couverte par l'évaluation CCCS de Microsoft pour PBMM |
| PL — Planification | Plans de sécurité, périmètre d'autorisation du système | Aperçu de la plateforme; Périmètre d'autorisation (cette page) |
| RA — Évaluation des risques | Évaluation des menaces et des risques, balayage des vulnérabilités | Évaluation des vulnérabilités et test de pénétration (EVTP) et évaluation des menaces et des risques (ÉMR), menées par le ministère (voir Documents clés à demander); balayage de la plateforme Azure par Microsoft |
| SA — Acquisition de systèmes et de services | Chaîne d'approvisionnement, dépendances tierces, pratiques des fournisseurs | Inventaire des composants, Ce que l'éditeur exploite; inventaire complet des dépendances offert sur demande |
| SC — Protection des systèmes et des communications | Chiffrement en transit, isolation des locataires, protection des limites | Chiffrement, Résidence et souveraineté des données. Déploiement mono-locataire avec ressources dédiées; les ministères peuvent ajouter des points de terminaison privés, une intégration VNet et un WAF. |
| SI — Intégrité des systèmes et de l'information | Correctifs, gestion des vulnérabilités, intégrité des données saisies | Modèle de déploiement (paramètres de sécurisation par défaut, migrations additives). Le SE et le runtime sont corrigés par Azure; le code applicatif et les dépendances sont corrigés par l'éditeur. |
Conformité aux balises de sécurité infonuagique du GC
Le tableau suivant établit la correspondance entre les contrôles d'AccessPoint et les balises de sécurité infonuagique du GC — les configurations de sécurité minimales obligatoires pour l'adoption de l'infonuagique par le GC.
| Balise | Comment AccessPoint y répond |
|---|---|
| 01 — Protéger les comptes racine/administrateur global | AccessPoint n'utilise ni ne requiert de comptes Global Admin au moment de l'exécution. Les rôles Admin au sein de l'application sont distincts des rôles admin Azure/M365. Le déploiement initial nécessite des permissions admin; le fonctionnement courant n'en nécessite pas. |
| 02 — Gestion des privilèges administratifs | RBAC au niveau applicatif avec six rôles distincts, appliqué côté serveur au niveau de l'API à chaque demande. Le rôle Administrator est distinct des rôles opérationnels. L'App Service s'authentifie au moyen d'une identité managée attribuée par le système, sans identifiant stocké, et Azure SQL utilise l'authentification Entra uniquement (l'authentification par mot de passe SQL est désactivée). Voir Autorisation et RBAC. |
| 03 — Accès à la console infonuagique | AccessPoint n'accède ni au portail Azure ni à aucune console de gestion infonuagique au moment de l'exécution. La gestion des ressources Azure demeure la responsabilité du ministère. |
| 04 — Comptes de surveillance d'entreprise | Toute la télémétrie est stockée dans l'instance Application Insights et l'espace de travail Log Analytics du client. Les ministères peuvent accorder au CCCS/SPC un accès en lecture seule selon leurs procédures standard. Voir Journalisation, surveillance et audit. |
| 05 — Emplacement des données | Toutes les données résident dans le locataire Azure du client, dans la région canadienne sélectionnée (Canada Centre ou Canada Est). La validation de licence ne transmet que l'ID du locataire et la clé de licence — aucune donnée client n'est transmise à l'éditeur ni stockée par celui-ci. Voir Résidence et souveraineté des données. |
| 06 — Protection des données au repos | Azure SQL TDE et Azure Blob Storage SSE (AES-256) activés par défaut. Les clés gérées par le client (CMK) sont prises en charge. Voir Chiffrement. |
| 07 — Protection des données en transit | TLS 1.3 appliqué en périphérie de l'App Service (TLS 1.0/1.1/1.2 rejetés); TLS 1.2 ou supérieur sur Azure SQL et Blob Storage. Aucun point de terminaison en texte clair. Voir Chiffrement. |
| 08 — Segmenter et séparer | Déploiement mono-locataire avec des ressources dédiées par client — aucun calcul, stockage ou base de données partagés. Les chemins Blob et les requêtes de base de données sont limités à la portée du locataire. Une segmentation réseau (points de terminaison privés, intégration VNet) peut être ajoutée. Voir Résidence et souveraineté des données. |
| 09 — Services de sécurité réseau | Le déploiement par défaut utilise des points de terminaison publics Azure PaaS avec une protection des limites gérée par la plateforme. Les ministères peuvent ajouter des points de terminaison privés, une intégration VNet, un WAF (Application Gateway / Front Door) et des règles NSG. |
| 10 — Services de cyberdéfense | Les données d'Application Insights et de Log Analytics sont accessibles aux fins d'intégration avec les capteurs de cyberdéfense du GC et le SIEM ministériel. Voir Journalisation, surveillance et audit. |
| 11 — Journalisation et surveillance | Piste d'audit immuable au niveau des champs dans Azure SQL, complétée par un registre d'audit chaîné par hachage et à ajout seul. Application Insights capture toute la télémétrie de l'API, avec des règles d'alerte métriques par défaut (HTTP 5xx, latence). Log Analytics avec rétention configurable (30 à 730 jours). Voir Journalisation, surveillance et audit. |
| 12 — Configuration des places de marché infonuagiques | Le composant WebPart SPFx et l'application Teams sont distribués via Microsoft AppSource. Le backend Azure se déploie au moyen d'un modèle Bicep/ARM — en un clic depuis le portail Azure, ou par script avec un script PowerShell. Les ministères approuvent les installations selon leurs processus standard de catalogue d'applications et de gouvernance Azure. Voir Modèle de déploiement. |
| 13 — Planifier la continuité | Les sauvegardes automatisées Azure SQL, les options de redondance de Blob Storage et un App Service sans état permettent un redéploiement rapide (l'API intègre son schéma et l'applique au démarrage). Voir Modèle de déploiement. |
Orientations sur le processus d'EAS
Lorsqu'ils mènent une évaluation de sécurité et autorisation pour AccessPoint, les ministères devraient tenir compte des éléments suivants.
Catégorisation du système
AccessPoint est généralement catégorisé PBMM lorsqu'il est utilisé pour le traitement des demandes ATIP. Le système traite :
| Catégorie de données | Classification | Justification |
|---|---|---|
| RPI du demandeur (nom, courriel, adresse) | Protégé B | Renseignements personnels — préjudice grave en cas de divulgation |
| Dossiers de demandes et descriptions | Protégé B | Peuvent décrire des sujets sensibles |
| Documents pertinents téléversés | Jusqu'à Protégé B | La classification dépend du contenu du document |
| Décisions d'exemption et justification | Protégé B | La divulgation pourrait révéler des processus délibératifs |
| Piste d'audit et registre d'audit | Protégé B | Contiennent des références aux RPI et aux détails des demandes |
| Configuration de l'application | Interne | Aucune donnée sensible dans la configuration |
| Télémétrie et journaux | Interne | Données de performance, aucun RPI dans la télémétrie |
Périmètre d'autorisation
Le périmètre d'autorisation d'AccessPoint comprend :
- L'Azure App Service et son code applicatif déployé
- L'Azure SQL Database et toutes les données applicatives
- Le compte Azure Blob Storage et tous les documents stockés
- L'espace de travail Application Insights et Log Analytics
- Azure AI Search, lorsque la fonctionnalité optionnelle de recherche en texte intégral est déployée
- L'inscription d'application Entra ID et l'identité managée de l'App Service
- Le composant WebPart SPFx déployé sur SharePoint Online et le package de l'application Teams
- Tous les flux de données entre ces composants
Les éléments suivants sont en dehors du périmètre d'autorisation d'AccessPoint et relèvent de l'EAS Azure/M365 plus large du ministère :
- La configuration de l'abonnement Azure et du groupe de ressources
- Les politiques du locataire Entra ID (AMF, accès conditionnel, conformité des appareils)
- La configuration réseau (VNet, NSG, points de terminaison privés)
- Les services de la plateforme Azure gérés par Microsoft
Tirer parti des évaluations existantes
- Les contrôles de la plateforme Azure (PE, certaines parties de SC et de CP) sont couverts par l'évaluation CCCS de Microsoft pour PBMM. Les ministères peuvent se référer à l'évaluation CCCS du fournisseur de services infonuagiques pour Azure plutôt que de réévaluer les contrôles au niveau de la plateforme.
- Les contrôles Entra ID et M365 sont couverts par l'EAS M365 existante du ministère. AccessPoint hérite de l'AMF, de l'accès conditionnel et de la gouvernance des identités à partir de la configuration du locataire du ministère.
- Les contrôles d'AccessPoint au niveau applicatif (AC, AU, la couche applicative d'IA/CM/SI, et IR) doivent être évalués par le ministère. La page Architecture technique fournit la documentation détaillée des contrôles.
Documents clés à demander
Lors de l'évaluation d'AccessPoint, votre équipe d'EAS voudra peut-être demander :
| Document | Objectif |
|---|---|
| Cette page + Architecture technique | Documentation des contrôles de sécurité |
| Résultats de l'évaluation des vulnérabilités et test de pénétration (EVTP) | Tests de sécurité applicative |
| Guide de déploiement | Procédure de déploiement et sécurisation post-déploiement |
| Inventaire des dépendances | Évaluation des risques de la chaîne d'approvisionnement (voir Inventaire des composants; inventaire complet des dépendances offert sur demande) |
| Procédures de réponse aux incidents | Engagements de RI du fournisseur (offerts par l'éditeur sur demande) |
| Évaluation des facteurs relatifs à la vie privée (PIA) | Flux de renseignements personnels et contrôles de protection de la vie privée (voir Évaluation des facteurs relatifs à la vie privée du GC) |
| Diagrammes de flux de données | Mouvement des données (voir Diagramme d'architecture et Résidence et souveraineté des données) |