Vers un SI de plus en plus décentralisé…

Ces dernières années, les entreprises ont fait face à un élargissement du champ d’action de l’Identity and Access Management. Cette discipline n’est plus uniquement centrée sur les problématiques de provisioning utilisateur et d’authentification ; elle s’est tournée non seulement vers des problématiques de revue et de certification des comptes mais aussi vers l’utilisation des mécanismes de fédération d’identités (eg. SAML). Ces changements concernent aussi bien les applications SaaS que les applications restées en interne. Ces évolutions ont chacune permis une ouverture du SI toujours plus large, et nécessitent par conséquent d’être correctement implémentées pour limiter les failles de sécurité.

Cette évolution de l’IAM se fait en parallèle de la généralisation des services Cloud, qui ne cessent de donner naissance à de nouveaux usages pour plus de flexibilité et de souplesse dans l’accès et l’utilisation du SI. Les utilisateurs internes accédant au SI le font de plus en plus majoritairement depuis l’extérieur du réseau de l’entreprise, et ce depuis des terminaux de plus en plus variés.

En outre, les nouvelles technologies agiles et DevOps poussent le SI à évoluer différemment, intégrant beaucoup plus rapidement de nouvelles technologies (IoT, etc.) et de nouveaux usages.

Toutes ces évolutions font aujourd’hui du SI une bulle parmi d’autres interagissant avec son environnement et devant maîtriser, à distance, des interactions entre des composants décentralisés.

 

… rendant les APIs incontournables

Ce nouveau modèle décentralisé du SI donne naissance à la problématique d’interconnexion des services et des applications : comment assurer l’accès aux données à chaque instant et en chaque endroit ?

Aujourd’hui les APIs (Application Programmable Interface) représentent déjà un mécanisme de communication prépondérant et incontournable pour toute entreprise lancée dans sa transformation numérique. Elles sont utilisées dans  les traitements réalisés non seulement sur des données publiques (adresses d’agences, horaires des transports, etc.) mais aussi sur des données personnelles (tracking fitness, application Ameli et CAF, etc.) et des données sensibles (DSP2, achat en ligne, informations industrielles en mobilité, etc.).

Face à son importance dans le SI, la question de la sécurisation des APIs se pose plus que jamais.

Quelle recette pour sécuriser ses API ?

La sécurisation des API passe par une recette à base de 4 ingrédients à doser finement.

Une base de security as usual

Selon un benchmark Wavestone sur le sujet de la sécurité des applications web, sur 128 applications auditées, des failles graves sont observées dans 60% des cas et la situation est très similaire pour les APIs. À cet effet, les recommandations habituelles de la sécurité web, par exemple celles d’OWASP doivent être prises en compte de la même manière.

Il s’agit essentiellement de s’assurer de couvrir les principales zones à risques d’une application web et de déterminer les mesures de sécurité appropriées.

 

Une pincée d’OAuth

OAuth est un framework de délégation d’autorisation qui permet à une application d’obtenir l’autorisation d’accès à une ressource au nom d’un utilisateur.

OAuth se propose de couvrir un large éventail de cas d’usages (applications web, mobile, accès ou non à un navigateur, accès serveur-à-serveur, etc.) et offre à cet effet 4 cinématiques principales pour obtenir un jeton. Combiné à une spécification détaillant l’utilisation de ce jeton, un document détaillant le threat model, et enfin une surcouche dédiée à l’authentification (OpenID Connect), il s’agit d’un corpus documentaire équivalent à 250 pages, laissant une place certaine à un grand nombre d’options et de choix d’implémentation.

Et c’est bien cette abondance d’options et ce manque de contraintes qui entraînent les failles de sécurité observées régulièrement dans la mise en place d’OAuth2.0 : usurpation d’identité d’une application, accès aux données personnelles d’un utilisateur tiers, vol de cookie Facebook/Google lors d’un social login ou encore compromission de compte utilisateur.

Les six recommandations suivantes sont essentielles pour une mise en place sécurisée du Framework :

• Secret local : L’application est munie d’identifiants lui permettant de s’authentifier auprès du serveur OAuth : ne pas mettre ce secret (identifiant du service) dans l’application mobile ou le considérer compromis
• Redirect URI: Valider strictement les URLs de redirection vers l’application, sans wildcard
• Implicit: Éviter le « Implicit grant » dans la mesure du possible (et se tourner vers le proxy pattern)
• Authorization code: Valider strictement les authorization codes et clients associés
• State and PKCE: À utiliser pour garantir l’intégrité d’une cinématique complète
• Authorization ≠ Authentication: Utiliser OpenID Connect pour authentifier, OAuth pour déléguer l’accès

Limitez les additifs

À peine cette première pincée d’OAuth digérée, il faut déjà réfléchir à des solutions de sécurité permettant de répondre aux besoins que nous rencontrons le plus fréquemment.

Le Single Sign-On mobile, ou comment permettre à des employés en mobilité ou des clients d’accéder aisément aux applications sans se réauthentifier ?

Qu’il s’agisse d’un agent terrain en contact clientèle ou en tournée d’intervention qui peut utiliser plus d’une dizaine d’applications par jour ou qu’il s’agisse d’un client ayant installé plusieurs applications sur le store public, le besoin d’accéder à l’ensemble des applications sans avoir à se réauthentifier sur chacune est aujourd’hui très présent. Si, depuis 2008, les techniques le permettant ont varié au gré des possibilités offertes par les OS mobiles (KeyChain iOS, paramètres d’URL, Mobile Device Management…), Apple et Google ont convergé vers une solution commune en 2015 : utiliser le navigateur système comme point d’ancrage d’une session SSO. C’est maintenant une bonne pratique officielle matérialisée par la BCP « OAuth2 for native applications »

L’authentification contextuelle, ou comment adapter le niveau d’accès à une donnée en fonction de la criticité de celle-ci ?

Un des nombreux enjeux concernant l’authentification est de simplifier au maximum l’accès des utilisateurs à leurs données tout en garantissant un niveau de sécurité satisfaisant. L’authentification contextuelle permet de répondre à cet enjeu, en adaptant le niveau d’accès à la nature de la transaction, à ses caractéristiques, aux habitudes utilisateurs, à son contexte…. On parle de LOA (Level of Assurance). Dans le cadre d’une application mobile bancaire, cela permet à l’utilisateur de consulter son compte en banque, de bénéficier de la météo de ses comptes sans avoir à se réauthentifier à chaque accès. L’application requerra toutefois une authentification au moment de réaliser une opération sensible (un virement interne par exemple), et une authentification forte au moment de réaliser une opération très sensible (ajout d’un bénéficiaire par exemple).

Les solutions du marché proposent aujourd’hui des solutions pensées selon une logique où le client applicatif est responsable d’initier la demande de LOA correspondant à la donnée ou au service auquel il souhaite accéder. Mais le vrai besoin consiste à définir et appliquer ces politiques d’accès aux données de manière centralisée, au sein du serveur d’autorisation. Il s’agit notamment d’un besoin essentiel lorsque l’on veut appliquer une authentification liée au niveau de risque du contexte (géolocalisation, terminal connu ou non, habitudes de transactions, etc.)

Propagation de l’identité, ou comment transmettre un jeton d’accès entre deux applications (ou plus) ?

Il est courant qu’un appel vers une API déclenche une cascade d’appels vers d’autres API, notamment dans le cadre d’une architecture de type micro-service. La transmission de l’identité de l’utilisateur doit alors être assurée sans créer de risque de sécurité. Et les trois premières solutions qui viennent à l’esprit présentent des limites :

• La transmission du token initial est évidement à proscrire, à la vue du risque de fraude interne très élevé que cela entrainerait.
• L’authentification de l’appelant seule n’est pas suffisante non plus, car un composant compromis dans la chaîne peut usurper l’identité de n’importe quel utilisateur et compromet le reste de la chaîne.
• La génération d’un token pour l’appelant transmis avec le token de l’utilisateur initial ne permet pas d’assurer l’intégrité de la combinaison utilisateur/API et ne permet pas de vérifier la chaine.

Une ébauche avancée de solution existe aujourd’hui, proposant un nouveau grant type : Token Exchange. Ce mécanisme permet à l’appelant de demander un jeton intermédiaire, composé notamment de l’identité de l’utilisateur, de l’identité de l’appelant et de la chaine d’appel déjà effectuée. Cette nouvelle cinématique permet de centraliser la politique d’appel entre micro-service et l’application de cette politique, et d’assurer la traçabilité des appels.

Protection contre le vol de jeton, ou comment se prémunir du vol d’un ou d’une base de jetons ?

Par principe, le jeton contient de nombreuses informations sur son porteur, ce qui entraîne un risque important en cas de vol. Plus impactant encore, dans certains contextes (e.g. DSP2), un tiers (agrégateur) peut se retrouver en possession de très nombreux jetons, et le propriétaire de l’API se retrouve à la merci de ce tiers et de son niveau de sécurité. La détection du vol étant très difficile, il a fallu trouver d’autres solutions comme le Token Binding, un mécanisme de négociation à deux ou trois composants, permettant de lier un jeton à une paire de clés cryptographiques, et dans lequel le client doit prouver qu’il possède la clé privée constituant une partie de cette paire en établissant une connexion TLS mutuelle avec l’API.

Écrire la recette

Dernier ingrédient de la recette, il convient de décliner une architecture de référence de OAuth pour l’adapter au contexte du SI de l’entreprise. Pour cela, il faut définir le cadre d’utilisation des API en :

• Définissant et partageant les règles de sécurité : Les cinématiques autorisées et le cadre d’application, les checklists sécurité et l’architecture de référence doivent être formalisées.
• Formant et outillant les développeurs: Des sessions de formation et de présentations des principes adoptés doivent être organisées. Les équipes projets peuvent être rendues autonomes dans leur intégration au reste du SI.
• Intégrant les ressources sécurité dans les sprints agiles: Les ressources agissant en tant que coach sécurité doivent être identifiées pour accompagner la conception applicative et apporter des solutions prêtes à l’emploi et être un accélérateur

 

En synthèse

Au final, comme la recette du bon miel, sécuriser des APIs nécessite une succession d’ingrédients allant du plus basique jusqu’au plus élaboré tout en tenant compte du besoin et du contexte.