Implications de l’écart AuthN/AuthZ

Il est désormais admis que, dans le cloud, « l’identité est le nouveau périmètre ». La formule est élégante et facile à glisser dans une présentation ou un article, mais la transformer en recommandations concrètes est un peu plus ardu. Aujourd’hui, je souhaite me concentrer sur un seul aspect de l’IAM cloud, que j’appelle l’« écart AuthN/AuthZ ». Il s’agit en réalité d’un problème qui se pose dès que vous recourez à la fédération, mais les enjeux sont plus élevés dans le cloud, car le plan de gestion cloud est toujours exposé sur Internet.

Tout d’abord, un bref rappel sur AuthN et AuthZ :

• AuthN désigne l’authentification. L’action de prouver que vous êtes bien une entité donnée. Pour le commun des mortels, cela passe généralement par un nom d’utilisateur, un mot de passe et, éventuellement, une authentification multifacteur.
• AuthZ désigne l’autorisation. L’action de vérifier si une opération est permise. Dans le cloud IaaS, cela correspond presque toujours à un appel d’API, même lorsque vous utilisez la console ou le portail web.

L’authentification et l’autorisation sont deux tâches distinctes, avec des flux distincts. Lorsque nous nous connectons à un site web, nous nous authentifions, ce qui crée généralement une session. Nous n’avons pas à ressaisir nos identifiants à chaque clic : notre navigateur transmet simplement un jeton valide pendant une certaine durée. Les autorisations, elles, sont généralement vérifiées à chaque action, afin de s’assurer que nous disposons des droits requis.

Si l’on y réfléchit, une fois ce jeton de session obtenu, il n’est plus vérifié, sauf si quelque chose dans le code impose une nouvelle vérification. Votre authentification reste valide pour toute la durée de la session, et vous pouvez donc effectuer tout ce qui relève de vos autorisations. Selon la plateforme ou le système, ces identifiants temporaires continueront de fonctionner même s’ils sont révoqués ou si le compte est entièrement supprimé. C’est cela, l’écart AuthN/AuthZ.

Je consacre beaucoup de temps à ce sujet lorsque j’enseigne la réponse aux incidents dans le cloud, car j’ai constaté que même des intervenants en sécurité expérimentés n’en mesurent pas toujours les implications. Imaginez un vol d’identifiants cloud : vous révoquez ou supprimez ces identifiants, mais l’attaquant dispose d’une session active ouverte et peut potentiellement continuer à exécuter des actions autorisées. C’est… problématique.

Comment y remédier ?

Selon l’usage que vous faites de ces identifiants, la solution la plus simple consiste généralement à modifier l’autorisation. Il suffit d’appliquer une stratégie de refus à l’entité (ou de supprimer les actions autorisées), puisque celle-ci est évaluée à chaque appel d’API effectué par l’attaquant. Bien qu’il s’agisse de l’option la plus simple, ce n’est pas toujours la meilleure, car elle peut interrompre des tâches en cours (les identifiants volés ne sont pas toujours liés à des utilisateurs). Parmi les autres possibilités, selon la prise en charge offerte par votre fournisseur cloud :

• Ajouter des conditions afin de restreindre l’adresse IP d’origine des appels d’API.
• Refuser toutes les sessions créées avant une date ou une heure donnée.

Vous risquez davantage de rencontrer ce problème lors d’une fédération vers un fournisseur cloud qu’au sein même de ce fournisseur. Je viens de réaliser un test dans AWS et j’ai perdu l’accès sur les sessions ouvertes assez rapidement après la suppression d’un utilisateur IAM. En revanche, il n’en va pas nécessairement de même lors d’une fédération depuis un fournisseur d’identité externe, et même au sein d’AWS, certains services ne revérifient pas les identifiants pendant les sessions actives (par exemple, ma session Session Manager est restée active pendant environ 15 minutes ou plus après la suppression du rôle qui en autorisait l’accès).

Il ne s’agit pas d’une grande vulnérabilité inconnue, mais d’un élément à garder à l’esprit lors de l’élaboration de vos contrôles de sécurité cloud et de vos playbooks de réponse aux incidents. Les différents types d’identifiants ont des durées de vie différentes, d’un fournisseur cloud à l’autre comme au sein d’un même fournisseur. Votre fournisseur d’identité entre également en ligne de compte, de même que l’endroit où vous tentez de révoquer les identifiants. Par exemple, si vous disposez d’un utilisateur dans Active Directory que vous fédérez ensuite vers AWS, et que cet utilisateur endosse un rôle dans AWS et obtient des identifiants de session pour ce rôle, vous devez révoquer ou restreindre les identifiants du rôle endossé, même si vous restreignez l’utilisateur dans AD. AWS n’aura aucun moyen de savoir que la session de l’utilisateur issue d’AD n’est plus valide, jusqu’à la fin de la session, au moment où il procédera à une nouvelle validation de l’authentification.

En interne, nous sommes passés à notre outil Authorization Control, qui prend en charge la création de sessions assorties de restrictions via ChatOps, sans introduire de friction susceptible de ralentir nos développeurs. Il n’est pas encore disponible en version générale, mais si vous souhaitez l’essayer en accès anticipé, il vous suffit de m’écrire directement à rich.mogull@firemon.com.