Sécurité
Cette page réunit trois politiques : le signalement de vulnérabilités, la réponse aux incidents, et la sécurité de l'information. Elle décrit ce que nous faisons réellement, à l'échelle qui est la nôtre — un éditeur indépendant publiant une application entièrement hébergée sur la plateforme Atlassian Forge, sans serveur ni infrastructure propre.
1. Signalement de vulnérabilités
Comment nous joindre
Adressez tout signalement à contact@miksumia.com. Nous accusons réception sous deux jours ouvrés et vous tenons informé de l'avancement. Les signalements anonymes sont acceptés.
Informations utiles
- description de la vulnérabilité et de son impact potentiel ;
- endroit où elle se manifeste ;
- étapes de reproduction, avec captures ou scripts si possible.
Le français et l'anglais conviennent également.
Délais de correction visés
Ils courent à partir de la qualification du signalement. Ils respectent la politique de correction des failles de l'Atlassian Marketplace, qui fixe les délais maximaux d'une application Cloud.
| Gravité | Objectif | Délai maximal Atlassian |
|---|---|---|
| Critique | 7 jours | 10 jours |
| Élevée | 4 semaines | 4 semaines |
| Moyenne | 12 semaines | 12 semaines |
| Faible | 25 semaines | 25 semaines |
Périmètre
Cette politique couvre l'application « Miksumia Publisher » et le site miksumia.com. Les plateformes tierces sur lesquelles l'application s'exécute ou dont elle consomme les API — Atlassian, Google — ne relèvent pas de ce périmètre : adressez-vous directement à leurs programmes respectifs.
Ce que nous vous demandons
- nous signaler la faille dès sa découverte, et nous laisser un délai raisonnable pour la corriger avant toute publication ;
- ne pas dégrader le service, ni détruire ou modifier des données ;
- n'exploiter une faille que dans la mesure nécessaire à sa démonstration : ni extraction de données, ni persistance, ni rebond vers d'autres systèmes ;
- interrompre immédiatement le test et nous prévenir en cas d'accès à des données personnelles ou confidentielles, et garder ces données confidentielles.
Ne sont pas autorisés : les tests de déni de service, l'ingénierie sociale et les tests physiques.
Notre engagement
Une recherche menée conformément à cette politique est considérée comme autorisée. Nous n'engagerons aucune action en justice à son encontre et nous travaillerons avec vous à la compréhension et à la correction du problème.
2. Réponse aux incidents
Objet et responsabilité
Cette politique définit la conduite à tenir en cas d'incident de sécurité ou de violation de données concernant l'application. MIKSUMIA étant une structure à personne unique, le gérant assume l'ensemble des rôles : réception du signalement, investigation, correction, communication.
Signalement
Tout incident suspecté ou confirmé doit être signalé sans délai à contact@miksumia.com, que le signalement vienne d'un client, d'un chercheur en sécurité, d'une plateforme tierce ou de notre propre supervision.
Procédure
- Qualifier. Reproduire le problème, en établir la nature et l'étendue, et déterminer si des données personnelles sont concernées.
- Contenir. Suspendre ou révoquer les accès concernés. L'application peut être désactivée sur une installation, et l'autorisation Google révoquée, sans attendre la correction.
- Corriger. Développer le correctif, le vérifier par des tests, puis le déployer en développement avant la production.
- Communiquer. Informer les administrateurs des sites concernés, et les plateformes tierces lorsque leur périmètre est en cause.
- Prévenir la récidive. Ajouter un test couvrant le cas, et rechercher les occurrences du même motif ailleurs dans le code.
- Consigner. Documenter l'incident, sa cause et sa résolution.
Violation de données personnelles
En cas de violation de données à caractère personnel susceptible d'engendrer un risque pour les personnes concernées, nous notifions la CNIL dans les 72 heures suivant la prise de connaissance de la violation, conformément à l'article 33 du RGPD. Lorsque le risque est élevé, les personnes concernées sont informées dans les meilleurs délais, conformément à l'article 34. Les administrateurs des sites Confluence concernés sont informés dans tous les cas.
3. Sécurité de l'information
Périmètre
L'application s'exécute intégralement dans le bac à sable géré d'Atlassian Forge. Nous n'exploitons aucun serveur, aucune base de données et aucun réseau propre. La sécurité de l'infrastructure d'hébergement relève d'Atlassian ; ce qui suit décrit ce qui relève de nous.
Données conservées, emplacement et sous-traitants
L'application conserve, par site Confluence, dans le stockage Forge hébergé par Atlassian :
- les réglages de connexion : identifiant du dossier Drive, espace cible, état, réglages de synchronisation et de traduction ;
- pour chaque document synchronisé : identifiant Drive, titre du document, type, dossier parent, identifiant de la page Confluence, empreinte SHA-256 du contenu publié, état technique ;
- pour chaque dossier : titre du dossier et identifiants ; règles d'exclusion (identifiants de fichiers et de dossiers) ;
- des enregistrements techniques : synchronisations, canaux de notification, compteurs mensuels d'IA, interrupteurs d'urgence, événements d'audit, faits techniques par PDF.
Le contenu complet des documents n'est pas conservé : il est lu, converti et publié dans Confluence. Le jeton d'actualisation Google est gardé dans le stockage chiffré des secrets de Forge.
Les données sont traitées et conservées sur l'infrastructure Atlassian Forge. Miksumia n'exploite ni serveur ni base de données. Les données ne quittent Atlassian que vers les services Google ci-dessous ; les appels à Confluence passent par Forge et ne sont pas une sortie vers l'extérieur. Pour l'hébergement (emplacement, chiffrement, certifications), voir les pages d'Atlassian : Atlassian Trust Center et sécurité de Forge.
| Sous-traitant | Rôle |
|---|---|
| Atlassian | Hébergement de l'application et stockage (Forge) ; Confluence |
| Lecture seule de Drive, Sheets et Slides (autorisation OAuth) ; API Gemini pour les seules fonctions activées par un administrateur |
Destinations réseau déclarées
Exactement les adresses déclarées au manifeste de l'application :
- www.googleapis.com, oauth2.googleapis.com, sheets.googleapis.com, slides.googleapis.com, docs.google.com et *.googleusercontent.com : lecture des fichiers connectés et autorisation OAuth, en lecture seule. Elles reçoivent le jeton d'accès et des identifiants de fichiers ;
- generativelanguage.googleapis.com : API Gemini (Gemini Developer API, pas Vertex AI). C'est le seul service qui reçoit du contenu client.
Gemini reçoit du contenu dans deux cas seulement. (1) Traduction : dès qu'un administrateur choisit une langue pour un dossier, le texte de ses documents lui est envoyé à chaque synchronisation de ce dossier. (2) Lecture par IA d'un PDF numérisé : elle est demandée document par document, et les pages du PDF sont alors envoyées. Une consigne fixe accompagne l'envoi ; le titre, le nom de fichier, l'espace et l'utilisateur ne sont pas envoyés. Rien d'autre ne quitte Atlassian : aucun contenu Confluence, aucune donnée d'utilisateur Atlassian, aucune télémétrie, aucune analyse d'audience, aucun journal externe.
Conservation et suppression
- Le stockage n'a pas de durée de vie : les enregistrements durent autant que la connexion. Seul l'état anti-CSRF d'OAuth expire (10 minutes).
- Supprimer une connexion (après l'avoir déconnectée) efface ses enregistrements de documents, ses correspondances de dossiers, ses règles d'exclusion et sa dernière synchronisation.
- Déconnecter le compte Google révoque le jeton auprès de Google puis le supprime.
- À la désinstallation, l'application révoque d'abord l'autorisation Google
(étape
preUninstall), suspend les connexions et retire les canaux de notification. Atlassian supprime ensuite les données stockées après 28 jours, selon le cycle de vie du stockage Forge hébergé (documentation Atlassian). - Les pages déjà publiées restent dans l'espace Confluence du client, à qui elles appartiennent.
- Il n'existe pas d'export en libre-service. Toute demande : contact@miksumia.com.
Journaux
Les journaux contiennent des noms d'événements, des identifiants techniques, des compteurs et des codes d'erreur. Les messages d'erreur affichés ou journalisés sont composés par l'application ; le texte venu d'un service amont est classé puis abandonné. Aucun contenu client dans les journaux de production.
Classification des données
- Secrets. Identifiants OAuth et jetons d'actualisation Google. Traités selon la section « gestion des secrets » ci-dessous.
- Contenu client. Documents lus dans Google Drive et contenu dérivé. Traité en mémoire, publié dans Confluence, conservé seulement dans la mesure décrite plus haut et dans la politique de confidentialité.
- Données techniques. Identifiants de fichiers, titres de documents et de dossiers, empreintes, compteurs, états de synchronisation.
Contrôle des accès
Les fonctions de l'application sont réservées aux administrateurs du site Confluence, vérifié côté serveur à chaque requête auprès de Confluence lui-même, jamais déduit de l'interface. L'accès à Google Drive est demandé en lecture seule et limité aux dossiers explicitement connectés par l'administrateur.
Les comptes d'administration de l'éditeur — console développeur Atlassian, console Google Cloud, dépôt de code — sont nominatifs et protégés par authentification à deux facteurs.
Gestion des secrets
Aucun secret ne figure dans le code source. Les identifiants client OAuth sont fournis au déploiement par variables d'environnement Forge. Les jetons d'actualisation sont écrits exclusivement dans le stockage chiffré de Forge, révoqués auprès de Google puis supprimés lors de la déconnexion du compte ou de la désinstallation. Aucun secret n'est journalisé, renvoyé dans une réponse, ni inclus dans un message d'erreur.
Chiffrement des communications
Toutes les communications utilisent HTTPS. Les destinations réseau autorisées sont déclarées au manifeste de l'application et vérifiées par la plateforme à l'exécution : aucune autre destination n'est joignable.
Développement
- revue de conception avant implémentation ;
- tests automatisés exécutés en intégration continue à chaque modification ;
- analyse statique de sécurité du code source, reproductible et rejouable ;
- analyse des dépendances, avec suivi des vulnérabilités publiées, y compris celles introduites de façon transitive.
Évaluation indépendante
Miksumia Publisher V2.7.0 was assessed by TAC Security against the CASA specification v2.1.1 at assurance level AL1 (grey-box testing, 7–23 September 2026; report issued 25 September 2026). Result: In Compliance. The assessment was carried out for Google's OAuth restricted scopes (Drive read-only).
Les tests ont utilisé la configuration « App Defense Alliance ADA Burp Audit Scan Configuration ».
Vérification OAuth de Google
La vérification OAuth de l'application par Google a été approuvée le 28/09/2026.
Registre STAR de la Cloud Security Alliance
Nos réponses au questionnaire CAIQ Lite v4.1.0 de la Cloud Security Alliance sont inscrites au registre STAR de la CSA depuis le 6 octobre 2026 (STAR Level One) : Miksumia Publisher for Confluence au registre STAR. Le niveau un est une auto-évaluation : les réponses sont les nôtres, aucun auditeur ne les a vérifiées.
Revue
Ces politiques sont revues au moins une fois par an, et à chaque évolution substantielle de l'architecture de l'application.