GraphWarden et la LPRPDE (PIPEDA) : comment le proxy soutient vos obligations de conformité

La LPRPDE impose aux organisations privées canadiennes dix principes de protection des renseignements personnels pour toute collecte, utilisation ou communication de données dans le cadre d'activités commerciales. GraphWarden aide à respecter plusieurs de ces principes en centralisant le contrôle des accès à Microsoft Graph, en minimisant les données retournées et en produisant un journal d'audit vérifiable. Ce document associe chacun des dix principes aux capacités de GraphWarden, avec des limites explicites.

Pour qui ce document

- Organisation assujettie à la LPRPDE (secteur privé fédéral ou hors Alberta, Colombie-Britannique, Québec) - Politique de protection des renseignements personnels en place - Accès à l'application d'administration GraphWarden et à votre Azure Key Vault - Lecteurs visés : responsable de la protection des renseignements personnels, RSSI, équipe juridique et de conformité

Contexte de la LPRPDE

La LPRPDE — Loi sur la protection des renseignements personnels et les documents électroniques — a été adoptée par le Parlement du Canada en 2000 et encadre le traitement des renseignements personnels par les organisations du secteur privé dans le cadre d'activités commerciales. Elle repose sur dix principes de protection des renseignements personnels, issus du Code type sur la protection des renseignements personnels de l'Association canadienne de normalisation (CSA), annexés à la loi. Le Commissariat à la protection de la vie privée du Canada (CPVP) supervise son application, reçoit les plaintes et publie des lignes directrices.

Un cadre interprovincial s'applique : la LPRPDE ne vise pas le Québec (Loi 25), l'Alberta (PIPA) ni la Colombie-Britannique (PIPA BC), qui ont adopté des lois jugées substantiellement similaires. Le projet de loi C-27 propose une modernisation de la LPRPDE (Loi sur la protection de la vie privée des consommateurs et Tribunal de la protection des renseignements personnels et des données); les obligations décrites ici reflètent le régime actuel, indépendamment de l'évolution législative en cours.

Mapping LPRPDE (PIPEDA) → capacités GraphWarden

Principe de la LPRPDE Capacité GraphWarden Statut Preuve technique
Principe 1 — Responsabilité Identités d'application dédiées par système intégré Aligned Chaque application intégrée à Graph a sa propre identité GraphWarden avec ruleset YAML versionné, rendant les responsabilités traçables.
Principe 2 — Détermination des fins Rulesets YAML documentant les endpoints permis Aligned Le ruleset de chaque identité d'application documente explicitement les endpoints Graph et les champs autorisés, servant d'artefact de détermination des fins.
Principe 3 — Consentement Non couvert par GraphWarden Not in scope Le consentement des personnes concernées relève de votre application, pas du proxy.
Principe 4 — Limitation de la collecte Filtres de réponse (Response Filter transforms) Aligned Configurer un Response Filter pour limiter les champs Graph retournés aux seuls nécessaires, implémentant la minimisation à la source.
Principe 5 — Limitation de l'utilisation, de la communication et de la conservation Blocage d'endpoints par ruleset Aligned Bloquer au niveau du ruleset les endpoints Graph qui dépassent les fins déterminées.
Principe 6 — Exactitude Non couvert directement Not in scope L'exactitude relève de votre application et des procédures internes.
Principe 7 — Mesures de sécurité Identifiants Graph dans votre Azure Key Vault (architecture à connaissance nulle) Aligned GraphWarden détient une permission get sur vos secrets Key Vault; les identifiants Graph ne transitent jamais par GraphWarden en clair.
Principe 8 — Transparence Rulesets publiables en interne Supported Le ruleset YAML est un artefact lisible par un humain, utilisable dans votre politique interne de transparence.
Principe 9 — Accès aux renseignements personnels Non couvert par GraphWarden Not in scope La gestion des demandes d'accès (Art. 4.9 LPRPDE) relève de votre application.
Principe 10 — Possibilité de porter plainte Journal d'audit comme preuve technique Supported Le journal d'audit HMAC-authentifié vers votre SIEM produit des preuves d'accès vérifiables utiles lors d'une enquête du CPVP.

Scénario concret

Un assureur canadien exploite dans 9 provinces (hors Québec) et intègre un système de ressources humaines SaaS à Microsoft 365. Sans GraphWarden, le fournisseur SaaS détient les identifiants Graph et peut interroger l'ensemble des utilisateurs du tenant. Avec GraphWarden, l'identité d'application du SaaS a un ruleset qui limite l'accès aux membres du groupe RH-Active et aux champs displayName, mail, jobTitle. Lors d'une enquête du CPVP (Principe 10), l'assureur produit le ruleset YAML et le journal d'audit comme preuve technique des contrôles d'accès en place durant la fenêtre visée.

Hébergement et résidence des données

Mode hébergé : le proxy fonctionne dans Azure Canada Central; le plan de contrôle s'exécute dans Canada East (OVHCloud). Mode sur site (Windows Service ou Docker) : le proxy s'exécute entièrement dans votre infrastructure — aucune donnée Graph ne quitte votre environnement. L'hébergement canadien maintient vos données sous juridiction canadienne, cohérent avec le périmètre de la LPRPDE. Les secrets Graph (client secrets, certificats) ne quittent jamais votre Azure Key Vault : GraphWarden n'en détient que l'empreinte SHA-256 pour authentifier les appels de vos applications.

Limites explicites

GraphWarden soutient plusieurs principes de la LPRPDE mais ne couvre pas l'ensemble du régime. Les éléments suivants restent sous votre responsabilité.

  • GraphWarden NE couvre PAS le consentement (Principe 3) — celui-ci relève de votre application et de vos processus métier.
  • GraphWarden NE couvre PAS l'exactitude des renseignements personnels (Principe 6).
  • GraphWarden NE couvre PAS l'accès aux renseignements personnels par les personnes concernées (Principe 9, Art. 4.9 LPRPDE).
  • GraphWarden NE détermine PAS à votre place les fins légitimes (Principe 2) — le proxy applique votre décision, il ne la prend pas.
  • GraphWarden NE NOTIFIE PAS les personnes concernées en cas d'atteinte à la confidentialité — ce processus demeure votre responsabilité.
  • GraphWarden NE remplace PAS votre responsable de la protection des renseignements personnels (Principe 1).

Préparer votre brief de conformité avec un assistant IA

Préparer un brief de conformité LPRPDE (PIPEDA)

Prépare un brief de conformité LPRPDE (PIPEDA) pour mon organisation utilisant GraphWarden avec Microsoft 365.

Je dois fournir à mon comité :
1. Pour chacun des 10 principes de la LPRPDE, ce que GraphWarden aide à satisfaire
2. Pour chaque principe, ce qui reste sous ma responsabilité
3. Les artefacts techniques que je peux extraire (rulesets, journaux d'audit)

Documentation de référence : https://graphwarden.com/llms.txt

Demande-moi :
- Ma province d'exploitation (PIPEDA ne s'applique pas au Québec / Alberta / Colombie-Britannique)
- Le nombre d'applications intégrées à Graph
- Si j'ai déjà une politique de protection des renseignements personnels

Reference: llms.txt

Troubleshooting

  • Mon organisation exploite au Québec — est-ce que la LPRPDE s'applique ? Non, la Loi 25 s'applique ; voir /fr/compliance/loi-25.
  • Le CPVP me demande un journal des accès sur 12 mois. Voir l'endpoint /audit dans Agent API et configurer un export périodique vers votre archive.
  • Comment démontrer que mon ruleset respecte le Principe 4 (limitation de la collecte) ? Exporter le YAML du ruleset et joindre comme annexe au brief de conformité.
  • Je reçois des données que je n'ai pas demandées. Vérifier le Response Filter du ruleset ; voir Rulesets et règles.
  • Comment distinguer les appels d'une application compromise ? Filtrer le journal d'audit sur l'identité d'application et sur la fenêtre de l'incident ; voir Identités d'application.

Ressources

Prochaines étapes

Pour une démo adaptée à votre conformité LPRPDE, contactez l'équipe GraphWarden. Parcourez les cas d'usage pour voir comment d'autres organisations privées canadiennes ont documenté leurs principes via rulesets. Apportez à la session : votre province d'exploitation, votre liste d'applications intégrées à Graph, et la rétention audit souhaitée (90 jours, 1 an, ou 7 ans).

Dernière revue :