Évaluer et améliorer votre posture de sécurité NHI

Nos politiques de sécurité s'inspirent de l'OWASP Top 10 pour les NHIs, un cadre complet qui met en avant les risques de sécurité les plus critiques liés aux NHIs.

Nous prenons en charge les politiques suivantes :

• Publicly Leaked Secrets : ce sont des secrets exposés publiquement, identifiés via nos services de monitoring public. Cette exposition peut permettre à des tiers non autorisés d'accéder à des systèmes sensibles, ce qui constitue une menace de sécurité importante.
• Internally Leaked Secrets : les secrets exposés par inadvertance au sein de votre périmètre interne peuvent être détectés via nos services de monitoring privé. Ces fuites internes peuvent être tout aussi préjudiciables que les fuites publiques, en particulier si vos défenses internes sont franchies.
• Cross-Environment Secrets : un secret présent dans plusieurs environnements, par exemple à la fois en production et en staging, peut exposer un accès sensible de niveau production à des environnements moins sécurisés. Veiller à ce que chaque environnement dispose de secrets distincts permet de maintenir des frontières de sécurité claires.
• Reused Secrets : lorsqu'un secret est utilisé par plusieurs entités, le risque de compromission augmente. Si une entité est compromise, les autres qui utilisent le même secret peuvent l'être aussi. Garantir des secrets uniques pour chaque cas d'usage réduit ce risque.
• Duplicated Secrets : avoir le même secret stocké dans plusieurs vaults ou chemins peut compliquer la gestion et augmenter le risque d'utiliser des identifiants obsolètes ou non révoqués. Maintenir une source unique de vérité est essentiel pour une gestion efficace des secrets.
• Long-Lived Secrets : les secrets qui existent au-delà d'une durée de vie donnée (par défaut un an) sans renouvellement sont vulnérables aux usages malveillants. Mettre à jour régulièrement ces secrets aide à minimiser le risque d'exposition prolongée.
• Overprivileged Identity : une identité qui s'est vu accorder des permissions plus larges que ce dont elle a réellement besoin. Les NHIs surdimensionnées en privilèges élargissent le blast radius en cas de compromission de leur secret ; ramener leurs droits au moindre privilège est essentiel pour réduire le risque. L'évaluation est disponible pour les identités AWS IAM, Microsoft Entra et Okta.

Dans le détail de l'inventaire, sélectionner une policy non respectée fait apparaître visuellement les emplacements concernés sur la carte d'exploration.

Identifier les identités admin

En plus des violations de policies, GitGuardian signale les identités disposant de permissions de niveau admin sur votre infrastructure ou votre fournisseur d'identité. Les NHIs admin sont mises en évidence dans l'inventaire avec un badge Identity level: Admin et peuvent être isolées via le filtre dédié Identity level (Admin / Non-admin).

La détection des admins est disponible pour :

• AWS IAM : principals attachés à AdministratorAccess ou IAMFullAccess, ou portant des policies personnalisées avec actions wildcard sur IAM ou AWS Organizations.
• Microsoft Entra : principals avec des rôles d'annuaire à fort impact (par ex. Global Administrator, Privileged Role Administrator, Application Administrator), des rôles Azure RBAC équivalents admin (Owner, User Access Administrator), ou des permissions Microsoft Graph de tier 1 (par ex. RoleManagement.ReadWrite.Directory).
• Okta : principals avec des rôles admin natifs (Super, Org, App, Group, User, API Access Management Admin) ou des rôles personnalisés conférant des permissions équivalentes admin.

Utilisez ce signal pour concentrer la remédiation sur les identités au plus grand blast radius, indépendamment du fait qu'elles violent ou non une policy.

Criticité du risque

Chaque NHI de l'inventaire se voit attribuer un niveau de Risk criticality (low, medium, high, critical) calculé à partir de deux couches :

1. Sévérité de base issue de la policy active la plus risquée violée par l'identité. Par exemple, un secret divulgué publiquement est noté critical, un divulgué en interne est noté high, surdimensionné en privilèges est noté medium, à longue durée de vie est noté low.
2. Modificateurs qui rehaussent le score de +1 niveau chacun, plafonnés à critical :
   • Identité admin : toute violation sur une NHI admin est d'un niveau plus sévère.
   • Cross-environment avec la production : une violation cross-environment qui touche l'environnement de production est d'un niveau plus sévère.

Cela signifie qu'un secret divulgué sur une identité admin est remonté en critical même si la fuite elle-même est interne, ce qui vous permet de trier l'inventaire par risque et de vous concentrer en priorité sur les NHIs où un attaquant ferait le plus de dégâts.

À noter que de nouvelles policies seront prises en charge prochainement.