Security and Your Service

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 Schema Service, 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 Schema Service
Application security options
Security options for RESTful Web Services that access Schema Service

Oracle Cloud Security Measures

All security is based on well-thought out and implemented practices and procedures. Oracle Database Cloud Schema Service 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 Schema Service, 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 Schema Service 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 Schema Service Security Measures

Oracle Database Cloud Schema Service 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 Schema Service, 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 Schema Service, see Oracle Database Cloud Schema Service Features and Implementation Considerations.

Application Security Options

Your Oracle Database Cloud Schema Service 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 Schema Service.

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 Schema Service 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

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 Schema Service 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.

Description of the illustration restful.gif

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 Schema Service 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 Schema Service.

However, this does not mean that you cannot limit access to data based on user identity. The identity of a user is established through Schema Service 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.