mor einfo

src/pentesting-cloud/azure-security/az-basic-information/README.md

@@ -227,7 +227,7 @@ Example:
 
 Depending on the scope the role was assigned to, the **role** cold be **inherited** to **other resources** inside the scope container. For example, if a user A has a **role on the subscription**, he will have that **role on all the resource groups** inside the subscription and on **all the resources** inside the resource group.
 
-### **Classic Roles**
+### Classic Roles
 
 | **Owner**                     | <ul><li>Full access to all resources</li><li>Can manage access for other users</li></ul> | All resource types |
 | ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
@@ -312,6 +312,19 @@ This elevation can be done at the end of the page: [https://portal.azure.com/#vi
 
 <figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
 
+### Assignments Conditions & MFA
+
+It’s possible to **establish some conditions when a role is assigned** to a principal. A common condition to add is to require MFA to access some role permissions:
+
+```bash
+az role assignment create \
+  --assignee <user-or-service-principal-id> \
+  --role <custom-role-id-or-name> \
+  --scope "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f" \
+  --condition "PrincipalClaims['amr'] contains 'mfa'" \
+  --condition-version 2.0
+```
+
 ### Deny Assignments
 
 Just like role assignments, **deny assignments** are used to **control access to Azure resources**. However, **deny assignments** are used to **explicitly deny access** to a resource, even if a user has been granted access through a role assignment. **Deny assignments** take precedence over **role assignments**, meaning that if a user is granted access through a role assignment but is also explicitly denied access through a deny assignment, the deny assignment will take precedence.