Sécurité des API : pilier de la transformation des systèmes d’information modernes

de | 8 septembre 2018

Le recours aux API se densifie dans les organisations dans le cadre d’un coté la transition numérique des organisations, désigné plus simplement par transformation digitale, et de l’autre la modernisation des architectures des systèmes d’informations.

  • Les échanges avec des services de tiers… utilisation initiale des API mais qui se densifie avec l’enrichissement de l’écosystème des entreprises notamment avec d’un coté les start-ups et de l’autre les fournisseurs de services dans le cloud public ;
  • L’intégration des API dans les applications, notamment dans les applications mobiles pour les usages internes des organisation ;
  • La généralisation des architectures à basées sur les microservices publiés à travers des API, MSA pour Micro-Services Architecture douce évolution des architectures SOA ;
  • L’automatisation et l’orchestration des actions dans le système d’information qui se basent principalement sur les API.

Il existe deux types d’API : les API SOAP et les API REST. Je laisse le soin aux architectes SI de positionner les cas d’usage de chaque type et les avantages et inconvénients associés (chacun son job). D’un point de vue, purement, sécurité, les deux types d’API ne se valent pas : la sécurité dans la API SOAP est structurée par la norme, là où la sécurité des API REST est comparable au Far West.

Une bonne sécurité des API SOAP passe par la mise en place de WS-Security qui propose nativement des mécanismes d’authentification, de chiffrement voire de signature des messages échangés : WS-Security assure la sécurité du message depuis sa création jusqu’à sa consommation par le tiers appelant. Le fait que WS-Security propose ses propres mécanismes de sécurité, le rend agnostique au protocole de transport. Ainsi un message SOAP sécurisé par WS-Security peut-être transporté dans tous types de protocole de transport :  https ou un tunnel TLS (ses mécanismes de transport par défaut), voire SSH ou encore IPSec. La mauvaise bonne nouvelle : la richesse de SOAP fait qu’il est complexe à mettre en œuvre et probablement pas adapté au projet tactique (test/POC et/ou court terme) ou un projet qui nécessite des échanges très basiques (quelques données) avec des tiers.

Lorsqu’il s’agit d’API REST : c’est le no man’s land. Les API REST sont très focalisées sur la transmission et le traitement des échanges du contenu principalement au format JSON (JavaScript Object Notation). JSON est un format assez simpliste qui se résume en un ensemble de clés suivi de listes ordonnées de valeurs. Hormis la dimension transport qui peut s’appuyer sur https et ses fonctionnalités de chiffrement réseau et d’authentification mutuelle, il n’existe pas vraiment de mesures de sécurité natives malgré quelques initiatives sur le sujet tel que JSON Web Signature (JWS). L’ensemble des mesures de sécurité sont à réfléchir et à partager avec le(s) tiers qui souhaite(nt) bénéficier des services. A ce titre, je ne peux que renvoyer vers la publication de l’OWASP sur le sujet. Elle traite de l’ensemble des sujets qu’un développeur doit considérer afin de mettre en œuvre des API REST. Par ailleurs, cette publication met en avant des mesures qui sont communes aux deux types d’API.

La publication complète est disponible ici : REST Security Cheat Sheet