Sécurisation des API : les bonnes pratiques pour protéger le système d'information
"Accéder à des données qui ne nous sont pas destinées par la simple modification d'un bout d'URL ? Oui, c'est possible si l'API qui assure leur transit n'a pas respecté les recommandations de sécurité", assure Nicolas Bouquet, fondateur de Numéthique. Quand on sait que ces morceaux de code sont derrière la plupart des interactions en ligne, l'enjeu est de taille. La plateforme programmableweb.com recense près de 25 000 API publiques, toutes catégories confondues (finances, IA, loisirs, etc.) "et il existe des millions d'API privées !", ajoute Nicolas Bouquet.
"Les APIs sont devenues la règle, confirme Bertrand Carlier, senior manager chez Wavestone. Dans les processus de développement, elles sont même très souvent réalisées en premier. L'interface graphique n'arrive qu'ensuite". Dans un contexte d'informatique décentralisée, et en quête constante d'agilité, les APIs permettent au système d'information des entreprises, toutes tailles confondues, de se connecter aux applications métiers, aux partenaires, aux terminaux des collaborateurs mais aussi des clients.
"Le point commun entre une startup et une entreprise du Cac 40 est qu'elles cherchent toutes les deux les moyens de rendre leur organisation plus agile. Et les API REST ou GraphQL apportent cette souplesse qui facilite la vie des développeurs. Chez AWS, nous délivrons tous nos services sous forme d'API depuis 2006. C'est un principe fondateur chez nous !", rapporte Stéphan Hadinger, CTO chez AWS France. On se souvient de l'API Mandate de Jeff Bezos, publié en 2002 et connu pour sa 6ème règle : "Anyone who doesn't do this will be fired" ("qui ne fait pas cela sera viré").
Faire cohabiter agilité et sécurité
D'abord exposées en XML à partir du protocole d'échange SOAP (Simple Object Access Protocol), les APIs ont progressivement basculé sur REST (REpresentational State Transfer) au début des années 2000. L'idée était de découpler le client et le serveur et rendre l'accès à l'API plus abordable, voire auto-découvrable (contrôles hypermédias). Ni protocole, ni norme, REST se définit plutôt comme un ensemble de contraintes architecturales. Plus légère, la technologie est aussi appréciée pour sa capacité à désentraver le développeur dans sa créativité et à favoriser l'agilité des projets, mais au détriment, parfois, de la sécurité.
"SOAP, lui, intègre directement des contrôles pour une validation stricte du format des données échangées. Non seulement par l'utilisation du XML et des schémas XSD, mais aussi via une authentification présente dans les entêtes de chaque requête SOAP. "L'extension WS-Security permet d'assurer l'intégrité, le chiffrement des données - très utile à une époque où HTTPS n'était pas encore très utilisé - et le support de protocoles d'authentification, Kerberos, X-509, etc", précise Nicolas Bouquet.
Une API qui ne respecte pas les bonnes pratiques de sécurité expose le système d'information à des risques d'intrusion. Un principe qui s'applique également aux API GraphQL, créées par Facebook en 2012. Et, lorsqu'on parle de sécurité du SI, il s'agit de garantir les quatre principes fondamentaux que sont la confidentialité - les données ne vont qu'aux personnes autorisées -, leur intégrité - les données ne sont ni transformées ni supprimées -, leur disponibilité et leur traçabilité.
Deux protocoles incontournables
Concernant l'aspect confidentialité, cela commence par l'authentification de l'origine des requêtes, à savoir apporter la preuve que le client de l'API est bien celui qu'il prétend être. Il existe aujourd'hui des standards comme OAuth2, très popularisé par les géants du web, qui permettent de gérer l'autorisation, ou encore OpenID Connect (OIDC) pour l'authentification.
OAUTH2 (RFC6749) est un cadre d'autorisation largement utilisé, qui s'appuie sur les jetons Bearer (RFC6750) pour l'authentification. Il permet de déléguer un sous-ensemble de privilèges aux applications. Il est recommandé de l'utiliser comme choix par défaut pour son API car il gère la plupart des cas d'utilisation et quasi tous les géants du Web y recourent. "On utilise un serveur de confiance tiers qui confirme qu'un client a le droit ou non d'accéder à une donnée appartenant à un utilisateur, explique Jordan Afonso, expert en sécurité applicative. L'utilisateur a délégué l'accès à ses données à un client tiers : c'est ce protocole que nous utilisons à chaque fois qu'un Google ou Facebook nous demande des permissions d'accès pour une application. Le serveur qui détient la ressource n'a pas besoin de connaître les identifiants du client, tout repose sur la relation de confiance avec le serveur d'autorisation".
Un exemple bien connu de serveur OIDC est le service gouvernemental France Connect
OpenID Connect, lui, se charge de décrire plus précisément l'identité des utilisateurs et de réaliser l'authentification des tiers. Pour ce faire, il utilise les normes existantes, dont OAUTH2 et JWT. "Son usage est recommandé si vous souhaitez gérer les utilisateurs d'une manière standard. Il va permettre aux développeurs d'applications et de sites d'authentifier les utilisateurs sans avoir à stocker et gérer les mots de passe", explique Nicolas Bouquet. Il peut être utilisé pour authentifier applications et utilisateurs sur des ressources API privées. Une fois en place, OpenID Connect permettra de gérer un ou plusieurs fournisseurs d'identité, internes (authentification d'entreprise) ou externes (Facebook Connect, Google, etc.). Un exemple bien connu de serveur OIDC est le service gouvernemental France Connect, qui permet de faire fonctionner ensemble les fournisseurs de services, les fournisseurs d'identité et les fournisseurs de données. C'est comme cela que vous pouvez vous connecter à Ameli - en tant que service - en utilisant vos identifiants des impôts (fournisseur d'identité).
"Il existe également d'autres solutions plus artisanales comme API Key, mais peu recommandées dans le cadre d'usages sensibles", complète Nicolas Bouquet. API Key est une chaîne aléatoire servant de secret partagé entre le client et le serveur. "Mais c'est comme si deux espions se mettaient d'accord, pour se reconnaître, sur une phrase de type : "Un secret a toujours la forme d'une oreille". Si cette phrase est connue d'autres personnes, elle n'a plus d'utilité pour identifier les deux personnes. Il faut donc que les deux parties se mettent à nouveau d'accord sur un autre secret partagé. C'est très sommaire comme méthode d'authentification", explique Jordan Afonso.
Les passerelles ou API Gateway, comme premier niveau
Si les compétences viennent à manquer en interne pour mettre tout cela en application, les passerelles API offrent un premier rempart. Sortes de proxys inversés placés entre le client et le serveur, elles automatisent et systématisent la mise en place de certains verrous. Gérées par un fournisseur, elles garantissent le maintien des technologies utilisées. Amazon API Gateway met à disposition des services pré-packagés pour mettre en place les premières règles de sécurité avec, par exemple, des options d'authentification (contrôle des jetons OAUTH2/OIDC), de routage, de quotas (throttling), mais aussi pour gérer ces règles au long cours. "Mettre en place un certificat SSL/TLS pour sécuriser les échanges est à la portée de tous, mais assurer le bon niveau de mise à jour et de chiffrement est un travail de spécialiste. API Gateway apporte ce niveau de sécurité et permet aux équipes IT de ne pas s'en soucier. Autre point important : la journalisation avec la gestion des logs, pour monitorer et superviser en temps réel", explique Stephan Hedinger. Parmi les passerelles, on retrouve Kong Gateway, Apache APISIX, Tyk disponibles en Open Source ; Ocelot, Goku, Express Gateway, Gloo, KrakenD, Fusio, WSO2 ; Apigee et Cloud Endpoint de Google et Azure de Microsoft.
Une fois tout cela dit, attention. "Le prisme de l'API seul ne suffit pas, précise Bertrand Carlier. Pour aller plus loin, il est de rigueur d'intégrer ces considérations à une démarche de gestion des risques et de se poser les bonnes questions : à quel(s) risque(s) suis-je exposé ? Quelles sont mes données sensibles ? Quid du RGPD ? Qui va m'aider à dimensionner correctement mon effort de sécurité (budget/temps/complexité/impact sur l'expérience utilisateur) ? Ensuite, la sécurité doit faire l'objet d'une intégration dans tous les développements." On parle ici de DevSecOps, de tests automatisés de sécurité (SCA, SAST, DAST, etc.) ou encore, pour compléter les tests classiques de pénétration (Pentest), de campagnes type Bug Bounty. "Leur objectif est d'offrir, par l'intermédiaire de plateformes, comme les françaises Yogosha ou YesWehack, une prime à des "chasseurs", experts en sécurité, lorsqu'ils trouvent des failles réelles. Et c'est terriblement efficace !", conclut Nicolas Bouquet.