Ajouter un commentaire

Par :
Omer Shmuelly

lun, 19/09/2022 - 13:19

À l'heure où de plus en plus d'organisations migrent leur infrastructure vers le cloud, un outil unifié de sécurité du cloud tel que CloudGuard de Check Point devient essentiel. Face à un déluge de normes et de réglementations, la gestion de votre niveau de sécurité du cloud (CSPM) peut être une tâche difficile. Si certaines configurations erronées sont faciles à détecter, telles un compte de stockage non crypté ou une machine virtuelle connectée à Internet, évaluer la sécurité de votre gestion des identités et des accès Azure peut vous obliger à plonger dans un puit sans fond.

Cet article présente quelques exemples de risques pour la sécurité du cloud liés à l’élévation des privilèges, et explique comment CloudGuard CSPM propose des règles complètes intégrées et un langage de script GSL de pointe pour créer vos propres règles afin d'améliorer la sécurité de Azure.

Un contrôle d'accès Azure basé sur les rôles

Le contrôle d'accès basé sur les rôles (RBAC) d'Azure est un système qui permet une gestion fine de l'accès aux ressources Azure. Grâce à Azure RBAC, qui permet d’assurer le respectdes autorisations, vous pouvez séparer les tâches au sein de votre équipe et accorder aux utilisateurs les accès nécessaires à l'exécution de leurs tâches.

Principal de service: Une identité de sécurité créée pour chaque application dans un locataire spécifique, définissant les privilèges d'accès à un certain principal de service.

Gestion des identités : Une identité gérée est un principal de service particulier qui fournit aux ressources et applications prises en charge une identité logique à des fins d'authentification AD. Un service doté d'une identité gérée peut l'utiliser pour se connecter et s'authentifier à d'autres ressources Azure prises en charge par AD, ce qui élimine la maintenance des identifiants. Il existe deux types d'identités gérées :

  • Celles attribuée par le système : Une identité gérée, qui est liée au cycle de vie d'une seule ressource, et à cette ressource uniquement. Une identité attribuée par le système n'est prise en charge que pour certaines ressources telles que les machines virtuelles, les automatismes, etc.
  • Celles attribuées par l'utilisateur : Une identité autonome distincte qui peut être attribuée et partagée entre plusieurs ressources.

Qu'est-ce que l’élévation de privilèges ?

L'élévation de privilèges fait référence à une manière non intentionnelle d'obtenir des privilèges élevés - en l'occurrence, pour un compte ou une ressource Azure.

Le principe du moindre privilège : Selon Saltzer et Schroeder dans « Basic Principles of Information Protection »: « Chaque programme et chaque utilisateur du système doit fonctionner en utilisant le plus petit lot de privilèges nécessaires pour effectuer le travail. Avant tout, ce principe limite les dommages qui peuvent résulter d'un accident ou d'une erreur. »

Dans cet article, nous examinons l'élévation des privilèges du point de vue du cloud, en partant du principe qu'un attaquant peut avoir un pied dans l'infrastructure de l'utilisateur. Bien que les risques puissent varier d'une disponibilité affectée à l'exfiltration et à la manipulation de données confidentielles, nous décrivons les meilleures pratiques que vous devriez suivre pour que votre environnement soit aussi sûr que possible.

La planification et la gestion de votre service Azure IAM ne constituent pas une première ligne de défense comme passerelle de sécurité de réseau cloud, mais il s'agit néanmoins d'une étape très importante à suivre.

Par exemple, si un attaquant réussit à accéder à l'une de vos machines virtuelles attribuée avec une identité gérée, il peut simplement se connecter au compte Azure en utilisant l'identité de la machine virtuelle avec la commande suivante :

> az login --identity
{
  "environmentName": "AzureCloud",
  "homeTenantId": "<HOME-TENANT-ID>",
  "id": "<ID>",
  "isDefault": true,
  "managedByTenants": [ {
    "tenantId": "<TENANT-ID>"
} ],
  "name": "<SUBSCRIPTION-NAME>", 
  "state": "Enabled",
  "tenantId": "<HOME-TENANT-ID>",
  "user": {
    "assignedIdentityInfo": "MSI",
    "name": "systemAssignedIdentity",
    "type": "servicePrincipal"
  }
}

L'ampleur de l'impact est déterminée par les privilèges qui ont été accordés à l'identité de la machine virtuelle. Si le fait de garder les permissions de l'identité au minimum (selon le principe du moindre privilège) limite l'attaquant à certaines ressources, d'autres permissions peuvent lui permettre d'avoir une mainmise plus étendue, augmentant ainsi l'impact.

Exemples de permissions connues et de leurs risques potentiels :

Exemple 1 : Élévation de privilèges via l'attribution de rôles

Attribution des rôles : Microsoft le définit comme le processus consistant à associer une définition de rôle à un utilisateur, un groupe, un principal de service ou une identité gérée à un niveau particulier dans le but d'accorder un accès.

Un principal avec cette permission

Microsoft.Authorization/roleAssignments/write

peut attribuer un rôle sélectionné à une ou plusieurs identités gérées, avec la possibilité d'élever ses privilèges au rôle de propriétaire dans un groupe de ressources donné.

Par exemple, cette commande attribue à une identité gérée le rôle de Propriétaire :

> az role assignment create --role "Owner" --assignee <PRINCIPAL-ID> --scope /subscriptions/SUBSCRIPTION-ID/resourceGroups/<RESOURCE-GROUP
{
      "canDelegate": null,
      "condition": null,
      "conditionVersion": null,
      "description": null,
      "id": "/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP>/providers/Microsoft.Authorization/roleAssignments/<ROLE-ASSIGNMENT-ID>",
      "name": "<ROLE-ASSIGNMENT-ID>",
      "principalId": "<PRINCIPAL-ID>",
      "principalType": "ServicePrincipal",
      "resourceGroup": "<RESOURCE-GROUP>",
      "roleDefinitionId": "/subscriptions/<SUBSCRIPTION-ID>/providers/Microsoft.Authorization/roleDefinitions/8e3af657-a8ff-443c-a75c-2fe8c4bcb635",
      "scope": "/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP>",
      "type": "Microsoft.Authorization/roleAssignments"
}

Règle pertinente de CloudGuard CSPM :

  • D9.AZU.IAM.35 - S'assurer d'auditer les assignations de rôles qui ont des permissions implicites de gestion de rôles

Exemples 2 : Élévationde privilèges via la définition des rôles

Définition des rôles: Microsoft le définit comme un ensemble d'autorisations qui répertorie les actions pouvant être effectuées, telles que la lecture, l'écriture et la suppression. On se contente généralement de l'appeler pour un seul rôle.

Un principal avec cette permission :

Microsoft.Authorization/roleDefinitions/write

peut créer de nouvelles définitions de rôle ou redéfinir des rôles existants. Cela peut être exploité par le principal pour obtenir des privilèges que le propriétaire du compte n'a jamais eu l'intention de donner à un certain principal en premier lieu.

Par exemple, cette commande permet à un principal d'élever les autorisations de sa définition de rôle pour effectuer n'importe quelle action :

> az role definition update --role-definition '{
{
      "Name": "example-role",
      "IsCustom": true,
      "Description": "",
      "Actions": ["*"],
      "notActions": [],
      "notDataActions": [],
      "assignableScopes": ["/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/<RESOURCE-GROUP>"]
}

Vous pouvez utiliser la requête GSL de CloudGuard CSPM pour rechercher des définitions de rôle Azure avec ces autorisations spécifiques :

> RoleDefinition should not have properties.permissions contain [ actions contain ['Microsoft.Authorization/roleDefinitions/write'] ]

 


Capture d'écran 1 : Requête vers l'infrastructure Azure à l'aide de CloudGuard GSL. [OS2] 

Exemple 3 : Attribuer une identité existante

Par exemple, un groupe de ressources Base-RG, qui contient une identité gérée Linked-Identity avec des autorisations de gestion, est affecté à un autre groupe de ressources Target-RG.


Diagramme 1 : Obtenir l'accès à une autre étendue de groupe de ressources avec une identité gérée attribuée à l'utilisateur.

Un principal au sein de Base-RG avec ces permissions :

Microsoft.ManagedIdentity/userAssignedIdentities/assign/action
Microsoft.Compute/virtualMachines/read
Microsoft.Compute/virtualMachines/write

Peut s'attribuer l'identité gérée « Linked-Identity » à elle-même ou à d'autres ressources prises en charge, et obtenir l'accès à une autre étendue de groupe de ressources. Par exemple :

> az vm identity assign -g Base-RG -n base-vm --identities linked-identity
{
  "systemAssignedIdentity": "<SYSTEM-ASSIGNED-ID>",
  "userAssignedIdentities": {
    "/subscriptions/<SUBSCRIPTION-ID>/resourceGroups/Base-RG/providers/Microsoft.ManagedIdentity/userAssignedIdentities/linked-identity": {
      "clientId": "<CLIENT-ID>",
      "principalId": "<PRINCIPAL-ID>"
      }
   }
}

Règle pertinente de CloudGuard CSPM :

  • D9.AZU.IAM.36 - Assurer l'audit des affectations de rôles qui ont des autorisations implicites d'identité gérée.

Tous les exemples présentés ci-dessus montrent des autorisations légitimes mais peuvent rapidement conduire à une élévation imprévue. Par conséquent, vous devez prendre en considération le principe du moindre privilège avant de les attribuer à un rôle.

Le principe du moindre privilège - Lignes directrices

  • Permissions : Donnez toujours les permissions minimales nécessaires au bon fonctionnement. Même la plus petite et la plus inoffensive des autorisations, comme une autorisation de lecture autonome d'une certaine ressource, peut donner à un attaquant la possibilité d'étendre sa portée à d'autres ressources.
  • Champ d’application : Veillez à prendre en compte la portée des ressources auxquelles vous exposez un principal particulier. Même si un principal doit avoir des privilèges élevés pour une ressource comme Key Vault, la portée de ses privilèges doit être limitée à Key Vault uniquement. Limitez les autorisations permettant d'agir sur la plus petite portée possible.
  • But : Étudiez la logique et le mécanisme que vous voulez atteindre. Est-ce la meilleure façon de procéder ? Votre application doit-elle gérer votre base de données et vos secrets en même temps ?
  • Dans le pire des cas : Demandez-vous toujours quel est le pire scénario possible. Les risques doivent être évalués à l'avance et non après coup.
  • Audit : L'infrastructure évolue en permanence, et la conception du service peut être dynamique. Assurez-vous d'auditer les privilèges d'intervalle incohérents du cloud pour maintenir une bonne sécurité.

Règles pertinentes de CloudGuard CSPM :

  • D9.AZU.IAM.34 - S'assurer que la définition de rôle personnalisé ne dispose pas de permissions excessives (Wildcard)
  • D9.AZU.IAM.37 - Assurez-vous d'auditer les attributions de rôles qui ont des permissions implicites de 'Propriétaire'.

Conclusion

Selon l'ensemble des autorisations, l’élévation des privilèges peut entraîner des conséquences simplesmais parfois regrettables. Au départ, toutes les permissions étaient légitimes, mais dans certaines circonstances, l’élévation les transforme en quelque chose qui n'a jamais été prévu.

 

Dans un monde où l'infrastructure du cloud se fait chaque jour plus complexe, il convient d'accorder une attention particulière aux permissions et aux définitions de rôles, avec des affectations données avec soin. C'est là que Check Point CloudGuard entre en jeu.

Un audit cohérent est un facteur clé pour maintenir un bon niveau de sécurité. CloudGuard CSPM rend votre processus d'audit efficace et facile avec une variété de capacités de prévention.

Étapes suivantes

  • Pour une démo personnalisée de CloudGuard, cliquez ici.
  • Vous pouvez lire le guide détaillé pour utiliser la sécurité d'Azure PaaS avec CloudGuard Network Security ici.
  • CloudGuard CSPM est disponible pour un essai gratuit de 30 jours ou un déploiement sur Azure Marketplace et peut être consommé via PAYG.
  • Si vous souhaitez plus d'informations sur CloudGuard CSPM, veuillez-vous adresser à votre partenaire de distribution Check Point, à l'ingénieur sécurité de votre compte ou contactez-nous.

 

Contenu supplémentaire pour l'apprentissage et la lecture

Si vous migrez vers le cloud et évaluez des solutions CSPM en nuage, téléchargez le Guide de l'acheteur de CSPM pour comprendre :

  • Les 10 principales considérations lors de l'évaluation et du choix d'une solution CSPM
  • Un aperçu de Check Point CloudGuard et comment il répond aux 10 critères principaux.
  • Les avantages relatifs des solutions fournies par les principaux fournisseurs de cloud et les fournisseurs de sécurité tiers.

Vous souhaitez plus d'informations sur la sécurité du cloud ?

Téléchargez les documents sur la sécurité du cloud de Check Point :

-        Introduction au Cloud Security Blueprint présente le plan de sécurité du cloud et décrit les principes architecturaux clés et les concepts de sécurité du cloud.

-        Cloud Security Blueprint:Architecture and Solutions explique l'architecture blueprint, décrit comment les solutions de sécurité du cloud de Check Point vous permettent de mettre en œuvre le blueprint, et comment celles-ci répondent aux défis de la sécurité du cloud et aux principes architecturaux qui ont été décrits dans le premier document.

-        Ce document fournit des architectures de référence pour la mise en œuvre du plan de sécurité du cloud.

Suivez et rejoignez les conversations sur Check Point et CloudGuard sur TwitterFacebookLinkedIn et Instagram.

A propos de l'auteur

Omer Shmuelly
Chercheur en sécurité, Cloud Security

Filtered HTML

Plain text

CAPTCHA
Cette question permet de vérifier que vous n'êtes pas un robot spammeur :-)
 K  K   QQQ    RRRR    SSS   W     W 
K K Q Q R R S W W
KK Q Q RRRR SSS W W W
K K Q QQ R R S W W W
K K QQQQ R RR SSSS W W
Q