An additional security layer in adw cloud v2

ThomasTeske,Oracle – 2018-06-18 – audience:public–keywords :database,security,autonomous
thomas.teske@oracle.com @ThomasTeskeORCL
Securingyour data in Oracle AutonomousData Warehouse CloudService
Say “Hello”tovirtual private database inthe cloud
by ThomasTeske, Oracle, June 18th
2018
Introduction:
Securitymatterstoeveryone.All cloudvendorsstriveforthe securityprotectionlevelsforthe cloud
infrastructure,the service instances,datatransfersandproperrole basedaccesscontrols.See the
followingreportfora recent securitydocument bykuppingercole. Itisonline available at
http://www.oracle.com/us/products/database/kuppingercole-autonomous-database-4368706.pdf
Thisdocumentshall triggeryourthoughts,turnyourwantsintoactionable sprintsdelivering
actionable code.Justcode it…
Is your data secure within your applicationor analytics?
Withinanapplicationoranalytics-service itisequallyimportanttobe contextaware.
 Who has the permissionon whichoperationonwhichsubsetof data?
 Under whichcircumstancesisinallowed?
 If it is allowed:isitinsix monthsalsoOKforyour auditor?Thus:alwaysenforce accessrules
and monitorthemandanalysisthe monitoredusage.Otherwise youdon’tknow,whatis
goingon.Any modernsecurityoperationscenterworksonsuchprinciples.
 On topof that youwant to constrainall applicationusersasfollows:
no one shall see the PIIrelevantattributes –
inour example:name,address,city,phone-numberare shownbuttheyremainempty.
 Some usersmightnotevenbe allowedtosee the countrynorregional information
inour example:nationandregion are shownbuttheyremainempty.
 Responsibilitiesof usersmightrestrictthemtoworkonlywithasubsetof the data -
inour example:we onlyallowsome usersworkingwithdataforAMERICA and MIDDLE-
EAST.
All data shownhere issyntheticdata.The Oracle AutonomousDataWarehouse cloudservice
(ADWC) comeswitha greatresource:the SSB schemafor testing.Itispopulatedwithasimple data
model aboutcustomers,businessdates,products,suppliersandorderlinessreferringto them.
ADWC isdescribedat https://cloud.oracle.com/en_US/datawarehouse

Example for VPD:
One recipe implementingVPDisshownin ourexample:
1. DATA Creatingacopy of a subsetof the sample schemaSSBintoschemaADMIN.
ADMIN ownsthe data beingsharedwiththe otherusers.
2. USERS Creatingtendatabase usersALICE,BOB, CHARLIE,… to demonstrate accessfor
different
persons/profiles.
Alternativeapproach:use ONLYdatabase usersforapplicationroles.Thatrequiresthe VPD
policiestodetermine permissionsinaslightlydifferentway.
3. METADATA Creatingusermeta-datadescribingthe (application) users.
4. METADATA Creatingpermission meta-datadescribingpermissionsonthe data model.
5. METADATA Assigningpermissionstothe database users.
6. VPD FUNCTIONS& POLICIES Create for eachtable the necessaryfunctionstodetermine the
predicatestobe appliedbyVPD.Define the VPDpoliciesontablesusingthesefunctions.
7. ROLE Define arole inthe database containingthe basicaccessrightsto tables.
ROLE ASSIGNMENTAssignthe database role tothe database users.
8. PUBLIC SYNONYMSCreatingpublicsynonymsforthe tables –simplifyaccess.
Note:VPDimplementationscanbe done differentlyi.e.using differentMETA DATA model.

WHAT we protect
We coverinour simple model dataaboutCUSTOMERs, SUPPLIERs,TIME, PRODUCTS and ORDERs.
No matter,howpeople accessthe data:it mustremainsecuredwithnoexceptionspossible.

HOW we protect it
METADATA drivessecurity.We keeprecordof PEOPLE,ROLESand ENTITLEMENTS i.e.assigned
ROLES to PEOPLE.

HOW it works in the database
In Oracle database we have VPD.It takesthe METADATA first.FUNCTIONsare automaticallyinvoked
to access the METADATA.The FUNCTIONsdetermine,how toautomaticallyaddaccessrestrictions
to SQL commands.All thishappenswithoutachance of interceptionnorexception.
Thisis,how itworksfor an individualtable.

Since we have more than one table:all the rulesapply,whenevercombinationsof tablesare used.It
happensall inthe backgroundautomatically.Rulescanbe muchmore complex thanthe oneswe
usedhere. A caution:alwaysensure,thatrulescanbe explainedinsimple terms.If youcan’tdo that,
than itis reallydifficulttocheck,if theyare correct.

1. DATA Creatingacopy of a subsetof the sample schemaSSB
As userADMIN run the following.
CUSTOMER
-- create a demo table from SSB demo schema
create table customer as
select * from ssb.customer;
SUPPLIER
create table supplier as
select * from ssb.supplier;
DWDATE
create table dwdate as
select * from ssb.dwdate;
PART
create table part as
select * from ssb.part;
LINEORDER
-- original table is 6 billion records!
create table lineorder as
select * from ssb.lineorder
where c_custkey <= 1000;

2. USERS Creatingtendatabase users
As userADMIN run the following.
-- create users using simple passwords
-- consider enabling password policies later on!
create user alice identified by Welcome1234#;
…
-- allow them having sessions to the database
grant CREATE SESSION to alice;
…

3. METADATA Creatinguser
As userADMIN run the following.CreateaMETA-DATA table first.
create table SOC_USER
( U_USER VARCHAR2(30 BYTE) NOT NULL ENABLE,
U_NAME VARCHAR2(30 BYTE) NOT NULL ENABLE,
U_DEPT VARCHAR2(30 BYTE) NOT NULL ENABLE,
CONSTRAINT "SOC_USER_PK" PRIMARY KEY ("U_USER") ENABLE
);
Nowadd METADATA describingthe rolesandresponsibilitiesof these applicationusers.
insert into SOC_USER
values ( 'ADMIN', 'Matthew and team', 'application data steward' );
values ( 'ALICE', 'Alice', 'sales management, worldwide' );
…

4. METADATA Creatingmeta-datadescribingpermissions
create table SOC_PROFILE
( P_PROFILE VARCHAR2(30 BYTE) NOT NULL ENABLE,
P_NAME VARCHAR2(60 BYTE) NOT NULL ENABLE,
P_PREDTYPE VARCHAR2(12 BYTE) NOT NULL ENABLE,
P_PRED_TABLE VARCHAR2(60 BYTE) NOT NULL ENABLE,
P_PRED_COLUMN VARCHAR2(60 BYTE) ,
P_PRED_COLVAL VARCHAR2(60 BYTE) ,
CONSTRAINT "SOC_PROFILE_PK" PRIMARY KEY ("P_PROFILE") ENABLE
);
Insertdata describingthe permissionsinbusinessterms.
-- allow access to all columns in CUSTOMER table
insert into SOC_PROFILE
values ( 'CUST_ALL_COLUMNS', 'see all columns in table', 'HIDE_COLS',
'CUSTOMER', NULL, NULL );
-- allow access to all columns excluding the PII columns in CUSTOMER
table
values ( 'CUST_NO_PII_COLUMNS', 'see no PII columns in table',
'HIDE_COLS', 'CUSTOMER', NULL, NULL );
-- allow access to all columns excluding the GEO columns in CUSTOMER
table
values ( 'CUST_NO_GEO_COLUMNS', 'see no GEOGRAPHY columns in table',
'HIDE_COLS', 'CUSTOMER', NULL, NULL );
-- allow access to all rows in CUSTOMER table
values ( 'CUST_ALL_RECORDS', 'see all records in table', 'HIDE_ROWS',
'CUSTOMER', NULL, NULL );
-- allow access to C_REGION having value EUROPE only in CUSTOMER
table
values ( 'CUST_ONLY_EUROPE_ROWS', 'see only EUROPE rows in table',
'HIDE_ROWS', 'CUSTOMER', 'C_REGION', 'EUROPE' );
-- allow access to C_REGION having value AMERICA only in CUSTOMER
table
values ( 'CUST_ONLY_AMERICA_ROWS', 'see only AMERICA rows in table',
'HIDE_ROWS', 'CUSTOMER', 'C_REGION', 'AMERICA' );
-- allow access to C_REGION having value ASIA only in CUSTOMER table

values ( 'CUST_ONLY_ASIA_ROWS', 'see only ASIA rows in table',
'HIDE_ROWS', 'CUSTOMER', 'C_REGION', 'ASIA' );
-- allow access to C_REGION having value MIDDLE EAST only in CUSTOMER
table
-- This REGION is not used at all in our COUNTRY table!
values ( 'CUST_ONLY_MIEAST_ROWS', 'see only MIDDLE EAST rows in
table', 'HIDE_ROWS', 'CUSTOMER', 'C_REGION', 'MIDDLE EAST' );
-- allow access to C_REGION having value AFRICA only in CUSTOMER
table
values ( 'CUST_ONLY_AFRICA_ROWS', 'see only AFRICA rows in table',
'HIDE_ROWS', 'CUSTOMER', 'C_REGION', 'AFRICA' );
-- allow access to all columns in LINEORDER table
values ( 'ORDERS_ALL_COLUMNS', 'see all columns in table',
'HIDE_COLS', 'LINEORDER', NULL, NULL );
-- allo access to all columns excluding the COMMERCIAL columns in
LINEORDER table
values ( 'ORDERS_NO_COMM_COLUMNS', 'see no COMMERCIAL columns in
table', 'HIDE_COLS', 'LINEORDER', NULL, NULL );
-- allow access to all LO_ORDERDATE values in LINEORDER table
values ( 'ORDERS_ALL_DAYS', 'see any data in table', 'HIDE_ROWS',
'LINEORDER', NULL, NULL );
-- allow access to LO_ORDERDATE having value 30 days only in
LINEORDER table
values ( 'ORDERS_30_DAYS_ONLY', 'see only last 30 days in table',
'HIDE_ROWS', 'LINEORDER', 'LO_ORDERDATE', '30' );
LINEORDER table
LINEORDER table

LINEORDER table
-- allow access to all rows in SUPPLIER table
values ( 'SUPP_ALL_RECORDS', 'see all records in table', 'HIDE_ROWS',
'SUPPLIER', NULL, NULL );
-- allow access to S_REGION having value EUROPE only in SUPPLIER
table
values ( 'SUPP_ONLY_EUROPE_ROWS', 'see only EUROPE rows in table',
'HIDE_ROWS', 'SUPPLIER', 'S_REGION', 'EUROPE' );
-- allow access to S_REGION having value AMERICA only in SUPPLIER
table
values ( 'SUPP_ONLY_AMERICA_ROWS', 'see only AMERICA rows in table',
'HIDE_ROWS', 'SUPPLIER', 'S_REGION', 'AMERICA' );
-- allow access to S_REGION having value ASIA only in SUPPLIER table
values ( 'SUPP_ONLY_ASIA_ROWS', 'see only ASIA rows in table',
'HIDE_ROWS', 'SUPPLIER', 'S_REGION', 'ASIA' );
-- allow access to S_REGION having value MIDDLE EAST only in SUPPLIER
table
values ( 'SUPP_ONLY_MIEAST_ROWS', 'see only MIDDLE EAST rows in
table', 'HIDE_ROWS', 'SUPPLIER', 'S_REGION', 'MIDDLE EAST' );
-- allow access to S_REGION having value AFRICA only in SUPPLIER
table
values ( 'SUPP_ONLY_AFRICA_ROWS', 'see only AFRICA rows in table',
'HIDE_ROWS', 'SUPPLIER', 'S_REGION', 'AFRICA' );
-- allow access to all columns in SUPPLIER table
values ( 'SUPP_ALL_COLUMNS', 'see all columns in table', 'HIDE_COLS',
'SUPPLIER', NULL, NULL );
-- allow access to all columns excluding the PII columns in SUPPLIER
table
values ( 'SUPP_NO_PII_COLUMNS', 'see no PII columns in table',
'HIDE_COLS', 'SUPPLIER', NULL, NULL );

-- allow access to all columns excluding the GEO columns in SUPPLIER
table
values ( 'SUPP_NO_GEO_COLUMNS', 'see no GEOGRAPHY columns in table',
'HIDE_COLS', 'SUPPLIER', NULL, NULL );
Nowwe have usersand permissionsdefined.We now needtoassignpermissionstousers.
All the steps to this pointare covered by two scripts:

5. METADATA Assigningpermissions
create table SOC_USER_PROFILE
( UP_USER VARCHAR2(30 BYTE) NOT NULL ENABLE,
UP_PROFILE VARCHAR2(30 BYTE) NOT NULL ENABLE,
CONSTRAINT "SOC_USER_PROFILE_PK" PRIMARY KEY
("UP_USER","UP_PROFILE") ENABLE,
CONSTRAINT "UP_FK_USER" FOREIGN KEY ("UP_USER")
REFERENCES "SOC_USER" ("U_USER") ENABLE,
CONSTRAINT "UP_FK_PROFILE" FOREIGN KEY ("UP_PROFILE")
REFERENCES "SOC_PROFILE" ("P_PROFILE") ENABLE
);
Insertingactual assignments( akaentitlements)
-- user ADMIN - no constraints on customers nor order details
insert into SOC_USER_PROFILE
values ( 'ADMIN', 'CUST_ALL_COLUMNS' );
values ( 'ADMIN', 'CUST_ALL_RECORDS' );
values ( 'ADMIN', 'ORDERS_ALL_COLUMNS' );
values ( 'ADMIN', 'ORDERS_ALL_DAYS' );
values ( 'ADMIN', 'SUPP_ALL_RECORDS' );
values ( 'ADMIN', 'SUPP_ALL_COLUMNS' );
-- user ALICE - no constraints on customers nor order details
values ( 'ALICE', 'CUST_ALL_COLUMNS' );
values ( 'ALICE', 'CUST_ALL_RECORDS' );
values ( 'ALICE', 'ORDERS_ALL_COLUMNS' );
values ( 'ALICE', 'ORDERS_ALL_DAYS' );
values ( 'ALICE', 'SUPP_ALL_RECORDS' );

values ( 'ALICE', 'SUPP_NO_PII_COLUMNS' );
and so on.The complete listof assignmentsiscreated inscript:
We create a simple viewtodetail the insertedMETADATA.
create or replace view soc_entitlements as
select u.*, p.*
from soc_user u,
soc_profile p,
soc_user_profile up
where u.u_user = up.up_user
and p.p_profile = up.up_profile;
-- list the entitlements to see the overview
select * from soc_entitlements
order by u_user, p_profile;

6. VPD FUNCTIONS& POLICIES Create for eachtable
As userADMIN we define foreachtable the functionsandpoliciestobe applied.
GeneratedVPDpredicatesmayuse one scalarvalue tocompare withor a listof scalars.
Table inschema Scripts to define functionandpolicy
DWDATE none
CUSTOMER
LINEORDER
SUPPLIER
DWDATE

7. ROLE Define arole inthe database containingthe basicaccessrightsto tables&
ROLE ASSIGNMENTAssignthe database role tothe database users.
As userADMIN we define arole to accessthe objectsownedbythe usertothe application
users.
-- create a role to SELECT tables and views owned by ADMIN
create role select_on_admin;
grant select on dwdate to select_on_admin;
grant select on part to select_on_admin;
grant select on customer to select_on_admin;
grant select on supplier to select_on_admin;
grant select on lineorder to select_on_admin;
Then we grant the role to the application users:
-- grant role to users
grant select_on_admin to alice;
grant select_on_admin to bob;
grant select_on_admin to charlie;
grant select_on_admin to doug;
grant select_on_admin to linda;
grant select_on_admin to monica;
grant select_on_admin to robert;
grant select_on_admin to susan;
grant select_on_admin to harry;
grant select_on_admin to frank;
These stepsare coveredinthe followingscript:

8. PUBLIC SYNONYMSCreatingpublicsynonymsforthe tables –simplifyaccess.
As userADMIN run the following:
create public synonym dwdate for admin.dwdate;
create public synonym customer for admin.customer;
create public synonym prod for admin.prod;
create public synonym supplier for admin.supplier;
create public synonym lineorder for admin.lineorder;
Nowwe have createdthree METADATA tablesthat governwiththe helpof VPDfunctionsand
policiesthe accesstotablesownedbyADMIN.
That is all folks.
Nowyoucan start designingyourown.Please note:all code iskeptmostsimple
and maystrict codingguideline.Butyousee,how itisdone and can adapt as per
your codingethics,standardsandsecurityrequirements.

An additional security layer in adw cloud v2

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

An additional security layer in adw cloud v2