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

Nos politiques de sécurité s'inspirent du OWASP Top 10 for NHIs, un cadre complet qui met en évidence les risques de sécurité les plus critiques qu'ils présentent.

Nous prenons en charge les politiques suivantes :

• Publicly Leaked Secrets : il s'agit de secrets qui ont été exposés publiquement. GitGuardian les identifie grâce à deux signaux : les incidents ouverts provenant 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 communes et ignorées. Une telle exposition peut permettre à des parties non autorisées d'accéder à des systèmes sensibles, ce qui constitue des menaces de sécurité importantes.
• Internally Leaked Secrets : les secrets qui ont été exposés par inadvertance au sein de 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 néfastes que les fuites publiques, en particulier si les défenses internes sont compromises.
• Cross-Environment Secrets : un secret que l'on retrouve 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. Veiller à ce que chaque environnement dispose de secrets distincts aide à maintenir les frontières de sécurité. L'environnement de chaque copie est celui déduit par secret, et non uniquement l'env au niveau de la source.
• Improper Offboarding : une version antérieure d'un secret, qui n'est plus la valeur actuelle à son emplacement, qui est toujours valide et liée à un incident de secret ouvert (triggered ou assigned). Remplacer une valeur fuitée dans un coffre 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, comme 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 plutôt OpenID Connect (fédération d'identité de charge de travail) afin que les pipelines obtiennent des identifiants cloud à courte durée de vie.
• 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 mises en danger. Veiller à ce que chaque cas d'usage dispose de secrets uniques réduit ce risque.
• Duplicated Secrets : stocker le même secret dans plusieurs coffres 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 efficacement les 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 abus. 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 caractère générique au lieu de permissions limitées à sa tâche. Les NHI surprivilégiées élargissent le rayon d'impact si leur secret est compromis, c'est pourquoi réduire les droits au principe de moindre privilège 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 connaître 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 infractions aux politiques, GitGuardian signale les identités qui détiennent des permissions de niveau admin sur votre infrastructure ou votre fournisseur d'identité. Les NHI admin sont mises en évidence 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 rattachés à AdministratorAccess ou IAMFullAccess, ou détenant des politiques personnalisées qui autorisent *, iam:* ou organizations:* sur toutes les ressources.
• Microsoft Entra : les principals disposant de rôles d'annuaire à fort impact (par exemple Global Administrator, Privileged Role Administrator, Application Administrator), de rôles Azure RBAC équivalents à admin (Owner, User Access Administrator, Role Based Access Control Administrator), ou de permissions Microsoft Graph de niveau tier-1 (par exemple RoleManagement.ReadWrite.Directory).
• Okta : les principals disposant de rôles admin intégrés (Super, Org, App, Group, User, API Access Management Admin) ou de rôles personnalisés accordant des permissions équivalentes à admin.

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

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 droits avec les actions que l'identité effectue : elle signale les permissions larges par nature, quel que soit l'usage 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) reprend le résultat de l'identité qui le détient.

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 FullAccess, telle que AmazonS3FullAccess ou AWSLambda_FullAccess.
  • Une politique personnalisée ou inline avec une instruction Allow sur l'action générique complète (*) ou une action générique de service (telle que s3:* ou ec2:*), sur n'importe quelle ressource. Les instructions comportant 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 (*), comme Contributor.
  • Une permission d'application Microsoft Graph à privilège élevé. Cela inclut les permissions tier-1 utilisées pour la détection admin et les permissions d'écriture ayant 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 le droit 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 un scope 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 disposant de droits plus larges que ce qu'une tâche limitée exige.

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 provenant de l'infraction de politique active la plus risquée sur l'identité. Par exemple, un secret fuité publiquement est noté critical, une fuite interne est notée high, une identité surprivilégiée est notée medium, un secret à longue durée de vie est noté low.
2. Modificateurs qui augmentent le score de +1 niveau chacun, plafonné à critical :
   • Identité admin : toute infraction sur une NHI admin est un niveau plus grave.
   • Cross-environment avec production : une infraction cross-environment qui touche un environnement de production, tel que déduit par secret, est 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 en priorité sur les NHI où un attaquant ferait le plus de dégâts.

Notez que de nouvelles politiques seront prises en charge prochainement.