[Oracle] Defense in depth

As we know, we are fighting an asymmetrical battle with attackers when it comes to defend our valuable artifacts such as databases, web servers, mail servers, etc. Also, I am not aware of any system that is free of vulnerabilities. Attackers exploit those vulnerabilities to gain access to these systems. Further, you cannot eliminate the human factor. No amount of technology can make a system secure if your users are attack vectors. The reality is that we cannot make any system completely secure.

So, I hear you ask if we cannot secure our systems, aren't we doomed to fail? Not really. Having been working in the security field for a long time, one thing I have realized is that security is not about building 100% secure systems, but rather it is about building systems that makes attackers life harder to break in. Security is all about economics. If you can make the system harder to break in, financially motivated attackers will give up eventually as the effort (aka investment on time and resources) they put in is far greater than the outcome (aka profit by breaking in) they get.

So, if we cannot build fully secure systems, how can we make systems harder to break in? You have to deploy multiple layers of security in order to protect your valuable assets. In other words, you need to build defense in depth into your system. Think about a bank safe. The safe is not kept in a public area, but rather you have to go through multiple doors to get into where the safe is mounted. Once you reach there, then you are left with the task of breaking the safe itself. That's a lot of labor. Most attackers would simply give up.

Let me show how Oracle database 12c takes the defense in depth approach.

Perimeter security:
- Strong authentication (preventive)
- On the wire encryption (preventive)
- AVDF - Audit Vault and Database Firewall (preventive and detective)

Out-bound data:
- Secure backup
- Data masking
- Data redaction (for applications)

Access control:
- DAC and RBAC based privileges and roles
- VPD (Virtual Private Database) - row level access control
- OLS (Oracle Label Security) - multi-level security
- DV (Database Vault) - privileged user controls
- RAS (Real Application Security) - middleware-application security

Data at rest:
- Standard ACID controls
- TDE (Transparent Data Encryption) - data-at-rest encryption
- Oracle wallet/OKV (Oracle Key Vault) for key management

Administrative/Hardening Tools - help reduce the attack surface:
- Secure configuration management
- Privilege analysis
- Sensitive data discovery

Monitoring:
- Unified auditing framework
- AVDF (Audit Vault)

Similar to the bank safe example mentioned above, it is also very important to harden the environment (OS, network) where the database is deployed as well.

[Oracle] Proxy Authentication

You are the DBA of your organisation managing a cluster of Oracle databases. You want to give full access to a schema (say hr) to multiple database users (say bob and alice). How can you do it?

One approach is to give schema name and password to the users. Do you see any problem with that approach? I can think of at least a few:
1. Accountability - multiple users using the same username/password makes tracing actions to database users impossible.
2. Security - shared password is more vulnerable to exposure risks.
3. Revocation - in order to revoke access to the hr schema, you need to change the password of hr user.

Another approach would be to grant system privileges to bob and alice so that they can do anything on the hr schema. However, this does not follow the principle of least privileges and is prone to misuse as users are given more privileges than they require to do the job. Therefore, it is not a good idea to grant system privileges. In fact, as a rule of thumb, system privileges should be granted sparingly in order to improve security.

An improved approach would be to grant all privileges on the hr schema to bob and alice. This requires granting object privileges on each object in hr schema. Managing many object privileges is a nightmare. Further, this does not allow to create new objects in the hr schema. Therefore, this solution also has limitations.

So, what can we do about it? Having identified the above limitations, Oracle actually introduced what is called proxy authentication for such use cases. You simply grant proxy authentication to the users. The following toy script shows how to:  (You can also further restrict access to the schema by specifying what roles can be used during the proxy session. For simplicity, I am omitting such fine tuning here.)


SQL> conn / as sysdba
Connected.

SQL> alter user hr grant connect through bob;
User altered.
SQL> alter user hr grant connect through alice;
User altered.

SQL> 
SQL> conn hr
Password:
SQL> create table emp(name varchar2(100), sal int);
Table created.

SQL> insert into emp values ('tim', 125000);
1 row created.
SQL> insert into emp values ('eve', 150000);
1 row created.

SQL> -- bob connecting as proxy user

SQL> conn bob[hr]

Password:

SQL> select sys_context('userenv', 'current_user') from dual;

SYS_CONTEXT('USERENV','CURRENT_USER')

-------------------------------------

HR

SQL> select sys_context('userenv', 'proxy_user') from dual;

SYS_CONTEXT('USERENV','PROXY_USER')

-----------------------------------

BOB

SQL> -- bob can do anything on hr schema

SQL> select * from hr.emp;

NAME      SAL

------------------

tim       125000

eve       150000