What Is Common Role? Definition & Examples

A common role is an Oracle role created in the root container and visible across current and future containers in a multitenant database. It is designed for access that must span the whole container database. Because of that reach, common roles require careful governance and should not be confused with narrowly scoped local roles.

How Common Roles Work in Oracle Multitenant Databases

In Oracle multitenant architecture, a common role is created in the root container and can exist across the container database, which makes it a shared access construct rather than a container-local one. That broad scope is what distinguishes it from a local role and makes it useful for permissions that must apply consistently across the whole environment.

Because the role is defined at the root level, it follows the multitenant boundary of the container database. In practice, that means it is suited to standardised administrative or application access that must be available in multiple containers without recreating the same role repeatedly.

Why Common Roles Matter for Access Design

Common roles are part of access design, not just database housekeeping. They help centralise privilege assignment when the same access pattern is required everywhere, but they also expand the blast radius of any mistaken permission because the role is not confined to a single container.

That makes role design an architectural choice. If the intended access is genuinely cross-container, a common role can reduce duplication and improve consistency. If the access need is only local, using a common role can create unnecessary reach and weaken separation between containers.

Common Role vs Local Role

The key distinction is scope. A common role is visible across current and future containers, while a local role is intended for a single container. The difference affects not only where the role can be used, but also how carefully it must be governed and reviewed.

Practitioners should treat common roles as shared security objects. Their privileges may be inherited widely, so a role that appears convenient at creation time can later become overbroad if its privileges are expanded without reassessing where that access is actually needed.

Governance and Operational Consequences

Common roles make it easier to standardise access, but they also increase the importance of naming discipline, ownership, and periodic review. A role that spans the container database should have an explicit business or operational purpose, because ambiguous shared roles are harder to audit and harder to retire safely.

In multitenant environments, access scope is part of the control objective. Common roles should be reserved for privileges that are intentionally universal, while container-specific access should stay local so that separation remains meaningful.

Risk and Threat Considerations

Common roles can widen exposure if their privileges are excessive, inherited too broadly, or misunderstood during administration. In a multitenant database, a mistake at the root level can affect multiple containers at once, so the governance issue is not just convenience, it is shared blast radius.

Failure mechanism: Privileges granted to a common role propagate across the container database, so overassignment, role reuse, or weak change control can create unintended access in many containers at once.

Impact: A compromised or misconfigured common role can enable broader-than-intended data access, administrative actions, or lateral movement across containers, making containment more difficult.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Common roles govern broad access scope across containers.
	AC-2 — Account Management	Common roles are shared access objects that require ownership and lifecycle control.
	IA-5 — Authenticator Management	Roles often depend on credentials and related access material used to obtain database privileges.
Recommendation — Limit common role privileges to the minimum shared access needed across containers. Track common role ownership, assignment, and revocation through account management controls. Control the lifecycle of credentials that can activate or reach role-based access.
CIS Controls v8	CIS-6 — Access Control Management	Common roles are an access-governance mechanism that must be scoped and reviewed.
Recommendation — Restrict and review common role assignments to prevent unnecessary cross-container access.
ISO/IEC 27001:2022	A.5.15 — Access control	Common roles implement broad access decisions that must be governed by access control policy.
Recommendation — Define when a common role is permitted and require approvals for cross-container privileges.

Practitioner Guidance

Governance implication: Use common roles only when the access requirement is truly cross-container and can be justified at the root level. That keeps the role aligned to an explicit security purpose instead of becoming a convenient shortcut for access sprawl.

What to watch for: Review whether the role still matches a shared need, whether its privileges have drifted, and whether a local role would better preserve least privilege for container-specific access.

Common Role