®Sécurité offensive / Tests d'intrusion infrastructure et IaaS
Une infrastructure peut être composée de systèmes individuellement bien gérés et pourtant permettre des chemins d'accès indésirables. OTOKO® contrôle, dans le périmètre autorisé, l'infrastructure externe et interne ainsi que les environnements IaaS relevant de la responsabilité du client. Les identités, la configuration et les limites réseau sont examinées conjointement afin que les observations techniques se traduisent en risques évaluables et en mesures concrètes.
Nos services en détail
Analyse, intégration et transfert documenté
Ce que vous confiez à OTOKO®
Les lots de travail sont dérivés de votre situation de départ. Votre équipe connaît le périmètre convenu, la contribution nécessaire et les résultats attendus lors du transfert.
Les adresses, systèmes, comptes et points de départ autorisés sont définis. Les dépendances de production et les composants exclus font partie de l'autorisation. Le test ne commence qu'une fois établie une compréhension commune du périmètre autorisé.
Périmètre documenté et règles d'intervention convenues.
Le contrôle examine quelles actions sont réellement possibles à partir du point de départ convenu. Les identités et les limites réseau sont évaluées dans leur contexte. Les preuves se limitent au périmètre autorisé et à ce qui est nécessaire à l'évaluation.
Constats étayés sur les systèmes et autorisations atteignables.
Les comptes cloud, les systèmes virtuels et les accès relevant de la responsabilité du client sont contrôlés par rapport à l'objectif convenu. Les exigences de l'exploitant de la plateforme et les droits sur les systèmes tiers concernés doivent être clarifiés au préalable.
Évaluation contextuelle de la configuration cloud examinée.
Les résultats techniques sont traduits en améliorations compréhensibles. Les responsabilités et les dépendances sont prises en compte dans la priorisation. Un retest examine les modifications convenues sur la version mise à jour.
Vue d'ensemble des mesures et vérification documentée.
Planification et mise en œuvre
Un test réalisé depuis Internet ne répond pas aux mêmes questions qu'un contrôle effectué avec un compte interne standard. Nous déterminons ensemble le scénario à examiner et les autorisations en place au départ. Le périmètre autorisé est déduit de cette situation de départ. Les systèmes, adresses et identités sont documentés ; les services partagés et les systèmes tiers nécessitent une attention particulière. La planification évite ainsi que l'investigation ne dépasse involontairement une autorisation accordée du fait de responsabilités imprécises.
Les conditions d'exploitation font également partie de la préparation. Les interlocuteurs, les plages horaires et les critères d'interruption sont définis. Les modifications de systèmes, les tests de charge ou toute mesure allant plus loin ne font pas tacitement partie de chaque pentest. Ils doivent correspondre explicitement à la procédure convenue. Les résultats indiquent ensuite la position de départ réelle et la version contrôlée. Cela facilite l'interprétation : une vulnérabilité observée avec des droits administratifs déjà détenus n'a pas la même portée qu'une preuve obtenue depuis un point de départ non privilégié.
La segmentation réseau ne décrit pas à elle seule toutes les possibilités d'accès. Les comptes utilisateurs, les comptes de service et les voies d'administration peuvent établir d'autres connexions entre systèmes. Le contrôle examine donc, dans le cadre autorisé, si les limites techniques et les rôles font réellement respecter le modèle prévu. Les erreurs de configuration isolées sont évaluées au regard de leur impact. Un constat doit montrer pourquoi il est pertinent pour votre environnement et quelles conditions préalables l'accès démontré suppose.
Dans les environnements IaaS, il faut en outre tracer la limite avec le fournisseur. Les ressources et la configuration relevant de la responsabilité du client peuvent faire l'objet de l'examen ; les services de plateforme partagés ne sont pas pour autant automatiquement autorisés. Les droits nécessaires et les exigences sont clarifiés avant le contrôle. Des sites et applications connectés peuvent également être concernés. La planification associe donc les responsables cloud et infrastructure, afin que le test reste transparent et que ses effets puissent être maîtrisés dans le cadre convenu.
Le résultat distingue les constats confirmés, les remarques et les domaines non contrôlés. Les preuves décrivent les conditions requises et l'impact observé. Elles doivent permettre l'évaluation sans collecter inutilement de données sensibles. La direction et les équipes techniques reçoivent une présentation adaptée ; les observations particulièrement pertinentes sont transmises par les circuits de notification convenus. Le pentest devient ainsi plus qu'un simple export de signalements techniques : les responsables peuvent décider quelles mesures mettre en œuvre en priorité.
Plusieurs équipes peuvent être impliquées dans la correction, par exemple la gestion des identités, l'exploitation réseau et la maintenance applicative. Les recommandations sont donc discutées avec leurs dépendances. Le retest se concentre sur la version modifiée convenue et documente si la démonstration concrète reste possible. Une rémunération liée au résultat peut être définie via Result as a Service pour un objectif adapté et clairement défini. Le périmètre de test autorisé reste alors impératif et n'est pas étendu par une incitation économique.
Scénario de projet illustratif
Une entreprise connecte des systèmes internes à un environnement IaaS. Dans le périmètre autorisé, les chemins d'accès nécessaires et indésirables depuis des rôles définis sont contrôlés. Les résultats sont priorisés conjointement avec les responsables réseau et cloud, puis vérifiés de manière ciblée après les modifications.
Avant de démarrer
L'approche adaptée est définie en fonction du besoin de protection et du risque d'exploitation. Les plages horaires, les méthodes autorisées, les interlocuteurs et les critères d'interruption sont convenus par écrit au préalable.
Non. Les droits sur les systèmes tiers et les exigences de l'exploitant de la plateforme doivent être clarifiés séparément. Seul le périmètre explicitement autorisé est contrôlé.
Non. Ces procédures nécessitent un accord explicite et une préparation adaptée. Elles ne découlent pas du seul terme « pentest ».
Un rapport comprenant le périmètre, les constats confirmés, les preuves, les impacts, les limitations et les mesures priorisées. Un retest convenu évalue les corrections concrètes.
Services complémentaires
Tests d'intrusion infrastructure et IaaS avec OTOKO®
Indiquez les systèmes concernés et l'objectif de votre demande. Lors du premier entretien, nous délimitons ensemble le périmètre, les conditions préalables et les prochaines étapes.
Discuter de Tests d'intrusion infrastructure et IaaS
