PAM et sécurité du cloud : supprimer les privilèges permanents

La gestion des accès à privilèges suppose que toute identité doit être gérée, certes, mais surtout sécurisée, afin de protéger les ressources les plus précieuses d'une entreprise.

Le cabinet américain Gartner révèle un intérêt croissant des organisations pour la gestion des accès distants. En revanche, l’adoption croissante du cloud fait émerger des environnements, des rôles et des cas de figure entièrement inédits qui obligent à repenser la gestion des accès à privilèges (PAM) et à revoir les pratiques pour appliquer les principes de cette gestion à la sécurisation des identités. La gestion des accès à privilèges suppose en effet que toute identité doit être gérée, certes, mais surtout sécurisée, afin de protéger les ressources les plus précieuses d’une entreprise.

Le rapport 2023 Data Breach Investigations Report de Verizon, par exemple, mentionne le vol d'informations d'identification et l'utilisation abusive de privilèges comme facteurs contribuant à de nombreuses failles. Il est donc important d’imposer le principe de moindre privilège, les contrôles d’accès basés sur les rôles, ainsi que des systèmes permettant d’auditer des sessions à haut risque. La difficulté consiste à appliquer ces principes aux nouveaux environnements propres au cloud.

De nouveaux environnements impliquant de nouvelles exigences de sécurité

Il n’est pas difficile d’identifier les responsabilités de sécurité dans les environnements sur site où chaque couche d’infrastructure est clairement circonscrite. Généralement, il est possible de retrouver un datacenter physique, des câbles réseau, différents protocoles réseau, des racks physiques contenant des systèmes informatiques ou du stockage, et ainsi de suite, de la base au sommet de la pile informatique. Or, les frontières entre ces différents domaines de responsabilité disparaissent complètement avec le cloud, qu’il s’agisse d’un environnement hybride (avec certains workloads déplacées vers le cloud) ou que l’on adopte une approche cloud-native (où les applications sont conçues via une architecture de microservices).

Par exemple, une pratique courante dans le cloud, avec un utilisateur d’AWS provisionnant un bucket S3 pour stocker des fichiers électroniques. Dans une infrastructure sur site, cela revient à apporter un rack dans un datacenter, l’y installer et y connecter des disques durs, puis des câbles Ethernet. Naturellement, une telle opération ne serait jamais autorisée dans un environnement traditionnel. Cet exemple illustre bien la raison pour laquelle il est impossible de considérer l’accès à un fournisseur de services cloud (CSP) comme une console parmi d’autres dans des environnements de ce type.

Une analyse des trois principaux CSP montre qu’un même utilisateur peut accéder à environ 1 400 services natifs, offrant au total environ 40 000 contrôles d’accès distincts, et ce nombre ne cesse d’augmenter. Ainsi, le modèle traditionnel d’une petite équipe d’administrateurs aux privilèges définis une fois pour toutes n’est pas adapté à de tels environnements.

La surcharge de travail des administrateurs et l’évolution des rôles

Les applications traditionnelles ont des profils clairement différenciés pour les administrateurs et les utilisateurs, où ces derniers n’ont généralement pas accès aux systèmes et données sensibles. Par exemple, un salarié utilisant Outlook peut envoyer et recevoir des e-mails, mais il lui est impossible de modifier les paramètres POP ou SMTP, par exemple, ou d’ajouter ou de supprimer des utilisateurs. En revanche, toute personne disposant d’un accès au cloud peut obtenir des droits lui permettant d’exploiter 1 400 services natifs aux capacités allant des fonctionnalités basiques, comme le calcul ou le stockage, à des outils plus sophistiqués tels que des moteurs d’intelligence artificielle ou de machine learning. Ce que beaucoup ignorent, c’est que ces 1 400 services natifs comprennent également toute une série de services SaaS, tels que des moteurs de workflow, des outils de traitement vidéo et des messageries instantanées. De toute évidence, quiconque est en mesure d’acheter et d’utiliser de tels services peut être considéré comme un administrateur.

Il faut aussi noter l’apparition d’un nouveau type d’administrateur : les développeurs de logiciels. À quelques exceptions près, tous les outils et processus modernes de développement s’utilisent ou s’effectuent dans le cloud, où sera ensuite déployé le logiciel produit. Ainsi, les développeurs peuvent désormais être assimilés à des administrateurs du cloud et leurs identités doivent être protégées en conséquence. Malgré cela, la sécurité des identités est trop souvent sacrifiée pour gagner en rapidité.

Parmi les professionnels de la sécurité, 77% estiment que les développeurs disposent de trop de privilèges et deviennent, de ce fait, des cibles de choix pour les hackers, ce qui pénalise la sécurité des entreprises. Ces développeurs disposent en effet d’autorisations étendues pour parer à toutes les situations auxquelles ils peuvent être confrontés sur des systèmes rigides et statiques. Comme ces développeurs doivent être en mesure d’innover, ils ne peuvent pas attendre qu’on leur crée et sécurise des comptes partagés pour chaque service ou workload à modifier, en particulier si ces derniers n’ont qu’une existence éphémère. Mais une telle approche manque trop de flexibilité pour répondre aux bonnes pratiques des fournisseurs de cloud et occasionne des retards inacceptables dans les plannings d’ingénierie.

Architectures cloud et cas de figure inédits

L’essor des microservices a généré de formidables économies d’échelle, gains d’efficacité et réductions de coûts. Cependant, il a également créé un enchevêtrement de dépendances et de complexité pour toute application cloud native digne de ce nom. Dans un contexte d’architectures de microservices dans le cloud, la moindre panne a un impact sur tous les clients : aucun processus n’est isolé. Il n’est plus question d’applications ERP monolithiques individuelles ni d’outils de messagerie où seul un segment d’utilisateurs était impacté en cas d’instabilité ou de panne. En cas d’incident, les ingénieurs doivent être en mesure d’accéder à n’importe quel point de l’environnement de production pour localiser, diagnostiquer et résoudre le problème. Une telle liberté était naturellement inimaginable dans un environnement informatique classique.

Zéro privilège permanent : une approche pratique de la sécurité des identités dans le cloud

Une nouvelle approche est nécessaire pour appliquer les principes Zero Trust sans ralentissement dans des environnements avec ces rôles et ces types de problèmes : le système « Zéro privilège permanent » (ZSP). Ce système supprime complètement les droits inactifs d’un utilisateur, mais peut en fournir de façon dynamique, à chaud, au gré des besoins. En outre, le système ZSP élimine la possibilité d’une attaque par mouvement latéral et exploite les informations d’identification intégrées pour assurer une bonne application des politiques en vigueur.

Les professionnels de la sécurité doivent limiter les accès et les risques, mais sans pour autant ralentir les développeurs, les équipes DevOps et les services informatiques. Miser sur l’approche ZSP constitue le moyen le plus viable d’atteindre ces objectifs tout en empêchant le vol d’informations d’identification et en bloquant tout mouvement latéral afin que les entreprises puissent profiter pleinement de tous les avantages du cloud.