Vous livrez du logiciel
Vos applications web et vos API changent à chaque sprint. Un test d'intrusion montre lesquels de ces changements ont ouvert un chemin réellement exploitable, avec les étapes pour le reproduire.
Test d'intrusion
Test d'intrusion
Un test d'intrusion est une attaque simulée et autorisée de vos applications, API et réseau qui révèle les failles exploitables avant un vrai attaquant, puis vérifie chaque correctif par un nouveau test.
CloudKey réalise des tests d'intrusion manuels et cadrés sur vos applications web, vos API et vos réseaux externes et internes. Chaque mission débute par des règles d'engagement signées et se termine par des constats reproductibles, priorisés, avec une revérification de chaque correctif.
- Règles d'engagement signées
- Périmètre externe et interne
- Manuel, pas un simple scan
- Revérification incluse
Élevé
Risque agrégé
- Prise de contrôle via contournement d'authentification enchaîné (app.example.com) Critique
- Autorisation au niveau objet cassée sur /api/v1/orders Critique
- Injection SQL dans un ancien point de recherche Élevé
- Panneau d'administration exposé sur un hôte public Élevé
Chaque constat est livré avec étapes de reproduction, preuves et revérification. Illustration uniquement.
Le périmètre en chiffres
Ce que couvre une mission
Aperçu
Un test manuel qui prouve ce qui est réellement exploitable
La plupart des outils de sécurité disent ce qui pourrait être un problème. Un test d'intrusion dit ce qu'un attaquant peut réellement en faire. Les services de test d'intrusion CloudKey opposent un testeur expérimenté à vos systèmes, sous autorisation écrite et contrôlée, avec un seul but : trouver les chemins qu'un vrai attaquant emprunterait, prouver l'impact, et remettre à vos équipes les étapes pour les fermer.
Les scanners automatiques ont leur place, et nous les utilisons pour couvrir la largeur. Mais un scanner ne sait pas enchaîner trois failles moyennes en une prise de contrôle complète, raisonner sur votre logique métier, ni distinguer un faux positif d'un vrai risque. Des personnes le font. Chaque mission CloudKey est menée par un test manuel, le résultat du scanner servant de point de départ, pas de rapport.
Nous testons applications web, API, et réseaux externes et internes, cadrés sur le risque qui vous importe et l'exigence que vous visez. Vous obtenez des constats priorisés avec étapes de reproduction, un résumé pour la direction, et une revérification qui confirme que les correctifs tiennent.
Pour qui
Quand avez-vous besoin d'un test d'intrusion ?
Trois situations nous amènent des équipes. La plupart en cumulent plusieurs.
Vous exploitez un réseau
Le périmètre externe et les segments internes portent tous deux du risque. Le test externe et interne montre ce qu'un attaquant atteint depuis Internet et ce qu'un intrus atteint une fois à l'intérieur.
Un auditeur le demande
SOC 2, PCI DSS, ISO 27001 et NIS2 attendent une preuve de test. Nous livrons un rapport lisible par votre auditeur, rattaché au contrôle qui l'exige.
Périmètre
Que couvrent les services de test d'intrusion CloudKey ?
Choisissez le périmètre qui correspond à votre risque. Nous le testons manuellement, pas avec un scanner automatique seul. Les panneaux sont des illustrations stylisées du type de constats que chaque périmètre révèle.
Test d'intrusion d'application web
Authentification, contrôle d'accès, logique métier, injections et OWASP Top 10, testés à la main sur votre application réelle, pas sur une liste générique.
- OWASP Top 10
- Authentification et contrôle d'accès
- Failles de logique métier
- Contrôle d'accès cassé sur /admin Élevé
- XSS stocké dans le champ biographie Élevé
- Logique métier : cumul abusif de coupons Moyen
- Erreur verbeuse révélant la pile d'appels Faible
Illustration pour example.com, pas un scan réel.
Test d'intrusion d'API
Points d'accès REST et GraphQL vérifiés pour l'autorisation au niveau objet, l'exposition excessive de données et les limites de débit, les failles que les scanners manquent souvent.
- REST et GraphQL
- Autorisation au niveau objet cassée
- Exposition excessive de données
- GET /api/v1/users/{id} BOLA - Élevé
- GET /api/v1/orders Données excessives - Élevé
- POST /api/v1/login Aucune limite - Moyen
- GET /api/v1/health Conforme
Illustration de constats de points d'accès pour example.com.
Test d'intrusion réseau externe
La vue qu'un attaquant a de vos actifs exposés sur Internet. Services exposés, configurations faibles et vulnérabilités en bordure, classés par accessibilité réelle.
- Périmètre et services en bordure
- Exposition sur Internet
- Constats accessibles, classés
- 203.0.113.10:443 https (TLS 1.0 activé) Élevé
- 203.0.113.10:22 ssh (auth par mot de passe) Moyen
- 203.0.113.24:3389 rdp (exposé sur Internet) Élevé
- 203.0.113.24:80 http (redirige vers https) Conforme
Hôtes d'exemple pour example.com. Illustration uniquement.
Test d'intrusion réseau interne
Ce qu'un intrus atteint après une première prise de pied. Déplacement latéral, élévation de privilèges et cloisonnement insuffisant dans votre environnement.
- Déplacement latéral
- Élévation de privilèges
- Cloisonnement insuffisant
- 10.0.2.15 poste de travail (prise de pied initiale) Entrée
- 10.0.2.40 serveur de fichiers (admin local réutilisé) Latéral - Élevé
- 10.0.1.5 contrôleur de domaine (kerberoast) Élévation - Critique
- VLAN utilisateur vers VLAN serveur Sans cloisonnement - Élevé
Illustration d'un chemin d'attaque pour example.com.
Méthodologie
Testé selon des méthodologies reconnues, par des testeurs certifiés
Nous structurons les missions autour des standards que vos auditeurs et vos ingénieurs connaissent déjà, pour un travail reproductible et un rapport défendable. Les testeurs détiennent OSCP et CEH ; les chefs de mission visent CREST CRT et OSWE selon les besoins.
OWASP WSTG
Les tests web et API suivent l'OWASP Web Security Testing Guide et couvrent l'OWASP Top 10 et l'API Security Top 10, la base que la plupart des auditeurs s'attendent à voir citée.
PTES et OSSTMM
La structure de mission suit le Penetration Testing Execution Standard, du cadrage initial à l'exploitation et au rapport, rien n'est improvisé.
NIST SP 800-115
Les tests techniques s'alignent sur le guide technique NIST des tests de sécurité, la référence vers laquelle pointent de nombreux cadres de conformité.
Qualifications des testeurs
Les testeurs principaux détiennent OSCP (Offensive Security Certified Professional) et CEH (Certified Ethical Hacker). Les chefs de mission visent CREST CRT et OSWE pour la profondeur en sécurité applicative, pour un rapport défendable face aux auditeurs qui demandent qui était au clavier.
Déroulé
Comment se déroule un test d'intrusion ?
Faites défiler : chaque phase se révèle à son tour.
Phase 01
Cadrage et règles d'engagement
Nous convenons des cibles, des fenêtres horaires, des contacts d'urgence et des modalités de divulgation, puis les consignons dans des règles d'engagement que vous signez.
- Périmètre convenu signé
- Fenêtres horaires définies
- Contacts d’urgence nommés
Illustratif.
Phase 02
Reconnaissance
Nous cartographions la surface d'attaque du périmètre, les actifs, points d'entrée et technologies, pour cibler les tests qui suivent.
- app.exemple.tld web
- api.exemple.tld API
- vpn.exemple.tld périmètre
Illustratif.
Phase 03
Exploitation
Nous tentons une exploitation réelle et contrôlée des failles trouvées, pour confirmer l'impact plutôt que rapporter un risque théorique.
- $ tentative auth-bypass confirmé
- $ accès obtenu preuve capturée
- $ impact démontré journalisé
Illustration, pas de vraie cible.
Phase 04
Rapport
Vous recevez des constats priorisés avec étapes de reproduction et preuves, un résumé pour la direction et une section technique exploitable par vos équipes.
- Auth bypass · edge Critique
- IDOR · API Élevé
- En-têtes manquants Faible
Illustratif.
Phase 05
Revérification
Une fois les constats corrigés, nous les retestons et délivrons une attestation de ce qui est clos. La revérification est incluse.
- Auth bypass Clos
- IDOR Clos
- Attestation délivrée
Illustratif.
Aller plus loin
Red team et simulation d'attaque
Quand un test d'intrusion standard ne suffit pas, nous menons des missions offensives par objectif qui testent la détection et la réponse, pas seulement les contrôles.
Mission red team
Une mission par objectif, discrète, qui émule un véritable adversaire vers des buts convenus, par exemple atteindre une donnée sensible, pour tester si votre équipe détecte et réagit. Cadrée et autorisée comme toute mission CloudKey.
Simulation d'attaque (BAS)
Simulation reproductible de techniques d'attaquants connues, alignées sur MITRE ATT&CK, pour mesurer la couverture de détection dans le temps plutôt qu'à un instant donné.
Nous ne testons pas avant la signature des règles d'engagement
La reconnaissance et l'exploitation ne commencent qu'après autorisation écrite. Les règles d'engagement définissent le périmètre, les fenêtres horaires, les contacts d'urgence et la divulgation. Sans exception.
- Périmètre et cibles convenus par écrit
- Fenêtres horaires et contacts d'urgence nommés
- Modalités de divulgation fixées avant tout test actif
Cycle de vie d’un constat
D’exploitable à clos, prouvé à chaque étape
Chaque constat suit le même chemin, traçable de bout en bout.
-
Trouvé
Auth bypass · edge-gw
Exploité sous autorisation, impact prouvé.
-
Rapporté
Constat + reproduction
Étapes, preuves et priorité remises à l’équipe.
-
Revérifié
Clos · attestation
Correctif retesté, fermeture attestée.
Ce que vous obtenez
Votre rapport de test d'intrusion, et la preuve que les correctifs tiennent
Des constats exploitables, des preuves qu'un auditeur accepte, et une revérification qui boucle la boucle.
Constats priorisés
Chaque problème classé par exploitabilité réelle et impact métier, pas seulement par score brut, pour corriger d'abord les rares qui comptent.
Reproduction et preuves
Chaque constat porte les étapes pour le reproduire et les preuves recueillies. Un ingénieur l'ouvre et le confirme. Pas de folklore.
Rapport direction et technique
Un résumé que votre direction lit et une section technique sur laquelle vos équipes travaillent, dans un seul document.
Attestation de revérification
Après remédiation, nous retestons et attestons ce qui est clos, l'artefact que votre auditeur et vos clients veulent voir.
Conformité
Test d'intrusion pour SOC 2, PCI DSS, ISO 27001 et NIS2
La plupart des missions sont déclenchées par une exigence. Nous rattachons le rapport au contrôle qui l'impose.
SOC 2
Preuve de test d'intrusion indépendante pour votre audit SOC 2, cadrée sur les systèmes de votre périmètre de confiance.
PCI DSS
Test d'intrusion externe et interne aligné sur l'exigence 11 de PCI DSS, avec les contrôles de cloisonnement attendus.
ISO 27001
Preuve de test qui appuie votre ensemble de contrôles ISO 27001 et alimente le plan de traitement du risque.
NIS2
Test qui appuie les attentes de gestion du risque et de résilience auxquelles les organisations de l'UE font face sous NIS2.
FAQ
Le test d'intrusion, en clair
Un test d'intrusion est une attaque simulée et autorisée de vos applications, API ou réseau. Un testeur tente d'exploiter des failles réelles comme le ferait un attaquant, puis rapporte ce qui a fonctionné, comment le reproduire et comment le corriger.
Un scan de vulnérabilités est automatique et liste des problèmes potentiels. Un test d'intrusion est manuel : un humain confirme lesquels sont réellement exploitables, les enchaîne et prouve l'impact métier. Le scan trouve des candidats, le test prouve lesquels comptent.
Le coût dépend du périmètre : nombre d'applications, d'API et de plages réseau, et test externe, interne ou les deux. Nous cadrons chaque mission et donnons un prix fixe avant tout travail, sans surprise.
Un test ciblé d'application web ou de réseau externe demande en général une à deux semaines de test, plus le cadrage en amont et le rapport en aval. Les périmètres plus larges prennent plus de temps. Nous confirmons le calendrier dans les règles d'engagement.
La boîte noire signifie sans connaissance préalable, comme un attaquant externe. La boîte grise donne un accès limité, par exemple un compte à faibles privilèges. La boîte blanche donne un accès complet au code et aux identifiants. La boîte grise offre souvent la meilleure couverture pour le temps imparti.
Le test externe évalue ce qu'un attaquant atteint depuis Internet contre votre périmètre. Le test interne évalue ce qu'un intrus atteint après une prise de pied dans votre réseau. Beaucoup de missions incluent les deux.
SOC 2 ne nomme pas le test d'intrusion comme ligne dédiée, mais les auditeurs attendent couramment une preuve de test pour appuyer les critères de sécurité. Un rapport de test d'intrusion cadré sur votre périmètre de confiance est la façon habituelle de la fournir.
Oui. CloudKey ne commence ni reconnaissance ni exploitation avant que vous signiez des règles d'engagement définissant périmètre, fenêtres horaires, contacts d'urgence et divulgation. Tester sans autorisation écrite n'est jamais acceptable.
Prochaine étape
Cadrez votre test d'intrusion
Dites-nous ce que vous exploitez et ce qu'un auditeur ou un client demande. Nous revenons avec un périmètre, un calendrier et un prix fixe, puis rien d'actif ne commence avant votre signature.