Les API ont souvent accès à des données sensibles, ce qui rend les organisations essentielles à connaître chaque API utilisée. Pourtant, de nombreuses entreprises luttent avec des API fantômes et des paramètres sans papiers. Vous ne pouvez pas protéger ce que vous ne pouvez pas voir, rendre la visibilité complète de l’API fondamentale pour un programme de sécurité.
La découverte efficace de l’API nécessite une approche systématique qui s’étend sur l’ensemble du cycle de vie de développement logiciel (SDLC). Voici sept équipes de sécurité des meilleures pratiques de découverte API essentielles devraient mettre en œuvre, de l’analyse du code source à la surveillance continue.
1. Conduisez l’analyse du code source et la numérisation du référentiel
La découverte complète de l’API commence à la source. Les outils de test de sécurité des applications statiques modernes numérisent automatiquement les référentiels de code pour identifier les définitions, les points de terminaison et les configurations de l’API telles que les définitions OpenAPI.
Portez une attention particulière aux fichiers de configuration, aux variables d’environnement et aux scripts de déploiement qui peuvent référencer les API externes ou définir de nouveaux points de terminaison. De nombreuses organisations découvrent les API oubliées qui se cachent dans les bases de code héritées ou les branches expérimentales.
Les outils à considérer incluent les éléments suivants:
- L’API Discovery de Stackhawk se connecte directement aux référentiels de code, en utilisant une approche interne pour découvrir les API à partir du code source avec la génération de schéma automatisée.
- Semgrep fournit une analyse statique rapide dans la plupart des langages de programmation pour trouver des modèles d’API dans le code, ce qui en fait une excellente option open source pour identifier les déclarations de point de terminaison de repos, les schémas GraphQL et l’utilisation du cadre API.
2. Effectuer l’analyse de la passerelle et de la plate-forme de gestion de l’API
Les passerelles API servent de points d’étranglement centralisés pour le trafic API, ce qui en fait de précieuses sources de vérité pour découvrir des API actives dans une organisation. Les passerelles telles que les Apigee maintiennent des registres complets des API déployés, y compris les métadonnées sur les points finaux, les versions, les modèles de trafic et l’analyse d’utilisation.
La découverte d’API basée sur la passerelle offre les avantages suivants:
- Inventaire API complet à partir des processus d’enregistrement centralisés.
- Analyse du trafic montrant les modèles réels d’utilisation et de consommation d’API.
- Suivi de la version entre différentes itérations et déploiements API.
- Métriques de performance qui indiquent quelles API sont activement utilisées par rapport à Dormant.
Les stocks de passerelle ont cependant des limites. Toutes les API ne parcourent pas les passerelles – par exemple, les communications de microservice internes, les points de terminaison hérités et les API de développement contournent souvent entièrement cette infrastructure. Utilisez les données de passerelle comme base d’inventaire primaire, mais complétez avec d’autres méthodes de découverte pour capturer le paysage API complet.
3. Audit des intégrations tierces
Les applications modernes dépendent fortement des services externes, nécessitant des audits systématiques pour comprendre la portée complète des dépendances de l’API. Passez en revue toutes les intégrations SaaS et les API des fournisseurs que les applications consomment, examinant les méthodes d’authentification, les accords de partage de données et les autorisations d’accès accordées aux services externes.
Documentez tous les appels API sortants que les applications effectuent, y compris les types de données échangées et l’objectif commercial de chaque intégration. Ce processus d’audit révèle souvent des relations de partage de données inattendues ou des modèles d’intégration sans sécurité non capturés dans la documentation officielle de l’API.
Portez une attention particulière aux dépendances des services cloud et à leurs points de terminaison API associés, car ces connexions contournent fréquemment des outils de surveillance de réseau traditionnels. De nombreuses organisations ne découvrent les dépendances critiques des API que lorsque les services externes subissent des pannes ou des incidents de sécurité.
4. Mettre en œuvre la gestion continue de la surface d’attaque
Déployez des outils automatisés qui scannent en continu l’infrastructure orientée externe pour les API exposées. Les outils de gestion de la surface d’attaque moderne utilisent des techniques telles que l’énumération du répertoire, la découverte du sous-domaine et la numérisation des ports pour identifier les points de terminaison qui auraient pu être déployés sans examen de sécurité approprié.
Se concentrer sur les chemins d’API communs (* / api / *, * / rest / *, * / v1 / *), Méthodes HTTP et modèles de réponse qui indiquent les interfaces API. Les outils avancés peuvent faire la différence entre le contenu Web statique et les points de terminaison dynamiques de l’API, aidant à identifier les API non capturées via d’autres méthodes de découverte.
5. Utiliser l’analyse du trafic réseau et l’intégration SIEM
Les plates-formes SIEM excellent à ingérer et à analyser les données de trafic réseau pour révéler les modèles d’utilisation de l’API, même s’ils ne fournissent pas de capacités de découverte d’API natives. Ces plates-formes traitent les journaux de flux de réseau, les données de trafic HTTP et les modèles de communication pour identifier les points de terminaison API potentiels à travers votre infrastructure.
Configurez les plates-formes SIEM pour effectuer ce qui suit:
- Analyser les journaux de trafic HTTP pour les modèles de point de terminaison API et les structures d’URL de type repos.
- Surveillez les requêtes DNS vers les domaines API (API., REST., * .AMAZONAWS.COM, * .googleapis.com).
- Suivez l’utilisation des ports et l’analyse du protocole pour les communications API non standard.
- Corréler les modèles de trafic avec les délais de déploiement des applications pour identifier les nouvelles API.
Microsoft Sentinel démontre bien cette approche, l’intégration avec l’analyse du trafic Azure Network Watcher pour traiter les journaux de flux de sécurité du réseau et identifier les modèles de trafic HTTP / HTTPS et les dépendances de connexion.
D’autres plates-formes SIEM majeures – Splunk, IBM Qradar et la sécurité élastique – offrent des capacités d’analyse de réseau similaires, permettant aux équipes de sécurité de créer des règles de corrélation personnalisées qui signalent les modèles de trafic de type API et les comportements de communication suspects.
6. Configurer les outils EDR pour la découverte d’exécution
Les outils de détection et de réponse (EDR) (EDR) fournissent des informations d’exécution puissantes sur l’activité de l’API grâce à une surveillance complète des points de terminaison. Par exemple, Crowdsstrike Falcon offre une visibilité en temps réel dans les activités de point de terminaison tout en suivant les connexions du réseau, les demandes DNS et les modèles de communication au niveau du processus.
Les capacités de découverte de l’API EDR incluent les éléments suivants:
- Surveillance des processus. Suivez les applications en train de passer des appels d’API en analysant l’exécution du processus et les arguments de ligne de commande.
- Analyse du réseau. Surveillez les connexions HTTP / HTTPS, les requêtes DNS vers les domaines API et l’utilisation inhabituelle du port.
- Détection comportementale. Identifier les modèles indiquant l’utilisation non autorisée d’API ou les abus d’API.
- Découverte en temps réel. Détecter de nouvelles communications API telles qu’elles se produisent dans toute l’organisation.
Les outils EDR excellent dans l’identification des API qui ne s’activent que dans des conditions spécifiques ou pendant les processus métier, ce qui les rend essentiels pour découvrir l’utilisation conditionnelle ou basée sur les API que l’analyse statique pourrait manquer.
7. Effectuer une surveillance et une intégration continues
La découverte de l’API n’est pas une activité unique – elle nécessite une intégration continue sur plusieurs méthodes de découverte.
Établir des processus automatisés qui combinent ce qui suit:
- Code source Analyse intégrée dans des pipelines d’intégration continue / de livraison continue.
- API Gateway Analytics avec mises à jour automatisées d’inventaire.
- Analyse du trafic réseau via les plates-formes SIEM.
- Surveillance EDR pour la découverte de l’API d’exécution.
- Revues d’intégration des tiers régulières.
Créez des tableaux de bord qui consolident les résultats à partir de toutes les méthodes de découverte, identifiez les lacunes entre les différents inventaires et les API nouvellement découvertes pour l’évaluation de la sécurité. Cette approche multicouche assure une visibilité complète à mesure que le paysage API d’une organisation évolue.
En mettant en œuvre ces pratiques de découverte dans l’ensemble du SDLC, les équipes de sécurité peuvent maintenir une visibilité approfondie de l’API et assurer une protection adéquate pour ces points d’intégration critiques.
Comment mettre en œuvre les meilleures pratiques de découverte d’API
La mise en œuvre de ces meilleures pratiques en tant que programme de sécurité intégré plutôt que comme des activités isolées est essentielle à la réussite de la découverte d’API.
Commencez par l’analyse du code source pour établir l’inventaire de l’API de base de l’organisation, puis superposez la surveillance de la passerelle, l’analyse du trafic réseau et l’EDR d’exécution pour capturer le spectre complet de l’utilisation d’API à travers le réseau.
N’oubliez pas que les API sont dynamiques – de nouveaux points de terminaison émergent à travers les cycles de développement, les API héritées sont obsolètes et que les API fantômes apparaissent lorsque les équipes contournent les processus officiels.
Colin Domoney est un consultant en sécurité des logiciels qui évangélise DevSecops et aide les développeurs à sécuriser leur logiciel. Il a auparavant travaillé pour Veracode et 42Crunch et a écrit un livre sur la sécurité de l’API. Il est actuellement CTO et co-fondateur, et un consultant en sécurité indépendant.
