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.
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.
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.
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
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.
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).
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:
Use the API or the CLI and specify an OCID value for the
secretId.
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.
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).
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
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.
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_endplanned 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.