Az - Basic Information
Hiérarchie de l'organisation
Groupes de gestion
Si votre organisation a de nombreux abonnements Azure, vous pourriez avoir besoin d'un moyen efficace pour gérer l'accès, les politiques et la conformité de ces abonnements. Les groupes de gestion fournissent une portée de gouvernance au-dessus des abonnements.
Notez que 10 000 groupes de gestion peuvent être pris en charge dans un seul annuaire et qu'un arbre de groupe de gestion peut supporter jusqu'à six niveaux de profondeur.
Depuis la documentation : Chaque annuaire reçoit un groupe de gestion de niveau supérieur appelé le groupe de gestion racine. Le groupe de gestion racine est intégré à la hiérarchie pour que tous les groupes de gestion et abonnements y soient rattachés. Ce groupe de gestion racine permet d'appliquer des politiques globales et des affectations 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 de l'annuaire pour gérer la hiérarchie. En tant qu'administrateur, vous pouvez attribuer votre propre compte en tant que 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, quel que soit le type d'abonnements que vous pourriez avoir. Cependant, tous les abonnements au sein d'un même 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és sur les rôles.
Groupes de ressources
Depuis la documentation : 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 de pouvoir les déployer, les mettre à jour et les supprimer facilement en tant que groupe.
Toutes les ressources doivent être à l'intérieur d'un groupe de ressources et ne peuvent appartenir qu'à un seul groupe. Si un groupe de ressources est supprimé, toutes les ressources qu'il contient sont également supprimées.
Unités administratives
Depuis la documentation : Les unités administratives vous permettent de subdiviser 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 permissions 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.
Ainsi, une unité administrative contiendra certains membres et d'autres principaux se verront attribuer des permissions sur cette unité administrative qu'ils pourront 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é d'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 permissions accordées aux groupes sont héritées par ses membres.
Service Principal/Applications d'entreprise : C'est une identité créée pour utilisation 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 accédées 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 (Metadata Creds) : 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 à des ressources compatibles avec l'authentification Azure Active Directory (Azure AD). En utilisant des identités gérées, les applications peuvent sécuriser des 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 permissions
Les rôles sont attribués aux principaux sur une portée : principal -[A UN RÔLE]->(portée)
Les rôles attribués aux groupes sont hérités par tous les membres du groupe.
Selon la portée à laquelle le rôle a été attribué, le rôle pourrait être hérité par d'autres ressources à l'intérieur du conteneur de portée. 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
Depuis la documentation : Azure role-based access control (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 affectations 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 prévus, par exemple, consultez ces 2 exemples de rôles intégrés sur les ressources Compute :
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 permissions dont l'utilisateur a besoin.
Permission refusée
Pour qu'un principal ait un accès à une ressource, il a besoin d'un rôle explicite lui étant accordé (de quelque manière que ce soit) lui accordant cette permission.
Une attribution de rôle de refus explicite prend le pas sur le rôle accordant la permission.
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 et groupes de gestion Azure. Cette élévation peut être effectuée à la fin 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 à appliquer 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 sont conformes aux réglementations externes et aux 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 la conformité au RGPD.
Imposer des normes de dénomination : Les politiques peuvent imposer des conventions de dénomination pour les ressources Azure. Cela aide à organiser et à identifier facilement les ressources en fonction de leurs noms, ce qui est utile dans les 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 définie pour empêcher la création de types de ressources coûteux, comme certaines tailles de VM, pour contrôler les coûts.
Imposer des 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 imposer que certaines balises doivent être présentes, 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 imposer que certaines ressources, comme les comptes de stockage ou les bases de données, n'aient pas de points de terminaison publics, garantissant qu'elles ne sont accessibles qu'au sein du réseau de l'organisation.
Appliquer automatiquement les 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 s'assurer 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 couramment utilisées dans le groupe de gestion racine ou dans d'autres groupes de gestion.
Portée des permissions
Dans Azure, les permissions 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 permissions sont héritées par les ressources contenues dans l'entité où elles ont été attribuées.
Cette structure hiérarchique permet une gestion efficace et évolutive des permissions d'accès.
Azure RBAC vs ABAC
RBAC (role-based access control) 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 des accès plus fine ou simplifier la gestion
Last updated