Sécurité du cloud AWS, Azure et GCP

L'unification de la visibilité dans les environnements cloud et la détection précoce des mauvaises configurations en matière de gestion des identités et des accès (IAM) facilitent la gestion du risque lié au cloud et la mise en conformité sans passer par des outils déconnectés les uns des autres.

Cette page décompose les modèles de sécurité des trois principaux fournisseurs de service cloud (CSP) et met en évidence les domaines dans lesquels vos équipes peuvent avoir besoin d'une contextualisation, d'une visibilité ou d'un outil supplémentaire pour sécuriser chaque modèle.

Que vous travailliez dans un seul cloud ou que vous gériez des environnements multicloud, il est essentiel de savoir où s'arrêtent les contrôles natifs et où commence le modèle de responsabilité partagée du cloud pour éviter les mauvaises configurations et les expositions des identités.

Amazon Web Services (AWS) opère sous un modèle de responsabilité partagée. AWS sécurise l'infrastructure et vous êtes responsable de vos configurations, de vos contrôles d'accès et de la protection de vos données.

AWS propose des outils natifs pour la détection des menaces, l'IAM pour la gestion des accès et une visibilité centralisée. Pourtant, les mauvaises configurations cloud, comme les buckets S3 publics et les rôles IAM surprivilégiés, restent des risques courants.

Une plateforme de sécurité cloud comme Tenable renforce la sécurité d'AWS en s'intégrant aux API natives pour découvrir les expositions liées aux identités et les mauvaises configurations des assets. Elle établit une corrélation entre les clés d'accès inutilisées et les endpoints publics afin de mettre en évidence les assets induisant une exposition (EIA) et de signaler les chemins à haut risque entre les services de calcul et de données.

Le modèle de responsabilité partagée de Microsoft Azure place la sécurité des configurations et des identités entre vos mains.

Cependant, des rôles de contrôle d'accès basés sur le rôle (RBAC) étendus, des endpoints exposés et des ressources non surveillées continuent d'introduire un risque.

Les outils d'Azure manquent souvent de corrélation multi-abonnements et de contextualisation entre les identités et les charges de travail.

Tenable comble ces lacunes en analysant les données CIEM pour détecter les mauvaises configurations des identités dans Entra ID.

Par exemple, un principal de service mal configuré doté d'autorisations inutiles pouvant donner accès à un stockage sensible signalé comme faisant partie d'une combinaison toxique permet de prioriser une menace réelle.

La plateforme s'intègre à Azure Policy pour faire respecter les bases de référence de configuration et rationaliser la remédiation grâce à la Policy as Code.

Le modèle de responsabilité partagée de Google Cloud vous confie le contrôle des identités, des ressources et des données. Security Command Center, VPC Service Controls et IAM constituent vos premières lignes de défense.

Il n'en reste pas moins que les comptes de service par défaut, les liaisons IAM trop permissives et la désactivation de la journalisation sont souvent à l'origine d'incidents liés à la sécurité du cloud.

La hiérarchie des ressources de GCP (projets, dossiers, entreprises) vient encore complexifier la protection des charges de travail cloud.

Tenable s'intègre aux API GCP pour connecter le risque lié aux identités à l'exposition des charges de travail.

La solution signale par exemple les comptes de service inactifs dotés de privilèges élevés liés à des fonctions publiques. Elle permet d'établir une corrélation entre les identités et les données, ce qui est indispensable pour prévenir l'élévation de privilèges et tout mouvement latéral.

La plateforme prend également en charge l'application des règles grâce à Google Cloud Policy Intelligence et aligne les détections sur des analyses comparatives telles que les Benchmarks CIS.

Si AWS, Azure et GCP prennent tous en charge l'IAM, la journalisation, le chiffrement et la surveillance, les détails de leur mise en œuvre diffèrent considérablement :

• AWS utilise des politiques et des relations d'approbation.
  • Azure s'appuie sur les rôles RBAC et sur Entra ID.
  • GCP utilise des comptes de service et des rôles définis par projet.
• Les paramètres de journalisation, de chiffrement et de pare-feu varient considérablement.
  • Un fournisseur peut définir un accès permissif par défaut, vous obligeant à le restreindre manuellement.
• Les outils natifs offrent différents niveaux de contexte.
  • Azure Defender bénéficie d'une intégration plus poussée avec Microsoft 365.
  • GCP met l'accent sur l'isolement des projets.

Il est donc essentiel d'adopter une stratégie de visibilité multicloud. En effet, si vous ne vous appuyez que sur des outils natifs, vous laissez des angles morts dans votre environnement et ne serez pas en mesure de connecter les risques liés aux identités, aux charges de travail et aux données.

Les fournisseurs cloud proposent des outils intégrés, mais ils sont souvent cloisonnés par service ou par compte.

Une plateforme de protection des applications cloud native (CNAPP), comme Tenable, combine ces informations natives avec le contexte des identités, des charges de travail et des données, ce qui vous permet de bénéficier d'une vue d'ensemble complète.

Alors que les outils natifs offrent des solutions ponctuelles, les CNAPP rassemblent tout, de sorte que votre équipe peut prioriser les éléments à risque plutôt que les éléments mal configurés.

• Ajoutez une solution CNAPP comme Tenable Cloud Security pour unifier le risque lié aux identités, aux mauvaises configurations et aux données entre les fournisseurs.
• Priorisez les mauvaises configurations qui exposent vos assets sensibles, et pas seulement les violations des meilleures pratiques.
• Adoptez des approches « Policy as Code » et « Shift-Left » pour détecter les problèmes très tôt dans votre pipeline.

Pour en savoir plus sur la détection des menaces spécifiques au cloud, la remédiation et l'intégration des politiques, visitez le hub de sécurité du cloud de Tenable.