Identity, Security, and Governance Across Cloud Providers
Identity federation
Use one enterprise IdP such as Microsoft Entra ID or Okta as the source of truth. Federate it to OCI IAM identity domains and to AWS IAM Identity Center or Google Cloud Identity. Use SCIM for lifecycle, MFA at the IdP, and break-glass local accounts stored and monitored separately. Authentication proves identity; authorization decides access.
Authorization and security
- OCI policies use compartments, groups, dynamic groups, and resource principals; avoid wildcards and tenancy-wide admin.
- Azure RBAC, AWS IAM policies and roles, and Google Cloud IAM govern partner-cloud resources; they do not grant Oracle Database privileges. Database grants remain in Oracle.
- Separate duties: network admin, database admin, security admin, billing admin.
- Encrypt at rest with customer-managed keys in OCI Vault, Azure Key Vault, AWS KMS, or Google Cloud KMS; encrypt in transit with TLS; prefer private connectivity.
- Centralize audit logs, enable Cloud Guard, Security Hub, or Defender for Cloud, and retain logs per policy.
Worked example
A financial firm federates Entra ID to OCI IAM. An Entra group oci-dba-prod maps to an OCI group; a policy allows that group to manage autonomous databases in compartment ProdDB, but not to change VCNs. Azure RBAC limits the same team to read-only on the VNet. Keys live in OCI Vault with a separate key-admin group. Audit logs flow to the SIEM. No shared local users exist.
Traps
Using local IAM users; wildcard policies; assuming Azure RBAC controls Oracle DB roles; putting keys and data in the same admin scope; missing audit coverage in one cloud; forgetting that identity outages can block operations.