Security and Oracle Database Cloud Service (Database Schema)

One of the key concerns for organizations as they move to a shared resource model on the Cloud is insuring the security of their data. Oracle Database Cloud Service (Database Schema), like the Oracle Database that is the foundation of the Database Cloud, has been created from the beginning with the utmost concern for security.

Topics:

This section reviews several aspects of security and the Oracle Cloud:

  • The basic architecture of the security domains used with Oracle Cloud

  • Security measures that apply to the overall service

  • Security measures that apply to individual Oracle Database Cloud Services (Schema)

  • Application security options

  • Security options for RESTful Web Services that access Oracle Database Cloud Services (Schema)

Security Architecture

The Oracle Cloud uses a security architecture that includes different security domains and administrative and use privileges within a particularOracle Database Cloud Service (Database Schema).

Topics:

Security Domains

There are several different security domains used with the overall implementation of Oracle Database Cloud Service (Database Schema).

  • Accounts

  • Identity Domain

  • Oracle Database Cloud Service (Database Schema)

Accounts

Each and every Oracle Database Cloud Service (Schema) is owned by an account. An account is the top level in the security hierarchy. The individual who initially sets up an Account is known as the Buyer. A Buyer is automatically an Account Administrator as an Account Administrator can assign themselves privileges at the Identity Domain and Service level.

When you initially sign up for a Oracle Database Cloud Service (Schema), you must have an Oracle.com user account. After you initially sign up for a service, you can grant the Account Administrator privilege to any other Oracle.com users. Any Account Administrator can remove the Account Administrator privilege from any other Account Administrator.

Account Administrators can see all services, PaaS or SaaS services, associated with an account.

Identity Domain

An Identity Domain is a pool of users. An account can have one or more Identity Domains, but each domain is separate and distinct. You must define an Identity Domain when you initially request an account, and the requester is given a username within the Identity Domain.

Identity Domain membership and privileges are defined on the Security page in My Services.

Members of an Identity Domain can have security roles for one or more of the Cloud Services associated with the Identity Domain. These roles described in more detail below.

Identity Domain Administrators can see all Oracle Database Cloud Service (Schema) associated with the Identity Domain, and can assign and remove all security roles associated with these services, including the Administrator role for any of the services.

Oracle Database Cloud Service (Database Schema)

Oracle Database Cloud Service (Schema) is an individual service within the Oracle Cloud. Data within an individual Oracle Database Cloud Service (Schema) is completely separated from data in all other services in the Oracle Cloud, as described in more detail below.

Oracle Database Cloud Service (Schema) administrators can define users for the services that they administer. Oracle Database Cloud Service (Schema) users can be defined on the Security page in My Services or within the Administration area of the development platform for the service itself. If a user is defined on the Security page in My Services, they must use this page to manage their profile; if a user is defined through the Administration area of the development platform, they must manage their profile through that platform. Administrators and developers for Oracle Database Cloud Service (Schema) must be defined on the Security page in My Services and given the appropriate security role.

Security Roles

There is an Administrator role at the Account, Identity Domain and Service levels. Administrators can grant this role at their level to other defined users.

There are three roles for each Oracle Database Cloud Service (Database Schema):

  • Service Administrator, who can create, modify and delete Oracle Database Cloud Service (Schema) users and their privileges, both on the Security page in My Services and the Administration area of Oracle Database Cloud Service (Schema) development platform.

  • Developers, who can use the development platform within Oracle Database Cloud Service (Schema) to create applications, but who cannot create, modify or delete users for that Oracle Database Cloud Service (Schema).

  • End users, who can run applications within Oracle Database Cloud Service (Schema).

When Oracle Database Cloud Service (Schema) is added to an Identity Domain, three individual roles which map to these levels are created within the Identity Domain. The Account Administrator and Identity Domain Administrator are automatically given the Service Administrator role for the initial Oracle Database Cloud Service (Schema), but all other roles have to be explicitly assigned on the Security page in My Services.

Managing Users and Roles

All users and roles defined as part of the Cloud Identity Domain are administered on the Security page in My Services. On this page, an Identity Domain or Service administrator is allowed to add, delete and modify users, or to create, delete, assign or delete roles.

Identity Domain Administrators are allowed to access all users defined within their Identity Domain and their roles. Service Administrators only have access to the users defined for their Service, and users of a service can only modify their own user profile and reset their account password.

For more details, refer to Managing Users and Roles in Getting Started with Oracle Cloud.

Oracle Cloud Security Measures

All security is based on well-thought out and implemented practices and procedures. Oracle Database Cloud Service (Database Schema) is implemented with rigorous security practices and procedures based on decades of experience.

The security processes used for the overall Oracle Cloud include secure access to data centers, annual security audits by third parties to insure regulatory security compliance and full auditing of the entire Cloud stack on a quarterly basis.

All data stored in the Oracle Cloud benefits from the use of Transparent Data Encryption. Transparent Data Encryption encrypts data stored on disk and in backups, protecting against unauthorized direct file access. The encryption and decryption of your data is handled automatically by the Oracle Database, so you do not have to add programmatic steps to use this powerful security feature.

The Oracle Cloud has to be protected against the introduction of malicious code which could harm all users. To enforce this level of protection while still allowing users to load data into their Oracle Database Cloud Service (Schema), data loads are sent to a Secure FTP server, where they are scanned for viruses before the data in the files is loaded into the Oracle Database Cloud Service (Schema) using your database account information. With this approach, malicious data can never be loaded in such a way that it affects other accounts or breaches the security isolation. This two step process also automatically compresses the actual data to be loaded, reducing the time needed to upload data to the Oracle Cloud.

Oracle Database Cloud Service (Database Schema) Security Measures

Oracle Database Cloud Service (Database Schema) is built on a multi-tenant architecture, with database schemas providing the boundaries of tenant isolation. Schemas have been used in the Oracle Database as a method of separating data for decades.

To enforce and protect the absolute security of tenants of Oracle Database Cloud Service (Schema), some standard Oracle features have been locked down.

For instance, access to any data dictionary view which allows a tenant to see the existence of other schemas has been prohibited. In addition, some SQL syntax is not allowed, such as GRANT or REVOKE, since accessing objects between one schema to another schema owner uses these options.

For a detailed list of syntax, objects and operations disallowed in Oracle Database Cloud Service (Schema), see Oracle Database Cloud Service (Database Schema) Features and Implementation Considerations.

Application Security Options

Your Oracle Database Cloud Service (Database Schema) includes Oracle Application Express, which you can use to develop and deploy HTML-based applications through a declarative process. Oracle Application Express has been in production since 2004, with hundreds of thousands of enterprise applications deployed throughout the world.

There are many features of Oracle Application Express that help you to develop secure applications in your Oracle Database Cloud Service (Schema).

Oracle Application Express supports several authentication schemes used to insure that a particular user is properly identified. Oracle Application Express gives developers the ability to use authorization schemes, which are ways of allowing access to specific pages, regions within pages or items within regions, based on user identity. As a developer, you always have access to the identity of a user, so you can implement procedural limitations based on user identity.

Although Oracle Application Express includes robust monitoring tools, you can add in procedural logic to log application and session specific information for further security analysis.

Oracle Application Express includes protection against cross-site scripting attacks by providing a way to reference values that automatically escapes special characters, which will not allow any type of script to be included in pages returned to users through Oracle Database Cloud Service (Schema) applications.

In addition, Oracle Application Express gives you the option to automatically protect navigational URLs from being maliciously modified. This option, referred to as Session State Protection, generates checksums which are included with any parameters passed as part of a URL to retrieve a page in an application. In addition, you can prevent a page from ever being accessed by a URL, only allowing access as the destination of a navigation link or branch from another page within the application.

Application Express also includes reports which allow you to rapidly see the security options in force for a particular application, and also to monitor usage of applications and individual pages in applications.

RESTful Web Service Security Options

Application Express also includes reports which allow you to rapidly see the security options in force for a particular application, and also to monitor usage of applications and individual pages in applications.

Topics:

You can also specify security on a RESTful Web Service in several ways. These ways are different from the traditional method of using schema users to implement security. Oracle Database Cloud Service (Database Schema) is based on a single schema, and all RESTful Web Services which access data in this schema are executed by the user who owns the schema. Without any specific security implementations on a RESTful Web Service, the services will return all data that satisfies an SQL statement or is collected by a PL/SQL block.

There are three ways you can add security to your RESTful Web Services:

  • Based on the application using the RESTful Web Service

  • Based on the identity of the user calling the RESTful Web Service

  • Based on logic implemented in the RESTful Web Service call itself

Authentication

RESTful Services support two types of authentication: First party authentication and Third party authentication.

First party authentication is accomplished by the first-party authority, in this case the Application Express security system.

Third party authentication is accomplished by a third party authority, so the application requesting the authentication does not actually know the identity of the user.

Once a user is authenticated through either of these methods, you can limit authorization based on the identity of the user.

OAUTH2 Authentication

RESTful Web Services use the OAUTH2 model of authentication, as shown in the diagram below.

OAUTH2 authentication is one of the standard authentication flows used on the Internet. To understand how to implement application-based or user-based authentication, you need to understand how the OAUTH authentication process flow works.

OAUTH authentication requires two different tokens - a request token, which allows a client to request authorization, and an access token, which grants access to a specific user.

To limit access based on the application, you can grant access to the RESTful Web Services once authentication is complete. You can also use the username for specific authentication.

Logic-based Access

The method of implementing security described above grants access to one or more specific RESTful Web Services calls, similar to allowing a connection to a database. In traditional database security, access is granted based on the identity of the database user making the request. Since all RESTful Web Services in a specific Oracle Database Cloud Service (Database Schema) are executed by the same database user, this option is not available for these Services.

In recognition of this architecture, the SQL command GRANT is not supported in Oracle Database Cloud Service (Schema).

However, this does not mean that you cannot limit access to data based on user identity. The identity of a user is established through Oracle Database Cloud Service (Schema) authentication process, and this identity is available to developers as the :current_user bind variable, kept securely in the header of all RESTful Web Service requests.

You can use this value as part of a standard WHERE clause, which, for instance, could be used to limit the rows returned from a query to those for the same department as the current user. You could also use this value in more complex logic in either SQL or PL/SQL.