What is Role-Based Access Control (RBAC) in Database Security?
Learn how Role-Based Access Control (RBAC) grants privileges to roles instead of users, and why it strengthens database security.
Expected Interview Answer
Role-Based Access Control (RBAC) is a database security model where permissions are granted to named roles rather than to individual users, and users gain their privileges by being assigned to one or more of those roles.
Instead of running GRANT statements against every account whenever access needs change, an administrator defines roles such as "read_only_analyst" or "billing_admin" that bundle a specific set of table, view, and procedure privileges. Users are then assigned to a role, immediately inheriting exactly the access that role carries, and losing it the moment the role is revoked. This keeps privilege management centralized, auditable, and consistent, since editing one role instantly changes access for every user who holds it, and it naturally supports the principle of least privilege by keeping each role narrowly scoped to what a job function actually needs.
- Centralizes permission changes in one place per role
- Enforces least privilege by job function
- Simplifies onboarding and offboarding of users
- Makes access reviews and audits far easier
AI Mentor Explanation
A cricket board does not hand each individual official a custom list of powers; instead it defines fixed roles like umpire, match referee, and scorer, each carrying a pre-set bundle of authority such as who may overturn a decision or sign the final scoresheet. When someone is appointed umpire for a match, they instantly gain every power tied to that role, and lose it all once the appointment ends. Database RBAC works identically: privileges are attached to a role, not a person, and assigning or removing the role assigns or removes the whole bundle of access at once.
Step-by-Step Explanation
Step 1
Define roles
Create named roles that represent job functions, such as CREATE ROLE report_viewer.
Step 2
Grant privileges to the role
Attach the specific table, view, or procedure privileges the role needs, e.g. GRANT SELECT ON Orders TO report_viewer.
Step 3
Assign users to roles
Add user accounts to one or more roles rather than granting privileges directly to each account.
Step 4
Audit and revoke as needed
Review which users hold which roles periodically, and remove a role assignment to instantly revoke that bundle of access.
What Interviewer Expects
- Clear distinction between role-level and user-level privilege grants
- Understanding of least-privilege and job-function-based role design
- Ability to describe GRANT/REVOKE against roles, not individuals
- Awareness of how RBAC simplifies audits and offboarding
Common Mistakes
- Granting privileges directly to individual users instead of roles
- Designing overly broad roles that violate least privilege
- Forgetting that removing a role assignment revokes the whole bundle
- Confusing RBAC with row-level or attribute-based access control
Best Answer (HR Friendly)
“Role-Based Access Control means we define roles like "analyst" or "admin" with a fixed set of database permissions, and then assign employees to those roles instead of configuring access per person. It makes it much easier to keep access consistent, review who can see what, and instantly cut off access by just removing someone from a role.”
Code Example
-- Define a role for reporting analysts
CREATE ROLE report_viewer;
-- Grant only the privileges that role needs
GRANT SELECT ON Orders TO report_viewer;
GRANT SELECT ON Customers TO report_viewer;
-- Assign a user to the role
GRANT report_viewer TO 'analyst_jane';
-- Revoking access later is a single statement
REVOKE report_viewer FROM 'analyst_jane';Follow-up Questions
- How does RBAC differ from attribute-based access control (ABAC)?
- How would you design roles to enforce least privilege in a multi-team database?
- What is the difference between GRANT and REVOKE in RBAC?
- How does RBAC interact with row-level security policies?
MCQ Practice
1. In RBAC, where are privileges primarily granted?
RBAC bundles privileges into roles, and users inherit access by being assigned to those roles rather than receiving individual grants.
2. What happens when a user is removed from a role in RBAC?
Since access derives entirely from role membership, removing the role assignment immediately revokes that bundle of privileges.
3. Which principle does well-designed RBAC most directly support?
Narrowly scoped roles that match job functions ensure users only get the access their role actually requires.
Flash Cards
What is RBAC? — A security model where permissions are granted to roles, and users inherit access by being assigned to those roles.
Why use roles instead of per-user grants? — Centralizes management, enforces consistency, and makes audits and offboarding much simpler.
How do you revoke a user’s access under RBAC? — Remove the user from the role; they lose the entire bundle of privileges that role granted.
What principle does RBAC support? — Least privilege, by scoping each role to only the access a job function actually needs.