Security Features in Autonomous AI Database on Dedicated Exadata Infrastructure

This article describes the key security features in Autonomous AI Database on Dedicated Exadata Infrastructure.

Note that throughout this section the term “you” is broadly used to mean any administrator in your organization who has the responsibility for performing certain tasks. In some cases, that’s the fleet administrator, in others it’s the database administrator.

Along with the standard security features of the Oracle AI Database such as privilege analysis, network encryption, centrally managed users, secure application roles, transparent sensitive data protection, and others, a Dedicated Autonomous AI Database adds Database Vault, Data Safe, and other advanced security features at no additional cost.

You can see the building blocks for the key security features of a Dedicated Autonomous AI Database depicted below.

Description of the illustration adbd-security-features.svg

Configuration Management

Built on Oracle Cloud Infrastructure, Autonomous AI Database provides standard, hardened security configurations so you and your team don’t need to spend huge amounts of time and money managing configurations across your Autonomous AI Database fleet. All service accounts such as SYS and System are rotated every 90 days. Refer to Configuration Management in Autonomous AI Database to explore further.

Security patches and updates are done automatically, so you don’t need to worry about keeping security up to date. These capabilities protect your highly sensitive databases and data from costly and potentially disastrous security vulnerabilities and breaches. Refer to Service Maintenance of Dedicated Autonomous AI Database for more details.

Data Encryption

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

Autonomous AI Database uses always-on encryption that protects data at rest and in transit. All data stored in and network communication with Oracle Cloud is encrypted by default. Encryption cannot be turned off.

Refer to Data Encryption in Dedicated Autonomous AI Database for more details about data encryption and master encryption keys.

Auditing

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

Refer to Auditing Capabilities in Dedicated Autonomous AI Database for more details.

Access Control

When configuring the Dedicated Exadata Infrastructure feature, 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 AI Databases created on the dedicated infrastructure. Otherwise, you run the risk of “runaway” consumption of your dedicated infrastructure resources or inappropriate access to mission-critical data.

Securing access to your data and the databases that contain it comprises several different kinds of access control. Refer to Access Control Within Dedicated Autonomous AI Database for more details.

Certificate Management

When a client attempts to connect to an Autonomous AI Database through a TCPS (Secure TCP) database connection service, Oracle Autonomous AI Database on Dedicated Exadata Infrastructure uses standard TLS 1.2 and TLS 1.3 certificate-based authentication to authenticate the connection. However, TLS 1.3 is only supported on Oracle AI Database 23ai or later. Regardless of whether the client attempts to connect through a TCPS or TCP database connection service, the client’s access to the database is restricted by the access rights of the database user the client uses to connect.

Oracle Managed Self-signed Certificate

By default, Autonomous AI Database uses self-signed certificates. A self-signed certificate is a security certificate that is system generated.

Certificate generation

Oracle managed self-signed certificates are automatically generated while provisioning an Autonomous Exadata VM Cluster (AVMC) and apply to all the databases created in that AVMC.

Certificate management

Self-signed certificates are generated and associated with an AVMC automatically. However, you must download Autonomous AI Database client wallet before connecting to your databases. With self-signed certificates, connecting to databases without a wallet is not an option. Refer to Download Client Credentials for instructions on downloading a wallet for your database.

Depending on the requirement, either of the following certificate types are associated with your AVMC:

Certificate rotation

To meet your organization’s security compliance needs, you can rotate the Oracle-managed self-signed certificates using the Oracle Cloud Infrastructure (OCI) console or API. Refer to Manage Security Certificates for an Autonomous Exadata VM Cluster Resource for step-by-step instructions. This is called certificate rotation.

For newly provisioned Autonomous Exadata VM Cluster (AVMC) resources, Oracle-managed self-signed certificates have a 13-month validity from their creation. Rotating an SSL certificate using the console or API rotates both the server-side and client-side certificates and resets their validity to 13 months. When an Oracle-managed server-side or client-side certificate is not rotated before its expiry, Oracle rotates them automatically and generates new wallets.

In the case of database SSL certificates, certificate rotation does not invalidate the existing certificate immediately.

Within two weeks from the certificate rotation, you can connect to your databases using the Autonomous AI Database client wallet you downloaded before or after the certificate rotation.

After two weeks from the certificate rotation:

Let’s discuss this with an example:

Consider an SSL certificate, say C1, is due to expire and you have rotated this certificate on the 1st of February. For two weeks from Feb 1st, that until Feb 14th, the old certificate (C1) is still available to use. You can either continue using the old certificate (C1) or download a new database wallet for the rotated certificate (C2) for your database connections. After two weeks from Feb 1st, that is, from Feb 14th onwards, the old certificate (C1) gets invalidated and can not be used for database connections. You can continue using the database wallet that you downloaded post certificate rotation (C2) during these two weeks. You can also download a new database wallet and start using it for your database connections after two weeks from rotation.

You can also rotate a database SSL certificate within two weeks from its most recent rotation. In this scenario, the old certificate (about to get invalidated due to the first rotation) gets disabled immediately. The next certificate (resulting from the first rotation) remains active, and a third certificate (resulting from the second rotation) will be waiting for activation for two weeks from the second rotation. Any database wallet downloaded before the first rotation gets invalidated soon after the second rotation. You can continue connecting to the database with any database wallet downloaded after the first rotation until two weeks from the second rotation. After the completion of two weeks from the second rotation, you can only connect to your databases using a client wallet downloaded after the second rotation, that is, a wallet that was downloaded within two weeks from the second rotation or later.

In the above example, if you rotate the same certificate (C1) again within two weeks from Feb 1st, the certificate undergoes double rotation. In this case, the old certificate (certificate before the first rotation, that is, C1) gets invalidated immediately. The certificate resulting from the first rotation (C2) remains active and a third certificate resulting from the second rotation, say C3, will be waiting for activation for two weeks from the second rotation. After two weeks from the second rotation, the certificate resulting from the first rotation (C2) also gets invalidated and any database wallets downloaded before the second rotation can not be used for database connections. You can continue using the database wallet that you downloaded post certificate rotation (C3) during these two weeks. You can also download a new database wallet and start using it for your database connections after two weeks from the second rotation.

In the case of ORDS SSL certificates, all the existing application connections would be lost with the certificate rotation and you are advised to restart ORDS. The two week buffer period discussed above does not apply when you rotate an ORDS SSL certificate.

Bring Your Own Certificate (BYOC)

Bring Your Own Certificate (BYOC) lets you use your CA-signed server-side certificate with your Autonomous AI Databases.

Certificate generation

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.

Certificate installation

After creating the CA-signed server-side certificate, you must install it with your AVMC so that any databases created in it can use this certificate for secure connections. Associating your BYOC certificate with an AVMC is facilitated from the Manage Certificates dialog on the OCI console. On this dialog, choose the Bring your own certificate, and select the certificate that you would have created earlier from the select list. Optionally, you can also specify a CA certificate with certificate authority and CA bundle. However, If you are selecting a CA bundle for an ORDS SSL certificate, the bundle must only contain certificates which are part of the certificate chain. Refer to Manage Security Certificates for an Autonomous Exadata VM Cluster Resource for step-by-step instructions.

Certificate management

You can connect to Autonomous AI Databases associated with a CA-signed server-side with or without an Autonomous AI Database client wallet.

Certificate rotation

To meet your organization’s security compliance needs, you can rotate the CA-signed server-side certificates using the Oracle Cloud Infrastructure (OCI) console or API. Refer to Manage Security Certificates for an Autonomous Exadata VM Cluster Resource for step-by-step instructions.

You must rotate them before their expiry date, failing which the databases on this AVMC will not be reachable on TLS ports until you provide a valid certificate. However, you can continue to access the databases on a non-TLS port such as 1521.

Certificate Events

The following events are published for security certificate management:

Event Generated when
sslcertificateexpiry.reminder An Autonomous Exadata VM Cluster determines that a wallet is due to expire in less than six (6) weeks. This event is reported at most once per week. This event is triggered when there is a connection that uses the wallet that is due to expire.
sslcertificate.expired The SSL Certificate expires. All the Autonomous AI Database wallets related to this Autonomous Exadata VM Cluster will expire.
sslcertificaterotation.reminder An SSL certificate is older than 365 days and recommends the customer to rotate the certificate. After an SSL certificate crosses 365 days, this reminder is once per week until it is rotated.
sslcertificate.rotated The SSL certificate is rotated either manually (using the Oracle Cloud Infrastructure console or API) or automatically on its expiry.

Tip: Subscribe to these events using the OCI Notifications Service to receive them whenever they are published. Refer to Creating a Subscription for further details.

Refer to Events for Autonomous AI Database on Dedicated Exadata Infrastructure for a comprehensive list of Autonomous AI Database events.

Data Protection

Data protection is a critical aspect of data security in any database. Privileged database accounts are one of the most commonly used pathways for gaining access to sensitive applications data in the database. While privileged users such as ADMIN or Oracle operators need broad and unrestricted access to facilitate database maintenance, the same access also creates a point of attack for gaining access to large amounts of data.

Autonomous AI Database lets you implement Privileged Access Management (PAM)using:

Sensitive Data Discovery and Data Masking

Identifying sensitive data (such as credit card number, SSN) and masking or redacting them as needed enhances data protection and overall data security.

Regulatory Compliance Certification

Autonomous AI Database on Dedicated Exadata Infrastructure meets a broad set of international and industry-specific compliance standards, including:

For more information and a complete list of certifications, see Oracle Cloud Compliance. See Compliance documents to download copies of the certification documents.

Related Content