Sécurité
Version en vigueur le .
En bref
- Chaque entreprise est isolée des autres au niveau de la base de données, et les accès par rôle sont vérifiés par le serveur à chaque requête.
- Mots de passe jamais conservés en clair, double authentification obligatoire pour les propriétaires et gestionnaires, jetons et secrets chiffrés.
- Un agent IA ne peut pas envoyer, réserver, annuler ou payer sans l'approbation d'une personne.
- Nous décrivons ici seulement ce qui est réellement en place, et ce qui reste à faire. Pilotiko ne détient aucune certification de sécurité et n'a pas encore fait l'objet d'un audit externe.
- Vous avez trouvé une faille ? Écrivez à [À COMPLÉTER: courriel de signalement de vulnérabilités, ex. [email protected]].
1. Architecture
Pilotiko est une application web (Python) avec une base de données PostgreSQL, derrière un serveur frontal (Caddy) qui gère le HTTPS. Hébergement : [À COMPLÉTER: qui héberge les serveurs de production (ex. vos propres machines, ou le nom de l'hébergeur)], [À COMPLÉTER: ville ou région et pays des serveurs de production et des sauvegardes (ex. Montréal, Québec, Canada)]. Les fichiers téléversés sont stockés : [À COMPLÉTER: où sont gardés les fichiers téléversés (disque local du serveur, ou nom du service S3 et sa région)]. Le site public et l'application n'utilisent aucun script tiers, aucun réseau de diffusion de contenu externe et aucun traceur.
2. Chiffrement en transit
- Le trafic vers Pilotiko passe en HTTPS ; les certificats (Let's Encrypt) sont obtenus et renouvelés automatiquement par le serveur frontal.
- Les témoins de session portent les attributs
HttpOnly,SameSite=Laxet, en production,Secure. - Les appels vers nos fournisseurs (envoi de courriels, IA, téléphonie, paiement, connexions OAuth) se font en HTTPS.
3. Chiffrement au repos
- Chiffrés par l'application (AES-256-GCM) : les jetons d'accès et d'actualisation des outils connectés, les clés d'API confiées (téléphonie, DNS, prise de rendez-vous), les secrets de double authentification. La clé de chiffrement est fournie au serveur par une variable d'environnement ou un fichier protégé, jamais par le dépôt de code.
- Jamais conservés en clair : les mots de passe (empreinte scrypt avec sel), les jetons de session, les liens de vérification et de réinitialisation, les codes de secours (empreintes SHA-256).
- Copies de sauvegarde hors machine : chiffrées (AES-256-GCM) avec une clé distincte de celle de l'application ; une copie non chiffrée vers une destination externe est refusée.
- Chiffrement des disques des serveurs : [À COMPLÉTER: les disques des serveurs de production et de sauvegarde sont-ils chiffrés (ex. « oui, LUKS sur les deux machines ») ? Phrase publiée telle quelle].
4. Authentification et contrôle d'accès
- Mots de passe d'au moins 14 caractères ; les mots de passe courants, ou contenant votre courriel ou votre nom, sont refusés.
- Double authentification par application d'authentification (TOTP), avec codes de secours. Obligatoire pour les propriétaires et gestionnaires après un délai de grâce de 7 jours, recommandée pour tous. La désactiver exige le mot de passe.
- Le courriel doit être vérifié avant d'accéder à une entreprise. La réinitialisation du mot de passe ferme toutes les sessions ouvertes. Les écrans de connexion et de mot de passe oublié ne révèlent pas si un compte existe.
- Limites de débit sur la connexion, l'inscription, le mot de passe oublié, les codes de double authentification, les formulaires publics et les écritures par entreprise ; les compteurs ne conservent qu'une empreinte de l'adresse IP ou du courriel.
- Rôles (propriétaire, gestionnaire, employé) vérifiés par le serveur à chaque requête, jamais seulement par l'interface.
- Accès de notre équipe : les pages d'exploitation sont réservées à une liste nominative d'exploitants ; l'accès direct à la base de production est limité aux administrateurs de l'infrastructure.
5. Isolation entre entreprises
- Chaque donnée métier porte l'identifiant de son entreprise. L'application s'exécute avec un rôle de base de données sans privilège, soumis à la sécurité au niveau des lignes forcée : une requête ne voit que les lignes de l'entreprise de la transaction en cours.
- Des clés étrangères composées interdisent qu'une entreprise référence les lignes d'une autre.
- L'adresse d'une entreprise à laquelle vous n'appartenez pas répond « introuvable » : l'existence des autres ne fuit pas.
- Ces garanties sont vérifiées par des tests automatiques qui forgent des requêtes entre entreprises.
6. Agents IA
- Toute action à risque préparée par un agent (envoi externe, réservation, annulation, paiement) attend l'approbation d'une personne autorisée ; la base de données refuse une telle exécution sans l'identité de la personne qui l'a approuvée. Une proposition expirée n'exécute rien.
- Les secrets sont retirés des requêtes avant tout envoi au modèle. Une entreprise peut choisir la confidentialité stricte : aucune requête n'est alors envoyée à un fournisseur d'IA externe.
- L'usage de l'IA est plafonné par entreprise ; en cas de dépassement ou de panne, l'assistant revient à ses règles.
7. Journaux d'audit
Les actions importantes (connexion d'un outil, approbation, modification de réglages, actions des agents) sont inscrites dans un journal d'audit en ajout seul : le rôle de l'application peut y écrire, pas modifier ni effacer. Le journal technique des requêtes ne contient ni adresse IP ni navigateur, et les valeurs sensibles (jetons, mots de passe) sont masquées dans les journaux.
8. Sauvegardes et reprise
- Sauvegarde quotidienne de la base, vérifiée par une restauration dans une base jetable ; les 7 dernières sont conservées.
- Copie hors machine : [À COMPLÉTER: où va la copie chiffrée hors machine des sauvegardes (OQEL_BACKUP_TARGET), ou « aucune pour l'instant »]. Les copies hors machine sont toujours chiffrées.
- Une procédure de restauration documentée existe et peut être exercée.
9. Gestion des secrets et du code
- Aucun secret dans le dépôt de code : les clés sont fournies au serveur par l'environnement. Les secrets de la plateforme peuvent être gardés dans un coffre chiffré.
- Les dépendances logicielles sont figées par un fichier de verrouillage, et chaque modification passe par une suite de tests automatiques.
- En-têtes de sécurité : politique de sécurité du contenu (aucun script externe), interdiction d'affichage dans un cadre,
X-Content-Type-Options: nosniff, politique de référent restrictive. Les pages de ce centre de confiance ajoutentStrict-Transport-SecurityetPermissions-Policy. - Protection contre les requêtes inter-sites (vérification de l'origine) sur toutes les actions qui modifient des données.
10. Surveillance et incidents
L'application mesure en continu les taux d'erreurs et les temps de réponse et signale à l'exploitant toute anomalie grave (par exemple, une page qui échoue massivement). En cas d'incident de sécurité touchant des renseignements personnels, nous suivons la procédure décrite dans la politique de confidentialité : limiter les dégâts, évaluer le risque de préjudice, aviser la Commission d'accès à l'information et les personnes concernées si le risque est sérieux, et aviser sans délai les entreprises clientes touchées.
11. Ce qui n'est pas encore en place
Par transparence, voici les améliorations prévues que nous ne prétendons pas avoir :
- l'en-tête
Strict-Transport-Securitysur toutes les pages de l'application (aujourd'hui : seulement sur les pages de ce centre de confiance) ; - le chiffrement des sauvegardes locales conservées sur le serveur (seules les copies hors machine sont chiffrées) ;
- l'effacement automatique des sessions expirées et de certains journaux anciens ;
- la révocation automatique, chez le fournisseur, des autorisations OAuth lors d'une déconnexion (aujourd'hui : les jetons sont effacés chez nous ; la révocation chez le fournisseur se fait depuis votre compte) ;
- un test d'intrusion par une firme externe.
12. Signaler une vulnérabilité
Nous remercions les personnes qui nous signalent une vulnérabilité de façon responsable.
- Où : [À COMPLÉTER: courriel de signalement de vulnérabilités, ex. [email protected]] (voir aussi security.txt). Décrivez le problème, les étapes pour le reproduire et l'impact possible.
- Notre engagement : accuser réception dans les 5 jours ouvrables, vous tenir informé de la correction et, si vous le souhaitez, vous remercier publiquement.
- Règles : n'accédez qu'aux données de comptes qui vous appartiennent ; ne modifiez ni ne supprimez de données ; pas d'attaque par déni de service, d'ingénierie sociale ni de test physique ; laissez-nous un délai raisonnable avant toute divulgation publique.
- Nous n'engagerons pas de poursuites contre une personne qui respecte ces règles de bonne foi. Nous n'offrons pas de récompense financière pour l'instant.
Historique des modifications
| Date | Modification |
|---|---|
| Description détaillée des mesures et signalement de vulnérabilités. |
Version imprimable : utilisez la fonction Imprimer de votre navigateur.