mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 14:40:37 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -2,17 +2,17 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Hiérarchie de l'organisation
|
||||
## Hiérarchie Organisationnelle
|
||||
|
||||
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUcVrh1BpuQXN7RzGqoxrn-4Nm_sjdJU-dDTvshloB7UMQnN1mtH9N94zNiPCzOYAqE9EsJqlboZOj47tQsQktjxszpKvIDPZLs9rgyiObcZCvl7N0ZWztshR0ZddyBYZIAwPIkrEQ=s2048?key=l3Eei079oPmVJuh8lxQYxxrB" alt=""><figcaption><p><a href="https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png">https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png</a></p></figcaption></figure>
|
||||
|
||||
### Groupes de gestion
|
||||
### Groupes de Gestion
|
||||
|
||||
- Il peut contenir **d'autres groupes de gestion ou abonnements**.
|
||||
- Cela permet d'**appliquer des contrôles de gouvernance** tels que RBAC et Azure Policy une fois au niveau du groupe de gestion et de les **hériter** par tous les abonnements dans le groupe.
|
||||
- **10 000 groupes de gestion** peuvent être pris en charge dans un seul annuaire.
|
||||
- Un arbre de groupes de gestion peut supporter **jusqu'à six niveaux de profondeur**. Cette limite n'inclut pas le niveau racine ou le niveau d'abonnement.
|
||||
- Chaque groupe de gestion et abonnement peut supporter **uniquement un parent**.
|
||||
- Un arbre de groupes de gestion peut prendre en charge **jusqu'à six niveaux de profondeur**. Cette limite n'inclut pas le niveau racine ou le niveau d'abonnement.
|
||||
- Chaque groupe de gestion et abonnement peut prendre en charge **un seul parent**.
|
||||
- Même si plusieurs groupes de gestion peuvent être créés, **il n'y a qu'un seul groupe de gestion racine**.
|
||||
- Le groupe de gestion racine **contient** tous les **autres groupes de gestion et abonnements** et **ne peut pas être déplacé ou supprimé**.
|
||||
- Tous les abonnements au sein d'un seul groupe de gestion doivent faire confiance au **même locataire Entra ID.**
|
||||
@@ -21,20 +21,20 @@
|
||||
|
||||
### Abonnements Azure
|
||||
|
||||
- C'est un autre **conteneur logique où les ressources** (VM, DB…) peuvent être exécutées et seront facturées.
|
||||
- C'est un autre **conteneur logique où les ressources** (VMs, DBs…) peuvent être exécutées et seront facturées.
|
||||
- Son **parent** est toujours un **groupe de gestion** (et cela peut être le groupe de gestion racine) car les abonnements ne peuvent pas contenir d'autres abonnements.
|
||||
- Il **fait confiance à un seul annuaire Entra ID**
|
||||
- Les **permissions** appliquées au niveau de l'abonnement (ou à l'un de ses parents) sont **héritées** par toutes les ressources à l'intérieur de l'abonnement.
|
||||
|
||||
### Groupes de ressources
|
||||
### Groupes de Ressources
|
||||
|
||||
[Des docs :](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) 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 pour 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.
|
||||
[Dans la documentation :](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) 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 pour 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.
|
||||
|
||||
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfe8U30iP_vdZCvxX4g8nEPRLoo7v0kmCGkDn1frBPn3_GIoZ7VT2LkdsVQWCnrG_HSYNRRPM-1pSECUkbDAB-9YbUYLzpvKVLDETZS81CHWKYM4fDl3oMo5-yvTMnjdLTS2pz8U67xUTIzBhZ25MFMRkq5koKY=s2048?key=gSyKQr3HTyhvHa28Rf7LVA" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1</a></p></figcaption></figure>
|
||||
|
||||
### Identifiants de ressources Azure
|
||||
### Identifiants de Ressources Azure
|
||||
|
||||
Chaque ressource dans Azure a un identifiant de ressource Azure qui l'identifie.
|
||||
|
||||
@@ -46,7 +46,7 @@ Pour une machine virtuelle nommée myVM dans un groupe de ressources `myResource
|
||||
|
||||
- `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`
|
||||
|
||||
## Azure vs Entra ID vs Services de domaine Azure AD
|
||||
## Azure vs Entra ID vs Services de Domaine Azure AD
|
||||
|
||||
### Azure
|
||||
|
||||
@@ -56,9 +56,9 @@ Azure est la **plateforme de cloud computing complète de Microsoft, offrant une
|
||||
|
||||
Entra ID est un service de **gestion des identités et des accès basé sur le cloud** conçu pour gérer l'authentification, l'autorisation et le contrôle d'accès des utilisateurs. Il permet un accès sécurisé aux services Microsoft tels qu'Office 365, Azure et de nombreuses applications SaaS tierces. Avec des fonctionnalités telles que l'authentification unique (SSO), l'authentification multi-facteurs (MFA) et des politiques d'accès conditionnel, entre autres.
|
||||
|
||||
### Services de domaine Entra (anciennement Azure AD DS)
|
||||
### Services de Domaine Entra (anciennement Azure AD DS)
|
||||
|
||||
Les services de domaine Entra étendent les capacités d'Entra ID en offrant des **services de domaine gérés compatibles avec les environnements traditionnels de Windows Active Directory**. Il prend en charge des protocoles hérités tels que LDAP, Kerberos et NTLM, permettant aux organisations de migrer ou d'exécuter des applications plus anciennes dans le cloud sans déployer de contrôleurs de domaine sur site. Ce service prend également en charge les stratégies de groupe pour une gestion centralisée, ce qui le rend adapté aux scénarios où des charges de travail héritées ou basées sur AD doivent coexister avec des environnements cloud modernes.
|
||||
Les Services de Domaine Entra étendent les capacités d'Entra ID en offrant des **services de domaine gérés compatibles avec les environnements traditionnels de Windows Active Directory**. Il prend en charge des protocoles hérités tels que LDAP, Kerberos et NTLM, permettant aux organisations de migrer ou d'exécuter des applications plus anciennes dans le cloud sans déployer de contrôleurs de domaine sur site. Ce service prend également en charge les stratégies de groupe pour une gestion centralisée, ce qui le rend adapté aux scénarios où des charges de travail héritées ou basées sur AD doivent coexister avec des environnements cloud modernes.
|
||||
|
||||
## Principaux Entra ID
|
||||
|
||||
@@ -75,9 +75,9 @@ Les services de domaine Entra étendent les capacités d'Entra ID en offrant des
|
||||
- Indiquer les propriétés
|
||||
- Le type d'utilisateur par défaut est “**Invité**”
|
||||
|
||||
### Permissions par défaut des membres et invités
|
||||
### Permissions par défaut des Membres & Invités
|
||||
|
||||
Vous pouvez les consulter sur [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) mais parmi d'autres actions, un membre pourra :
|
||||
Vous pouvez les vérifier dans [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) mais parmi d'autres actions, un membre pourra :
|
||||
|
||||
- Lire tous les utilisateurs, groupes, applications, appareils, rôles, abonnements et leurs propriétés publiques
|
||||
- Inviter des invités (_peut être désactivé_)
|
||||
@@ -90,7 +90,7 @@ Vous pouvez les consulter sur [https://learn.microsoft.com/en-us/entra/fundament
|
||||
> [!NOTE]
|
||||
> N'oubliez pas que pour énumérer les ressources Azure, l'utilisateur a besoin d'une attribution explicite de la permission.
|
||||
|
||||
### Permissions configurables par défaut des utilisateurs
|
||||
### Permissions configurables par défaut des Utilisateurs
|
||||
|
||||
- **Membres (**[**docs**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
|
||||
- Enregistrer des applications : Par défaut **Oui**
|
||||
@@ -98,21 +98,21 @@ Vous pouvez les consulter sur [https://learn.microsoft.com/en-us/entra/fundament
|
||||
- Créer des groupes de sécurité : Par défaut **Oui**
|
||||
- Restreindre l'accès au portail d'administration Microsoft Entra : Par défaut **Non**
|
||||
- Cela ne restreint pas l'accès API au portail (uniquement web)
|
||||
- Autoriser les utilisateurs à connecter un compte de travail ou scolaire avec LinkedIn : Par défaut **Oui**
|
||||
- Autoriser les utilisateurs à connecter leur compte de travail ou scolaire avec LinkedIn : Par défaut **Oui**
|
||||
- Afficher garder l'utilisateur connecté : Par défaut **Oui**
|
||||
- Restreindre les utilisateurs de récupérer la ou les clés BitLocker pour leurs appareils possédés : Par défaut Non (vérifiez dans les paramètres de l'appareil)
|
||||
- Lire d'autres utilisateurs : Par défaut **Oui** (via Microsoft Graph)
|
||||
- **Invités**
|
||||
- **Restrictions d'accès des utilisateurs invités**
|
||||
- **Les utilisateurs invités ont le même accès que les membres** accorde par défaut toutes les permissions des utilisateurs membres aux utilisateurs invités.
|
||||
- **Les utilisateurs invités ont le même accès que les membres** accorde toutes les permissions des utilisateurs membres aux utilisateurs invités par défaut.
|
||||
- **Les utilisateurs invités ont un accès limité aux propriétés et adhésions des objets d'annuaire (par défaut)** restreint l'accès des invités uniquement à leur propre profil utilisateur par défaut. L'accès aux informations d'autres utilisateurs et groupes n'est plus autorisé.
|
||||
- **L'accès des utilisateurs invités est restreint aux propriétés et adhésions de leurs propres objets d'annuaire** est la plus restrictive.
|
||||
- **L'accès des utilisateurs invités est restreint aux propriétés et adhésions de leurs propres objets d'annuaire** est le plus restrictif.
|
||||
- **Les invités peuvent inviter**
|
||||
- **Quiconque dans l'organisation peut inviter des utilisateurs invités, y compris des invités et des non-administrateurs (le plus inclusif) - Par défaut**
|
||||
- **Tout le monde dans l'organisation peut inviter des utilisateurs invités, y compris des invités et des non-administrateurs (le plus inclusif) - Par défaut**
|
||||
- **Les utilisateurs membres et les utilisateurs assignés à des rôles administratifs spécifiques peuvent inviter des utilisateurs invités, y compris des invités avec des permissions de membre**
|
||||
- **Seuls les utilisateurs assignés à des rôles administratifs spécifiques peuvent inviter des utilisateurs invités**
|
||||
- **Personne dans l'organisation ne peut inviter des utilisateurs invités, y compris des administrateurs (le plus restrictif)**
|
||||
- **Les utilisateurs externes peuvent partir** : Par défaut **Vrai**
|
||||
- **Personne dans l'organisation ne peut inviter des utilisateurs invités, y compris les administrateurs (le plus restrictif)**
|
||||
- **Les utilisateurs externes peuvent quitter** : Par défaut **Vrai**
|
||||
- Autoriser les utilisateurs externes à quitter l'organisation
|
||||
|
||||
> [!TIP]
|
||||
@@ -122,7 +122,7 @@ Vous pouvez les consulter sur [https://learn.microsoft.com/en-us/entra/fundament
|
||||
|
||||
Il existe **2 types de groupes** :
|
||||
|
||||
- **Sécurité** : Ce type de groupe est utilisé pour donner aux membres accès aux applications, ressources et attribuer des licences. Les utilisateurs, appareils, principaux de service et autres groupes peuvent être membres.
|
||||
- **Sécurité** : Ce type de groupe est utilisé pour donner aux membres accès aux applications, ressources et assigner des licences. Les utilisateurs, appareils, principaux de service et autres groupes peuvent être membres.
|
||||
- **Microsoft 365** : Ce type de groupe est utilisé pour la collaboration, donnant aux membres accès à une boîte aux lettres partagée, un calendrier, des fichiers, un site SharePoint, etc. Les membres du groupe ne peuvent être que des utilisateurs.
|
||||
- Cela aura une **adresse email** avec le domaine du locataire EntraID.
|
||||
|
||||
@@ -131,31 +131,31 @@ Il existe **2 types d'adhésions** :
|
||||
- **Assigné** : Permet d'ajouter manuellement des membres spécifiques à un groupe.
|
||||
- **Adhésion dynamique** : Gère automatiquement l'adhésion en utilisant des règles, mettant à jour l'inclusion du groupe lorsque les attributs des membres changent.
|
||||
|
||||
### **Principaux de service**
|
||||
### **Principaux de Service**
|
||||
|
||||
Un **Principal de service** 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 assigné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.
|
||||
Un **Principal de Service** 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 assigné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.
|
||||
|
||||
Il est possible de **se connecter directement en tant que principal de service** en lui générant un **secret** (mot de passe), un **certificat**, ou en accordant un accès **fédéré** à des plateformes tierces (par exemple, Github Actions) à son sujet.
|
||||
Il est possible de **se connecter directement en tant que principal de service** en lui générant un **secret** (mot de passe), un **certificat**, ou en accordant un accès **fédéré** à des plateformes tierces (par exemple, Github Actions) à travers lui.
|
||||
|
||||
- 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**.
|
||||
|
||||
### Enregistrements d'applications
|
||||
### Enregistrements d'Applications
|
||||
|
||||
Un **Enregistrement d'application** est une configuration qui permet à une application de s'intégrer avec Entra ID et d'effectuer des actions.
|
||||
Un **Enregistrement d'Application** est une configuration qui permet à une application de s'intégrer avec Entra ID et d'effectuer des actions.
|
||||
|
||||
#### Composants clés :
|
||||
#### Composants Clés :
|
||||
|
||||
1. **ID d'application (Client ID)** : Un identifiant unique pour votre application dans Azure AD.
|
||||
2. **URI de redirection** : URLs où Azure AD envoie les réponses d'authentification.
|
||||
3. **Certificats, Secrets & Identifiants fédérés** : Il est possible de générer un secret ou un certificat pour se connecter en tant que principal de service de l'application, ou d'accorder un accès fédéré à celle-ci (par exemple, Github Actions). 
|
||||
1. **ID d'Application (Client ID)** : Un identifiant unique pour votre application dans Azure AD.
|
||||
2. **URIs de Redirection** : URLs où Azure AD envoie les réponses d'authentification.
|
||||
3. **Certificats, Secrets & Identifiants Fédérés** : Il est possible de générer un secret ou un certificat pour se connecter en tant que principal de service de l'application, ou pour accorder un accès fédéré à celle-ci (par exemple, Github Actions). 
|
||||
1. Si un **certificat** ou un **secret** est généré, il est possible pour une personne de **se connecter en tant que principal de service** avec des outils CLI en connaissant l'**ID d'application**, le **secret** ou le **certificat** et le **locataire** (domaine ou ID).
|
||||
4. **Permissions API** : Spécifie quelles ressources ou API l'application peut accéder.
|
||||
5. **Paramètres d'authentification** : Définit les flux d'authentification pris en charge par l'application (par exemple, OAuth2, OpenID Connect).
|
||||
6. **Principal de service** : Un principal de service est créé lorsqu'une application est créée (si cela est fait depuis la console web) ou lorsqu'elle est installée dans un nouveau locataire.
|
||||
4. **Permissions API** : Spécifie quelles ressources ou APIs l'application peut accéder.
|
||||
5. **Paramètres d'Authentification** : Définit les flux d'authentification pris en charge par l'application (par exemple, OAuth2, OpenID Connect).
|
||||
6. **Principal de Service** : Un principal de service est créé lorsqu'une application est créée (si cela est fait depuis la console web) ou lorsqu'elle est installée dans un nouveau locataire.
|
||||
1. Le **principal de service** obtiendra toutes les permissions demandées avec lesquelles il a été configuré.
|
||||
|
||||
### Permissions de consentement par défaut
|
||||
### Permissions de Consentement par Défaut
|
||||
|
||||
**Consentement des utilisateurs pour les applications**
|
||||
|
||||
@@ -163,7 +163,7 @@ Un **Enregistrement d'application** est une configuration qui permet à une appl
|
||||
- Un administrateur sera requis pour toutes les applications.
|
||||
- **Autoriser le consentement des utilisateurs pour les applications de publishers vérifiés, pour des permissions sélectionnées (Recommandé)**
|
||||
- Tous les utilisateurs peuvent consentir pour des permissions classées comme "faible impact", pour des applications de publishers vérifiés ou des applications enregistrées dans cette organisation.
|
||||
- **Permissions par défaut à faible impact** (bien que vous deviez accepter de les ajouter comme faibles) :
|
||||
- **Permissions à faible impact par défaut** (bien que vous deviez accepter de les ajouter comme faibles) :
|
||||
- User.Read - se connecter et lire le profil utilisateur
|
||||
- offline_access - maintenir l'accès aux données auxquelles les utilisateurs ont donné accès
|
||||
- openid - connecter les utilisateurs
|
||||
@@ -175,27 +175,27 @@ Un **Enregistrement d'application** est une configuration qui permet à une appl
|
||||
**Demandes de consentement administratives** : Par défaut **Non**
|
||||
|
||||
- Les utilisateurs peuvent demander le consentement administratif pour des applications auxquelles ils ne peuvent pas consentir
|
||||
- Si **Oui** : Il est possible d'indiquer les utilisateurs, groupes et rôles qui peuvent consentir aux demandes
|
||||
- Configurez également si les utilisateurs recevront des notifications par email et des rappels d'expiration 
|
||||
- Si **Oui** : Il est possible d'indiquer les Utilisateurs, Groupes et Rôles qui peuvent consentir aux demandes
|
||||
- Configurer également si les utilisateurs recevront des notifications par email et des rappels d'expiration 
|
||||
|
||||
### **Identité gérée (Métadonnées)**
|
||||
### **Identité Gérée (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** aux **ressources** compatibles avec l'authentification Azure Active Directory (**Azure AD**). Cela permet de **supprimer le besoin de coder en dur les identifiants cloud** dans le code, car l'application pourra contacter le **service de métadonnées** pour obtenir un jeton valide afin de **réaliser des actions** en tant qu'identité gérée indiquée dans Azure.
|
||||
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** aux **ressources** compatibles avec l'authentification Azure Active Directory (**Azure AD**). Cela permet de **supprimer le besoin de coder en dur les identifiants cloud** dans le code car l'application pourra contacter le **service de métadonnées** pour obtenir un jeton valide afin de **réaliser des actions** en tant qu'identité gérée indiquée dans Azure.
|
||||
|
||||
Il existe deux types d'identités gérées :
|
||||
|
||||
- **Assigné au 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 au système, un **principal de service** est créé dans le locataire Entra ID de confiance par l'abonnement où la ressource est située. Lorsque la **ressource** est **supprimée**, Azure supprime automatiquement **l'identité** pour vous.
|
||||
- **Assigné par l'utilisateur**. Il est également possible pour les utilisateurs de générer des identités gérées. Celles-ci sont créées à l'intérieur d'un groupe de ressources dans un abonnement et un principal de service sera créé dans l'EntraID de confiance par l'abonnement. Ensuite, vous pouvez assigner l'identité gérée à 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**.
|
||||
- **Assignée au 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 au système, un **principal de service** est créé dans le locataire Entra ID de confiance par l'abonnement où la ressource est située. Lorsque la **ressource** est **supprimée**, Azure supprime automatiquement **l'identité** pour vous.
|
||||
- **Assignée par l'utilisateur**. Il est également possible pour les utilisateurs de générer des identités gérées. Celles-ci sont créées à l'intérieur d'un groupe de ressources dans un abonnement et un principal de service sera créé dans l'EntraID de confiance par l'abonnement. Ensuite, vous pouvez assigner l'identité gérée à 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**.
|
||||
|
||||
Les identités gérées **ne génèrent pas de credentials éternels** (comme des mots de passe ou des certificats) pour accéder en tant que principal de service qui y est attaché.
|
||||
Les Identités Gérées **ne génèrent pas de credentials éternels** (comme des mots de passe ou des certificats) pour accéder en tant que principal de service qui y est attaché.
|
||||
|
||||
### Applications d'entreprise
|
||||
### Applications d'Entreprise
|
||||
|
||||
C'est juste une **table dans Azure pour filtrer les principaux de service** et vérifier les applications qui leur ont été assignées.
|
||||
C'est juste une **table dans Azure pour filtrer les principaux de service** et vérifier les applications qui ont été assignées.
|
||||
|
||||
**Ce n'est pas un autre type d'“application”**, il n'y a aucun objet dans Azure qui soit une “Application d'entreprise”, c'est juste une abstraction pour vérifier les Principaux de service, les Enregistrements d'applications et les identités gérées.
|
||||
**Ce n'est pas un autre type d'“application”**, il n'y a aucun objet dans Azure qui est une “Application d'Entreprise”, c'est juste une abstraction pour vérifier les Principaux de Service, les Enregistrements d'Applications et les Identités Gérées.
|
||||
|
||||
### Unités administratives
|
||||
### Unités Administratives
|
||||
|
||||
Les unités administratives permettent de **donner des permissions d'un rôle sur une portion spécifique d'une organisation**.
|
||||
|
||||
@@ -203,54 +203,54 @@ Exemple :
|
||||
|
||||
- Scénario : Une entreprise souhaite que les administrateurs informatiques régionaux gèrent uniquement les utilisateurs de leur propre région.
|
||||
- Mise en œuvre :
|
||||
- Créer des unités administratives pour chaque région (par exemple, "AU Amérique du Nord", "AU Europe").
|
||||
- Créer des Unités Administratives pour chaque région (par exemple, "AU Amérique du Nord", "AU Europe").
|
||||
- Peupler les AU avec des utilisateurs de leurs régions respectives.
|
||||
- Les AU peuvent **contenir des utilisateurs, groupes ou appareils**
|
||||
- Les AU prennent en charge **les adhésions dynamiques**
|
||||
- Les AU **ne peuvent pas contenir d'AU**
|
||||
- Attribuer des rôles administratifs :
|
||||
- Accorder le rôle "Administrateur des utilisateurs" au personnel informatique régional, limité à l'AU de leur région.
|
||||
- Assigner des Rôles Administrateurs :
|
||||
- Accorder le rôle "Administrateur des Utilisateurs" au personnel informatique régional, limité à l'AU de leur région.
|
||||
- Résultat : Les administrateurs informatiques régionaux peuvent gérer les comptes utilisateurs au sein de leur région sans affecter d'autres régions.
|
||||
|
||||
### Rôles Entra ID
|
||||
|
||||
- Afin de gérer Entra ID, il existe certains **rôles intégrés** qui peuvent être assignés aux principaux Entra ID pour gérer Entra ID
|
||||
- Vérifiez les rôles sur [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
|
||||
- Le rôle le plus privilégié est **Administrateur global**
|
||||
- Vérifiez les rôles dans [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
|
||||
- Le rôle le plus privilégié est **Administrateur Global**
|
||||
- Dans la description du rôle, il est possible de voir ses **permissions granulaires**
|
||||
|
||||
## Rôles & Permissions
|
||||
|
||||
**Les rôles** sont **assignés** aux **principaux** sur un **scope** : `principal -[HAS ROLE]->(scope)`
|
||||
**Les Rôles** sont **assignés** aux **principaux** sur un **scope** : `principal -[HAS ROLE]->(scope)`
|
||||
|
||||
**Les rôles** assignés aux **groupes** sont **hérités** par tous les **membres** du groupe.
|
||||
**Les Rôles** assignés aux **groupes** sont **hérités** par tous les **membres** du groupe.
|
||||
|
||||
Selon le 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.
|
||||
Selon le scope auquel le rôle a été assigné, le **rôle** peut être **hérité** à **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**
|
||||
### **Rôles Classiques**
|
||||
|
||||
| **Propriétaire** | <ul><li>Accès complet à toutes les ressources</li><li>Peut gérer l'accès pour d'autres utilisateurs</li></ul> | Tous les types de ressources |
|
||||
| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
|
||||
| **Contributeur** | <ul><li>Accès complet à toutes les ressources</li><li>Ne peut pas gérer l'accès</li></ul> | Tous les types de ressources |
|
||||
| **Lecteur** | • Voir toutes les ressources | Tous les types de ressources |
|
||||
| **Administrateur d'accès utilisateur** | <ul><li>Voir toutes les ressources</li><li>Peut gérer l'accès pour d'autres utilisateurs</li></ul> | Tous les types de ressources |
|
||||
| **Administrateur d'Accès Utilisateur** | <ul><li>Voir toutes les ressources</li><li>Peut gérer l'accès pour d'autres utilisateurs</li></ul> | Tous les types de ressources |
|
||||
|
||||
### Rôles intégrés
|
||||
### Rôles Intégrés
|
||||
|
||||
[Des docs : ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Le contrôle d'accès basé sur les rôles Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) a plusieurs **rôles intégrés Azure** que vous pouvez **assigner** à **des utilisateurs, groupes, principaux de service et identités gérées**. Les attributions de rôle 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**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
|
||||
[Dans la documentation : ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Le contrôle d'accès basé sur les rôles Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) a plusieurs **rôles intégrés Azure** que vous pouvez **assigner** à **utilisateurs, groupes, principaux de service et identités gérées**. Les attributions de rôle 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**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
|
||||
|
||||
Les **rôles intégrés** s'appliquent uniquement aux **ressources** pour lesquelles ils sont **destinés**, par exemple, vérifiez ces 2 exemples de **rôles intégrés sur les ressources Compute** :
|
||||
Les **Rôles Intégrés** s'appliquent uniquement aux **ressources** auxquelles ils sont **destinés**, par exemple, vérifiez ces 2 exemples de **Rôles Intégrés sur les ressources de Calcul** :
|
||||
|
||||
| [Lecteur de sauvegarde de disque](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | Fournit la permission au coffre de sauvegarde pour effectuer une sauvegarde de disque. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
|
||||
| [Lecteur de Sauvegarde de Disque](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | Fournit la permission au coffre de sauvegarde pour effectuer une sauvegarde de disque. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
|
||||
| ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
|
||||
| [Connexion utilisateur de machine virtuelle](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Voir les machines virtuelles dans le portail et se connecter en tant qu'utilisateur régulier. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
|
||||
| [Connexion Utilisateur de Machine Virtuelle](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | 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 assigné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**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
|
||||
- Trouvez ici une liste avec [**tous les rôles intégrés Entra ID**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
|
||||
|
||||
### Rôles personnalisés
|
||||
### Rôles Personnalisés
|
||||
|
||||
- Il est également possible de créer [**rôles personnalisés**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
|
||||
- Ils sont créés à l'intérieur d'un scope, bien qu'un rôle puisse être dans plusieurs scopes (groupes de gestion, abonnements et groupes de ressources)
|
||||
@@ -262,7 +262,7 @@ Ces rôles peuvent **également être assignés sur des conteneurs logiques** (t
|
||||
- `actions` sont pour contrôler les actions sur la ressource
|
||||
- `dataActions` sont des permissions sur les données à l'intérieur de l'objet
|
||||
|
||||
Exemple de JSON de permissions pour un rôle personnalisé :
|
||||
Exemple de permissions JSON pour un rôle personnalisé :
|
||||
```json
|
||||
{
|
||||
"properties": {
|
||||
@@ -292,47 +292,47 @@ Exemple de JSON de permissions pour un rôle personnalisé :
|
||||
}
|
||||
}
|
||||
```
|
||||
### Permissions order
|
||||
### Ordre des autorisations
|
||||
|
||||
- Afin qu'un **principal ait un accès sur une ressource**, il a besoin d'un rôle explicite qui lui est accordé (de quelque manière que ce soit) **lui accordant cette permission**.
|
||||
- Une **attribution de rôle de refus explicite a la priorité** sur le rôle accordant la permission.
|
||||
- Afin qu'un **principal ait un accès à une ressource**, il a besoin d'un rôle explicite qui lui est accordé (de quelque manière que ce soit) **lui accordant cette permission**.
|
||||
- Une affectation de rôle explicite **de refus a la priorité** sur le rôle accordant la permission.
|
||||
|
||||
<figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
|
||||
|
||||
### Global Administrator
|
||||
### Administrateur global
|
||||
|
||||
Le Global Administrator est un rôle d'Entra ID qui accorde **un contrôle total sur le locataire Entra ID**. Cependant, il n'accorde par défaut aucune permission sur les ressources Azure.
|
||||
L'administrateur global est un rôle d'Entra ID qui accorde **un contrôle total sur le locataire Entra ID**. Cependant, il n'accorde par défaut aucune permission sur les ressources Azure.
|
||||
|
||||
Les utilisateurs ayant le rôle de Global Administrator ont la capacité de '**s'élever' au rôle d'Administrateur d'Accès Utilisateur Azure dans le Groupe de Gestion Racine**. Ainsi, les Global Administrators peuvent gérer l'accès dans **toutes les souscriptions Azure et groupes de gestion.**\
|
||||
Les utilisateurs ayant le rôle d'administrateur global ont la capacité de '**s'élever' au rôle d'administrateur d'accès utilisateur Azure dans le groupe de gestion racine**. Ainsi, les administrateurs globaux peuvent gérer l'accès dans **toutes les souscriptions 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](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
|
||||
|
||||
<figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Azure Policies
|
||||
### Politiques Azure
|
||||
|
||||
**Les Azure Policies** sont des règles qui aident les organisations à s'assurer que leurs ressources répondent à des normes spécifiques et à des exigences de conformité. Elles vous permettent de **faire respecter ou d'auditer les paramètres sur les ressources dans Azure**. Par exemple, vous pouvez empêcher la création de machines virtuelles dans une région non autorisée ou vous assurer que toutes les ressources ont des balises spécifiques pour le suivi.
|
||||
**Les politiques Azure** sont des règles qui aident les organisations à s'assurer que leurs ressources répondent à des normes spécifiques et à des exigences de conformité. Elles vous permettent de **faire respecter ou d'auditer les paramètres sur les ressources dans Azure**. Par exemple, vous pouvez empêcher la création de machines virtuelles dans une région non autorisée ou vous assurer que toutes les ressources ont des balises spécifiques pour le suivi.
|
||||
|
||||
Les Azure Policies sont **proactives** : elles peuvent empêcher la création ou la modification de ressources non conformes. Elles sont également **réactives**, vous permettant de trouver et de corriger les ressources non conformes existantes.
|
||||
Les politiques Azure sont **proactives** : elles peuvent empêcher la création ou la modification de ressources non conformes. Elles sont également **réactives**, vous permettant de trouver et de corriger les ressources non conformes existantes.
|
||||
|
||||
#### **Key Concepts**
|
||||
#### **Concepts clés**
|
||||
|
||||
1. **Définition de la politique** : Une règle, écrite en JSON, qui spécifie ce qui est autorisé ou requis.
|
||||
2. **Attribution de la politique** : L'application d'une politique à un champ spécifique (par exemple, souscription, groupe de ressources).
|
||||
2. **Affectation de la politique** : L'application d'une politique à un champ spécifique (par exemple, souscription, groupe de ressources).
|
||||
3. **Initiatives** : Une collection de politiques regroupées pour une application plus large.
|
||||
4. **Effet** : Spécifie ce qui se passe lorsque la politique est déclenchée (par exemple, "Refuser", "Auditer" ou "Ajouter").
|
||||
|
||||
**Quelques exemples :**
|
||||
|
||||
1. **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.
|
||||
1. **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.
|
||||
2. **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.
|
||||
3. **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.
|
||||
4. **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 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.
|
||||
4. **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.
|
||||
5. **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.
|
||||
6. **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 Azure Policies 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.
|
||||
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.
|
||||
|
||||
Exemple de json de politique Azure :
|
||||
Exemple de politique Azure json :
|
||||
```json
|
||||
{
|
||||
"policyRule": {
|
||||
@@ -350,20 +350,20 @@ Exemple de json de politique Azure :
|
||||
"mode": "All"
|
||||
}
|
||||
```
|
||||
### Héritage des Permissions
|
||||
### Héritage des autorisations
|
||||
|
||||
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 de l'entité où elles ont été attribuées.
|
||||
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 permissions d'accès.
|
||||
Cette structure hiérarchique permet une gestion efficace et évolutive des autorisations d'accès.
|
||||
|
||||
<figure><img src="../../../images/image (26).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### 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 des accès plus granulaire** ou **simplifier** la gestion de **centaines** d'assignations de rôles.
|
||||
Cependant, dans certains cas, vous pourriez vouloir fournir une **gestion des 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'assignation de rôle basées sur des attributs** dans le contexte d'actions spécifiques. Une _condition d'assignation de rôle_ est un **vérification supplémentaire que vous pouvez optionnellement ajouter à votre assignation de rôle** pour fournir un contrôle d'accès plus granulaire. Une condition filtre les permissions accordées dans le cadre de la définition de rôle et de l'assignation de rôle. Par exemple, vous pouvez **ajouter une condition qui exige qu'un objet ait une étiquette spécifique pour lire l'objet**.\
|
||||
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 étiquette spécifique pour lire l'objet**.\
|
||||
Vous **ne pouvez pas** explicitement **refuser** l'**accès** à des ressources spécifiques **en utilisant des conditions**.
|
||||
|
||||
## Références
|
||||
|
||||
@@ -71,7 +71,7 @@ La commande `az account get-access-token --resource-type [...]` prend en charge
|
||||
* **arm (Azure Resource Manager)** : Utilisé pour gérer les ressources Azure via l'API Azure Resource Manager. Cela inclut des opérations telles que la création, la mise à jour et la suppression de ressources telles que des machines virtuelles, des comptes de stockage, et plus encore.
|
||||
- `https://management.core.windows.net/ ou https://management.azure.com/`
|
||||
|
||||
- **batch (Azure Batch Services)** : Utilisé pour accéder à Azure Batch, un service qui permet d'exécuter efficacement des applications de calcul parallèle à grande échelle et à haute performance dans le cloud.
|
||||
- **batch (Azure Batch Services)** : Utilisé pour accéder à Azure Batch, un service qui permet d'exécuter efficacement des applications de calcul parallèle à grande échelle et de haute performance dans le cloud.
|
||||
- `https://batch.core.windows.net/`
|
||||
|
||||
* **data-lake (Azure Data Lake Storage)** : Utilisé pour interagir avec Azure Data Lake Storage Gen1, qui est un service de stockage et d'analyse de données évolutif.
|
||||
@@ -121,7 +121,6 @@ device_flow
|
||||
pprint(azure_cli_bearer_tokens_for_graph_api)
|
||||
|
||||
|
||||
|
||||
# DECODE JWT
|
||||
def decode_jwt(base64_blob: str) -> Dict[str, Any]:
|
||||
"""Decodes base64 encoded JWT blob"""
|
||||
@@ -149,7 +148,7 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
|
||||
|
||||
Il a été mentionné précédemment que les jetons d'actualisation doivent être liés aux **portées** avec lesquelles ils ont été générés, à l'**application** et au **locataire** pour lesquels ils ont été générés. Si l'une de ces limites est franchie, il est possible d'escalader les privilèges car il sera possible de générer des jetons d'accès pour d'autres ressources et locataires auxquels l'utilisateur a accès et avec plus de portées que ce qui était initialement prévu.
|
||||
|
||||
De plus, **cela est possible avec tous les jetons d'actualisation** dans la [plateforme d'identité Microsoft](https://learn.microsoft.com/en-us/entra/identity-platform/) (comptes Microsoft Entra, comptes personnels Microsoft et comptes sociaux comme Facebook et Google) car comme le mentionnent les [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) : "Les jetons d'actualisation sont liés à une combinaison d'utilisateur et de client, mais **ne sont pas liés à une ressource ou à un locataire**. Un client peut utiliser un jeton d'actualisation pour acquérir des jetons d'accès **à travers n'importe quelle combinaison de ressource et de locataire** où il a la permission de le faire. Les jetons d'actualisation sont cryptés et seule la plateforme d'identité Microsoft peut les lire."
|
||||
De plus, **cela est possible avec tous les jetons d'actualisation** dans la [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (comptes Microsoft Entra, comptes personnels Microsoft et comptes sociaux comme Facebook et Google) car comme le mentionnent les [**docs**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens) : "Les jetons d'actualisation sont liés à une combinaison d'utilisateur et de client, mais **ne sont pas liés à une ressource ou à un locataire**. Un client peut utiliser un jeton d'actualisation pour acquérir des jetons d'accès **à travers n'importe quelle combinaison de ressource et de locataire** où il a la permission de le faire. Les jetons d'actualisation sont cryptés et seule la Microsoft identity platform peut les lire."
|
||||
|
||||
De plus, notez que les applications FOCI sont des applications publiques, donc **aucun secret n'est nécessaire** pour s'authentifier auprès du serveur.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user