L’importance des ingénieurs plateforme dans un programme de sécurité

Les ingénieurs plateforme doivent avoir les moyens de jouer pleinement leur rôle dans le programme de sécurité d’une organisation. Leur travail a une influence considérable sur la posture de sécurité d’un produit et peut avoir un impact tout aussi important, voire supérieur selon certains, à celui des vulnérabilités applicatives. Malgré l’importance de leur contribution, leur rôle dans les programmes de sécurité reste mal défini. Alors que les fournisseurs cloud publient des modèles de responsabilité partagée bien définis à l’intention de leurs clients, les organisations précisent rarement qui, des développeurs d’applications ou des ingénieurs plateforme, est responsable de la sécurité.

Dans cet article, nous verrons ce qu’est un ingénieur plateforme et présenterons certains des défis dont les équipes de sécurité des produits doivent avoir conscience.

Qu’est-ce qu’un ingénieur plateforme ?

Les ingénieurs plateforme créent des outils et des systèmes qui permettent aux développeurs de gagner en autonomie au sein de leur organisation. Ils mettent en place des « parcours balisés » qui permettent aux développeurs de renoncer à certaines options en échange d’une charge cognitive réduite, d’une meilleure ergonomie et d’un cycle de développement logiciel plus simple. Libérés du paradoxe du choix et des longues courbes d’apprentissage, les développeurs d’applications peuvent mieux se concentrer sur la satisfaction de leurs clients.

Les ingénieurs plateforme utilisent un vaste ensemble de composants d’infrastructure complexes et fragmentés pour fournir un ensemble plus restreint de composants plus simples et moins riches en fonctionnalités. En substance, ils assemblent des briques LEGO pour créer quelque chose qui ressemble à Duplo.

Lorsqu’elle est bien menée, cette approche permet aux développeurs d’applications de personnaliser 80 % de leur travail sans avoir à devenir des experts en infrastructure.

Quel est le lien entre l’ingénierie de plateforme et la sécurité ?

En faisant abstraction des détails de l’infrastructure, les ingénieurs plateforme prennent des décisions sur la manière dont celle-ci doit être configurée. Ces décisions ont un impact considérable sur la posture de sécurité de l’organisation. On pourrait soutenir que les défauts de conception et les erreurs de configuration ont davantage d’impact sur la posture du programme de sécurité que les vulnérabilités applicatives. En effet, dans le rapport de Snyk 2021 State of Cloud Native Application Security, nous avons constaté que 45 % des personnes interrogées avaient des vulnérabilités dues à des erreurs de configuration.

Pensez à toutes les erreurs qui peuvent survenir lors de la conception et de la mise en œuvre de chaque couche d’une plateforme de développement interne classique :

• Gestion des applications : agents de journalisation, intégration et déploiement continus (CD), orchestration des conteneurs, gestion des secrets, réplication des images, sauvegarde et cycle de vie des données, création et stockage des artefacts

• Calcul des applications : clusters de conteneurs, machines virtuelles, équilibrage de charge, certificats

• Réseau : DNS, réseaux isolés, connectivité Internet, règles d’entrée et de sortie

• Accès : identité, privilèges

Et cette liste ne fera que s’allonger si vous en parlez à un ingénieur plateforme. Examinons maintenant certains des problèmes auxquels les équipes d’ingénierie de plateforme peuvent être confrontées.

Difficile de sécuriser un assemblage grandissant de briques LEGO toujours plus complexes

Le nombre de composants est élevé et ne cesse d’augmenter. Chacun d’entre eux devient toujours plus sophistiqué. Les microservices évoluent également vers le SaaS, à mesure que les clients confient certains composants de leur architecture à des éditeurs de logiciels externes.

Les ingénieurs plateforme sont souvent généralistes, avec des connaissances plus approfondies dans certains domaines. Comme les développeurs d’applications, ils connaissent mal les vulnérabilités de sécurité. Toutefois, leurs lacunes sont sans doute plus variées et plus difficiles à cerner, car il faut souvent bien connaître les services d’un fournisseur donné et leur configuration.

Une gestion des changements complexe, aggravée par des pratiques de test encore immatures

Pour les développeurs d’applications, les tests sont bien compris et largement pratiqués. On attend des développeurs qu’ils écrivent des tests pour leur code et qu’ils comprennent les avantages et les inconvénients des différentes stratégies de test à chaque niveau de la pyramide des tests. Par conséquent, le coût de fusion des correctifs de sécurité des applications est relativement faible : l’organisation peut s’appuyer sur la maturité de ses tests pour se prémunir contre les régressions. Il suffit donc souvent qu’une compilation aboutisse pour fusionner un correctif de sécurité.

La situation est différente pour l’ingénierie de plateforme. La codification de l’infrastructure progresse encore lentement dans les différents secteurs et au sein des entreprises. Même au-delà de ce prérequis élémentaire — le contrôle de version, nécessaire à toute forme de test —, les pratiques de test des changements d’infrastructure sont mal définies. Le risque associé à chaque changement est donc élevé. Pour ne rien arranger, tous les attributs d’un changement de configuration n’ont pas les mêmes conséquences. Certaines mises à jour, omissions ou additions d’attributs déclenchent le remplacement de ressources, ce qui peut avoir de graves répercussions sur les ressources qui en dépendent, les applications qu’elles prennent en charge et leurs utilisateurs.

Aujourd’hui, corriger les vulnérabilités de l’infrastructure coûte plus cher. Les ingénieurs plateforme examinent chaque changement avec inquiétude, car c’est leur meilleur moyen d’éviter une catastrophe lors du déploiement. Cette pratique ne pourra pas passer à l’échelle, mais la communauté encore jeune de l’ingénierie de plateforme n’a pas encore défini de bonnes pratiques.

Le libre-service entraîne des problèmes de déploiement

L’ingénierie de plateforme, souvent appelée « platform as a product », consiste à offrir aux utilisateurs un parcours balisé et à permettre aux développeurs de gagner en autonomie. Certains changements apportés à la plateforme sont déployés par les ingénieurs plateforme eux-mêmes, notamment ceux qui concernent la configuration de l’infrastructure dans les différentes instances de l’entreprise. D’autres changements dépendent toutefois de leur adoption et de leur installation par les équipes de développement d’applications : nouveaux charts Helm, modules Terraform, orbs ou plugins de déploiement, bibliothèques d’instrumentation, et bien d’autres encore.

La posture de sécurité de l’organisation évolue au fil de ces versions, et les retards de mise à jour de quelques équipes seulement peuvent poser des problèmes à l’ensemble du programme de sécurité, sans que la sécurité des applications en ait connaissance.

En résumé

Face à ces défis, les ingénieurs plateforme ont besoin d’outils pour détecter rapidement les erreurs de configuration dans leur cycle de développement logiciel, mais aussi d’aide pour aller au-delà des tests et améliorer la conception de leurs parcours balisés.

Les ingénieurs plateforme auront une influence considérable sur la posture de sécurité de leur organisation et, plus généralement, sur l’univers du logiciel, caractérisé par une multiplicité de fournisseurs et une forte dépendance au SaaS. L’émergence de bonnes pratiques et les investissements dans la maturité des plateformes permettront d’éliminer et d’atténuer les risques de sécurité, tout en aidant les développeurs d’applications à corriger les vulnérabilités plus rapidement et à moindre coût que jamais.