FAQ

La protection du matériel cryptographique critique (CCM) concerne uniquement : l'inventaire, la génération, le stockage, l'utilisation, le cycle de vie, l'architecture du portefeuille, la détection des compromissionssions et le contrôle du personnel (domaines B.1–B.8). La frontière est délibérément étroite – de la même manière que le PCI DSS protège uniquement les données des titulaires de carte. Délibérément hors de portée : sécurité des contrats intelligents, preuve de réserves et composition des réserves, AML et criminalistique en chaîne, intégrité du moteur de négociation et manipulation du marché. Il s’agit là d’une limite de positionnement, et non d’une lacune : le Conseil ne fait pas double emploi avec les fonctions de renseignement financier et ne vérifie pas la logique commerciale.

À quatre segments (Section C) : C.1 — portefeuilles de conservation et dépositaires (tous les domaines 8 obligatoires), C.2 — portefeuilles non dépositaires, où le sujet de certification est le fournisseur ou le fabricant de l'appareil, jamais l'utilisateur final, C.3 — échanges pour leur infrastructure de conservation, C.4 — émetteurs pour leurs clés neuves/brûlées. Le niveau de chaque segment est déterminé par sa propre mesure d'échelle (AUM, MAU, volume quotidien, capitalisation boursière). Une organisation opérant sur plusieurs segments répond à l'ensemble de toutes les exigences obligatoires, et le niveau global est le plus strict parmi ses segments.

Non. CCSS (CryptoCurrency Security Standard) est un partenaire de base de CCSA, pas un concurrent : ses exigences sont conservées et les niveaux CCSS I/II/III correspondent aux niveaux CCSA 1/2/3. La différence est la couverture. CCSS se concentre sur la gestion des clés pour les portefeuilles et les échanges ; CCSA couvre en outre quatre segments (portefeuilles, bourses, dépositaires, émetteurs), ajoute un positionnement réglementaire, un registre public de produits certifiés et un réseau d'auditeurs accrédités. Nous faisons délibérément référence à CCSS plutôt que de le réécrire.

La sécurité des infrastructures cryptographiques est fragmentée : chaque segment a son propre standardisateur (PCI SSC pour les cartes, C4 pour les portefeuilles CCSS, Rosstandart pour GOST R 57580.3 en Russie, EBA/ESMA pour MiCA dans le EU), mais aucun ne couvre la protection du matériel cryptographique. de bout en bout, et 60–70 % du travail d'infrastructure commune est dupliqué. CCSA ne remplace pas ces normes ; il les relie via une seule matrice de report et ajoute un delta étroit uniquement pour le matériel cryptographique critique. La posture est « référence, ne réécrivez pas ».

CCSA est une initiative de marché au stade de projet v0.2 ; il s’agit aujourd’hui d’une norme privée et non d’une exigence réglementaire obligatoire. Le poste cible est une initiative mondiale avec une reconnaissance régionale. Le chemin vers la reconnaissance figure sur la feuille de route : la v1.0 est ciblée pour 2026-12-01, et la feuille de route répertorie les demandes de reconnaissance dans les juridictions non russes (VARA à Dubaï, FSRA dans ADGM) dans 2028. Ce sont des objectifs planifiés et non un statut confirmé. CCSA complète les exigences des régulateurs plutôt que de les concurrencer.

La norme est gérée par le Conseil CCSA, une organisation privée de normalisation calquée sur PCI SSC et la Linux Foundation. Les décisions standard sont prises par un conseil d'administration indépendant (au moins des membres du 7 : un président indépendant, des administrateurs indépendants et des sièges d'observateurs de membres fondateurs sans droit de vote). 4pay.online est l'un des membres fondateurs avec l'un des sept sièges — la première société de référence, et non le propriétaire de la norme. À ce stade, la composition nommée du conseil d'administration et des comités est publiée sous forme de sièges réservés avec des délais de nomination, et non sous forme de noms confirmés.

Si l'organisation détient un certificat de base valide (PCI DSS, GOST 57580, CCSS, SOC 2 Type 2 ou MiCA), les exigences CCSA correspondantes sont reportées sous conditions : l'âge du certificat ne dépasse pas 12 mois au début de l'évaluation, au moins Mois de validité restants du 6, chevauchement de la portée avec l'environnement CCM et validation de l'authenticité basée sur le registre. Catégories : Complète – l'exigence est acceptée sans nouveau test ; Partiel – seule la partie spécifique à la cryptographie est en outre testée ; N/A — le report ne s’applique pas. Avec le report de références multiples, l'auditeur effectue environ 50 % du travail par rapport à un audit complet, soit à titre indicatif 1.5–2x moins cher pour le client.

Non. Les huit exigences critiques ne sont jamais reportées, quelle que soit la force du certificat de base : elles sont toujours testées dans leur intégralité via l'approche définie. Ceux-ci incluent l'inventaire et la classification CCM (B.1.1, B.1.2), le stockage du matériel cryptographique critique dans HSM/MPC/Secure Enclave (B.3.1), la révocation et la rotation sécurisées des clés (B.5.2) et la détection des compromissionssions (B.7.3). Pour quatre d’entre eux, un contrôle compensatoire est totalement interdit ; pour le reste, il n'est autorisé qu'au niveau 1 avec l'approbation du Conseil. Leur mappage dans les tableaux est uniquement un contexte de référence.

Grâce à une structure de gouvernance et une politique formelle. Les décisions standard sont prises par un conseil d'administration indépendant : le président et les administrateurs indépendants ne peuvent pas être des employés du Conseil, d'une organisation membre ou d'un cabinet d'audit accrédité, et ne doivent avoir aucun lien financier avec eux. La divulgation annuelle des affiliations est obligatoire pour les propriétaires du conseil d’administration, des cadres supérieurs et des cabinets d’audit. En cas de conflit actif, le participant se récuse : pas de discussion, pas de vote, pas d'accès aux documents, et le fait est enregistré dans un registre public. Les conflits non divulgués entraînent des sanctions pouvant aller jusqu'à l'annulation de la décision et à la cessation de la participation. Il s’agit d’un rejet délibéré du modèle « les bourses s’autorégulent » – la leçon de l’échec du CARC (2019–2022).

Le total comporte trois parties versées à différents destinataires et dépend du segment et du niveau ; vous trouverez ci-dessous un projet de chiffres indicatifs v0.2- excluant VAT. Exemple d'échange (C.3) ciblant le niveau 2 : adhésion standard ~RUB 1.0M/an plus une liste LVCS L2 ~RUB 1.2M avec la réduction membre — de l'ordre de RUB 2.1M au Conseil la première année. Un scénario plus petit – un fournisseur de portefeuille non dépositaire (C.2) au niveau 1 – est sur ordre de RUB 0.58M au Conseil. De plus, le travail du cabinet d'audit (CCSAC) est payé séparément et dépend du volume ; le report le réduit. Tous les chiffres sont des objectifs planifiés ; le Conseil confirme l'estimation définitive de votre scénario.

Il existe trois destinataires de paiement avec des rôles séparés. Le Conseil facture l'adhésion à une organisation participante ainsi que l'inscription et la maintenance d'un produit dans le registre LVCS (par niveau). Le cabinet d'audit accrédité (CCSAC) facture l'évaluation elle-même et le rapport – ce paiement revient au cabinet et non au Conseil. Les cabinets d'audit et les professionnels individuels passent à leur tour par une accréditation et un cours delta. La séparation des destinataires fait partie de la politique de conflit d'intérêts : l'organisation qui gère la norme n'est payée pour aucune évaluation spécifique.

Le Conseil CCSA est une organisation privée de normalisation, et non un régulateur gouvernemental, et le développeur de la norme, et non un garant. Un certificat confirme la conformité à la méthodologie CCSA au moment de l'évaluation et réduit le risque de compromission du matériel cryptographique, mais ne l'élimine pas et ne constitue pas une garantie contre un incident. À ce stade, la conformité à CCSA est volontaire ; la norme complète les exigences des régulateurs et se veut une méthodologie d'évaluation reconnue et non un remplacement.

Ce qui est publié maintenant est le projet v0.2 : le texte normatif complet est lisible et en consultation publique, mais les exigences peuvent changer avant sa publication. La date cible de la v1.0 est 2026-12-01, prenant effet 2027-01-01 ; les engagements du Conseil sont fixés à v1.0. Les modifications substantielles entre les versions et les exigences en cours de consultation sont suivies dans le journal des modifications. Vous pouvez déjà vous fier au texte pour préparer — pour la certification finale, ciblez la v1.0.