Configuration avancée

Le protocole MSP (Metadata Security Protocol) permet aux utilisateurs de définir éventuellement des listes d’autorisation RBAC (Role Based Access Control) personnalisées pour les points de terminaison de service de métadonnées par utilisateur et/ou par processus. Cette liste autorisée est activée par un nouveau type de ressource dans la Galerie Azure Compute, le InVMAccessControlProfile.

Motivation

Traditionnellement, les services de métadonnées traitent l’intégralité de la machine virtuelle comme limite d’approbation et autorisent tout logiciel s’exécutant dans l’invité à y accéder. Cet accès est trop permissif, en particulier si votre charge de travail n’est pas strictement implémentée avec une architecture cloud native moderne. Microsoft Security Response Center (MSRC) a constaté que la plupart des attaques de sécurité auraient pu être évitées en limitant l’accès aux logiciels nécessaires uniquement.

InVMAccessControlProfile vous permet de définir un contrôle plus granulaire sur les applications/utilisateurs qui peuvent avoir accès aux points de terminaison. Il vous permet d’écrire des règles telles que :

• La configuration réseau est accessible uniquement par l’agent invité et SQL Server
• Les jetons MSI (Managed Service Identity) sont accessibles uniquement par l’extension de supervision

Le nouveau type de ressource facilite la gestion de ces configurations à grande échelle. Les règles appropriées pour votre machine virtuelle dépendent du logiciel qu’il exécute. Le InVMAccessControlProfile vous permet de définir votre configuration une seule fois et de l'associer à toutes les machines virtuelles applicables.

Propriétés

Concepts de la liste d’autorisation MSP (RBAC)

La première étape du contrôle d’accès consiste à vérifier l’identité du client. Normalement, la vérification de l’identité est effectuée à l’aide d’un type d’informations d’identification. MSP a été conçu afin d'éviter l'introduction de changements perturbateurs aux clients afin d'optimiser la compatibilité et de faciliter l'intégration. En outre, disposer de clients avec des informations d'identification mises à niveau introduit une nouvelle couche de problèmes à résoudre liés à l'établissement de la confiance.

Au lieu de cela, MSP prend en charge la définition des « identités virtuelles » par rapport aux métadonnées existantes du système d’exploitation et du processus. Le noyau d’une machine virtuelle effectue le suivi du compte d’utilisateur auquel appartient un processus en plus d’autres métadonnées relatives à son appel. Le GPA est capable d’identifier le processus qui a effectué la requête HTTP. Par conséquent, le GPA peut accéder à ces métadonnées pour déterminer l’identité d’un appelant et prendre des décisions d’autorisation.

Rôles

Les rôles vous permettent de regrouper plusieurs privilèges dans une unité nommée et réutilisable. Ils sont utilisés pour améliorer l’organisation et la lisibilité.

Attributions de rôles

Les attributions de rôles associent une identité à un rôle. Cela signifie que les demandes résultant d'un processus qui s'aligne sur l'identité disposent de tous les privilèges associés à ce rôle.

Identities

MSP permet à l’utilisateur de définir un ensemble de conditions à évaluer par rapport à un conteneur de propriétés de métadonnées de processus. Si toutes les conditions correspondent, le processus est considéré comme « appartenant » à cette identité et reçoit des privilèges.

L’objet GPA prend en charge l’écriture de règles de correspondance exactes par rapport à ces métadonnées :

La méthode idéale pour configurer votre charge de travail consiste à exécuter chaque application dans un compte d’utilisateur dédié avec des groupes à étendue unique, puis à écrire des règles uniquement sur ces propriétés. L’ID utilisateur ne peut pas être usurpé et il n’existe aucun critère spécial à prendre en compte. Toutefois, nous reconnaissons que cela n’est pas pratique dans toutes les charges de travail, c’est pourquoi nous offrons les autres propriétés.

Si plusieurs propriétés sont spécifiées, la correspondance est effectuée en tant que AND logique. Par exemple, la définition d’identité :

{
    "name": "WebServer",
    "exePath": "/usr/sbin/apache2",
    "processName": "apache2",
    "groupName": "www-data"
}

Générerait la validation :

bool isWebServerIdentity = properties["exePath"] == "/usr/sbin/apache2"
    && properties["exePath"] == "apache2"
    && properties["groups"].contains("www-data");

Privilèges

Les privilèges accordent l’accès à des points de terminaison spécifiques. Certains points de terminaison sont RESTful et peuvent être exprimés uniquement en tant que chemin d’accès. D’autres sont influencés par les paramètres de requête.

Les privilèges sont définis avec un name, un path, et un Set facultatif de queryParameters.

"privileges": [
    {
        "name": "GoalState",
        "path": "/machine",
        "queryParameters": {"comp": "goalstate"}
    },
    {
        "name": "config",
        "path": "/machine",
        "queryParameters": {"comp": "config"}
    }
]

Règles de comparaison

• La correspondance de chaîne ne respecte pas la casse
• Si aucun paramètre de requête n’est spécifié, le privilège accorde l’accès à toutes les valeurs possibles sur ce chemin d’accès

defaultAccess Règlement

Les modes d’accès par défaut sont utilisés pour verrouiller lentement une charge de travail et simplifier la création de règles dans le cas où seuls des points de terminaison spécifiques sont intéressants pour restreindre l’accès.

• Si les paramètres de requête sont fournis, la question « est-ce qu’un privilège est défini ? » pour déterminer si defaultAccess elle s’applique devient : « Une règle correspond-elle à ce chemin d’accès + chaque paramètre de requête spécifié dans la règle est présente + correspondances dans la requête ? ». Les paramètres de requête supplémentaires sont ignorés dans cette évaluation.
• La requête est rejetée si les clés de paramètre de requête dupliquées dans une requête ne sont pas valides

Écriture de règles

La spécification d'une liste d'autorisation via des règles RBAC est facultative. Si un champ est spécifié, tous les champs doivent être fournis. (Par exemple, même si vous n'aviez aucun roles à définir, vous fourniriez quand même le tableau vide).

Le moyen le plus simple de générer des règles consiste d’abord à exécuter MSP en Audit mode, puis à utiliser les journaux d’audit pour générer des règles.

Extension de schéma IMDS (Full Instance Metadata Service) / exemple de la sous-section règles :

{
  "defaultAccess": "allow",
  "mode": "enforce",
  "rules": {
    "privileges": [
      {
        "name": "Msi",
        "path": "/metadata/identity/oauth2/token"
      }
    ],
    "roles": [
      {
        "name": "MyWebApp",
        "privileges": [
          "Msi"
        ]
      }
    ],
    "identities": [
      {
        "name":"MyWebApp1",
        "processName":"WebApp1"
      }
    ],
    "roleAssignments": [
      {
        "role": "MyWebApp",
        "identities": [
          "MyWebApp1"
        ]
      }
    ]
  },
  "id": "D/uTRPye9b9xSUCRIgfRDF41zeY="
}

Extension complète du schéma Wireserver / exemple de sous-section règles :

{
  "defaultAccess": "allow",
  "mode": "enforce",
  "rules": {
    "privileges": [
      {
        "name": "GoalState",
        "path": "/machine",
        "queryParameters": {
          "comp": "goalstate"
        }
      }
    ],
    "roles": [
      {
        "name": "Provisioning",
        "privileges": [
          "GoalState"
        ]
      }
    ],
    "identities": [
      {
        "name": "WinPA",
        "exePath": "C:\\Windows\\OEM\\Unattend.wsf.exe",
        "processName": "winpa.exe",
        "userName": "SYSTEM"
      }
    ],
    "roleAssignments": [
      {
        "role": "Provisioning",
        "identities": [
          "WinPA"
        ]
      }
    ]
  },
  "id": "D/uTRPye9b9xSUCRIgfRDF41zeY="
}

Configurations implicites + par défaut

La définition RBAC suivante est appliquée en tant que comportement par défaut pour les règles d’accès de défense en profondeur qui existaient avant LE MSP :

{
    "imds": {
        "defaultAccess": "Allow",
        "mode": "Disabled",
    },
    "wireServer": {
        "defaultAccess": "Allow",
        "mode": "Enforce",
    }
}

N’oubliez pas que Wireserver autorise uniquement l’accès à partir des processus administrateur/racine. La raison defaultAccess est toujours Allow ici, car cette règle n’est pas configurable par l’utilisateur. C'est intégré dans le GPA. Le GPA vérifie si le client est un utilisateur administrateur avant d’évaluer les règles RBAC pour une demande Wireserver. Si le client n’est pas un utilisateur administrateur, la demande est immédiatement rejetée.