DORA et Netwrix Identity Manager : gouverner les identités et les habilitations

L'article 21 impose d'attribuer les droits selon les principes du besoin d'en connaître, du besoin d'en disposer et du moindre privilège, y compris pour les accès distants et d'urgence.

Netwrix Identity Manager permet de traduire cette exigence en modèle d'habilitation. Son modèle de rôles associe des droits techniques à des rôles compréhensibles par les utilisateurs non techniques, puis permet de les attribuer manuellement ou automatiquement selon le contexte de l'identité. La documentation Netwrix donne par exemple des règles fondées sur le département, la localisation ou d'autres dimensions organisationnelles.

L'intérêt est de ne plus seulement savoir qu'un utilisateur appartient à tel groupe Active Directory ou possède telle permission applicative. L'organisation peut documenter la règle qui justifie l'accès et distinguer les droits automatiquement liés à une fonction des habilitations sensibles qui nécessitent une décision explicite.

L'article 21 est particulièrement précis sur le maintien des habilitations. Il exige que les responsabilités d'attribution, de revue et de révocation soient définies, que les accès soient retirés sans retard injustifié lorsqu'un emploi prend fin ou qu'ils ne sont plus nécessaires, et fixe une fréquence minimale de réexamen. Les droits doivent être revus au moins une fois par an pour les systèmes TIC ordinaires et au moins tous les six mois pour ceux qui supportent des fonctions critiques ou importantes.

Netwrix Identity Manager répond à ce besoin avec ses campagnes de certification. Une campagne définit une période et un périmètre précis d'habilitations à contrôler. Celui-ci peut être filtré selon une catégorie de rôles, un type d'affectation, la dernière date de certification ou le niveau de risque. Le responsable de la revue peut alors déterminer si chaque habilitation doit être conservée ou supprimée.

La classification DORA peut donc servir directement à construire la politique de certification : les systèmes supportant des fonctions critiques ou importantes entrent dans un cycle semestriel au minimum, tandis que les autres relèvent du cycle annuel. Les droits particulièrement risqués ou les conflits SoD peuvent, eux, être contrôlés plus fréquemment sans attendre l'échéance réglementaire.

L'article 21 couvre également les accès privilégiés, administrateur et d'urgence, qui doivent être accordés sur une base need-to-use ou ad hoc, ainsi que les mécanismes d'authentification adaptés à la criticité et au risque des actifs TIC.

C'est la limite qu'il faut conserver dans l'architecture. Netwrix Identity Manager gouverne pourquoi une identité est éligible à un accès ou à un privilège, mais l'IGA ne remplace pas l'Access Management pour l'authentification forte ni le PAM lorsqu'il faut gérer une élévation temporaire, un compte d'administration, un secret ou une session privilégiée. Les journaux IAM doivent également être complétés par ceux de l'Access Management, du PAM et des applications lorsque l'objectif est de savoir non seulement pourquoi un accès a été accordé, mais ce qui a effectivement été réalisé avec cet accès.

Le cas d'usage n'est finalement pas « installer Netwrix Identity Manager pour être conforme à DORA ». Il consiste à utiliser l'IGA pour transformer certaines obligations précises du règlement en contrôles permanents : gérer le cycle de vie des identités, justifier les habilitations, détecter les combinaisons incompatibles, revoir les droits selon la criticité des systèmes et les retirer lorsqu'ils ne sont plus nécessaires.

La valeur du dispositif vient alors de la continuité entre la règle et son exécution. Pour une habilitation donnée, l'organisation peut retrouver l'identité concernée, la justification du droit, la règle ou la décision qui l'a attribué, son niveau de risque, sa dernière certification et, le cas échéant, sa révocation. C'est cette traçabilité qui fait passer la gestion des accès d'une conformité déclarative à un contrôle DORA démontrable.