Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’APPLIQUE À : Tous les niveaux de Gestion des API
Gestion des API Azure s’appuie sur le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour permettre une gestion des accès affinée pour les services et entités Gestion des API, y compris les espaces de travail. Cet article fournit une vue d’ensemble des rôles intégrés et personnalisés dans Gestion des API. Pour plus d’informations sur la gestion de l’accès dans le portail Azure, consultez Prise en main de la gestion des accès dans le portail Azure.
Note
Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour bien démarrer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell depuis AzureRM vers Az.
Rôles de service intégrés
Gestion des API fournit actuellement trois rôles de service intégrés. Ces rôles peuvent être affectés à différentes étendues, notamment un abonnement, un groupe de ressources et une instance spécifique de Gestion des API. Par exemple, si vous affectez le rôle « Lecteur du service Gestion des API » à un utilisateur au niveau du groupe de ressources, cet utilisateur a un accès en lecture à toutes les instances Gestion des API du groupe de ressources.
Le tableau ci-dessous fournit de brèves descriptions des rôles intégrés. Vous pouvez affecter ces rôles à l’aide du portail Azure ou d’autres outils, notamment Azure PowerShell, Azure CLI et l’API REST. Pour plus d’informations sur l’attribution de rôles intégrés, consultez Attribuer des rôles Azure pour gérer l’accès aux ressources de votre abonnement Azure.
| Rôle | Accès en lecture[1] | Accès en écriture[2] | Création, suppression et mise à l’échelle d’un service, configuration d’un VPN et d’un domaine personnalisé | Accès au portail de publication ancien | Description |
|---|---|---|---|---|---|
| Contributeur du service de gestion des API | ✓ | ✓ | ✓ | ✓ | Super utilisateur. A un accès CRUD complet aux services et entités de gestion des API (par exemple, les API et les stratégies). Dispose d’un accès au portail de publication ancien. |
| Lecteur de la gestion des services API | ✓ | Dispose d’un accès en lecture seule aux services et aux entités de la gestion des API. | |||
| Opérateur du service Gestion des API | ✓ | ✓ | Peut gérer les services Gestion des API, mais pas les entités. |
[1] Accès en lecture aux services et entités API Management (par exemple les API et les stratégies)
[2] Accès en écriture aux services et entités de la gestion des API, à l’exception des opérations suivantes : création, suppression et mise à l’échelle d’instances, configuration du VPN et configuration du domaine personnalisé.
Rôles d’espace de travail intégrés
Gestion des API fournit les rôles intégrés suivants pour les collaborateurs dans les espaces de travail d’une instance Gestion des API.
Un collaborateur d’espace de travail doit se voir attribuer à la fois un rôle au niveau de l’espace de travail et un rôle au niveau du service.
| Rôle | Étendue | Description |
|---|---|---|
| Contributeur d’espace de travail de gestion des API | espace de travail | Peut gérer l’espace de travail et consulter ses membres, mais ne pas les modifier. Ce rôle doit être attribué sur l’étendue de l’espace de travail. |
| Lecteur d’espace de travail de gestion des API | espace de travail | Dispose d’un accès en lecture seule aux entités de l’espace de travail. Ce rôle doit être attribué au niveau de l’étendue de l’espace de travail. |
| Développeur API de l’espace de travail de gestion des API | espace de travail | Dispose d’un accès en lecture aux entités dans l’espace de travail et d’un accès en lecture et en écriture aux entités pour la modification des API. Ce rôle doit être attribué sur le périmètre de l’espace de travail. |
| Chef de produit de l'espace de travail de gestion des API | espace de travail | Dispose d’un accès en lecture aux entités dans l’espace de travail et d’un accès en lecture et en écriture aux entités pour la publication des API. Ce rôle doit être attribué à l'échelle de l'espace de travail. |
| Développeur d'API pour le Service de Gestion d'API dans l'Espace de Travail | service | Dispose d’un accès en lecture aux étiquettes et aux produits et d’un accès en écriture pour autoriser : ▪️ Affectation d’API à des produits ▪️ Affectation d’étiquettes à des produits et des API Ce rôle doit être attribué sur l’étendue du service. |
| Responsable produit de l'API de l'espace de travail du service de gestion des API | service | A le même accès que le développeur de l'API de l'espace de travail du service de gestion des API, ainsi qu’un accès en lecture aux utilisateurs et un accès en écriture pour assigner des utilisateurs à des groupes. Ce rôle doit être attribué sur l’étendue du service. |
Selon la façon dont les collaborateurs de l’espace de travail utilisent ou gèrent l’espace de travail, nous vous recommandons également d’attribuer l’un des rôles RBAC fournis par Azure suivants dans l’étendue de la passerelle d’espace de travail : Lecteur, Contributeur ou Propriétaire.
Rôles du portail intégré des développeurs
| Rôle | Étendue | Description |
|---|---|---|
| Éditeur de contenu du portail des développeurs pour la gestion des API | service | Peut personnaliser le portail des développeurs, modifier son contenu et le publier à l’aide des API Azure Resource Manager. |
Rôles personnalisés
Si aucun des rôles intégrés ne répond à vos besoins, vous pouvez créer des rôles personnalisés permettant une gestion plus précise de l’accès aux entités Gestion des API. Par exemple, vous pouvez créer un rôle personnalisé qui dispose d’un accès en lecture seule à un service Gestion des API, mais qui ne dispose d’un accès en écriture que pour une API spécifique. Pour plus d’informations sur les rôles personnalisés, consultez Rôles personnalisés dans le RBAC Azure.
Note
Pour être en mesure de voir une instance de la gestion des API dans le portail Azure, un rôle personnalisé doit inclure l’action Microsoft.ApiManagement/service/read.
Avertissement
Ne vous fiez pas à la suppression des listSecrets (ou d’autres */listSecrets/action) autorisations pour masquer les informations d’identification à un principal qui a déjà un accès en écriture à l’entité parente.
Plusieurs entités Gestion des API , telles que les back-ends, les valeurs nommées et les fournisseurs d’autorisation, peuvent stocker des informations d’identification (par exemple, secrets client, clés API ou chaînes de connexion). Pour empêcher le rôle Lecteur de lire ces informations d’identification, ils sont omis de la réponse standard GET et exposés uniquement par le biais d’une action dédiée listSecrets (ou équivalente). Le simple octroi de Microsoft.ApiManagement/service/<entityType>/listSecrets/action à un principal protège donc les identifiants des utilisateurs ayant un accès en lecture seule.
Toutefois, tout principal disposant d’un accès en écriture sur l’entité peut modifier les informations d’identification stockées via une requête PUT ou PATCH, et le corps de réponse de ces requêtes contient l’entité complète mise à jour, y compris les informations d’identification qui viennent d’être écrites. Par conséquent, le retrait de l’action listSecrets à partir d’un rôle personnalisé qui accorde déjà un accès en écriture n’empêche pas ce principal d’obtenir des justificatifs d'identité. Il modifie uniquement l’appel d’API qui les renvoie.
Lorsque vous créez un rôle personnalisé, concevez la protection des informations d’identification autour de l’autorisation d’écriture sur l’entité, pas autour listSecrets. Si un principal ne doit pas apprendre les informations d’identification, n’accordez pas l’accès en écriture sur les entités qui les stockent.
Quand vous créez un rôle personnalisé, il est plus facile de commencer avec un des rôles intégrés. Modifiez les attributs pour ajouter les propriétés Actions, NotActions ou AssignableScopes, puis enregistrez les modifications en tant que nouveau rôle. L’exemple suivant commence par le rôle « Lecteur du service Gestion des API », puis crée un rôle personnalisé appelé « Éditeur d’API de calcul ». Vous pouvez affecter le rôle personnalisé à l’étendue d’une API spécifique. Par conséquent, ce rôle a accès uniquement à cette API.
$role = Get-AzRoleDefinition "API Management Service Reader Role"
$role.Id = $null
$role.Name = 'Calculator API Contributor'
$role.Description = 'Has read access to Contoso APIM instance and write access to the Calculator API.'
$role.Actions.Add('Microsoft.ApiManagement/service/apis/write')
$role.Actions.Add('Microsoft.ApiManagement/service/apis/*/write')
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add('/subscriptions/<Azure subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.ApiManagement/service/<APIM service instance name>/apis/<API name>')
New-AzRoleDefinition -Role $role
New-AzRoleAssignment -ObjectId <object ID of the user account> -RoleDefinitionName 'Calculator API Contributor' -Scope '/subscriptions/<subscription ID>/resourceGroups/<resource group name>/providers/Microsoft.ApiManagement/service/<APIM service instance name>/apis/<API name>'
L’article Opérations du fournisseur de ressources Azure Resource Manager contient la liste des autorisations qui peuvent être accordées au niveau Gestion des API.
Contenu connexe
Pour en savoir plus sur le contrôle d’accès en fonction du rôle dans Azure, consultez les articles suivants :