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

Last updated: August 09, 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 (v2.0.67).

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
  • Assistance IA (en option) — suggestions et rédaction propulsées par Azure OpenAI, s'exécutant entièrement dans l'abonnement propre du client : résumés de documents, suggestions de caviardage par IA, rédaction ancrée, tri des demandes entrantes, préremplissage des réponses d'évaluation, recherche sémantique et détection des doublons, un assistant par dossier sensible à la législation (Demander à AccessPoint — citations cliquables, conversations enregistrées, un mode Mon portefeuille de dossiers), des réponses aux données « Demander à AccessPoint », un guide de juridiction qui ancre les réponses de procédure, traduction automatique et un résumé quotidien — tout est optionnel par locataire, journalisé uniquement au niveau des métadonnées, avec divulgation de l'activité de l'IA par enregistrement

Tous les modules sont pilotés par des paquets de juridiction, 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 override,          │         │  (222 tables, 3,410 fields)            │
│   optional)                  │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.ReadBasic.All  │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         │  (opt-in) Azure OpenAI                  │
        │  Calendars.Read      │         │  (opt-in) Azure Document Intelligence   │
        │  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.23.2 SharePoint Online / Teams du client Interface utilisateur pour tous les rôles
Teams App Manifeste Teams v1.19, version alignée sur la solution SPFx et ApiVersion.Current (estampillée par la CI) 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 (~103 contrôleurs, ~124 interfaces de service) 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 (222 tables, 3 410 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, plus recherche vectorielle sémantique (index des documents + des dossiers); provisionné uniquement lorsque deployAiSearch=true
Azure OpenAI (en option) Azure OpenAI Service Abonnement Azure du client Assistance IA — rédaction ancrée, suggestions, recherche sémantique, assistant de dossier (Demander à AccessPoint); authentification par identité managée (sans clés d'API), provisionné uniquement lorsque l'Assistance IA est déployée
Document Intelligence (en option) Azure AI Document Intelligence (prebuilt-read) Abonnement Azure du client OCR pour les numérisations image seule, alimentant la recherche de contenu, la détection des doublons, les résumés et les suggestions de caviardage; authentification par identité managée, provisionné uniquement lorsque deployDocumentIntelligence=true

Ce que l'éditeur exploite

Service Objectif
Realizer Platform Validation de licence, relais des notifications Teams, découverte de l'URL de l'API du SPFx, le routeur intelligent de l'onglet personnel Teams, et la page Finish Setup post-déploiement (aucune donnée de dossier client transmise)
AppSource Listing Distribution du package SPFx
Modèle de déploiement Modèle Bicep/ARM pour le backend Azure, déployé en un clic depuis le portail Azure dans l'abonnement du client
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 paquets de juridiction.

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, dossiers, familles de courriels, suivi de lecture, vues enregistrées, détection des doublons basée sur les décisions, aperçu Syncfusion, pipeline de caviardage avec exemptions et aller-retour XFDF, motifs de recherche et caviardage, suggestions de caviardage basées sur des règles et par IA, réutilisation des caviardages de demandes antérieures, assemblage des réponses avec fusion du papier à en-tête.
Demandeurs / Contacts Identité de demandeur réutilisable de première classe, contrôle du flux de réception, espace de travail de la conduite F&V (frivole ou vexatoire), 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, assignation 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 piloté par catalogue (tableaux de bord Report Studio), rapports statistiques annuels, tableaux de bord SLA/gestion, registre d'audit chaîné par hachage et exportations d'audit de dossier prêtes pour un tribunal.
Assistance IA (en option) Suggestions et rédaction propulsées par Azure OpenAI : résumés, suggestions de caviardage, rédaction ancrée, tri des demandes entrantes, suggestions de Custodian, préremplissage des évaluations et vérifications de cohérence, recherche sémantique et doublons, un assistant de dossier sensible à la législation — Demander à AccessPoint (citations cliquables, préparation de brouillon, conversations enregistrées) — ainsi qu'un assistant de portefeuille (Mon portefeuille de dossiers), un guide de juridiction prérempli par les paquets de juridiction, Demander à AccessPoint pour les rapports, résumé quotidien et récapitulatif de rattrapage, portefeuille de risques et analyse de la conduite. Bascules par fonctionnalité au niveau du locataire; journalisation limitée aux métadonnées (l'assistant peut en outre enregistrer des transcriptions privées propres au propriétaire du dossier).
Configuration et plateforme Importation de paquets de juridiction (1 paquet Universal Baseline + 106 paquets de juridiction, y compris les statuts automatiques de refus présumé propres à chaque type et l'ancrage IA optionnel), 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, ainsi que les ressources en option AI Search / Azure OpenAI / Document Intelligence) 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. Un choix obligatoire de type de déploiement protège les redéploiements : Nouvelle installation crée le serveur SQL Entra en premier (le principal effectuant le déploiement devient l'administrateur Entra initial, avec une authentification Entra uniquement dès l'origine — aucun identifiant SQL n'existe jamais), tandis que Mise à niveau d'une installation existante préserve les paramètres d'application de l'opérateur et laisse l'accès à la base de données intact. 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, réaffirme l'authentification Entra uniquement pour SQL (une protection de secours — le modèle l'applique déjà), accorde les permissions Microsoft Graph à l'identité managée (l'équivalent scripté de la page Finish Setup de l'éditeur), configure la substitution facultative de l'URL de l'API par entité de stockage SharePoint, et approuve les demandes de permission API du SPFx. Chaque étape peut être ignorée indépendamment.

Les permissions Graph sont normalement accordées par l'entremise de la page Finish Setup de l'éditeur — le déploiement produit une sortie finishSetupUrl qu'un administrateur Entra du client ouvre pour accorder chaque permission d'identité managée en une seule passe idempotente (à relancer après les mises à niveau pour récupérer les nouvelles permissions).

Le déploiement est sécurisé par défaut : TLS 1.3, FTPS désactivé, authentification de base SCM/FTP désactivée, HTTP/2 activé, et Microsoft Defender for SQL activé par défaut (option de retrait). 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 paquet de 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. PermissionService:   │
     │                              │     resolve roles +      │
     │                              │     permission grants    │
     │                              │                          │
     │     ◄── 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 L'émetteur de tout locataire Entra — les formats https://login.microsoftonline.com/{tenantId}/v2.0 (v2) et https://sts.windows.net/{tenantId}/ (v1) sont validés; la revendication tid du jeton détermine la portée du locataire
Inscription de l'application Application multi-locataire exploitée par l'éditeur, avec consentement accordé par chaque locataire client (aucune inscription d'application propre au client à gérer ou à faire pivoter); portée exposée access_as_user; aucun secret client. L'isolation entre les locataires clients est assurée par la revendication tid validée, ainsi qu'une vérification de licence/abonnement

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 (le serveur est créé Entra en premier; aucun identifiant SQL n'existe jamais)
  • Azure Blob Storage — DefaultAzureCredential (identité managée en production)
  • API Microsoft Graph — ManagedIdentityCredential avec des permissions d'application
  • Ressources IA en option (AI Search, Azure OpenAI, Document Intelligence) — identité managée uniquement, authentification locale/par clé désactivée

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

Autorisation et RBAC

AccessPoint met en œuvre un modèle de permissions granulaire et configurable par locataire, stocké dans Azure SQL et appliqué au niveau de l'API à chaque demande : un catalogue de codes de permission atomiques défini par le produit (p. ex. request.modify, document.view, redaction.approve, request.view.pii) est regroupé en rôles, et chaque action de contrôleur est subordonnée à un code de permission.

Type de rôle Rôles Notes
Rôle système Administrator (le seul rôle permanent intégré) Résolu à l'ensemble des permissions du catalogue — calculé à partir du catalogue, non de données d'amorçage en base — de sorte qu'il ne peut jamais être verrouillé; immuable et impossible à supprimer.
Rôles de relation Reviewer, Custodian, Contributor, Reader, Advisor Ensembles de permissions définis par le produit, conférés automatiquement et par cible en fonction des relations de travail/collaboration (assignation de Custodian, tâche de Contributor, révision, appartenance d'Advisor/Reader). Non attribuables directement, limités à l'enregistrement concerné, et n'incluent jamais les RPI du demandeur.
Rôles de locataire p. ex. Coordonnateur des demandes (fourni via le paquet Universal Baseline), ainsi que tout rôle personnalisé Ensembles de permissions entièrement modifiables, gérés dans Paramètres > Rôles et permissions. Les rôles de coordonnateur/agent sont entièrement définis par le locataire — le Coordonnateur des demandes fourni par le pack est le rôle de facto d'agent d'accès et de protection de la vie privée.
Rôle Voit les RPI du demandeur Accès type Utilisateur type
Administrator Oui Tout (toutes les permissions du catalogue) Admin TI, propriétaire du système
Coordonnateur des demandes (rôle de locataire) Oui Gère les demandes, les assignations, les caviardages, la correspondance Agent d'accès et de protection de la vie privée
Reviewer Non Lecture + signalement/résolution des enjeux de caviardage sur les demandes en révision Conseiller juridique, AQ
Advisor Non Lecture + visualisation/signalement des caviardages (ne les applique ni ne les approuve jamais) Conseiller externe, expert en la matière
Custodian Non Ses assignations et leurs documents Agent des documents du ministère
Contributor Non Ses tâches et leurs documents Expert en la matière
Reader Non Lecture seule sur les demandes associées et les documents partagés Surveillance, audit

Points d'application :

  1. Attributs [RequirePermission(code)] — un fournisseur de politiques dynamique associe chaque action de contrôleur à un code de permission du catalogue
  2. PermissionService — résout les permissions effectives de l'appelant (rôles permanents combinés aux octrois de relation par cible), avec des vérifications limitées à l'objet au niveau de la demande, du document, de l'assignation ou de la tâche
  3. Vérifications de propriété au niveau des ressources — par exemple, un Contributor ne peut accéder qu'à ses propres tâches; un Custodian, qu'à ses propres assignations
  4. PiiFilterMiddleware — supprime les champs RPI du demandeur des réponses JSON pour tout appelant qui ne détient pas la permission de visualisation des RPI du demandeur

Tous les points de terminaison API en écriture appliquent les permissions 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 attributions de rôle permanent ont une portée définie (globale, demande, assignation ou tâche), sont facultativement limitées dans le temps, et les rôles de relation ne sont jamais inscrits comme attributions permanentes — ils sont dérivés par cible à partir des enregistrements de travail sous-jacents. Le premier utilisateur à accéder au système se voit attribuer d'office le rôle Administrator, et une protection côté serveur empêche de retirer le dernier Administrator actif.

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
Substitution de l'URL de l'API (facultative) Entité de stockage du locataire SharePoint Locataire M365 du client (la découverte principale se fait via le point de découverte d'API de l'éditeur)
Index de recherche IA, résumés, sortie OCR (en option) Azure AI Search / Azure SQL Abonnement Azure 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 Jeton d'identité managée Entra (la revendication tid du jeton identifie le locataire), version de l'API, et l'URL de base propre à l'API (auto-enregistrement pour la découverte par le composant web) Valider l'abonnement actif; la réponse transporte également la dernière version publiée d'AccessPoint, afin que le panneau Configuration puisse afficher un avis « Mise à jour disponible » (numéros de version uniquement — aucune donnée d'utilisation ni de dossier)
Découverte de l'URL de l'API SPFx → Plateforme de l'éditeur Jeton Bearer (revendication d'ID de locataire seulement) Résoudre l'URL de base de l'API du client lorsqu'aucune substitution par entité de stockage n'est définie
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 (optionnel — modulable / éliminable) API → Plateforme de l'éditeur → Microsoft Graph Type d'activité, GUID du destinataire et du locataire, titre/texte d'aperçu de la notification, nom de l'utilisateur agissant, numéro de demande, ID d'enregistrement (lien profond) 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). C'est le seul canal de notification qui quitte le locataire — le courriel et le flux intégré à l'application livrent les mêmes avis à l'intérieur du locataire. Voir Partage des données de notification 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
  • Invites et réponses de l'Assistance IA — lorsque l'Assistance IA est déployée, la ressource Azure OpenAI s'exécute dans l'abonnement et la région propres au client; Microsoft n'entraîne pas ses modèles sur le contenu, et le contenu des invites et des réponses n'est pas conservé (seulement des métadonnées d'utilisation, pour le compteur de budget et la divulgation de l'intervention de l'IA de l'exportation d'audit du dossier)
  • Notifications intégrées à l'application et par courriel/Outlook — le flux intégré à l'application est servi depuis la propre API du client; le courriel est envoyé depuis la propre boîte aux lettres partagée du client via Mail.Send. Aucun des deux ne transite par l'éditeur. Seul le flux d'activité Teams optionnel envoie des données hors du locataire, et même celui-ci peut être minimisé ou éliminé (ci-dessous)

Partage des données de notification Teams (facultatif)

Conformément à la promesse de souveraineté des données, la seule donnée du locataire qui franchit la limite pour les notifications est une charge utile d'activité Teams optionnelle — et elle peut être minimisée ou supprimée entièrement. Chaque notification est livrée sur jusqu'à trois canaux; deux sont toujours à l'intérieur du locataire (le flux intégré à l'application, servi depuis l'API du client, et le courriel/Outlook, envoyé depuis la propre boîte aux lettres partagée du client). Le flux d'activité Teams est une commodité : dans son mode par défaut, l'API du client envoie par POST une petite charge utile à l'application multi-locataire de l'éditeur, qui appelle Graph sendActivityNotification (laquelle doit être invoquée par l'application propriétaire du manifeste Teams). L'éditeur n'en conserve rien et ne consigne que les GUID du destinataire et du locataire.

Champs de la charge utile Teams par défaut (relayée par l'éditeur) — et ce que la bascule Minimiser retire :

Champ Contient Donnée personnelle? Retiré par Minimiser?
tenantId / recipientUserId GUID Entra du locataire et du destinataire Non — identifiants Non (acheminement)
activityType Énumération fixe du manifeste (p. ex. assignmentCreated) Non Non
previewText / topicText Aperçu et titre (nom d'assignation/de tâche, texte de la notification) Potentiellement (texte libre) Oui → valeur générique
actorName Nom d'affichage du membre du personnel agissant Oui — nom personnel Oui → « AccessPoint »
requestNumber Code de référence de la demande Non — référence Non (contexte)
relatedEntity + relatedRecordId Type d'enregistrement + GUID (lien profond) Non — identifiants Non (lien profond)

Les RPI du demandeur ne figurent jamais dans la charge utile — il n'existe aucun champ de nom ou de courriel du demandeur, et les notifications aux Custodian/Contributor sont de toute façon expurgées des RPI en amont. Deux contrôles resserrent encore cela :

  • Minimiser (Notifications:TeamsMinimalPayload, une bascule de locataire) remplace previewText, topicText et actorName par des valeurs génériques neutres, de sorte que les noms, les titres et le texte libre ne quittent jamais le locataire — seuls les identifiants d'acheminement et de lien profond le font. Aucune modification du manifeste n'est requise.
  • Éliminer (Notifications:TeamsRelayMode=Direct) fait en sorte que l'API du client appelle elle-même Graph sendActivityNotification avec sa propre identité managée, de sorte qu'aucune charge utile n'atteint l'éditeur. Cela exige le rôle d'application TeamsActivity.Send sur l'identité managée de l'API et que le webApplicationInfo.id du manifeste Teams pointe vers l'application propre du client — voir le Guide de déploiement.
Mode Charge utile transmise à l'éditeur RPI / texte libre quitte le locataire Effort de configuration
Relais par défaut Oui (champs ci-dessus) Noms/titres, sauf si minimisé Aucun
Bascule Minimiser Oui (identifiants seulement) Aucun Une bascule
Relais direct (auto-hébergé) Aucune Aucun Octroi d'identité managée + modification du manifeste
Teams désactivé Aucune Aucun (courriel + intégré à l'application seulement) Aucun

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 tout appelant qui ne détient pas la permission de visualisation des RPI du demandeur (les Custodian, Contributor, Reader, Reviewer et Advisor ne la détiennent jamais), côté serveur, indépendamment de ce que demande le client. Champs supprimés : requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, ainsi que les champs d'identité/coordonnées du représentant et les notes de vérification d'identité.

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 une exportation d'audit du dossier (anciennement « dossier de preuves ») prête pour un tribunal peut être générée 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

Un seul moteur RetentionService élimine les enregistrements expirés dans cinq registres — demandes, évaluations, incidents, plaintes et risques de confidentialité autonomes — piloté par un couple RetentionPeriodMonths + RetentionStartPoint propre à chaque type (NULL = conserver indéfiniment, valeur par défaut). Les enregistrements qui ne doivent jamais expirer sont exclus par construction (une évaluation En vigueur, un risque Accepté, un risque rattaché à un dossier), et un enregistrement expiré dont dépend encore un autre dossier ouvert est refusé côté serveur; l'admissibilité est réévaluée au moment de la purge. Lorsqu'un enregistrement est purgé, le moteur supprime les blobs de documents, les PDF convertis, les annotations et les packages 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 — EntityName identifie de quel registre il provient, accompagné d'un instantané de son numéro, de son type, de sa date de fermeture et de son nombre de documents — une piste de qualité conformité qui survit à la suppression des données et n'est elle-même jamais purgée.

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
→