Politique de sécurité

Introduction

La présente Politique de sécurité a pour objet de décrire l'ensemble des mesures techniques et organisationnelles mises en œuvre par Vincent CAHART pour assurer la sécurité du service Fatoom et la protection des données personnelles des utilisateurs, conformément à l'article 32 du Règlement Général sur la Protection des Données (RGPD) et aux obligations de sécurité prévues par la loi Informatique et Libertés.

Vincent CAHART s'engage à garantir un niveau de sécurité adapté aux risques présentés par le traitement des données personnelles, en tenant compte de l'état de l'art, des coûts de mise en œuvre, de la nature, de la portée, du contexte et des finalités du traitement, ainsi que des risques pour les droits et libertés des personnes physiques.

Article 1 - Architecture de sécurité

1.1. Infrastructure cloud sécurisée

Le service Fatoom est hébergé sur l'infrastructure Google Cloud Platform (GCP) et Firebase, qui bénéficient de certifications de sécurité internationales reconnues, notamment :

• ISO/IEC 27001 : Norme internationale pour les systèmes de management de la sécurité de l'information
• ISO/IEC 27017 : Contrôles de sécurité spécifiques aux services cloud
• ISO/IEC 27018 : Protection des données personnelles dans le cloud
• SOC 2 Type II : Certification de conformité aux contrôles de sécurité, disponibilité, intégrité du traitement, confidentialité et protection de la vie privée
• Conformité RGPD : Google Cloud Platform respecte les exigences du RGPD et s'engage contractuellement en tant que sous-traitant

1.2. Séparation des environnements

L'architecture du service Fatoom repose sur une séparation stricte entre l'environnement de production (accessible aux utilisateurs) et les environnements de développement et de test. Cette séparation garantit que les données de production ne sont jamais mélangées avec les données de test et que les modifications du code ne sont déployées en production qu'après avoir été testées et validées.

1.3. Principe du moindre privilège

L'accès aux ressources de l'infrastructure (bases de données, fichiers, fonctions cloud, journaux) est régi par le principe du moindre privilège : chaque composant du système et chaque utilisateur ne dispose que des autorisations strictement nécessaires à l'exécution de ses fonctions. Les autorisations sont définies au moyen de règles IAM (Identity and Access Management) de Google Cloud Platform et de Firebase Security Rules.

Article 2 - Authentification et contrôle d'accès

2.1. Authentification des utilisateurs

L'authentification des utilisateurs est assurée par Firebase Authentication, service d'authentification sécurisé fourni par Google. Firebase Authentication offre les garanties de sécurité suivantes :

• Hachage sécurisé des mots de passe : Les mots de passe ne sont jamais stockés en clair. Ils sont hachés au moyen de l'algorithme scrypt avec un facteur de travail élevé, conformément aux recommandations de l'OWASP (Open Web Application Security Project). En cas de violation de la base de données, les mots de passe hachés ne peuvent pas être facilement inversés pour retrouver les mots de passe en clair.
• Gestion sécurisée des sessions : Après authentification, un token de session sécurisé (JWT - JSON Web Token) est généré et transmis au client. Ce token est signé cryptographiquement et ne peut être forgé ou modifié. Les tokens de session expirent automatiquement après un délai d'inactivité ou une durée maximale, obligeant l'utilisateur à se réauthentifier.
• Protection contre les attaques par force brute : Firebase Authentication intègre des mécanismes de limitation du taux de tentatives d'authentification (rate limiting) afin de prévenir les attaques par force brute visant à deviner les mots de passe.
• Authentification multifacteur (MFA) : Bien que non obligatoire actuellement, Firebase Authentication supporte l'authentification multifacteur, qui pourra être proposée aux utilisateurs dans une version future du service pour renforcer la sécurité de leurs comptes.

2.2. Firebase Security Rules

L'accès aux données stockées dans Cloud Firestore (base de données) et Cloud Storage (fichiers) est contrôlé par Firebase Security Rules, un langage déclaratif permettant de définir des règles d'autorisation granulaires. Les règles de sécurité en vigueur garantissent que :

• Seul un utilisateur authentifié peut accéder aux données de son propre compte. Aucun utilisateur ne peut accéder aux données d'un autre utilisateur.
• Les opérations de lecture, écriture, mise à jour et suppression sont autorisées uniquement si l'identifiant unique de l'utilisateur (UID Firebase) correspond à celui du propriétaire des données.
• Les requêtes tentant d'accéder à des données non autorisées sont automatiquement rejetées par Firebase avant même d'atteindre les serveurs de l'application.

2.3. Firebase App Check

Firebase App Check est activé sur le service Fatoom afin de protéger les ressources backend contre les abus provenant de sources non authentifiées. App Check vérifie que les requêtes proviennent bien de l'application officielle Fatoom et non d'un script automatisé, d'un outil de reverse engineering ou d'une application tierce non autorisée. Les requêtes ne provenant pas d'une source autorisée sont automatiquement rejetées.

Article 3 - Chiffrement des données

3.1. Chiffrement en transit

Toutes les communications entre les terminaux des utilisateurs et les serveurs de Fatoom, ainsi qu'entre les différents composants de l'infrastructure backend, sont chiffrées au moyen du protocole TLS (Transport Layer Security) version 1.2 ou supérieure. Le protocole TLS garantit :

• Confidentialité : Les données transmises sur le réseau ne peuvent être lues par un tiers interceptant la communication.
• Intégrité : Les données transmises ne peuvent être modifiées par un tiers sans que cette modification soit détectée.
• Authentification : Le client peut vérifier l'identité du serveur au moyen de certificats numériques émis par des autorités de certification reconnues.

Les certificats TLS utilisés par le service Fatoom sont émis par Let's Encrypt ou Google Trust Services et sont automatiquement renouvelés avant leur expiration.

3.2. Chiffrement au repos

Toutes les données stockées sur l'infrastructure Google Cloud Platform (bases de données Cloud Firestore, fichiers Cloud Storage) sont automatiquement chiffrées au repos au moyen de l'algorithme de chiffrement AES-256 (Advanced Encryption Standard avec une clé de 256 bits).

Le chiffrement au repos est effectué de manière transparente par Google Cloud Platform, sans action requise de la part de Vincent CAHART ou des utilisateurs. Les clés de chiffrement sont gérées par Google Key Management Service (KMS) et font l'objet de rotations régulières conformément aux meilleures pratiques de sécurité. Les clés de chiffrement elles-mêmes sont chiffrées au moyen de clés maîtres (master keys) stockées dans des modules de sécurité matériels (HSM - Hardware Security Modules) certifiés FIPS 140-2.

3.3. Hachage des mots de passe

Comme indiqué à l'article 2.1, les mots de passe des utilisateurs ne sont jamais stockés en clair. Ils sont hachés au moyen de l'algorithme scrypt, qui est un algorithme de dérivation de clé conçu pour être intentionnellement lent et coûteux en ressources de calcul, afin de rendre les attaques par force brute impraticables. Les paramètres de scrypt utilisés par Firebase Authentication (facteur de coût, taille du sel) sont conformes aux recommandations de l'OWASP et de l'ANSSI (Agence Nationale de la Sécurité des Systèmes d'Information).

Article 4 - Surveillance et détection d'anomalies

4.1. Journalisation des événements

L'ensemble des événements significatifs survenant sur le service Fatoom sont journalisés (enregistrés dans des fichiers de logs) à des fins de traçabilité, de détection d'incidents de sécurité et de conformité. Les événements journalisés incluent notamment : tentatives d'authentification (réussies et échouées), accès aux données, modifications de compte, opérations d'administration, erreurs techniques, et requêtes rejetées par les règles de sécurité. Les journaux sont conservés pendant une durée de 12 mois, conformément aux recommandations de la CNIL.

4.2. Surveillance en temps réel

L'infrastructure du service Fatoom fait l'objet d'une surveillance en temps réel au moyen d'outils de monitoring fournis par Google Cloud Platform (Cloud Monitoring, Cloud Logging). Ces outils permettent de détecter rapidement les anomalies de performance, les pics de charge, les erreurs serveur et les tentatives d'intrusion. Des alertes automatiques sont configurées pour notifier Vincent CAHART en cas de détection d'un événement anormal nécessitant une intervention.

4.3. Firebase Crashlytics

Firebase Crashlytics est activé sur l'application mobile Fatoom afin de détecter et journaliser les erreurs et plantages de l'application. Les rapports de crash incluent des informations techniques (modèle de l'appareil, version du système d'exploitation, version de l'application, pile d'exécution au moment de l'erreur) mais n'incluent jamais de données personnelles des utilisateurs. Ces rapports permettent à Vincent CAHART d'identifier et de corriger rapidement les bugs et vulnérabilités de sécurité.

4.4. Audits de sécurité

Vincent CAHART s'engage à réaliser ou à faire réaliser des audits de sécurité réguliers du service Fatoom afin d'identifier les vulnérabilités potentielles et de vérifier la conformité des mesures de sécurité aux meilleures pratiques de l'industrie. Ces audits peuvent prendre la forme de revues de code, de tests d'intrusion (pentests), d'analyses de vulnérabilités automatisées ou d'audits de configuration de l'infrastructure.

Article 5 - Gestion des incidents de sécurité

5.1. Procédure de gestion des incidents

Vincent CAHART a mis en place une procédure de gestion des incidents de sécurité visant à détecter, analyser, contenir et remédier rapidement à toute violation de données personnelles ou tout autre incident de sécurité. Cette procédure comprend les étapes suivantes :

1. Détection : Identification de l'incident au moyen des outils de surveillance, des alertes automatiques, des rapports de crash, ou des signalements d'utilisateurs.
2. Évaluation : Analyse de la nature, de la gravité et de l'impact de l'incident. Détermination des données et des utilisateurs concernés.
3. Confinement : Mise en œuvre de mesures immédiates pour limiter l'impact de l'incident et empêcher sa propagation (par exemple, blocage d'un compte compromis, révocation de tokens d'authentification, désactivation temporaire d'une fonctionnalité).
4. Éradication : Identification et correction de la cause racine de l'incident (correction d'une vulnérabilité, modification d'une configuration erronée, suppression d'un accès non autorisé).
5. Récupération : Restauration des services et des données à leur état normal. Vérification que l'incident a été complètement résolu et que le service fonctionne correctement.
6. Analyse post-incident : Réalisation d'un bilan de l'incident pour identifier les leçons apprises et les améliorations à apporter aux mesures de sécurité.

5.2. Notification des violations de données

Conformément à l'article 33 du RGPD, en cas de violation de données personnelles susceptible d'engendrer un risque pour les droits et libertés des personnes physiques, Vincent CAHART s'engage à notifier cette violation à la CNIL (Commission Nationale de l'Informatique et des Libertés) dans un délai maximum de 72 heures après en avoir pris connaissance.

Conformément à l'article 34 du RGPD, lorsque la violation de données personnelles est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques, Vincent CAHART communique la violation de données personnelles aux utilisateurs concernés dans les meilleurs délais, en indiquant la nature de la violation, les catégories de données concernées, les conséquences probables, et les mesures prises ou envisagées pour remédier à la violation et en atténuer les effets négatifs.

5.3. Communication avec les utilisateurs

En cas d'incident de sécurité majeur affectant la disponibilité ou l'intégrité du service, Vincent CAHART s'engage à informer les utilisateurs dans les meilleurs délais via les canaux de communication appropriés (courrier électronique, notification in-app, message sur le site web). Cette communication précisera la nature de l'incident, son impact, les mesures prises pour y remédier, et les éventuelles actions attendues de la part des utilisateurs (par exemple, modification du mot de passe).

Article 6 - Sécurité du développement

6.1. Pratiques de développement sécurisé

Le développement du service Fatoom suit les principes du développement sécurisé (secure coding) afin de minimiser les vulnérabilités de sécurité dans le code de l'application. Ces pratiques incluent notamment :

• Validation et assainissement de toutes les entrées utilisateur pour prévenir les attaques par injection (SQL injection, XSS - Cross-Site Scripting, etc.)
• Utilisation de bibliothèques et frameworks de développement à jour, exempts de vulnérabilités connues
• Évitement des fonctions et pratiques dangereuses (par exemple, utilisation d'eval(), de requêtes SQL non paramétrées, etc.)
• Mise en place de tests de sécurité automatisés (analyse statique de code, tests unitaires de sécurité)

6.2. Gestion des dépendances

Le service Fatoom utilise des bibliothèques et frameworks open source tiers (par exemple, React, Next.js, Firebase SDK). Ces dépendances sont gérées au moyen d'outils de gestion de paquets (npm, yarn) et font l'objet d'une surveillance continue des vulnérabilités connues. Lorsqu'une vulnérabilité est détectée dans une dépendance, Vincent CAHART s'engage à mettre à jour la dépendance concernée dans les meilleurs délais.

6.3. Contrôle de version et déploiement

Le code source du service Fatoom est géré au moyen d'un système de contrôle de version (Git) permettant de tracer l'historique des modifications, de revenir à des versions antérieures en cas de problème, et de faciliter la collaboration. Les déploiements en production sont réalisés de manière automatisée via un pipeline d'intégration continue et de déploiement continu (CI/CD) comprenant des étapes de tests automatisés, de revue de code et de validation avant la mise en production.

Article 7 - Sécurité physique et organisationnelle

7.1. Sécurité des centres de données

Les données du service Fatoom sont hébergées dans des centres de données de Google Cloud Platform situés dans l'Union européenne. Ces centres de données bénéficient de mesures de sécurité physique de niveau professionnel, incluant notamment : contrôle d'accès biométrique, surveillance vidéo 24/7, détection d'intrusion, protection contre les incendies et les inondations, alimentation électrique redondante, et climatisation contrôlée. L'accès physique aux serveurs est strictement limité au personnel autorisé de Google.

7.2. Sensibilisation à la sécurité

Vincent CAHART, en sa qualité d'entrepreneur individuel exploitant le service Fatoom, est sensibilisé aux enjeux de sécurité et de protection des données personnelles et s'engage à maintenir ses connaissances à jour en suivant régulièrement des formations et en consultant les recommandations des autorités de contrôle (CNIL, ANSSI) et des organisations professionnelles (OWASP, SANS Institute).

7.3. Gestion des accès administratifs

L'accès aux outils d'administration de l'infrastructure (console Google Cloud Platform, console Firebase) est protégé par une authentification forte (mot de passe robuste, authentification multifacteur obligatoire). Les accès administratifs sont strictement limités aux comptes autorisés et font l'objet d'une révision régulière. Les sessions administratives sont automatiquement déconnectées après un délai d'inactivité.

Article 8 - Signalement de vulnérabilités

Vincent CAHART encourage les chercheurs en sécurité, les utilisateurs et toute personne ayant connaissance d'une vulnérabilité de sécurité affectant le service Fatoom à la signaler de manière responsable. Les signalements de vulnérabilités doivent être adressés à l'adresse électronique suivante : contact@fatoom.fr

Le signalement doit inclure une description détaillée de la vulnérabilité, les étapes permettant de la reproduire, et, si possible, une preuve de concept (proof of concept). Vincent CAHART s'engage à accuser réception du signalement dans un délai de 7 jours et à analyser la vulnérabilité signalée dans les meilleurs délais. En cas de confirmation de la vulnérabilité, Vincent CAHART s'engage à la corriger dans un délai raisonnable et à informer la personne ayant effectué le signalement de la correction apportée.

Vincent CAHART s'engage à ne pas engager de poursuites judiciaires à l'encontre des personnes ayant signalé de bonne foi une vulnérabilité, à condition que le signalement soit effectué de manière responsable et ne s'accompagne pas d'actions malveillantes (exploitation de la vulnérabilité à des fins personnelles, divulgation publique de la vulnérabilité avant sa correction, tentative d'accès non autorisé aux données d'autres utilisateurs).

Article 9 - Évolution de la Politique de sécurité

La présente Politique de sécurité est régulièrement révisée et mise à jour afin de tenir compte des évolutions technologiques, des nouvelles menaces de sécurité, des recommandations des autorités de contrôle, et des retours d'expérience tirés des audits de sécurité et des incidents passés.

Toute modification substantielle de la Politique de sécurité sera portée à la connaissance des utilisateurs par les moyens de communication appropriés.

Article 10 - Contact

Pour toute question relative à la présente Politique de sécurité ou pour signaler une vulnérabilité de sécurité, vous pouvez contacter Vincent CAHART :