The volume of the data being stored in databases is increasing day by day and so is the need to access this data. One of the biggest challenge for organizations is to keep this data safe from hackers, intruders etc while still keeping it accessible to legitimate users. On the same token there is a growing concern to make sure that internal employees also do not get their hands on this data. Oracle is well aware of the challenges which organizations are facing and hence every new release of the database is accompanied with a number of Enhanced Security Features. In this article we will look at these eOracle 12c Security Features including Data Redaction, Unified Auditing and Extended SHA-2.
Read more on other Oracle Database Security topics:
• Oracle Database Security Checklist
• Log into a Schema Without a Password!
Oracle 12c Security Data Redaction Unified Auditing Extended SHA-2
Auditing has been part of the database features for quite some time now but the main problem has been that it takes too much to manage the collected audit data. Secondly there were several different types of auditing which can be enabled. They include Standard Auditing, Fine Grained Auditing, Privileged user Auditing. Each one of these have have to be turned on individually and their audit data is stored in different trail locations. A further disadvantage was the difficulty in enabling the auditing, as bouncing of the database instance was required. Furthermore there was no standard way of protecting the audit data itself. Lastly, accessing that audit data also had some performance concerns.
Starting with 12c, Oracle has unified all of the auditing types into one single unit called Unified auditing. You don’t have to turn on or off all of the different auidting types individually and as a matter of fact auditing is enabled by default right out of the box. The AUD$ and FGA$ tables have been replaced with one single audit trail table. All of the audit data is now stored in Secure Files table thus improving the overall management aspects of audit data itself.
The auditing of access to audit records table is also enabled by default. Further the audit data can also be buffered solving most of the common performance related problems seen on busy environments.
Unified Auditing is able to collect audit data for Fine Grained Audit, RMAN, Data Pump, Label Security, Database Vault and Real Application Security operations.
Audit Roles and Policies
A feature closely related to auditing is the introduction of the new roles and policies. Audit roles are basically a step forward towards implementing a better SOD (Segregation of Duty) guideline. Now a user with DBA or SYSDBA role only needs to create a tablespace to hold audit data. The new role, AUDIT_ADMIN, should be the primary, responsible for managing the audit data and defining the audit policies. Further to view the actual audit data there is separate role, AUDIT_VIWER, provided for users who are assigned to view the audit data.
Audit policies are the named containers of audit settings that you may want to implement. You can create policies to audit the actions, privileges and objects access. These policies can be system wide or they can be specific to your own requirement. They can include roles and can have conditions as well as exceptions. These policies will be enabled by using the familiar audit and noaudit commands.
Until 11g, Oracle did not have a data masking facility. There were features where you could completely hide sensitive data like Credit Card numbers and Social Security numbers. This was normally targeted for use in development and test instances. This was however not suitable for Production systems because they completely replaced the original value, rendering the record useless. Starting in 12c, Oracle has provided a data masking facility built right into the database called Data Redaction. With this you no longer have to mask your data using complex programming inside your application either.
The new database package, DBMS_REDACT is used to mask the data and has the option to mask the data either randomly, with some special characters using regular expressions, or mask the data partially or in its entirety. A possible use case is the hiding of the starting or ending Credit Card numbers or making social security numbers partially visible.
Database Vault Improvements
The Database Vault has been considerably improved, especially the management aspect,making it much easier to configure and use. Infact, it’s already installed as part of database installation and all you have to do is to complete the configuration using just a single command. The performance overhead has been pushed to near zero as well. The database vault too uses the Unified Auditing trail.
Another interesting enhancement is the new mandatory “realms” feature. With this all privileges can be revoked, even from the owner of the data. The application DBAs will also not have access to sensitive data while they are upgrading or patching the applications.
Role and Privilege Analysis
One of the main security challenge comes when you deploy an application which uses the database as the back end. Normally the aaplication deployments require some level of DBA support with access to data to partner the code change. To meet the project deadlines this single Security aspect of the data was ignored. Niether was there any way of recording the use of privileges and roles assigned to applications during this deployment phase.
Starting with 12c, Oracle now introduces the Roles and Privilege analysis and aims at achieving the least privilege model. Once setup the feature will monitor which privileges and roles are not being used by the applications and thus enable the application administrators to possibly revoke those unnecessarily granted privileges. Apart from showing which privileges are not being used by users it also shows how the user got this privilege in first place!
Code Based Security
Normally if an application needs certain privilege during runtime then those required privileges are assigned to the user who will be running the application code. If a user A needs to execute package B and package B has the Create Table command in it, then in order for this package to be able to run successfully, you will have to assign the Create Table privilege to user A. But starting with 12c the Create Table privilege can now be assigned to Package B instead of the user A thus implementing security at code level.
This greatly improves the overall security perspective of the database as the privileges will be controlled at more granular level.
Restrictions on Privileges and Roles
The Select Any Dictionary privilege has now been restricted so that user having it does not have access to the security related metadata stored inside the data dictionary. In particular having this privilege will not allow you to access sensitive tables like DEFAULT_PWD$, ENC$, LINKS$, USER$, USER_HISTORY$ and XS$VERIFIERS.
Additionally the UNLIMITED_TABLSPACE privilege will also not be a part of the Resource role any more. If you have upgraded from the previous releases then this restriction will not apply. However if Resource role is assigned in 12c, it will not have UNLIMITED_TABLESPACE privilege.
SOD and Extended SHA-2 support
Oracle 12c has better SOD (Segregation of Duties) model as there are new roles specifically created for specific DBA operations. We already saw this in Unified Auditing that to view or manage audit data there are new roles. But 12c also introduces new roles like SYSBACKUP to perform backup related operations, SYSDG to perform operations related to Data Guard and SYSKM to perform operations related to Key Management. These roles will complement the existing DBA roles like SYSOPER, SYSASM and of course SYSDBA.
The support for SHA-2 (Strong Hashing Algorithm) in encryption was started in 188.8.131.52 but it now has been extended. The SHA-2 will be used to authenticate passwords and can also be used by DBMS_CRYPTO advance security package.
Last Login Information
When a user logged in last time is now recorded in USER$ table and also displayed in SQL*PLUS when the user connects to database. This is helpful in two ways. First storing last login information in USER$ table will allow the DBA to check which user is not being used and which one is used heavily.
Displaying the same information in SQL*PLUS when user logs in allows the user to see if someone else has used his login information.
Label Security Metadata Export/Import
The metadata for Oracle Label Security is stored inside LBACSYS schema. Starting from 12c you can export and import this schema as part of Full database export/import. This will allow you to move the label security settings from one database to another thus resulting in conformity of settings. For this to work your source database must be 184.108.40.206 or higher and terget must be 12.1 or higher.
Password Complexity Check
When creating database using DBCA the password complexity checks for users will be performed at the spot. This will improve the overall security of the database.
Read more on Oracle 12c Database Extended Data Types.