Principes de sécurité des fournisseurs de cloud (CSP) et détection

1. Introduction : la philosophie du cloud et de ses utilisateurs

D’après la légende, le cloud est né d’une volonté de Jeff Bezos de faire collaborer les différentes fonctions d’Amazon via des API dès 2002. Après plusieurs années d'évolution, ce système a accouché d’AWS, qui a été suivi notamment par Google avec GCP, Microsoft avec Azure et de nombreux autres.

Les services cloud (Cloud Service Providers ou CSP dans le reste de l’article) ont en général été conçus avec des exigences de sécurité répondant aux usages les plus avancés (le gouvernement américain ou de nombreuses banques sont des utilisateurs notoires des CSP). Les mécanismes d’identité, d’authentification et d’autorisation sont poussés et flexibles pour répondre à ces exigences.

Nous verrons quels principes de sécurité ont émergé d’un modèle où la frontière entre hébergeur et hébergé est moins nette que dans le monde physique. D’autre part, nous verrons que le modèle API centrique des CSP a permis l’émergence d’outils de sécurité puissants, où l’inventaire comme les détections sont à la fois temps réel et exhaustifs.

Enfin, nous verrons que cette attention à la sécurité ne rend pas les CSP exempts de vulnérabilités, mais que la majorité des attaques cible quelques vulnérabilités bien connues provenant de mauvaises pratiques de la part des utilisateurs.

2. Hors sujet pour cet article

Cet article considérera comme cloud des acteurs fournissant des API de gestion de l’infrastructure. Sont donc exclus de ce modèle :

• Heroku et les solutions de type PaaS ;
• VMWare et les hyperviseurs, qui ne sont qu’un élément parmi d’autres dans un cloud ;
• Kubernetes, un service offert par chaque CSP.

Les recommandations de cet article sont applicables dans son propre cloud (par exemple avec [OpenStack]).

3. Principes de sécurité des CSP

3.1 Responsabilités respectives du CSP et de l’utilisateur

Le CSP est responsable de la sécurité du cloud, quand les utilisateurs sont responsables de la sécurité dans le cloud.

Par exemple :

• Sont sous la responsabilité du CSP :
  • la sécurité des composants opérés par le CSP (bases de données, OS sous-jacents, hyperviseurs, équipements réseau…) ;
  • la sécurité des logiciels propres aux CSP, en particulier relatifs à son administration (API, contrôle d’accès…) ;
  • les infrastructures physiques.
• Sont sous la responsabilité de l’utilisateur :
  • le code déployé ;
  • la sécurité de ses données ;
  • la configuration et la mise à jour des OS des charges de travail (si l’OS utilisé est fourni par le CSP, ce dernier fournira les mises à jour, mais l’utilisateur devra les appliquer) ;
  • le cloisonnement réseau ;
  • la gestion des utilisateurs et de leurs permissions ;
  • la gestion des secrets et de leur cycle de vie.

Certains produits cloud fournissent différents modèles d’abstraction, déformant les zones de responsabilité. Par exemple, les services dits serverless vont déplacer certaines responsabilités depuis l’utilisateur vers le CSP : le système d’exploitation sera configuré et mis à jour par le CSP.

3.2 Charges de travail

Les meilleures pratiques de sécurité usuelles s’appliquent (SDLC, minimisation, etc.). Le point le plus critique concerne leurs permissions, nécessaires pour accéder à des éléments gérés par le CSP. Elles doivent répondre au principe du moindre privilège.

Les charges de travail héritent d’un rôle définissant leurs permissions.

3.3 Gestion et cloisonnement des comptes

Un compte de CSP est défini comme une unité logique à laquelle appartiennent des ressources telles que des machines virtuelles, des load balancers, des règles de routage réseau...

Des ressources ayant besoin d’environnements d’exécution différents sont séparées en différents comptes, afin de les cloisonner, d’un point de vue données, administratif, facturation… Par exemple, utiliser des comptes différents pour le développement, la préproduction et la production, mais peut-être aussi par équipe voire par service. Il est courant que des utilisateurs de CSP possèdent plusieurs dizaines voire centaines de comptes [need-more-than-one].

Les comptes suivent une structure arborescente où chacun dispose de sa propre configuration et hérite des politiques définies sur les comptes parents.

3.4 Gestion des identités et des accès

La gestion des utilisateurs est idéalement centralisée et suit les meilleures pratiques usuelles (centralisation via SSO, mot de passe fort, authentification à deux facteurs…).

Pour les machines, les CSP supportent l’attribution de rôles. Par exemple, une machine virtuelle ou un container disposent d’un rôle qui peut être passé à l’application hébergée, afin d’accéder à certaines ressources authentifiées du CSP.

Les accès programmatiques se font à l’aide d’un secret, et il est recommandé d’utiliser des [secrets temporaires] pour réduire l’impact de fuites potentielles.

Pour des accès à des systèmes tiers, les CSP proposent des gestionnaires de secrets pour centraliser les informations d’authentification.

3.5 Détection

La détection s’applique au comportement des ressources du cloud (natives ou déployées par l’utilisateur), et à la configuration du cloud.

Les changements de configuration sont parfois causés par le mouvement latéral d’un attaquant, une augmentation de privilèges ou une tentative de voler des données.

Une fonctionnalité native des CSP permet d’obtenir la liste des appels à leurs API (similaires à des journaux d’audit). L’API étant la seule façon de changer la configuration de consulter des ressources sensibles telles que les utilisateurs ou les permissions, ces journaux d’audit sont la source des détections de sécurité.

Voici un extrait d’[AWS CloudTrail] où un utilisateur « Alice » a ajouté « Bob » au groupe « admin » :

Ici, un système de détection pourrait lever une alerte puisqu’un nouvel utilisateur a été créé. Cette action peut avoir de nombreuses origines, par exemple :

• Le compte d’Alice a été volé (pas d’authentification multifacteur configurée comme indiqué par le champ mfaAuthenticated) ;
• Les clefs d’Alice ont été volées ;
• ...

Les données de facturation ou de performance sont également des indicateurs intéressants.

3.6 Disponibilité

Les CSP sont en général architecturés avec des régions géographiques (par exemple, France ou Amérique du Nord - Ouest), et des zones de disponibilité (AZ). Chaque région dispose d’au moins 3 AZ. Une AZ comporte au moins un datacenter dédié. Les différentes AZ sont à une distance inférieure à 100 km et des fibres dédiées les interconnectent afin d’assurer une faible latence.

Les CSP recommandent de déployer des infrastructures sur 3 AZ dans une même région, et rendent la chose très simple : nombre de ressources (par exemple, une solution de load balancing) seront disponibles sur toutes les AZ de la région en même temps.

4. Outils de détection et de protection

4.1 Outils natifs

Les offres des CSP évoluent rapidement et s’enrichissent régulièrement de nouveaux produits. Certains de ces produits sont liés à la sécurité :

• Web Application Firewall (WAF) ;
• Protection contre les attaques par dénis de service distribués (DDOS, exemple : Google Cloud Armor) ;
• Security information and event management (SIEM, exemple : Azure Sentinel) ;
• Détection de menaces spécifiques au CSP (AWS Guard Duty) ;
• Détection de données sensibles (AWS Macie) ;
• Analyse des permissions et accès (AWS IAM Access Analyzer) ;
• Détection de vulnérabilités connues dans les containers (GCP container scanning).

Ces produits bénéficient d’une intégration avancée et également de threat intelligence spécialisée aux CSP. À l’inverse, cette spécialisation rend leur interopérabilité difficile lors de l’utilisation de différents CSP et peut requérir l’utilisation d’outils différents.

4.2 Outils tierce partie

La philosophie API des CSP rend la plupart de leurs paramètres de configuration accessibles par des systèmes externes, en lecture seule, ce qui garantit l’absence d’effets de bord. Ainsi de nombreux outils de sécurité sont rapidement déployables et testables.

Les catégories les plus répandues sont :

• CWS / CWP : Cloud Workload Security ou Cloud Workload Protection. Une solution de surveillance et de protection fonctionnant au niveau du système d’exploitation (souvent fondée sur [eBPF]), pour détecter des évènements systèmes inhabituels ou dangereux - en général, des post exploitations ou des pivots d’attaquants. La plupart de ces solutions sont des logiciels libres ([Datadog CWS], [Sysdig CWS]…).
• CSPM : Cloud Security Posture Management. Cette solution cherche à détecter des déviations de l’infrastructure face à des politiques de sécurité (telles que les standards [CIS], par exemple [AWS CIS]). Elle utilise généralement un modèle fondé à la fois sur un agent (pour inspecter les configurations des OS et des charges de travail) et sur la consultation des API des CSP. Quelques solutions : [Wiz CSPM], [Lacework CSPM], [Datadog CSPM]…
• CIEM : Cloud Infrastructure Entitlements Management. Permet la gestion des identités et des autorisations avec de multiples organisations ou vendeurs de cloud [Ermetic] [Microsoft Entra Permissions Management].
• IaC Security : L’utilisation d’infrastructure as code (IaC), rendue possible par l’approche API des CSP, permet d’auditer les changements de configuration grâce à l’intégration continue et de surveiller les éventuelles déviations entre l’infrastructure réelle et sa définition programmatique.

Les catégories CWS et CSPM sont parfois agrégées en CNAPP (Cloud Native Application Protection Platform).

Quelques exemples de cas d’usage :

• CSPM, IaC, SIEM : surveillance de l’infrastructure et de ses modifications (le cas échéant mis en regard du code le définissant). Exemples d’attaques détectées : l’ajout d’un utilisateur, la modification de ses permissions, la création et le téléchargement d’une sauvegarde.
• SIEM : connexion depuis des emplacements inhabituels, une connexion de l’utilisateur racine, un accès inhabituel à des stockages de données.
• CWS : démarrage d’un reverse shell, modification d’une configuration sensible, élévation locale de privilèges, comportement inhabituel d’un processus.
• Sécurité IaC : des exemples de politiques sont :
  • le chiffrement au repos doit être activé ;
  • un stockage de données ne doit pas être public ;
  • les utilisateurs doivent avoir une authentification à plusieurs facteurs.

Les outils des CSP supportant les déploiements multi-cloud sont rares, ce qui implique d’utiliser des produits agnostiques du vendeur comme ceux cités ci-dessus.

5. Surface d’attaque des infrastructures cloud

On peut distinguer la surface d’attaque intrinsèque, qu’un CSP en particulier offre à des attaquants, et la surface d’attaque d’un utilisateur du CSP, qui variera donc en fonction de l’utilisation faite du cloud. Les exemples suivants illustrent l’importance d’une veille sécurité spécifique à un CSP.

5.1 Surface d’attaque intrinsèque

• Physique : les datacenters et liens de communication inter-datacenters. Ceci est généralement ignoré.
• Sur les API : les API du CSP, exposées aux utilisateurs par définition, reposent sur des socles applicatifs classiques.
• Sur les produits : une vulnérabilité dans un hyperviseur ou un orchestrateur donne le contrôle à un attaquant de la machine sous-jacente, et l’accès aux données des machines virtuelles voisines, probablement appartenant à d’autres clients. Exemple appliqué à Azure : [azure escape].

Celles-ci sont de plus en plus exploitées. Voici quelques exemples de vulnérabilités :

• OMIGOD : OMI est un démon utilisé par Azure démarré implicitement dans certaines configurations. La CVE-2021-38647 permet une exécution de code à distance non authentifiée en tant que root.
• Azure ExtraReplica : cela autorise l’accès à n’importe quelle base de données hébergée dans une région donnée. Microsoft a corrigé le problème en 48 heures [extrareplica].
• ChaosDB : la base de données CosmosDB d’Azure a permis à des attaquants de télécharger des bases de données d’autres utilisateurs [chaosDB].

Voir [csp_security_mistakes] pour une liste maintenue.

5.2 Surface d’attaque liée aux clients

En 2021, trois catégories d’attaques ont principalement impacté les utilisateurs de CSP, et sont tous imputables à une vulnérabilité cliente ou une mauvaise configuration du CSP [2021] :

1. Vol de clefs via SSRF : une SSRF (Server Side Request Forgery) est une vulnérabilité applicative permettant à un attaquant de faire générer au serveur distant une requête HTTP. En ciblant le service IDMSv1 avec cette requête, un attaquant peut obtenir les permissions d’une entité telle qu’une machine virtuelle et les utiliser. IDMS est un service utilisé par AWS pour que certains services comme les machines virtuelles téléchargent leurs identifiants. La version 1 de ce service permet un appel direct à l’URL https://169.254.169.254 depuis la machine pour obtenir les clefs API de la machine virtuelle, et AWS conseille de migrer vers la version 2, qui nécessite une authentification préalable.
2. Mauvaises permissions dans un stockage d’object (typiquement S3) : les permissions sont complexes et sont régulièrement mal interprétées par les utilisateurs. Des attaquants accèdent régulièrement à des informations non publiques de cette façon.
3. Vol de clefs permanentes : utiliser des clés sans limites de validité accroît le risque qu’un attaquant puisse en découvrir pour accéder à un CSP. Les clefs peuvent fuiter par de nombreux vecteurs tels que du code source ou une application compilée.

D’autres exemples typiques :

• Vol des identifiants du compte racine, ne disposant pas de MFA ;
• Permissions trop larges, permettant à l’attaquant d’élever ses privilèges ou de se retrouver administrateur.

6. Différences avec des infrastructures classiques

Les infrastructures cloud diffèrent en certains points liés à la culture et aux pratiques :

• Utilisation de code pour définir l’infrastructure (IAC, permis par l’approche API offerte par les CSP). Avantage en sécurité : les modifications de l’infrastructure par un attaquant sont détectables en comparant l’état au code, et les modifications peuvent être auditées.
• Conteneurisation et immutabilité. Ces pratiques ont émergé en même temps que les CSP [12factors]. L’immutabilité vient d’une utilisation poussée des conteneurs interdisant aux applications d’utiliser les systèmes de stockage locaux (souvent en lecture seule). Cela autorise par exemple l’arrêt d’une charge de travail sans perte d’état (puisque l’état applicatif est stocké dans des systèmes dédiés, tels que des bases de données ou des caches). Avantage en sécurité : la persistance d’un attaquant est plus difficile, et les mises à jour sont plus faciles (puisqu’un redémarrage n’a aucun impact).
• Load balancing. Les bonnes pratiques recommandent l’utilisation de 3 AZ. Cela implique l’utilisation de modèles distribués en termes de bases de données, caches, d’ingestion… L’avantage est principalement en termes de disponibilité, mais au coût d’une complexité plus élevée (3 plans d'adressage réseau, nombre minimum de 3 machines pour un service…).
• Pour les clients les plus matures, diversifier les CSP aide à éviter d’être prisonnier d’un seul vendeur ou d’avoir un unique point de défaillance. Ce genre de pratique impose une vision très différente du cloud, en général en utilisant K8S pour orchestrer des charges de travail de façon transparente, en utilisant Terraform pour décrire l’infrastructure de façon (relativement) commune aux CSP, et en utilisant des systèmes génériques plutôt que propriétaires (Kafka à la place de Amazon Kinesis ou GCP DataFlow). Se passer de certaines ressources autrement prises en charge par le CSP augmente drastiquement la complexité de tels déploiements.

7. Vocabulaire spécifique aux CSP

Conclusion

Le monde des CSP a permis l’émergence de nouvelles pratiques d’ingénierie et une évolution de la surface d’attaque, en particulier en en retirant une partie de la responsabilité des utilisateurs. Cette évolution vers une approche API a fait émerger des solutions de sécurité offrant une visibilité exhaustive sur ces infrastructures.

Les menaces et les pratiques d’attaque ont évolué.

L’infrastructure devenant logicielle, le rythme de ces évolutions va continuer à accélérer et à nécessiter une veille bien plus importante qu’à l’époque révolue où chaque fournisseur de service gérait ses serveurs physiques. Ceci concerne évidemment les deux faces du diptyque attaquant/défenseur, car si la surface d’attaque augmente, la capacité de détection et d’investigation augmente également.

Ressources

[openstack] https://www.openstack.org/

[need-more-than-one] https://blog.coinbase.com/you-need-more-than-one-aws-account-aws-bastions-and-assume-role-23946c6dfde3

[secrets temporaires] https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html

[AWS Cloud Trail] https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-examples.html

[CIS] https://www.cisecurity.org/cis-benchmarks/

[AWS-CIS] https://docs.aws.amazon.com/audit-manager/latest/userguide/CIS-1-2.html

[eBPF] https://ebpf.io/

[Datadog CWS] https://docs.datadoghq.com/security_platform/cloud_workload_security/

[Sysdig CWS] https://docs.sysdig.com/en/docs/sysdig-secure/

[Wiz CSPM] https://www.wiz.io/#

[Lacework CSPM] https://docs.lacework.com/

[Datadog CSPM] https://docs.datadoghq.com/security_platform/cspm/

[Ermetic] https://ermetic.com/solution/cloud-infrastructure-entitlements-management/

[Microsoft Entra Permissions Management] https://www.microsoft.com/en-us/security/business/identity-access/microsoft-entra-permissions-management

[azure escape] https://unit42.paloaltonetworks.com/azure-container-instances/

[extrareplica] https://msrc-blog.microsoft.com/2022/04/28/azure-database-for-postgresql-flexible-server-privilege-escalation-and-remote-code-execution

[csp_security_mistakes] https://github.com/SummitRoute/csp_security_mistakes

[chaosDB] https://www.wiz.io/blog/chaosdb-how-we-hacked-thousands-of-azure-customers-databases/

[2021] https://blog.christophetd.fr/cloud-security-breaches-and-vulnerabilities-2021-in-review/

[12factors] https://12factor.net/