Identity Federation and Least Privilege in a Multicloud Environment
A financial services company, FinCorp, uses a multicloud strategy with AWS and Azure. They have 5,000 employees and 2,000 external partners who need access to specific applications. FinCorp's IAM team implemented SAML federation between their on-premises Active Directory and both cloud providers, with just-in-time (JIT) provisioning. However, an audit revealed that 30% of employee accounts have excessive permissions due to role explosion: there are 1,200 custom roles in AWS and 800 in Azure, many with overlapping permissions. Partners are granted access via a separate portal that uses OAuth 2.0, but their tokens have a 24-hour lifetime and are not scoped to specific resources. A recent penetration test found that a partner's compromised token allowed access to sensitive financial reports. The CISO wants to reduce the attack surface and achieve least privilege without disrupting business operations. The IAM team proposes implementing attribute-based access control (ABAC) and shortening token lifetimes to 1 hour. The application teams are concerned about the impact on user experience and the effort to refactor applications to support ABAC.
1. Identify the IAM weaknesses in FinCorp's current setup and explain how they contribute to risk.
Read the worked answer
The IAM weaknesses are: (1) Role explosion: 1,200 AWS roles and 800 Azure roles with overlapping permissions lead to excessive privileges. This violates least privilege and increases the blast radius if an account is compromised. (2) Partner token scope and lifetime: OAuth 2.0 tokens have a 24-hour lifetime and are not scoped to specific resources, meaning a stolen token grants broad access for a long period. This directly contributed to the penetration test finding. (3) Lack of centralized visibility: With separate role management in each cloud, it's difficult to enforce consistent policies and audit access. (4) JIT provisioning may be insufficient: If JIT provisioning is not tightly integrated with approval workflows and time-bound, it may still allow standing access. These weaknesses increase the risk of unauthorized access to sensitive financial data, potential data breaches, and compliance violations (e.g., PCI DSS, GDPR). The partner token issue is particularly critical because external entities are involved, and the 24-hour window gives attackers ample time to exploit a compromised token.
2. Evaluate the proposed ABAC and token lifetime changes. What are the trade-offs, and how would you address the application teams' concerns?
Read the worked answer
ABAC can reduce role explosion by using attributes (e.g., department, location, resource tags) to dynamically grant permissions, achieving least privilege with fewer policies. However, it requires application refactoring to support attribute-based decisions and may introduce complexity in policy management. Shortening token lifetimes to 1 hour reduces the window of opportunity for token misuse but may increase authentication frequency, impacting user experience, especially for partners who may have automated processes. To address concerns: (1) Phased ABAC rollout: Start with a pilot on low-risk applications, measure impact, and refine policies. Use a central policy engine (e.g., AWS IAM Roles Anywhere, Azure AD Conditional Access) to minimize application changes. (2) Token improvements: Implement refresh tokens with rotation and scope tokens to specific resources using OAuth 2.0 scopes. For partners, use short-lived tokens (1 hour) with refresh tokens that require re-authentication for sensitive actions. Provide SDKs and documentation to ease integration. (3) User experience: Use seamless SSO and silent token refresh where possible. For partners, offer a self-service portal to manage tokens. (4) Monitoring: Implement anomaly detection for token usage. The trade-off is initial implementation effort versus long-term risk reduction; the effort is justified given the audit findings and the sensitivity of financial data.