Glossaire de sécurité pour Azure Cosmos DB for NoSQL

S’APPLIQUE À : NoSQL

Cet article inclut un glossaire de terminologie courante utilisée dans ce guide de sécurité pour Azure Cosmos DB for NoSQL.

Contrôle d’accès basé sur les rôles

Le contrôle d’accès en fonction du rôle fait référence à une méthode qui permet de gérer l’accès aux ressources dans Azure. Cette méthode est basée sur des identités spécifiques attribuées aux rôles qui gèrent le niveau d’accès dont ils ont besoin pour une ou plusieurs ressources. Le contrôle d’accès en fonction du rôle fournit un système flexible de gestion des accès précis qui garantit que les identités disposent uniquement d’un accès le moins privilégié dont ils ont besoin pour effectuer leur tâche.

Pour plus d’informations, consultez Vue d’ensemble du contrôle d’accès en fonction du rôle.

Identité/Principal

Les identités font référence à des objets dans Microsoft Entra qui représente une entité qui peut avoir besoin d’un niveau d’accès à votre système. Dans le contexte d’Azure et de Microsoft Entra, les identités peuvent faire référence à l’un des types d’entités suivants :

Pour plus d’informations, consultez Notions de base des identités.

Rôle

Les rôles sont les principales unités d’application de l’accès et des autorisations. Vous attribuez un rôle à une identité et la définition du rôle détermine le niveau d’accès que cette identité peut avoir. L’étendue de l’attribution détermine précisément à quoi l’identité a accès.

Azure dispose d’un grand ensemble de rôles intégrés que vous pouvez utiliser pour accorder l’accès à différentes ressources. Prenons cet exemple :

Dans cet exemple, le rôle CosmosBackupOperator vous a été attribué pour groupe de ressources spécifique. Cette attribution vous permet d’effectuer les actions backup ou restore sur n’importe quel compte Azure Cosmos DB au sein de ce groupe de ressources.

Pour plus d’informations, voir Rôles intégrés Azure

Définition de rôle

Une définition de rôle est un objet JSON qui contient la liste des actions du plan de contrôle et du plan de données autorisées et non autorisées. Considérez cet exemple tronqué à partir du rôle intégré CosmosRestoreOperator :

{
  "roleName": "CosmosRestoreOperator",
  "type": "Microsoft.Authorization/roleDefinitions",
  ...
  "permissions": [
    {
      "actions": [
        "Microsoft.DocumentDB/locations/restorableDatabaseAccounts/restore/action",
        "Microsoft.DocumentDB/locations/restorableDatabaseAccounts/*/read",
        "Microsoft.DocumentDB/locations/restorableDatabaseAccounts/read"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }
  ],
  ...
}

Dans cette définition, une identité attribuée à ce rôle peut effectuer une action restore. Une fois l’opération de restauration terminée, l’identité peut ensuite lire différentes ressources pour vérifier que la restauration a réussi. Nous pouvons déterminer qu’elle peut lire ces ressources en raison de l’opérateur * (générique) pour read.

Pour plus d’informations, consultez Concepts des définitions de rôle.

Attribution de rôle

Une attribution de rôle accorde un accès d’identité à une ressource Azure spécifique. Les attributions de rôles présentent les composants suivants :

Pour plus d’informations, consultez Concepts de l’attribution de rôle.

Actions

Les actions définissent les autorisations spécifiques qu’un rôle a pour une ressource cible. Les actions sont des chaînes qui incluent généralement le type de ressource et un nom descriptif détaillant les autorisations accordées par l’action. Voici quelques exemples courants :

Les actions peuvent également contenir des caractères (génériques) * afin que vous n’ayez pas à détailler manuellement chaque sous-envoi spécifique. Voici quelques exemples d’actions avec des caractères génériques :

Les actions sont séparées en plan de contrôle et en plan de données. Vous devez définir séparément des actions sur les ressources du plan de contrôle et les actions qui peuvent influencer les données. Dans une définition de rôle, les actions du plan de contrôle utilisent la propriété actions et les actions de plan de données qui se trouvent dans la propriété dataActions. Vous pouvez également définir des actions qu’une identité ne peut pas effectuer à l’aide des propriétés notActions et notDataActions, respectivement.

Pour plus d’informations, consultez Actions de contrôle et actions sur les données.

Privilège minimum

Le concept de « privilège minimum » fait référence à une meilleure pratique opérationnelle pour s’assurer que tous les utilisateurs disposent uniquement du niveau d’accès minimal dont ils ont besoin pour effectuer leur tâche ou leur travail. Par exemple, une application qui lit des données à partir d’une base de données n’a besoin que d’un accès en lecture au magasin de données. Si cette application avait un accès en lecture et en écriture au magasin de données, certaines choses peuvent se produire, notamment, mais sans s’y limiter :

• L’application peut détruire les données de manière erronée
• Un utilisateur non autorisé peut accéder aux informations d’identification de l’application et modifier les données

La pratique du privilège minimum garantit que toutes les violations de données potentielles sont limitées dans l’étendue. Cette pratique optimise la sécurité opérationnelle tout en permettant aux utilisateurs de rester efficaces.

Pour plus d’informations, consultez Rôles les moins privilégiés recommandés par tâche.

Plan de contrôle

L’accès au plan de contrôle fait référence à la possibilité de gérer des ressources pour un service Azure sans gérer les données. Par exemple, l’accès au plan de contrôle Azure Cosmos DB peut inclure la possibilité de :

• Lire toutes les métadonnées de compte et de ressource
• Lire et régénérer les clés de compte et les chaînes de connexion
• Effectuer des sauvegardes et des restaurations de compte
• Démarrer et suivre les tâches de transfert de données
• Gérer les bases de données et les conteneurs
• Modifier les propriétés du compte

Plan de données

L’accès au plan de données fait référence à la possibilité de lire et d’écrire des données au sein d’un service Azure sans pouvoir gérer les ressources dans le compte. Par exemple, l’accès au plan de données Azure Cosmos DB peut inclure la possibilité de :

• Lire certaines métadonnées de compte et de ressource
• Créer, lire, mettre à jour, corriger et supprimer des éléments
• Exécuter des requêtes NoSQL
• Lire dans le flux de modification du conteneur
• Exécuter des procédures stockées
• Gérer les conflits dans le flux de conflit

Authentification portable

En développement, il est courant d’écrire deux jeux de logique d’authentification distincte pour les instances de développement et de production locales. Avec le kit de développement logiciel (SDK) Azure, vous pouvez écrire votre logique à l’aide d’une technique unique et vous attendre à ce que le code d’authentification fonctionne en toute transparence dans le développement et la production.

La bibliothèque de client Azure Identity est disponible dans plusieurs langages de programmation dans le cadre du kit de développement logiciel (SDK) Azure. À l’aide de cette bibliothèque, vous pouvez créer un objet DefaultAzureCredential qui décrit intelligemment plusieurs options, afin de trouver les informations d’identification appropriées en fonction de votre environnement. Ces options d’authentification incluent (dans l’ordre) :

1. Clé secrète client ou certificat stocké en tant que variable d’environnement
2. Microsoft Entra Workload ID
3. Identité gérée attribuée par le système ou l’utilisateur
4. Informations d’identification Azure dérivées des paramètres de Visual Studio
5. Informations d’identification utilisées dans l’extension de compte Azure de Visual Studio Code
6. Informations d’identification actuelles d’Azure CLI
7. Informations d’identification actuelles d’Azure PowerShell
8. Informations d’identification actuelles d’Azure Developer CLI
9. Session interactive qui lance le navigateur du système pour la connexion

Chaque bibliothèque du kit de développement logiciel (SDK) Azure moderne prend en charge un constructeur pour leurs objets client ou classes respectifs qui acceptent une instance DefaultAzureCredential ou son type de base.

Identificateur unique

Chaque identité dans Microsoft Entra a un identificateur unique. Vous voyez parfois cet identificateur unique appelé id, objectId ou principalId. Lors de la création d’attributions de rôles, vous avez besoin de l’identificateur unique de l’identité que vous utilisez avec l’attribution.

Étendue

Lorsque vous attribuez un rôle, vous devez décider des ressources ou groupes Azure auxquels accorder l’accès. L’étendue d’une attribution de rôle définit le niveau auquel une attribution est effectuée.

Par exemple :

• Une étendue de ressource unique applique des autorisations à cette ressource unique
• Un ensemble d’étendues au niveau du groupe de ressources applique les autorisations à toutes les ressources pertinentes au sein du groupe
• Les étendues au niveau du groupe d’administration ou de l’abonnement s’appliquent à l’ensemble des groupes et ressources enfants

Quand vous attribuez un rôle dans le contrôle d’accès en fonction du rôle Azure, l’idéal est de définir l’étendue de cette attribution de façon à inclure seulement les ressources nécessaires pour votre charge de travail. Par exemple, vous pouvez définir l’étendue d’une attribution sur un groupe de ressources. Cette étendue de groupe de ressources inclut toutes les ressources Azure Cosmos DB au sein du groupe de ressources :

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>

Vous pouvez aussi définir l’étendue sur une seule ressource Azure et rendre votre attribution d’autorisations plus granulaire et plus étroite. Dans cet exemple, le fournisseur et le nom de la ressource Azure Cosmos DB sont utilisés pour restreindre l’étendue :

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>

Pour plus d’informations, consultez Étendue du contrôle d’accès en fonction du rôle Azure.

Étendue (native dans Azure Cosmos DB)

Dans l’implémentation native du contrôle d’accès en fonction du rôle dans Azure Cosmos DB, l’étendue fait référence à la granularité des ressources au sein d’un compte pour lequel vous voulez appliquer une autorisation.

Au plus haut niveau, vous pouvez délimiter l’étendue d’une attribution de contrôle d’accès en fonction du rôle d’un plan de données à l’ensemble du compte en utilisant l’étendue la plus grande. Cette étendue inclut toutes les bases de données et tous les conteneurs au sein du compte :

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/

Vous pouvez aussi délimiter l’étendue de l’attribution de rôle de votre plan de données à une base de données spécifique :

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/<database-name>

Enfin, vous pouvez délimiter l’étendue de l’attribution à un seul conteneur, qui est l’étendue la plus granulaire :

/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.DocumentDB/databaseAccounts/<account-name>/dbs/<database-name>/colls/<container-name>

Étape suivante