Aperçu de l'architecture technique destiné aux équipes TI qui évaluent AccessPoint

Last updated: July 12, 2026 by Steve

Architecture technique

Ce document fournit un aperçu technique de la plateforme AccessPoint à l'intention des architectes de solutions, des ingénieurs en cybersécurité et des directeurs TI qui évaluent le produit pour leur organisation. Il est tiré du Guide d'architecture de solution AccessPoint (v1.4.1).

Aperçu de la plateforme

AccessPoint est une plateforme de gestion de l'accès à l'information et de la protection de la vie privée bâtie sur Microsoft 365 et Azure. Elle a démarré comme un outil de gestion des demandes d'accès des personnes concernées (subject access request, SAR) et a évolué vers une suite intégrée ATIP/bureau de protection de la vie privée couvrant l'ensemble du cycle de vie des demandes ainsi que le programme de protection de la vie privée qui l'entoure. Elle fonctionne entièrement dans le locataire Microsoft 365 et Azure de votre propre organisation : il n'existe aucun serveur externe, aucune base de données ni aucune dépendance infonuagique tierce au moment de l'exécution, et toutes les données demeurent dans votre environnement, sous votre contrôle.

La plateforme est organisée en modules qui partagent un socle commun d'identité, de RBAC, de notifications, d'audit et de rapports :

  • Demandes d'accès — réception ATI/FOIA/GDPR, attribution des tâches aux détenteurs de dossiers (Custodian), examen et caviardage des documents, assemblage des réponses et rapports réglementaires
  • Évaluations de la protection de la vie privée — un moteur configurable d'évaluations PIA/AIA/sécurité
  • Incidents et atteintes à la vie privée — réception, confinement, évaluation du risque de préjudice et flux de travail de notification des atteintes
  • Plaintes et appels — cycle de vie des plaintes avec les parties concernées, les délais réglementaires et l'enquête
  • Registre des risques liés à la vie privée — risques de type ISO 31000, plans de traitement et indicateurs clés de risque
  • Registre des activités de traitement (ROPA) — dossiers GDPR Article 30 et exportation du registre
  • Registre des engagements — engagements en matière de protection de la vie privée suivis, avec cadence et points de contrôle

Tous les modules sont pilotés par des packs de configuration, sans données d'amorçage statiques.

Caractéristiques principales :

  • Natif du locataire — se déploie comme une solution SharePoint Framework (SPFx) et des services Azure PaaS au sein de votre locataire existant
  • Aucune dépendance à Power Platform — aucune licence Dataverse, Power Automate ou Power Apps requise
  • Souveraineté des données — toutes les données résident dans la géographie configurée de votre locataire Azure
  • Aucun accès du fournisseur en cours d'exécution — l'éditeur ne peut accéder à vos données pendant le fonctionnement normal
  • Licence à tarif fixe — licence ministérielle sans comptage par utilisateur
  • Protection de la vie privée dès la conception — les rôles Custodian et Contributor sont structurellement isolés des RPI du demandeur et de la personne concernée
  • Configuration plutôt que code — les types de demandes, les codes d'exemption et les champs à choix sont pilotés par les données
  • Multilingue par conception — un système de traduction à trois niveaux prenant en charge 11 langues

Diagramme d'architecture

Customer's Microsoft 365 Tenant          Customer's Azure Subscription
┌──────────────────────────────┐         ┌─────────────────────────────────────────┐
│                              │         │                                         │
│  SPFx Web Part               │         │  Azure App Service (Linux)              │
│  (SharePoint Online /        │──HTTPS──│  ASP.NET Core 10 Web API               │
│   Teams Personal App /       │  (JWT)  │    ├─ Entra ID JWT validation          │
│   Teams Tab)                 │         │    ├─ Role-based authorization          │
│                              │         │    ├─ PII filter middleware             │
│  Installed from AppSource    │         │    ├─ User upsert from JWT claims      │
│  or Tenant App Catalog       │         │    ├─ License validation middleware    │
│                              │         │    └─ Syncfusion document conversion   │
│                              │         │                                         │
│  SharePoint Tenant Storage   │         │  Azure SQL Database                     │
│  (API URL + Client ID)       │         │  (~186 tables, ~2,900 fields)          │
│                              │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.Read.All       │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         └─────────────────────────────────────────┘
        │  Calendars.Read      │
        │  AiEnterprise…Read   │  ← M365 record capture (delegated + app-only Copilot)
        └──────────────────────┘

Inventaire des composants

Composant Technologie Déployé vers Objectif
SPFx Web Part TypeScript, React 17, Fluent UI 8, SPFx 1.22.1 SharePoint Online / Teams du client Interface utilisateur pour tous les rôles
Teams App Manifeste Teams v1.19, version d'application 1.0.0 Centre d'administration Teams du client Application personnelle, onglet configurable, notifications du flux d'activité avec liens profonds
API Web C# / ASP.NET Core 10, .NET 10 (~87 contrôleurs, ~88 services) Azure App Service (Linux) du client Logique métier, accès aux données, traitement des documents
Base de données SQL Server (DacPac) Azure SQL Database du client Magasin de données relationnelles (~186 tables, ~2 900 champs)
Blob Storage Azure Blob Storage Compte de stockage Azure du client Stockage des fichiers documentaires
Surveillance Application Insights + Log Analytics Abonnement Azure du client Télémétrie, diagnostics, alertes
AI Search (en option) Azure AI Search Abonnement Azure du client Recherche en texte intégral dans le contenu des documents; provisionné uniquement lorsque deployAiSearch=true

Ce que l'éditeur exploite

Service Objectif
Realizer Platform Émission et validation des clés de licence (aucune donnée client transmise)
AppSource Listing Distribution du package SPFx
Azure Marketplace Listing Modèle de déploiement de l'infrastructure Azure
Teams App Package Distribution du manifeste Teams (chargement latéral ou magasin d'applications de l'organisation)

Aucune donnée client n'est transmise à un service exploité par l'éditeur, ni stockée par celui-ci.

Modules fonctionnels

Tous les modules s'exécutent au sein de l'API Web / composant SPFx unique et partagent un socle commun d'identité, de RBAC, de commentaires, de notifications, de Ma journée, d'audit, d'heures, de flux de révision et de rapports. Chacun est piloté par les données via les packs de configuration.

Module Résumé
Demandes (ATIP/SAR) Réception de la demande → attribution aux détenteurs de dossiers (Custodian) → collecte → réponse. Types, statuts, numérotation, calendriers et SLA configurables.
Documents et caviardage Espace de travail documentaire à facettes : étiquettes, familles de courriels, suivi de lecture, vues enregistrées, aperçu Syncfusion, pipeline de caviardage avec exemptions et aller-retour XFDF, assemblage des réponses.
Demandeurs / Contacts Identité de demandeur réutilisable de première classe, contrôle du flux de réception, frais et vérification, fusion; consultations; rédacteur de correspondance avec pare-feu RPI.
Évaluations de la protection de la vie privée Moteur configurable PIA/AIA/sécurité : modèles, questionnaires de présélection, délégation par section, notation/paliers, registre des risques, résumés de clôture et à l'intention des organismes de réglementation.
Incidents / atteintes à la vie privée Réception des incidents, confinement, évaluation du risque de préjudice, règles de notification des atteintes selon le régime applicable, remédiation.
Plaintes et appels Cycle de vie des plaintes : parties, délais réglementaires, recevabilité, enquête, examen des représentations.
Risques et engagements Registre des risques ISO 31000 avec appétit pour le risque, indicateurs clés de risque (ICR) et tâches de traitement; registre des engagements avec cadence et points de contrôle.
ROPA / Objets de la vie privée Programmes/systèmes réutilisables avec dossiers GDPR Article 30 et exportation du registre.
Révisions Moteur configurable de révision et d'approbation séquentielle/parallèle, réutilisé pour toutes les entités de dossier.
Rapports et audit Rapports fixes, générateur de rapports personnalisés, rapports statistiques annuels, tableaux de bord SLA/gestion, registre d'audit chaîné par hachage et dossiers de preuves prêts pour un tribunal.
Configuration et plateforme Importation de packs de configuration, paramètres du locataire, rôles/permissions personnalisés, bascules de fonctionnalités, champs personnalisés, tables de traduction en 11 langues.

Modèle de déploiement

AccessPoint utilise un modèle de déploiement scindé. Le composant WebPart SPFx est installé depuis Microsoft AppSource (ou un catalogue d'applications du locataire), le package de l'application Teams est installé par chargement latéral ou depuis le magasin d'applications de l'organisation, et le backend Azure est déployé dans l'abonnement propre du client par l'une des deux méthodes suivantes :

  • Portail Azure (recommandé) — déploiement en un clic de toutes les ressources Azure (App Service, SQL, Blob Storage, Application Insights) via ARM/Bicep. L'API est déployée par zipdeploy pendant le déploiement ARM; le code est téléchargé une seule fois depuis le CDN de l'éditeur et stocké dans l'App Service du client, sans aucune dépendance externe au moment de l'exécution. Le client conserve la pleine propriété du groupe de ressources.
  • Modèle Bicep + script PowerShell (manuel) — pour les organisations ayant un contrôle des changements strict. Un bouton Deploy to Azure ou le script Deploy-AccessPoint.ps1 déploie l'infrastructure, configure l'authentification Entra uniquement pour SQL, accorde les permissions Microsoft Graph à l'identité managée, configure les entités de stockage du locataire SharePoint et approuve les demandes de permission API du SPFx. Chaque étape peut être ignorée indépendamment.

Le déploiement est sécurisé par défaut : TLS 1.3, FTPS désactivé, authentification de base SCM/FTP désactivée, et HTTP/2 activé. L'API intègre son DacPac de base de données et l'applique au démarrage via un service de migration utilisant DacServices.Deploy(upgradeExisting: true) — une opération sans effet si le schéma est déjà à jour, et un delta additif et non destructif après une modification de schéma (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). Le résultat de la migration est exposé via /api/health. Après le déploiement, un administrateur accorde le consentement pour l'application d'entreprise Realizer (notifications Teams), configure la boîte aux lettres d'envoi et importe un pack de configuration propre à sa juridiction.

Authentification et identité

AccessPoint utilise Microsoft Entra ID comme unique fournisseur d'identité. Il n'existe aucun compte utilisateur ni mot de passe propre à l'application. Le composant WebPart SPFx acquiert un JWT pour l'audience de l'API via AadHttpClient; l'API valide l'émetteur, l'audience, la signature et l'expiration à chaque demande. Les politiques d'AMF et d'accès conditionnel configurées dans le locataire s'appliquent intégralement.

User (Browser)                SharePoint Online           AccessPoint API
     │                              │                          │
     │  1. Load SPFx web part       │                          │
     │─────────────────────────────►│                          │
     │                              │                          │
     │  2. AadHttpClient.getClient()│                          │
     │  (SPFx acquires token for    │                          │
     │   api://<client-id> audience)│                          │
     │                              │                          │
     │  3. API call + Bearer token  │                          │
     │──────────────────────────────┼─────────────────────────►│
     │                              │                          │
     │                              │  4. Validate JWT:        │
     │                              │     - Issuer (Entra ID)  │
     │                              │     - Audience (api://)  │
     │                              │     - Signature          │
     │                              │     - Expiry             │
     │                              │                          │
     │                              │  5. UserUpsertMiddleware: │
     │                              │     Extract claims →     │
     │                              │     Upsert Users table   │
     │                              │                          │
     │                              │  6. RoleAuthorization:   │
     │                              │     Check UserRoles table│
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│
Paramètre Valeur
Fournisseur d'identité Microsoft Entra ID (Azure AD)
Protocole OAuth 2.0 / OpenID Connect
Type de jeton JWT Bearer
Audience api://<client-id> et <client-id> (jetons v1 et v2 acceptés)
Émetteur https://login.microsoftonline.com/{tenantId}/v2.0 et https://sts.windows.net/{tenantId}/
Inscription de l'application Mono-locataire (AzureADMyOrg); portée exposée access_as_user; aucun secret client

Identité managée

L'App Service utilise une identité managée attribuée par le système pour s'authentifier auprès des services principaux, de sorte qu'aucun secret client ni certificat n'est stocké dans l'application :

  • Azure SQL Database — authentification Entra uniquement (l'authentification par mot de passe SQL est désactivée)
  • Azure Blob Storage — DefaultAzureCredential (identité managée en production)
  • API Microsoft Graph — ManagedIdentityCredential avec des permissions d'application

Les identifiants de l'identité managée sont renouvelés automatiquement par Azure.

Autorisation et RBAC

AccessPoint met en œuvre un contrôle d'accès basé sur les rôles au niveau applicatif, stocké dans Azure SQL et appliqué au niveau de l'API à chaque demande.

Rôle Voit les RPI du demandeur Gère les demandes Gère les assignations Soumet des documents Utilisateur type
Administrator Oui Config uniquement Non Non Admin TI, propriétaire du système
SAO Oui Oui Oui Non Agent d'accès et de protection de la vie privée
Reviewer Oui Lecture seule Lecture seule Non Conseiller juridique, AQ
Custodian Non Non Ses assignations Non Agent des documents du ministère
Contributor Non Non Non Ses tâches Expert en la matière
Reader Non Lecture seule Lecture seule Non Surveillance, audit

Points d'application :

  1. Politiques d'autorisation de l'API — attributs ASP.NET Core [Authorize(Policy = "...")] sur chaque action de contrôleur
  2. RoleAuthorizationHandler — vérifie la table UserRoles pour l'appartenance de l'utilisateur authentifié à un rôle
  3. ResourceOwnerAuthorizationHandler — valide la propriété au niveau des ressources (par exemple, un Contributor ne peut accéder qu'à ses propres tâches)
  4. PiiFilterMiddleware — supprime les champs RPI du demandeur des réponses JSON pour les rôles restreints (Custodian, Contributor, Reader)

Tous les points de terminaison API en écriture appliquent les rôles côté serveur au niveau du contrôleur. La reclassification des documents tient compte de la portée — seule la personne qui a collecté un document peut le reclasser — et une fois qu'une demande est clôturée, les mutations sur son graphe d'objets renvoient HTTP 409, à l'exception d'un petit ensemble d'exceptions délibérées (correspondance postérieure à la clôture, purge de rétention et réouverture). Les rôles ont une portée et peuvent être limités à des ressources spécifiques (portée globale, demande, assignation ou tâche). Le premier utilisateur à accéder au système se voit automatiquement attribuer les rôles Administrator et SAO.

Résidence et souveraineté des données

Toutes les données résident dans le locataire Azure du client, dans la région sélectionnée lors du déploiement. Aucune donnée n'est transmise ou stockée dans d'autres régions, sauf si le client configure explicitement la géoréplication Azure.

Ministères fédéraux canadiens : pour les exigences de résidence des données propres au GC, la correspondance des contrôles ITSG-33 et la conformité aux balises de sécurité infonuagique du GC, consultez la Référence des contrôles de sécurité du GC.

Emplacements des données du client

Type de données Emplacement de stockage Contrôlé par
Dossiers de demandes, données utilisateur, piste d'audit Azure SQL Database Abonnement Azure du client
Documents téléversés Azure Blob Storage Abonnement Azure du client
Télémétrie applicative Application Insights / Log Analytics Abonnement Azure du client
Ressources du composant WebPart SPFx CDN SharePoint Locataire M365 du client
Configuration du locataire (URL de l'API, ID client) Entités de stockage du locataire SharePoint Locataire M365 du client

Ce qui traverse les limites du locataire

Flux de données Direction Ce qui est transmis Objectif
Validation de licence API → Plateforme de l'éditeur Clé de licence (chaîne opaque), ID du locataire Valider l'abonnement actif
Notifications par courriel API → Microsoft Graph Contenu du courriel via Mail.Send Envoyer des notifications depuis la boîte aux lettres partagée
Notifications Teams API → Plateforme de l'éditeur → Microsoft Graph Type d'activité, texte d'aperçu, ID du destinataire, paramètres du modèle Envoyer des notifications du flux d'activité Teams (relayées par l'application d'entreprise multi-locataire de l'éditeur, car sendActivityNotification doit être appelée par l'application qui possède le manifeste Teams)
Recherche de profil utilisateur SPFx → Microsoft Graph Requêtes de recherche d'utilisateur Sélecteur de personnes, résolution d'utilisateur

Ce qui ne quitte jamais le locataire

  • Dossiers de demandes et RPI du demandeur
  • Documents téléversés
  • Historique d'audit
  • Données de configuration (types de demandes, modèles, numérotation)
  • Attributions de rôles

Chiffrement

En transit

Connexion Protocole TLS minimum
Navigateur → App Service HTTPS (appliqué, httpsOnly: true) TLS 1.3
SPFx → App Service HTTPS (appliqué par le contexte SharePoint) TLS 1.3
App Service → Azure SQL TDS avec chiffrement (Encrypt=True) TLS 1.2+
App Service → Blob Storage HTTPS (identité managée) TLS 1.2+
App Service → Microsoft Graph HTTPS TLS 1.2+

L'App Service applique TLS 1.3 comme minimum en périphérie (TLS 1.0/1.1/1.2 rejetés); les connexions sortantes vers les services principaux Azure négocient TLS 1.2 ou supérieur.

Au repos

Magasin de données Chiffrement Gestion des clés
Azure SQL Database Transparent Data Encryption (TDE) Clés gérées par Microsoft (par défaut) ou clés gérées par le client (CMK)
Azure Blob Storage Storage Service Encryption (SSE), AES-256 Clés gérées par Microsoft (par défaut) ou clés gérées par le client (CMK)
Application Insights Chiffrement de la plateforme Clés gérées par Microsoft

Au niveau applicatif

Fonctionnalité Mécanisme
Jetons du visualiseur de documents ASP.NET Core Data Protection (jeton de type WOPI, durée de vie de 15 minutes, validation croisée du locataire à chaque appel anonyme du visualiseur)
Signatures électroniques d'attestation Hachage SHA-256 du signataire et de l'horodatage, stocké dans les champs d'audit

Protection de la vie privée dès la conception

AccessPoint met en œuvre des contrôles de protection de la vie privée structurels, appliqués au niveau de l'API et non pas seulement dans l'interface utilisateur.

Intergiciel de filtrage des RPI

Un intergiciel au niveau des réponses intercepte toutes les réponses JSON et supprime les champs RPI pour les utilisateurs ayant des rôles restreints (Custodian, Contributor, Reader), côté serveur, indépendamment de ce que demande le client. Champs supprimés : requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth.

Masquage des RPI dans les notifications

Lorsque des notifications sont envoyées aux Custodian ou aux Contributor, les RPI du demandeur sont remplacés par un texte générique dans le contenu même de la notification — même si le modèle de notification comprend des champs de fusion RPI.

Isolation Custodian / Contributor

  • Les Custodian ne voient que leurs demandes assignées et travaillent à partir d'instructions épurées
  • Les Contributor ne voient que leurs tâches assignées
  • Aucun de ces rôles ne peut rechercher, parcourir ou accéder à des demandes en dehors de sa portée

Journalisation, surveillance et audit

Application Insights

Toute la télémétrie de l'API est envoyée à l'instance Application Insights du client :

Signal Ce qui est capturé
Traces de demandes Méthode HTTP, chemin, code de statut, durée, ID de corrélation
Suivi des dépendances Requêtes SQL, opérations Blob, appels API Graph (durée, succès/échec)
Exceptions Exceptions non gérées avec traces de pile
Métriques personnalisées Temps de traitement des demandes, durées de conversion des documents

Piste d'audit

AccessPoint maintient une piste d'audit complète dans la table AuditHistory (Azure SQL), qui enregistre le type d'entité, l'ID de l'entité, l'action (Create, Update, Delete, StatusChange), le nom du champ, les anciennes et nouvelles valeurs, un motif de changement facultatif (saisi lors des transitions de statut telles que la clôture et la réouverture), l'utilisateur authentifié et un horodatage UTC. Les enregistrements d'audit sont immuables — ils ne peuvent être ni modifiés ni supprimés via l'API.

Registre d'audit chaîné par hachage

En plus de la piste d'audit au niveau des champs, un registre AuditLedger inviolable et à ajout seul (chaîne de hachage SHA-256) enregistre les actions de tous les modules. Son intégrité peut être vérifiée côté serveur, et un dossier de preuves prêt pour un tribunal peut être exporté pour une demande.

Concurrence optimiste

Les entités à forte contention (Requests, Documents, CustodianAssignments) portent chacune un jeton de concurrence SQL Server ROWVERSION. Le client renvoie la version de la ligne lors de la mise à jour; si un autre auteur a modifié la ligne entre-temps, l'enregistrement est rejeté avec HTTP 409 (« Concurrent edit detected ») plutôt que d'être écrasé silencieusement.

Journal de purge de rétention

Lorsque des enregistrements sont purgés en vertu de la politique de rétention, la purge supprime les blobs de documents, les PDF convertis, les annotations et les dossiers d'exportation de Blob Storage, en plus des enregistrements de la base de données. La table RetentionPurgeLog consigne ce qui a été supprimé, quand et par qui — une piste de qualité conformité qui survit à la suppression des données.

Log Analytics et alertes

Application Insights s'appuie sur un espace de travail Log Analytics avec une rétention configurable (90 jours par défaut; configurable de 30 à 730 jours). Les données peuvent être exportées vers Microsoft Sentinel ou un SIEM existant. Le déploiement Bicep comprend deux alertes métriques par défaut sur l'App Service :

Alerte Gravité Condition Fenêtre
Erreurs serveur 2 (Avertissement) Nombre d'erreurs HTTP 5xx > 5 5 minutes
Latence élevée 3 (Information) Temps de réponse moyen > 5 secondes 15 minutes

Les clients peuvent personnaliser les seuils et ajouter des groupes d'actions (courriel, SMS, webhook) dans le portail Azure.

←
Previous Premiers pas avec AccessPoint
Next Référence des contrôles de sécurité du GC
→