Selon les recherches de GitGuardian et CyberArk, 79 % des décideurs informatiques ont déclaré avoir été confrontés à une fuite de secretscontre 75 % dans le rapport de l’année précédente. Dans le même temps, le nombre de fuites d’identifiants n’a jamais été aussi élevé, avec plus de 12,7 millions d’informations d’identification codées en dur dans les seuls référentiels publics GitHub. L’un des aspects les plus troublants de ce rapport est que plus de 90 % des secrets valides trouvés et signalés sont restés valides pendant plus de 5 jours.
D’après le même la recherche, en moyenne, cela prend aux organisations 27 jours pour remédier aux fuites d’informations d’identification. Combinez cela avec le fait que les identités non humaines sont plus nombreuses que les identités humaines d’au moins 45 : 1et il est facile de comprendre pourquoi de nombreuses organisations réalisent que mettre un terme à la prolifération des secrets signifie trouver un moyen de gérer cette crise d’identité des machines. Malheureusement, la recherche montre également que de nombreuses équipes ne savent pas à qui appartient la sécurité de ces identités. C’est une parfaite tempête de risques.
Pourquoi la rotation prend-elle si longtemps
Alors, pourquoi mettons-nous autant de temps à alterner les informations d’identification si nous savons qu’elles constituent l’une des voies d’attaque les plus faciles pour les adversaires ? L’un des principaux facteurs contributifs est le manque de clarté sur la manière dont nos informations d’identification sont autorisées. Les autorisations autorisent les éléments spécifiques qu’une entité, comme une charge de travail Kubernetes ou un microservice, peut demander avec succès à un autre service ou source de données.
Rappelons-nous ce que signifie la résolution d’un incident de prolifération de secrets : vous devez remplacer un secret en toute sécurité sans rien casser ni accorder de nouvelles autorisations trop étendues, ce qui pourrait potentiellement introduire davantage de risques de sécurité pour votre entreprise. Si vous avez déjà un aperçu complet du cycle de vie de vos identités non humaines et de leurs secrets associés, il s’agit d’un processus assez simple consistant à les remplacer par de nouveaux secrets avec les mêmes autorisations. Cela peut prendre un temps considérable si vous ne disposez pas déjà de ces informations, car vous devez espérer que le développeur qui l’a créé à l’origine est toujours là et a documenté ce qui a été fait.
Voyons pourquoi la gestion des autorisations est particulièrement difficile dans les environnements dominés par les NHI, examinons les défis auxquels les développeurs et les équipes de sécurité sont confrontés pour équilibrer contrôle d’accès et productivité, et discutons de la manière dont un modèle de responsabilité partagée pourrait aider.
À qui appartient vraiment l’étalement des secrets ?
La prolifération des secrets fait généralement référence à la prolifération de clés d’accès, de mots de passe et d’autres informations d’identification sensibles dans les environnements de développement, les référentiels et les services comme Slack ou Jira. Le dernier rapport Voice of the Practitioners de GitGuardian souligne que 65 % des personnes interrogées attribuent directement la responsabilité de la remédiation aux équipes de sécurité informatique. Dans le même temps, 44 % des responsables informatiques ont déclaré que les développeurs ne suivaient pas les meilleures pratiques. pour la gestion des secrets.
La prolifération des secrets et les problèmes sous-jacents liés aux informations d’identification de longue durée et trop autorisées continueront de se creuser dans cette lacune jusqu’à ce que nous trouvions comment mieux travailler ensemble dans un modèle de responsabilité partagée.
Le point de vue du développeur sur les autorisations
Les développeurs sont confrontés à une pression énorme pour créer et déployer rapidement des fonctionnalités. Cependant, une gestion minutieuse des autorisations, avec les meilleures pratiques de sécurité, peut demander beaucoup de travail. Chaque projet ou application a souvent ses propres exigences d’accès, qui prennent du temps à rechercher et à définir correctement, ce qui donne presque l’impression d’un travail à temps plein en plus du travail de création et de déploiement de leurs applications. Trop souvent, les meilleures pratiques de création et de gestion des autorisations ne sont pas appliquées de manière uniforme entre les équipes, sont rarement documentées de manière appropriée ou sont complètement oubliées une fois que le développeur a fait fonctionner l’application.
Pour aggraver le problème, dans de trop nombreux cas, les développeurs accordent simplement des autorisations trop larges à ces identités de machine. Un rapport a révélé que seulement 2 % des autorisations accordées sont réellement utilisées.. Si l’on regarde de plus près ce à quoi ils sont confrontés, il est facile de comprendre pourquoi.
Par exemple, pensez à gérer les autorisations au sein d’Amazon Web Services. Les politiques de gestion des identités et des accès (IAM) d’AWS sont connues pour leur flexibilité, mais elles sont également complexes et déroutantes à gérer. IAM prend en charge différents types de stratégies (basées sur l’identité, basées sur les ressources et les limites d’autorisation), qui nécessitent toutes des configurations précises. AWS propose également plusieurs chemins d’accès pour les informations d’identification, notamment les rôles IAM et les autorisations KMS (Key Management Service), chacun doté de ses propres configurations d’accès uniques. Apprendre ce système n’est pas une mince affaire.
GitHub est un autre exemple courant de service où les autorisations peuvent devenir difficiles à gérer. Les clés API peuvent accorder des autorisations aux référentiels de diverses organisations, ce qui rend difficile la garantie de limites d’accès appropriées. Une seule clé peut involontairement fournir un accès excessif à travers les environnements lorsque les développeurs sont membres de plusieurs organisations. La pression est forte pour bien faire les choses, alors que le temps presse et que le retard ne cesse de croître.
Pourquoi les équipes de sécurité ne peuvent pas résoudre ce problème à elles seules
Il peut sembler logique de confier aux équipes de sécurité la responsabilité de la surveillance et de la rotation des secrets ; après tout, c’est un problème de sécurité. La réalité est que ces équipes manquent souvent des connaissances granulaires au niveau du projet, nécessaires pour apporter des modifications en toute sécurité. Les équipes de sécurité ne disposent pas toujours du contexte nécessaire pour comprendre quelles autorisations spécifiques sont essentielles au bon fonctionnement des applications. Par exemple, une modification d’autorisation apparemment mineure pourrait interrompre un pipeline CI/CD, perturber la production ou même provoquer un problème à l’échelle de l’entreprise. échec en cascade si le mauvais service disparaît.
La nature dispersée de la gestion des secrets entre les équipes et les environnements augmente également la surface d’attaque. Sans personne réellement responsable, il devient beaucoup plus difficile de maintenir la cohérence des contrôles d’accès et des pistes d’audit. Cette fragmentation entraîne souvent des informations d’identification excessives ou obsolètes et les autorisations associées qui restent actives beaucoup trop longtemps, voire pour toujours. Il peut alors être difficile de savoir qui a un accès légitime ou illégitime à quels secrets à un moment donné.
Un modèle de responsabilité partagée pour une rotation plus rapide
Les développeurs et les équipes de sécurité pourraient aider à résoudre ces problèmes en se réunissant au milieu et en construisant un modèle de responsabilité partagée. Dans un tel modèle, les développeurs sont davantage responsables de la gestion cohérente de leurs autorisations grâce à des outils appropriés, tels que Gestionnaire de secrets Conjur de CyberArk ou Vault par HashiCorptout en documentant mieux les autorisations et la portée des autorisations nécessaires au niveau du projet. Les équipes de sécurité devraient aider les développeurs en travaillant à automatiser la rotation des secrets, en investissant dans des outils d’observabilité appropriés pour clarifier l’état des secrets et en travaillant avec le service informatique pour éliminer complètement les informations d’identification de longue durée.
Si les développeurs documentent clairement les autorisations nécessaires dans leurs exigences, cela pourrait aider les équipes de sécurité à réaliser des audits plus rapides et plus précis et à accélérer les mesures correctives. Si les équipes de sécurité s’efforcent de garantir que la voie globale la plus simple et la plus rapide vers la mise en œuvre d’un nouveau secret d’identité non humaine est également la voie la plus sûre et la plus évolutive, alors il y aura beaucoup moins d’incidents nécessitant une rotation d’urgence, et tout le monde y gagnera.
L’objectif des développeurs doit être de garantir que l’équipe de sécurité peut alterner ou mettre à jour les informations d’identification de ses applications en toute confiance, en toute autonomie, sachant qu’elle ne met pas en danger la production.
Questions clés à aborder concernant les autorisations
Lorsque vous réfléchissez à ce qui doit être documenté, voici quelques points de données spécifiques pour aider cet effort inter-équipes à se dérouler plus facilement :
- Qui a créé le titre ? – De nombreuses organisations ont du mal à suivre la propriété des informations d’identification, en particulier lorsqu’une clé est partagée ou alternée. Cette connaissance est essentielle pour comprendre qui est responsable de la rotation ou de la révocation des diplômes.
- À quelles ressources accède-t-il ? – Les clés API peuvent souvent accéder à une gamme de services, des bases de données aux intégrations tierces, ce qui rend essentiel la limitation des autorisations au minimum absolu nécessaire.
- Quelles autorisations accorde-t-il ? – Les autorisations varient considérablement en fonction des rôles, des politiques basées sur les ressources et des conditions politiques. Par exemple, dans Jenkins, un utilisateur disposant de l’autorisation « Global/Lecture » peut afficher des informations générales, tandis que « Global/Administrer » accorde un contrôle total sur le système.
- Comment pouvons-nous le révoquer ou le faire pivoter ? – La facilité de révocation varie selon la plateforme et, dans de nombreux cas, les équipes doivent rechercher manuellement les clés et les autorisations sur l’ensemble des systèmes, ce qui complique les mesures correctives et prolonge l’exposition aux menaces.
- L’identifiant est-il actif ? – Il est essentiel de savoir si un identifiant est toujours utilisé. Lorsque les NHI utilisent des clés API de longue durée, ces informations d’identification peuvent rester actives indéfiniment à moins d’être gérées correctement, créant ainsi des risques d’accès persistants.
Les autorisations sont difficiles, mais nous pouvons les gérer ensemble comme une seule équipe
Selon le rapport GitGuardian, si 75 % des personnes interrogées ont exprimé leur confiance dans leurs capacités de gestion des secrets, la réalité est souvent bien différente. Le temps moyen de remédiation de 27 jours reflète cet écart entre la confiance et la pratique. Il est temps de repenser la manière dont nous mettons en œuvre et communiquons les secrets et leurs autorisations en tant qu’organisation.
Alors que les développeurs travaillent avec diligence pour équilibrer sécurité et fonctionnalité, le manque de processus d’autorisation rationalisés et de chemins de documentation non centralisés ou non standardisés ne font qu’amplifier les risques. Les équipes de sécurité ne peuvent pas résoudre à elles seules ces problèmes efficacement en raison de leur connaissance limitée des besoins spécifiques au projet. Ils doivent travailler main dans la main avec les développeurs à chaque étape du processus.
GitGuardian développe la nouvelle génération d’outils de sécurité des secrets, aidant les équipes de sécurité et informatiques à maîtriser la prolifération des secrets. Savoir quelles informations d’identification en clair et de longue durée sont exposées dans votre code et dans d’autres environnements est une première étape nécessaire pour éliminer cette menace. Commencez dès aujourd’hui avec GitGuardian.