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".

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.

Network Access Control

allow group <group_name>
to { ZPR_TAG_NAMESPACE_USE, SECURITY_ATTRIBUTE_NAMESPACE_USE }
in tenancy

allow group <group_name>
to manage autonomous-database-family
in tenancy

allow group <group_name>
to read security-attribute-namespaces
in tenancy

For advanced network controls beyond Access Control Lists, Oracle Autonomous Database on Dedicated Exadata Infrastructure supports using Web Application Firewall (WAF). WAF protects applications from malicious and unwanted internet traffic. WAF can protect any internet facing endpoint, providing consistent rule enforcement across a customer's applications. WAF provides you with the ability to create and manage rules for internet threats including Cross-Site Scripting (XSS), SQL Injection, and other OWASP-defined vulnerabilities. Access rules can limit based on geography or the signature of the request. See Getting Started with Web Application Firewall Policies for steps on how to configure WAF.

Client Connection Control

Oracle Autonomous Database on Dedicated Exadata Infrastructure 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.