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, ainsi que les preuves 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 d'état (en temps réel) : status.didit.me
• Dossier 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 conditions 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 gestion ISO/IEC 27001:2022 de Didit.

3. Gouvernance

• Système de gestion 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 de la technologie (CTO) est le sponsor exécutif désigné pour la sécurité de l'information ; le Délégué à la protection des données (DPO) (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 examiné et mis à jour trimestriellement. Les risques importants sont transmis au comité de direction.
• Amélioration continue, chaque incident, constat d'audit et évaluation des risques alimente le carnet de commandes 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, stockage d'objets et volume de sauvegarde.
• En transit : TLS 1.3 pour chaque appel API externe, webhook et session de la console Business. Les versions TLS plus anciennes et les chiffrements faibles sont désactivés. HTTP Strict Transport Security (HSTS) est appliqué sur l'ensemble du 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 Zero Trust

• Zero Trust 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 multifacteur (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 d'entreprise, sous réserve de disponibilité, pour les juridictions dont les régulateurs l'exigent.
• Séparation des environnements. Le sandbox, la pré-production et la production sont isolés au niveau du réseau, de l'identité et de la 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 obligatoire 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.
• Le scan de conteneurs et d'infrastructure à chaque build et selon un calendrier récurrent pour les images déployées.
• Le test 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 constatations importantes sont suivies jusqu'à leur résolution selon un calendrier lié à un SLA.
• Programme de Bug Bounty / canal de divulgation responsable, signalez 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 interfaces 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 alertes 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 transmis aux ingénieurs de sécurité d'astreinte.
• Plan de réponse aux incidents documenté avec rôles désignés, arbre de communication, matrice de gravité et processus d'examen post-incident. Le plan est testé au moins une fois par an via des exercices de simulation.
• Notification de violation de données personnelles. Didit informe 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 d'entreprise reçoivent un ingénieur désigné d'astreinte et un canal de communication dédié.
• Page d'état 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, géographiquement séparées 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 une fois par an.

11. Sécurité du personnel

• Vérifications des 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 en matière de sécurité et de confidentialité à l'intégration et mise à jour au moins une fois par an pour chaque employé. Formation ciblée (codage sécurisé, traitement 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 / de mobilité / de 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 son intégration et réexaminé au moins une fois par an.
• 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

• 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 illimitée, sauf si le client configure une période plus courte. La rétention des données biométriques est dans tous les cas soumise et limité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.
• Consultez la Politique de confidentialité et l'Avis de confidentialité pour la vérification pour le processus complet des droits des personnes concernées.

14. Signalement d'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

Si vous avez des questions concernant cette politique, contactez :

• 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 dossier de confiance (sous NDA) : security@didit.me