Access Control Within Autonomous Database on Dedicated Exadata Infrastructure

When configuring Autonomous Database on Dedicated Exadata Infrastructure, you need to ensure that your cloud users have access to use and create only the appropriate kinds of cloud resources to perform their job duties. Additionally, you need to ensure that only authorized personnel and applications have access to the autonomous databases created on dedicated infrastructure. Otherwise, you run the risk of "runaway" consumption of your dedicated infrastructure resources or inappropriate access to mission-critical data.

Before you begin creating and using the cloud resources that provide the dedicated infrastructure feature, you need to formulate an access control plan, and then institute by creating appropriate IAM (Identity and Access Management) and Networking resources. Accordingly, access control within an Autonomous Database is implemented at various levels:

Oracle cloud user access control
Client access control
Database user access control

Related Topics

Key Security Features

Oracle Cloud User Access Control

You control what access the Oracle Cloud users in your tenancy have to the cloud resources that make up your deployment of Autonomous Database on Dedicated Exadata Infrastructure.

You use the Identity and Access Management (IAM) service to ensure that your cloud users have access to create and use only the appropriate kinds of Autonomous Database resources to perform their job duties. To institute access controls for cloud users, you define policies that grant specific groups of users specific access rights to specific kinds of resources in specific compartments.

The IAM service provides several kinds of components to help you define and implement a secure cloud user access strategy:

Compartment: A collection of related resources. Compartments are a fundamental component of Oracle Cloud Infrastructure for organizing and isolating your cloud resources.
Group: A collection of users who all need the same type of access to a particular set of resources or compartment.
Dynamic Group: A special type of group that contains resources that match rules that you define. Thus, the membership can change dynamically as matching resources are created or deleted.
Policy: A group of statements that specify who can access which resources, and how. Access is granted at the group and compartment level, which means you write a policy statement that gives a specific group a specific type of access to a specific type of resource within a specific compartment.

Policy and Policy Statements

The primary tool you use to define access control for cloud users is the policy, an IAM (Identity and Access Management) resource containing policy statements that specify access in terms of "Who", "How", "What" and "Where".

The format of a policy statement is:

Allow 
  group <group-name> 
  to <control-verb> 
  <resource-type> 
  in compartment <compartment-name>

group <group-name> specifies the "Who" by providing the name of an existing IAM group, an IAM resource to which individual cloud users can be assigned.
to <control-verb> specifies the "How" using one of these predefined control verbs:
- inspect: the ability to list resources of the given type, without access to any confidential information or user-specified metadata that may be part of that resource.
- read: inspect plus the ability to get user-specified metadata and the actual resource itself.
- use: read plus the ability to work with existing resources, but not to create or delete them. Additionally, "work with" means different operations for different resource types.
- manage: all permissions for the resource type, including creation and deletion.
In the context of the dedicated infrastructure feature, a fleet administrator can manage autonomous container databases, while a database administrator can only use them to create autonomous databases.
<resource-type> specifies the "What" using a predefined resource-type. The resource-type values for the dedicated infrastructure resources are:
- exadata-infrastructures
- autonomous-container-databases
- autonomous-databases
- autonomous-backups
Because dedicated infrastructure resources use networking resources, some of the policy statements you create will refer to the virtual-network-family resource-type value. Also, you may create policy statements that refer to the tag-namespaces resource-type value if tagging is used in your tenancy.
in compartment <compartment-name> specifies the "Where" by providing the name of an existing IAM compartment, an IAM resource in which resources are created. Compartments are a fundamental component of Oracle Cloud Infrastructure for organizing and isolating cloud resources.

For the policy details for Autonomous Database, refer to IAM Policies for Autonomous Database on Dedicated Exadata Infrastructure.

For information about how the IAM service and its components work and how to use them, see Overview of Oracle Cloud Infrastructure Identity and Access Management. For quick answers to common questions about IAM, see the Identity and Access Management FAQ.

Best Practices When Planning and Instituting Access Controls

When planning and instituting your access controls for the dedicated infrastructure feature, you should consider these best practices.

Create a separate VCN that contains only private subnets. In almost every case, the Autonomous Databases created on dedicated infrastructure house data that is company-sensitive and is normally accessible only from within the company's private network. Even the data shared with partners, suppliers, consumers and customers is made available to them through regulated, secure channels.

Therefore, the network access you provide to such databases should be private to your company. You can ensure this by creating a VCN that uses private subnets and an IPSec VPN or FastConnect to connect to your company's private network. For information about setting up such a configuration, see Scenario B: Private Subnets with a VPN in Oracle Cloud Infrastructure Documentation.

For additional information about securing network connectivity to your databases, see Ways to Secure Your Network in Oracle Cloud Infrastructure Documentation.
Create at least two subnets. You should create at least two subnets: one for Autonomous Exadata VM Cluster and Autonomous Container Database resources and one for resources associated with clients and applications of Autonomous Database.
Create at least two compartments. You should create at least two compartments: one for Exadata Infrastructure, Autonomous Exadata VM Cluster and Autonomous Container Database resources and one for Autonomous Database resources.
Create at least two groups. You should create at least two groups: one for fleet administrators and one for database administrators.

Client Access Control

Client access control is implemented in Autonomous Database by controlling network access control and client connections.

Network Access Control

You define network access control to autonomous databases when you set up and configure you dedicated deployment of Oracle Autonomous Database. How you do so depends on whether your dedicated deployment is on Oracle Public Cloud or Exadata Cloud@Customer:

On Oracle Public Cloud, you define network access control using components of the Networking service. You create a Virtual Cloud Network (VCN) containing private Subnets in which your autonomous databases are network-accessible. Additionally, you create Security Rules to allow a particular type of traffic in or out the IP addresses in a subnet.

For detailed information about creating these resources, run Lab 1: Prepare Private Network for OCI Implementation in Oracle Autonomous Database Dedicated for Fleet Administrators.
On Exadata Cloud@Customer, you define network access controls by specifying a client network within your data center and recording it in a VM Cluster Network resource within the Exadata Infrastructure resource.

For added security, you can enable Access Control Lists (ACLs) in both Oracle Public Cloud and Exadata Cloud@Customer dedicated deployments. An ACL provides additional protection to your database by allowing only the client with specific IP addresses to connect to the database. You can add IP addresses individually, or in CIDR blocks. This allows you to formulate a fine grained access control policy by limiting your Autonomous Database’s network access to specific applications or clients.

You can optionally create an ACL during the database provisioning, or at any time thereafter. You can also edit an ACL at any time. Enabling an ACL with an empty list of IP addresses makes the database inaccessible. See Set Access Control List for a Dedicated Autonomous Database for details.

Note the following about using an ACL with Autonomous Database:

The Autonomous Database Service Console is not subject to ACL rules.
As of the current release, Oracle Application Express (APEX), RESTful services, and Database Actions are not subject to ACLs. Choosing to enable an ACL disables these features automatically.
Performance Hub is not subject to ACL rules.
While creating an Autonomous Database, if setting an ACL fails, then provisioning the database also fails.
Updating an ACL is allowed only if the database is in the Available state.
Restoring a database does not overwrite the existing ACLs.
Cloning a database, full and metadata, will have the same access control settings as the source database. You can make changes as necessary.
Backup is not subject to ACL rules.
During an ACL update, all the Autonomous Container Database (CDB) operations are allowed, but Autonomous Database operations are not allowed.

Client Connection Control

Oracle Autonomous Database implements client connection control with standard TLS 1.2 certificate-based authentication to authenticate a client connection.

By default, Autonomous Database uses self-signed certificates. However, you can install your CA-signed server-side certificate from the Oracle Cloud Infrastructure (OCI) console. To bring your own certificate, you must first create the certificate using the Oracle Cloud Infrastructure (OCI) Certificate Service as demonstrated in Creating a Certificate. These certificates must be signed and must be in the PEM format, that is, their file extension must be .pem, .cer, or .crt only. For more details, refer to Certificate Management in Dedicated Autonomous Database.

Database User Access Control

Oracle Autonomous Database configures the databases you create to use the standard user management feature of Oracle Database. It creates one administrative user account, ADMIN, that you use to create additional user accounts and to provide access controls for accounts.

Standard user management provides a robust set of features and controls, such as system and object privileges, roles, user profiles and password policies, that enable you to define and implement a secure database user access strategy in most cases. See Create and Manage Database Users for detailed instructions.

For basic information about standard user management, see User Accounts in Oracle Database Concepts. For detailed information and guidance, see Managing Security for Oracle Database Users in Oracle Database Security Guide.

If your database user access strategy demands more controls than are provided by standard user management, you can configure your autonomous database to use any of the following tools to meet more rigorous requirements.

Tool	Description
Database Vault	Oracle Database Vault comes preconfigured and ready to use in Autonomous Databases. You can use its powerful security controls to restrict access to application data by privileged database users, reducing the risk of insider and outside threats and addressing common compliance requirements. Refer to Data Protection in Security Features of Autonomous Database for more details.
Oracle Cloud Infrastructure Identity and Access Management (IAM)	You can configure Autonomous Database to use Oracle Cloud Infrastructure Identity and Access Management (IAM) authentication and authorization to allow IAM users to access an Autonomous Database with IAM credentials. Refer to Use Identity and Access Management (IAM) Authentication with Autonomous Database for using this option with your database.
Azure OAuth2 Access Tokens	You can centrally manage Oracle Autonomous Database users in a Microsoft Azure Active Directory (Azure AD) service with the help of Azure `oAuth2` access tokens. This type of integration enables the Azure AD user to access an Oracle Autonomous Database instance. Azure AD users and applications can log in with Azure AD Single Sign On (SSO) credentials to get an Azure AD `OAuth2` access token to send to the database. For more information about integrating Microsoft Azure Active Directory with your databases, see Authenticate and Authorize Microsoft Azure Active Directory Users for Autonomous Database.
Microsoft Active Directory (CMU-AD)	If you use Microsoft Active Directory as a user repository, you can configure your Autonomous Databases to authenticate and authorize Microsoft Active Directory users. This integration can enable you to consolidate your user repository while still implementing a rigorous database user access strategy, regardless of whether you use standard user management, Database Vault, Real Application Security or Virtual Private Database. For more information about integrating Microsoft Active Directory with your databases, see Microsoft Active Directory with Autonomous Database.
Kerberos	Kerberos is a trusted third-party authentication system that relies on shared secrets. It presumes that the third party is secure, and provides single sign-on capabilities, centralized password storage, database link authentication, and enhanced PC security. It does this through a Kerberos authentication server. Autonomous Database support for Kerberos provides the benefits of single sign-on and centralized authentication of Oracle users. For more information, see Authenticate Autonomous Database Users with Kerberos.
Kerberos with CMU-AD	Kerberos authentication can be configured on top of CMU-AD to provide CMU-AD Kerberos authentication for Microsoft Active Directory users. To provide CMU-AD Kerberos authentication for Microsoft Active Directory users, you can enable Kerberos authentication on top of CMU-AD by setting `type` to `CMU` while enabling external authentication as demonstrated in the example discussed in Enable Kerberos Authentication on Autonomous Database.
Real Application Security and Virtual Private Database	Oracle Real Application Security (RAS) provides a declarative model that enables security policies that encompass not only the business objects being protected but also the principals (users and roles) that have permissions to operate on those business objects. RAS is more secure, scalable, and cost effective than its predecessor, Oracle Virtual Private Database. With Oracle RAS, application users are authenticated in the application-tier as well as in the database. Irrespective of the data access path, the data security policies are enforced in the database kernel based on the end-user native session in the database. The privileges assigned to the user control the type of operations (select, insert, update and delete) that can be performed on rows and columns of the database objects. For more information about Oracle RAS, see Introducing Oracle Database Real Application Security in Oracle Database Real Application Security Administrator's and Developer's Guide. Oracle Autonomous Database also supports Oracle Virtual Private Database (VPD), the predecessor of Oracle RAS. If you are already familiar with and use Oracle VPD, you can configure and use it with you autonomous databases. For more information about Virtual Private Database, see Using Oracle Virtual Private Database to Control Data Access in Oracle Database Security Guide.

Privileged Access Management (PAM)

Oracle's security posture around user access and privilege management across its products and services is documented in Oracle Access Control.

Autonomous Database on Dedicated Exadata Infrastructure is designed to isolate and protect customer services and database data from unauthorized access. Autonomous Database separates duties between the customer and Oracle. The customer controls access to database schema(s). Oracle controls access to Oracle-managed infrastructure and software components.

Autonomous Database on Dedicated Exadata Infrastructure is designed to help secure data for customer-authorized use and to help protect data from unauthorized access, which includes preventing access to customer data by Oracle Cloud Ops staff members. Security measures designed to protect against unauthorized access to the Exadata Infrastructure, Autonomous VMs, and Oracle database data include the following:

Oracle Database data is protected by Oracle Transparent Data Encryption (TDE) keys.
The customer controls access to TDE encryption keys and may choose to store such keys in an external Oracle Key Vault key management system.
Oracle Database Vault is pre-configured to prevent privileged users from accessing customer data in Autonomous Databases.
Customers may choose to approve Operator access via Operator Access Control service enrollment.
All operator access is based on FIPS 140-2 level 3 hardware multi-factor authentication, implemented with a hardware YubiKey implemented with Oracle-approved devices.
All operator actions are logged at the command level and can be sent to the OCI logging service or a customer SIEM on a near real-time basis.
Oracle Operations Access Control ensures that the user accounts that Oracle Cloud operations and support staff use to monitor and analyze the performance cannot access data in Autonomous Databases. Oracle Cloud operations and support staff do not have access to the data in your Autonomous Databases. When you create an Autonomous Container Database, Autonomous Database on Dedicated Exadata Infrastructure enables and configures the Operations Control feature of Oracle Database Vault to block common users from accessing data in Autonomous Databases created in the container database.
You can confirm that Operations Control is active by entering this SQL statement in an Autonomous Database:
```
SELECT * FROM DBA_DV_STATUS;
```
The status of APPLICATION CONTROL indicates that Operations Control is active.

Note:
Operations Control was earlier known as Application Control.

PAM is also implemented with Database Vault for data protection, as discussed in Security Features of Autonomous Database.

Title and Copyright Information

Access Control Within Autonomous Database on Dedicated Exadata Infrastructure