Cloud : cinq étapes pour sécuriser la console d’administration
Le verrouillage de la console d’administration est essentiel pour maintenir la sécurité de ses déploiements cloud, et encore plus dans les environnements multicloud. Et cela ne nécessite pas des efforts insurmontables.
À mesure qu’elles utilisent de plus en plus de ressources et services cloud, les entreprises se retrouvent responsables de tout un éventail de consoles d’administration. Ce que l’on appelle parfois le plan de contrôle du cloud, ou cloud control plane.
Si ce plan n’est pas verrouillé proprement, il peut être vulnérable à de nombreuses attaques variées. Il est d’ailleurs arrivé fréquemment que les identifiants de comptes à privilèges soient attaqués et détournés sur des consoles d’administration cloud. Par exemple, l’hébergeur de code Code Spaces a mis la clé sous la porte en 2014 après le détournement d’un compte d’administration de sa console AWS. En 2018, de nombreuses interfaces d’administration Kubernetes ont été détournées pour créer des instances de conteneurs dédiées au minage de crypto-sous, dont une appartenant à Tesla. Et ce ne sont que deux exemples parmi bien d’autres.
Pour mieux sécuriser le plan de contrôle du cloud, il est important de suivre les cinq pratiques de référence suivantes.
1. Faire l’inventaire des comptes
Il est nécessaire de définir et inventorier avec soin les utilisateurs – et les comptes correspondants – qui ont besoin de droits administratifs sur les environnements cloud de leurs entreprises. Cela relève de la base de la gestion des identités et des accès, mais il peut être étonnamment difficile d’examiner les rôles et les fonctions nécessaires au sein d’une organisation suivant les services cloud.
Certains services SaaS peuvent n’avoir qu’un seul type de rôle administrateur, par exemple, mais la plupart des services PaaS et IaaS disposent d’un large éventail de politiques d’identité et de niveaux de privilèges. La création d’un modèle durable de moindre privilège efficace peut prendre du temps et des ressources. Mais c’est l’un des domaines les plus critiques sur lesquels il faut se pencher, non seulement lors de la mise en place des services cloud, mais aussi pour ce qui est déjà en cours d’exploitation.
Fédérer autour d’un référentiel unique des utilisateurs, tel qu’Active Directory, avec une authentification unique (SSO) – en utilisant soit des passerelles d’identité sur site, soit une offre d’IDaaS – permet de simplifier considérablement la gestion du cycle de vie des comptes, ainsi que leur surveillance centralisée.
2. Authentification à facteurs multiples
Pour tous les comptes d’administration, activer l’authentification à facteurs multiples (MFA) et en imposer strictement l’utilisation. Code Spaces n’aurait pas été fermé si la MFA avait été activée pour l’accès à la console administrative AWS. Idéalement, la MFA doit être imposée pour tous les comptes permettant d’interagir avec le plan de contrôle. Mais cela peut avoir des effets négatifs sur les efforts d’automatisation. Il convient donc de chercher à appliquer la MFA autant que possible tout en s’assurant de ne pas bloquer certains automatismes impliquant des comptes de service.
3. Journalisation
Un troisième aspect essentiel de la sécurisation du plan de contrôle dans le cloud consiste à activer la journalisation pour tout l’environnement. C’est facilement réalisable dans les principaux services d’IaaS, avec AWS CloudTrail, Azure Activity Log et Google Cloud Platform (GCP) Stackdriver.
Il faut bien sûr surveiller ces traces d’activité et les examiner régulièrement, mais la première étape consiste à activer la journalisation pour l’ensemble de l’environnement.
4. Restreindre l’accès aux API
Veiller à ce que tout accès aux API soit limité à un petit groupe d’utilisateurs et soit rigoureusement contrôlé et surveillé. L’interface de ligne de commande AWS, Azure PowerShell ou les API Cloud de GCP peuvent être facilement détournés, en particulier avec un accès privilégié. Il convient donc d’en limiter l’accès aux seules adresses IP ou sources fiables si ce type de modèle d’accès programmatique est activé et exploité.
5. Restrictions additionnelles
Il est également pertinent d’interdire l’utilisation de toute ressource ou région que l’organisation n’utilise pas au départ. Les politiques d’identité peuvent être utilisées pour restreindre l’accès à certains services supplémentaires proposés par le fournisseur, et la plupart des principaux fournisseurs de services cloud permettent de désactiver toute région géographique que l’on n’utilise pas ni ne prévoit d’utiliser.
Petits plus
Les mesures ci-dessus permettent de réduire considérablement la surface d’exposition, mais il est possible d’aller encore plus loin. Pour aider à surveiller et à verrouiller le plan de contrôle cloud, il est possible de faire appel à des outils dédiés à la gestion de la posture de sécurité cloud (CSPM). Ceux-ci s’avèrent particulièrement utiles dans les déploiements multicloud.
Les produits et solutions de CSPM peuvent être intégrés à de nombreux fournisseurs de services cloud afin d’analyser et d’évaluer en permanence l’état des contrôles de sécurité, d’identifier les défauts de configuration, de signaler les vulnérabilités ou encore de suggérer les pratiques de référence à mettre en œuvre à un tableau de bord central.
Pour approfondir sur Sécurité du Cloud, SASE
-
IAM : l’importance du provisionnement et du déprovisionnement des utilisateurs
-
Administration cloud : comment sécuriser Azure Functions avec Entra ID
-
« MFA : la sensibilisation des collaborateurs est nécessaire » (Antoine Coutant, Synetis)
-
Authentification : Microsoft met en garde contre les attaques en détournement de jetons