Comment sécuriser les API

Mehdi Medjaoui, économiste chez CA Technologies, distingue trois propositions de valeur grâce aux API :

• L’entreprise étendue, qui utilise des API pour élargir son champ d’activité, en créant de nouveaux segments et marchés ou de nouvelles offres de produits et services pour développer son portefeuille client. Il s’agit souvent de la première étape pour toute organisation commençant à explorer les opportunités offertes par les API.
• L’entreprise flexible, dont les API favorisent l’émergence : l’organisation peut ainsi fonctionner et se développer sans qu’il soit nécessaire de recruter un grand nombre de nouveaux membres.
• L’entreprise exponentielle : similaire au concept d’entreprise élastique, l’entreprise exponentielle est cependant davantage orientée client. L’intérêt d’une API réside dans sa capacité à tout gérer à l’aide d’algorithmes, sans supervision humaine. Pour les entreprises, le résultat est un coût marginal d’acquisition de nouveaux clients égal à zéro. Uber en est un excellent exemple : l’API traite les demandes de courses entre les passagers et les conducteurs, sans que personne n’ait à participer au processus.

Mais qui dit ouverture du système d’information dit risques, qu’il faut maîtriser. En effet, dans la mesure où les API, positionnées dans un système Back End, permettent l’interfaçage à des sources de données ou des applications, en principe génératrices de valeur pour les utilisateurs, la maîtrise de cet écosystème passe, en premier lieu, par une phase d’identification de ces ressources au sein de l’entreprise, mais aussi de leurs utilisateurs, en se posant deux questions :

• Quelles sont les ressources auxquelles les utilisateurs peuvent et souhaitent accéder ?
• Quelle est l’identité de chaque utilisateur (personne physique ou morale, compte applicatif…) et avec quels outils souhaite-t-il accéder aux ressources (application, portail Web, client lourd, poste de travail, appareil mobile…) ?

Organiser les droits d’accès

Plusieurs facteurs contribuent à multiplier les API, notamment la transformation numérique, les besoins de partage des données, les usages de mobilité, les exigences de l’omnicanal, le poids des écosystèmes d’applications, la nécessité du temps réel, la volonté de monétiser les données et de nouvelles offres qui sont des agrégations d’autres offres proposées par des tiers, de manière à améliorer l’expérience utilisateur… « Les API constituent une architecture enrichie du système d’information ; la mise en place d’API introduit le plus souvent de nouveaux composants redondés dans l’architecture (plateforme de management des API, solution de gouvernance, de monitoring des appels…) et sollicite ceux déjà en place et en particulier les firewalls, les Load Balancers, pour équilibrer la charge sur différentes instances », souligne Philippe Provost, RSSI membre du Cesin.

« C’est en regroupant les identifications utilisateurs/ressources dans un point central, que l’on pourra organiser une politique de gestion de droits d’accès aux ressources, pour garantir la sécurité de l’ensemble. Il devient ainsi possible de définir des autorisations à certains utilisateurs, depuis certains types d’environnements et d’outils autorisés, selon une période temporelle définie si nécessaire, pour qu’ils puissent accéder à certains types de ressources, et pas à d’autres », souligne Jérémie Devillard, co-fondateur et directeur technique chez Moskitos.

Bien qu’un nombre illimité de services puissent être mis à disposition au sein de la plateforme d’API, chacun susceptible de disposer d’une politique de sécurité différente, il n’en demeure pas moins qu’un seul sera visible par les applications consommatrices de données.

Cela va permettre d’instaurer une politique de gouvernance commune et donc de proposer :

• Une authentification unifiée (de type OpenId, SamI…) pour pouvoir récupérer, de manière homogène, les rôles et droits des utilisateurs dans l’environnement de l’entreprise.
• Une gestion des droits d’accès basée sur une catégorisation des API Back End selon leur niveau de confidentialité (avec une nomenclature de type C1 à Cn), correspondant au niveau d’accréditation nécessaire pour en faciliter l’accessibilité aux utilisateurs.

« Au sein de ces droits d’accès, il va alors être possible de définir des capacités d’accès pour les utilisateurs et leurs applications, selon des engagements de services (SLA) contractualisés selon des plans de type Gold, Silver, etc., établissant un niveau de consommation limité de la ressource recherchée. Par exemple, dans le cadre de son plan Silver, un utilisateur aura le droit d’accéder à une certaine API 50 fois par jour, uniquement en semaine de 7 heures à 20 heures », explique Jérémie Devillard.

« L’API est un moyen permettant d’exposer auprès de tiers des méthodes ou fonctions, données et/ou traitements. Ces interfaces doivent donc être conçues comme évolutives, réutilisables, versionnées et sécurisées », souligne Philippe Provost. Plus précisément, selon ce dernier, « dans la mesure où une API permet d’offrir un certain découplage entre l’implémentation technique (et ses occurrences) et le service publié utilisé par les tiers, exposer des API consiste à proposer des mécanismes à des tierces parties, via une passerelle contrôlée et sécurisée selon un modèle B2B, B2C ou B2B2C. »

 

De nouveaux risques pour les données

Plusieurs risques sont induits par les API :

• Les applications et les données sont par définition plus exposées.
• Un ensemble riche (et souvent hétérogène) de frameworks, librairies et produits introduit de nouvelles vulnérabilités.
• La conception des API n’intègre pas toujours suffisamment la sécurité.
• Les API et les données qu’elles véhiculent sont attractives pour les acteurs malveillants.
• L’urbanisation et la gouvernance des API ne sont pas toujours bien conçues.
• Les implications de processus externes non ou mal maîtrisés par des appels à des API en cascade, font courir des risques systémiques potentiels nouveaux.

« Le processus d’authentification de l’appelant est un facteur souvent déterminant dans la sécurisation du service et il faut également considérer que les attaques puissent aussi venir de l’intranet, les contrôles d’accès doivent donc être positionnés sur tous les niveaux de l’infrastructure, selon le concept du Zero Trust », précise Philippe Provost.

Celui-ci conseille également de réaliser « un suivi permanent et une analyse des messages échangés, pour détecter toute anomalie pouvant entraîner des exfiltrations de données ou l’injection de malware en mesure de compromettre la sécurité d’une partie de l’infrastructure. »

Pour Paolo Malinverno, analyste chez Gartner, « les attaquants ciblent ce qui a le plus de valeur, en l’occurrence les données, et les API constituent un vecteur pour y accéder. » La sécurité est d’ailleurs le premier challenge que les entreprises mettent en exergue (voir graphique ci-dessus), devant le manque de compétences et de standards API. Gartner suggère trois mesures : inventorier les API existantes (y compris celles provenant de tiers) et celles en cours d’implémentation, observer l’usage qui est ou sera fait et définir un comportement normal type, et, en fonction du contexte, adapter la politique de sécurité en incluant l’authentification, la protection des données et contre les attaques.

Sécuriser les API : les bonnes pratiques
Domaine	Recommandations
Conception des API	Prendre conscience que les APIs donnent accès aux actifs immatériels de l’entreprise S’assurer que les APIs provenant d’une application ne dévoilent rien de l’infrastructure ou du datacenter Limiter la connaissance des API aux seuls acteurs légitimes, dans le cas d’un modèle B2B Qualifier et mettre en œuvre les mécanismes d’authentification les plus sûrs au regard des contraintes du service proposé : étudier la possibilité de proposer deux niveaux d’authentification Identifier ce qui est une donnée ou un traitement sensible Garantir qu’une donnée ou un contexte sensible ne soit jamais présenté dans l’url S’assurer que les compétences soient bien présentes dans l’entreprise et que le niveau d’expertise soit à la hauteur des enjeux Former toutes les parties prenantes : développeurs, intégrateurs, recetteurs, administrateurs et exploitants Garantir qu’il y ait une bonne compréhension des différentes couches logicielles et de leurs limites
Architecture	Positionner un WAF (Web Application Firewall) ainsi qu’une API Gateway en frontal de l’application exposant ses API S’assurer que les échanges ne contiennent pas des attaques (SLQ/LDAP/CMD injection, etc..) et que le flux arrivant sur l’API Gateway soit considéré propre Ne mettre en base que les seules données concernées par les API Faire en sorte que les données en base considérées sensibles soient chiffrées Valider systématiquement et rigoureusement les données (longueur, type, genre) en entrée et en sortie, au niveau de la Gateway, mais aussi de chacune des applications ou services offrant les APIs. Contrôler systématiquement ce qui rentre ET ce qui sort du service sur lequel les API sont mises en œuvre Si le service est susceptible d’avoir beaucoup de trafic et que sa disponibilité doive être garantie (activité de e-commerce, par exemple), évaluer la mise en place d’une solution anti déni de service avec un opérateur ou prestataire spécialisé Assurer une gouvernance des APIs par un comité regroupant IT et métiers et un outil ad ’hoc.
Tests	Mettre en place une équipe de recette n’impliquant ni les développeurs, ni les intégrateurs Contrôler régulièrement, avec un audit détaillé, la façon dont les API sont utilisées S’assurer de la performance et des limites de l’architecture, en évaluant les capacités de traitement de l’architecture avec des tests de charge/surcharge, et mettre en place des mesures de contrôle de flux (Treshold, Throttling…) sur les API, via la Gateway Rester vigilant sur le versioning des API
Veille sécurité	Prendre en compte le plus en amont possible les vulnérabilités publiées affectant les composants logiciels de la plateforme API
Contrôle d’accès aux API	Ne pas considérer qu’il faille protéger les API que de l’extérieur : restreindre à l’indispensable S’appuyer sur des mécanismes d’authentification éprouvés et reconnus en évitant les développements spécifiques Assurer l’authentification renforcée ou forte des clients se connectant aux API (authentification par certificats croisés par les parties en configuration Machine to Machine) Mettre en oeuvre le protocole de sécurité OAuth2, dans un contexte Open ou B2C Privilégier un contexte par certificat mutuel, assurant l’authentification, la signature et le chiffrement des payloads, dans un contexte B2B Utiliser des mécanismes HSM (Hardware Security Module) pour le stockage des clés Assurer un contrôle d’accès sur les API : toutes les API ne doivent pas nécessairement être ouvertes à tous et il faut porter une attention particulière à celles permettant l’écriture de données Systématiser les contrôles d’intégrité, d’authentification et de chiffrement sur les échanges via API Rester vigilant sur les informations remontées par l’API Gateway, en filtrant les types d’information qui peuvent être affichées dans le monitoring ou les logs Faire tester régulièrement les API par un programme de Bug Bounty.
Source : Philippe Provost, Cesin.