L’annonce de la certification « Common Criteria EAL4+ » de la plateforme Amplify d’Axway a été accueilli par la communauté API comme une avancée majeure dans la sécurisation des systèmes d’informations. Cette certification, la plus haute certification pour un logiciel civil, est un gage de renforcement de la sécurité périmétrique de votre système d’information.
En effet, il faut considérer la plateforme exposant vos API comme le « pont-levis garant de la sécurité des entrées-sorties de la forteresse », en l’occurrence votre système d’information. Une sorte de « boite à fusible digital », pour laquelle il est normal d’exiger la plus haute qualité et la plus grande sécurité.
Et pourtant, même si la certification EAL4+ est indispensable à cette brique de sécurité (l’APIM), et même si cette brique de sécurité APIM est absolument nécessaire à la sécurité de votre SI, elle n’est pourtant pas suffisante pour assurer la sécurité complète d’un système d’information ouverts, à travers quatre axes : Disponibilité, Intégrité, Confidentialité et Preuve (DICP).
Au-delà des certifications
Ces axes DICP (Disponibilité, Intégrité, Confidentialité et Preuve) doivent s’appréhender différemment pour un SI étendu, ouvert par des API.
En effet, contrairement aux SI fermés, maitrisés de bout en bout, un SI ouvert permet à des développeurs externes de construire des applications pour vos clients, sans que vous ne puissiez en maitriser le code et donc l’ensemble des fonctions.
Que se passerait-il si, en tant qu’opérateur de santé, un de vos développeurs externes ne cachait une backdoor pour exfiltrer les données de vos clients ?
Que se passerait-il si, en tant que banque, les données de vos clients se retrouvaient exposées par le biais d’une faille dans une application que vous ne maitrisez pas ?
L’argument de la responsabilité juridique ne tient pas longtemps. Ce sont VOS clients, ces données ils VOUS les ont confiées, vous avez donc forcément une responsabilité, au moins d’image.
Dans le contexte d’un SI ouvert, il est donc indispensable d’appréhender la sécurité de bout en bout, en considérant le « zéro trust » notamment sur cette brique de développement externe dont vous ne pouvez pas avoir la complète maitrise.
Cela passe par plusieurs étapes complémentaires à une sécurisation classique.
La sécurisation des SI ouverts exige une approche « Zéro Trust »
Gestion d’identité
Il faut en premier lieu s’assurer de l’identité du développeur externe consommateur de vos services, de vos produit digitaux (API). Cela passe par une gestion stricte des identités digitales de vos partenaires développeurs externes.
Mais il est aussi nécessaire de contrôler les applications développées par ces développeurs. Un jeton par version applicative permet de s’assurer que n’importe quel code ne va pas consommer vos services.
Cette double identité est gérée par un double échange de jeton développeur / version de l’application.
Une fois cette identité validée, il faut s’assurer que le processus n’est pas corrompu. Comment s’assurer qu’un développeur ne pousse pas à vos clients une version d’application modifiée comportant une faille.
Sandboxing
Pour s’assurer de l’intégrité du processus, il est nécessaire de passer par une sandbox dans laquelle tournera l’application tant qu’elle ne sera pas validée par vos services de sécurité / compliance. Cette Sandbox permettra aussi à vos développeurs de tester les applications.
L’application testée devra nécessairement être celle présente en store (google play ou apple store), car sinon, il est impossible de s’assurer de la non-modification de l’application entre le moment de la validation et l’utilisation par vos clients. Une fois validée, on modifie l’état du jeton applicatif pour que l’application puisse tourner avec les données de production réelles.
Comme vous pouvez le voir, on inverse donc le processus classique (passage en production après test de sécurité) puisque l’application sera livrée dans les stores de production avant les tests. Grace à ce système de jetons sécurisés et de l’aiguillage sandbox/prod, vous pourrez vous assurer non seulement de la sécurité à un instant T mais surtout, vous gardez la maitrise et pouvez à tout moment débrancher le fonctionnement d’une application qui ne respecterait plus les guidelines.
Un robot détectant toute modification d’une version des applications en store est le complément idéal pour vous assurer qu’il n’y a pas de nouvelle version / nouvelle faille. S’il détecte une nouvelle version non testée, un processus de blocage du jeton la fera retourner dans la sandbox.
Maitrisez la complexité
Autre étape indispensable à un SI APIsé, la maitrise du foisonnement des API. Comme nous l’avons vu, celle-ci sont les portes d’entrée / sortie du SI, et leur croissance explosive entraîne une complexité croissante.
Elles doivent donc être parfaitement inventoriées afin d’en garantir la gouvernance ; impossible de gérer ou sécuriser ce dont on ignore l’existence.
Ces étapes sont complémentaires aux sécurisations classiques, elles ne les remplacent pas.
Axway offre une expertise au-delà des solutions, pour un SI ouvert et sécurisé
Pour vous accompagner sur une APIsation réussie et sécurisée de votre SI, Axway peut donc vous fournir les briques essentielles pour garantir non seulement la sécurité périmétrique mais aussi s’assurer de l’ensemble de cette gouvernance, allant jusqu’au conseil d’implémentation en fonction de la sensibilité de vos données et services.
N’hésitez-pas à nous contacter pour en discuter.
Découvrez 6 manières de relever les défis des leaders IT avec une plateforme ouverte.
Suivez-nous sur les réseaux sociaux