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

Nos politiques de sécurité s'appuient sur le OWASP Top 10 for NHIs, un cadre complet qui met en évidence les risques de sécurité les plus critiques qu'ils posent.

Nous prenons en charge les politiques suivantes :

• Publicly Leaked Secrets : ce sont des secrets qui ont été exposés publiquement. GitGuardian les identifie grâce à deux signaux : les incidents ouverts issus de nos services de surveillance publique (avec Public Monitoring) et les correspondances avec les fuites publiques connues de HasMySecretLeaked (pour tous les workspaces). Les correspondances HasMySecretLeaked trouvées dans plus de 10 emplacements publics sont considérées comme des valeurs courantes et ignorées. Une telle exposition peut permettre à des parties non autorisées d'accéder à des systèmes sensibles, ce qui représente des menaces de sécurité importantes.
• Internally Leaked Secrets : les secrets qui ont été exposés par inadvertance dans votre périmètre interne peuvent être détectés grâce à nos services de surveillance privée. Ces fuites internes peuvent être tout aussi nuisibles que les fuites publiques, en particulier si les défenses internes sont compromises.
• Cross-Environment Secrets : un secret qui se trouve dans plusieurs environnements, comme à la fois en production et en staging, risque d'exposer un accès sensible de niveau production à des environnements moins sécurisés. S'assurer que chaque environnement dispose de secrets distincts aide à maintenir les frontières de sécurité.
• Improper Offboarding : une version antérieure d'un secret, qui n'est plus la valeur actuelle à son emplacement, mais qui est toujours valide et liée à un incident de secret ouvert (triggered ou assigned). Remplacer une valeur fuitée dans un vault ne la révoque pas : l'ancienne version reste utilisable jusqu'à ce que vous la révoquiez et résolviez l'incident.
• Insecure Cloud Deployment Configuration : un secret GitHub Actions ou GitLab CI dont le nom correspond à un identifiant statique de fournisseur cloud, tel que AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AZURE_CLIENT_SECRET, ARM_CLIENT_SECRET ou GOOGLE_APPLICATION_CREDENTIALS. Les clés cloud à longue durée de vie stockées dans les pipelines sont une cible courante. Utilisez OpenID Connect (workload identity federation) afin que les pipelines obtiennent des identifiants cloud à courte durée de vie à la place.
• Reused Secrets : lorsqu'un secret est utilisé par plusieurs entités, cela augmente le risque de compromission. Si une entité est compromise, les autres utilisant le même secret peuvent également être menacées. 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 emplacements peut compliquer la gestion et augmenter le risque d'utiliser des identifiants obsolètes ou non révoqués. Il est crucial de maintenir une source unique de vérité pour gérer les secrets efficacement.
• 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 à une mauvaise utilisation. Mettre régulièrement à jour ces secrets aide à minimiser le risque d'exposition prolongée à des menaces potentielles.
• Overprivileged Identity : une identité qui détient des permissions larges ou avec des jokers (wildcard) au lieu de permissions limitées à sa tâche. Les NHIs surprivilégiées élargissent le rayon d'impact si leur secret est compromis, donc réduire les droits au strict minimum (least privilege) est essentiel pour diminuer le risque. L'évaluation est disponible pour les identités AWS IAM, Microsoft Entra et Okta. Consultez Détecter les identités surprivilégiées pour les critères exacts.

Dans les détails de l'inventaire, sélectionner une politique enfreinte mettra visuellement en évidence les emplacements des problèmes sur la carte d'exploration.

Identifier les identités admin

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

La détection admin est disponible pour :

• AWS IAM : les principals attachés à AdministratorAccess ou IAMFullAccess, ou détenant des politiques personnalisées qui autorisent *, iam:* ou organizations:* sur toutes les ressources.
• Microsoft Entra : les principals avec des rôles d'annuaire à fort impact (par exemple Global Administrator, Privileged Role Administrator, Application Administrator), des rôles Azure RBAC équivalents à admin (Owner, User Access Administrator, Role Based Access Control Administrator), ou des permissions Microsoft Graph de niveau 1 (par exemple RoleManagement.ReadWrite.Directory).
• Okta : les principals avec des rôles admin intégrés (Super, Org, App, Group, User, API Access Management Admin) ou des rôles personnalisés accordant des permissions équivalentes à admin.

Utilisez ce signal pour concentrer la remédiation sur les identités ayant le plus grand rayon d'impact, indépendamment du fait qu'elles enfreignent actuellement une politique ou non.

Détecter les identités surprivilégiées

La politique Overprivileged Identity analyse les permissions accordées à chaque identité, telles que synchronisées depuis vos intégrations AWS IAM, Microsoft Entra et Okta. Elle ne compare pas ces autorisations avec les actions que l'identité effectue : elle signale les permissions qui sont larges par nature, quelle que soit l'utilisation que l'identité en fait.

L'analyse inclut les permissions héritées des groupes auxquels l'identité appartient. Un secret (clé d'accès, client secret, token d'API) hérite du résultat de l'identité qui le possède.

Une identité enfreint la politique lorsqu'elle détient l'un des éléments suivants :

• AWS IAM :

  • Une politique gérée admin : AdministratorAccess ou IAMFullAccess.
  • Une politique gérée par AWS de type FullAccess, telle que AmazonS3FullAccess ou AWSLambda_FullAccess.
  • Une politique personnalisée ou inline avec une instruction Allow sur l'action joker complète (*) ou une action joker de service (telle que s3:* ou ec2:*), sur n'importe quelle ressource. Les instructions avec un bloc Condition n'enfreignent pas la politique, car elle n'évalue pas les conditions.

• Microsoft Entra :

  • Un rôle d'annuaire admin : Global Administrator, Privileged Role Administrator, Privileged Authentication Administrator, Application Administrator, Cloud Application Administrator, Hybrid Identity Administrator, Domain Name Administrator ou Partner Tier2 Support.
  • Un rôle Azure RBAC équivalent à admin (Owner, User Access Administrator, Role Based Access Control Administrator) ou qui autorise toutes les actions (*), tel que Contributor.
  • Une permission d'application Microsoft Graph à privilèges élevés. Cela inclut les permissions de niveau 1 utilisées pour la détection admin et les permissions d'écriture avec un large rayon d'impact, telles que Directory.ReadWrite.All, User.ReadWrite.All, Group.ReadWrite.All, Mail.Send, Files.ReadWrite.All ou Sites.ReadWrite.All. Les permissions déléguées n'enfreignent pas la politique.

• Okta, lorsque l'octroi s'applique à l'ensemble de l'organisation :

  • Un rôle admin intégré : Super, Org, App, Group, User ou API Access Management Admin.
  • Un rôle personnalisé ou une portée OAuth qui inclut une permission composite : okta.users.manage, okta.users.lifecycle.manage, okta.users.credentials.manage, okta.users.apitokens.manage, okta.groups.manage, okta.apps.manage, okta.devices.manage ou okta.devices.lifecycle.manage.

  Les rôles limités à des groupes, applications ou un ensemble de ressources spécifiques n'enfreignent pas la politique. Les permissions granulaires telles que okta.users.create ne l'enfreignent pas non plus.

La plupart des identités admin enfreignent également cette politique. Les deux signaux répondent à des questions différentes : le badge admin marque les identités qui peuvent prendre le contrôle du compte, du tenant ou de l'organisation, et la politique marque les identités avec des octrois plus larges que ce qu'une tâche limitée requiert.

Criticité du risque

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

1. Gravité de base issue de la violation de politique active la plus risquée sur l'identité. Par exemple, un secret fuité publiquement est évalué critical, une fuite interne est évaluée high, une identité surprivilégiée est évaluée medium, un secret à longue durée de vie est évalué low.
2. Modificateurs qui augmentent le score de +1 niveau chacun, plafonné à critical :
   • Identité admin : toute violation sur une NHI admin est d'un niveau plus grave.
   • Cross-environment avec production : une violation cross-environment qui touche l'environnement de production est d'un niveau plus grave.

Cela signifie qu'un secret fuité sur une identité admin est présenté comme 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 d'abord sur les NHIs où un attaquant ferait le plus de dégâts.

Notez que de nouvelles politiques seront prises en charge prochainement.