Tribunes

API publiques, API privées : des enjeux très similaires

Parmi ses nombreux usages, l'API est une porte ouverte entre plusieurs systèmes. Publique, privée, anonyme ou non, les choix sont nombreux. Les risques aussi. Tour d'horizon des modèles et des protections à y associer.

PublicitéAPI publique : valoriser ses applications...

C'est sans doute le modèle le plus connu de la sphère numérique. L'API publique permet à un éditeur de service Web de mettre à disposition son ou ses services auprès d'autres développeurs d'applications ou de services Web. Objectif : diffuser le plus largement possible son service. C'est précisément la position adoptée par Google Maps, Facebook et autre Twitter pour l'intégration des gadgets correspondants dans un site Web par exemple. A tel point qu'aujourd'hui, certains de ces services revendiquent plus de 60% du trafic par leur API et non plus par leur propre site Web.

Outre sa capacité à valoriser la donnée produite, l'API publique permet par ailleurs aux éditeurs de développer les usages sans avoir à fournir eux-mêmes les efforts de développement complémentaires, mais au contraire en s'appuyant sur l'inventivité et l'ingéniosité d'autres éditeurs de services. A priori, c'est donc une solution idéale pour des services dont les données sont à l'origine mises à disposition du public.

...au risque de perdre le contrôle de ses données

Pour autant, il convient de rester prudent avant de proposer au marché une API 100% publique et anonyme (sans identification préalable du développeur). Afin notamment de garder un certain regard sur l'utilisation des données produites. Et c'est d'ailleurs le choix d'une grande majorité des éditeurs proposant une API (Twitter, Google, etc.) : si la documentation et l'API sont en libre accès, les développeurs ont, en règle générale, l'obligation a minima de s'enregistrer avant d'accéder aux ressources.

De façon plus aboutie, un contrôle plus renforcé pourra être mis en oeuvre. Avec, en complément d'une authentification du développeur en amont, un contrôle, en aval, du comportement de l'application développée vis-à-vis des données du système d'information qu'elle exploite.

On parle alors d'API externe d'entreprise. Une solution plus sécurisée avec par exemple la validation de l'identité du développeur (ou de l'entreprise) avant l'accès aux données. C'est généralement la méthode retenue pour l'utilisation de données sensibles : échanges d'informations médicales, paiement sécurisé, accès aux données personnelles clients, etc.

API privées : une sécurité à ne pas négliger

De manière plus restreinte, une entreprise peut aussi avoir besoin d'une (ou plusieurs) API en interne : entre business units, entre filiales, et plus globalement pour l'interfaçage des données et des systèmes entre eux. Et dans la majorité des cas, en particulier dans les plus grandes entreprises, les problématiques sont quasi les mêmes que dans le cadre de la mise en place en place d'une API publique.

PublicitéAussi, la sécurité du système d'information en général, et des données en particulier, doit être prise en compte de la même manière. Les accès aux données les moins sensibles pouvant dès lors se contenter d'une API interne ouverte ou d'un simple accès par enregistrement, tandis que des données de type financier et comptable, des données clients ou des secrets industriels doivent faire l'objet d'une sécurité accrue, pour laquelle seul un contrôle d'accès permettra de suivre les usages qui en sont faits.

Comme dans le cas d'API publiques, une politique de sécurité des API internes globale et cohérente est alors nécessaire. Associée à une gestion fine des identités et des accès, elle permet en outre d'identifier précisément les rôles de chacun, voire les tranches horaires d'accès à l'API. Il devient dès lors possible de suivre l'activité sur chaque interface ou encore de gérer les quotas d'utilisation. Et ainsi de se prémunir des failles de sécurité internes, généralement les plus dangereuses...