Partager via

Sécuriser l’environnement de développement pour la Confiance Zéro

  • Article

Cet article vous aide, en tant que développeur, à sécuriser votre environnement de développement afin de pouvoir implémenter les principes de la Confiance Zéro (vérifier explicitement, utiliser des privilèges minimum, supposer une violation). Il propose du contenu de notre livre électronique Sécuriser les environnements DevOps d’entreprise et met en évidence les meilleures pratiques en matière de sécurité et d’approbation des outils, extensions et intégrations de branche.

La rapidité des développeurs repose sur votre capacité à travailler comment et où vous souhaitez optimiser les résultats métier. Vous souhaitez des machines puissantes et personnalisables avec un accès racine ou administrateur. Toutefois, les demandes des développeurs peuvent s’exécuter contrairement aux réglementations de conformité et la nécessité d’auditer et de contrôler l’accès et le stockage de l’environnement des employés privés.

Les machines non managées qui se connectent au réseau d’organisation défient les équipes de sécurité, l’approvisionnement et le conseil de gouvernance. Le meilleur scénario de fournir aux développeurs des environnements d’employés par défaut et renforcés crée un mépris des deux côtés. Lorsque les employés se connectent n’importe où, les réseaux Wi-Fi vulnérables sont une porte ouverte pour la cyber-attaque. Le vol et la perte de matériel sont des préoccupations majeures.

Les vulnérabilités s’étendent aux intégrations d’environnement de développement. Les outils de développement offrant une extensibilité riche peuvent avoir des intégrations non gérées dans leurs marketplaces. Les extensions malveillantes peuvent mettre en danger les outils de développement et provoquer des violations à l’échelle de l’entreprise.

Dans le diagramme ci-dessous, notez comment l’environnement de développement se connecte à l’environnement d’outils DevOps pour affecter les branches Git. Il élargit la surface de l’environnement grâce à la connexion à des packages open source et à des extensions d’application. Les extensions présentent des vecteurs d’attaque dans les vulnérabilités des applications de dépendance et d’extension.

Le diagramme illustre les environnements de développeur et les menaces de sécurité telles que décrits dans l’eBook précédent et résumées dans les articles connexes en lien ci-après.

Donner aux membres de l’équipe DevOps une flexibilité et un contrôle tout en empêchant les attaques malveillantes constitue un défi fondamental pour les bureaux de sécurité. DevOps peut contrôler l’environnement de développement avec un environnement cloud (voir Lancement approuvé pour les machines virtuelles Azure et GitHub Enterprise Cloud Docs) et sécuriser l’environnement développeur avec des conteneurs (consultez la documentation GitHub Codespaces).

En outre, les développeurs peuvent implémenter ces mesures de Confiance Zéro pour sécuriser l’environnement des développeurs :

  • Configurez les privilèges minimum.
  • Limitez les personnes autorisées à modifier et approuver le code avec la sécurité des branches.
  • Adoptez uniquement les outils, extensions et intégrations approuvés.

Meilleures pratiques pour le moindre privilège

Les développeurs croient souvent qu’ils peuvent intercepter des programmes malveillants, des hameçonnages et des violations dans leurs environnements. Les grandes surfaces de menace de l’environnement des développeurs rendent irréaliste pour les développeurs de maintenir les connaissances système omniprésentes. Une organisation perd un temps de correction précieux lorsqu’elle détecte une violation à la suite d’une attaque qui compromet un environnement de développement disposant d’un accès administrateur à tous les systèmes.

Pour corriger les opportunités d’accès potentielles qui amènent les pirates à cibler le rôle développeur de logiciels, tenez compte des Confiance Zéro meilleures pratiques de sécurité des privilèges minimum pour les applications.

  • Implémentez des privilèges minimum et un accès juste-à-temps pour DevOps. Assurez-vous que les membres de l’équipe ne conservent qu’un accès minimal aux environnements pendant le temps nécessaire le plus court. Placez les stratégies en place pour couvrir les droits d’accès administrateur sur les appareils principaux, les outils DevOps, les pipelines de mise en production, les référentiels de code, les environnements, les magasins de secrets et les bases de données. Pour les équipes DevOps, l’exigence de base est une connexion au magasin d’identités de l’organisation. Utilisez la fédération des identités pour l’intégration à des environnements SaaS afin d’éviter la duplication d’identités sur des plateformes tierces et de réduire les risques d’exposition.
  • N’utilisez pas de jetons d’accès personnels pour l’accès au code source. Les pratiques sécurisées pour les équipes DevOps incluent l’accès aux outils DevOps basés sur SaaS, aux référentiels de code (via SSH, HTTPS ou jeton d’accès personnel). Pour l’accès à l’environnement SaaS, consultez des instructions claires sur la façon dont les principes d’accès déterminent qui peut télécharger (cloner) les dépôts de code des systèmes et à partir des appareils (locaux, cloud et conteneurs). Par exemple, OneDrive peut bloquer ou limiter l’accès aux appareils non gérés.
  • Normaliser et synchroniser des comptes d’utilisateur GitHub Enterprise Managed User (UEM) avec des identités d’entreprise. Avec les utilisateurs gérés par l’entreprise, vous pouvez contrôler les comptes d’utilisateur de vos membres d’entreprise via votre fournisseur d’identité (IdP). Dans votre magasin d’identités d’organisation, définissez explicitement les noms d’utilisateur, les emails et les noms d’affichage GitHub. Les utilisateurs identifient ensuite facilement les collaborateurs.
  • Pour les trois façons dont un développeur peut se connecter à un environnement SaaS (HTTPS avec une identité, un jeton d'accès personnel, une connexion avec une clé SSH), établir des connexions avec le magasin d'identités de l’organisation. Avec GitHub (à l’exception des comptes EMU GitHub), votre identité est toujours votre identité publique. L’accès contrôlé via l’authentification unique (SSO) nécessite une connexion avec le magasin d’identités de l’organisation.
  • Utilisez une autorité de certification SSH pour fournir des certificats SSH signés aux membres afin d’accéder en toute sécurité aux ressources avec Git. Un certificat SSH est un mécanisme permettant à une clé SSH de signer une autre clé SSH. GitHub Enterprise Cloud prend en charge les certificats SSH pour permettre aux organisations de contrôler davantage la façon dont les membres accèdent aux référentiels. Administration peuvent charger leur clé publique d’autorité de certification SSH et émettre des certificats pour les membres à utiliser pour l’authentification Git. Les certificats peuvent uniquement accéder aux référentiels appartenant à l’organisation. Les administrations peuvent exiger que les membres utilisent des certificats lors de l’accès à leurs référentiels.
  • Utilisez un gestionnaire d’informations d’identification Git pour renforcer l’accès à votre code. Les outils tels que Visual Studio (VS) prennent en charge les identités intégrées. VS Code s’en remet à un gestionnaire d’informations d’identification Git.

Meilleures pratiques pour la sécurité des succursales

Lorsque les pirates accèdent au référentiel de code, ils peuvent étudier la sécurité du système et modifier le code sans que les équipes ne notent. Pour empêcher l’accès au référentiel de code non autorisé, implémentez une stratégie de branchement pour établir un contrôle sur les modifications de code (voir l’exemple illustré dans le diagramme suivant).

Le diagramme illustre un exemple de stratégie de ramification qui protège le référentiel principal.

Pour corriger les opportunités d’accès potentielles aux référentiels, tenez compte des meilleures pratiques de sécurité des branches suivantes.

  • Protégez les branches avec des révisions de code pour permettre aux équipes DevOps de contrôler les modifications de code et les avancées d’audit. La stratégie de branchement du diagramme précédent décrit un flux contrôlé de modifications qui fournit une chaîne claire de commandes et de blueprint pour traiter les modifications de code. Parmi les différentes approches de la stratégie de branchement, il est courant que les branche protégée servent de source pour les nouvelles versions en production.
  • Disposez d’administrateurs de référentiels Git qui contrôlent les autorisations d’approbation. Le mécanisme de contrôle des stratégies de branchement se trouve dans le flux de travail d’approbation. Les branches protégées nécessitent des validations, des révisions et des approbations avant d’accepter les modifications. Une option consiste à créer une règle de protection de branche pour appliquer des flux de travail. Par exemple, exiger un examen d'approbation ou une vérification de l'état pour toutes les demandes d'extraction fusionnées dans la branche protégée. Les stratégies de branche aident les équipes à protéger les branches importantes de développement. Les stratégies appliquent les standards de qualité du code et de gestion des modifications de votre équipe.

Meilleures pratiques pour l’approbation d’outils, d’extensions et d’intégrations

L’extensibilité dans les environnements de développement intégré (IDE) est si productive qu’il s’agit essentiellement d’une fonctionnalité obligatoire. Vous vous appuyez sur la possibilité d’appliquer et de organiser des extensions dans la Place de marché d’un IDE spécifique pour concevoir votre environnement de travail optimal.

Pour corriger les IDE sécurisés, tenez compte des meilleures pratiques d’outil, d’extension et d’intégration suivantes.

  • Vérifiez que vous intégrez uniquement des outils à partir de places de marché approuvées et d’éditeurs. Par exemple, la Place de marché VS Code a des milliers d’extensions pour faciliter votre vie. Toutefois, lorsque vos équipes adoptent de nouveaux outils ou extensions, l’aspect le plus important peut être de vérifier la fiabilité d’un éditeur.
  • Configurez des pratiques sécurisées pour contrôler l’utilisation de l’extension pour limiter la surface d’attaque des environnements de développement. La plupart des extensions IDE nécessitent l’approbation de certains privilèges pour fonctionner, souvent en tant que fichier disposant d’autorisations de lecture sur le système pour analyser le code. Les extensions nécessitent des connexions à des environnements cloud pour fonctionner (courantes dans les outils de métrique). L’approbation de fonctionnalités supplémentaires au-dessus de l’IDE ouvre des organisations à davantage de menaces.
  • Sur les machines de développement, suivez le nombre et la maturité des extensions utilisées pour comprendre la surface d’attaque potentielle. Incorporez uniquement les extensions de la Place de marché VS Code à partir de serveurs de publication vérifiés. Lorsque vous installez des extensions d’application avec VS Code, vérifiez régulièrement les extensions que vous exécutez avec la ligne de commande --list-extensions --show-versions. Comprenez bien les composants extensibles que vous exécutez dans votre environnement de développement.

Étapes suivantes