Identity and access management for Oracle Database@Azure
This article builds on the guidance in Identity and access management. Use this information to review design considerations and recommendations for identity and access management that are specific to Oracle Database@Azure deployments. Identity requirements for Oracle Database@Azure vary depending on its implementation in Azure. This article provides information based on the most typical scenarios.
Oracle Database@Azure is an Oracle database service that runs on Oracle Cloud Infrastructure (OCI) and is colocated in Azure datacenters at Microsoft. Microsoft and OCI jointly provide this offering, which requires you to manage identities and role-based access control (RBAC) across both platforms. This guide outlines best practices for identity and access management to create consistent deployment patterns for Oracle Database@Azure.
Considerations
Accept and enable the Oracle Database@Azure private offer on Azure Marketplace for your subscription. You must have the Contributor role for the subscription to deploy the Oracle Database@Azure service. For more information, see Set up identity federation. If your operational model is aligned with Azure landing zone principles, the individual application development team that requires Oracle Database@Azure services manages the process. If your organization uses a centralized model, the platform team might need to handle parts of the process.
When you deploy the initial Oracle Exadata Database@Azure instance, specific default groups are automatically created within Microsoft Entra ID and the corresponding OCI tenant. Some of these groups are replicated to OCI, where policies are defined. Use these groups to manage the various actions that Oracle Database@Azure services require. For more information, see Groups and roles in Oracle Database@Azure.
You can assign custom Oracle Exadata Database@Azure group names, but they need to be configured manually. Policies are created for specific group names. If you change the group name, you also need to change the policy statement in OCI.
To enhance the granularity of access permissions, contact the OCI administrator to establish other groups and roles within the OCI tenant. OCI provides control over who can create and manage Oracle Database@Azure resources.
For architectures that have multiple clusters, RBAC group permissions are applied to all clusters in the subscription. To assign RBAC to individual clusters separately, create customized group names and policies in OCI and Azure for each cluster.
Federation to non-Microsoft identity providers or Microsoft Active Directory is supported. For more information about security recommendations beyond federation of identity and RBAC, see Security guidelines for Oracle Database@Azure.
Design recommendations
Implement federation between Azure and OCI, including single sign-on and replication of users and groups.
Configure federation between Microsoft Entra ID and OCI to enable users to sign in to OCI with their Microsoft Entra ID credentials. For more information, see Steps to onboard Oracle Database@Azure).
When you provision a new account and tenant, an Admin user role is created in OCI. Avoid using this Admin identity for day-to-day operations. Instead, use Microsoft Entra administrator groups to provide elevated access for the relevant individuals.
Use Azure RBAC to control users' access to Oracle Database@Azure resources. Follow the principle of least privilege when you assign users to Database@Azure roles.
To help ensure that Microsoft Entra ID-based users are secure, follow identity management and access control best practices. When you help secure your Microsoft Entra ID-based users, enable identity protection. Validate your security measures by using the security checklist for identity and access management.
Enable Microsoft Entra ID audit logging to monitor access-related events.