Politique de sécurité de l'information

Cette Politique de Sécurité de l'Information décrit les certifications détenues par Didit, les contrôles techniques et organisationnels mis en œuvre par Didit, et les artefacts de confiance disponibles pour les clients, les prospects, les régulateurs et les auditeurs. Elle est révisée au moins tous les six mois.

• Contact sécurité : security@didit.me
• Délégué à la Protection des Données : dpo@didit.me
• Page de statut (en temps réel) : status.didit.me
• Pack de confiance (sous NDA) : envoyer un e-mail à security@didit.me

1. Certifications et attestations

Pour demander l'un des rapports ou certificats sous-jacents, envoyez un e-mail à security@didit.me. Les rapports restreints selon les termes de leur émetteur (par exemple, SOC 2 Type 1) sont partagés après la signature d'un Accord de Non-Divulgation (NDA), le même jour ouvrable.

2. Portée

Cette politique couvre tout le personnel de Didit (employés, sous-traitants et tiers autorisés), tous les systèmes d'information de production et d'entreprise de Didit, et les Services destinés aux clients décrits dans les Conditions Générales Commerciales. Elle est étayée par la Déclaration d'Applicabilité qui ancre le système de management ISO/IEC 27001:2022 de Didit.

3. Gouvernance

• Système de Management de la Sécurité de l'Information et de la Confidentialité aligné sur les contrôles ISO/IEC 27001:2022 et ISO/IEC 27701, avec une Déclaration d'Applicabilité documentée.
• Le Directeur Technique est le sponsor exécutif désigné pour la sécurité de l'information ; le Délégué à la Protection des Données (dpo@didit.me) est responsable de la gouvernance du programme de confidentialité.
• Audit de sécurité externe annuel par des auditeurs indépendants (surveillance ISO 27001 et examens SOC 2).
• Registre des risques revu et mis à jour trimestriellement. Les risques matériels sont remontés au comité de direction.
• Amélioration continue, chaque incident, constat d'audit et évaluation des risques alimente le backlog des actions correctives et la prochaine mise à jour de la politique.

4. Chiffrement et gestion des clés

• Au repos : AES-256 sur chaque base de données de production, magasin d'objets et volume de sauvegarde.
• En transit : TLS 1.3 pour chaque appel API externe, webhook et session de la Console Business. Les anciennes versions de TLS et les chiffrements faibles sont désactivés. HTTP Strict Transport Security (HSTS) est appliqué sur tout le site et préchargé.
• Gestion des clés : AWS Key Management Service (KMS) détient et fait pivoter les clés. Le code de l'application ne touche jamais le matériel de clé brut. Les clés de sandbox et de production sont entièrement séparées.
• Hachage : les identifiants des clients sont hachés avec des fonctions adaptatives standard de l'industrie (bcrypt ou équivalent). Les clés API sont stockées sous forme de hachages unidirectionnels ; la valeur brute n'est affichée à l'opérateur qu'au moment de la création.

5. Identité, accès et architecture zéro confiance

• Zéro confiance par défaut, chaque requête vers chaque système interne est authentifiée et autorisée. Il n'y a pas de confiance implicite basée sur l'emplacement réseau.
• Contrôle d'accès basé sur les rôles (RBAC) avec le principe du moindre privilège. Les revues d'accès sont effectuées trimestriellement.
• L'Authentification Multi-Facteurs (MFA) est obligatoire pour chaque employé, chaque système de production, chaque console cloud et chaque compte d'hébergement de code.
• Authentification Unique (SSO) pour les applications internes, avec MFA par jeton matériel pour les rôles privilégiés.
• Accès Juste-à-Temps pour la production : l'accès privilégié permanent est l'exception, pas la règle.
• Journalisation d'audit, chaque action privilégiée est enregistrée dans un pipeline d'audit inaltérable, à écriture unique, conservé pendant au moins 12 mois.

6. Résidence et ségrégation des données

• Union Européenne par défaut. Les données de production sont traitées et stockées dans l'Union Européenne sur Amazon Web Services. La résidence spécifique à une région ou à un pays est disponible sur les contrats Enterprise, sous réserve de disponibilité, pour les juridictions dont les régulateurs l'exigent.
• Séparation des environnements. Le sandbox, le staging et la production sont isolés au niveau du réseau, de l'identité et des couches de gestion des clés. Aucun humain ou service dans un environnement ne peut lire les données dans un autre sans un chemin d'accès explicite et audité.
• Séparation des locataires. Les données multi-locataires sont logiquement séparées avec des clés de chiffrement par locataire le cas échéant. Les requêtes inter-locataires sont bloquées au niveau de l'application et de la base de données.

7. Cycle de vie du développement sécurisé (SDLC)

• La revue de code est requise pour chaque modification de production. Aucun ingénieur ne peut fusionner du code non revu en production.
• Le Static Application Security Testing (SAST), l'analyse des dépendances et le Software Composition Analysis (SCA) s'exécutent automatiquement sur chaque pull request.
• L'analyse des conteneurs et de l'infrastructure à chaque build et selon un calendrier récurrent pour les images déployées.
• Les tests de sécurité pré-production pour les changements à fort impact (authentification, gestion des clés, pipelines biométriques, flux de paiement).
• Les tests d'intrusion internes en continu ; les tests d'intrusion externes au moins une fois par an par des spécialistes indépendants. Les découvertes matérielles sont suivies jusqu'à leur résolution selon un calendrier lié au SLA.
• Canal de Bug-bounty / divulgation responsable, signaler les problèmes de sécurité à security@didit.me.

8. Gestion des vulnérabilités

• SLA de patch par gravité, critique (dans les 72 heures suivant la divulgation du fournisseur), élevée (dans les 7 jours), moyenne (dans les 30 jours), faible (dans les 90 jours).
• Analyse continue des vulnérabilités sur l'infrastructure de production, les conteneurs et les dépendances.
• Modélisation des menaces pour les nouvelles surfaces de produits, les pipelines biométriques et les intégrations inter-environnements.

9. Surveillance, détection et réponse aux incidents

• Surveillance 24h/24 et 7j/7 de chaque système de production avec alerte sur la disponibilité, les erreurs et les signaux de sécurité.
• Le Security Information and Event Management (SIEM) agrège et corrèle les événements de sécurité ; les schémas anormaux sont remontés aux ingénieurs de sécurité d'astreinte.
• Plan de Réponse aux Incidents documenté avec des rôles nommés, un arbre de communication, une matrice de gravité et un processus de revue post-incident. Le plan est testé au moins annuellement via des exercices de simulation de crise.
• Notification de violation de données personnelles. Didit notifie les clients concernés sans délai excessif et en tout état de cause à temps pour permettre aux clients de respecter leur propre obligation de notification de 72 heures en vertu de l'article 33 du Règlement Général sur la Protection des Données (RGPD). Les clients Enterprise reçoivent un ingénieur dédié d'astreinte et un canal de communication dédié.
• Page de statut publique sur status.didit.me, chaque incident de production, chaque post-mortem, sans connexion requise.

10. Continuité des activités et reprise après sinistre

• Redondance active multi-AZ dans chaque région de production ; basculement automatique pour les services sans état.
• Les sauvegardes sont chiffrées, séparées géographiquement au sein de la limite de résidence choisie et testées selon un calendrier récurrent.
• Objectif de Point de Récupération (RPO) ≤ 1 heure et Objectif de Temps de Récupération (RTO) ≤ 4 heures pour l'API de vérification principale et la Console Business.
• Tests de Reprise après Sinistre (DR) au moins annuellement.

11. Sécurité du personnel

• Vérifications d'antécédents pour chaque employé et chaque sous-traitant ayant accès aux données de production ou aux données personnelles, lorsque la loi applicable le permet.
• Accords de confidentialité à l'embauche pour chaque employé et sous-traitant.
• Formation obligatoire sur la sécurité et la confidentialité à l'intégration et rafraîchie au moins annuellement pour chaque employé. Formation ciblée (codage sécurisé, gestion des données biométriques, anti-fraude, anti-blanchiment d'argent) pour les rôles qui en ont besoin.
• Simulations de phishing selon un calendrier récurrent.
• Le processus d'intégration / mobilité / départ révoque l'accès dans les 24 heures suivant un changement de rôle ou un départ.

12. Gestion des fournisseurs et sous-traitants

• Chaque sous-traitant est évalué en termes de risques avant l'intégration et réévalué au moins annuellement.
• Chaque sous-traitant signe un Accord de Traitement des Données (DPA) imposant des obligations de protection des données substantiellement similaires à celles que Didit doit à ses propres clients.
• La liste actuelle des sous-traitants est partagée avec les clients et les prospects par e-mail après la signature d'un Accord de Non-Divulgation (NDA). Envoyez un e-mail à security@didit.me pour la demander. Les clients abonnés aux notifications de changement de sous-traitant sont informés par e-mail avec un préavis suffisant pour s'y opposer.

13. Droits des personnes concernées et suppression des données

• Droit d'accès et de portabilité, `GET /v3/sessions/:session_id/decision/`.
• Droit à l'effacement, `POST /v3/sessions/:session_id/delete/`. Supprime la session et tous les artefacts liés sur chaque réplique.
• La rétention par application est configurable dans la Console Business entre 30 jours et 10 ans ; la valeur par défaut est indéfinie à moins que le client ne configure une période plus courte. La rétention des données biométriques est dans tous les cas soumise à, et plafonnée par, les lois et réglementations applicables en matière de confidentialité biométrique, y compris l'article 9 du Règlement Général sur la Protection des Données (RGPD) de l'UE, le Illinois Biometric Information Privacy Act (BIPA), le Texas Capture or Use of Biometric Identifier Act (CUBI), le Washington H.B. 1493, et toute autre loi applicable en matière de confidentialité biométrique ; lorsque cette loi prescrit une période de rétention plus courte ou une obligation de destruction antérieure, cette règle plus courte ou plus stricte prévaut sur toute période de rétention par défaut ou configurée par le client.
• Voir la Politique de Confidentialité et l'Avis de Confidentialité de la Vérification pour le processus complet des droits des personnes concernées.

14. Signaler un problème de sécurité

Si vous pensez avoir trouvé une vulnérabilité de sécurité dans un produit ou service Didit, envoyez un e-mail à security@didit.me avec une description, les étapes de reproduction et l'impact que vous avez observé. Didit accuse réception des rapports de sécurité dans les 2 jours ouvrables et travaille de bonne foi avec les rapporteurs qui suivent les pratiques de divulgation responsable.

15. Contact

• Sécurité : security@didit.me
• Délégué à la Protection des Données : dpo@didit.me
• Confidentialité : privacy@didit.me
• Juridique / contrats : legal@didit.me
• Demande de pack de confiance (sous NDA) : security@didit.me