Identity and Security in Multicloud Deployments
Identity and Security in Multicloud Deployments
This domain tests authentication versus authorization across OCI IAM and Microsoft Entra ID, plus workload identity, network security, encryption, and audit. The exam expects you to keep a single identity source and apply least privilege in each cloud.
Core rules
- Federation: configure an OCI IAM identity domain to trust Microsoft Entra ID as a SAML 2.0 identity provider. Entra ID authenticates the user; OCI IAM authorizes with policies. Map Entra ID groups to OCI groups; do not create parallel local users for normal administration.
- Enforce MFA and conditional access at Entra ID. Keep a tightly controlled break-glass path and monitor it.
- Workloads should use short-lived cloud identity: OCI instance principals or resource principals, and Azure managed identities. Do not put long-lived keys in code or config.
- Protect the data path with private endpoints, NSGs/security lists, TLS, OCI Vault or Azure Key Vault, and audit logs. OCI Audit, Cloud Guard, and Security Zones complement Azure Monitor and Defender for Cloud.
- Shared responsibility does not move to the network provider: you still own IAM policies, data classification, and application security.
Worked example
An Entra ID group oci-db-admins is mapped to an OCI group of the same name. An OCI policy in compartment Prod grants that group manage autonomous-database-family. The same team gets Azure Reader on the app resource group. Reasoning: Entra ID proves who the user is; OCI IAM decides what they can do in OCI. An Azure role assignment never grants OCI permissions.
Traps
Assuming Entra ID roles flow into OCI, leaving local OCI users active after federation, granting manage all-resources at tenancy scope, forgetting group-mapping changes and deprovisioning, and treating the private interconnect as sufficient security without TLS or least privilege.