Break Glass Access for SaaS on Autonomous Database

Autonomous Database supports break glass access for SaaS providers. Break glass access allows a SaaS operations team, when explicitly authorized by a SaaS customer, to access a customer's database to perform critical or emergency operations.

About Break Glass Access on Autonomous Database

Break glass access on Autonomous Database supports SaaS providers, where the SaaS organization defines procedures to permit a SaaS operations team member to access a customer's database when they are explicitly authorized by the customer.

Break Glass Sample Use Case with Example.com

Consider a SaaS provider named example.com that is using Autonomous Database for their product. In usual operations the SaaS provider, example.com, creates an Autonomous Database instance for each SaaS customer. In this model a SaaS customer, for example a customer named Scott, is an end-user for the example.com product (and a SaaS customer whose data is stored in an Autonomous Database instance). The provider example.com creates and stores all of Scott's data in an Autonomous Database instance, and the customer, Scott, has no direct access to the database.

This SaaS model is summarized as follows:

  • The Oracle customer creating Autonomous Database instances is the SaaS organization, ( example.com).

  • The SaaS provider is example.com.

  • The SaaS customer is Scott.

If and when something goes wrong with regards to application performance, or there is some other critical issue that requires troubleshooting by the SaaS operations team, the customer Scott, can grant access so that the operations team can access Scott's database for troubleshooting. The SaaS operations team is only authorized to establish direct access to Scott's Autonomous Database instance through a SaaS defined approval process (in other words, after example.com receives permission from their customer, Scott).

Break Glass and the Autonomous Database SAAS_ADMIN User

When a SaaS invokes the break glass API on a customer's Autonomous Database instance, this enables the SAAS_ADMIN user. The SaaS operations team can then access the instance using the SAAS_ADMIN user with a specified set of roles, for a limited time.

By default the SAAS_ADMIN user is locked. Using an approval process defined by the SaaS organization, the SAAS_ADMIN user can be enabled to allow access to an Autonomous Database instance. The break glass name comes from manual fire alarms that require their users to break a small glass window pane before activating the alarm (the glass must be broken to prevent the alarm from being triggered by mistake). Similarly, the SAAS_ADMIN user doesn’t normally access the database and access requires a predefined approval process.

Depending on the type of access granted, when enabled, the SAAS_ADMIN user can access the database to investigate issues or to make changes associated with an emergency or other unusual event. When break glass access expires or when access is explicitly disabled, the SAAS_ADMIN account password/secrets are immediately rotated and SAAS_ADMIN user access is revoked. All the actions that the SAAS_ADMIN user performs are audited.

The SAAS_ADMIN user is enabled with one of three access types:

  • read-only: provides read only access to the instance. This is the default access type and includes default roles: CREATE SESSION, SELECT ANY TABLE, SELECT ANY DICTIONARY, SELECT_CATALOG_ROLE.
  • read/write: provides read/write access to the instance. The default roles for this type are: CREATE SESSION, SELECT ANY TABLE, SELECT ANY DICTIONARY, SELECT_CATALOG_ROLE, INSERT ANY TABLE, and UPDATE ANY TABLE.
  • admin: provides admin access to the instance. The default roles for this type are: CREATE SESSION and PDB_DBA.

Break Glass API

The SAAS_ADMIN user is enabled and disabled only through the Command Line Interface (CLI) or using the Autonomous Database REST APIs.

For information about using the REST APIs and signing requests, see REST APIs and Security Credentials.

For information about SDKs, see Software Development Kits and Command Line Interface.

Use these APIs for Break Glass operations:

Enable Break Glass Access

After authorization to access a database with SAAS_ADMIN is approved through procedures defined by your organization, use the Autonomous Database CLI or API to enable the SAAS_ADMIN user.

You must have the manage autonomous database privilege to enable the SAAS_ADMIN user.

Before you enable the SAAS_ADMIN user to access a database you must obtain values for the required parameters.

Parameter Description
isEnabled

Specifies a Boolean value. Use TRUE to enable.

password

Specifies the password for the SAAS_ADMIN user. If you specify secretId you cannot specify password.

The password you provide as a parameter must conform to the Autonomous Database password requirements. See About User Passwords on Autonomous Database for more information.

secretId

Specifies the value of a secret's Oracle Cloud Infrastructure Vault secret OCID. If you specify password you cannot specify secretId. See Overview of Vault for more information.

The password you provide as a secret in the Oracle Cloud Infrastructure Vault must conform to the Autonomous Database password requirements. See About User Passwords on Autonomous Database for more information.

secretVersionNumber

Specifies the version number of the secret specified with the secretId. This parameter is optional. The default is to use the latest secret version. This parameter only applies when secretId is also specified.

accessType

One of: read-only, read/write, or admin. The default is read-only.

duration

Specifies the duration in hours, in the range of 1 hour to 24 hours. The default is 1 hour.

To enable the SAAS_ADMIN user on an Autonomous Database instance you must define the required access using OCI Identity and Access Management policy statements written by an administrator.

The following policy is required:

Allow group Group_Name to manage autonomous-databases in compartment Compartment_Name

See IAM Policies for Autonomous Database and Getting Started with Policies for more information.

Topics

Enable Break Glass Access with a Password

Use the Autonomous Database CLI or API to enable SAAS_ADMIN with a password.

  1. Use the API or the CLI and specify a value for the password to enable SAAS_ADMIN with a password.

    For example:

    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/configureSaasAdminUser
    
    {  "isEnabled": true,
       "password": password,
       "accessType": "READ_ONLY",
       "duration": 17
    } 

    See configureSaasAdminUser for more information.

  2. Verify that SAAS_ADMIN user is enabled.
    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/getSaasAdminUserStatus
    
    {    "isEnabled": true,
         "accessType": "READ_ONLY",
         "timeSaasAdminUserEnabled": "2023-11-23T01:59:07.032Z"
    }
    

    This response shows that the SAAS_ADMIN user is enabled and that access type is READ_ONLY. The timestamp shows the time when SAAS_ADMIN was enabled (time is in UTC).

    See getSaasAdminUserStatus for more information.

Enable Break Glass Access with a Vault Secret

Use the Autonomous Database CLI or API to enable SAAS_ADMIN with a secretId, when the secret is stored in Oracle Cloud Infrastructure Vault.

When you specify a secretId, in order for Autonomous Database to reach the secret in the Oracle Cloud Infrastructure Vault, the following conditions must apply:

  • The secret must be in current or previous state.

  • You must have the proper user group policy that allows READ access to the specific secret in a given compartment. For example:

    Allow userGroup1 to read secret-bundles in compartment training

To enable SAAS_ADMIN with a secretId with the secret stored in Oracle Cloud Infrastructure Vault:

  1. Use the API or the CLI and specify an OCID value for the secretId.

    For example:

    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/configureSaasAdminUser
    
    {  "isEnabled": true,
       "secretId": "ocid1.key.co1.ap-mumbai-1.example..aaaaaaaauq5ok5nq3bf2vwetkpqsoa",
       "accessType": "READ_ONLY",
       "duration": 20
    }

    Specifying a secret version is optional. If you specify a secret version in the API call with secretVersionNumber, the specified secret version is used. If you do not specify a secret version the call uses the latest secret version.

    See configureSaasAdminUser for more information.

  2. Verify that SAAS_ADMIN user is enabled.

    For example:

    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/getSaasAdminUserStatus
    
    {    "isEnabled": true,
         "accessType": "READ_ONLY",
         "timeSaasAdminUserEnabled": "2023-11-23T01:59:07.032Z"
    }
    

    This response shows that the SAAS_ADMIN user is enabled and the access type is READ_ONLY. The timestamp shows the time when the user was enabled (time is in UTC).

    See getSaasAdminUserStatus for more information.

Disable Break Glass Access

Use the Autonomous Database CLI or API to disable SAAS_ADMIN user access.

By default access expires after one hour if the duration parameter is not set when SAAS_ADMIN is enabled. If the duration parameter is set when SAAS_ADMIN is enabled, then access expires after the specified duration number of hours. As an alternative to letting the access expire based on the either the default expiration time or the duration you specify, you can use configureSaasAdminUser to explicitly disable SAAS_ADMIN user access.

To disable the SAAS_ADMIN user on an Autonomous Database instance you must define the required access using OCI Identity and Access Management policy statements written by an administrator.

The following policy is required:

Allow group Group_Name to manage autonomous-databases in compartment Compartment_Name

See IAM Policies for Autonomous Database and Getting Started with Policies for more information.

  1. Disable SAAS_ADMIN user access.

    For example:

    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/configureSaasAdminUser
    {
      "isEnabled": false
    }

    See configureSaasAdminUser API for more information.

  2. Verify that SAAS_ADMIN user is disabled.

    For example:

    POST https://dbaas-api.svc.ad3.us-phoenix-1/20160918/autonomousDatabases/ocid1.autonomousdatabase.oc1.phx.uniqueId/actions/getSaasAdminUserStatus
    
    {    "isEnabled": false
    }
    

    This response indicates that the SAAS_ADMIN user is disabled.

    See getSaasAdminUserStatus for more information.

When you disable the SAAS_ADMIN user, access to the database is revoked and Autonomous Database rotates the password or the secret that was used to access the database.

Notes for Break Glass Access

Provides notes for break glass access.

Notes for break glass access:

  • The duration you specify when you enable SAAS_ADMIN applies either until the specified time expires or until you explicitly disable the SAAS_ADMIN user. You cannot change this value after you enable the SAAS_ADMIN user.

  • Always Free Autonomous Database does not support access with the SAAS_ADMIN user.

  • The DBA_CLOUD_CONFIG view provides information on the SAAS_ADMIN user.

    For example, the use the following query to obtain information on the status for the SAAS_ADMIN user:

    SELECT PARAM_VALUE FROM DBA_CLOUD_CONFIG WHERE
                 param_name ='saas_admin_access' order by 1;

    The presence of a value for auth_revoker means the access has been revoked and shows the user who revoked access.

    The auth_end shows a planned time. After authorization is revoked, if the authorization expired at the time end of the duration specified when SAAS_ADMIN user was enabled, the planned time will be the same as the actual time. If the planned and the actual time are different, this means that SAAS_ADMIN authorization was revoked before the duration expired.

    For example, if SAAS_ADMIN is enabled with a duration of 2 hours, and after 1 hour access is disabled by calling the API configureSaasAdminUser to disable the SAAS_ADMIN user, the auth_end planned and actual times will be different.

    If this query shows no rows, then the SAAS_ADMIN user does not exist. It may have been created and dropped or it was never created.