Architecture du scanner
Architecture du scanner
Le DuoKey PQC Scanner est un outil CLI natif en Rust construit sur Tokio, Clap et Rustls. Il est livré sous la forme d'un binaire unique avec 10 commandes de scan, une exécution parallèle via Rayon, et des sorties aux formats JSON, YAML, HTML, terminal ANSI et CBOM CycloneDX.
Architecture du scanner PQC
CLI Rust haute performance pour la découverte cryptographique post-quantique et l'évaluation des risques
Scanners d'infrastructure
E/S asynchronesScanners avancés
ExtensibleÉvaluation de la préparation PQC
Inventaire cryptographique complet avec notation de la vulnérabilité quantique et feuille de route de migration
Flux de données de haut niveau
Chaque scan suit le même pipeline en cinq étapes, de l'invocation de la CLI jusqu'à la sortie du rapport.
Analyse de la CLI (clap 4.5)
L'utilisateur invoque l'une des 10 sous-commandes (filesystem, domain, agent, network, serve, ci, sourcecode, compliance, servicenow, cbom). Clap analyse les arguments, valide les entrées et redirige vers le scanner correspondant.
Exécution du scanner
Le scanner sélectionné collecte les données cryptographiques brutes -- handshakes TLS, fichiers de certificats, motifs de code source, métadonnées de KMS cloud ou clés d'hôte SSH. Les scanners utilisent Tokio pour les E/S asynchrones et Rayon pour le parcours de fichiers en parallèle sur le CPU.
Couche d'analyse (PEM / DER / PKCS#12)
Les données brutes sont transmises à des analyseurs spécifiques au format pour PEM, DER, PKCS#12, le magasin de certificats Windows et CBOM, qui extraient les métadonnées de certificats, les algorithmes de clés et les schémas de signature à l'aide des crates x509-parser et schannel.
Notation des risques (0-10)
Chaque découverte analysée passe par le moteur de notation des risques, qui attribue un score de risque quantique de 0 à 10, le fait correspondre à un niveau de sévérité (de Critique à Info), assigne une priorité (de P0 à P4), et génère des raisons et des recommandations lisibles par un humain.
Formatage de la sortie
Le ScanResult noté est sérialisé par le formateur de sortie choisi -- JSON, YAML, HTML, terminal ANSI ou CBOM CycloneDX 1.7 -- et écrit dans un fichier ou sur stdout.
Le point d'entrée du binaire initialise un runtime asynchrone Tokio avec le souscripteur tracing pour la journalisation structurée. Toutes les opérations du scanner sont asynchrones par défaut, l'analyse liée au CPU étant déchargée sur des pools de threads Rayon.
Hiérarchie des modules
Le scanner est organisé en un ensemble de domaines fonctionnels ciblés, chacun ayant une responsabilité unique.
| Domaine | Responsabilité |
|---|---|
| CLI | 10 sous-commandes Clap -- filesystem, domain, agent, network, serve, ci, sourcecode, compliance, servicenow, cbom |
| Core | Structures de données centrales (Finding, ScanResult, RiskAssessment) et moteur de notation des risques quantiques |
| Scanners | Collecteurs de données pour filesystem, domain/TLS, agent, network, code source, KMS cloud, SSH, Fortinet, capture de paquets, sous-domaines |
| Parsers | Analyseurs de format pour PEM, DER, PKCS#12, magasin de certificats Windows (schannel), CBOM CycloneDX |
| Output | Générateurs de rapports -- export JSON, YAML, terminal ANSI, HTML, CBOM CycloneDX 1.7 |
| Server | Serveur web Axum 0.7 avec API REST, prise en charge des WebSocket et authentification (OIDC / clé API) |
| Compliance | 8+ cadres de conformité, analyse d'écarts et génération de rapports (HTML/PDF/JSON) |
| Integrations | API REST ServiceNow avec auto-incidents et synchronisation CMDB ; intégration JFrog Artifactory |
| Configuration | Modes d'authentification, CORS, limitation de débit et validation des entrées |
| Entrypoint | Point d'entrée asynchrone Tokio, initialisation du tracing, distribution CLI |
Commandes CLI
La CLI est construite avec les macros derive de Clap 4.5. Chaque sous-commande correspond à un scanner ou un service dédié.
| Commande | Description |
|---|---|
| filesystem | Analyse les chemins locaux à la recherche de certificats et de keystores (PEM, DER, PKCS#12, JKS) |
| domain | Se connecte aux points d'accès TLS via Rustls et inspecte les handshakes, les suites de chiffrement et les certificats |
| agent | Inventaire cryptographique à l'échelle du système -- certificats, keystores, clés SSH, KMS cloud |
| network | Capture réseau passive du trafic cryptographique (pas encore implémentée) |
| serve | Démarre le serveur web Axum exposant les points d'accès API REST et WebSocket |
| ci | Mode pipeline CI/CD avec sortie SARIF pour GitHub Actions, GitLab CI et Azure DevOps |
| sourcecode | Analyse statique avec plus de 150 règles de détection sur 8 langages de programmation |
| compliance | Exécute des contrôles de conformité selon 8+ cadres réglementaires et génère une analyse d'écarts |
| servicenow | Envoie les découvertes vers ServiceNow -- crée automatiquement des incidents et synchronise avec la CMDB |
| cbom | Analyse ou génère une nomenclature cryptographique (CBOM) CycloneDX 1.7 |
Structures de données centrales
Tous les résultats de scan partagent le même modèle de données. Cela garantit une sortie cohérente, quel que soit le scanner ayant produit les données.
Un Finding représente un actif cryptographique unique découvert lors d'un scan.
| Champ | Type | Description |
|---|---|---|
| id | String | Identifiant unique de la découverte |
| finding_type | Enum | Certificate, Keystore, Key, ConfigFile ou SshKey |
| source | String | Quel scanner a produit cette découverte |
| location | String | Chemin de fichier, URL ou nom d'hôte où l'actif a été trouvé |
| certificate | Option<CertificateInfo> | Métadonnées de certificat analysées (sujet, émetteur, algorithme, taille de clé, validité) |
| keystore | Option<KeystoreInfo> | Format du keystore et entrées contenues |
| risk_assessment | RiskAssessment | Notation de la vulnérabilité quantique et recommandations |
| tls_info | Option<TlsInfo> | Version du protocole TLS, suite de chiffrement et détails du handshake |
Chaque découverte est notée pour sa vulnérabilité quantique par le moteur de notation des risques.
| Champ | Type | Description |
|---|---|---|
| quantum_vulnerable | bool | Indique si l'actif utilise des algorithmes cassables par des ordinateurs quantiques |
| quantum_risk_score | f64 (0-10) | 0 = aucun risque (PQC pur), 10 = risque maximal (RSA-1024, DSA-1024) |
| severity | Enum | Critical, High, Medium, Low ou Info |
| priority | Enum | P0 (immédiat), P1 (urgent), P2 (planifié), P3 (surveiller), P4 (informatif) |
| reasons | Vec<String> | Explications lisibles par un humain du score attribué |
| recommendations | Vec<String> | Étapes concrètes pour remédier à la vulnérabilité |
Les scores de risque correspondent aux priorités : P0 (score 9-10, par exemple RSA-1024, signatures MD5), P1 (7-8, par exemple RSA-2048, SHA-1), P2 (5-6, par exemple RSA-3072), P3 (2-4, par exemple RSA-4096, ECDSA P-384), P4 (0-1, par exemple algorithmes hybrides ou PQC purs).
La structure de sortie de plus haut niveau renvoyée par chaque opération de scan.
| Champ | Type | Description |
|---|---|---|
| scan_metadata | ScanMetadata | Version du scanner, mode de scan, date, nom d'hôte, durée en secondes |
| findings | Vec<Finding> | Tous les actifs cryptographiques découverts pendant le scan |
| summary | ScanSummary | Décomptes agrégés par sévérité, type de découverte et algorithme |
| recommendations | Vec<String> | Recommandations de remédiation de haut niveau basées sur toutes les découvertes |
Modules de scan
Chaque scanner est un composant autonome qui collecte des données cryptographiques brutes à partir d'une source spécifique. Les scanners sont asynchrones (tokio) et utilisent rayon pour le parcours parallèle de fichiers, le cas échéant.
Parcourt récursivement les répertoires à l'aide de la crate walkdir, détectant les fichiers de certificats et de keystores par extension et octets magiques. Prend en charge les formats PEM, DER, PKCS#12 et JKS. Les fichiers sont traités par l'analyseur de format correspondant.
Stratégie de détection :
- Correspondance par extension de fichier (
.pem,.crt,.cer,.der,.p12,.pfx,.jks,.key) - Détection par signature d'octets magiques pour les formats binaires
- Profondeur de répertoire et motifs d'exclusion configurables
- E/S de fichiers parallèles via un pool de threads Rayon
Se connecte aux points d'accès TLS à l'aide d'un client basé sur rustls 0.23. Capture l'intégralité du handshake TLS, y compris la version du protocole, la négociation des suites de chiffrement, la chaîne de certificats du serveur et les paramètres d'échange de clés. Prend en charge l'énumération des sous-domaines via l'intégration de l'API WhoisXML.
Réalise un inventaire cryptographique à l'échelle du système en combinant les résultats de plusieurs sous-scanners : certificats du système de fichiers, magasin de certificats Windows (via la crate schannel), clés d'hôte SSH et métadonnées de KMS cloud (pour AWS KMS, Azure Key Vault et GCP Cloud KMS).
Moteur d'analyse statique doté de plus de 150 règles de détection couvrant 8 langages de programmation. Il parcourt les arborescences de code source et applique une correspondance de motifs basée sur les expressions régulières pour détecter les appels de fonctions cryptographiques vulnérables (par exemple, RSA_generate_key, ECDSA_sign, clés codées en dur).
Capacités :
- Définitions de motifs de détection (algorithme, nom de fonction, sévérité)
- Moteur de parcours de fichiers et de correspondance de règles
- Format de sortie SARIF pour l'intégration CI/CD
- Connecteurs pour les dépôts GitHub, GitLab et Azure DevOps
Couche d'analyse
Les analyseurs convertissent les données binaires ou textuelles brutes en objets structurés CertificateInfo et KeystoreInfo. Ils sont appelés par les scanners et sont spécifiques à chaque format.
| Analyseur | Crate | Formats pris en charge |
|---|---|---|
| PEM | x509-parser | Certificats, clés privées et CSR encodés en Base64 |
| DER | x509-parser | Certificats X.509 encodés en binaire (.der, .cer) |
| PKCS#12 | x509-parser | Ensembles certificat/clé protégés par mot de passe (.p12, .pfx) |
| Magasin de certificats Windows | schannel | Magasins de certificats LocalMachine et CurrentUser sous Windows |
| CBOM | serde | Nomenclature cryptographique CycloneDX (entrée JSON) |
Moteur de notation des risques
Le moteur de notation des risques évalue chaque découverte sur une échelle de vulnérabilité quantique de 0 à 10. La notation tient compte de la famille d'algorithmes, de la taille de clé, du schéma de signature et de facteurs contextuels.
| Plage de score | Priorité | Sévérité | Exemples d'algorithmes |
|---|---|---|---|
| 9 - 10 | P0 (Immédiat) | Critique | RSA-1024, DSA-1024, signatures MD5, DES, 3DES |
| 7 - 8 | P1 (Urgent) | Élevé | RSA-2048, ECDSA P-256, signatures SHA-1 |
| 5 - 6 | P2 (Planifié) | Moyen | RSA-3072, Diffie-Hellman 2048 bits |
| 2 - 4 | P3 (Surveiller) | Faible | RSA-4096, ECDSA P-384, ECDSA P-521 |
| 0 - 1 | P4 (Informatif) | Info | ML-KEM, ML-DSA, SLH-DSA, algorithmes PQC hybrides |
Formateurs de sortie
Le scanner fournit cinq backends de sortie. L'indicateur CLI --format sélectionne le formateur qui rend le ScanResult.
| Format | Cas d'usage |
|---|---|
| JSON | Sortie lisible par machine pour les pipelines, les API et les intégrations |
| YAML | Sortie structurée lisible par un humain pour la gestion de configuration |
| Terminal (ANSI) | Sortie console à code couleur avec mise en évidence de la sévérité pour un usage interactif |
| HTML | Rapports HTML autonomes à partager avec les parties prenantes |
| CBOM CycloneDX | Export de nomenclature cryptographique CycloneDX 1.7 |
Le mode CI (commande ci) produit une sortie SARIF, distincte des formateurs de sortie standard. SARIF s'intègre directement à GitHub Code Scanning, GitLab SAST et Azure DevOps.
Serveur web Axum
La commande serve démarre un serveur web Axum 0.7.
- API REST -- Points d'accès pour déclencher des scans, récupérer des résultats et gérer la configuration
- WebSocket -- Diffusion en temps réel de la progression du scan vers les clients connectés
- Authentification -- Modes OIDC et clé API
- CORS -- Politique cross-origin configurable pour les tableaux de bord dans le navigateur
- Limitation de débit -- Limitation des requêtes pour prévenir les abus
Moteur de conformité
Le moteur de conformité évalue les découvertes de scan selon 8+ cadres réglementaires et industriels.
| Composant | Objectif |
|---|---|
| Checker | Évalue les découvertes selon les règles spécifiques à chaque cadre |
| Frameworks | Définitions des cadres -- NIST, BSI TR-02102, CNSA 2.0, PCI DSS, FIPS 140-3, ETSI, ISO 27001, SOC 2 |
| Gap Analyzer | Identifie les écarts entre la posture actuelle et l'état de conformité cible |
| Report Generator | Produit des rapports de conformité aux formats HTML, PDF et JSON |
| PDF Parser | Extrait les exigences des PDF de politiques organisationnelles personnalisées |
Intégrations
Envoie les découvertes de scan vers ServiceNow via l'API REST. Prend en charge la création automatique d'incidents pour les découvertes P0/P1, la synchronisation CMDB pour les actifs cryptographiques découverts et les flux de synchronisation planifiés. La commande CLI servicenow déclenche un cycle complet de scan et d'envoi.
Capacités :
- Intégration à l'API REST pour l'envoi des données de vulnérabilité
- Création automatique d'incidents en fonction de seuils de sévérité
- Synchronisation CMDB pour l'inventaire des actifs cryptographiques
- Fréquence de synchronisation configurable (continue, planifiée, à la demande)
Le tableau de bord ServiceNow affiche les actifs vulnérables au quantique par sévérité, l'état de conformité et l'avancement de la remédiation.
Dépendances clés
| Crate | Version | Objectif |
|---|---|---|
| tokio | 1.x | Runtime asynchrone pour les opérations d'E/S concurrentes |
| clap | 4.5 | Analyse des arguments CLI avec macros derive |
| serde / serde_json / serde_yaml | 1.x | Sérialisation et désérialisation pour JSON, YAML et fichiers de configuration |
| rustls | 0.23 | Implémentation client TLS pour le scan de domaine (aucune dépendance à OpenSSL) |
| x509-parser | 0.16+ | Analyse des certificats X.509 et des CRL |
| walkdir | 2.x | Parcours récursif de répertoires pour le scan du système de fichiers |
| rayon | 1.x | Traitement parallèle des données lié au CPU (analyse de fichiers, correspondance de règles) |
| reqwest | 0.12+ | Client HTTP pour les API KMS cloud, ServiceNow et les intégrations de fournisseurs git |
| axum | 0.7 | Framework web asynchrone pour la commande serve (REST + WebSocket) |
| tracing | 0.1 | Journalisation structurée et diagnostics |
| schannel | 0.1 | Accès au magasin de certificats Windows via l'API SChannel |
Le scanner n'a aucune dépendance à OpenSSL. Les opérations TLS utilisent rustls, et l'analyse des certificats utilise x509-parser. Cela élimine toute une classe de vulnérabilités de la chaîne d'approvisionnement et simplifie les compilations multiplateformes.
Principes d'architecture
Binaire unique
Livré sous la forme d'un exécutable natif unique par plateforme. Aucune dépendance d'exécution, ni JVM, ni interpréteur Python. Il suffit de copier et d'exécuter.
Asynchrone d'abord
Toutes les E/S réseau utilisent l'asynchrone Tokio. Le travail lié au CPU (analyse de fichiers, correspondance de règles) est déchargé sur des pools de threads Rayon pour un débit maximal.
Zéro OpenSSL
TLS pur Rust via Rustls et x509-parser. Aucune dépendance à une bibliothèque C pour les opérations cryptographiques.
Scanners modulaires
Chaque commande de scan est un module indépendant. De nouveaux scanners peuvent être ajoutés sans modifier le code existant.