Vos données,
bien gardées.

Objet et portée

Cette politique s’applique :

• à l’application Web, à l’API et aux applications iOS et Android de Minori;
• aux bases de données, au serveur de production à Montréal, à Coolify et aux tâches planifiées;
• aux comptes de fournisseurs : Plaid, AWS, GitHub, Apple, Google, registraire de domaines, messagerie;
• aux postes de travail et appareils utilisés pour administrer ces systèmes;
• à toute personne qui accède à ces systèmes, y compris un contractuel.

Rôles et responsabilités

• Le responsable approuve cette politique, tient les registres (accès, incidents, exceptions, fins de vie), décide des accès et répond aux demandes des utilisateurs et des autorités. Il est aussi le responsable de la protection des renseignements personnels au sens de la loi québécoise sur le secteur privé.
• Un contractuel ou un employé n’accède aux systèmes qu’après une entente écrite de confidentialité, avec les seuls accès nécessaires à son mandat. Ses accès sont retirés le jour où le mandat se termine.

Classification des données

Les environnements de développement et de préproduction utilisent uniquement des données fictives. Les données réelles n’existent qu’en production.

Contrôle d’accès

• Moindre privilège. Chaque personne et chaque service reçoit seulement les droits nécessaires.
• Rôles de base de données distincts. Le rôle de migration est séparé de celui de l’application, qui n’a aucune lecture directe des secrets bancaires. Ceux-ci passent par des fonctions contrôlées et liées au propriétaire de la connexion.
• Comptes nominatifs. Aucun compte d’administration partagé.
• Accès au serveur par clé SSH uniquement, l’authentification par mot de passe étant désactivée. La base de données n’est pas exposée à Internet.
• Accès aux données d’un utilisateur seulement pour répondre à sa demande, à un incident ou à une obligation légale. Chaque accès est consigné.
• Revue trimestrielle de tous les accès (serveur, Coolify, base de données, fournisseurs), consignée dans le registre des accès.
• Retrait des accès le jour même du départ d’une personne, et changement des secrets qu’elle connaissait.

Authentification

Administration

• MFA obligatoire sur tous les comptes d’administration et de fournisseurs. Passkey ou clé matérielle lorsque le service l’offre, sinon application d’authentification. Le SMS n’est accepté que si aucune autre méthode n’existe.
• Mots de passe uniques, générés et conservés dans un gestionnaire de mots de passe.

Utilisateurs

• Mot de passe d’au moins 12 caractères et vérification de l’adresse courriel à l’inscription.
• Deuxième facteur : code à usage unique par courriel lors d’une connexion depuis un nouvel appareil, et avant chaque connexion d’une banque. Les passkeys deviennent ensuite la méthode de connexion principale.
• Sessions limitées à 30 jours, révoquées à la déconnexion et lors de la fermeture du compte.

Chiffrement et gestion des clés

• En transit : TLS 1.2 ou plus récent pour tout échange entre les applications et le serveur, et entre le serveur et ses fournisseurs.
• Au repos : base de production sur un volume chiffré (LUKS) dont la clé est elle-même chiffrée par AWS KMS et jamais conservée en clair sur le disque.
• Jetons Plaid : chiffrement supplémentaire dans l’application, par enveloppe AES-256-GCM. Chaque clé de données est protégée par AWS KMS et liée au propriétaire et à la connexion.
• Sauvegardes chiffrées avant de quitter le serveur.
• Clés maîtresses dans AWS KMS, région ca-central-1 (Montréal), avec rotation automatique annuelle. Les identifiants AWS du serveur ne permettent que les opérations nécessaires.
• Secrets applicatifs changés au moins une fois par an, et immédiatement après un incident ou un départ.

Gestion des secrets

• Les secrets vivent dans les variables d’environnement privées de chaque environnement ou dans des fichiers privés exclus de Git, lisibles par leur seul propriétaire.
• Un secret n’est jamais écrit dans le code, un journal, une capture, un courriel, un ticket ou une conversation.
• Le responsable tient un inventaire des secrets : usage, environnement, date de dernière rotation.
• Un secret exposé ou soupçonné de l’être est révoqué et remplacé immédiatement, et l’événement est traité comme un incident.

Développement et mises en production

• Chaque changement est relu avant sa mise en production.
• Les tests automatisés (unitaires, base de données, isolation des espaces, parcours principaux), la vérification des types et la construction réussissent avant tout déploiement.
• Les dépendances sont verrouillées par des fichiers de verrouillage et des versions épinglées.
• Les entrées sont validées côté serveur. Les notifications des fournisseurs (webhooks) sont vérifiées par signature avant traitement.
• Les jetons durables des fournisseurs restent côté serveur et ne sont jamais transmis aux applications Web ou mobiles.
• Les environnements de développement, de préproduction et de production sont séparés, avec des secrets distincts.

Gestion des vulnérabilités et des correctifs

• npm audit et analyse des vulnérabilités (Trivy) dans l’intégration continue, avant chaque mise en production et chaque semaine.
• Mises à jour de sécurité automatiques et quotidiennes du système du serveur (Ubuntu LTS). Les mises à jour du noyau sont appliquées lors d’un redémarrage planifié.
• Postes de travail : mises à jour automatiques, disque chiffré, verrouillage automatique.

Une vulnérabilité activement exploitée est traitée comme un incident. Le responsable tient la liste des logiciels de production (système du serveur, Node.js, PostgreSQL, Coolify, dépendances majeures) avec leur date de fin de support, et planifie leur migration avant cette date.

Journalisation et surveillance

• Les journaux applicatifs ne contiennent ni secret, ni jeton, ni contenu bancaire (montants, marchands, libellés).
• Le journal d’audit enregistre seulement des métadonnées minimales sur les exportations, restaurations, effacements et changements de partage.
• La disponibilité du service et les erreurs de synchronisation sont surveillées.
• La conservation des journaux suit la politique de conservation et de suppression.

Sauvegardes et continuité

• Sauvegarde quotidienne de la base de production, chiffrée avant envoi vers un stockage AWS S3 au Canada (ca-central-1).
• Conservation de 30 jours, avec suppression automatique.
• Test de restauration chaque trimestre, consigné.

Fournisseurs et sous-traitants

• Avant d’utiliser un fournisseur qui traite des renseignements personnels, le responsable évalue sa sécurité, le lieu de traitement et le contrat.
• Une évaluation des facteurs relatifs à la vie privée précède toute communication de renseignements hors Québec. Une entente écrite encadre l’usage des données, la confidentialité, l’avis d’incident et la fin du contrat.
• La liste des fournisseurs et de leurs lieux de traitement figure dans la politique de confidentialité. Elle est revue chaque année.

Gestion des incidents

1. Détecter et consigner l’événement dans le registre des incidents.
2. Contenir : révoquer les accès ou secrets touchés, isoler le système, retirer au besoin les connexions bancaires concernées.
3. Évaluer le risque de préjudice sérieux pour les personnes concernées.
4. Aviser sans délai la Commission d’accès à l’information et les personnes concernées si le risque de préjudice est sérieux, ainsi que les fournisseurs selon les ententes, notamment Plaid pour tout incident touchant des données reçues de Plaid.
5. Corriger la cause, puis documenter les leçons apprises.

Chaque incident de confidentialité reste au registre au moins cinq ans.

Sécurité physique et appareils

• Les serveurs sont hébergés chez un fournisseur en centre de données à Montréal.
• Les appareils d’administration ont un disque chiffré, un verrouillage automatique, un système à jour et le MFA sur la session lorsqu’il est disponible.
• Aucune donnée de production n’est copiée sur un poste de travail, sauf nécessité temporaire, sous forme chiffrée et supprimée ensuite.

Sensibilisation et exceptions

Le responsable relit cette politique et les bonnes pratiques de sécurité au moins une fois par an. Toute personne qui obtient un accès lit cette politique et s’engage à la respecter avant de recevoir cet accès.

Une exception est écrite, motivée, approuvée par le responsable, limitée dans le temps et inscrite au registre des exceptions.

Annexe : état de mise en œuvre

Mis à jour à chaque changement. Les mesures marquées « à faire » seront en place avant l’accueil de données bancaires réelles.