#Azure #Security #Identity #Access #Entra >[!info] Azure Access Control Models >Understanding Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) in Azure/Entra ID. These models are fundamental to implementing [[Key Risks of Fully Syncing Active Directory with Azure AD|secure Azure AD synchronization]]. >[!related] >Related Azure security concepts: >- [[App Registration]] - Application identity and access >- [[Role as Entra Reader]] - Example of RBAC implementation >- [[Azure RMS]] - Rights Management using RBAC/ABAC >- [[Microsoft Graph API Permissions]] - API-level access control ### Role-Based Access Control (RBAC) **The Concept:** Think of RBAC as the trusty go-to for managing who gets to do what in your tech kingdom. With RBAC, you create roles like "keys" that unlock certain capabilities. You then hand these keys to your users, and voilà—access granted! It's all about linking roles with permissions and users. **Example Breakdown:** - **Roles:** The hats people wear, like `Admin`, `Editor`, `Viewer`. - **Users:** Your team members who get assigned hats—sometimes more than one! - **Permissions:** The actions tied to those hats, like knocking on doors labeled `read`, `write`, or `delete`. **Advantages:** - **Simplicity:** Easy peasy. Just connect people to roles, and roles to what they can do. - **Scalability:** Growing your team? No sweat—just toss new folks into the right roles. **Disadvantages:** - **Rigidity:** Not super flexible. If someone needs special access, you might have to make a new role, and you risk getting buried under a mountain of roles. **Example:** Meet Jane. She's a Content Editor. - Jane (Your User) = Editor (Her Role) - Editor = She can create and tweak content but can't toss anything in the bin. Jane can jump in and get cracking on her tasks without running to IT for new permissions every day. ### Attribute-Based Access Control (ABAC) **The Concept:** ABAC is like the Batman utility belt of access control—packed with tools to cover every scenario. Instead of just roles, you use attributes for decision-making. These could be anything about the user, the resource, the environment, or what action they're trying to take. **Example Breakdown:** - **Attributes:** Details about the user (e.g., department), resource (e.g., data sensitivity), action (e.g., read), and environment (e.g., time of day). - **Policies:** Your rules here use attributes to decide who gets a golden ticket. **Advantages:** - **Flexibility:** Dial in those access controls with pinpoint precision. - **Context-Aware:** Factor in things like time and place—super handy for tightening security. **Disadvantages:** - **Complexity:** A bit trickier to set up and keep running smoothly compared to RBAC. - **Performance:** All that number-crunching could slow things down. **Example:** Meet John. He's the Manager of Finance. - Attributes: `{role: Manager, department: Finance}` - Policy: "Let this user view financial reports if they're a Finance Manager and it's during the day shift (9 AM to 5 PM)." John only sees those sensitive reports when all the puzzle pieces match up. It's like having a tiny bouncer checking IDs at the data door. ### Summing It Up - **RBAC:** It's like issuing preset keys to your team. Perfect for straightforward setups. - **ABAC:** Kind of like configuring a security system with sensors and rules—ideal for in-depth control where every little detail matters.