IaC Scanning : une opportunité d'apprentissage fantastique et négligée

Tout ce que vous lisez sur l'infrastructure en tant que code (IaC) se concentre sur son fonctionnement ou sur la raison pour laquelle vous voulez vous assurer qu'elle se construit réellement comme vous le souhaitez.

Ce sont des zones critiques. Mais réfléchissons-nous suffisamment à la manière dont nous utilisons cette approche dans notre organisation ?

As Mélinda Marques d'ESG déclare dans un rapport d'entreprise, "83% des organisations ont connu une augmentation des erreurs de configuration des modèles IaC" alors qu'elles continuent d'adopter la technologie.

Nous savons d'après les travaux effectués par la Cloud Security Alliance ("Principales menaces pour le Cloud Computing : Egregious Eleven") et d'autres, les erreurs de configuration continuent d'être un risque majeur dans le cloud.

IaC est pris en charge pour réduire
les erreurs de configuration en systématisant la création d'infrastructures, en ajoutant un niveau de rigueur et de processus qui garantit que les équipes construisent ce qu'elles veulent et uniquement ce qu'elles veulent. Si ~ 83% des équipes ne voient pas cela, il y a un problème plus profond en jeu.

Dans des équipes plus petites, où les éléments Dev et Ops de la philosophie DevOps sont ensemble, cela a du sens. IaC permet à ces petites équipes d'utiliser le même langage — le code — pour décrire tout ce qu'elles font.

C'est pourquoi nous voyons des abstractions de niveau encore plus élevé que des outils comme Terraform ou AWS CloudFormation dans le CDK AWS et des projets comme cdk8s. Ces abstractions de haut niveau sont plus confortables pour les développeurs.

Une perspective ops/SRE/plateforme d'un service cloud sera très différente d'une perspective développeur du même service. Un développeur examinera un service de mise en file d'attente et plongera dans son interface - un simple point de terminaison à ajouter et un à lire ? Vendu. C'est une intégration facile.

Cette perspective opérationnelle vise à trouver les bords. Alors, quand cette file d'attente atteint-elle sa limite ? Les performances sont-elles constantes ou changent-elles radicalement sous charge ?

Oui, il y a des préoccupations qui se chevauchent. Et oui, c'est une vue simplifiée. Mais l'idée tient. L'IaC résout beaucoup de problèmes, mais il peut aussi créer et amplifier la déconnexion entre les équipes. Plus important encore, cela peut mettre en évidence l'écart entre l'intention de ce que vous essayez de construire et la réalité de ce que vous avez construit.

En conséquence, c'est là que les problèmes de sécurité s'intensifient souvent.

La plupart des outils - commerciaux ou open source - se concentrent sur l'identification des éléments qui ne vont pas avec les modèles d'infrastructure. Ce
est une bonne construction. Fabrication this
serait mauvais. Ces outils visent à générer ces résultats dans le cadre du pipeline d'intégration/livraison continue (CI/CD).

C'est un bon début. Mais cela fait écho au même problème de langue.

Qui parle et qui écoute ?

Lorsqu'un outil IaC met en évidence un problème, qui s'en occupe ? S'il s'agit de l'équipe de développement, dispose-t-elle de suffisamment d'informations pour savoir pourquoi cela a été signalé comme un problème ? S'il s'agit de l'équipe des opérations, les conséquences du problème sont-elles décrites dans le rapport ?

Pour les développeurs, ce qui arrive souvent, c'est qu'ils ajusteront simplement la configuration pour que le test IaC réussisse.

Pour les opérations, il s'agit généralement de savoir si les tests réussissent. Si tel est le cas, passez à la tâche suivante. Ce n'est pas un coup sur l'une ou l'autre équipe; il met plutôt en évidence l'écart entre les attentes et la réalité.

Ce qu'il faut, c'est le contexte. Les outils de sécurité IaC offrent une visibilité sur ce qui est sur le point (espérons-le) d'être construit. Le but est d'arrêter les problèmes before ils entrent en production.

Les outils de sécurité IaC d'aujourd'hui mettent en évidence de vrais problèmes qui doivent être résolus. Prendre la sortie de ces outils et l'enrichir avec un contexte supplémentaire spécifique à l'équipe responsable du code est une opportunité parfaite pour une automatisation personnalisée.

Cela aidera également à combler le fossé linguistique. La sortie de votre outillage est essentiellement dans une troisième langue - juste pour compliquer les choses - et doit être communiquée d'une manière logique pour un public de développement ou d'exploitation. Souvent les deux.

Par exemple, lorsqu'une analyse signale qu'une règle de groupe de sécurité n'a pas de description, pourquoi est-ce important ? Le simple fait de recevoir une alerte indiquant "Ajouter une description pour le contexte" n'aide personne à mieux construire.

Ce type de drapeau est une excellente occasion d'éduquer les équipes qui construisent dans le cloud. L'ajout d'une explication indiquant que les règles du groupe de sécurité doivent être aussi spécifiques que possible réduit les risques d'attaques malveillantes. Fournir des références à des exemples de règles strictes. Appelez cela sans connaître l'intention, et les autres équipes ne peuvent pas tester la validité de la confirmation de sécurité.

La sécurité est la responsabilité de chacun, donc reconnaître le fossé linguistique entre les développeurs et les opérations mettra en évidence des opportunités comme celle-ci pour ajouter des automatisations simples qui fournissent des informations à vos équipes. Cela contribuera à améliorer ce qu'ils construisent et, par conséquent, entraînera de meilleurs résultats en matière de sécurité.

À propos de l’auteur

Je suis un scientifique médico-légal, un conférencier et un analyste technologique qui essaie de vous aider à comprendre le monde numérique et son impact sur nous. Pour les utilisateurs du quotidien, mon travail permet d'expliquer quels sont les enjeux du monde numérique. Quel est l'impact de l'utilisation des médias sociaux sur votre vie privée ? Qu'est-ce que cela signifie lorsque des technologies comme la reconnaissance faciale commencent à être utilisées dans nos communautés ? J'aide à répondre à des questions comme celle-ci et plus encore. Pour les personnes qui développent des technologies, je les aide à appliquer une optique de sécurité et de confidentialité à leur travail, afin qu'elles puissent permettre aux utilisateurs de prendre des décisions plus claires concernant leurs informations et leur comportement. Il y a une montagne de confusion en matière de confidentialité et de sécurité. Il ne devrait pas y en avoir. Je rends la sécurité et la confidentialité plus faciles à comprendre.