Mesures techniques et organisationnelles (MTO)

1. Champ d'application et architecture

• Société : CreatorFlow Labs S.L., Madrid, Espagne. Une petite équipe qui travaille entièrement à distance. Nous n'exploitons pas de serveurs en propre, ni de salles de serveurs, ni de réseau informatique de bureau, et aucune donnée personnelle n'est stockée dans les locaux de l'entreprise.
• Hébergement : l'ensemble du service fonctionne sur Amazon Web Services (AWS) dans l'Union européenne, région eu-west-1 (Irlande). L'application, les bases de données, les caches, le stockage d'objets et les sauvegardes se trouvent tous dans cette région.
• Données traitées : noms d'utilisateur Instagram et identifiants publics de profil, texte des commentaires et des messages privés qui déclenchent des automatisations ou qui en résultent, adresses e-mail collectées via les automatisations, événements de clic sur les liens, ainsi que données de compte et de facturation des clients. Aucune catégorie particulière de données personnelles au sens de l'article 9 du RGPD n'est destinée à être traitée.
• Responsabilité partagée : la sécurité physique et environnementale des centres de données est assurée par AWS ; tout ce qui se situe au niveau du système d'exploitation et au-dessus est exploité par CreatorFlow. Chaque section ci-dessous indique si un contrôle relève d'AWS ou de CreatorFlow.

2. Contrôle de l'accès physique (Zutrittskontrolle)

• Locaux de l'entreprise : sans objet. Aucun serveur, équipement réseau ni support de données contenant des données personnelles ne se trouve dans les locaux de CreatorFlow. Les salles de serveurs verrouillables, les armoires de serveurs, la gestion des clés, les registres des visiteurs, les systèmes d'alarme et les règles relatives au personnel de nettoyage ou de maintenance ne nous sont donc pas applicables.
• Centres de données (AWS) : contrôles hérités d'AWS. Les centres de données d'AWS mettent en œuvre une sécurité périmétrique, un contrôle d'accès par badge et par biométrie, l'accompagnement des visiteurs, la vidéosurveillance et la journalisation des accès. Ces contrôles font l'objet d'audits ISO 27001 et SOC 2, et les rapports sont disponibles pour les clients sur demande, par notre intermédiaire ou directement via AWS Artifact.
• Alimentation de secours et protection contre l'incendie : contrôles hérités d'AWS. Les centres de données disposent d'alimentations électriques redondantes, d'onduleurs et de groupes électrogènes, ainsi que de systèmes automatiques de détection et d'extinction des incendies, couverts par les mêmes rapports d'audit.

3. Contrôle de l'accès aux systèmes (Zugangskontrolle)

• Authentification des clients : les clients se connectent avec une adresse e-mail et un mot de passe, ou via la connexion avec Google. Le formulaire d'inscription exige des mots de passe d'au moins 8 caractères ; ce minimum n'est actuellement imposé que dans le navigateur, et non côté serveur. Les mots de passe sont stockés sous forme hachée et salée, jamais en clair ; la migration vers un algorithme moderne de hachage des mots de passe (bcrypt ou argon2) est suivie comme un point en suspens. Les nouveaux comptes sont créés après une vérification reCAPTCHA ; la confirmation de l'adresse e-mail avant la première utilisation n'est pas imposée à ce jour.
• Sessions : les sessions sont stockées côté serveur et référencées par un cookie signé doté de l'attribut HttpOnly, limité à notre domaine, qui expire au bout de 7 jours. L'attribut Secure n'est pas encore défini sur ce cookie ; son ajout figure dans notre feuille de route en matière de sécurité. Un changement de mot de passe met fin à la session en cours et révoque les jetons « se souvenir de moi », mais ne met pas fin, à ce jour, aux autres sessions actives sur d'autres appareils. Une modification de l'adresse e-mail du compte à l'initiative d'un administrateur invalide toutes les sessions de cet utilisateur.
• Verrouillage des comptes : le verrouillage automatique d'un compte après des tentatives de connexion infructueuses répétées n'est pas encore en place ; des protections supplémentaires contre les abus de connexion figurent dans notre feuille de route en matière de sécurité. Les liens de réinitialisation du mot de passe sont envoyés uniquement à l'adresse e-mail enregistrée pour le compte.
• Accès à Instagram : nous ne demandons ni ne stockons jamais de mots de passe Instagram. Les comptes Instagram sont connectés via le flux OAuth 2.0 officiel de Meta, et les jetons d'accès ainsi obtenus sont chiffrés au niveau applicatif (AES-256) avant d'être stockés.
• Accès du personnel et accès à l'infrastructure : l'accès à la console AWS, aux serveurs et aux fonctions d'administration est limité à des membres du personnel nommément désignés qui disposent d'identifiants individuels ; l'accès aux serveurs se fait par SSH avec des clés individuelles. Dans l'application, les fonctions d'administration sont réservées à un seul compte administrateur inscrit sur une liste d'autorisation, et elles sont soumises à une limitation de débit.

4. Contrôle de l'accès aux données (Zugriffskontrolle)

• Cloisonnement par locataire : chaque enregistrement client (automatisations, contacts, activité, analyses) est stocké avec l'identifiant du workspace auquel il appartient, et l'application ne présente à un utilisateur que les workspaces dont il est membre. Des vérifications côté serveur de l'appartenance au workspace sont en place sur une partie de l'API et sont en cours d'extension à chaque point de terminaison propre à un workspace ; tant que ce travail n'est pas terminé, nous ne décrivons pas la séparation des locataires comme entièrement appliquée au niveau de l'API.
• Besoin d'en connaître : seuls les membres du personnel nommément désignés qui exploitent le service peuvent accéder aux données de production, et uniquement pour l'assistance, la gestion des incidents et la maintenance.
• Protection des identifiants : les jetons d'accès Instagram sont chiffrés au repos et exclus des lectures par défaut de la base de données ; ils ne sont donc pas renvoyés par les requêtes ou les exports ordinaires.
• Données de paiement : les données de carte sont entièrement traitées par Stripe ; CreatorFlow ne reçoit ni ne stocke jamais de numéros de carte complets.

5. Contrôle des transferts (Weitergabekontrolle)

• Chiffrement en transit : les connexions entre les utilisateurs et le service, ainsi qu'entre le service et Meta, Stripe et nos prestataires d'e-mail et de journalisation, sont chiffrées avec TLS.
• Sous-traitants ultérieurs : les données personnelles ne sont partagées qu'avec les sous-traitants ultérieurs énumérés à la section 5 du DPA, dans le cadre de conditions de traitement des données. Les données sont hébergées et journalisées dans l'Union européenne ; les transferts vers des sous-traitants ultérieurs situés hors de l'UE reposent sur les Clauses contractuelles types ou sur le Cadre de protection des données UE-États-Unis, comme le prévoit le DPA.
• Exports : les clients peuvent exporter les contacts qu'ils ont collectés sous forme de fichier CSV. Une fois exportées, ces données relèvent du contrôle et de la responsabilité du client.
• Supports amovibles : sans objet. Aucun support de données amovible (clés USB, disques externes, bandes de sauvegarde) n'est utilisé pour des données personnelles ; aucun inventaire des supports de données n'est donc nécessaire.

6. Journalisation et contrôle de la saisie (Eingabekontrolle)

• Journaux applicatifs : l'application enregistre des journaux structurés pour chaque webhook traité, chaque exécution d'automatisation, chaque envoi de message et chaque requête d'API. Chaque entrée porte un identifiant de corrélation, ce qui permet de suivre un même événement de bout en bout.
• Journaux d'accès : la couche HTTP enregistre une ligne de journal d'accès par requête.
• Stockage centralisé et conservation : tous les journaux sont envoyés vers une plateforme de journalisation hébergée dans l'UE (New Relic, région de données UE) et conservés pendant 30 jours. Les utilisateurs de l'application ne peuvent pas modifier les journaux.
• Journal d'audit administratif : les actions effectuées par le personnel de CreatorFlow sur les comptes clients via l'interface d'administration, y compris les suppressions de comptes et les modifications de l'adresse e-mail des comptes, sont inscrites dans un journal d'audit, avec l'administrateur qui a agi, l'horodatage et le résultat.
• Échecs de connexion : les tentatives de connexion infructueuses des clients ne sont pas inscrites, à ce jour, dans un journal de sécurité dédié ; ce point figure dans notre feuille de route en matière de sécurité.

7. Contrôle de la séparation (Trennungskontrolle)

• Séparation des clients : les données des clients sont séparées logiquement par identifiant de workspace au niveau de la couche de données (architecture multilocataire). Via l'application, les clients ne peuvent pas voir les données qui appartiennent à d'autres workspaces.
• Séparation fonctionnelle : les données de compte et d'authentification sont conservées dans une base de données distincte de celle des données applicatives (automatisations, contacts, analyses).
• Environnements : les tests automatisés s'exécutent sur une base de données isolée en mémoire et n'accèdent jamais aux données de production. Le développement courant utilise des bases de données locales ; des membres du personnel nommément désignés interrogent aussi directement les données de production pour l'assistance, le débogage et les enquêtes sur les incidents. Il existe un seul environnement de production et aucun environnement de préproduction distinct ; les modifications sont vérifiées en local et par la suite de tests automatisés avant leur mise en production, et elles peuvent être annulées.
• Séparation physique : sans objet au-delà de la limite du compte AWS ; toutes les charges de travail s'exécutent dans un compte AWS dédié, détenu par CreatorFlow.

8. Disponibilité et résilience (Verfügbarkeitskontrolle)

• Infrastructure : le service fonctionne dans une seule région AWS (eu-west-1), au sein d'un groupe Auto Scaling qui remplace automatiquement un hôte de calcul défaillant. Les données se trouvent sur des volumes de stockage persistants qui subsistent lors du remplacement d'un hôte.
• Instantanés : des instantanés des volumes sont réalisés avant les modifications de l'infrastructure et conservés dans la même région AWS. Les instantanés susceptibles de contenir des données personnelles sont supprimés par rotation.
• Résilience des webhooks : Meta renvoie les webhooks Instagram pendant un certain temps après une panne temporaire, et Stripe renouvelle l'envoi des webhooks de facturation pendant plusieurs jours ; les courtes interruptions n'entraînent donc pas de perte d'événements.
• Supervision : l'état de santé de l'application, son débit et ses taux d'erreur sont surveillés via notre plateforme de journalisation ; les déploiements sont observés par rapport à une base de référence établie avant le déploiement.
• Limites : il n'existe ni basculement multirégion, ni objectif de délai de reprise ou de point de reprise faisant l'objet d'un engagement formel. Le service n'est pas destiné à des cas d'usage qui exigent une disponibilité continue garantie.
• Résilience des centres de données : contrôles hérités d'AWS (redondance de l'alimentation, du refroidissement et du réseau, extinction des incendies), voir la section 2.

9. Gestion des correctifs et des modifications

• Processus de modification : les modifications non mineures commencent par une spécification écrite et un plan de mise en œuvre. Le code est couvert par une suite de tests automatisés qui s'exécute sur des bases de données de test isolées, et chaque version est compilée et soumise à une vérification des types avant son déploiement.
• Mises en production : l'application est déployée sous forme d'images de conteneur versionnées. Une image antérieure peut être redéployée pour annuler une mise en production. Les comportements présentant un risque plus élevé sont livrés derrière des indicateurs de fonctionnalité (feature flags), qui peuvent être désactivés sans nouveau déploiement et activés d'abord pour une partie des workspaces.
• Vérification : des indicateurs clés sont relevés avant un déploiement, puis comparés après celui-ci, afin de détecter rapidement les régressions.
• Dépendances et système d'exploitation : les dépendances tierces et les images de base des conteneurs sont mises à jour dans le cadre du processus normal de mise en production, et le système d'exploitation de l'hôte est renouvelé lors du remplacement de l'hôte de calcul. Il n'existe pas de calendrier fixe pour l'application des correctifs ; les mises à jour qui concernent la sécurité sont hiérarchisées selon leur gravité.
• Registre de sécurité : les constats issus de nos propres audits de sécurité sont suivis dans un registre interne, avec un score de gravité, et sont corrigés par ordre de risque.

10. Gestion des incidents et des violations de données

• Contact : les problèmes de sécurité peuvent être signalés à security@creatorflow.so. Nous accusons réception des signalements et nous les examinons ; nous ne proposons pas de programme de bug bounty rémunéré.
• Traitement : les incidents font l'objet d'une enquête à l'aide des journaux centralisés, puis sont confinés, documentés avec leur chronologie et leur cause première, et corrigés. Les enseignements tirés alimentent le registre de sécurité.
• Notification des clients : si une violation de données personnelles touche les données d'un client, nous en informons ce client dans les meilleurs délais après en avoir pris connaissance, avec les informations décrites à la section 8 du DPA, afin qu'il puisse respecter ses propres obligations au titre des articles 33 et 34 du RGPD.

11. Mesures organisationnelles

• Confidentialité : les membres du personnel qui ont accès aux données personnelles sont tenus par des obligations de confidentialité contractuelles ou légales.
• Cycle de vie des accès : l'accès à l'infrastructure et aux fonctions d'administration est accordé individuellement et retiré lorsqu'une personne quitte l'entreprise ou change de fonction.
• Appareils et travail à distance : l'équipe travaille à distance. L'accès aux données de production se fait uniquement avec des identifiants individuels, par des connexions chiffrées (TLS, SSH), et, en pratique, ces données ne sont pas stockées sur des appareils locaux. Il n'existe pas de réseau informatique de bureau, aucun VPN n'est donc utilisé ; chaque connexion d'administration est authentifiée et chiffrée individuellement.
• Bureau propre et documents papier : sans objet au sens classique. Les données personnelles traitées via le service n'existent que sous forme électronique au sein d'AWS, et aucun document papier contenant des données de clients n'est conservé.
• Tiers et maintenance : aucun personnel externe de maintenance, de nettoyage ou d'assistance n'a accès aux systèmes de production. Aucune maintenance à distance n'est confiée à des tiers ; l'infrastructure est exploitée uniquement par le personnel de CreatorFlow.
• Protection des terminaux sur les serveurs : les charges de travail de production s'exécutent sous forme de conteneurs Linux, avec des utilisateurs non root, sur un hôte qui n'expose publiquement que HTTPS ; les postes de travail des employés ne font pas partie du réseau de production.

12. Suppression et conservation

• Suppression de compte : sur demande, un compte est supprimé avec l'ensemble de ses workspaces, automatisations, contacts, enregistrements d'activité, états d'automatisation en attente et connexions Instagram, et le contact correspondant utilisé pour les e-mails marketing est retiré. Chaque suppression est consignée dans un journal d'audit.
• Suppression des contacts : le client peut supprimer des contacts individuels (adresses e-mail collectées), ce qui permet de donner suite aux demandes d'effacement des personnes concernées.
• Expiration automatique : les enregistrements temporaires utilisés pendant qu'une automatisation attend une action de l'utilisateur (par exemple une réponse avec une adresse e-mail ou un abonnement) cessent d'être utilisables dans un délai de 24 à 48 heures, selon le type d'automatisation, et sont physiquement supprimés de la base de données dans un délai de 48 heures.
• Journaux : les journaux applicatifs et les journaux d'accès sont conservés pendant 30 jours.
• Instantanés : voir la section 8. Les instantanés ne sont restaurés que pour rétablir le service après une défaillance du système. Les données personnelles supprimées avant une telle restauration devraient ensuite être supprimées à nouveau ; il n'existe pas de réconciliation automatisée à cet effet, c'est pourquoi nous relançons manuellement les suppressions sur demande.

13. Réexamen des présentes mesures