Database Security and Privacy UNIT - III - PPT

18CSE455T - Database Security and Privacy
Prepared by
Dr. B. Muruganantham
Assistant Professor
Department of
Computer Science and
Engineering
SRMIST, Chennai
References :
1) Hassan A. Afyouni, “Database Security and Auditing”, Third Edition,

Cengage Learning, 2009
2) Charu C. Aggarwal, Philip S Yu, “Privacy Preserving Data Mining”:
Models and Algorithms, Kluwer Academic Publishers, 2008
3) Ron Ben Natan, ”Implementing Database Security and Auditing”,
Elsevier Digital Press, 2005.
4) http://adrem.ua.ac.be/sites/adrem.ua.ac.be/files/securitybook.pdf
5) www.docs.oracle.com
10/25/2023 Dr.B.Muruganantham
AP / CSE / SRMIST
UNIT III - Database Application Security Models & Virtual
Private Databases
 Introduction
 Types of Users
 Security Models
 Application Types
 Application Security Models
 Data Encryption
 Overview of VPD
 Implementation of VPD using Views
 Application Context in Oracle
 Implementing Oracle VPD
 Viewing VPD Policies and Application contexts using Data Dictionary
 Policy Manager Implementing Row
 Column level Security with SQL Server
AP / CSE / SRMIST
Introduction
 A Database user being used to log on ( be authenticated ) to an

application
 For each application user , a database account must be created and

assign specific privileges.
 Application
 A program that solves a problem or performs a specific business
function
 Database
 A collection of related data files used by an applications
 DBMS
 A collection of programs that maintain data files (Database)
AP / CSE / SRMIST
Types of Users
 Application Administrator – Has application privileges to administer application

users and their roles ( do not require any special database privileges )
 Application owner – User who owns application tables and objects
 Application user – Perform tasks within the application
 DBA – Perform any administration tasks
 Database user- user account that has database roles and/or privileges assigned to
it
 Proxy user – User is employed to work on behalf of an application user
 Schema owner - User that owns database objects
 Virtual user – An account that has access to the database through another
database account; a virtual user is referred to in some cases as a proxy user
AP / CSE / SRMIST
Security Models
 There are two security models
 Access Matrix Model
 Access Modes Model
AP / CSE / SRMIST
Security Models…
 Access Matrix Model
 A conceptual model that specifies the right that each subject
– possesses for each object
 Subjects in rows and objects in columns
Object 1 Object 2 . . . Object m
Subject 1 Access Access . . . Access

[S1,01] [S1,02] [S1,0m]
Subject 2 Access Access . . . Access

[S2,01] [S2,02] [S2,0m]
. . . .
. . . .
. . . .
Subject n Access Access . . . Access

[Sn,01] [Sn,02] [Sn,0m]
AP / CSE / SRMIST
Security Models…
Access Matrix Model - Example
AP / CSE / SRMIST
Security Models…
Access Modes Model

 This model based on the Take-Grant models
 It uses both subject and object
 Object is the main security entity
 Access mode indicates that the subject can perform any task or not
 There are two modes
 Static Modes
 Dynamic Modes
AP / CSE / SRMIST
Security Models…
Access Modes – Static Modes
Access Mode Level Description
Use 1 Allows the subject to access the object without

modifying
Read 2 Allows the subject to read the content of the object
Update 3 Allows the subject to modify the content of the object
Create 4 Allows the subject to add instance to the object
Delete 4 Allows the subject to remove instance to the object
AP / CSE / SRMIST
Security Models…
Access Modes – Dynamic Modes
Access Mode Level Description
Allows the subject to grant any static access mode to any

Grant 1 other subject
Allows the subject to revoke a granted static access mode
Revoke 1 from the subject
Allows the subject to grant the grant privileges to other

Delegate 2 subjects
Allows the subject to grant the revoke privileges to other
Abrogate 2 subjects
AP / CSE / SRMIST
Application Types
 Mainframe applications
 Client / Server Applications
 Web Applications
 Data warehouse applications
AP / CSE / SRMIST
Application Types …
Mainframe applications
 Years back computing in corporations was centralized in the Management Information
System(MIS)
 MIS department is responsible for all information
 MIS mainly developed for Mainframe projects The following figure is Mainframe
application architecture
Workstation Mainframe
Server
CODE
DB
Server
AP / CSE / SRMIST
Client / Server Applications
 To overcome the limitations in MIS department the client / server architecture was
introduced
 It is based on a business model, client request and the server respond
 Client / Server architecture became a dominating configuration for all applications
 Flexible
 Scalable
 Processing power
 Three main components typically found in Client / Server architecture
 User interface component – Represents all screens, reports, etc.,
 Business logic component – Contains all the codes related to data
validations
 Data access component – Contains all the codes related to retrieves,
inserts, deletes and updates
AP / CSE / SRMIST
 A client / server application consists of minimum of two tiers .
 Normally four to five tiers is the maximum configuration
 The following figure represents the logical components of a client server architecture
CLIENT
Tier 1
User Tier 2
Interface Business Tier 3
Logic Business Tier 4
Logic
Tier 5
SERVER
AP / CSE / SRMIST

 The following figure represents the physical architecture of a client/server
application
Client Server
DB
User Business Data Server
Interface Logic Access
 The data access component of client server architecture is the component

responsible for retrieving and manipulating data.
 The security model should be embedded in this component.
AP / CSE / SRMIST
Web Applications
 Client server application once dominated but not for long.
 Another architecture evolved with rise of dot-com and Web-based companies
 The new client / server architecture is based on the web and it is referred as a web
application or a Web-based application
 Web application uses HTTP protocol to connect and communicate to the server.
 Web pages are embedded with other web services.
 The following figure represents the logic components of Web application
architecture
CLIENT
Web browser layer Tier 1
Web server layer Tier 2
Application server layer Tier 3
Business logic layer Tier 4
Database server layer Tier 5
SERVER
AP / CSE / SRMIST
Components of Web application
 Web browser layer - Atypical browser program that allows user to

navigate through web pages found on the internet.
 Web server layer – A software program residing on a computer

connected to Internet
 Application server layer - A software program residing on a computer that is

used for data processing
 Business logic layer – A software program that implements business

rules
 Database server layer – A software program that stores and manages data
AP / CSE / SRMIST
 The following figure shows a physical architecture that is typical for a
web-based application.
 In this architecture , each layer resides on a separate computer
 One or more web application layers could be housed on one computer

 The main reason for separating web application layers to reside on different
computers is to distribute the processing load
Server
Client
Application Server
Business Logic
Web Server
Web DB
browser Internet Server
AP / CSE / SRMIST
Data Warehouse Applications

 DW is subject oriented , time variant, non volatile and integrated system.
 DWs are decision support system.
 DW is a collection of many types of data taken from different data sources.

 The architecture of these types of data warehousing applications is typically of
a database server on which the application resides.
 The DW is accessed by software applications or reporting applications called
OLAP ( OnLine Analytical Processing)
AP / CSE / SRMIST
 The following figure shows the Physical and Logical structure of a data
warehouse
Server
DB
Server
Client Server
OL AP
ionr
Applicat
Data Source
DB Transform
Server Data Application
Server
Server
Data
Warehouse DB
Database Server
Application
Server
AP / CSE / SRMIST
Application Security Models
 Database role based
 Application role based
 Application function based
 Application role and function based
 Application table based
AP / CSE / SRMIST
Application Security Models …
Security Model based on Database Roles
 This model depends on the application to authenticate the application users by
maintaining an end users in a table with their encrypted passwords
 In this model each end user is assigned a database role
 The user can access whatever the privileges are assigned to the role
 In this model proxy user needed to activate assigned roles
 The following figure shows the data model for this application (Security data
model based on database roles)
APPLICATION USERS APPLICATION USERS ROLES
APP_USER_ID
APP_USER-ID (FK)
APP-USERNAME
APP_ENC_PASSWORD ROLE_NAME
FIRST_NAME CTL_INS_DTIM
LAST_NAME CTL_UPD_DTIM
CTL_INS_DTIM CTL_USER_USER
CTL_UPD_DTIM CTL_USER_STAT
CTL_UPD_USER
CTL_REC_STAT
AP / CSE / SRMIST
The following list presents the a brief description of these columns
CONTROL COLUMN DESCRIPTION
CTL_INS_DTIM Contains when date and time when the record

(Control insert Date and Time) was inserted
CTL_UPD_dtim Contains when date and time when the record

was last updated
(Control update Date and Time)
CTL_UPD_USERS Contains the username that created the record

(Control update user) or last updated the record
CTL_REC_STAT Can be used to indicate the status of the

(Control Record Status) record
AP / CSE / SRMIST
Tables used in security data model based on database roles
TABLE NAME DESCRIPTION
Stores and maintain all end users of the

APPLICATION_USERS applications with their encrypted
passwords
Contains all roles defined by the

APPLICATIONS_USERS_ROLES application and for each role that a
privilege is assigned , the privileges can be
read, write or read/write
AP / CSE / SRMIST
Architecture of a security data model based on database roles
Contains three columns:

Username, password and role
Application User with
no database privileges
Application
Authorization table
End User
Proxy user has read access

to authorization table and
Is assigned to all application Schema Owner
roles
All application tables are owned

by schema owner including
authorization table
AP / CSE / SRMIST
The following points on this type of security model are worth noting:
 This model uses the DB role functionality
 Therefore it is DB independent
 If the roles are implemented poorly , the model does not work properly
 Privileges to table are also DB dependent
 Can isolate the application security from the DB
 Maintenance of the application security does not require specific DB privileges
 Password must be surely encrypted

 The application must use proxy users to log on and connect to the application
database and activate specific roles for each database session
AP / CSE / SRMIST
Implementation in ORACLE
1. Creating the users by entering the following code:
Creating Application Owner
SQL > CREATE USER APP_OWNER IDENTIFIED BY APP_OWNER
2 DEFAULT TABLESPACE USERS
3 TEMPORARY TABLESPACE TEMP
4 QUOTA UNLIMITED ON USERS;
User created
SQL> GRANT RESOURCE, CREATE SESSION TO APP_OWNER;

Grant succeeded
Creating Proxy User
SQL > CREATE USER APP_PROXY IDENTIFIED BY APP_PROXY
2 DEFAULT TABLESPACE USERS
3 TEMPORARY TABLESPACE TEMP;
User created
SQL> GRANT CREATE SESSION TO APP_PROXY;

Grant succeeded
AP / CSE / SRMIST
Creating Application tables
SQL> CONN APP_OWNER@DB

Enter password : *********
Connected
SQL> CREATE TABLE CUSTOMERS

2 ( CUSTOMER_ID NUMBER PRIMARY KEY,
3 CUSTOMER_NAME VARCHAR2(50) );
Table created
SQL> CREATE TABLE AUTH_TABLE

2 ( APP_USER_ID NUMBER,
3 APP_USERNAME VARCHAR2(20),
4 APP_PASSWORD VARCHAR2(20),
5 APP_ROLE VARCHAR2(20) );
Table created
AP / CSE / SRMIST
Creating Application Roles
SQL> CONNECT SYSTEM@DB

Enter password: *******
Connected
SQL> CREATE ROLE APP_MGR;

Role created
SQL> CREATE ROLE APP_SUP;

Role created
SQL> CREATE ROLE APP_CLERK;

Role created
SQL> GRANT APP_MGR, APP_SUP, APP_CLERK TO APP_PROXY;

Grant succeeded
SQL> ALTER USER “APP_PROX” DEFAULT ROLE NONE;

User altered
AP / CSE / SRMIST
Assign grants
SQL> CONNECT APP_OWNER@DB

Connected
SQL> GRANT SELECT,INSERT,UPDATE,DELETE ON CUSTOMER TO APP_MGR;

Grant succeeded
SQL> GRANT SELECT,INSERT,UPDATE,DELETE ON CUSTOMER TO APP_SUP;

Grant succeeded
SQL> GRANT SELECTON CUSTOMER TO APP_CLREK;

Grant succeeded
SQL > GRANT SELECT ON AUTH_TABLE TO APP_PROXY;

Grant succeeded
AP / CSE / SRMIST
2. Add rows to the CUSTOMER table
SQL> CONN APP_OWNER@DB

Connected
SQL> INSERT INTO CUSTOMERS VALUES (1, ‘Tom’);

1 row inserted
SQL> INSERT INTO CUSTOMERS VALUES (2, ‘Linda’);

1 row inserted
SQL> COMMIT
Commit complete
AP / CSE / SRMIST
3. Add a row for an application user called APP_USER:
SQL> INSERT INTO AUTH_TABLE VALUES (100, ’APP_USER’

‘d323deq4fdfgdgg’, ‘APP_CLERK’);
1 row inserted
4. Now assume that APP_USER is trying to log in through PROXY_USER.

Your application should look up the role of the user by using the SELECT
statement and activating that role:
SQL> SELECT APP_ROLE FROM AUTH_TABLE WHERE APP_USERNAME =

‘APP_USER’;
APP_ROLE
----------------------------
APP_CLERK
AP / CSE / SRMIST
5.Activate the role for this specific APP_USER session:
SQL> CONN APP_PROXYUSER

Enter password : **********
Connected
SQL> SET ROLE APP_CLERK;

Role set
SQL> SELECT * FROM SESSION_ROLES;

ROLE
-------------------------
APP_CLERK
AP / CSE / SRMIST
Implementation in SQL Server
 In SQL Server 2000 you are using application roles.
 Application roles are the special roles you create in the database, that are then
activated at the time of authorization.
 Application roles requires a password and cannot contain members
 Application roles are inactive by default

 Application roles can be activated using the SP_SETAPPROLE , system stored
procedure
AP / CSE / SRMIST
Creating Application Roles using the command line
 To create an application role in the Query Analyzer, use the SP_ADDPROFILE system-stored
procedure
sp_addapprole [ @rolename = ] ‘role’, [@password =] ‘password’
Where :
@rolename – The name of the application role ( The value must be a valid
identifier and cannot already exist in the database)
@password – The password required to activate the role. (SQL Server stores
the password as an encrypted hash)
Example :
To create the application role of clerk for your Pharmacy database , use this command
exec sp_addapprole ‘clerk’, ‘Clerk@ccess’
AP / CSE / SRMIST
Creating Application Roles using SQL

Server Enterprise Manager
Follow the steps
1. Open Enterprise Manager
2. Expand the Role container for your
Pharmacy database. Right click in the
right pane, the select New Database
Role
3. Type the name db_accessadmin in the
name box
4. Select Application Role under
Database role type
5. Enter password db@ccess in the text
box
6. Click OK to create the role.
AP / CSE / SRMIST
Dropping application Roles using Command line

 To drop an application role , using the Query Analyzer ,use the
SP_DROPAPPROLE system-stored procedure
sp_dropapprole [@rolename = ] ‘role’
Where
@rolename – The Application role to drop.
Dropping application Roles using Enterprising Manager
 Follow the steps

1. Open Enterprise Manager
2. Expand the roles container of the database from which you are dropping
the role
3. Select and Delete the desired role
AP / CSE / SRMIST
Security Model based on Application Roles
 Depends on the application authenticate the application users.
 Authentication is accomplished by maintaining all end users in a table with their
encrypted passwords.
 Each end user is assigned an application role to read / write specific modules of
the applications.
 The following table contains the description of tables used for this model.
APPLICATION_USERS
APP_USER_ID APPLICATION USERS
APP_ROLE_ID
APP_ROLE_ID (FK)
APP_USERNAME
APP_ENC_PASSWORD APP_ROLE_NAME
FIRST_NAME APP_ROLE_DESCRIPTIO
LAST_NAME N
CTL_INS_DTTM APP_ROLE_PRIVILEGE
CTL_UPD_DTTM CTL_INS_DTTM
CTL_UPD_USER CTL_UPD_DTTM
CTL_REC_STAT CTL_UPD_USER
CTL_REC_STAT
AP / CSE / SRMIST
Architecture of Security Model based on Application Roles

Application
Authorization table
End User
Schema Owner

authorization table
AP / CSE / SRMIST
Security Model based on Application Roles
 When considering this security model , keeps this point in mind
 This model is primitive and does not allow the flexibility required to make
changes necessary for security
 Privileges are limited to any combination like read, add, read / update /
admin and so on
 The following list presents characteristics of this security model
 Isolating the application security from the database

 Only one role is assigned to an application user
 This lowers the risk of database violations
 Passwords must be securely encrypted
 The application must use a real database user to log on and connect to the
application database
AP / CSE / SRMIST
Security Model based on Application Functions
 Based on application functions depends on the application to authenticate the
application users
 Application divided into functions
 The following figure represents a data model for this type of application
APPLICATION_USERS APPLICATION_USERS_FUNCTIONS APPLICATION_FUNCTIONS

APP_USER_ID APP_FUNCTION_ID
APP_USER_ID (FK)
APP_FUNCTION_ID (FK)
APP_ROLE_ID (FK) APP_FUNCTION_PRIVILEGE_ID (FK) APP_FUNCTION_NAME
APP_USERNAME APP_FUNCTION_DESCRIPTION
APP_ENC_PASSWORD CTL_INS_DTTM
FIRST_NAME CTL_INS_DTTM CTL_UPD_DTTM
LAST_NAME CTL_UPD_DTTM CTL_UPD_USER
CTL_INS_DTTM CTL_UPD_USER CTL_REC_STAT
CTL_UPD_DTTM CTL_REC_STAT
CTL_UPD_USER
CTL_REC_STAT
APPLICATION_FUNCTION_PRIVILEGE
APP_FUNCTION_PRIVILEGE_ID
APP_FUNCTION_PRIVILEGE_OPERATION
CTL_INS_DTTM
CTL_UPD_DTTM
CTL_UPD_USER
CTL_REC_STAT
AP / CSE / SRMIST
Architecture of Security Model based on Application Functions

Application
Authorization
End User tables owned
Schema Owner by application
owner
Schema Owner

authorization table
AP / CSE / SRMIST
The following list presenting the characteristics of this security model
 Isolating the application security from the database
 Only one role is assigned to an application user
 This lowers the risk of database violations
 Passwords must be securely encrypted

 The application must use a real database user to log on and connect to the
application database
 The application must be designed in a granular module.
AP / CSE / SRMIST
Security model based on Application Roles and Functions

 It is a combination of both the role and function security model
 Depends on the application to authenticate the application users
 The application authenticates users by maintaining all end users in a table with
their encrypted passwords
 Applications are divided into functions and roles are assigned to functions that
are in turn assigned to users.
 This model is highly flexible in implementing application security.
AP / CSE / SRMIST
 The following figure represents a data model for Security Model Based
on Application showing the ER Diagram
APPLICATION_USERS APPLICATION USERS ROLES APPLICATION _ROLES
APP_USER_ID APP_USER-ID (FK) APP_ROLE-ID

APP_ROLE_ID (FK)
APP_USERNAME APP_ROLE_NAME
APP_ENC_PASSWORD CTL_INS_DTIM APP_ROLE_DESCRIPTION
FIRST_NAME CTL_UPD_DTIM APP_ROLE_PRIVILEGE
LAST_NAME CTL_USER_USER CTL_INS_DTIM
CTL_INS_DTTM CTL_USER_STAT CTL_UPD_DTIM
CTL_UPD_DTTM CTL_USER_USER
CTL_UPD_USER CTL_USER_STAT
CTL_REC_STAT
APPLICATION_FUNCTIONS APPLICATION_ ROLE_FUNCTIONS APPLICATION_FUNCTION_PRIVILEGE
APP_FUNCTION_ID APP_FUNCTION_ID (FK) APP_FUNCTION_PRIVILEGE_ID

APP_ROLE_PRIVILEGE (FK)
APP_ROLE-ID (FK)
APP_FUNCTION_NAME APP_FUNCTION_PRIVILEGE_DESCRIPTION
APP_FUNCTION_DESCRIPTION CTL_INS_DTTM
CTL_INS_DTTM CTL_INS_DTTM CTL_UPD_DTTM
CTL_UPD_DTTM CTL_UPD_DTTM CTL_UPD_USER
CTL_UPD_USER CTL_UPD_USER CTL_REC_STAT
CTL_REC_STAT CTL_REC_STAT
AP / CSE / SRMIST
 Architecture of a Security data model based on application roles and

function
Contains columns for
Username, password , role
function and privilege

Application
Authorization
table
Schema Owner
Schema Owner

authorization table
AP / CSE / SRMIST
 The following list presents the characteristics of security model based

on application roles and functions
 Provides utmost flexibility for implementing application security
 Isolate the application security from the database

 Maintenance of the application security does not require specific database
privileges
 Lowers the risk of database violations
 Password must be surely encrypted
 The application must be designed in a very granular fashion
AP / CSE / SRMIST
Security Model Based on Application Tables
 Depends on application to authenticate users by maintaining all end users in a
table with their encrypted passwords
 All application provides privileges to the user based on tables
 User is assigned access privilege to each table owned by the application owner
 The following figure represents a data model for this security model
APPLICATION_USERS APPLICATION_USER_TABLES APPLICATION_TABLES
APP_USER_ID APP_USER_ID (FK) APP_TABLE_ID

APP_TABLE_ID (FK)
APP_USERNAME APP_TABLE_PRIVILEGE_ID (FK) APP_TABLE_NAME
APP_ENC_PASSWORD APP_TABLE_DESCRIPTION
FIRST_NAME CTL_INS_DTTM CTL_INS_DTTM
LAST_NAME CTL_UPD_DTTM CTL_UPD_DTTM
CTL_INS_DTTM CTL_UPD_USER CTL_UPD_USER
CTL_UPD_DTTM CTL_REC_STAT CTL_REC_STAT
CTL_UPD_USER
CTL_REC_STAT
APPLICATION_TABLE_PRIVILEGES
APP_TABLE_PREVILIGES_ID
APP_TABLE_PRIVILEGE_DESCRIPTION
CTL_INS_DTTM
CTL_UPD_DTTM
CTL_UPD_USER
CTL_REC_STAT
AP / CSE / SRMIST
Architecture of a Security Model Based on Application Tables
Authorization table has four columns

Username, password , table and
accesss (0,1,2,3,4,5)

Application
Authorization
table
Schema Owner
Schema Owner

authorization table
AP / CSE / SRMIST
 The following list presents the characteristics of security model based on

application tables
 Isolate the application security from the database

 Maintenance of the application security does not require specific database
privileges
 Lowers the risk of database violations
 Security is implemented easily by using table access privileges
AP / CSE / SRMIST
Characteristics of Security Model
Security Model
Applicatio
Database Application
Application n Role and Application
Role Function
Role based Function Table Based
based Based
Characteristics Based
Is flexible in implementing
application security No No No Yes No
Isolates application security

from the DB Yes Yes Yes Yes Yes
Maintenance of application
security does not require
specific DB privileges No No No Yes No
Password must be securely

encrypted Yes Yes Yes Yes Yes
Uses real DB user to log on No Yes Yes Yes Yes

Is business-function specific
No No Yes Yes No
AP / CSE / SRMIST
Data Encryption
 Encryption is a security method in which information is encoded in
such a way that only authorized user can read it.
 It uses encryption algorithm to generate ciphertext that can only be read

if decrypted.
 Types of Encryption
 There are two types of encryptions schemes as listed below:
 Symmetric Key encryption
 Public Key encryption
AP / CSE / SRMIST
Data Encryption
 Symmetric key encryption algorithm uses same cryptographic keys for both
encryption and decryption of cipher text.
 Public key encryption algorithm uses pair of keys, one of which is a secret key and
one of which is public. These two keys are mathematically linked with each other.
AP / CSE / SRMIST
Virtual Private Databases
 VPD (Virtual Private Database) is shared database schema containing data
that belongs to many users , and each user can view or manipulate
the data the user owns
User can only see and

modify data of deptno 20
Schema Owner
User can only see and

modify data of deptno 10
AP / CSE / SRMIST
 Not every database system offers a mechanism to implement VPD

with out VIEW objects.
 ORACLE offered VPD in several versions before the release of 10G
 ORACLE uses two other names to refer VPDs

 Row Level Security (RLS)
 Fine Grain Access (FGA)
AP / CSE / SRMIST
Architecture of Virtual Private Database
Use
O
DBMS_RLS Add RACLE
Package and s
Regi upplied
ster
a po PL/SQL
licy
for t package
he E
MP to
tabl
e
VPD policy automatically adds a

WHERE clause predicate Deptid = 20 Schema Owner
----- Query is rewritten to become

EMP Table
Submits
SELECT * FROM PRODUCTS ------ SELECT * FROM PRODUCTS
WHERE DEPTID = 20
-----
Policy
Function
AP / CSE / SRMIST
 Setup Test Environment
 Create an Application Context
 Create Login Trigger
 Create Security Policies
 Apply Security Policies to Tables
 Test VPD
AP / CSE / SRMIST
Setup Test Environment
 First we must create a user to act as the schema owner for this example. Obviously, you will
perform the following tasks using your current schema owner.
CONNECT sys/password@service AS SYSDBA;
CREATE USER schemaowner IDENTIFIED BY schemaowner DEFAULT TABLESPACE users

TEMPORARY TABLESPACE temp;
GRANT connect, resource TO schemaowner;
CREATE USER user1 IDENTIFIED BY user1 DEFAULT TABLESPACE users TEMPORARY

TABLESPACE temp;
GRANT connect, resource TO user1;
CREATE USER user2 IDENTIFIED BY user2 DEFAULT TABLESPACE users TEMPORARY

TABLESPACE temp;
GRANT connect, resource TO user2; GRANT EXECUTE ON DBMS_RLS TO PUBLIC;
AP / CSE / SRMIST
CONN schemaowner/schemaowner@service
CREATE TABLE users (id NUMBER(10) NOT NULL, ouser VARCHAR2(30) NOT
NULL, first_name VARCHAR2(50) NOT NULL, last_name VARCHAR2(50) NOT
NULL);
CREATE TABLE user_data (column1 VARCHAR2(50) NOT NULL, user_id

NUMBER(10) NOT NULL);
INSERT INTO users VALUES (1,'USER1','User','One');
INSERT INTO users VALUES (2,'USER2','User','Two');
COMMIT;
GRANT SELECT, INSERT ON user_data TO user1, user2;
AP / CSE / SRMIST
Create an Application Context
 Grant CREATE ANY CONTEXT to the schema owner then create the context and
context package.
GRANT create any context, create public synonym TO schemaowner;
CONNECT schemaowner/schemaowner@service;
CREATE CONTEXT SCHEMAOWNER USING SCHEMAOWNER.context_package;
CREATE OR REPLACE PACKAGE context_package AS PROCEDURE

set_context;
END;
/
AP / CSE / SRMIST
 Next we create the context_package body which will actually set the user context.
CREATE OR REPLACE PACKAGE BODY context_package IS

PROCEDURE set_context IS v_ouser VARCHAR2(30); v_id NUMBER;
BEGIN
DBMS_SESSION.set_context('SCHEMAOWNER','SETUP','TRUE');
v_ouser := SYS_CONTEXT('USERENV','SESSION_USER');
BEGIN
SELECT id INTO v_id FROM users WHERE ouser = v_ouser;
DBMS_SESSION.set_context('SCHEMAOWNER','USER_ID', v_id);
EXCEPTION WHEN NO_DATA_FOUND THEN
DBMS_SESSION.set_context('SCHEMAOWNER','USER_ID', 0);
END;
DBMS_SESSION.set_context('SCHEMAOWNER','SETUP','FALSE');
END set_context;
END context_package;
AP / CSE / SRMIST
 Next we make sure that all users have access to the Context_Package.
GRANT EXECUTE ON SCHEMAOWNER.context_package TO PUBLIC;
CREATE PUBLIC SYNONYM context_package FOR SCHEMAOWNER.context_package;
Create Login Trigger
 Next we must create a trigger to fire after the user logs onto the database.
CREATE OR REPLACE TRIGGER SCHEMAOWNER.set_security_context

AFTER LOGON ON DATABASE
BEGIN
SCHEMAOWNER.context_package.set_context;
END;
AP / CSE / SRMIST
Create Security Policies
 In order for the context package to have any effect on the users interaction with
the database, we need to define a security_package for use with the security
policy. This package will tell the database how to treat any interactions with the
specified table.
CONNECT schemaowner/schemaowner@service;
CREATE OR REPLACE PACKAGE security_package AS

FUNCTION user_data_insert_security(owner VARCHAR2, objname VARCHAR2)
RETURN VARCHAR2;
FUNCTION user_data_select_security(owner VARCHAR2, objname VARCHAR2)

RETURN VARCHAR2;
END security_package;
AP / CSE / SRMIST
 Next we create the security_package body.
CREATE OR REPLACE PACKAGE BODY Security_Package IS
FUNCTION user_data_select_security(owner VARCHAR2, objname VARCHAR2) RETURN VARCHAR2 IS
predicate VARCHAR2(2000);
BEGIN
predicate := '1=2';
IF (SYS_CONTEXT('USERENV','SESSION_USER') = 'SCHEMAOWNER') THEN
predicate := NULL;
ELSE
predicate := 'USER_ID = SYS_CONTEXT(''SCHEMAOWNER'',''USER_ID'')';
END IF;
RETURN predicate;
END user_data_select_security;
FUNCTION user_data_insert_security(owner VARCHAR2, objname VARCHAR2) RETURN VARCHAR2 IS

predicate VARCHAR2(2000);
BEGIN
predicate := '1=2';
IF (SYS_CONTEXT('USERENV','SESSION_USER') = 'SCHEMAOWNER') THEN
predicate := NULL;
ELSE
predicate := 'USER_ID = SYS_CONTEXT(''SCHEMAOWNER'',''USER_ID'')';
END IF;
RETURN Predicate;
END user_data_insert_security;
END security_package;
AP / CSE / SRMIST
 Next we make sure that all users have access to the Security_Package.
GRANT EXECUTE ON SCHEMAOWNER.security_package TO PUBLIC;
CREATE PUBLIC SYNONYM security_package FOR SCHEMAOWNER.security_package;
Apply Security Policies to Tables
 The DBMS_RlS package is used to apply the security policay, implemented by

security_package, to the relevant tables.
BEGIN
DBMS_RLS.add_policy('SCHEMAOWNER', 'USER_DATA',
'USER_DATA_INSERT_POLICY',
'SCHEMAOWNER', 'SECURITY_PACKAGE.USER_DATA_INSERT_SECURITY',
'INSERT', TRUE);
DBMS_RLS.add_policy('SCHEMAOWNER', 'USER_DATA',
'USER_DATA_SELECT_POLICY',
'SCHEMAOWNER', 'SECURITY_PACKAGE.USER_DATA_SELECT_SECURITY',
'SELECT');
END;
AP / CSE / SRMIST
Test VPD
 Finally, test that the VPD is working correctly.
CONNECT user1/user1@service;
INSERT INTO schemaowner.user_data (column1, user_id) VALUES ('User 1', 1);
COMMIT;
CONNECT user2/user2@service
COMMIT;
CONNECT schemaowner/schemaowner@service
SELECT * FROM schemaowner.user_data;
CONNECT user1/user1@Service;
CONNECT user2/user2@Service
AP / CSE / SRMIST
Column level Security with SQL Server
 Column level permissions provide a more granular level of security for data in
your database. You do not need to execute a separate GRANT or DENY
statements for each column; just name them all in a query:
GRANT SELECT ON data1.table (column1, column2) TO user1;
GO
DENY SELECT ON data1.table (column3) TO user1;
GO
 If you execute a DENY statement at table level to a column for a user, and after
that you execute a GRANT statement on the same column, the DENY permission
is removed and the user can have access to that column. Similarly, if you execute
GRANT and then DENY, the DENY permission will be in force.
AP / CSE / SRMIST

Database Security and Privacy UNIT - III - PPT

Uploaded by

Copyright:

Available Formats

Database Security and Privacy UNIT - III - PPT

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Database Security and Privacy UNIT - III - PPT

Uploaded by

Copyright:

Available Formats

18CSE455T - Database Security and Privacy

1) Hassan A. Afyouni, “Database Security and Auditing”, Third Edition,

 A Database user being used to log on ( be authenticated ) to an

 For each application user , a database account must be created and

 Application Administrator – Has application privileges to administer application

 There are two security models

 Access Matrix Model

 Access Modes Model

Subject 1 Access Access . . . Access

Subject 2 Access Access . . . Access

Subject n Access Access . . . Access

Access Modes Model

 It uses both subject and object

 Object is the main security entity

Access Mode Level Description

Use 1 Allows the subject to access the object without

Update 3 Allows the subject to modify the content of the object

Create 4 Allows the subject to add instance to the object

Delete 4 Allows the subject to remove instance to the object

Access Mode Level Description

Allows the subject to grant any static access mode to any

Allows the subject to grant the grant privileges to other

 Client / Server Applications

 Data warehouse applications

 Normally four to five tiers is the maximum configuration

Client / Server Applications

 The data access component of client server architecture is the component

 Web browser layer - Atypical browser program that allows user to

 Web server layer – A software program residing on a computer

 Application server layer - A software program residing on a computer that is

 Business logic layer – A software program that implements business

 One or more web application layers could be housed on one computer

Data Warehouse Applications

 DWs are decision support system.

 DW is a collection of many types of data taken from different data sources.

 Database role based

 Application role based

 Application function based

 Application role and function based

 Application table based

CTL_INS_DTIM Contains when date and time when the record

CTL_UPD_dtim Contains when date and time when the record

CTL_UPD_USERS Contains the username that created the record

CTL_REC_STAT Can be used to indicate the status of the

TABLE NAME DESCRIPTION

Stores and maintain all end users of the

Contains all roles defined by the

Contains three columns:

Proxy user has read access

All application tables are owned

 This model uses the DB role functionality

 Privileges to table are also DB dependent

 Can isolate the application security from the DB

 Maintenance of the application security does not require specific DB privileges

 Password must be surely encrypted

SQL> GRANT RESOURCE, CREATE SESSION TO APP_OWNER;

SQL> GRANT CREATE SESSION TO APP_PROXY;

SQL> CONN APP_OWNER@DB

SQL> CREATE TABLE CUSTOMERS