Zone grise de la sécurité de Cloud : qui est responsable des risques liés à la gestion des identités ?
D'innombrables heures peuvent être consacrées à l'application de l'AMF et au verrouillage des autorisations. Mais qu'en est-il des identités que vous ne gérez pas ? Celles que votre fournisseur de cloud crée et gère pour vous ?
Ces "identités non humaines gérées par le CSP" sont les robots automatisés qui exécutent les services en arrière-plan. Bien qu'ils soient essentiels, la façon dont AWS, Google Cloud et Microsoft les ont conçus crée des risques de sécurité uniques et non évidents. Si vous pensez qu'une configuration sécurisée dans AWS l'est également dans Azure, vous risquez d'être surpris.
Prenons le temps d'analyser les risques propres à chaque cloud.
AWS : Le problème du "député confus" (c'est de votre faute)
Dans AWS, les services sont globaux et partagés par tous. Cela crée un risque classique d'"adjoint confus" pour plusieurs locataires. Un attaquant utilisant son propre compte peut potentiellement tromper un service AWS en utilisant ses autorisations pour accéder aux ressources de votre compte.
- Le problème : La seule chose qui empêche cela est un paramètre spécial dans vos politiques de ressources IAM appelé clé de condition (c.-à-d. aws:SourceArn).
- La réalité : Il peut être très difficile d'utiliser correctement les clés de condition. Il en résulte une faille importante, souvent négligée, qui fait peser le poids de la prévention sur vos épaules.
Google Cloud: Le problème de la "boîte noire" (ils en sont responsables)
Google adopte l'approche inverse. Ses identités non humaines gérées par le CSP (agents de service) sont à locataire unique et enfermées dans des projets contrôlés par Google. Il est impossible d'y toucher, ce qui évite les abus d'identification que l'on observe dans d'autres nuages.
- Le problème : Cela crée un autre problème : l'abus d'accès transitif. Un service peut être si puissant par nature qu'il constitue une cible juteuse. Un attaquant peut l'inciter à agir en son nom, en contournant la vérification de ses propres autorisations.
- La réalité : C'est exactement ce qui s'est passé avec le service Document AI. Bien que Google ait corrigé le problème, vous n'avez aucun contrôle direct sur la situation. Vous devez vous fier au fait que le fournisseur a conçu tous ses services de manière sécurisée.
Microsoft Entra ID : "Service Principal Hijacking" (risque actuel)
Microsoft utilise un modèle hybride dans lequel un Principal local pour l'application de première partie appartenant à Microsoft vit dans votre locataire. Historiquement, cette conception présentait une faille critique: un administrateur (comme Application Admin) pouvait ajouter ses propres informations d'identification au Service Principal et escalader ses autorisations.
- Le problème : Microsoft propose un correctif appelé appInstancePropertyLock. Lorsqu'il est activé, il empêche ce type de détournement.
- La réalité : La correction n'est pas rétroactive. Microsoft doit mettre à jour manuellement les plus de 300 applications par défaut installées chez ses clients. Bien que nombre d'entre elles aient été redéployées avec cette propriété activée, comme l'ont récemment montré des chercheurs, des applications critiques comme Office 365 Exchange Online ne sont toujours pas protégées, ce qui en fait le risque le plus immédiat et le plus important des trois.
Ce qu'il faut en retenir ?
La sécurité n'est pas universelle dans l'cloud. La menace qui doit vous obséder dans AWS n'est pas un problème dans Google, et le plus grand risque dans Entra ID a une cause complètement différente.
- Dans AWS ? Auditez vos politiques IAM pour détecter les clés de condition manquantes. Les problèmes d'adjoints confus peuvent être évités.
- Dans le Cloud Google ? La sécurité des agents de service dépend uniquement de Google. Tenez-vous au courant des vulnérabilités, n'activez que les services dont vous avez le moins besoin et surveillez toute activité inhabituelle.
- Dans Microsoft Entra ID ? Surveillez l'ajout d'informations d'identification aux Service Principals locaux. Restez au courant des détournements de Service Principal signalés dans la nature.
Les menaces ne sont pas uniformes. La menace la plus grave dans un cloud peut être sans importance dans un autre. Les défenseurs et les chercheurs doivent adapter leurs stratégies, en reconnaissant qu'il n'existe pas d'approche "1 pour 1" des contrôles de sécurité dans un environnement cloud .
Pour en savoir plus sur les recherches qui sous-tendent chacun de ces modèles de menace et les différentes architectures, consultez le livre blanc "A Comparative Threat Model of CSP-Managed Machine Identities" (Modèle comparatif de menace pour les identités des machines gérées par les fournisseurs de services de télécommunications).