English translation provided below.

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.

API governance and security: Best practices to achieve your growth objectives

On May 19th, we gathered with companies and public services around the AIFE (L’Agence pour l’Informatique Financière de l’Etat – French Agency for State Financial Information Technology) to share on “API Governance and Security: best practices to reach your growth objectives” during a workshop hosted by Frédéric Simottel from BFMTV. We discussed best practices in three key areas of APIs: security, governance and API adoption.

AIFE and PISTE

Alexandre Streicher, Delegate of the Director of AIFE, first shared about the role of APIs at AIFE with the PISTE project (Plateforme d’Intermédiation des Services pour la Transformation de l’État – Service Intermediation Platform for State Transformation):

• 58 AIFE APIs and 31 partner APIs published on the platform (ten external partners have chosen to publish their API services on PISTE)
• Over 8,300 applications created
• More than 7,000 users
• Between 20 and 30 million calls every day.

PISTE started as a platform for AIFE solutions and the French Ministry of Economy, Finance, and Industrial and Digital Sovereignty, and then became an interministerial platform used by DINUM, (Interministerial Digital Direction), the Ministries of Ecological Transition, Culture, Justice and Transformation and the Civil Service.

The use cases covered by PISTE include B2G electronic invoicing, public procurement, management of city planning applications and soon B2B electronic invoicing.

API security

Following this introduction, we discussed the first topic: API security. I started with a short overview of recent API attacks, with the examples of the Facebook scrape breach last year, which exposed the passwords of 530 million people and following up with the “View As” API attack in 2019, and the Equifax API attack in 2017 that impacted 147m US citizens and caused the organization to pay back over $425m.

Unfortunately, this trend is on the rise. Attacks on APIs are growing twice as fast (+50% per quarter) as the underlying growth of APIs in use (+25% per quarter). For example, the German employment service Bundesagentur für Arbeit, an Axway customer, faces more than 5 million attacks per day!

So what should you do? First of all, Axway recommends taking an inventory of resources in a Service Registry that gathers all the APIs exposed by all the gateways of an enterprise, in order to avoid “zombie APIs” that are exposed and unprotected.

Secondly, each API must offer security “by design”, i.e. be designed from a security perspective from the OpenAPI specification, with roles that have a defined scope of access to resources. And this principle must be applied to all APIs: internal, partner, or public, with no privileges for the internal ones, following a “zero trust security” model. Finally, of course, APIs must be secured by an API gateway!

Alexandre Streicher confirmed this rising trend of security concerns, and the generalization of API security via OAuth2 and JWT tokens. He cited two examples of additional security services: following the discovery of the exposure of IP addresses to Google by captcha, the AIFE took responsibility for creating a sovereign version of the captcha with the Captch’Etat, which is made available to public entities.

Furthermore, given the sensitivity of API access authorizations, DINUM has implemented an access form that complies with government access control procedures, the datapass, which has been incorporated into PISTE.

In addition to these best practices, the working group added ongoing security training for all staff, not just developers, as well as regular pen testing.

Once our APIs were secured and ready to be exposed, we turned to the topic of API Governance introduced by my colleague, Emmanuel Methivier.

API governance

API governance has become a complex subject in companies that choose an API-first approach. Indeed, thanks to their four complementary powers, APIs bring together people from various departments: security managers (CISO), infrastructure managers (ops, devops), developers who create or consume APIs (devs), product offer managers (marketing) and more recently, with the power of the platform, partnership managers.

This means there’s a significant potential for conflicts in governance between these stakeholders. This calls for a distributed organization, with API product teams in the business lines, supported by a central organization, the platform team, ensuring the coherence of the product teams’ best practices and guidelines, the maintenance of a common API catalog, a coherent and secure architecture, and the maintenance of a common budget for the entire API program.

Given the complexity of state organizations, governance lies at the heart of the success of the AIFE API program. For AIFE and PISTE, the API program is supported by the French General Secretariat of the Ministry of Economy, Finance, and Industrial and Digital Sovereignty, and is part of DINUM’s governance.

As far as the State’s financial system (Chorus) and the connected ministerial applications are concerned, the impetus for the APIfication program comes from the Strategic Orientation Committee of the State Information System.

As for Chorus Pro (B2G electronic invoicing – processing of 68 million government invoices), digital transformation of public procurement, and B2B electronic invoicing, APIfication strategies are part of the governance and consultation mechanisms implemented.

For its ecosystem of third-party API providers, the AIFE does not currently have any specific governance, but shares its best practices and templates with its partners.

Once security and governance were in place, we could move on to the success of an API program: adoption of its APIs.

API adoption

I then took the floor again to remind the audience why API adoption has become a major issue for the companies and agencies we work with. These customers use APIs for four business models:

• to publish secure applications for their customers on the web or mobile, and provide an interactive experience based on captured information
• to enrich this customer experience with third party APIs (CRM, information, music, identification…) that would be much more expensive to develop by themselves,
• to distribute third-party services that complement their offer, and thus earn distributor commissions,
• to be distributed by third party companies and thus acquire new customers.

With this shift from security and experience concerns to ecosystem-serving platform concerns, APIs have come to the forefront of enterprise transformation strategy. Their success is measured by adoption. Here are some best practices we’ve seen from our customers:

Start adoption with internal alignment, on long-term key success factors, budget, creation of hybrid business-IT teams, with aligned interests and goods, and regular internal communication based on “quick wins.”

Once internal alignment is achieved, build APIs as a customer-centric product, with a simple and differentiated experience. If possible, a migration of users from obsolete integrations to these APIs in order to ensure startup, and permanent A/B testing.

Once the product is well established, look to develop a partner network, starting with those that enrich the experience you offer, those you can distribute and those that can distribute your API. Once identified, share your long-term vision and organize offering interoperability to make the experience of your common user community as effortless as possible.

Once – and only once – internal alignment, product, and partner ecosystem are secured, it’s time to communicate. Using growth hacking techniques, developer evangelism, and community conferences, and finally looping in internal communication to the stakeholders you aligned at the beginning.

Alexandre Streicher complemented this general view with AIFE’s good practices:

• a website/portal for developers in PISTE
• simple, self-service consumption of PISTE by developers to facilitate a reduced TTFAC (Time To First API Call), ensured by an API review by AIFE to guarantee adoption of best practices by API producers
• empowerment of API producers with the Publication Self-Service module, a sort of publication sandbox
• permanent consultation and sharing of developments with partner publishers
• the adoption of relevant technological innovations, such as asynchronous APIs, for which a POC is underway.

Conclusion

We would like to thank the AIFE, the CIOs in attendance, and BFM TV for this exchange session, which we hope will help address some of the challenges on the steep but very beneficial path of the API Platform.