6 principes d'une stratégie holistique de sécurité des API

Alors que l’UX est le visage de vos applications, les API sont l’épine dorsale de votre organisation. Une erreur courante commise par de nombreuses entreprises est de considérer une API comme une simple couche d’interface au-dessus d’une application. La réalité est que les APLI servent de tissu conjonctif pour vos applications et écosystèmes tiers, qui sont de plus en plus distribués dans des architectures hybrides et multi-cloud. Bien que les API soient soumises à certains des mêmes risques que les applications Web (à savoir les exploitations de vulnérabilités, les abus de logique métier et les erreurs de configuration), il existe d’autres risques importants. Il s’agit notamment d’attaques qui contournent les contrôles d’authentification et d’autorisation faibles, l’inventaire inapproprié et l’utilisation dangereuse d’API tierces. Le risque est encore accru par la vitesse des activités numériques employées via des chaînes d’approvisionnement de logiciels complexes et des pipelines Cl/CD automatisés qui peuvent donner lieu à des API inconnues, non surveillées et non sécurisées. Il s’agit notamment des API fantômes et zombies qui sont inconnues des équipes de sécurité et/ou non maintenues par les équipes de développement. Dans cet article, nous explorerons 6 principes d’une approche holistique et complète de la sécurité des API.

1. Comprendre vos API et vos points de terminaison

Il existe une réelle probabilité que, si vous essayiez, vous ne puissiez pas identifier tous les points de terminaison d’API dans votre environnement pour le moment. Malheureusement, on ne peut pas en dire autant des acteurs malveillants. Si un point de terminaison existe, il peut être utilisé comme moyen d’entrer ou comme moyen de perturber des fonctions commerciales critiques.

De plus, l’exposition publique des API vous ouvre la possibilité de recevoir des requêtes d’une myriade de clients, de partenaires et d’applications. Cette exposition expose également votre organisation à des compromis, il est donc essentiel de comprendre et de surveiller les API. Il existe un certain nombre de contrôles des risques qui doivent être pris en compte pour protéger vos organisations contre les vulnérabilités et les menaces potentielles que les API peuvent exposer et qui pourraient entraîner des violations et des temps d'arrêt.

Pour tout défenseur, la découverte d’API est la première étape cruciale pour sécuriser les API. Cela va sans dire, mais rien n’est plus vrai que le dicton « on ne peut pas protéger ce qu’on ne peut pas voir ». Disposer d'un inventaire API complet constitue le point de départ pour développer ou améliorer toute posture de sécurité API, vous aidant à comprendre et à quantifier l'ensemble de votre surface de menace API. Il sert de base pour :

  • Visibilité: En cataloguant toutes les API disponibles, vous améliorez votre visibilité sur le paysage des menaces de vos API, y compris les vulnérabilités, l'exposition des données sensibles et les points de terminaison non autorisés ou oubliés.
  • Contrôle de version : L’établissement d’un inventaire facilite la gestion des versions : connaître l’historique et les différentes versions des API vous aide à supprimer les versions obsolètes ou vulnérables ou à les sécuriser correctement.
  • Surveillance: Un inventaire API centralisé et complet vous permet de mieux surveiller et enregistrer l'utilisation des API, ce qui facilite la détection et la réponse aux activités suspectes (anomalies) et aux événements de sécurité potentiels. De plus, en cas d'incident, un inventaire clair peut vous aider dans votre réponse.
  • Contrôles et politiques de sécurité cohérents : Disposer de cette visibilité, y compris d’un inventaire API complet, vous permet de mettre en œuvre efficacement des contrôles et des politiques sur l’ensemble de votre surface de menace API.

2. Trouver un équilibre entre innovation et sécurité

C'est une lutte classique. D’un côté, l’envie d’être audacieux, de repousser les limites, de faire ce que vos concurrents ne peuvent pas faire, est la pierre angulaire de toute entreprise prospère. Mais d’un autre côté, rester en sécurité ne va pas toujours de pair avec les dernières innovations.

La clé pour trouver l’équilibre est triple :

  • Concevez une stratégie de gouvernance API pour chaque type d'API afin de définir les contrôles de sécurité appropriés.
  • Mettre en œuvre des politiques de sécurité API qui peuvent être appliquées de manière cohérente partout où les API sont déployées.
  • Adaptez-vous aux menaces émergentes, aux comportements anormaux et aux utilisateurs malveillants qui tentent d'exploiter ou d'abuser des APl en utilisant l'IA pour réduire la charge des équipes de sécurité.

Selon votre secteur d’activité, les normes de conformité varient, certaines exigeant une sécurité plus stricte que d’autres. Quoi qu’il en soit, il est essentiel que votre posture de sécurité API soit suffisamment robuste pour faire face à un barrage de vecteurs de menaces.

3. Gérer les risques tout au long du cycle de développement

Les tests de sécurité des API ne sont pas une opération ponctuelle. Les tests avant, pendant et après le déploiement sont essentiels. En intégrant des tests à chaque étape du développement, vous bénéficiez de bien plus d’opportunités d’identifier les faiblesses et les vulnérabilités avant qu’une violation ne se produise. Et même si les outils de test spécifiques à la sécurité sont excellents, n’oubliez pas également la modélisation des cas d’utilisation de sécurité.

La sécurité doit s'exécuter dans le même cycle de vie continu que les applications elles-mêmes, ce qui signifie une intégration étroite au sein des pipelines CI/CD, de la fourniture de services et des écosystèmes de surveillance des événements.

4. Protections de couche du back-end au client final

Des clients externes à l’infrastructure interne et back-end, chaque partie de l’architecture doit avoir ses propres mesures de protection.

De plus, des pratiques de sécurité éprouvées s’appliquent toujours : architectures de refus par défaut, cryptage fort et accès au moindre privilège.

Lorsque vous réfléchissez à la protection au niveau de la couche API, il est utile de commencer par trier vos API en deux catégories : internes et externes. Les API internes sont plus simples à sécuriser puisque le fournisseur d'API peut coordonner les mesures de sécurité avec les équipes d'application. Pour les API externes, le calcul des risques est différent. Vous pouvez (et devez) implémenter des protections au niveau de l’API qui font trois choses :

  • Réduisez les risques de faille de sécurité grâce à des renseignements sur les menaces en temps réel et à des mécanismes de contrôle d'accès tels que des jetons de session renforcés.
  • Établir des modèles de trafic normaux et anormaux de référence.
  • Limitez l’utilisation des API et fournissez un contrôle granulaire de tous les agrégateurs approuvés et des intégrations tierces.

Au niveau de la production, le volume considérable de trafic dû à la prolifération des API nécessite l’utilisation de l’IA pour détecter les comportements anormaux et les utilisateurs malveillants.

5. Ayez les bonnes stratégies et les bons outils

Tout comme il n’existe pas d’aliment unique qui puisse nous nourrir pleinement, il n’existe pas de contrôle de sécurité unique qui puisse protéger complètement les API. Au lieu de cela, vous devez développer une stratégie qui utilise un écosystème complet d’outils dans le cadre d’une architecture de sécurité holistique des applications et des API. Cela inclut la détection et l'application en ligne vous donnant la possibilité de contrôler le comportement des API, de limiter les activités indésirables ou malveillantes et d'empêcher l'exposition des données sensibles.

Cela peut inclure une combinaison de capacités et d’outils, notamment :

  • Une passerelle API
  • Tests de sécurité des applications (SAST et DAST)
  • Un pare-feu d'application Web (WAF)
  • Prévention de la perte de données (DLP)
  • Gestion des robots
  • Atténuation des attaques DDoS

Les passerelles API offrent des capacités d'inventaire et de gestion robustes, mais n'offrent qu'une sécurité de base telle que la limitation du débit qui ne dissuadera pas les attaquants sophistiqués. De plus, la prolifération des API conduit à la prolifération des outils, y compris à la prolifération des passerelles API.

Les tests de sécurité des applications sont toujours essentiels, mais les méthodologies de déplacement vers la gauche pour une sécurité robuste des application pendant le développement doivent être complétées par des pratiques de protection vers la droite, à savoir la sécurisation des points de terminaison d'API en production. 

Les pare-feu application Web constituent une solution provisoire cruciale pour atténuer les exploits de vulnérabilité des application avec des signatures. Les API sont sensibles aux mêmes types d’attaques par injection que les applications qu’elles prennent en charge : elles tentent d’exécuter des commandes involontaires ou d’accéder à des données. Mais les WAF manquent généralement des capacités de découverte dynamique nécessaires pour détecter en continu les API et les problèmes inconnus (fantômes ou zombies), notamment les anomalies comportementales avec les API et les exploits potentiels de la logique métier.

Les capacités de détection de données sensibles et de prévention de la perte de données aident à protéger les API et les données auxquelles elles accèdent et qu'elles transmettent en détectant et en masquant les données critiques sensibles, notamment les informations personnelles identifiables (PII) et les informations financières. Cela permet aux organisations de créer des règles de protection des données pour limiter ou masquer la transmission de données et empêcher les points de terminaison d'API d'exposer complètement les données, contribuant ainsi à prévenir les fuites de données via les API.

La gestion des robots pour les API ne peut pas s'appuyer sur des contrôles de sécurité couramment utilisés tels que l'authentification multifacteur (MFA) et CAPTCHA, car le trafic API se fait généralement de machine à machine et il n'y a pas d'interaction humaine directe, sauf au sein des interfaces utilisateur des systèmes basés sur les API. 

L’atténuation DDoS traditionnelle se concentre sur les attaques réseau et volumétriques, tandis que les API peuvent être soumises à des attaques ciblées de couche 7 qui abusent de la logique métier critique. Le résultat final est le même : dégradation des performances et, potentiellement, temps d’arrêt.

La découverte dynamique d’API, l’application de schémas (sécurité positive), le contrôle d’accès et la détection et protection automatisées des anomalies basées sur l’apprentissage automatique sont devenues des capacités écosystémiques essentielles pour la défense des API. Il est important de disposer d’un ou de plusieurs outils maîtrisant les protocoles API et permettant d’appliquer un comportement API approprié et de créer des règles de protection API. Les organisations doivent pouvoir créer des règles personnalisées qui régissent spécifiquement les API et le comportement des API. Cela inclut les contrôles de liste d'autorisation et de refus, la limitation du débit, le filtrage géo-IP et la création de règles personnalisées pour agir sur les requêtes API, y compris le masquage des données sensibles et les critères de contrainte de correspondance et de demande pour des points de terminaison ou des groupes d'API spécifiques.

6. Sécurité hybride et multi-cloud

La prolifération des API entraîne une prolifération architecturale intenable dans les environnements hybrides et multicloud. Encore une fois, la prolifération des API a conduit à la prolifération des passerelles API, car de nombreux outils de sécurité ne peuvent pas fournir une sécurité cohérente sur plusieurs architectures telles que le centre de données, le cloud privé/public et la périphérie. La visibilité et le contrôle du trafic API sur l’ensemble de l’écosystème numérique sont impératifs pour atténuer la prochaine vulnérabilité critique et pour éviter les erreurs de configuration qui peuvent se produire lorsque les points de terminaison sont répartis sur différents fournisseurs de cloud.

Des API sécurisées partout où elles se trouvent

Les API sont partout : dans le centre de données, dans les clouds, en périphérie, et sont interconnectées derrière des applications Web, des applications mobiles et des intégrations tierces associées. Les API doivent être protégées où qu’elles se trouvent et la sécurité ne doit jamais dormir. Assurez-vous plutôt que votre stratégie inclut des solutions qui défendent en permanence la logique métier critique derrière les API et sécurisent systématiquement votre structure numérique connectée aux API, afin que vous puissiez rationaliser vos opérations et innover en toute confiance.

Ressources