2. What SCURTY is

From a high level point of view the purpose of SCURTY is:

  • Strictly personalized access

  • Tool-agnostic security

  • Enable personalized audit

  • Decentralized provisioning of users and rights

  • Row and column level security

  • Sandboxing

SCURTY adds a comprehensive, easy to use security layer to the Oracle Database Enterprise Edition. This layer provides authorization on object-, row- and column level in addition to the standard authorization layer of the database. It also provides a logon firewall using rules to check if a user is allowed to access the database. SCURTY enables personalized authorization by using either personalized accounts or context information provided by applications. This subsequently enables personalized auditing which means that the audit trail contains meaningful information.

SCURTY enables reporting on current and historical access rights. Several views show which user currently has access to which objects, sensitive columns, rows etc. The same information is available to tell which user had access at which point in time in the past. Oracle Flashback Archive is used to provide this information and the time period is configurable.

As SCURTY runs inside the database, it is always in effect, regardless of the tool used or what the access path looks like. It can be provisioned decentralized by calling the easy to use SCURTY API using a database connection with proper privileges. The API may even be hidden if SCURTY Plus, and additional, optional module is used.

SCURTY sandboxing means, database objects may be created and changed in a closed, separated environment inside the database. There are two different types of sandboxes: private sandboxes and project sandboxes. A private sandbox may only be used by a single user while a project sandbox is a space shared between several users. Of course the SCURTY security rules also apply to sandboxes.

Technically spoken, SCURTY is an intelligent framework with a user API to provide comfortable usage of Oracle Database security functions. SCURTY makes heavy use of these existing functions but completely hides complexity behind from users and from administrators. The use of these functions raises database security substantially. At the same time administrative effort regarding database security is reduced by automating creation and maintenance of the security functions. SCURTY utilizes all common Oracle Database security functions like user accounts, roles, database profiles and so on plus the following functions that usually are not widely in use:

  • Virtual Private Database (VPD)

  • Secure Application Roles

  • Application Context

  • Proxy Authentication

  • Database triggers

SCURTY combines the above features in a sensible way. It is not necessary to understand these features in detail and they will not be discussed within this guide. In fact during daily usage of SCURTY these features do not need to be maintained and they are not even shown to the administrator. SCURTY is goal-oriented which means the features are used without exposing their parameters, policies or code to anyone. SCURTY’s API uses information about a task (e.g. creating a user) to create or modify database objects incorporating all reasonable security features.

Using SCURTY it is possible to:

  • Create users and define user types

  • Create and grant object groups and add or remove objects from them

  • Register sensitive columns

  • Grant privileges to users down to row and column level access rights

  • Create temporary sandboxes e.g. for development or ad-hoc analysis

  • Preserve user identity in 2- and 3-tier environments

  • Report on current and historical access rights

  • Report on the status of all database objects created by SCURTY

SCURTY is not a separate add-on, instead it tightly integrates with the Oracle Database. SCURTY automates utilization of database functionality by creating objects and definitions depending on the requirements provided via API. It adds sophisticated logic to keep SCURTY definitions and the Oracle Database dictionary in sync at all times. This is true for both directions, meaning regardless if the change is made within SCURTY or outside of it e.g. by a DBA. For example if a user holding DBA privileges changes access rights, SCURTY is aware of it and possibly reverts the change if the implemented security rules require it. And in the other direction, changes within SCURTY are visible in the Oracle database dictionary, too. There is no break line between SCURTY and the Oracle database.

2.1. Security areas covered by SCURTY

After assessing security requirements they need to be mapped to functions that satisfy them. The following table shows security areas which can be configured in the Oracle Database and if they are covered by SCURTY:

Configurable security area in Oracle Database

Coverage by SCURTY

User accounts

Covered by SCURTY. Account creation and maintenance is part of SCURTY functionality.

Authentication methods and strong authentication

Partly covered by SCURTY. SCURTY makes use of several advanced authentication methods like for example proxy user authentication. SCURTY preserves the user identity also in multitiered environments. SCURTY integrates with external services for authentication (LDAP, RADIUS, KERBEROS) but they have to be configured separately.

Privileges and roles

Covered by SCURTY. Creation, granting and administration of roles is part of SCURTY functionality. Granting privileges on a row and/or column level is part of SCURTY functionality. Granting system privileges to roles, which is a well-established task in database administration is outside of the scope of SCURTY.

User session information using application context

Covered by SCURTY. SCURTY uses application context to provide the database with personalized information about the identity of a user.

Classify and protect data in different categories

Covered by SCURTY. SCURTY uses tenant columns (‘tenants’) to identify rows with different sensitivity categories. Tenants are used to restrict access on row level.

Network data encryption

Not covered by SCURTY. The effort to configure network encryption is very low and there is practically no maintenance.

Thin JDBC client network configuration Not covered by SCURTY.

JDBC client network configuration has to be done separate.

Auditing database activities

Oracle Database auditing has to be configured separately. SCURTY does not interact with it but enables meaningful audit logs by providing the real identity of the user at any time. Besides that SCURTY logs all changes to access privileges and provides a current and historical view on them.

2.2. Logon firewall

A logon firewall inside the database is part of SCURTY. This logon firewall uses rules to allow or deny login depending on the following factors:

  • username

  • client operating system username

  • granted roles

  • database profile name

  • database service name

  • client program name

  • client machine name

  • client terminal name

  • client IP address

Restriction: this logon firewall cannot prevent login for users holding the “administer database” privilege or the DBA role. To prevent login of such users an external database firewall is needed. Examples for external database firewalls are Oracle Database Firewall or IBM Security Guardium that provide another layer of access control. These products may check access even before the request reaches the database server.

Logon rules are stored in table CTX_LOGON_RULES and are added using procedure p_rep_admin.add_ctx_logon_rule.

2.3. SCURTY and Oracle Database editions, options and management packs

The configurable security areas in Oracle Database described above are those that are included in the database license. SCURTY utilizes functionality included in Oracle Database Enterprise Edition and will not work with Oracle Database Standard Edition 2.

In addition, SCURTY supports datamasking in the context of column level security (CLS) leveraging the Data Redaction option. Make sure that a valid license for this option is in place before this functionality is used.

Other additional database options or enterprise management packs are not required but may be added. These options and management packs may add reasonable security to a system. For example the already mentioned encryption of data at rest by Transparent Data Encryption, part of the Advanced Security Option, may be implemented without lots of effort and adds security against attacks from the operating system side. Database options and management packs do not interact or interfere with SCURTY.

2.4. Integration with an external IDM

SCURTY may be integrated with an existing Identity Management (IDM) solution. The IDM may provide user names and access privileges via SCURTY API calls. Metadata may be provided manually or the IDM may translate the organizational roles to technical roles that are then activated in SCURTY. A user holding the SCURTY operator role may configure provisioning from IDM.