juin 17th, 2014

Les entreprises font face aujourd’hui à de nouveaux modes de consommation de l’informatique où les API jouent un rôle essentiel pour développer de nouveaux services et faciliter les échanges avec les clients et les partenaires. Si cette nouvelle « économie de l’API » génère de formidables potentiels de croissance, elle pose également de nouvelles problématiques en matière de sécurité et de confidentialité des données échangées, auxquelles il faut apporter des réponses adaptées et efficaces. Êtes-vous certain de l’intégrité de vos API ? Les réseaux sociaux, les services Cloud ou encore les terminaux mobiles ont bouleversé les conditions d’accès aux données et aux services, en même temps qu’ils ont généré de nouvelles opportunités de croissance pour les entreprises. C’est dans ce contexte que les API web, véritables couches communes faisant l’interface entre différents systèmes, plateformes et appareils, se sont peu à peu imposées dans la sphère technologique. Et ce n’est qu’un début : selon le cabinet Gartner, les trois quarts des entreprises du Fortune 500 envisagent d’ouvrir une API au cours de l’année. Toutes ces API participent à enrichir les services fournis aux utilisateurs : transmettre des résultats d’examens médicaux en ligne, gérer ses comptes bancaires depuis son téléphone mobile, consulter un historique de commandes sur sa tablette… Mais aussi séduisants et pratiques que soient ces services, ils n’en soulèvent pas moins des questions critiques quant à la sécurité des données qui transitent via ces API. Les entreprises l’ont bien compris et la sécurisation de leurs API est au coeur de leurs préoccupations. Non toutefois sans un certain nombre d’idées reçues qui en empêchent la pleine efficacité…

1. L’opacité d’une API suffit à la protéger
La première erreur consiste à penser qu’une API est protégée de fait, seules les équipes impliquées
dans son développement en connaissant les rouages. Une approche assurément inefficace sur le
long terme, dans la mesure où si un produit ou un service est doté d’une API, celle-ci finira par susciter la curiosité de tiers qui ne manqueront pas de l’examiner. Et, pour peu qu’ils soient
malveillants, de s’en servir à mauvais escient. Le constructeur automobile Tesla a failli en faire
l’amère expérience : il avait choisi de ne pas documenter l’API de l’un de ses véhicules électriques
de luxe, ni d’y appliquer de règles d’authentification, estimant qu’elle ne présentait pas de risques
critiques en termes de sécurité. Jusqu’à ce qu’il découvre qu’elle permettait potentiellement à
n’importe qui de déclencher des actions à distance sur la voiture. En d’autres termes :
documentation et authentification doivent être les deux clés de voûte d’une API sécurisée.

2. Seul le contrôle des accès compte, les usages importent peu
Si des règles strictes d’authentification permettent de contrôler les accès à l’API, elles ne suffisent toutefois pas à en garantir pleinement l’intégrité. Il est également essentiel de contrôler, via un audit détaillé, la façon dont l’API est utilisée. D’abord pour disposer de données légalement exploitables en cas d’attaques malveillantes, ensuite pour garantir sa conformité avec les réglementations industrielles en vigueur. C’est particulièrement vrai pour les entreprises de secteurs sensibles, comme la santé ou l’énergie, où les contraintes réglementaires sont particulièrement fortes. Notons par ailleurs l’intérêt économique de connaître l’usage qui est fait d’une API au fil du temps …

3. Le protocole SSL a fait son temps
Les technologies évoluent et la tentation est grande de succomber à l’attrait de la nouveauté. Pour
ce qui est de la gestion des API, le protocole SSL a beau avoir de la bouteille, il n’en demeure pas
moins LA référence en matière de sécurisation des échanges. Ce n’est d’ailleurs pas un hasard si
une société comme Amazon, qui gère chaque mois des milliards d’interactions, n’autorise les accès à son API que via SSL. Et les nouveaux standards d’authentification, comme OAuth, doivent davantage être envisagés comme des compléments à SSL plutôt que comme des alternatives.

4. Rien ne vaut un système de sécurité maison
SSL, OAuth, OpenID, SAML, SW-Security et autre authentification HTTP : le nombre et la complexité des combinaisons et procédés possibles d’authentification poussent certains programmeurs à développer leurs propres systèmes de sécurité. Bien mal leur en prend, non seulement ils s’infligent une surcharge de travail, mais prennent aussi le risque de générer un système faillible. La moindre modification, aussi légère soit-elle, sur un standard existant, altère potentiellement l’efficacité – éprouvée – de celui-ci et expose l’API à des risques inconsidérés.

5. Sécurité et processus métiers ne doivent faire qu’un
Confondre logique métier et logique de sécurité n’est pas une aussi bonne idée qu’il y paraît. D’une
part parce que cela démultiplie les opérations de maintenance puisque tout changement dans les règles de sécurité a des répercussions sur les processus métier. D’autre part parce que cela peut impacter les performances de votre réseau tout entier. Avoir une plateforme séparée dédiée à la sécurité permet à l’inverse de préserver les performances de votre système tout en y ajoutant une couche de protection supplémentaire contre de potentielles attaques.

6. Une API n’est pas concernée par les menaces web traditionnelles
Il ne faut pas oublier qu’une API web est avant tout une application web et qu’à ce titre, elle est
exposée aux mêmes menaces que ses consoeurs : attaques en déni de service (DDoS), injections SQL, etc. Autrement dit, sécuriser une API implique de tenir compte non seulement des nouvelles menaces propres à l’API, mais aussi des attaques typiques et connues visant les applications web dans leur ensemble.

7. XML, JSON : on doit choisir le format de données le plus adapté
PC plutôt que Mac ? Chat plutôt que chien ? Bordeaux plutôt que Bourgogne ? XML plutôt que JSON ? En matière de formats de description de données, nos préférences personnelles ne doivent pas guider notre choix : il faut opter pour les deux ! Gérer à la fois du XML et du JSON permet de renforcer la sécurité d’une API en autorisant les interactions avec des API partenaires sans se soucier du protocole qu’elles utilisent.