Les Web Services sont une approche relativement standard permise par les Application Programming Interfaces (API, interfaces de programmation d'applications), qui permettent à une entreprise ou des entités d'accéder aux capacités d'un site web, aux applications ou aux systèmes internes d'une organisation en se connectant directement aux données sous-jacentes. Cette approche permet un accès rapide au marché en termes d'innovations en temps réel, mais requiert de nouveaux standards dans la manière de sécuriser et de gérer les API ainsi que dans la nature des communications inter-organisationnelles des API au niveau des passerelles B2B d'entreprise.
Comment les API facilitent-elles les innovations ? La manière la plus évidente est celle du mashups qui s'appuie sur une plate-forme d'API bien établie, comme Google Maps ou les services basés sur la localisation. Une autre manière peut-être moins évidente est, pour une entreprise, de créer une poignée d'über-API permettant aux applications d'entreprise d'effectuer de nouvelles fonctions génératrices de revenus, telles que l'expansion d'une couverture de marché via de nouveaux canaux. Deux exemples parmi les API d'entreprise les plus populaires qui génèrent de nouveaux mashups sont Salesforce.com et DocuSign.
Dans tous les cas de figure, les API doivent êtres gérées, gouvernées et sécurisées avec fondamentalement les mêmes politiques sur les différentes plate-formes et entités du domaine, et doivent prendre en compte la connectivité et les protocoles de transport relatifs aux messages des applications concernées. Les avantages des API sont encore plus flagrants quand les organisations ont besoin de partager des applications et des données via des plates-formes Cloud ou mobiles. Cependant, exploiter des données d'entreprise au travers d'API dans des environnements de Cloud privé/public sans contrôles adéquats d'identité, d'accès, de vulnérabilité et de gestion de risque expose ces sources de données à de potentielless failles de sécurité (voir aussi How to Manage and Secure APIs with Unified Services Gateways).
Voici quelques exemples d'innovations pilotées par la technologie qui exigent les standards les plus rigoureux en termes de sécurisation automatisée d'API et de conformité :
Le commerce de détail : la Communication en Champs Proche (Near-Field Communications ou NFC) permet aux smartphones d'interagir avec des produits physiques via Radio-Identification (RFID) ; par exemple, Coca-Cola peut générer un bon de réduction à la volée dans le rayon des boissons pour un consommateur qui utilise les fonctions NFC du smartphone. La possibilité de personnaliser cette interaction dépend du consentement de l'utilisateur et de l'authentification sécurisée - cette fonction, comme beaucoup d'autres fonctions NFC seront rendues possibles par des API sécurisées ; de plus, les API NFC déployées dans les canaux de distribution devront adhérer aux Standards de Sécurité des Données de l'Industrie des Cartes de Paiement (PCI DSS, Payment Card Industry Data Security Standards).
Les services de vidéo numérique : WebRTC, ou Communications Temps Réel, est un standard vidéo libre émergent en cours de développement par le World Wide Web Consortium (W3C). WebRTC a des applications navigateur-à-navigateur pour la discussion vidéo, les appels vocaux et le partage de fichier peer-to-peer sans lecteur multimédia ou plugin tiers. Ces applications vidéo qui menacent les standards existants de collaboration temps-réel et de communication, tels que WebEx et Windows Media Player, vont nécessiter une authentification et un transport sécurisés, qui se feront dans des API. Pour les applications dédiées aux réunions, l'API devra fournir les autorisations d'utilisation et de ré-utilisation, les communications avec privilèges cadres par segmentation des responsabilités, et les contrôles de codes en temps-réel.
Les dossiers médicaux électroniques : nous savons que les DME lancés par les gouvernements sont soumis à des pressions ; la numérisation des données médicales va créer des opportunités pour les services basés sur API. Par exemple, l'API peut s'interfacer avec le profil médical d'un individu pour faciliter à la fois les aspects business et services du monde médical, comme par exemple une application de rendez-vous qui accorde les besoins médicaux du patient avec les disponibilités des spécialistes et des services, ou une application SMS qui alerte le patient sur la réception de nouvelles informations ou résultats d'analyses disponibles. Par ailleurs, les API qui s'interfacent avec les DME devront intégrer les plus hauts niveaux de protection des données privées et de conformité aux réglementations.
Les services financiers en Cloud : plus de 60% du trading d'actions et obligations est maintenant constitué de transactions dites haute-fréquence ( High-Frequency Trading ou HFT). Les données analytiques en termes de volumes de transaction, succès des algorithmes, évaluation en volumes et analyses comparatives sont des ensembles d'informations de valeur pour l'industrie. Par exemple, une très grande institution pourrait avoir jusqu'à 10 000 professionnels utilisant les technologies HFT requérant de la visibilité sur les mêmes données au même moment. Le principal avantage de ce type de plates-formes data-as-a-service est de modéliser l'analyse de gestion des risques pour de futures opportunités de transactions financières, c'est pourquoi l'API doit sécuriser les données sous-jacentes aussi sûrement que toute autre technologie régulée dans la finance.
Services de chiffrement et de partage des données : les moyennes et grandes entreprises ont de plus en plus tendance à allouer certains aspects de leur infrastructure informatique à un fournisseur de cloud public tel qu'Amazon Web Services. L'interaction entre les clusters de calcul et de stockage, le réseau de l'entreprise et l'Amazon Elastic Cloud (EC2) est une API d'entreprise qui communique avec l'API EC2. Cependant, la topologie de stockage sous-jacente, souvent formée dans un standard libre comme Hadoop, ne se conforme pas toujours aux standards individuels de l'entreprise en termes de stockage ou de mobilité des données, et les passerelles API de l'entreprise doivent donc orchestrer l'usage des données et le chiffrement adéquat de celles-ci dans le cloud comme si les services étaient fournis par l'entreprise elle-même.
La souplesse commerciale des API est à la fois un problème de gestion et de sécurité. Les gestionnaires d'API doivent évaluer l'automatisation de la gouvernance des API pour réduire les erreurs de programmation potentielles. De l'autre côté du miroir, les problématiques de sécurité liées aux politiques de gouvernance, de protection des données, de conformité aux lois et aux réglementation doivent toutes êtres atténuées pour répondre au mieux aux exigences commerciales. (pour une analyse plus détaillée, voir The Reality of API Management Challenges).
Protection des données : l'accès non-autorisé aux fichiers d'entreprise par des développeurs utilisant les API fait peser une menace de corruption de l'intégrité des données. Que ce soit malicieux ou accidentel, une entité accédant à des données d'entreprise au travers d'une API peut potentiellement changer cette donnée et casser la conformité de la société envers certaines réglementations qui requièrent l'intégrité des données pour des audits, des transactions financières ou autres.
Adhésion et Conformité : prenons l'exemple d'un gros fabricant. Ce fabricant développe un système de commandes auquel on confie le reporting des ordres de vente destiné à des développeurs d'applications tierces. Le fabricant a, de cette façon, potentiellement mis en danger la précision de ses rapports financiers. Pour les "petits c" - conformité avec les contrôles internes et la gouvernance d'API - la société prend le risque de voir ses systèmes d'ERP compromis, avec des impacts sur l'intégrité et la disponibilité des données. Pour les "grands C" ou Conformité avec les pressions externes, le manque de contrôle et de gouvernance d'API sur le système de commandes pourrait mettre en défaut la conformité avec Sarbanes-Oxley, qui couvre les contrôles internes assurant la justesse des rapports financiers.
Atténuation des risques : si nous gardons l'exemple de ce fabricant, l'incertitude sur l'identité de celui de qui accède au système ERP du backend et sur la version de l'API qui s'exécute peut déclencher la tempête sur les contrôles internes. Par exemple, si un distributeur peut accéder à une commande au travers d'une API et changer sa date - un acte en théorie interdit par un contrôle interne - ce contrôle sera rendu déficient. Le même risque se présente tout du long de cette procédure de contrôle. Une API manquant de la gouvernance adéquate peut perturber l'intégrité des données relatives au chiffre d'affaires.
En conséquence, la gouvernance adéquate implique de développer un ensemble d'objectifs de contrôles d'API basés sur le Cycle de vie et les facteurs liés, tels que la double casquette commerciale et informatique de certains intervenants clés (tout comme avec ITIL pour le service et COBIT pour les processus). Tout processus qui touche à une API et est sujet à un audit de conformité, comme des contrôles internes ou des données confidentielles, devrait remplir les trois objectifs clés de gouvernance suivants :
-
Le Cycle de Vie de l'API devrait être contrôlé afin que seules les versions permises soient en production : à l'étape de planification, en phases de développement et tests, en production et en retraite.
-
Les intervenants clés, tels que les cadres dirigeants, managers des équipes informatiques, équipes de sécurité et auditeurs de conformité devraient avoir une visibilité sur l'état dynamique, actuel de l'API. Ils devraient toujours être sürs que la version qu'ils regardent est la bonne version dans le contexte du cycle de vie.
-
Les API devraient aussi être sujettes aux processus d'authentification et d'autorisation pour protéger le patrimoine informatique de l'entreprise des abus, des menaces envers la disponibilité ou des failles de confidentialité des données, tout en s'assurant que les exigences de surveillance et de contrôle sont remplies.
A propos de l'auteur
Atchison Frazer est un stratège de la mise en réseau et des services, expert en gestion de marchés d'entreprises, des start-ups Gnodal, ServGate et Fortinet aux leaders de l'industrie Cisco et HP.