6 principes pour une stratégie globale de sécurité des API

1. Comprenez vos API et vos points de terminaison

Il est fort probable que, même en essayant, vous ne puissiez pas identifier à l’heure actuelle tous les points de terminaison d’API présents dans votre environnement. Malheureusement, il n’en va peut-être pas de même pour les acteurs malveillants. Tout point de terminaison existant peut servir de porte d’entrée ou être exploité pour perturber des fonctions métier critiques.

En outre, l’exposition publique des API vous amène à recevoir des requêtes provenant d’une multitude de clients, de partenaires et d’applications. Elle expose également votre organisation à des compromissions. Il est donc essentiel de bien comprendre et surveiller les API. Plusieurs mesures de maîtrise des risques doivent être envisagées afin de protéger votre organisation contre les vulnérabilités et les menaces potentielles liées aux API, susceptibles d’entraîner des failles de sécurité et des interruptions de service.

Pour tout défenseur, la découverte des API constitue la première étape essentielle de leur sécurisation. Cela va peut-être sans dire, mais rien n’est plus vrai que l’adage « on ne peut pas protéger ce que l’on ne voit pas ». Disposer d’un inventaire complet des API constitue le point de départ pour élaborer ou améliorer toute stratégie de sécurité des API, en vous aidant à comprendre et à quantifier l’ensemble de votre surface d’attaque liée aux API. Cet inventaire sert de référence pour :

• Visibilité : En répertoriant toutes les API disponibles, vous bénéficiez d’une meilleure visibilité sur les menaces qui pèsent sur vos API, notamment les vulnérabilités, l’exposition de données sensibles et les points de terminaison non autorisés ou oubliés.
• Gestion des versions : Établir un inventaire facilite la gestion des versions : connaître l’historique et les différentes versions des API vous permet de retirer les versions obsolètes ou vulnérables, ou de les sécuriser correctement.
• Surveillance : Un inventaire centralisé et complet des API vous permet de mieux surveiller et consigner leur utilisation, ce qui facilite la détection des activités suspectes (anomalies) et des incidents de sécurité potentiels, ainsi que la réponse à ceux-ci. De plus, en cas d’incident, un inventaire clair peut faciliter votre intervention.
• Contrôles et politiques de sécurité cohérents : Cette visibilité, qui inclut un inventaire complet des API, vous permet de mettre en œuvre efficacement des contrôles et des politiques sur l’ensemble de votre surface d’attaque liée aux API.

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

C’est un dilemme classique. D’un côté, l’envie d’oser, de repousser les limites et de faire ce dont vos concurrents sont incapables est l’une des clés de la réussite de toute entreprise. Mais de l’autre, les impératifs de sécurité ne font pas toujours bon ménage avec les innovations les plus récentes.

Pour trouver le juste équilibre, trois éléments sont essentiels :

• Concevez une stratégie de gouvernance des API adaptée à chaque type d’API afin de mettre en place les contrôles de sécurité appropriés.
• Mettez en œuvre des politiques de sécurité des API pouvant ê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 les API ou d’en abuser, en utilisant l’IA pour alléger la charge de travail des équipes de sécurité.

Selon votre secteur d’activité, les normes de conformité varient, certaines imposant des mesures de sécurité plus strictes que d’autres. Quoi qu’il en soit, il est essentiel que votre dispositif de sécurité des API soit suffisamment robuste pour faire face à une multitude de vecteurs de menace.

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

Les tests de sécurité des API ne sont pas une opération ponctuelle. Il est essentiel d’effectuer des tests avant, pendant et après le déploiement. En intégrant les tests à chaque étape du développement, vous multipliez les occasions de détecter les faiblesses et les vulnérabilités avant qu’une faille de sécurité ne survienne. Et si les outils de test dédiés à la sécurité sont très utiles, n’oubliez pas non plus la modélisation des cas d’utilisation liés à la sécurité.

La sécurité doit s’inscrire dans le même cycle de vie continu que les applications elles-mêmes, ce qui implique une intégration étroite aux pipelines CI/CD, au provisionnement des services et aux écosystèmes de surveillance des événements.

4. Superposez les protections du back-end jusqu’au client final

Des clients externes à l’infrastructure interne côté back-end, chaque composant de l’architecture doit disposer de ses propres mesures de protection.

En outre, les pratiques de sécurité éprouvées restent de mise : architectures avec refus par défaut, chiffrement robuste et accès selon le principe du moindre privilège.

Lorsque vous réfléchissez à la protection au niveau de la couche API, il est utile de commencer par classer vos API en deux catégories : internes et externes. Les API internes sont plus simples à sécuriser, car le fournisseur d’API peut coordonner les mesures de sécurité avec les équipes chargées des applications. Pour les API externes, l’évaluation des risques est différente. Vous pouvez (et devriez) mettre en œuvre des protections au niveau des API qui remplissent trois fonctions :

• Réduisez les possibilités de faille de sécurité grâce à des renseignements en temps réel sur les menaces et à des mécanismes de contrôle d’accès tels que des jetons de session renforcés.
• Établissez des modèles de référence pour le trafic normal et anormal.
• Restreindre l’utilisation des API et assurer un contrôle granulaire de tous les agrégateurs et intégrations tierces approuvés.

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

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

Tout comme aucun aliment ne peut à lui seul couvrir tous nos besoins nutritionnels, aucun contrôle de sécurité ne peut protéger entièrement les API. Il est donc nécessaire d’élaborer une stratégie reposant sur un écosystème complet d’outils, intégré à une architecture globale de sécurité des applications et des API. Celle-ci doit notamment inclure des mécanismes de détection et d’application des règles en ligne, afin de contrôler le comportement des API, de limiter les activités indésirables ou malveillantes et d’empêcher l’exposition de données sensibles.

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

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

Les passerelles d’API offrent de solides fonctionnalités d’inventaire et de gestion, mais seulement des mesures de sécurité élémentaires, telles que la limitation du débit, qui ne dissuaderont pas les attaquants expérimentés. En outre, la prolifération des API entraîne une multiplication des outils, notamment des passerelles d’API.

Les tests de sécurité des applications sont toujours essentiels, mais les méthodologies « shift-left », qui visent à garantir une sécurité robuste des applications pendant leur développement, doivent être complétées par des pratiques « shield-right », notamment la sécurisation des points de terminaison d’API en production.

Les pare-feu d’applications web constituent une mesure palliative essentielle pour limiter, à l’aide de signatures, l’exploitation des vulnérabilités applicatives. Les API sont exposées aux mêmes types d’attaques par injection que les applications qu’elles prennent en charge, lesquelles visent à exécuter des commandes non prévues ou à accéder à des données. Toutefois, les WAF ne disposent généralement pas des capacités de découverte dynamique nécessaires pour détecter en continu les API inconnues (fantômes ou zombies), ainsi que les problèmes tels que les anomalies de comportement des API et les tentatives potentielles d’exploitation de la logique métier.

Détection des données sensibles et prévention des pertes de données : ces fonctionnalités contribuent à protéger les API ainsi que les données auxquelles elles accèdent et qu’elles transmettent, en détectant et en masquant les données sensibles critiques, notamment les informations personnelles identifiables (PII) et les informations financières. Elles permettent aux organisations de créer des règles de protection des données afin de limiter ou de masquer leur transmission, et d’empêcher les points de terminaison d’API d’exposer des données, contribuant ainsi à prévenir les fuites de données via les API.

Gestion des bots 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 les CAPTCHA, car le trafic des API s’effectue généralement de machine à machine, sans interaction humaine directe, sauf au sein des interfaces utilisateur des systèmes basés sur des API.

L’atténuation traditionnelle des attaques DDoS se concentre sur les attaques réseau et volumétriques, tandis que les API peuvent faire l’objet d’attaques ciblées de couche 7 qui exploitent une logique métier critique. Le résultat final est le même : une dégradation des performances et, potentiellement, une interruption de service.

La découverte dynamique des API, l’application des schémas (sécurité positive), le contrôle des accès, ainsi que la détection automatisée des anomalies et les protections fondées sur l’apprentissage automatique sont devenus des capacités essentielles de l’écosystème pour protéger les API. Il est important de disposer d’un ou de plusieurs outils maîtrisant les protocoles d’API et permettant d’imposer un comportement approprié des API ainsi que de créer des règles de protection des API. Les organisations doivent pouvoir créer des règles personnalisées régissant spécifiquement les API et leur comportement. Cela comprend la gestion des listes d’autorisation et de refus, la limitation du débit, le filtrage géographique par adresse IP et la création de règles personnalisées pour traiter les requêtes API, notamment en masquant les données sensibles et en définissant des critères de correspondance et de contraintes applicables aux requêtes pour des points de terminaison ou des groupes d’API spécifiques.

6. Sécurité hybride et multicloud

La prolifération des API entraîne une dispersion architecturale intenable dans les environnements hybrides et multicloud. Là encore, la multiplication des API a conduit à celle des passerelles d’API, car de nombreux outils de sécurité ne peuvent pas assurer une protection cohérente sur plusieurs architectures, telles que les centres de données, les clouds privés et publics, ainsi que l’edge computing. La visibilité et le contrôle du trafic des API dans l’ensemble de l’écosystème numérique sont indispensables pour atténuer la prochaine vulnérabilité critique et prévenir les erreurs de configuration susceptibles de se produire lorsque les points de terminaison sont répartis entre différents fournisseurs de cloud.

Sécurisez les API où qu’elles se trouvent

Les API sont partout — dans les centres de données, dans les différents clouds et à la périphérie du réseau — et sont interconnectées derrière des applications web, des applications mobiles et les intégrations tierces associées. Elles doivent être protégées où qu’elles se trouvent, et la sécurité ne doit jamais connaître de répit. Veillez donc à ce que votre stratégie intègre des solutions qui protègent en permanence la logique métier critique sous-jacente aux API et sécurisent de manière cohérente votre infrastructure numérique connectée par API, afin de rationaliser vos opérations et d’innover en toute confiance.