À quoi ressemble la sécurité dans la nouvelle économie des APIs ?

Parce que le volume de données générées est toujours plus important sur les plateformes de chaque entreprise et entre les plateformes des entreprises partenaires d’affaires, la sécurité de tout l’écosystème devient un sujet très chaud.

Comme nous nous connectons toujours plus avec de nouveaux terminaux, l’attente de nouvelles expériences utilisateurs avec ces terminaux augmente elle aussi. Ce n’est plus une surprise quand une application est déjà informée de la recherche qu’on a faite le matin même, ou encore si nous avons acheté quelque chose en ligne. C’est même une attente de l’utilisateur qui souhaite une expérience personnalisée et sans couture. De la même manière, il parait aujourd’hui normal de pouvoir commencer à visionner une série sur notre smartphone en rentrant du travail et regarder la suite sur notre tablette ou à la télévision une fois rentré à la maison. Et nous ne pouvons même pas imaginer que cela puisse poser un problème. Nous vivons dans un monde ‘toujours connecté’ et attendons de nos terminaux qu’ils nous fournissent des services sans couture et immédiats.

Les APIs (Interface de Programmation d’Applications) constituent la clé de voute de cette expérience connectée car elles permettent l’intégration des business entre les entreprises, et contribuent directement à l’accroissement des revenus et à l’émergence de nouvelles opportunités commerciales. C’est la raison pour laquelle le sujet des API n’est plus uniquement le domaine réservé des développeurs, mais devient un sujet majeur d’entreprise discuté au sein des instances de direction : Expedia, par exemple, a généré 90% de ses revenus de ses API dès 2015. Pour Twilio, plateforme cloud de communications, ce niveau atteint 100% de ses revenus. Et ces sociétés sont seulement la partie visible de l’iceberg.

Plus nous nous connectons, plus le rôle de ces API est capital. Parce que le volume de données générées est toujours plus important sur les plateformes de chaque entreprise et entre les plateformes des entreprises partenaires d’affaires, la sécurité de tout l’écosystème devient un sujet très chaud, qui doit être observé à la loupe dès aujourd’hui.

Les fondamentaux de la sécurité des API

Selon Gartner, d’ici 2022 on prévoit que les cyber attaques visant les API constitueront la grande majorité des cyber menaces pour les entreprises. Sans un véritable effort spécifique et une volonté affichée dès maintenant de protéger ces nouveaux systèmes, cela risque même d’arriver beaucoup plus tôt que prévu, avec des conséquences potentiellement graves. La sécurité des APIs repose sur trois piliers qui peuvent se résumer ainsi : Quoi, Combien et Avec qui.

Quoi : On n’expose que les interfaces souhaitées,
Combien : On ne partage et n’accepte que les données requises,
Avec qui : On permet l’accès uniquement aux personnes et systèmes autorisés.

Faire en sorte que les métiers prennent le sujet de la sécurité des API très au sérieux et dès le début du développement de leurs services est le tout premier défi à relever. Il existe différentes approches pour sécuriser son économie des APIs, certaines sont sophistiquées et reposent sur l’utilisation des technologies, d’autres sont malheureusement beaucoup plus problématiques.

1. Faire confiance à ses utilisateurs

Choisir de faire confiance à ses utilisateurs n’est pas une approche très sérieuse en termes de sécurité mais c’est malheureusement de loin la plus répandue aujourd’hui.

Faire confiance a priori ne peut en aucun cas être synonyme de sécurité même concernant des API internes. Ne pas chercher à renforcer la sécurité des APIs rendra malheureusement l’entreprise vulnérable aux cyberattaques et pourra menacer jusqu’à son intégrité. Les développeurs se doivent de traiter ce sujet avec la même importance qu’ils accordent aux interfaces web et applications afin de protéger les données et la propriété intellectuelle de l’entreprise.

2. Les clés API (API Keys)

La plupart des accès aux APIs se font avec des clés. Rapides et faciles à mettre en place, ces clés ont un format de type XXXXX, ce qui signifie qu’elles fonctionnent comme un mot de passe. Cela implique donc de maintenir ces mots de passe et leurs nécessaires rotations. À grande échelle, cela devient un énorme casse-tête pour les développeurs.

En général, les clés API permettent l’accès en mode tout ou rien. Ainsi, si un développeur possède vos clés API, il est possible d’appeler toutes les API que vous exposez ! En résumé, le système des clés API gère plutôt bien le "Avec qui" mais beaucoup plus rarement le "Quoi" ou le "Combien".

3. Utiliser une API Gateway

L’un des moyens les plus sophistiqués pour protéger une infrastructure API est l’API Gateway, comme celles d’Apigee ou Mulesoft. En général, cette technologie apporte une fonctionnalité de gestion des accès qui permet d’adresser la question des interfaces que l’on souhaite exposer ou pas (le Quoi). Mais si l’on regarde la gestion des accès dans son ensemble, la plupart des API Gateways ne permettent pas de gérer le partage des données seulement requises (le "Combien") ni la gestion d’accès aux personnes et systèmes seulement autorisés (le "A qui").

Néanmoins, là où les API Gateways peuvent s’avérer réellement intéressantes, c’est lorsqu’elles sont couplées à une solution complète de gestion des accès. Utilisées seules, les API Gateway ne prennent pas assez en compte le contexte d’accès des utilisateurs : il existe une grande différence entre simplement demander aux utilisateurs qui ils sont (les authentifier) et savoir ce qu’ils comptent faire sur telle ou telle application. Par exemple, utiliser une API sur un système RH pour télécharger votre historique de congés ne comporte pas du tout les mêmes risques que d’utiliser la même API pour modifier vos informations bancaires.

4. OAuth 2.0

Toutes ces solutions imparfaites nous amènent à évaluer le standard de sécurité OAuth. Pour mieux comprendre, il suffit de vous rappeler de l’expérience que vous vivez lorsque vous arrivez pour la première fois dans un hôtel : on vous donne une carte magnétique (un badge) pour accéder à votre chambre. Dans le cas des API, il s’agit d’accéder à une application avec un token, comme vous entrez dans votre chambre d’hôtel avec un badge. Des tokens d’accès spécifiques émis par un serveur d’autorisation sur la base préalable d’une authentification permettent de donner accès, pour un utilisateur alors authentifié, à un ensemble de ressources. Cet accès expire automatiquement après un certain temps prédéfini, ce qui permet de supprimer les risques liés à la gestion et rotation régulière des mots de passe. De plus, avec OAuth, le périmètre des données requises (scoping en anglais, le fameux "Combien") est nativement supporté et permet ainsi de mettre en place tous les éléments pour répondre à nos trois piliers fondamentaux de la sécurité des APIs. OAuth utilise une approche plus complexe, étant moins une spécification unique qu’un cadre sécuritaire de gestion d’accès. Ce cadre permet plus de flexibilité, donc moins de standardisation, et son utilisation est reconnue, dans le monde de la sécurité, comme un atout indéniable. Il faut néanmoins rappeler que OAuth 2.0 n’est pas suffisant seul pour sécuriser les API car, s’il couvre complètement nos trois piliers, il ne permet pas de protéger l’API elle-même ! En conclusion, il faut deux types de solutions complémentaires pour vraiment sécuriser son économie des APIs :

En pratique, aucune des deux solutions seules - API Gateway pour sécuriser l’API elle-même, et OAuth pour sécuriser l’accès aux APIs - ne peut garantir à elle seule une sécurité à 100%, et si vous décidez de mettre en place une seule de ces solutions, vous prendrez certainement un risque qu’il faudra évaluer et gérer !

Une Gateway API qui utilise OAuth est clairement l’approche qui permet la meilleure sécurité en particulier pour des cas d’usage complexes.

Les technologies complémentaires peuvent être combinées pour créer un système de gestion des accès aux API très puissant qui peut, par exemple, limiter des "scopes" OAuth particuliers à certains terminaux, réseaux ou groupes en particulier. Une équipe sécurité peut gérer ce genre de politiques d’accès en dehors de l’API Gateway, avec un archivage centralisé des demandes et validations d’accès ainsi qu’une gestion centralisée des changements de politique de sécurité.

Ainsi, il devient possible de sortir l’économie des APIs du monde du ‘Shadow IT’ et le ramener à des systèmes et mécanismes de confiance connus, Aucune solution n’est jamais définitive, et le partenaire de confiance d’aujourd’hui peut demain devenir le système infecté mettant à risque la sécurité et l’intégrité de votre activité. Il ressort donc qu’il faut continuer à être flexible et à ajuster ses solutions pour protéger au mieux nos systèmes sur la base d’une compréhension toujours plus fine du contexte d’utilisation et des objectifs de chaque utilisateur quand celui-ci souhaite accéder à une ressource de votre entreprise.