Gouvernance des APIs et sécurité: les bonnes pratiques pour atteindre vos objectifs de croissance

Le 19 Mai, nous nous sommes rassemblés avec des entreprises et services publics autour de l’AIFE (L’Agence pour l’Informatique Financière de l’Etat) pour partager sur « la Gouvernance des APIs et sécurité : les bonnes pratiques pour atteindre vos objectifs de croissance » lors d’un workshop animé par Frédéric Simottel de BFMTV. Lors de ce workshop, nous avons échangé sur les bonnes pratiques dans trois domaines clé des APIs :  la sécurité, la gouvernance et l’adoption des APIs. Voici un résumé de notre discussion, et vous pouvez également découvrir les points forts de la discussion dans cet article BFM Business.

L’AIFE et PISTE

Alexandre Streicher, Délégué de la Directrice de l’AIFE, a d’abord présenté la place des APIs à l’AIFE avec le projet PISTE, Plateforme d’Intermédiation des Services pour la Transformation de l’État :

• 58 APIs de l’AIFE et 31 APIs de partenaires publiées sur la plateforme (Dix partenaires externes ayant choisi de publier leurs services API sur PISTE) ;
• Plus de 8 300 applications créées ;
• Plus de 7 000 utilisateurs ;
• Entre 20 et 30 millions d’appels chaque jour ;

PISTE a démarré comme plateforme pour les solutions AIFE et le Ministère de l’Economie, des Finances, et la Souveraineté industrielle et numérique, pour devenir ensuite une plateforme interministérielle utilisée par la DINUM, Direction Interministérielle du Numérique, les ministères de la Transition Ecologique, de la Culture, de la Justice et de la Transformation et la Fonction Publiques. Les cas d’usages couverts par PISTE incluent la facturation électronique B2G, la commande publique, la gestion des demandes d’urbanisme et bientôt la facturation électronique B2B.

La sécurité des APIs

Suite à cette introduction, nous avons échangé sur le premier thème : la sécurité des APIs. J’ai commencé par un court état des lieux des attaques récentes aux APIs, avec les exemples de la brèche en scrapping de Facebook l’an dernier, qui a exposé les mots de passe de 530 millions de personnes et faisant suite à l’attaque de l’API « View As » en 2019, et l’attaque sur l’API Equifax en 2017 qui a impacté 147m de citoyens américains et les a amené à rembourser plus de $425m.

Malheureusement, cette tendance est en hausse. Les attaques sur APIs augment deux fois plus rapidement (+50% par trimestre) que la croissance sous-jacente des APIs utilisées (+25% par trimestre). Par exemple, Bundesagentur für Arbeit, le Pôle Emploi allemand, client Axway, doit affronter plus de 5 millions d’attaque par jour !

Alors, que faire ? Tout d’abord, Axway recommande de réaliser un inventaire des ressources dans un Service Registry qui rassemble les APIs exposées par toutes les gateways d’une entreprise, afin d’éviter les APIs zombies, non protégées mais exposées.

Ensuite, chaque API doit offrir une sécurité « by design », c’est-à-dire être pensée sous un angle de sécurité dès la spécification OpenAPI avec des rôles ayant une portée définie en termes d’accès aux ressources. Et ce principe doit être appliqué à toutes les APIs : internes, partenaires ou publiques, sans privilèges pour les internes suivant une « zero trust security ». Et finalement, bien sûr, les APIs doivent être sécurisées par une API gateway !

Alexandre Streicher a confirmé cette tendance haussière des préoccupations de sécurité, et la généralisation de la sécurisation des APIs par le protocole OAuth2 et des Jetons JWT. Par ailleurs, Alexandre a cité deux exemples de services additionnels de sécurisation : suite à la découverte de l’exposition d’adresse IP à Google par les captcha, l’AIFE a pris la responsabilité de créer une version souveraine du captcha avec le Captch’Etat, qui est proposée aux entités publiques.

Par ailleurs, compte tenu de la sensibilité des habilitations d’accès aux APIs, la DINUM a mis en place un formulaire d’accès obéissant aux procédures de contrôle d’accès de l’Etat, le datapass, qui a été incorporé à PISTE.

En plus de ces bonnes pratiques, le groupe de travail a ajouté une formation continue à la sécurité pour l’ensemble du personnel, pas seulement les développeurs, ainsi que l’organisation régulière de pentest.

Une fois nos APIs sécurisées, donc prêtes à être exposées, nous nous sommes penchés sur le sujet de la Gouvernance des APIs introduit par mon collègue Emmanuel Methivier.

Gouvernance des APIs

La gouvernance des APIs est devenu un sujet complexe dans les entreprises choisissant une démarche API-first. En effet, grâce à leur quatre pouvoirs complémentaires, les APIs rassemblent des personnes issues de divers départements : les responsables de sécurité (CISO),  des infrastructures (ops, devops), les développeurs créateurs ou consommateurs d’APIs (devs) , les responsables des offres produit  (marketing) et plus récemment avec le pouvoir de plateforme, les responsables de partenariats.

L’enjeu de gouvernance entre ces parties prenantes est donc majeur. Une organisation distribuée est nécessaire, avec des équipes produits API dans les lignes de métier, supportées par une organisation centrale, l’équipe plateforme, assurant la cohérence des bonnes pratiques et directives des équipes produit, la bonne tenue d’un catalogue commun d’APIs, une architecture cohérente et sécurisée, et la tenue d’un budget commun pour l’ensemble du programme API.

Compte tenu de la complexité des organisations étatiques, la gouvernance réside au cœur du succès du programme API de l’AIFE. Pour l’AIFE et PISTE, le programme API est soutenu par le Secrétariat Général du Ministère de l’Economie, des Finances, et de la Souveraineté industrielle et numérique (« Bercy »), et s’inscrit dans la gouvernance de la DINUM.

Pour ce qui concerne le système financier de l’Etat (Chorus) et les applications ministérielles raccordées, la dynamique du programme d’APIsation vient du Comité d’Orientation Stratégique du Système d’Information de l’Etat.

Pour ce qui concerne Chorus Pro (facturation électronique B2G – traitement des 68 millions de factures de l’Etat), la transformation numérique de la commande publique, et la facturation électronique B2B, les stratégies d’APIsation s’inscrivent dans les gouvernances et les mécanismes de concertation mis en œuvre.

Pour son écosystème de fournisseurs d’APIs tiers, l’AIFE ne dispose pas à ce jour d’une gouvernance particulière, mais partage ses bonnes pratiques et templates de CGU avec ses partenaires.

Une fois la sécurité et la gouvernance en place, nous pouvions passer au succès d’un programme API, l’adoption de ses APIs.

Adoption des APIs

J’ai alors repris la parole pour rappeler les raisons pour lesquelles l’adoption des APIs est devenu un enjeu majeur chez les entreprises et agences avec lesquelles nous travaillons. Ces clients utilisent les APIs pour 4 business models :

• pour publier des applications sécurisées pour leurs clients en web ou mobiles, et fournir une expérience interactive basée sur les informations issues de capteurs,
• pour enrichir cette expérience client avec des APIs tierces (CRM, information, musique, identification…) qu’il serait bien plus coûteuses à développer par eux-mêmes,
• pour distribuer les services d’entreprises tierces complétant leur offre, et ainsi toucher des commissions de distributeur,
• pour se faire distribuer par des entreprises tierces et par la même acquérir de nouveaux clients.

Avec ce passage de préoccupations de sécurité et expérience, aux préoccupations de plateforme desservant un écosystème, les APIs sont passées au premier plan dans la stratégie de transformation des entreprises. Et leur succès se mesure par l’adoption, et voici quelques bonnes pratiques rencontrées chez nos clients :

Démarrer l’adoption par un alignement interne, sur les facteurs clé de succès à long terme, le budget, la création d’équipes hybrides métier-IT, avec des intérêts et bons alignés, et une communication interne régulière basée sur des « quick wins »

Une fois l’alignement interne obtenu, construire des APIs comme un produit qui doit satisfaire un client roi, avec une expérience simple et différenciée, si possible une migration d’utilisateurs d’intégrations obsolètes vers ces APIs afin d’en assurer le démarrage, et un A/B testing permanent

Une fois que le produit est bien établi, chercher à développer un réseau de partenaires, en commençant par les partenaires enrichissant l’expérience que vous offrez, ceux que vous pouvez distribuer et ceux qui peuvent distribuer votre API. Une fois identifiés, partager votre vision à long terme et organiser l’interopérabilité des offres pour que l’expérience de votre communauté commune d’utilisateurs soit la plus simple possible.

Et seulement une fois l’alignement interne, le produit et l’écosystème de partenaires sécurisés, communiquer : en utilisant les techniques de growth hacking, une évangélisation des développeurs et des conférences de communauté, pour finalement reboucler sur une communication interne aux parties prenantes que vous avez alignées au départ.

Alexandre Streicher a complété ce point de vue général avec les bonnes pratiques de l’AIFE :

• un site web/portailpour les développeurs dans PISTE
• une consommation simple et self-service de PISTE par les développeurs pour faciliter un TTFAC (« Time To First API Call ») réduit, assuré par une revue des APIs par l’AIFE afin de garantir l’adoption des bonnes pratiques par les producteurs d’APIs
• une responsabilisation des producteurs d’APIs avec le module Publication Self-Service, sorte de bac à sable de publication
• en permanence, une concertation et un partage des évolutions avec les éditeurs partenaires
• l’adoption d’innovation technologique pertinentes, par exemple les APIs asynchrones pour lesquelles un POC est en cours.

Conclusion

Nous tenons à remercier l’AIFE, les DSIs présents à cette matinale ainsi que BFM TV pour cette séance d’échanges qui nous l’espérons aidera à adresser certains défis sur le chemin escarpé mais très bénéfique de l’API Platform.