IREX - Tests de sécurité à réaliser sur la plateforme ACRA : Démarche de tests

Démarche de tests de sécurité sur la plateforme ACRA

1. Introduction



Un test de sécurité n’a de valeur que s’il est autorisé, reproductible et documenté.
Cet article décrit la démarche suivie pour tester la plateforme ACRA : les règles à respecter, les étapes, le périmètre et la manière de consigner les résultats.


Il fait suite à l’article sur les référentiels, qui explique par rapport à quoi ACRA est évaluée.
Il précède l’article sur les outils, puis les deux articles qui détaillent les tests eux-mêmes.


2. Principes de la démarche



Quatre principes encadrent tous les tests.


Autorisation et périmètre. Aucun test ne commence sans accord écrit. Le périmètre et les règles d’engagement sont fixés avant le premier test.


Environnement. Les tests sont réalisés en préproduction, après une sauvegarde, et sont non destructifs.


Comptes de test. Un compte par profil utilisateur : profane, administrateur système, administrateur sécurité et administrateur réseau. Le risque principal d’ACRA est qu’un profil accède aux fonctions d’un autre.


Traçabilité. Chaque test est relié à une exigence d’un référentiel, à une catégorie du NIST CSF 2.0 et à une preuve.


3. Le cycle de test en quatre phases



Le cycle suit les quatre phases du guide NIST SP 800-115 : planification, découverte, attaque et rapport.


Cycle de test en quatre phases

Phase	Ce que l’on fait	Application à ACRA	Résultat
1. Planification	Fixer les règles et les objectifs avant tout test	Recenser les composants, définir le périmètre, créer les comptes de test	Fiche de cadrage validée
2. Découverte	Identifier ce qui peut être testé	Relever les ports, les services, les interfaces et les configurations	Liste des cibles et des interfaces exposées
3. Attaque	Vérifier si les faiblesses sont réellement exploitables	Tester chaque exigence, puis enchaîner des scénarios	Constats vérifiés, avec preuves
4. Rapport	Consigner et recommander	Se fait tout au long des trois autres phases	Rapports de vulnérabilités et de conformité




Ce cycle n’est pas strictement linéaire.
Si l’attaque révèle une nouvelle cible, on revient à la découverte.
Le rapport, lui, s’écrit au fil des tests plutôt qu’à la fin.


4. Cadrage et périmètre


1. Recenser les composants



ACRA repose sur un serveur d’applications sous Debian, qui héberge Nginx, Grafana, Prometheus, Zabbix, Thanos et SeaweedFS.
Keycloak fonctionne comme fournisseur d’identité interne, en dehors de ce serveur. Jenkins, sur un serveur d’automatisation, déploie les composants.
Chaque service est précédé de son propre Nginx interne.


2. Identifier les interfaces



Les utilisateurs accèdent à ACRA en HTTPS (port 4443) par le Nginx frontal.
Celui-ci transmet les requêtes aux services en HTTP : Keycloak (8080), Grafana (8089), Prometheus (9090), Zabbix (8080), Thanos et SeaweedFS (8089).
Chaque profil utilise une interface précise : le profane consulte Grafana, l’administrateur système configure Prometheus, l’administrateur réseau configure Zabbix et l’administrateur sécurité gère les règles et les alertes.


3. Définir le périmètre



Le périmètre indique ce qui est testé


Périmètre des tests

Élément	Décision	Justification
Serveur d’applications, serveur d’automatisation	Dans le périmètre	Ils hébergent tous les composants
Nginx (frontal et internes), Keycloak, Grafana, Prometheus, Zabbix, Thanos, SeaweedFS	Dans le périmètre	Composants déployés
Jenkins et son pipeline	Dans le périmètre	Droits de déploiement sur les composants
Flux HTTP entre composants	Dans le périmètre	Le chiffrement est à vérifier
Quatre profils utilisateurs	Dans le périmètre	Cloisonnement des rôles



5. Points de vue et ordre d’exécution


1. Points de vue de test



Le guide NIST SP 800-115 distingue des points de vue de test : externe ou interne, ouvert ou discret.
Le tableau suivant indique le choix proposé pour ACRA.


Points de vue de test

Point de vue	Signification	Choix pour ACRA (à valider)
Externe	Test depuis l’extérieur du périmètre	Oui : par le Nginx frontal, seul point d’entrée
Interne	Test depuis l’intérieur du réseau	Oui : entre composants, avec un compte de chaque profil
Ouvert	Les équipes techniques sont informées du test	Oui : environnement de préproduction
Discret	Les équipes ne sont pas informées	Non



2. Ordre d’exécution



L’ordre des tests va du plus bas niveau vers le plus haut : une faiblesse sur un serveur change la lecture de tous les tests applicatifs.


Ordre d’exécution

Ordre	Ce que l’on teste	Pourquoi à ce moment
1	Serveurs Debian et serveur d’automatisation	Le socle : une faiblesse ici touche tout le reste
2	Nginx frontal et flux entre composants	Premier contact avec l’extérieur, chiffrement
3	Keycloak	Tous les accès dépendent de l’authentification
4	Grafana, interfaces de Prometheus et de Zabbix	Cloisonnement des profils, injections
5	Collecte de Prometheus et de Zabbix	Configuration et exposition réseau
6	Thanos et SeaweedFS	Accès et intégrité de l’historique
7	Jenkins et pipeline	Secrets, droits, modification du pipeline
8	Scénarios combinés	Ils enchaînent les faiblesses trouvées avant



6. Consigner un test



Chaque test est consigné avec six champs : la référence dans le référentiel, le contrôle, la description, les vérifications à effectuer, le moyen de vérification et la preuve.
Le résultat est l’un des quatre suivants : conforme, non conforme, partiellement conforme ou non applicable.


Exemple suivi de bout en bout : les flux entre composants.
Planification. Les flux HTTP du Nginx frontal vers les services sont dans le périmètre. Le test retenu est l’exigence V12.3.3 de l’ASVS 5.0 (niveau 2) : le chiffrement de transport entre services internes.
Découverte. On relève les ports en écoute sur le serveur d’applications, pour confirmer sur quel port répond chaque service.
Attaque. On capture, en préproduction, le trafic entre le Nginx frontal et un service, puis on regarde si le contenu est lisible.
Rapport. On consigne le résultat, la capture comme preuve et la correction recommandée : activer TLS entre les composants, selon le guide ANSSI.


Le résultat n’est pas connu à l’avance : le schéma de déploiement montre ces flux en HTTP, et le test doit le confirmer ou l’infirmer.

Sources consultées du 03-10-2026 au 13-10-2026 : NIST SP 800-115 ; OWASP ASVS 5.0.0 (fichier officiel) ; NIST CSF 2.0 ; guide ANSSI Recommandations de sécurité relatives à TLS (v1.2).