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

S’APPLIQUE À : NoSQL

Diagramme de la séquence du guide de déploiement, y compris ces emplacements, dans l’ordre : Vue d’ensemble, Concepts, Préparation, Contrôle d’accès en fonction du rôle, Réseau et Référence. L’emplacement « Concepts » est mis en surbrillance.

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 :

	Description
Identités de charge de travail	Une identité de charge de travail représente une charge de travail logicielle qui doit accéder à d’autres services ou ressources
Identités humaines	Une identité humaine représente un utilisateur qui peut être natif de votre locataire ou ajouté en tant qu’invité
Identités gérées	Les identités gérées sont des ressources distinctes dans Azure qui représentent l’identité d’un service Azure
Principaux de service	Un principal de service est un compte de service qui peut être utilisé dans un nombre flexible de scénarios d’authentification
Identités d’appareil	Une identité d’appareil est un objet dans Microsoft Entra mappé à un appareil
Groupes	Les groupes sont des objets utilisés pour gérer l’accès à une ou plusieurs identités en tant qu’opération unique

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 :

	Valeur
Rôle	CosmosBackupOperator
Definition	Microsoft.DocumentDB/databaseAccounts/backup/action et Microsoft.DocumentDB/databaseAccounts/restore/action
Portée	Un groupe de ressources

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.

Important

Certains services Azure, comme Azure Cosmos DB, ont leur propre implémentation de contrôle d’accès en fonction du rôle native qui utilise différentes propriétés Azure Resource Manager, des commandes Azure CLI et des cmdlet Azure PowerShell. Les commandes que vous utilisez généralement pour gérer le contrôle d’accès en fonction du rôle ne fonctionnent pas avec l’accès au plan de données Azure Cosmos DB. Certaines commandes pour le contrôle d’accès en fonction du rôle Azure peuvent fonctionner avec l’accès au plan de contrôle Azure Cosmos DB.

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 :

	Description
Principal	Identité attribuée à ce rôle
Rôle	Rôle attribué à l’identité
Portée	Ressource ou groupe Azure cible de l’attribution
Nom/Description	Métadonnées qui facilitent la gestion des attributions à grande échelle

Conseil

Dans le contrôle d’accès en fonction du rôle, vous pouvez voir que les termes identité et principal sont utilisés de manière interchangeable.

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 :

	Description	Plane
Microsoft.DocumentDB/databaseAccounts/listKeys/action	Lire uniquement les clés de compte	Plan de contrôle
Microsoft.DocumentDB/databaseAccounts/backup/action	Effectuer des sauvegardes	Plan de contrôle
Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/items/replace	Remplacer entièrement un élément existant	Plan de données
Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers/executeQuery	Exécuter une requête NoSQL	Plan de données

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 :

	Description
Microsoft.DocumentDb/databaseAccounts/*	Créer et gérer des comptes Azure Cosmos DB
Microsoft.DocumentDB/*/read	Lire n’importe quel conteneur ou base de données

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.

Remarque

La séparation des actions en plan de contrôle et en plan de données est une mesure de sécurité qui empêche les actions génériques des définitions de rôle héritées d’avoir un accès illimité et involontaire aux données.

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

Important

Dans Azure Cosmos DB, vous avez besoin d’accéder au plan de contrôle pour gérer les définitions et les attributions de contrôle d’accès en fonction du rôle natives du plan de données. Étant donné que le mécanisme de contrôle d’accès en fonction du rôle basé sur le rôle d’Azure Cosmos DB est natif, vous aurez besoin d’un accès au plan de contrôle pour créer des définitions et des attributions et les stocker en tant que ressources dans un compte Azure Cosmos DB.

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.

Conseil

Pour rendre votre code de production plus facile à déboguer et plus prévisible, vous pouvez choisir d’utiliser DefaultAzureCredential dans le développement et de basculer vers des informations d’identification plus spécifiques comme WorkloadIdentityCredential ou ManagedIdentityCredential une fois l’application déployée. Toutes ces classes sont basées sur la classe TokenCredential attendue par de nombreux kits de développement logiciel (SDK) Azure dans le cadre de leur logique d’initialisation du client, ce qui facilite le basculement.

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

Obtenir l’identité du compte connecté