L'entrée en vigueur de la directive européenne NIS 2 (Network and Information Security) marque un tournant historique pour la cybersécurité en Europe. Contrairement à la première mouture qui ne ciblait que les opérateurs d'infrastructures vitales, NIS 2 élargit considérablement son périmètre. Désormais, des milliers de PME, ETI et fournisseurs de services managés (MSSP) entrent dans la catégorie des "Entités Essentielles" ou "Importantes".
Parmi les obligations phares de cette législation figure l'obligation de mettre en œuvre des mesures de gestion des incidents et d'assurer une traçabilité irréprochable de toutes les actions correctives entreprises sur le réseau. Pour les entreprises et leurs prestataires cyber, comprendre comment auditer ces actions n'est plus une option, c'est une contrainte légale sous peine de lourdes sanctions financières.
Les exigences de NIS 2 en matière de gestion des incidents
La directive NIS 2 impose une approche proactive et documentée de la cyberdéfense. Il ne suffit plus de bloquer une attaque en tâche de fond ; vous devez être capable de prouver comment vous l'avez bloquée, quand l'action a été prise, et qui a autorisé cette intervention.
L'article 21 de la directive stipule explicitement que les entités doivent disposer de capacités de réponse aux incidents adaptées et proportionnées aux risques. En cas d'audit par les autorités nationales (comme l'ANSSI en France ou le BSI en Allemagne), l'entreprise doit être en mesure de fournir des journaux d'audit (logs) détaillés de l'infrastructure de supervision. Si votre centre d'opérations de sécurité (SOC) ou votre orchestrateur (SOAR) exécute des commandes d'urgence sans conserver de traces immuables et imputables, votre organisation est en situation de non-conformité.
Le défi de l'imputabilité pour les MSSP et les SOCs internes
Pour un prestataire cyber (MSSP) qui administre les locataires (Tenants) Microsoft Security de dizaines de clients, ou pour une équipe informatique interne gérant un parc d'ETI, le principal piège en matière d'audit est le manque d'imputabilité réelle.
Dans de nombreuses architectures artisanales, les scripts de remédiation ou les outils de billetterie informatique utilisent un compte de service générique unifié (un "compte fantôme") pour appeler les API Microsoft Graph. Lorsqu'une machine est isolée du réseau ou qu'une session utilisateur est révoquée, le journal d'audit natif de Microsoft se contente d'indiquer : "Action exécutée par l'application SOAR-XYZ".
Aux yeux d'un auditeur NIS 2, cette traçabilité est insuffisante. L'outil est incapable de lier l'action technique à l'opérateur humain réel qui était devant son écran et a cliqué sur le bouton. L'imputabilité est rompue.
L'architecture "Compliance by Design" d'Akuity SOC
L'orchestrateur Akuity SOC a été développé en Bavière selon des normes strictes de sécurité et de conformité réglementaire européenne. Son module de gestion des journaux d'audit (centralisé dans le fichier de configuration audit.ts) résout nativement le problème de l'imputabilité exigé par NIS 2.
1. La résolution automatique du contexte
Chaque fois qu'une action de remédiation active est déclenchée sur la plateforme — qu'il s'agisse d'un isolement réseau d'une machine gérée par Intune (ISOLATEDEVICE) ou d'une purge globale d'un e-mail de phishing (SOFTDELETE_EMAIL) — la fonction backend logAudit intercepte la requête. Elle analyse le jeton de session Supabase (sb-access-token) présent dans les cookies de la requête serveur. Le système interroge immédiatement le module Supabase Auth pour extraire l'e-mail exact et l'UUID de l'analyste connecté. L'action est ainsi signée et imputée de manière indéniable à un être humain réel.
2. Le format JSON standardisé SOC 2
Les logs d'audit générés ne sont pas de simples lignes de texte modifiables. Ils sont structurés selon un schéma JSON brut standardisé, écrit directement sur la sortie standard (console.log). Ce payload consigne de manière immuable :
- Un horodatage précis au format ISO UTC (
timestamp). - Le contexte de l'acteur (
actoravec l'email et l'UUID). - L'action spécifique exécutée (
action). - Le périmètre de l'espace de travail (
workspace_id). - Les cibles précises impactées (
targetscomme le nom du PC ou l'UPN de l'utilisateur).
3. Les garanties pour les tâches de fond
Si une action se produit sans jeton de session utilisateur (par exemple, une tâche planifiée automatisée de nettoyage ou un script système), le moteur d'Akuity refuse de laisser la case vide. Il impute automatiquement l'événement à l'acteur institutionnel "System", garantissant qu'aucun angle mort n'existe dans la chronologie des logs.
Conclusion : Transformez la contrainte en bouclier
Se mettre en conformité avec la directive NIS 2 ne doit pas être perçu comme une corvée administrative de plus. En adoptant un orchestrateur souverain qui intègre la traçabilité et l'imputabilité au plus profond de son code, vous protégez vos clients et votre entreprise. Vous disposez d'un journal de bord irréprochable pour vos audits officiels et vous renforcez la confiance de vos partenaires commerciaux.
Mettez vos opérations SOC en conformité avec les exigences européennes. > Découvrez notre plateforme d'Orchestration conforme NIS 2 et SOC 2 et sécurisez vos journaux d'audit dès aujourd'hui.