Les exchanges crypto sont à l'intersection de deux modèles de menace : la fintech traditionnelle (avec tout ce que ça implique de sécurité d'API, d'accès interne et de conformité) et le crypto-natif (avec tout ce que ça implique de gestion des clés, de surveillance on-chain et de l'impossibilité de défaire une transaction).
MiCA, DORA et les divers régimes nationaux PSAN/VASP relèvent la barre de la sécurité documentée à travers l'UE. Les attaquants modernes relèvent la barre de la vraie sécurité sous-jacente. Cet article couvre ce qu'on regarde quand on fait une revue de sécurité pour un exchange, et ce que les équipes doivent avoir en place, opérationnellement et sur le papier.
Custody : hot, warm, cold
L'architecture vers laquelle les opérateurs d'exchange convergent, et qu'on recommande, ressemble à ceci :
La cold storage détient l'écrasante majorité des fonds clients. Air-gappée, multi-sig ou MPC à seuil, signataires distribués géographiquement, opérations hardware uniquement. Touchée selon un calendrier défini pour le réapprovisionnement, jamais à la demande.
La warm storage détient le buffer opérationnel. Plusieurs jours de volume de retrait attendu. Signée par un seuil plus petit, plus rapide à mobiliser, mais toujours via signature hardware-backed.
Les hot wallets détiennent le float opérationnel immédiat. Signés automatiquement par des services HSM- ou KMS-backed, avec des policies programmatiques strictes, caps par transaction, caps par heure, address whitelists quand possible.
La question pertinente, ce n'est pas « cette architecture est-elle bonne ? », c'est « quelle est la pire perte ? ». Un drain du hot wallet doit être une mauvaise journée. Un drain du warm doit être un incident sérieux. Un drain du cold doit être impossible sans compromission de plusieurs organisations indépendantes.
On conçoit et audite ces architectures dans une mission Wallet Setup, et on les surveille en continu via Wallet Surveillance.
Le pipeline de retrait
L'endpoint le plus attaqué de tout exchange, c'est le flux de retrait. C'est aussi le plus dur à sécuriser parce qu'il doit rester assez rapide pour livrer un produit compétitif.
Les questions qu'on pose dans une mission Penetration Testing :
- Quel est le chemin entre l'utilisateur qui appuie sur « retirer » et la transaction signée ? Combien de systèmes entre la requête et la signature ?
- Où est la clé de signature ? Quelle est la frontière de confiance ?
- Une compromission de l'API user-facing peut-elle entraîner un retrait ? Et de l'admin tooling ? Du CI/CD ? Du laptop d'un seul ingénieur ?
- Quelles rate limits s'appliquent, sur quelles dimensions (par utilisateur, par IP, par adresse, globalement) ?
- Quelles confirmations out-of-band existent pour les nouvelles adresses de retrait ?
- Quelle détection automatique d'anomalie tourne, et sur quoi paget-elle ?
- Combien de temps faut-il pour mettre un retrait en pause une fois une anomalie détectée ?
Les exchanges qui ont perdu des fonds clients avaient en général une de ces réponses fausse, pas toutes. La défense est en couches : chaque étape qui pourrait échouer doit être backstoppée par une autre.
Surface d'API et accès interne
Les exchanges accumulent des APIs plus vite que les revues d'API. REST, WebSocket, FIX, admin panels internes, endpoints partenaires, gateways market-maker. Chacun est un point d'entrée potentiel.
Findings courants dans nos rapports de pentest :
- IDOR sur de l'admin tooling interne, où un utilisateur modérément privilégié peut agir sur des comptes qu'il ne devrait pas voir.
- Bugs d'isolation de tenant dans des setups white-label ou sub-account, transactions d'un tenant visibles ou actionnables depuis un autre.
- Auth sur endpoints internes plus faible que sur ceux user-facing, sur l'hypothèse « le trafic interne est de confiance ».
- Lacunes de rate-limiting qui permettent de l'énumération de comptes ou du credential stuffing à grande échelle.
- Secrets dans le CI/CD qui ont survécu à un workflow déprécié et restent valides.
- Permissions de clé d'API plus larges qu'elles ne devraient, une clé read-only qui s'avère pouvoir aussi bouger des fonds.
Chacun a été un vrai finding sur une vraie mission. Aucun n'est exotique. C'est ce qu'on trouve quand un attaquant compétent passe une semaine à chercher, ce qu'on fait, en amont, pour que le prochain qui cherche ne trouve rien.
Monitoring on-chain
L'empreinte on-chain d'un exchange est énorme et à enjeu. Hot, warm, cold, adresses de dépôt par client, sweep wallets internes, flux de rebalancing market-maker. Chacun a un profil qui, quand il dérive, est un signal qui mérite enquête.
Wallet Surveillance pour un exchange couvre :
- Sweeps d'adresses de dépôt qui ont l'air inhabituelles (volume, destinations, timing).
- Sorties de hot wallet qui divergent de la baseline, même de peu.
- Activité de cold wallet tout court (toute activité est, par design, un événement).
- Propositions multi-sig en file avant exécution.
- Approvals à des contrats inconnus, parfois l'indicateur précoce d'une compromission interne.
- Interactions avec des adresses sanctionnées (liste OFAC SDN, adresses tainted Tornado), un signal compliance et sécurité.
Le monitoring est continu ; la réponse est humaine. Un vrai analyste à l'autre bout de l'alerte, c'est la différence entre un dashboard outillé et une vraie fonction sécurité.
Préparation aux incidents
Un incident dans un exchange est existentiel. Des fonds clients perdus, ce n'est pas une position récupérable, financièrement, réputation, ou réglementairement.
La préparation minimum :
- Un chemin de pause pour le pipeline de retrait, détenu par un petit groupe d'astreinte, avec un SLA de réponse publié.
- Une procédure de communication permanente, drafts pré-validés avec le légal et le conseil, prêts à remplir.
- Une relation avec un cabinet de Réponse à incident, sous retainer, avec des SLA proportionnels à la valeur en jeu.
- Une capacité de trace-and-recovery, interne ou contractée, qui peut produire un récit on-chain en heures.
- Une liste de contacts régulateurs et law-enforcement, par juridiction.
Ce n'est pas optionnel. MiCA et les régimes équivalents exigent de plus en plus des preuves documentées de chacun, et les régulateurs le demandent à l'inspection, pas seulement après les incidents.
Notes spécifiques MiCA
Pour les exchanges opérant dans l'UE, MiCA introduit des attentes opérationnelles spécifiques :
- Ségrégation de la custody. Fonds clients non commingled avec les fonds opérationnels de l'exchange. Documenté, auditable, on-chain quand possible.
- Gestion des risques ICT sous DORA, recouvrement large avec les contrôles sécurité. Un programme SOC 2 Type II ou ISO 27001 devient de plus en plus la preuve de fait.
- Contrôles d'externalisation. Les fournisseurs tiers (partenaires custody, intégrations market-maker, fournisseurs KMS) demandent des contrôles contractuels et opérationnels.
- Reporting d'incident avec des délais définis vers les autorités compétentes. Une équipe sans pipeline de reporting en heure zéro va rater le délai.
- Conformité Travel Rule pour les transferts au-dessus de seuils, y compris la coordination avec les autres entités régulées.
Les exchanges qui obtiennent l'autorisation aujourd'hui bénéficient de règles plus claires que la mosaïque nationale précédente. La rampe réglementaire est réelle, et les contrôles de sécurité sous-jacents en sont l'essentiel.
À quoi ressemble le bon
Les exchanges qui n'apparaissent pas dans les rapports d'incident partagent un profil :
- Architecture de custody qu'un reviewer externe qualifierait de boring. Pas de schémas exotiques, pas de raccourcis astucieux, pas d'hypothèses de confiance énoncées dans des slide decks au lieu de contrats.
- Une surface d'API régulièrement battue par des testeurs externes, avec findings suivis, corrigés, re-testés.
- Un monitoring on-chain continu avec un analyste humain à l'autre bout.
- Procédures opérationnelles documentées que l'équipe sait exécuter sous pression, parce qu'elle a répété.
- Une relation établie avec un cabinet de réponse à incident.
- Documentation conformité qui reflète les opérations réelles, pas aspirationnelles.
Rien de tout cela n'est excitant. Tout cela compose, année après année, en une posture de sécurité qui ne fait pas la une.
L'alternative excitante, c'est celle qui fait la une. Choisissez.