La sécurité applicative à l’ère des microservices


This post is also available in: Anglais Allemand Italien Portugais - du Brésil Espagnol Russe

Alors que les entreprises fractionnent leurs applications en microservices, tirant parti des conteneurs comme architecture idéale à cette fin, la responsabilité de sécurisation de ces environnements évolue également, exposant les entreprises à un plus large éventail de risques de sécurité et de failles de protection.

Nous nous trouvons de fait à un point d’inflexion culturel entre le rôle du DevOps et celui du RSSI. Tandis que le RSSI a pour mission d’assurer la sécurité de l’entreprise à tout prix, pour l’équipe DevOps, l’agilité des activités métier est la seule chose qui compte, si bien qu’elle adopte souvent une approche « satisfaisante » (et parfois, une approche de refus catégorique) en matière de sécurité.

Qu’est-ce que cela implique pour les entreprises et la cybersécurité ?

Nous avions axé notre étude de marché 2019 sur la communauté DevOps et DevSecOps ; nous souhaitions savoir à quel point le rôle de DevOps s’était généralisé et quelle était son influence sur la prise de décision en matière de sécurité des informations. À cette fin, nous avons interrogé près de 300 professionnels travaillant dans des entreprises de toutes tailles du monde entier. Nous vous présentons ci-dessous un résumé de nos conclusions.

Les entreprises adoptent volontiers les technologies et concepts émergents

Les entreprises semblent très conscientes du fait que, dans le cadre de leur transformation numérique, l’introduction de nouveaux cadres exige un esprit ouvert (et un portefeuille important) vis-à-vis des nouvelles solutions. Et elles essaient et/ou acquièrent des mesures de sécurité supplémentaires.

[Sur le même thème : 4 nouveaux défis pour la sécurisation des applications modernes]

Ainsi, 67 % des entreprises interrogées utilisent des microservices/conteneurs, et 53 % d’entre elles recourent déjà à une forme de technologie de sécurité des conteneurs. 43 % d’entre elles ont recours à une solution dédiée pour sécuriser les fonctions sans serveur pendant leur exécution, afin d’éviter toute interruption et toute fuite de données.

Si cela peut sembler prometteur, on a toutefois l’impression que les entreprises adoptent l’approche du « spaghetti lancé sur le mur », en empilant plusieurs technologies sans nécessairement optimiser leur interopérabilité, tout en espérant que cette profusion de solutions les couvrira contre tous les risques.

La gestion des microservices et des conteneurs étant encore considérée comme une technologie émergente, les entreprises sont forcément en phase d’apprentissage en ce qui concerne l’adaptation des bonnes solutions et pratiques à leur nouvelle infrastructure et aux nouveaux flux de données. Cependant, une confiance injustifiée dans les modèles de sécurité existants prévaut, ce qui donne lieu à des failles de sécurité inattendues qui conduisent à des violations de données.

Les entreprises suivent les pratiques de sécurité nécessaires

Les entreprises sont non seulement désireuses d’adopter les nouvelles technologies de sécurité, mais elles suivent aussi largement les sacrosaintes pratiques de sécurité informatique. Cas concrets :

  • 70 % d’entre elles disposent de contrôles de sécurité sur le trafic est-ouest.
  • Plus de la moitié d’entre elles effectuent des vérifications de code en plus des tests de sécurité et des solutions WAF.
  • 52 % d’entre elles estiment que leur principal critère de sélection d’une technologie de sécurité applicative est la qualité de la sécurité.

Cette notion est bien illustrée par les pratiques de sécurité concernant les API. Comme le montre le diagramme ci-dessous, les entreprises sont conscientes des risques de sécurité liés aux API et y remédient activement, ce qui est judicieux car les API sont désormais le lien entre les outils, les applications, les systèmes et les environnements.

[Sur le même thème : Comment empêcher en temps réel l’utilisation abusive des API]

Le respect des pratiques de sécurité élémentaires et l’adoption de rôles tels que DevSecOps (plus de 90 % des entreprises disposent déjà d’équipes DevOps ou DevSecOps, et 58 % ont indiqué que le ratio DevSecOps/personnel de développement était compris entre 1:6 et 1:10), associés à l’empilement des technologies de sécurité applicative, contribuent à donner aux entreprises un sentiment de confiance élevé :

Les applications continuent d’être piratées

Pourtant, les pirates sévissent toujours, et les attaques d’applications restent une menace constante. 88 % des entreprises interrogées ont signalé des attaques tout au long de l’année, et 90 % d’entre elles ont subi une violation de données. L’éventail des attaques quotidiennes citées comprend les violations d’accès, l’empoisonnement de session/cookie, les injections SQL, les dénis de service, les attaques de protocole, les scripts intersites, les falsifications de requêtes intersites et les manipulations d’API.

[Sur le même thème : Menaces envers les API et les applications mobiles]

56 % des entreprises ont indiqué un manque de connaissance des limites de responsabilité en matière de sécurité entre elles et leur fournisseur de services Cloud public. Nombre d’entre elles luttent encore chaque semaine contre différents types d’attaques contre leurs applications.

Les passerelles d’API ne semblent d’ailleurs pas être efficaces. Celles-ci sont principalement utilisées pour l’authentification (37 %), le filtrage des adresses IP (30 %) et un équilibrage sommaire de la charge (28 %), mais ne peuvent évidemment pas bloquer toutes les formes de manipulation et d’utilisation abusive des API.

De manière générale, les solutions basées sur des règles statiques et des heuristiques rigides ne parviennent pas à fournir le niveau approprié de sécurité applicative, car les applications changent tout le temps. Et la moitié des entreprises interrogées indiquent que leurs applications changent en permanence, parfois plusieurs fois par jour. Il n’est donc pas possible pour des humains d’en assurer le contrôle. Pour cela, il faut détecter chaque changement, ajuster la politique en conséquence, la valider et l’appliquer. Mission impossible. Il n’y a pas d’autre choix que de recourir à l’automatisation.

Le rythme rapide des changements procure un certain pouvoir au nouvel acheteur chargé du développement et de la fourniture agiles d’applications et de microservices, qui conçoit l’environnement SDLC et sélectionne les outils. Les rôles émergents du DevOps et du DevSecOps ont une influence croissante sur les décisions et les pratiques de sécurité. Souvenez-vous, c’était l’hypothèse que nous voulions vérifier au départ.

[Sur le même thème : Vos DevOps représentent-ils le plus grand risque pour la sécurité ?]

Qui prend les décisions ?

Pas l’équipe de sécurité. Le service informatique est toujours le principal décideur pour le choix des outils, la définition des politiques et la mise en œuvre des solutions de sécurité applicative (le service informatique contrôle le budget, mais il est néanmoins préoccupant de constater que 70 % des RSSI n’ont pas le dernier mot).

La transformation numérique ne se limite pas au numérique

La conclusion que nous tirons de cette étude est que les attaques sont encore efficaces parce que les entreprises n’ont pas pleinement pris conscience de l’impact de la transformation numérique sur leurs activités.

En matière de transformation numérique, la technologie est le fer de lance du changement. Et tandis que les entreprises achètent et adoptent de nouvelles technologies et de nouveaux cadres (c’est la partie facile !), la technologie à elle seule ne peut pas remplir ses promesses. Malgré les efforts des entreprises pour suivre les bonnes pratiques de sécurité, les attaques ne perdent pas en efficacité. Pourquoi ?  Parce que les entreprises ne sont pas passées à la deuxième étape de la transformation numérique – une étape non numérique, consistant à acquérir de nouvelles compétences, à adapter les processus métier et à redéfinir les rôles et les responsabilités.

C’est à ce niveau que la sécurité des applications est défaillante. En permettant aux professionnels de la sécurité de faire leur travail et de faire de la sécurité un soutien aux activités, la sécurité pourra enfin évoluer au rythme de l’entreprise.

Ben Zilberman

Ben Zilberman is a director of product-marketing, covering application security at Radware. In this role, Ben specializes in web application and API protection, as well as bot management solutions. In parallel, Ben drives some of Radware’s thought leadership and research programs. Ben has over 10 years of diverse experience in the industry, leading marketing programs for network and application security solutions, including firewalls, threat prevention, web security and DDoS protection technologies. Prior to joining Radware, Ben served as a trusted advisor at Check Point Software Technologies, where he led channel partnerships and sales operations. Ben holds a BA in Economics and a MBA from Tel Aviv University.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Locations
Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program

CyberPedia

An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

CyberPedia
What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Blog
Security Research Center