Security and Authentication in Oracle Autonomous Database

Oracle Autonomous Database stores all data in encrypted format in the database. Only authenticated users and applications can access the data when they connect to the database.

Note:

Oracle Autonomous Database supports the standard security features of the Oracle Database including privilege analysis, network encryption, centrally managed users, secure application roles, transparent sensitive data protection, and others. Additionally, Oracle Autonomous Database adds Label Security, Database Vault, Data Safe, and other advanced security features at no additional cost.

Configuration Management

The Oracle Autonomous Database provides standard, hardened security configurations that reduce the time and money managing configurations across your databases. Security patches and updates are done automatically, so you don't spend time, money, or attention to keeping security up to date. These capabilities protect your databases and data from costly and potentially disastrous security vulnerabilities and breaches.

Data Encryption

Oracle Autonomous Database uses always-on encryption that protects data at rest and in transit. Data at rest and in motion is encrypted by default. Encryption cannot be turned off.

Encryption of Data at Rest

Data at rest is encrypted using TDE (Transparent Data Encryption), a cryptographic solution that protects the processing, transmission, and storage of data. Using AES256 tablespace encryption, each database has its own encryption key, and any backups have their own different encryption keys.

By default, Oracle Autonomous Database creates and manages all the master encryption keys used to protect your data, storing them in a secure PKCS 12 keystore on the same systems where the database resides. If your company security policies require, Oracle Autonomous Database can instead use keys you create and manage in the Oracle Cloud Infrastructure Vault service. For more information, see About Master Encryption Key Management on Autonomous Database.

Additionally, customer-managed keys can be rotated when needed in order to meet your organization's security policies.

Note: When you clone a database, the new database gets its own new set of encryption keys.

Encryption of Data in Transit

Clients (applications and tools) connect to Oracle Autonomous Database using supported protocols including SQL*Net, JDBC, and ODBC.

TCPS (Secure TCP) database connection services use the industry-standard TLS 1.2 (Transport Layer Security) protocol for connections and symmetric-key data encryption.

  • With mTLS connections, Oracle Autonomous Database users download a connection wallet that contains all necessary files for a client to connect using TCPS. Distribute this wallet only to those users who need and are permitted to have database access. The client-side configuration uses information in the wallet to perform symmetric-key data encryption.

  • Autonomous Database by default supports Mutual TLS (mTLS) connections. You have the option to configure an Autonomous Database instance to allow both mTLS and TLS connections. Using TLS connections, some clients, such as JDBC Thin Driver clients, do not need to download a wallet if you use a TLS connection string and TLS is enabled for the Autonomous Database instance.

See Secure Connections to Autonomous Database for more information.

Data Access Control

Securing access to your Oracle Autonomous Database and your data uses several different kinds of access control:

Client Access Control

Network Access Control

You define network access control when you set up and configure your Oracle Autonomous Database. There are two options to consider.
  • Private Endpoints and Security Lists: This is the recommended option. Create your Oracle Autonomous Database in your virtual cloud network (VCN) using private endpoints. You control access to your database using security lists and network security groups allowing you to specify who can create connections to your database.

    For detailed information about creating these resources, see Configuring Network Access with Private Endpoints.

  • Public Endpoints and Access Control Lists: Create your Oracle Autonomous Database using public endpoints allowing access from any client with client credentials. You control access to your database using network access control lists (ACLs) allowing you to specify IP addresses, CIDR blocks, or VCNs that can connect to your database. Public IPs are easier to discover and attack, and Private Endpoints are recommended where possible.

    For detailed information about setting up an ACL, see Configure Access Control Lists for an Existing Autonomous Database Instance.

Client Connection Control

Clients connect through a TCPS (Secure TCP) database connection using standard TLS 1.2 to secure the connection. Oracle Autonomous Database uses self-signed certificates. You can rotate the self-signed certificates from the Oracle Cloud Infrastructure console to meet your organization's security compliance needs. See Rotate Wallets for Autonomous Database.

The access the client has to the database is restricted by the access rights of the database user the client uses to connect.

Database User Access Control

The Oracle Autonomous Database is configured with an administrative account, ADMIN, that is used to create and manage other database accounts. Oracle Autonomous Database provides a robust set of features and controls including system and object privileges and roles. User profiles allows you to customize password policies to define and implement a secure database user access strategy.

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 Oracle Autonomous Database to use Database Vault to meet more rigorous requirements.

Using Microsoft Active Directory to Manage Database Users

If you use Microsoft Active Directory as a user repository, you can configure your database to authenticate and authorize Microsoft Active Directory users. This integration enables you to consolidate your user repository while still implementing a rigorous database user access strategy, regardless of whether you use standard user management or Database Vault.

For more information about integrating Microsoft Active Directory with your databases, see Use Microsoft Active Directory with Autonomous Database.

Database Vault

Oracle Database Vault comes preconfigured and ready to use. You can use its powerful security controls to restrict access to application data by privileged database users, reducing the risk threats, and addressing common compliance requirements.

You configure controls to block privileged account access to application data and control sensitive operations inside the database. You configure trusted paths to add additional security controls to authorized data access, database objects, and database commands. Database Vault secures existing database environments transparently, eliminating costly and time consuming application changes.

Before using Database Vault, be sure to review Use Oracle Database Vault with Autonomous Database to gain an understanding of the impact of configuring and enabling Database Vault.

For detailed information on implementing Database Vault features, refer to Oracle Database Vault Administrator’s Guide.

Oracle Cloud User Access Control

You use Identity and Access Management (IAM) services to control the privileges of your Oracle Cloud users by specifying the actions those users can perform on your Oracle Autonomous Database.

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.

Of these, the policy is the primary tool you use to control access because it provides the "Who", "How", "What" and "Where" of a single access constraint. A policy statement has this format:

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.

  • 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.
  • <resource-type> specifies the "What" using a predefined resource-type. The resource-type values for infrastructure resources are:

    • autonomous-databases
    • autonomous-backups

    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.

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.

Auditing

Oracle Autonomous Database provides robust auditing capabilities that enable you to track who did what on the service and on specific databases. Comprehensive log data allows you to audit and monitor actions on your resources, which helps you to meet your audit requirements while reducing security and operational risk.

Auditing Service Level Activities

All actions Oracle Cloud users perform on the resources that make up your deployment of Oracle Autonomous Database are logged by the Audit service, regardless of the interface used: the Oracle Cloud Infrastructure Console, REST API, Command Line Interface (CLI), Software Development Kits (SDK) and so on.

You can use the Audit service to perform diagnostics, track resource usage, monitor compliance, and collect security-related events. For more information about the Audit service, see Overview of Audit in Oracle Cloud Infrastructure Documentation.

Additionally, when users perform operations on your Oracle Autonomous Database, the database publishes events to the Oracle Cloud Events service. The Oracle Cloud Events service allows you to create rules to capture these events and perform actions.

For more information about how the Events service works and how to set up the rules and actions it uses, see Overview of Events. For listings of the Oracle Autonomous Database operations that generate events, see Autonomous Database Event Types.

Auditing Database Activities

Oracle Autonomous Database configures the autonomous databases you create to use the unified auditing feature of Oracle Database.

This feature captures audit records from the following sources and gathers them in a single audit trail in a uniform format:

  • Audit records (including SYS audit records) from unified audit policies and AUDIT settings
  • Fine-grained audit records from the DBMS_FGA PL/SQL package
  • Oracle Database Real Application Security audit records
  • Oracle Recovery Manager audit records
  • Oracle Database Vault audit records
  • Oracle Label Security audit records
  • Oracle Data Mining records
  • Oracle Data Pump
  • Oracle SQL*Loader Direct Load

Audit information is retained for up to 14 days, after which it is automatically purged. To retain audit information for longer, and to easily analyze and report on database activity, use Oracle Data Safe (included with your Oracle Autonomous Database subscription).

See About Auditing Autonomous Database for more information.

Assessing the Security of Your Database and its Data

Oracle Autonomous Database integrates with Oracle Data Safe to help you assess and secure your databases.

Oracle Data Safe helps you understand the sensitivity of your data, evaluate risks to data, mask sensitive data, implement and monitor security controls, assess user security, monitor user activity, and address data security compliance requirements in your databases.

You use Oracle Data Safe to identify and protect sensitive and regulated data your Oracle Autonomous Database by registering your database with Data Safe. Then, you use the Data Safe console directly from the Details page of your database.

For more information about using Data Safe, see Safeguard Your Data with Data Safe on Autonomous Database.

Regulatory Compliance Certification

Oracle Autonomous Database meets a broad set of international and industry-specific compliance standards, including:

  • HIPAA - Health Insurance Portability and Accountability Act
  • ISO/IEC 27001:2013 - International Organization for Standardization 27001
  • ISO/IEC 27017:2015 - Code of Practice for Information Security Controls Based on ISO/IEC 27002 for Cloud Services
  • ISO/IEC 27018:2014 - Code of Practice for Protection of Personally Identifiable Information (PII) In Public Clouds Acting as PII Processors
  • SOC 1 - System and Organization Controls 1
  • SOC 2 - System and Organization Controls 2
  • ISO 15408 - Common Criteria at EAL2

For more information and a complete list of certifications, see Oracle Cloud Compliance.