Quand le MFA ne suffit pas

La règle numéro un de la sécurité du cloud est : « tu utiliseras le MFA en toutes circonstances ». Pourquoi ? Parce que lorsque vous passez au cloud public, vous prenez essentiellement toutes vos interfaces d'administration, vous les regroupez dans un portail ou une API unique, puis… vous les exposez sur Internet, protégées par un nom d'utilisateur, un mot de passe et (peut-être) le MFA. Même lorsque vous utilisez une fédération.

Mais il s'avère que même le MFA ne suffit pas toujours, comme l'ont montré plusieurs violations majeures, dont celle survenue chez Uber.

Il s'agit de l'une des différences les plus déterminantes à comprendre entre le cloud et l'infrastructure traditionnelle, et c'est la raison pour laquelle vous entendez sans cesse la formule « l'identité est le nouveau périmètre ». Avant le cloud, nous gérions notre centre de données depuis des réseaux privés (ou via des points d'accès contrôlés tels que les VPN et les serveurs rebonds). Avec le cloud, tout cela se trouve sur Internet par défaut et il est difficile de le verrouiller, d'autant plus que nous prenons désormais plus souvent en charge des collaborateurs et des administrateurs à distance.

Le MFA est un moyen efficace de protéger l'authentification des utilisateurs et des administrateurs. Nous disposons d'une multitude d'options, allant d'un niveau un peu plus sûr (MFA par messagerie) à un niveau vraiment très sûr (clés matérielles). Mais le problème, même avec le MFA, est que les utilisateurs disposent d'un accès permanent assorti de privilèges permanents. Si vous attribuez un rôle à un utilisateur, il peut se servir de ces autorisations à tout moment après s'être authentifié. Les attaquants le savent et ont mis au point toute une gamme de techniques pour obtenir un accès authentifié. Ils :

• abusent des identifiants statiques, en particulier lorsqu'aucun MFA n'est utilisé.
• contournent certains MFA. Par exemple, ils procèdent à un échange de carte SIM pour intercepter les SMS destinés aux téléphones.
• manipulent les administrateurs par ingénierie sociale afin de désactiver le MFA ou de le réinitialiser sur un appareil qu'ils contrôlent.
• manipulent les utilisateurs par ingénierie sociale pour subtiliser un code MFA.
• dérobent les identifiants de session sur le système d'un utilisateur après que celui-ci s'est authentifié, puis les utilisent depuis un système qu'ils contrôlent.

Une fois l'accès obtenu, l'attaquant commence à explorer les privilèges et finit par les exploiter à des fins malveillantes.

Le moindre privilège est un mythe

Le problème de fond est que nous accordons des autorisations non pas en fonction de ce qu'une personne doit faire à un instant donné, mais de ce qu'elle pourrait avoir à faire à l'avenir. Les utilisateurs, et en particulier les administrateurs, disposent de l'ensemble maximal d'autorisations pour toutes les actions possibles. Toutes les normes de sécurité de la planète affirment que l'IAM doit reposer sur le refus par défaut et le moindre privilège, mais c'est en quelque sorte un mensonge, puisque l'ensemble des « moindres privilèges » est défini par l'ensemble maximal des privilèges dont l'utilisateur aura besoin à un moment donné, et non en permanence.

Même lorsque nous permettons aux utilisateurs de changer de rôle et d'utiliser des autorisations différentes selon les sessions, ils conservent presque toujours l'accès à ces rôles à tout moment. En réalité, le moindre privilège devrait être limité dans le temps, et pas seulement lié à l'utilisateur. Historiquement, nous gérons les autorisations en attribuant des rôles, et les rôles disposent d'autorisations à une certaine portée. « Vous êtes administrateur sur ces 5 comptes et utilisateur standard sur les 98 autres. » Souvent, nous attribuons même plusieurs rôles à un utilisateur ; soit ces rôles combinent leurs autorisations, soit l'utilisateur peut passer de l'un à l'autre selon les tâches à accomplir.

Imaginez à quel point la tâche serait plus difficile pour un attaquant si nous supprimions les privilèges permanents. Au lieu qu'un utilisateur s'authentifie et accède à l'ensemble de ses autorisations, il disposerait d'un accès assorti d'un très petit ensemble d'autorisations et devrait demander une élévation pour toute action potentiellement dangereuse.

Renforcer la sécurité avec des autorisations dynamiques

Je ne propose pas de supprimer le MFA ou les autres mesures de sécurité au niveau de l'authentification. Elles restent d'une importance vitale, mais elles ne suffisent pas toujours. C'est particulièrement vrai dans la sécurité du cloud, en raison du degré d'exposition à Internet qui lui est inhérent. Mais le cloud présente aussi des avantages, parmi lesquels la fédération basée sur les sessions et les autorisations à granularité fine (jusqu'au niveau de chaque appel d'API).

Plutôt que de donner aux utilisateurs un accès permanent à toutes les autorisations dont ils pourraient un jour avoir besoin, nous leur accordons un accès plus limité et ils demandent ensuite l'accès à des privilèges élevés. Ce concept n'est pas nouveau ; c'est celui qu'utilisent depuis des années les produits de gestion des utilisateurs à privilèges. Mais ces produits s'appuient encore souvent sur des techniques lourdes, comme les sessions par proxy et la rotation de mots de passe temporaires. Le cloud est intrinsèquement plus souple, car les modèles IAM natifs sont par nature basés sur les sessions et les privilèges sont définis dans des documents de stratégie (généralement rédigés en JSON).

C'est ainsi que fonctionnent des outils comme notre FireMon Authorization Control. Vous pouvez aussi consulter Netflix ConsoleMe pour un exemple open source. Les utilisateurs demandent l'accès lorsqu'ils en ont besoin, puis les plateformes s'appuient sur des politiques pour déterminer ce qui est nécessaire à l'approbation. Lorsque ces conditions sont réunies, comme la validation par un responsable ou un collègue, l'utilisateur est autorisé à utiliser un rôle le temps d'une session. Les plateformes peuvent même ajouter des conditions, par exemple « n'autoriser cette session que depuis l'adresse IP à l'origine de la demande ». Ces demandes passent généralement par un canal hors bande et utilisent des canaux parallèles comme le ChatOps pour les approbations, ce qui rend le processus volontairement visible, en particulier pour les accès sensibles en production.

La sécurité au niveau des autorisations facilite en réalité la vie de tout le monde, des développeurs et des utilisateurs jusqu'aux administrateurs de la sécurité. Vous n'avez pas besoin de connaître à l'avance l'ensemble des autorisations potentielles. Les utilisateurs demandent plutôt ce dont ils ont besoin au moment où ils en ont besoin. Les politiques déterminent le chemin le moins contraignant pour accorder cet accès sans compromettre la sécurité. Des outils comme le ChatOps permettent à un développeur de demander l'accès à un nouveau compte et d'obtenir une réponse en quelques secondes, au lieu de devoir soumettre une demande dans un système de tickets qui pourrait prendre des jours ou des semaines.

En renforçant la sécurité au niveau des autorisations, nous réduisons l'impact des identifiants dérobés et des authentifications piratées, tout en diminuant les frictions et la charge administrative.