Az - Basic Information
Hiérarchie de l'organisation
Groupes de gestion
Si votre organisation a de nombreuses abonnements Azure, vous pourriez avoir besoin d'un moyen de gérer efficacement l'accès, les politiques et la conformité pour ces abonnements. Les groupes de gestion fournissent un champ de gouvernance au-dessus des abonnements.
Notez que 10 000 groupes de gestion peuvent être pris en charge dans un seul annuaire et un arbre de groupes de gestion peut supporter jusqu'à six niveaux de profondeur.
Des docs : Chaque annuaire se voit attribuer un groupe de gestion de niveau supérieur appelé groupe de gestion racine. Le groupe de gestion racine est intégré dans la hiérarchie pour que tous les groupes de gestion et abonnements s'y rassemblent. Ce groupe de gestion racine permet d'appliquer des politiques globales et des attributions de rôles Azure au niveau de l'annuaire. L'Administrateur global Azure AD doit s'élever au rôle d'Administrateur d'accès utilisateur de ce groupe racine initialement. Après avoir élevé l'accès, l'administrateur peut attribuer n'importe quel rôle Azure à d'autres utilisateurs ou groupes d'annuaire pour gérer la hiérarchie. En tant qu'administrateur, vous pouvez attribuer votre propre compte comme propriétaire du groupe de gestion racine.
Le groupe de gestion racine ne peut pas être déplacé ou supprimé, contrairement aux autres groupes de gestion.
Les groupes de gestion vous offrent une gestion de niveau entreprise à grande échelle, peu importe le type d'abonnements que vous pourriez avoir. Cependant, tous les abonnements au sein d'un seul groupe de gestion doivent faire confiance au même locataire Azure Active Directory (Azure AD).
Abonnements Azure
Dans Azure, un abonnement sert de conteneur logique dans le but de provisionner des ressources commerciales ou techniques. Ce conteneur maintient les détails des ressources telles que les machines virtuelles (VM), les bases de données, entre autres. Lors de la création d'une ressource Azure, comme une VM, l'abonnement associé est spécifié. Cette structure facilite la délégation d'accès, en utilisant des mécanismes de contrôle d'accès basé sur les rôles.
Groupes de ressources
Des docs : Un groupe de ressources est un conteneur qui contient des ressources liées pour une solution Azure. Le groupe de ressources peut inclure toutes les ressources de la solution, ou seulement celles que vous souhaitez gérer en tant que groupe. En général, ajoutez des ressources qui partagent le même cycle de vie au même groupe de ressources afin que vous puissiez facilement les déployer, les mettre à jour et les supprimer en tant que groupe.
Toutes les ressources doivent être dans un groupe de ressources et ne peuvent appartenir qu'à un seul groupe, et si un groupe de ressources est supprimé, toutes les ressources à l'intérieur sont également supprimées.
Unités administratives
Des docs : Les unités administratives vous permettent de sous-diviser votre organisation en n'importe quelle unité que vous souhaitez, puis d'attribuer des administrateurs spécifiques qui peuvent gérer uniquement les membres de cette unité. Par exemple, vous pourriez utiliser des unités administratives pour déléguer des autorisations aux administrateurs de chaque école dans une grande université, afin qu'ils puissent contrôler l'accès, gérer les utilisateurs et définir des politiques uniquement dans l'École d'ingénierie.
Seuls les utilisateurs, groupes et appareils peuvent être membres d'une unité administrative.
Par conséquent, une unité administrative contiendra certains membres et d'autres principaux se verront attribuer des autorisations sur cette unité administrative qu'ils peuvent utiliser pour gérer les membres de l'unité administrative.
Azure vs Azure AD vs Azure AD Domain Services
Il est important de noter que Azure AD est un service à l'intérieur d'Azure. Azure est la plateforme cloud de Microsoft tandis que Azure AD est un service d'identité entreprise dans Azure. De plus, Azure AD n'est pas comme Windows Active Directory, c'est un service d'identité qui fonctionne de manière complètement différente. Si vous souhaitez exécuter un contrôleur de domaine dans Azure pour votre environnement Windows Active Directory, vous devez utiliser Azure AD Domain Services.
Principaux
Azure prend en charge différents types de principaux :
Utilisateur : Une personne régulière avec des identifiants pour accéder.
Groupe : Un groupe de principaux géré ensemble. Les autorisations accordées aux groupes sont héritées par ses membres.
Principal de service / Applications d'entreprise : C'est une identité créée pour utiliser avec des applications, des services hébergés et des outils automatisés pour accéder aux ressources Azure. Cet accès est restreint par les rôles attribués au principal de service, vous donnant le contrôle sur quelles ressources peuvent être accessibles et à quel niveau. Pour des raisons de sécurité, il est toujours recommandé d'utiliser des principaux de service avec des outils automatisés plutôt que de leur permettre de se connecter avec une identité utilisateur.
Lors de la création d'un principal de service, vous pouvez choisir entre l'authentification par mot de passe ou l'authentification par certificat.
Si vous choisissez l'authentification par mot de passe (par défaut), enregistrez le mot de passe généré car vous ne pourrez plus y accéder.
Si vous choisissez l'authentification par certificat, assurez-vous que l'application aura accès à la clé privée.
Identité gérée (Identifiants de métadonnées) : Les identités gérées dans Azure Active Directory offrent une solution pour gérer automatiquement l'identité des applications. Ces identités sont utilisées par les applications pour se connecter aux ressources compatibles avec l'authentification Azure Active Directory (Azure AD). En utilisant des identités gérées, les applications peuvent sécuriser les jetons Azure AD tout en éliminant le besoin de gérer directement les identifiants. Il existe deux types d'identités gérées :
Assignée par le système. Certains services Azure vous permettent d'activer une identité gérée directement sur une instance de service. Lorsque vous activez une identité gérée assignée par le système, une identité est créée dans Azure AD. L'identité est liée au cycle de vie de cette instance de service. Lorsque la ressource est supprimée, Azure supprime automatiquement l'identité pour vous. Par conception, seule cette ressource Azure peut utiliser cette identité pour demander des jetons à Azure AD.
Assignée par l'utilisateur. Vous pouvez également créer une identité gérée en tant que ressource Azure autonome. Vous pouvez créer une identité gérée assignée par l'utilisateur et l'assigner à une ou plusieurs instances d'un service Azure (plusieurs ressources). Pour les identités gérées assignées par l'utilisateur, l'identité est gérée séparément des ressources qui l'utilisent.
Rôles et autorisations
Les rôles sont attribués aux principaux sur un champ : principal -[HAS ROLE]->(scope)
Les rôles attribués aux groupes sont hérités par tous les membres du groupe.
Selon le champ auquel le rôle a été attribué, le rôle peut être hérité par d'autres ressources à l'intérieur du conteneur de champ. Par exemple, si un utilisateur A a un rôle sur l'abonnement, il aura ce rôle sur tous les groupes de ressources à l'intérieur de l'abonnement et sur toutes les ressources à l'intérieur du groupe de ressources.
Rôles classiques
Propriétaire |
| Tous les types de ressources |
Contributeur |
| Tous les types de ressources |
Lecteur | • Voir toutes les ressources | Tous les types de ressources |
Administrateur d'accès utilisateur |
| Tous les types de ressources |
Rôles intégrés
Des docs : Le contrôle d'accès basé sur les rôles Azure (Azure RBAC) a plusieurs rôles intégrés Azure que vous pouvez attribuer à des utilisateurs, groupes, principaux de service et identités gérées. Les attributions de rôles sont la manière dont vous contrôlez l'accès aux ressources Azure. Si les rôles intégrés ne répondent pas aux besoins spécifiques de votre organisation, vous pouvez créer vos propres rôles personnalisés Azure.
Les rôles intégrés s'appliquent uniquement aux ressources pour lesquelles ils sont destinés, par exemple, consultez ces 2 exemples de rôles intégrés sur les ressources de calcul :
Fournit l'autorisation au coffre de sauvegarde pour effectuer une sauvegarde de disque. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Voir les machines virtuelles dans le portail et se connecter en tant qu'utilisateur régulier. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
Ces rôles peuvent également être attribués sur des conteneurs logiques (tels que des groupes de gestion, des abonnements et des groupes de ressources) et les principaux affectés les auront sur les ressources à l'intérieur de ces conteneurs.
Trouvez ici une liste avec tous les rôles intégrés Azure.
Trouvez ici une liste avec tous les rôles intégrés Azure AD.
Rôles personnalisés
Azure permet également de créer des rôles personnalisés avec les autorisations dont l'utilisateur a besoin.
Autorisation refusée
Pour qu'un principal ait un accès sur une ressource, il a besoin d'un rôle explicite qui lui est accordé (de toute façon) lui accordant cette autorisation.
Une attribution de rôle explicite de refus a la priorité sur le rôle accordant l'autorisation.
Administrateur global
Les utilisateurs avec le rôle d'Administrateur global ont la capacité de 's'élever au rôle d'Administrateur d'accès utilisateur Azure au groupe de gestion racine**. Cela signifie qu'un Administrateur global pourra gérer l'accès à tous les abonnements Azure et groupes de gestion. Cette élévation peut être effectuée en bas de la page : https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Politiques Azure
Les politiques Azure sont un ensemble de règles et de réglementations dans Microsoft Azure, un service de cloud computing, qui aident à gérer et à faire respecter les normes organisationnelles et à évaluer la conformité à grande échelle. Ces politiques appliquent différentes règles sur vos ressources Azure, garantissant que ces ressources restent conformes aux normes de l'entreprise et aux accords de niveau de service.
Les politiques Azure sont cruciales pour la gouvernance et la sécurité du cloud, aidant à garantir que les ressources sont utilisées correctement et efficacement, et qu'elles respectent les réglementations externes et les politiques internes. Quelques exemples :
Assurer la conformité avec des régions Azure spécifiques : Cette politique garantit que toutes les ressources sont déployées dans des régions Azure spécifiques. Par exemple, une entreprise pourrait vouloir s'assurer que toutes ses données sont stockées en Europe pour se conformer au RGPD.
Faire respecter les normes de nommage : Les politiques peuvent faire respecter des conventions de nommage pour les ressources Azure. Cela aide à organiser et à identifier facilement les ressources en fonction de leurs noms, ce qui est utile dans de grands environnements.
Restreindre certains types de ressources : Cette politique peut restreindre la création de certains types de ressources. Par exemple, une politique pourrait être mise en place pour empêcher la création de types de ressources coûteux, comme certaines tailles de VM, pour contrôler les coûts.
Faire respecter les politiques de balisage : Les balises sont des paires clé-valeur associées aux ressources Azure utilisées pour la gestion des ressources. Les politiques peuvent faire respecter la présence de certaines balises, ou avoir des valeurs spécifiques, pour toutes les ressources. Cela est utile pour le suivi des coûts, la propriété ou la catégorisation des ressources.
Limiter l'accès public aux ressources : Les politiques peuvent faire respecter que certaines ressources, comme les comptes de stockage ou les bases de données, n'ont pas de points de terminaison publics, garantissant qu'elles ne sont accessibles que dans le réseau de l'organisation.
Appliquer automatiquement des paramètres de sécurité : Les politiques peuvent être utilisées pour appliquer automatiquement des paramètres de sécurité aux ressources, comme appliquer un groupe de sécurité réseau spécifique à toutes les VM ou garantir que tous les comptes de stockage utilisent le chiffrement.
Notez que les politiques Azure peuvent être attachées à n'importe quel niveau de la hiérarchie Azure, mais elles sont généralement utilisées dans le groupe de gestion racine ou dans d'autres groupes de gestion.
Champ des autorisations
Dans Azure, les autorisations peuvent être attribuées à n'importe quelle partie de la hiérarchie. Cela inclut les groupes de gestion, les abonnements, les groupes de ressources et les ressources individuelles. Les autorisations sont héritées par les ressources contenues de l'entité où elles ont été attribuées.
Cette structure hiérarchique permet une gestion efficace et évolutive des autorisations d'accès.
Azure RBAC vs ABAC
RBAC (contrôle d'accès basé sur les rôles) est ce que nous avons déjà vu dans les sections précédentes : Attribuer un rôle à un principal pour lui accorder l'accès à une ressource. Cependant, dans certains cas, vous pourriez vouloir fournir une gestion d'accès plus fine ou simplifier la gestion de centaines d'attributions de rôles.
Azure ABAC (contrôle d'accès basé sur les attributs) s'appuie sur Azure RBAC en ajoutant des conditions d'attribution de rôle basées sur des attributs dans le contexte d'actions spécifiques. Une condition d'attribution de rôle est un vérification supplémentaire que vous pouvez ajouter en option à votre attribution de rôle pour fournir un contrôle d'accès plus fin. Une condition filtre les autorisations accordées dans le cadre de la définition de rôle et de l'attribution de rôle. Par exemple, vous pouvez ajouter une condition qui exige qu'un objet ait une balise spécifique pour lire l'objet. Vous ne pouvez pas explicitement refuser l'accès à des ressources spécifiques en utilisant des conditions.
Autorisations par défaut des utilisateurs
Un utilisateur de base aura certaines autorisations par défaut pour énumérer certaines parties d'AzureAD :
Lire tous les utilisateurs, groupes, applications, appareils, rôles, abonnements et leurs propriétés publiques
Inviter des invités (peut être désactivé)
Créer des groupes de sécurité
Lire les adhésions de groupe non cachées
Ajouter des invités aux groupes possédés
Créer une nouvelle application (peut être désactivé)
Ajouter jusqu'à 50 appareils à Azure (peut être désactivé)
Vous pouvez voir la liste complète des autorisations par défaut des utilisateurs dans les docs. De plus, notez que dans cette liste, vous pouvez également voir la liste des autorisations par défaut des invités.
N'oubliez pas que pour énumérer les ressources Azure, l'utilisateur a besoin d'un accord explicite de l'autorisation.
Gestion des identités privilégiées (PIM)
La gestion des identités privilégiées (PIM) dans Azure est un outil qui gère, contrôle et surveille l'accès privilégié dans Azure Active Directory et Azure. Il améliore la sécurité en fournissant un accès privilégié juste-à-temps et limité dans le temps, en faisant respecter des flux de travail d'approbation et en exigeant une authentification supplémentaire. Cette approche minimise le risque d'accès non autorisé en garantissant que les autorisations élevées ne sont accordées que lorsque cela est nécessaire et pour une durée spécifique.
Jetons d'authentification
Il existe trois types de jetons utilisés dans OIDC :
Jetons d'accès: Le client présente ce jeton au serveur de ressources pour accéder aux ressources. Il ne peut être utilisé que pour une combinaison spécifique d'utilisateur, de client et de ressource et ne peut pas être révoqué jusqu'à expiration - c'est-à-dire 1 heure par défaut. La détection est faible en utilisant cela.
Jetons d'identité : Le client reçoit ce jeton du serveur d'autorisation. Il contient des informations de base sur l'utilisateur. Il est lié à une combinaison spécifique d'utilisateur et de client.
Jetons de rafraîchissement : Fournis au client avec le jeton d'accès. Utilisé pour obtenir de nouveaux jetons d'accès et d'identité. Il est lié à une combinaison spécifique d'utilisateur et de client et peut être révoqué. L'expiration par défaut est de 90 jours pour les jetons de rafraîchissement inactifs et pas d'expiration pour les jetons actifs.
Les informations pour l'accès conditionnel sont stockées à l'intérieur du JWT. Donc, si vous demandez le jeton d'une adresse IP autorisée, cette IP sera stockée dans le jeton et vous pourrez ensuite utiliser ce jeton d'une adresse IP non autorisée pour accéder aux ressources.
Consultez la page suivante pour apprendre différentes manières de demander des jetons d'accès et de vous connecter avec eux :
Az - AzureAD (AAD)Les points de terminaison API les plus courants sont :
Azure Resource Manager (ARM) : management.azure.com
Microsoft Graph : graph.microsoft.com (Azure AD Graph qui est obsolète est graph.windows.net)
Références
Last updated
