ABAC (Attribute-Based Access Control) uses attributes of the subject (user), object (data/resource), and environment (time, location, etc.) to make access decisions.
Subject attributes: "Senior Trader," "Years of Experience"
Object attributes: "Transaction Value"
Environment attributes: "Market Hours" ABAC can create a policy like "Allow access if Subject.Role = 'Senior Trader' AND Subject.YearsOfExperience >= 10 AND Object.TransactionValue > $10M AND Environment.Time is within MarketHours."
*****
A) RBAC - Role-Based Access Control: While RBAC is simpler to implement, it lacks the granularity and dynamic nature required here. Roles are predefined and typically static, which makes it difficult to handle conditions like "market hours" or "$10M trades."
C) PBAC - Policy-Based Access Control: PBAC focuses on policy definitions but often does not inherently support the attribute-based evaluation that ABAC provides. ABAC includes both attributes and policies, making it more comprehensive for this use case.
Pure PBAC without any underlying model like ABAC is a very abstract concept and rarely seen in practical implementations. ABAC provides the necessary granularity and flexibility to make PBAC effective.
D) A hybrid RBAC-PBAC model: While a hybrid approach can provide more flexibility than pure RBAC/PBAC, it still might not match ABAC's capability to handle highly dynamic and attribute-driven conditions directly.