One Identity Provider, Three Clouds, 71 Privileged Users
Meridian Financial has 2,200 employees and uses Microsoft Entra ID as its corporate identity provider. It runs Oracle Database@Azure in East US for its core ledger, an AWS account for risk analytics with 25 developers, and an OCI tenancy for the Database@Azure control plane and a small Exadata development environment. Regulators require MFA for all administrative access, quarterly access reviews, 15-minute deprovisioning for leavers, and a documented break-glass process. Today, DBAs have local OCI accounts, AWS IAM users with long-lived access keys, and shared database passwords in a spreadsheet. The security team wants SSO for the OCI console, AWS console, and database access; SCIM provisioning from Entra ID; and session recording for privileged database sessions. The company has 40 DBAs, 25 developers, and 6 cloud platform admins. No one wants to manage a new on-premises identity store.
1. Design SSO and provisioning from Entra ID to OCI and AWS. What must be true for the OCI tenancy that owns Database@Azure?
Read the worked answer
Entra ID is the single source of truth. Create Entra groups for oci-dba, oci-platform-admin, aws-risk-developer, and aws-platform-admin, and drive both clouds from those groups.
OCI: Federate the OCI identity domain to Entra ID using SAML 2.0 and enable SCIM provisioning. Map Entra groups to OCI groups and OCI policies. The OCI tenancy is unavoidable for Database@Azure because the Exadata infrastructure and database control plane are managed through OCI, so this federation is not optional. Do not keep local OCI users for daily work; reserve them for break-glass.
AWS: Use IAM Identity Center with Entra ID as the external IdP, SAML for console/CLI access, and SCIM for users and groups. Map groups to permission sets. Delete long-lived IAM users and access keys; require role assumption.
Controls: Entra Conditional Access enforces MFA and device compliance for administrative roles. Session lifetime for OCI and AWS admin roles should be short. SCIM deprovisioning must be tested end to end to prove the 15-minute leaver requirement, including removal from OCI groups and AWS permission sets, not just sign-in revocation.
2. How do you handle database and operating-system privileged sessions without shared passwords, given Database@Azure and AWS?
Read the worked answer
Database@Azure: The customer does not get operating-system access to the Exadata infrastructure; Oracle manages the OS. Database access is through named Oracle database accounts. Put those credentials in a privileged access management vault integrated with Entra ID SSO, rotate them on checkout, and record the session at the database or proxy layer. Where Oracle and Microsoft support Entra/Active Directory-based database authentication for the service, use it to avoid passwords entirely; otherwise vaulted named accounts plus database auditing are the fallback.
AWS: Remove SSH key pairs from EC2. Use AWS Systems Manager Session Manager with IAM Identity Center roles, session logging to S3 and CloudWatch, and no inbound SSH security-group rules. For database access from AWS, use the same PAM proxy pattern.
Break-glass: Two emergency accounts per cloud, excluded from SCIM, with FIDO2 hardware keys stored in a sealed process. Alert on any use, require a ticket within 30 minutes, and rotate credentials after use. Break-glass accounts must be tested quarterly; an untested emergency path is not a control.
3. What governance controls detect entitlement drift and satisfy quarterly access reviews across the three clouds?
Read the worked answer
Reviews: Use Entra ID Governance access reviews quarterly for the groups that map to OCI policies and AWS permission sets. Reviewers attest to the business need, not just to the group name. Include database roles and break-glass usage in the review packet.
Drift detection:
- Export OCI IAM policies and AWS IAM policies as code and compare them with the approved baseline in CI.
- Run monthly reconciliation from Entra group membership to OCI group membership and AWS Identity Center assignments; alert on any delta older than one provisioning cycle.
- Alert on new local OCI users, new AWS IAM users or access keys, root account use, and policy changes.
- Use AWS IAM Access Analyzer and OCI Audit/Cloud Guard findings as evidence.
Separation of duties: The platform admins who can change IAM policy must not be the same people who approve access reviews. DBAs who can read production data must not approve their own database role grants. Document this matrix and sample it during audit.