La sécurité des API dans un monde Zero Trust
Aujourd'hui, plus que jamais, le concept traditionnel de périmètre de sécurité est en train de changer. Cela conduit de nombreuses organisations à adopter les principes de l' architecture Zero Trust (ZTA), dont beaucoup se concentrent sur l'évaluation de la confiance des utilisateurs et la gestion de l'accès aux réseaux, systèmes et données sensibles par le biais d'interfaces utilisateur primaires.
Cependant, de nombreuses initiatives ZTA négligent la prévalence croissante de l'accès basé sur l'interface de programmation d'applications (API) aux fonctionnalités et données d'application sensibles, car elles conçoivent des moyens d'évaluer la confiance sur une base continue.
Dans cet article de blog, nous allons mettre en évidence certains points d'intersection entre les API et la ZTA. Nous présenterons également quelques mesures initiales que vous pouvez prendre pour étendre votre ZTA afin d'inclure les API.
Qu'est-ce que le Zero Trust ?
En 2010, Forrester Research a présenté les principes de la ZTA au grand public dans le domaine de la sécurité des entreprises. La conception de la ZTA a été considérablement améliorée depuis lors, à la fois par Forrester et par de nombreux autres acteurs du secteur, dont le National Institute of Standards and Technology (Institut national des normes et des technologies) dans la publication spéciale NIST 800-207.
En termes simples, Zero Trust suppose qu'aucun utilisateur ou terminal ne peut être approuvé par défaut. Au contraire, l'un ou l'autre doit faire l'objet d'une évaluation chaque fois que l'on tente d'accéder à une ressource sensible, et d'une évaluation continue par la suite.
Pendant de nombreuses années, la ZTA a été davantage un sujet de discussion qu'une mesure prise par les organisations dans le monde réel. Mais la migration mondiale des travailleurs vers leur pays d'origine stimulée par la pandémie de COVID-19 a incité de nombreuses organisations à mettre en place des plans concrets pour adopter les principes de la ZTA.
Quel est le point de rencontre entre les API et l'architecture Zero Trust ?
La publication NIST SP 200-807 décrit sept principes de base de ZTA. Si ces principes vont bien au-delà de l'accès aux fonctionnalités et aux données des applications via les API, ils ont également des points d'intersection très clairs avec la stratégie d'API d'une entreprise.
Les 7 principes de base du Zero Trust
Le tableau suivant reprend les sept principes de base de la ZTA tels qu'ils sont définis dans la publication NIST SP 200-807, ainsi que des recommandations visant à aligner les pratiques de sécurité des API de votre organisation sur ces principes.
Les 7 principes de base de l'architecture Zero Trust |
Implications pour la sécurité des API |
|---|---|
1. « Toutes les sources de données et tous les services informatiques sont considérés comme des ressources. » |
Un grand nombre d'applications et de sources de données entrant dans le champ d'application de la ZTA sont accessibles via des API, en plus des interfaces utilisateur directes. Par conséquent, votre modèle d'application des règles et d'évaluation de la ZTA doit inclure des interfaces API. |
2. « Toutes les communications sont sécurisées quel que soit l'emplacement du réseau. » |
Même si les API ne sont destinées qu'à un usage interne au sein d'un centre de données privé ou d'un environnement cloud, vous devez mettre en œuvre le chiffrement, l'authentification et l'autorisation comme s'ils étaient orientés vers l'extérieur afin de garantir la confidentialité et l'intégrité des données. |
3. « L'accès aux ressources individuelles de l'entreprise est accordé est accordé pour chaque session. » |
Vous devez évaluer la confiance avant d'accorder l'accès à une ressource API. L'accès doit être accordé avec le moins de privilèges possible. Utilisez l'analyse comportementale pour surveiller l'utilisation de l'API et évaluer en permanence la confiance. |
4. « L'accès aux ressources est déterminé par une règle dynamique (y compris l'état observable de l'identité du client, de l'application/du service et de la ressource requérante) et peut inclure d'autres attributs comportementaux et environnementaux. » |
Pour appliquer la ZTA aux API, vous devez être en mesure d'identifier les entités concernées, de déduire le contexte commercial et d'utiliser l'analyse comportementale pour identifier les écarts par rapport aux schémas d'utilisation normaux. Un attribut comportemental à noter est le déni de service par le biais d'appels API rapides. C'est pourquoi l'absence de limitation du débit API est catégorisée comme accès illimité aux flux d'activité sensibles dans la liste des 10 principaux risques pour la sécurité des API dressée par l'Open Worldwide Application Security Project (OWASP). Alors que NIST indique que : « Ces règles et attributs sont basés sur les besoins du processus métier et sur le niveau de risque acceptable ». |
5. « L'entreprise surveille et mesure l'intégrité et la posture de sécurité de toutes les ressources détenues et associées. » |
Cette exigence est basée sur le concept Continuous Diagnostics and Mitigation (CDM) défini par la Cybersecurity and Infrastructure Security Agency (CISA). Le CDM comprend des éléments tels que la gestion des ressources, la gestion des failles de sécurité et la gestion de la configuration/des paramètres. Tout comme les ressources physiques, les API doivent être découvertes, classifiées et suivies en permanence. De même, les évaluations de vulnérabilité en cours doivent aller au-delà des vulnérabilités traditionnelles en matière de sécurité des réseaux et de sécurité des applications pour inclure les éventuelles vulnérabilités basées sur les API. |
6. « L'authentification et l'autorisation de toutes les ressources sont dynamiques et strictement appliquées avant que l'accès ne soit autorisé. » |
Ce concept peut et doit être étendu aux API. Les organisations qui adoptent la ZTA doivent surveiller en permanence l'utilisation des API et utiliser une technologie automatisée (par exemple, bloquer, limiter, révoquer les identifiants) pour réagir lorsqu'un comportement anormal ou abusif est détecté dans le trafic API authentifié et autorisé. |
7. « L'entreprise recueille autant d'informations que possible sur l'état actuel des ressources, de l'infrastructure réseau et des communications, et les utilise pour améliorer sa posture de sécurité. » |
Pour être un élément efficace d'une ZTA, les mesures de sécurité de votre API doivent être capables d'enregistrer des données sur de longues périodes. Idéalement, le temps doit être suffisant pour détecter les abus d'API subtils. Ce niveau de détail est nécessaire pour effectuer des analyses comportementales en vue d'une évaluation des risques en temps réel et d'une amélioration continue de la conception de la ZTA. Il s'agit notamment de fournir aux détecteurs de menaces un accès à la demande aux API et aux données sur les menaces, afin qu'ils puissent identifier les améliorations possibles de la règle. Des points d'intégration similaires doivent également être créés avec les outils de développement et d'exploitation et les flux de travail utilisés par vos équipes. |
Suivez ces sept étapes initiales pour étendre votre ZTA afin d'inclure des API
L'un des plus grands défis pour la plupart des organisations qui souhaitent adopter la ZTA est de décider par où commencer. Dans le cas de la sécurité des API, la mise en œuvre des capacités suivantes aura un effet immédiat sur votre posture de sécurité tout en vous donnant les bases nécessaires pour intégrer la sécurité des API dans vos futurs plans ZTA.
Mettre en œuvre la découverte continue des API et maintenir un inventaire précis de toutes les API et des ressources accessibles par API.
Au fur et à mesure que des API non autorisées sont découvertes, s'assurer que des flux de travail systématiques soient mis en place pour les gérer ou les éliminer.
Mettre en œuvre une authentification et une autorisation solides des API, qu'elles soient publiques ou privées.
Identifier de manière proactive les vulnérabilités de l'API en tant que discipline permanente, en commençant par les dix principaux risques pour la sécurité des API selon l'OWASP
Développer les capacités d'analyse de vastes ensembles de données sur le trafic des API afin de déterminer une base de référence pour le comportement normal et de procéder à la détection des anomalies
Alimenter les moteurs de règles de la ZTA en informations sur les menaces et la confiance au fur et à mesure de leur mise en œuvre par le biais d'intégrations d'API
Lancer des réponses automatisées lorsque des vulnérabilités, des menaces et des abus d'API sont révélés
La première étape
Intégrez la sécurité des API dans votre ZTA. Découvrez les possibilités avec API Security d'Akamai.
