L’économie numérique mondiale nécessite des interfaces de programmation d’applications (API) pour connecter les services applicatifs aux clients, aux consommateurs, aux partenaires et aux employés. Les applications existantes, modernisées et nouvelles évoluent vers des architectures basées sur des API afin d’accélérer leur développement et de réduire les délais de mise sur le marché. Le rapprochement des fonctionnalités applicatives au plus près du client afin de fluidifier son expérience est à l’origine des architectures décentralisées et du mouvement « API-first ».
Malheureusement, les gains d’efficacité apportés par les API dans le développement d’applications sont de plus en plus éclipsés par les risques qu’elles font peser sur les systèmes d’information des entreprises. Les pirates informatiques ont compris qu’il était facile de compromettre des API lorsqu’elles sont peu ou pas protégées. Personne ne contesterait que les API nécessitent des pratiques de sécurité rigoureuses ; toutefois, il n’existe aucun consensus dans le secteur quant à la meilleure façon de les sécuriser. Voici quelques-unes des principales raisons pour lesquelles les API nécessitent une protection supérieure à celle dont elles bénéficient généralement.
Les vulnérabilités des API restent en grande partie sans réponse
Un nombre croissant de failles de sécurité majeures dues au manque de visibilité et de sécurisation des API se produisent et continueront de se produire dans un avenir prévisible.1 La course à la transformation numérique des organisations entraînera la mise en production d’un nombre accru d’API insuffisamment protégées. De nombreuses organisations tenteront de remédier aux vulnérabilités des API en améliorant leur conception et leur codage, avant de constater qu’elles présentent les mêmes failles de sécurité que les applications en général, notamment parce que la sécurité ne fait généralement pas partie des compétences fondamentales des développeurs d’applications et que les équipes de sécurité peuvent ne pas avoir connaissance de toutes les interconnexions avec des tiers au sein de leur environnement.
La prolifération des API est étonnamment répandue
La prolifération des API découle principalement de l’absence d’une stratégie globale intégrant la gouvernance et les bonnes pratiques. Le développement agile d’applications a entraîné la multiplication des versions d’une même API, sans véritable gestion des versions. Le passage aux microservices aboutit à des applications composées de plusieurs dizaines d’API.
Les API non gérées donnent naissance à des API non autorisées, fantômes et zombies. Le nombre d’API approchera les 2 milliards d’ici 2030, ce qui aggravera encore le problème.2
Les passerelles API ne suffisent pas à sécuriser les API dans des écosystèmes complexes
Aujourd’hui, il est courant d’opérer dans un environnement cloud distribué. Toutefois, l’utilisation d’une passerelle API dédiée comme point d’entrée unique pour contrôler la sécurité présente certaines limites, notamment des points uniques de défaillance et une dégradation des performances. Les passerelles API étant désormais un composant essentiel de l’infrastructure des API, il est devenu évident que la prolifération des API entraîne une multiplication des déploiements de passerelles API, conduisant à leur dispersion.
Les pare-feu d’applications web (WAF) ne protègent que partiellement les API
Les WAF modernes offrent une protection et une sécurité robustes pour les protocoles d’API, notamment GraphQL et gRPC, et constituent une solution temporaire face aux vulnérabilités logicielles critiques. Toutefois, ils n’offrent souvent pas l’observabilité des API nécessaire pour détecter les menaces avancées dans les architectures hybrides et multicloud. De nombreux WAF ne disposent pas de fonctionnalités de découverte dynamique des API, de détection automatisée et d’atténuation des menaces, de test, ni d’automatisation et d’application des spécifications des documents OpenAPI.
Maintenant que nous savons pourquoi les pirates informatiques raffolent des API, comment pouvons-nous les protéger ?
S’appuyer sur les réglementations et les normes pour obtenir du soutien en faveur des projets de protection des API
Les autorités de réglementation ont pris conscience des risques liés aux API et ont encouragé les entreprises à les atténuer dans l’ensemble de leurs environnements informatiques, y compris chez les tiers. Le département du Trésor des États-Unis et le Bureau de protection financière des consommateurs (CFPB) ont publié des directives strictes à l’intention des entités assujetties, leur demandant de protéger leurs API. Du point de vue des normes, l’exigence 6.3.2 de la norme PCI DSS v4 impose la sécurisation des API, tandis que le guide NIST 800-95 sur la sécurisation des services web, publié en 2007, ainsi que le document 800-24 sur les stratégies de sécurité pour les systèmes applicatifs fondés sur des microservices préconisent une gestion sécurisée des API.
Se concentrer sur l’architecture
Une architecture de sécurité des API doit prendre en compte l’intégration à une infrastructure informatique distribuée, comprenant des environnements multicloud, des périphéries régionales et différents niveaux de services. La solution doit pouvoir être déployée sur tout type de matériel, dans un environnement virtualisé, avec Docker, Kubernetes, etc. Elle doit permettre aux politiques de sécurité de suivre l’API dans l’ensemble de son écosystème. Voici un exemple d’architecture de référence pour sécuriser les API.
Réflexions finales
Les pirates informatiques ont compris depuis longtemps que les API souffrent des mêmes failles de sécurité que les applications web, notamment de mécanismes d’authentification et d’autorisation insuffisants. Ils sont devenus experts dans l’exploitation des vulnérabilités des API, le détournement de la logique métier et la création d’exploits zero-day leur permettant d’accéder aux systèmes informatiques des entreprises sans rencontrer beaucoup de résistance.
Les données personnelles appartiennent à l’individu, et non à une application ou à un fournisseur de services. L’économie numérique favorise le partage ouvert des données. Les API permettent l’accès à des données et services privés, publics, de partenaires et de tiers. Des technologies de protection de la vie privée doivent être appliquées aux API afin de respecter la réglementation relative à la confidentialité des données.
Le déploiement d’une solution de sécurité des API nécessite une intégration à l’infrastructure et des connecteurs, dont certains doivent être personnalisés pour assurer un déploiement adéquat dans un environnement informatique. La compréhension des subtilités du déploiement exige une planification architecturale. Le choix d’une solution immédiatement opérationnelle au sein de l’architecture informatique existante de l’entreprise permet de réduire le temps de déploiement.
Pour en savoir plus sur la protection contre les attaques visant les API, consultez mon récent rapport commandé par F5, « Guide d’évaluation des solutions de sécurité des API ». Ce rapport présente les principaux critères à prendre en compte lors du choix d’une solution de protection des API.
Par Tari Schreider, C|CISO, CRISC – Conseiller stratégique, Datos Insights
Notes de bas de page :
2 Rajesh Narayanan, Mike Wiley, Prolifération continue des API, F5, 4 novembre 2021
À propos de l’auteur
Articles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.