Présentation de la sécurité / Livre blanc sur la sécurité

Dernière mise à jour : 25 octobre 2026 (version 1.0).

Fréquence de révision : annuelle, ainsi qu'à chaque modification substantielle de l'architecture de la plateforme

1. Introduction

PassportScan Cloud est une plateforme Software-as-a-Service exploitée par GlobeID Limited (« GlobeID ») qui permet aux prestataires d'hébergement de capturer les documents d'identité des clients, de recueillir les consentements et signatures, et de satisfaire aux obligations légales d'enregistrement des clients (autorités policières, statistiques et frontalières), ainsi que d'assurer l'intégration avec les PMS.

Le présent document décrit l'architecture de sécurité ainsi que les mesures techniques et organisationnelles qui protègent la plateforme et les données à caractère personnel qui y sont traitées. Il est destiné aux clients, prospects et auditeurs, complète l'Accord de traitement des données (DPA) et la Liste des sous-traitants ultérieurs, et constitue la réponse de référence aux questionnaires de sécurité. Il décrit la plateforme de production telle que déployée à la date d'entrée en vigueur du présent document.

2. Programme de sécurité et conformité

• GlobeID exploite un Système de management de la sécurité de l'information (SMSI) aligné sur la norme ISO/IEC 27001:2022, avec un Responsable de la sécurité des systèmes d'information (CISO) désigné, un registre des risques et une Déclaration d'applicabilité ; le SMSI est révisé au moyen d'audits internes et de revues de direction planifiés selon un cycle annuel.
• RGPD : GlobeID agit en qualité de sous-traitant pour les données des clients hébergés au titre du DPA et a désigné un Délégué à la protection des données externe. Des registres des activités de traitement, une AIPD relative aux données d'identité des clients hébergés et une procédure relative aux droits des personnes concernées sont tenus à jour.
• Les données de cartes de paiement sont traitées exclusivement par Stripe ; PassportScan n'exploite aucun environnement de données de titulaires de cartes et ne reçoit jamais les numéros de carte, les codes CVV ni les dates d'expiration.
• La surveillance des contrôles est assurée en continu par une plateforme d'automatisation de la conformité connectée aux fournisseurs de services cloud, de code source et d'identité ; des tests d'intrusion indépendants sont commandés périodiquement et les constats font l'objet d'un suivi jusqu'à leur résolution.

3. Hébergement et architecture

4. Sécurité du réseau

• Privé par défaut : chaque service s'exécute dans des sous-réseaux privés d'un VPC dédié. Seuls les interfaces destinées aux clients, la console d'administration du personnel et deux API publiques sont accessibles depuis Internet, via Amazon API Gateway et un répartiteur de charge applicatif (Application Load Balancer) public. La console d'administration est protégée par AWS WAF et par sa propre authentification, avec des comptes du personnel attribués individuellement et une authentification multifacteur obligatoire. Tous les microservices internes, le moteur d'automatisation et le moteur OCR ne sont accessibles que depuis l'intérieur du VPC ou via le VPN de l'entreprise.
• Pare-feu applicatif web : la bordure publique (étapes API Gateway et répartiteur de charge public) est protégée par AWS WAF. Les groupes de règles gérés par AWS Amazon IP Reputation List et Known Bad Inputs bloquent les sources et charges utiles malveillantes, le Core Rule Set d'AWS (aligné sur l'OWASP) est évalué à chaque requête, et la limitation de débit bloque les sources abusives, avec des limites plus strictes sur les points de terminaison d'authentification.
• Chiffrement en transit : les points de terminaison publics acceptent uniquement TLS 1.2 et TLS 1.3 (politique de sécurité API Gateway TLS_1_2 ; politique du répartiteur de charge ELBSecurityPolicy-TLS13-1-2-2021-06 avec des suites de chiffrement modernes ECDHE-GCM). Le trafic HTTP est redirigé vers HTTPS et le mécanisme HTTP Strict Transport Security (HSTS) est appliqué sur le répartiteur de charge public. Les certificats sont émis et renouvelés automatiquement par AWS Certificate Manager.
• Accès administratif : les ingénieurs accèdent aux services internes uniquement via un VPN à confiance zéro (zero-trust) lié à leur identité individuelle ; aucun accès SSH ou RDP n'est exposé à Internet, et il n'existe aucun hôte bastion.
• Journalisation réseau : les VPC Flow Logs (tout le trafic) et les journaux d'accès serveur S3 sont conservés pendant 90 jours.

5. Sécurité des données

5.1 Chiffrement

5.2 Localisation et résidence des données

• Les services principaux de la plateforme et les bases de données primaires sont hébergés exclusivement dans la région AWS eu-west-1 (Irlande) ; aucune réplication interrégionale des bases de données n'est configurée.
• Lorsqu'un client active le stockage des images de documents, les images sont stockées dans la région S3 correspondant à la juridiction de l'établissement. Régions provisionnées : eu-west-1 (Europe), us-east-1 (Amérique du Nord), sa-east-1 (Amérique du Sud), ap-southeast-1 (Asie-Pacifique) et ap-southeast-2 (Australie). Chaque compartiment régional applique la même configuration de chiffrement, de gestion des versions et de journalisation des accès.
• Les transferts hors de l'EEE sont couverts par l'avenant relatif au traitement des données (Data Processing Addendum) d'AWS et par les clauses contractuelles types, comme décrit dans le DPA.

5.3 Secrets et clés

• Les secrets applicatifs, les clés API et les clés de chiffrement sont stockés dans AWS Systems Manager Parameter Store (SecureString) et injectés dans les conteneurs au démarrage ; ils ne sont jamais intégrés au code source ni incorporés dans les images.
• Les identifiants des bases de données sont soit générés et renouvelés par AWS (secrets gérés par RDS dans AWS Secrets Manager), soit stockés sous forme de SecureStrings dans AWS Systems Manager Parameter Store et injectés dans les conteneurs en tant que secrets au démarrage.
• Les modifications de secrets en production sont effectuées via un flux opérationnel audité, et non manuellement sur la console. Les mots de passe des bases de données applicatives sont renouvelés selon un calendrier défini par notre plateforme d'exploitation interne, sans aucune interruption de service.

5.4 Sauvegardes et conservation

• Aurora MySQL : sauvegardes quotidiennes automatisées avec une conservation de 15 jours et une restauration à un instant donné en continu ; protection contre la suppression activée ; un instantané final est réalisé avant toute suppression de cluster.
• Stockage d'objets : gestion des versions avec conservation des versions antérieures pendant 90 jours, protégeant contre toute suppression ou écrasement accidentels.
• À la fin du contrat, les données du client lui sont restituées et/ou supprimées à sa demande, dans un délai de 30 jours à compter de la demande, conformément au DPA ; les copies de sauvegarde expirent ensuite selon le cycle de conservation décrit ci-dessus.

6. Gestion des identités et des accès

• Utilisateurs clients : l'authentification s'effectue via le fournisseur d'identité de la plateforme (Clerk) avec vérification de l'adresse e-mail, gestion des sessions et authentification multifacteur optionnelle ; les accès au sein d'un compte client sont fondés sur les rôles.
• Personnel de GlobeID : l'accès au code source, au CI/CD et à la console de gestion interne s'effectue via l'organisation GitHub avec authentification à deux facteurs obligatoire. Aucun ingénieur ne détient d'accès permanent au compte AWS de production, et aucun identifiant détenu par une personne ne peut assumer un rôle dans ce compte : la production est modifiée et exploitée exclusivement via notre plateforme d'exploitation interne et des flux opérationnels audités, sans aucun accès par console ou ligne de commande pour les ingénieurs. Les développeurs disposent d'un accès selon le principe du moindre privilège limité aux comptes de développement et de préproduction (staging). La surveillance et l'exploitation utilisent des rôles dédiés à moindre privilège ; les actions opérationnelles limitées disponibles sur notre plateforme d'exploitation (par exemple redémarrage progressif, mode maintenance, rotation planifiée des identifiants, tâches ponctuelles approuvées sur les données et instantanés de bases de données) sont restreintes à des ressources nommées, soumises à un contrôle par rôle et, pour les opérations sur les données de production, à l'approbation d'un second administrateur, et sont auditées. Une procédure d'urgence documentée (dite « break-glass ») est réservée aux propriétaires désignés de l'organisation, s'exécute uniquement via notre système CI/CD et est enregistrée et examinée à chaque utilisation.
• L'accès à la base de données de production n'est pas accordé de manière permanente aux ingénieurs : il est demandé à la demande (« just-in-time ») via notre plateforme d'exploitation interne avec un motif déclaré, approuvé par un second administrateur (jamais le demandeur), provisionné sous la forme d'un utilisateur de base de données limité à une seule base de données et à un seul niveau d'accès, jamais avec des droits de modification du schéma, limité dans le temps (en production au maximum 4 heures pour un accès en lecture et 1 heure pour un accès en écriture) et automatiquement supprimé à expiration ; les identifiants ne sont affichés qu'au demandeur. Chaque demande, approbation et révocation est enregistrée. L'exportation de données de production vers des postes de travail est interdite.
• Les données de production restent en production : les environnements de développement et de préproduction utilisent exclusivement des données synthétiques ou anonymisées. Les instantanés de bases de données ne sont restaurés que dans une nouvelle base de données au sein de l'environnement dont ils proviennent, de sorte que les données de production ne sont jamais restaurées dans des environnements de développement ou de test ; une restauration en production exige un motif déclaré et l'approbation d'un second administrateur. Les corrections apportées aux données de production ne sont effectuées que par des tâches préalablement déclarées, soumises à revue de code, testées d'abord en préproduction et approuvées par un second administrateur — jamais par des requêtes SQL ad hoc.
• Piste d'audit de l'activité des opérateurs : toutes les opérations privilégiées effectuées via la plateforme d'exploitation, y compris l'accès au contenu des journaux de production — demandes et approbations d'accès, promotions et retours arrière de versions, changements d'état d'alimentation des environnements, modifications de configuration, approbations de documents et signatures électroniques — sont journalisées avec l'identité de l'opérateur (SSO GitHub, 2FA obligatoire), l'horodatage et le résultat, et sont disponibles comme éléments de preuve pour les auditeurs.
• L'authentification du CI/CD auprès d'AWS s'effectue via la fédération GitHub OpenID Connect avec un rôle de déploiement dédié par environnement, restreint aux dépôts nommés de la plateforme.
• Les procédures d'arrivée, de mobilité et de départ, les vérifications préalables et les engagements de confidentialité font partie de la procédure de sécurité RH ; des revues d'accès sont effectuées périodiquement.

7. Développement sécurisé et gestion des changements

• Chaque modification parvient en production via Git : pull request, revue de code indépendante (approbation par une personne autre que l'auteur), contrôles automatisés et un flux de promotion branche par environnement (développement → préproduction → production). Chaque promotion vers la préproduction et vers la production est demandée par un administrateur et approuvée par un administrateur différent via la plateforme d'exploitation, avec une reconnaissance explicite de toute migration de base de données qu'elle comporte ; la promotion vers la production exige également une validation QA de la version en préproduction. Chaque ensemble de modifications est traçable depuis le ticket jusqu'à la version déployée, et les déploiements en production effectués en dehors de la plateforme d'exploitation sont refusés, sauf dans le cadre de la procédure d'urgence (« break-glass »).
• Les images de conteneurs sont construites une seule fois et analysées à la recherche de vulnérabilités connues lors de leur envoi (push) vers le registre ; les tags du registre de production sont immuables (un tag publié ne peut jamais être remplacé silencieusement) et la production récupère exactement le digest de l'image validée en préproduction — rien n'est reconstruit pour la production.
• Les modifications d'infrastructure suivent le même cheminement (plan Terraform sur pull request, application lors de la fusion), fournissant une piste d'audit complète et vérifiable des modifications en production.
• Les versions peuvent faire l'objet d'un retour arrière composant par composant ; la version déployée de chaque composant est enregistrée avant chaque promotion.

8. Journalisation, surveillance et réponse aux incidents

• Journaux centralisés : les journaux d'application et d'accès de chaque service sont transmis à Datadog (site UE, datadoghq.eu) et à Amazon CloudWatch ; les journaux d'application sont conservés pendant une durée maximale de 90 jours. Les données à caractère personnel et les secrets sont masqués dans les services avant l'envoi des journaux à Datadog, puis à nouveau lors de leur affichage : via notre plateforme d'exploitation, le personnel autre que les administrateurs consulte le contenu des journaux de production avec les valeurs personnelles masquées sur place, et les outils automatisés et d'IA ne reçoivent aucune charge utile de requête ou de réponse, tandis que les informations nécessaires au diagnostic (messages d'erreur, identifiants de requête, codes d'état) restent visibles. Chaque accès au contenu des journaux de production fait l'objet d'un audit.
• Audit cloud et détection des menaces : AWS CloudTrail enregistre chaque appel d'API de gestion effectué dans le compte de production, dans toutes les régions, avec validation de l'intégrité des fichiers journaux et stockage versionné ; Amazon GuardDuty analyse en continu CloudTrail, les VPC Flow Logs et l'activité DNS dans chaque région où nous opérons afin de détecter des menaces telles que l'utilisation abusive d'identifiants, la reconnaissance et la communication avec des hôtes malveillants connus ; les résultats sont examinés par l'équipe d'exploitation.
• Alertes : des alarmes CloudWatch portant sur les bases de données, les caches, les répartiteurs de charge, API Gateway et les événements du cycle de vie des tâches ECS notifient l'équipe d'exploitation via SNS ; les performances applicatives sont surveillées dans Datadog ; l'état de l'infrastructure, les files d'attente, les coûts et les avis d'obsolescence par environnement sont consolidés dans la console de surveillance de la plateforme d'exploitation.
• Page d'état publique : la disponibilité de la plateforme est surveillée en externe et publiée à l'adresse https://status.passportscan.net, avec communication automatique des incidents et des opérations de maintenance.
• Réponse aux incidents : une procédure documentée de réponse aux incidents et de violation de données définit les niveaux de gravité, les rôles et l'escalade. Les violations de données à caractère personnel sont notifiées aux clients concernés dans les meilleurs délais et, en tout état de cause, dans un délai de 48 heures, conformément au DPA, ainsi qu'à l'autorité de contrôle dans un délai de 72 heures lorsque cela est requis (article 33 du RGPD).
• Divulgation des vulnérabilités : les chercheurs en sécurité peuvent signaler des problèmes dans le cadre de la politique de divulgation des vulnérabilités (security@passportscan.net).

9. Continuité d'activité et reprise après sinistre

• La production s'exécute sur des services gérés AWS répartis sur trois zones de disponibilité dans eu-west-1 : le stockage Aurora est répliqué six fois sur les trois zones, les services essentiels exécutent au moins deux tâches réparties entre les zones avec mise à l'échelle automatique en fonction de la charge, et ECS remplace automatiquement une tâche défaillante dans une zone saine derrière les répartiteurs de charge. Les déploiements utilisent un disjoncteur qui procède automatiquement à un retour arrière lorsqu'une nouvelle version échoue à ses contrôles de santé.
• Les bases de données peuvent être restaurées à tout moment dans la fenêtre de conservation de 15 jours ; la procédure de restauration fait partie de l'exercice annuel de reprise après sinistre.
• Une analyse d'impact sur l'activité et un plan de continuité d'activité et de reprise après sinistre définissent les objectifs de reprise de la plateforme (objectif de délai de reprise inférieur à deux heures pour le service d'enregistrement principal ; objectif de point de reprise de l'ordre de quelques minutes grâce à la restauration à un instant donné).
• Les dépendances vis-à-vis de tiers (fournisseur de cloud, fournisseur d'identité, prestataire de paiement, gestion des journaux, protection contre les bots et services de communication d'entreprise) sont évaluées dans le cadre du processus de sécurité des fournisseurs et répertoriées dans la liste des sous-traitants ultérieurs.

10. Sous-traitants ultérieurs

Les tiers qui traitent des données à caractère personnel des clients pour le compte de GlobeID sont répertoriés, avec leur finalité et leur lieu de traitement, dans la liste publique des sous-traitants ultérieurs disponible à l'adresse https://www.passportscan.net/sub-processor/. Les clients sont informés des ajouts conformément au DPA.

11. Responsabilité partagée

GlobeID est responsable de la sécurité de la plateforme telle que décrite ci-dessus. Les clients demeurent responsables : de la gestion de leurs utilisateurs et de leurs identifiants (y compris l'activation de la MFA), de la sécurisation des appareils et des réseaux utilisés pour accéder à la plateforme, de la configuration licite des options de conservation et de stockage régional, de la fourniture d'informations relatives à la protection de la vie privée aux clients de l'établissement, ainsi que de la sécurité de tout PMS ou système tiers qu'ils connectent.

12. Contact

Questions et questionnaires de sécurité : security@passportscan.net Protection des données et DPO : privacy@passportscan.net GlobeID Limited, The Black Church, St. Mary's Place, Dublin 7, D07 P4AX, Irlande (CRO 559612)