An additional security layer in autonomous data warehouse cloud service

Thomas Teske, Oracle – 2018-06-01 – audience: public – keywords : database, security, autonomous
thomas.teske@oracle.com @ThomasTeskeORCL
Securing your data in Oracle Autonomous Data Warehouse Cloud Service
Say “Hello” to virtual private database in the cloud
by Thomas Teske, Oracle, June 1st
2018
Introduction:
Security matters to everyone. All cloud vendors strive for the security protection levels for the cloud
infrastructure, the service instances, data transfers and proper role based access controls. See the
following report for a recent security document by kuppingercole. It is online available at
http://www.oracle.com/us/products/database/kuppingercole-autonomous-database-4368706.pdf
This document shall trigger your thoughts, turn your wants into actionable sprints delivering
actionable code. Just code it …
Is your data secure within your application or analytics?
Within an application or analytics service it is equally important to be context aware. Who is allowed
to perform which operation on which subset of data? Under which circumstances is in allowed? If it
is allowed: is it in six month also OK for your auditor? Thus: always enforce access rules and monitor
them and analysis the monitored usage. Otherwise you don’t know, what is going on. Any modern
security operations center works on such principles.
• You might want to define, which user is allowed to work with data entities
and the allowed actions.
• On top of that you want to constrain all application users as follows:
no one shall see the PII relevant attributes –
in our example: name, address, city, phone-number are shown but they remain empty.
• Some users might not even be allowed to see the country nor regional information
in our example: nation and region are shown but they remain empty.
• Responsibilities of users might restrict them to work only with a subset of the data -
in our example: we only allow some users working with data for AMERICA and MIDDLE-
EAST.
All data shown here is synthetic data. The Oracle Autonomous Data Warehouse cloud service
(ADWC) comes with a great resource: the SSB schema for testing. It is populated with a simple data
model about customers, business dates, products, suppliers and orderliness referring to them.
ADWC is described at https://cloud.oracle.com/en_US/datawarehouse

Example shown here:
To make it simple: we just take a copy of the CUSTOMER information in the sample SSB schema
having 99 records. We define four users:
• ADMIN – owns the CUSTOMER data with 99 records & provides access rights to the other
users.
• ALICE – is allowed to see all CUSTOMER records but not the PII relevant attributes
• BOB - is allowed to see all CUSTOMER records but not the PII nor the geography relevant
attributes
• Charlie - is allowed to see all CUSTOMER records but not the PII nor the geography relevant
attributes. Plus: Charlie is NOT allowed to see the data for AMERICA or MIDDLE EAST.
How does this feel for them? See our simple example – screenshots taken of Oracle SQL Developer
for the four users.
User ADMIN – owns the CUSTOMER table having 99 records.

User ALICE – sees all customer records BUT not the PII relevant attributes
User BOB – see all customer records but not the PII relevant attributes NOR the geography details

User CHARLIE – works for BOB and is not allowed to see two regions
How is that achieved?
Let us walk through it – step by step – all done by user ADMIN in our example.
1. Create some users and allow them having sessions in the database
-- create three users
create user alice identified by (some password);
create user bob identified by (some password);
create user charlie identified by (some password);
-- allow them to create sessions
grant CREATE SESSION to alice;
grant CREATE SESSION to bob;
grant CREATE SESSION to charlie;
2. Create a sample table and make its name globally accessible
-- create a small demo table from SSB demo schema
create table customer
as select * from ssb.customer
where rownum <= 100;
create public synonym customer for admin.customer;

3. Define simple functions to generate in Oracle additional SQL predicates that can’t be bypassed
Note: these functions are the most simplistic implementations. For an enterprise grade
application you will keep metadata entities that are queried by the functions instead of
generating the SQL predicates statically. You will also put them into package() and wrap them to
protect the code too.
CREATE OR REPLACE FUNCTION hide_pii (
v_schema IN VARCHAR2,
v_objname IN VARCHAR2)
RETURN VARCHAR2 AS
con VARCHAR2 (400);
BEGIN
-- return a predicate that allows only user ADMIN to conform for
policies using it.
con := 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') = ''ADMIN'' ';
RETURN (con);
END hide_pii;
a second one to hide the geography attributes
CREATE OR REPLACE FUNCTION hide_geography (
RETURN VARCHAR2 AS
con VARCHAR2 (400);
BEGIN
-- return a predicate that allows only users ADMIN and ALICE to
conform for policies using it.
con := 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') in ( ''ADMIN''
, ''ALICE'' ) ';
RETURN (con);
END hide_geography;

and a third function to constrain by specific region
CREATE OR REPLACE FUNCTION hide_some_regions (
RETURN VARCHAR2 AS
con VARCHAR2 (400);
BEGIN
-- return a predicate that allows only users ADMIN and ALICE to
conform for policies using it.
con := 'SYS_CONTEXT(''USERENV'',''SESSION_USER'') in ( ''ADMIN''
, ''ALICE'' , ''BOB'') ';
con := con || ' or not ( c_region in ( ''AMERICA'', ''MIDDLE
EAST'' )) ';
RETURN (con);
END hide_some_regions;
4. Define policies to apply the functions on table CUSTOMER
Note: these policies are applied specifically on table CUSTOMER but they could also be used to
be applied for a set of entities. That is very practical to remain productive and reduce the
number of potential gaps in your data protection.
We have three policies to apply each of the functions defined in the previous step. All policies
are applied in one go. You can enable/disable them, but disabling any single policy is highly
discouraged.
Code examples show always the DROP and then CREATE of a policy. If you change the code, it is
very useful having these sniplets already available.

First policy: mask the PII attributes
-- define a VPD policy to be in effect
-- to not show the columns c_name, c_nation c_address and
c_phone - just return NULLs.
BEGIN
DBMS_RLS.DROP_POLICY (
object_schema => 'admin',
object_name => 'customer',
policy_name => 'hide_pii' );
END;
BEGIN
DBMS_RLS.ADD_POLICY (
policy_name => 'hide_pii',
policy_function => 'hide_pii',
sec_relevant_cols => 'c_name, c_city, c_address, c_phone',
sec_relevant_cols_opt => dbms_rls.ALL_ROWS );
END;
Second policy: mask the geography attributes
BEGIN
policy_name => 'hide_geography' );
END;
BEGIN
policy_name => 'hide_geography',
policy_function => 'hide_geography',
sec_relevant_cols => 'c_nation, c_region',
sec_relevant_cols_opt => dbms_rls.ALL_ROWS );
END;

Third policy: reduce the result set i.e. do not pass records as such
BEGIN
policy_name => 'hide_rows_by_region' );
END;
BEGIN
policy_name => 'hide_rows_by_region',
policy_function => 'hide_some_regions',
statement_types => 'select' );
END;
5. Provide access to the CUSTOMER table
Only now you should provide access to the users. Otherwise you would have planned to
constrain their data access, but enforced policies later.
-- provide access to customer table to users
grant select on customer to alice;
grant select on customer to bob;
grant select on customer to charlie;
6. That is all folks.
Now you can start designing your own. Please note: all code is kept most simple
and will definitely fail the strict coding guidelines by Steven Feuerstein. But you see, how
it is done and can adapt as per your coding ethics, standards and security requirements.

An additional security layer in autonomous data warehouse cloud service

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Empfohlen

Empfohlen (20)

An additional security layer in autonomous data warehouse cloud service