Risques de fuite de secrets

Les secrets tels que les clés API, les mots de passe et les jetons validés pour les référentiels peuvent être exploités par des utilisateurs non autorisés, créant ainsi des risques de sécurité, de conformité et de risque financier pour votre organisation.

Dans cet article

Qu’est-ce que les secrets ?

Les secrets sont des informations d’identification qui accordent l’accès aux systèmes et données sensibles. Voici quelques exemples courants :

  • Clés d’API et jetons utilisés pour s’authentifier auprès des services externes
  • Mots de passe de base de données et chaînes de connexion
  • Informations d’identification du fournisseur cloud et jetons de compte de service
  • Certificats et clés de chiffrement

Lorsque les secrets sont validés dans des référentiels, ils deviennent des informations d’identification codées en dur qui sont incorporées directement dans votre code source ou vos fichiers de configuration. Ces secrets codés en dur font partie de votre historique Git et restent accessibles même après avoir été supprimés de la dernière validation. Cela signifie que l’adressage d’une fuite d’informations d’identification nécessite plus que la suppression du fichier ; vous devez également révoquer et remplacer les informations d’identification pour empêcher l’accès non autorisé.

Comment les secrets sont exposés

          **Propagation incontrôlée des secrets** se produit lorsque les informations d’identification prolifèrent entre les référentiels, les équipes et les systèmes sans gestion centralisée ni visibilité. Cela rend difficile le suivi des secrets, où ils sont utilisés et s’ils ont été exposés. Les secrets entrent généralement dans des référentiels par le biais de plusieurs modèles courants.

Flux de travail de développement

  • Informations d’identification codées en dur ajoutées pendant les tests locaux et validées par inadvertance
  • Secrets dans des fichiers de configuration tels que les fichiers .env ou les modèles d’infrastructure en tant que code
  • Exemples d’informations d’identification contenant des clés API ou des jetons réels dans la documentation, les wikis ou les fichiers README

Gestion du référentiel

  • Référentiels hérités contenant des informations d’identification oubliées mais toujours actives
  • Secrets partagés dans les incidents GitHub, les commentaires de pull request, les discussions ou les gists.
  • Informations d’identification introduites par des contributeurs externes ou des sous-traitants

Propagation du contrôle de version

  • Les secrets persistent dans l’historique Git même après la suppression du code actuel.
  • Les informations d’identification se propagent aux dépôts dupliqués, aux systèmes de sauvegarde et aux journaux CI/CD.
  • Les dépôts publics avec des secrets exposés sont indexés par les moteurs de recherche et les services d’analyse spécialisés.

Risques liés à la sécurité

Les secrets exposés peuvent entraîner plusieurs types d’incidents de sécurité.

Accès non autorisé

Les fuites d’informations d’identification donnent aux utilisateurs non autorisés un accès direct à vos systèmes. Une fois exposés, les secrets codés en dur peuvent être exploités pour :

  • Approvisionner l’infrastructure ou les services sur votre compte à l’aide des informations d’identification du fournisseur cloud divulguées
  • Accéder aux données client ou organisationnelles sensibles par le biais d’informations d’identification de base de données compromises
  • Obtenir une entrée dans les systèmes de production via des jetons de compte de service exposés

Violations de données

Les fuites d’informations d’identification donnent aux utilisateurs non autorisés un accès direct à vos systèmes, ce qui entraîne des violations de données. Une fois que les attaquants ont accès à l’aide d’informations d’identification exposées, ils peuvent exfiltrer des données sensibles, modifier ou supprimer des informations critiques et compromettre la confiance des clients. Les violations de données nécessitent une réponse immédiate aux incidents, notamment la révocation des informations d’identification, la correction du système et l’évaluation de l’étendue et de l’impact de la violation.

Attaques de chaîne d’approvisionnement

Les jetons de Registre de packages exposés peuvent être utilisés pour publier des versions malveillantes de votre logiciel, ce qui affecte les utilisateurs et organisations en aval qui dépendent de vos packages.

Impact financier

Les secrets exposés peuvent coûter de l’argent à votre organisation de plusieurs façons.

  •         **Factures de cloud inattendues** : les clés API divulguées permettent aux attaquants d’utiliser vos ressources cloud. Ils peuvent exécuter des instances de calcul, stocker des données ou mine de crypto-monnaie sur votre compte, ce qui génère des factures volumineuses.

  •         **Réponse aux incidents** : l’examen des violations, la rotation des informations d’identification et les systèmes d’audit prend beaucoup de temps et de ressources d’ingénierie.

  •         **Coûts juridiques** : les violations de données peuvent entraîner des amendes, des frais juridiques et des frais de notification.

  •         **Dommages à long terme** : clients perdus, coûts d’assurance plus élevés et opportunités commerciales manquées après que les incidents de sécurité deviennent publics.

Sécurité des secrets avec GitHub

          GitHub fournit des outils pour vous aider à prévenir, détecter et corriger les fuites de secrets :

Empêcher la soumission de nouveaux secrets

Activez la protection Push pour analyser le code pendant git push les opérations et bloquer les validations contenant des secrets détectés avant d’entrer dans votre référentiel. Cela empêche l’ajout d’informations d’identification codées en dur à votre base de code et fournit des commentaires en temps réel aux développeurs au point de risque, couvrant les modèles de fournisseur pour les services connus et les modèles non fournisseurs tels que les clés privées et les clés API génériques.

Encouragez les développeurs individuels à activer la protection push pour leurs comptes personnels afin de protéger tous leurs pushs GitHub, quelles que soient les stratégies de l’organisation. Cela permet d’empêcher la prolifération des secrets en interceptant les informations d’identification divulguées avant qu’elles n’atteignent vos référentiels.

2. Détecter les secrets existants

Permet secret scanning de surveiller en continu vos référentiels pour les secrets codés en dur et de générer des alertes quand des informations d’identification sont détectées, ce qui vous permet de révoquer et de faire pivoter rapidement les informations d’identification compromises. Au-delà de la détection par défaut des modèles de fournisseur, vous pouvez développer l’analyse vers des modèles non fournisseurs et définir des modèles personnalisés pour les secrets spécifiques à l’organisation. Cela vous permet de bénéficier d’une visibilité sur l’expansion secrète au sein de votre organisation.

Étapes suivantes

Pour protéger votre organisation contre les fuites de secrets :

  1. Activez la protection Push pour empêcher la validation de nouveaux secrets.
  2. Activez secret scanning pour commencer à détecter les fuites de secrets existantes.
  3. Établissez des pratiques de gestion des informations d’identification sécurisées pour vos équipes de développement.