Sécurité
Dernière mise à jour · 8 août 2026
Orqex s’intercale entre les systèmes des clients et leurs prestataires de paiement. Notre approche vise à minimiser les données sensibles, limiter les accès, vérifier les communications, préserver l’intégrité des transactions et résister aux erreurs et défaillances de tiers. Cette page est une présentation publique, et non une attestation d’audit ou un accord de niveau de service.
1. Responsabilité partagée
Orqex sécurise la plateforme et les composants qu’il exploite, authentifie et autorise les accès, protège les secrets stockés, signe ou vérifie les webhooks pris en charge, sépare les locataires et environnements et maintient les contrôles de la plateforme. Les clients sécurisent leurs applications, réseaux, appareils et comptes de prestataires ; attribuent les rôles et retirent les accès obsolètes ; stockent les clés dans un gestionnaire de secrets adapté ; vérifient les webhooks Orqex et appliquent l’idempotence ; séparent test et production ; et garantissent la conformité de leurs transactions, données et intégrations.
2. Minimisation des données de carte
Orqex n’est pas conçu pour recevoir ou stocker les numéros complets de carte, cryptogrammes visuels, codes PIN ou données de piste magnétique. Les données de carte doivent passer directement du payeur au Prestataire de paiement sélectionné au moyen de pages hébergées, jetons ou composants approuvés. Les clients ne doivent jamais inclure de données brutes de carte dans les métadonnées, journaux, webhooks, champs libres, demandes de support ou l’environnement de test.
3. Authentification et contrôle d’accès
Les contrôles comprennent des jetons utilisateur signés, l’authentification multifacteur obligatoire pour les accès internes, des rôles et autorisations dans les organisations et projets, la vérification de l’appartenance au projet avant l’accès à une ressource, des chemins distincts pour utilisateurs, personnel interne, clés secrètes et clés publiables, la limitation des requêtes sensibles et la traçabilité des activités administratives. Le personnel n’accède aux données clients que lorsque cela est nécessaire au support, aux incidents, au respect de la loi ou à la protection de la plateforme.
4. Clés API et secrets
Les clés API secrètes contiennent un secret aléatoire, sont affichées intégralement uniquement à leur création et sont stockées sous forme d’empreinte SHA-256 irréversible. Elles peuvent être désactivées, expirées, limitées par une liste d’adresses IP et renouvelées avec une courte période de transition. Les clés publiables ont volontairement des droits limités. Les identifiants de prestataires, secrets de webhook et secrets multifacteurs du personnel stockés par Orqex sont protégés par chiffrement applicatif et masqués ou soumis à des permissions lors de leur affichage.
5. Séparation des locataires et environnements
Chaque projet constitue une frontière logique pour les comptes de prestataires, règles de routage, clients, transactions, remboursements, paiements sortants, clés et paramètres. Les clés, comptes, transactions et agrégats de production et de test sont séparés par environnement. Une clé de test ne doit pas autoriser une opération de production. Les clients doivent éviter les vraies données sensibles dans l’environnement de test.
6. Communications sécurisées et webhooks
Les interfaces de production et les endpoints de webhook configurés doivent utiliser HTTPS. Les webhooks entrants pris en charge font l’objet d’une vérification de signature et d’un dédoublonnage des événements. Les webhooks sortants Orqex sont signés, valident les certificats TLS de destination, ne suivent pas automatiquement les redirections et utilisent des nouvelles tentatives contrôlées. Les clients doivent vérifier la signature, l’horodatage et l’identité de l’événement avant d’agir.
7. Intégrité des transactions
Orqex utilise des clés d’idempotence pour les opérations API modifiant l’état, un verrouillage atomique pour les captures concurrentes d’une même intention, des limites de tentatives, des états explicites, des identifiants uniques, le dédoublonnage des événements de prestataires, des conditions prudentes de basculement et la vérification différée des résultats asynchrones. Les clients doivent néanmoins rendre leurs traitements idempotents et rapprocher leurs propres registres.
8. Contrôles contre la fraude et les abus
Orqex peut utiliser l’adresse IP, l’appareil, le pays, l’historique des tentatives, des empreintes irréversibles d’instruments, la vélocité et d’autres signaux pour identifier l’automatisation, les tests de cartes, les instruments bloqués, les volumes anormaux, les schémas de fraude ou les anomalies de prestataires. Les empreintes internes utilisent un HMAC SHA-256 contextualisé afin d’éviter les comparaisons sur la valeur brute. Le Client reste responsable de la configuration, de l’examen humain nécessaire et des conséquences métier.
9. Journalisation et données sensibles
Orqex enregistre les événements nécessaires au diagnostic, à la sécurité, à l’audit et à la livraison des transactions. Les contrôles de journalisation masquent les champs couramment sensibles tels que les en-têtes d’autorisation, clés API, mots de passe, jetons, OTP, secrets et données de carte. Cela ne remplace pas l’obligation du Client de ne pas transmettre de secrets dans des champs non prévus. Les journaux de webhooks sont conservés 30 jours selon la configuration de référence. Les exports expirent après 7 jours et utilisent des liens signés à durée limitée.
10. Développement et exploitation sécurisés
Les pratiques de référence comprennent une revue avant déploiement en production, des tests automatisés des règles d’accès et invariants de paiement, la validation aux frontières du système, la séparation des responsabilités, la gestion des dépendances et correctifs selon le risque, des secrets de production gérés par environnement, des expirations et nettoyages planifiés et la surveillance des erreurs, files, traitements différés et services critiques. Les détails susceptibles de faciliter une attaque ne sont pas publiés.
11. Prestataires et dépendances
Orqex utilise des prestataires d’infrastructure, de surveillance, de communication et de paiement dont les accès doivent être limités et encadrés contractuellement. Les Prestataires de paiement connectés par le Client restent des systèmes tiers. Leur panne, compromission ou modification d’API peut affecter les transactions. Orqex utilise des contrôles de basculement et de récupération lorsque le flux le permet, sans pouvoir garantir qu’un autre prestataire acceptera l’opération.
12. Réponse aux incidents
En cas d’incident suspecté, Orqex vise à qualifier et contenir l’événement, protéger les clés et données concernées, préserver les preuves, corriger la cause, restaurer prudemment, déterminer les clients et obligations concernés, notifier les clients affectés sans retard injustifié lorsque requis et documenter les actions correctives. Les clients doivent maintenir des contacts d’urgence et coopérer rapidement, notamment pour renouveler les clés ou agir sur leurs systèmes.
13. Résilience
Les états persistants, files, nouvelles tentatives contrôlées, vérifications différées et mécanismes d’idempotence sont conçus pour faciliter la récupération et éviter une double exécution après une interruption. Les engagements de disponibilité, sauvegarde, point de reprise ou délai de reprise ne s’appliquent que s’ils figurent dans un Bon de commande ou accord de niveau de service signé.
14. Certifications
La réduction du périmètre des données de carte est un objectif architectural, pas une certification. Sauf attestation valide dont la portée est expressément identifiée dans un contrat ou centre de confiance, Orqex ne revendique pas de certification PCI DSS, ISO 27001, SOC 1 ou SOC 2. Les clients ne doivent pas présenter Orqex comme certifié sur la seule base de cette page.
15. Divulgation responsable
Signalez confidentiellement les vulnérabilités à security@axazara.com avec l’actif concerné, une description claire, des étapes minimales de reproduction, l’impact potentiel et des preuves non destructives. Utilisez uniquement vos comptes et données de test. N’accédez pas aux données de tiers, ne perturbez pas le Service, ne menez pas de déni de service ou d’ingénierie sociale, n’installez pas de logiciel malveillant, ne conservez pas d’accès et ne publiez rien avant un délai raisonnable de correction. Arrêtez immédiatement si vous rencontrez une donnée ou un secret appartenant à un tiers.
16. Attentes envers les chercheurs et contact
Orqex vise à accuser réception d’un signalement sous trois jours ouvrés et à fournir des nouvelles raisonnables selon sa gravité. Cet objectif opérationnel n’est pas un SLA. Cette politique n’est pas un programme rémunéré de bug bounty. Une recherche de bonne foi conforme à ces règles ne déclenchera pas d’action initiée par Axa Zara, sous réserve de la loi et des droits des tiers. Les questionnaires de sécurité et demandes d’architecture peuvent également être adressés à security@axazara.com et peuvent nécessiter un accord de confidentialité.
