Az - Basic Information
Hiérarchie de l'organisation
Groupes de gestion
Si votre organisation possède de nombreuses souscriptions Azure, vous pouvez avoir besoin d'un moyen de gérer efficacement l'accès, les politiques et la conformité pour ces souscriptions. Les groupes de gestion fournissent une portée de gouvernance au-dessus des souscriptions.
Notez que 10 000 groupes de gestion peuvent être pris en charge dans un seul répertoire et qu'un arbre de groupes de gestion peut prendre en charge jusqu'à six niveaux de profondeur.
À partir de la documentation : Chaque répertoire reçoit un seul groupe de gestion de niveau supérieur appelé la racine. Le groupe de gestion racine est intégré dans la hiérarchie pour que tous les groupes de gestion et les souscriptions se replient dessus. Ce groupe de gestion racine permet d'appliquer des politiques globales et des affectations de rôles Azure au niveau du répertoire. L' Administrateur global Azure AD doit s'élever lui-même au rôle 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 du répertoire pour gérer la hiérarchie. En tant qu'administrateur, vous pouvez attribuer votre propre compte en tant que propriétaire de la racine du groupe de gestion.
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 qualité entreprise à grande échelle, quel que soit le type de souscriptions que vous pourriez avoir. Cependant, toutes les souscriptions au sein d'un seul groupe de gestion doivent faire confiance au même locataire Azure Active Directory (Azure AD).
Souscriptions Azure
Dans Azure, une souscription sert de conteneur logique dans le but de provisionner des ressources commerciales ou techniques. Ce conteneur conserve 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, la souscription associée est spécifiée. 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
À partir de 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. Généralement, ajoutez des ressources partageant 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 groupe, et si un groupe de ressources est supprimé, toutes les ressources à l'intérieur sont également supprimées.
Unités administratives
À partir de la documentation : Les unités administratives vous permettent de diviser votre organisation en unités de votre choix, puis de 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, les groupes et les 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 pourront utiliser pour gérer les membres de l'unité administrative.
Azure vs Azure AD vs Services de domaine Azure AD
Il est important de noter que Azure AD est un service à l'intérieur de 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 Active Directory de Windows, 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 Active Directory Windows, 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 informations d'identification pour accéder.
Groupe : Un groupe de principaux gérés 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 être utilisée 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 les ressources qui peuvent être accessibles et à quel niveau. Pour des raisons de sécurité, il est toujours recommandé de 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), sauvegardez le mot de passe généré car vous ne pourrez pas y accéder à nouveau.
Si vous choisissez l'authentification par certificat, assurez-vous que l'application aura accès à la clé privée.
Identité gérée (Informations d'identification 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 dans le but de 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 les jetons Azure AD tout en éliminant le besoin de gérer directement les informations d'identification. 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 attribué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 attribuée par l'utilisateur et l'attribuer à une ou plusieurs instances d'un service Azure (plusieurs ressources). Pour les identités gérées attribué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 assignés aux principaux sur un scope : principal -[A UN RÔLE]->(scope)
Les rôles assignés aux groupes sont hérités par tous les membres du groupe.
En fonction du scope auquel le rôle a été assigné, le rôle peut être hérité par d'autres ressources à l'intérieur du conteneur de scope. 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
À partir de la documentation : Le contrôle d'accès basé sur les rôles Azure (Azure RBAC) propose plusieurs rôles intégrés Azure que vous pouvez assigner à 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 auxquelles ils sont destinés, par exemple, consultez ces 2 exemples de rôles intégrés sur les ressources Compute :
Autorise la sauvegarde du disque par le coffre pour effectuer une sauvegarde de disque. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
Afficher 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 assignés sur des conteneurs logiques (tels que des groupes de gestion, des abonnements et des groupes de ressources) et les principaux concernés les auront sur les ressources à l'intérieur de ces conteneurs.
Trouvez ici une liste de tous les rôles intégrés Azure.
Trouvez ici une liste de 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 certain accès à une ressource, il a besoin qu'un rôle explicite lui soit accordé (de toute façon) lui accordant cette autorisation.
Une affectation de rôle de refus explicite a la priorité sur le rôle accordant l'autorisation.
Administrateur Global
Les utilisateurs ayant le rôle d'Administrateur Global ont la capacité de 'élever' au rôle 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 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 imposent 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 essentielles 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 :
Garantir 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.
Imposer des Normes de Nommage : Les politiques peuvent imposer 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 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 d'Étiquetage : Les étiquettes sont des paires clé-valeur associées aux ressources Azure utilisées pour la gestion des ressources. Les politiques peuvent imposer que certaines étiquettes 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 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, tels que l'application d'un groupe de sécurité réseau spécifique à toutes les VM ou en s'assurant 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 Autorisations
Dans Azure, les autorisations peuvent être assigné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é assigné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 : Assigner un rôle à un principal pour lui accorder l'accès à une ressource. Cependant, dans certains cas, vous voudrez peut-être fournir une gestion des accès plus fine ou simplifier la gestion de centaines d'affectations de rôles.
Azure ABAC (contrôle d'accès basé sur les attributs) s'appuie sur Azure RBAC en ajoutant des conditions d'affectation de rôle basées sur des attributs dans le contexte d'actions spécifiques. Une condition d'affectation de rôle est une vérification supplémentaire que vous pouvez éventuellement ajouter à votre affectation 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'affectation de rôle. Par exemple, vous pouvez ajouter une condition qui exige qu'un objet ait une étiquette 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 aux groupes non masqués
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 consulter la liste complète des autorisations par défaut des utilisateurs dans la documentation. 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 consentement 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. Elle renforce la sécurité en fournissant un accès privilégié juste-à-temps et limité dans le temps, en appliquant des workflows d'approbation et en exigeant une authentification supplémentaire. Cette approche réduit au minimum le risque d'accès non autorisé en veillant à ce que les autorisations élevées ne soient accordées que lorsque c'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é avant expiration - qui est de 1 heure par défaut. La détection est faible en utilisant celui-ci.
Jetons ID : 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és pour obtenir de nouveaux jetons d'accès et ID. Ils sont liés à une combinaison spécifique d'utilisateur et de client et peuvent être révoqués. 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. Ainsi, si vous demandez le jeton depuis une adresse IP autorisée, cette IP sera stockée dans le jeton et vous pourrez ensuite utiliser ce jeton depuis une adresse IP non autorisée pour accéder aux ressources.
Consultez la page suivante pour apprendre les différentes façons de demander des jetons d'accès et de vous connecter avec eux :
pageAz - AzureAD (AAD)Les points d'API les plus courants sont :
Gestionnaire de ressources Azure (ARM) : management.azure.com
Microsoft Graph : graph.microsoft.com (Azure AD Graph qui est obsolète est graph.windows.net)
Références
Dernière mise à jour
