CST221: Database Systems Dr. Zhen JiangComputer Science DepartmentWest Chester UniversityWest Chester, PA 19383

OutlineOverview

◦Non-relational DB system◦NonSQL DB system

InjectionInference

◦Role access control (UML)◦Perturbation

Design ◦Models◦Encryption

DBMS

Database System Overview

dataDatabase

Query reque

st

IntegrationAdministration Security &

encryptionPrivacy & inferenceTransaction &

injectionSketching & hashing

Application Programming Interface (API)

integration

Traditional DatabaseThe relation of key vs. non-keyThe relation between key and foreign

key◦Intra-table relation◦Inter-table relation

E-R diagram◦http://www.cs.wcupa.edu/~zjiang/ER.pdf ◦Any regularity?

Arbitrary & Abrupt

◦Ambiguity Sample of such ambiguity in normalization

process caused by the lack of background

Non-Relational DatabaseData does not relate in the true

sense◦e.g., Mongo, which handles

document stores or other content and/or metadata stores

NonSQL DatabaseA more clear structure

e.g., Kobo, Playtika (mobile service) Distributed database system

No need and not possible for a “join” operator Fast third-party data aggregation Fast caching for application objects Globally distributed data repository E-commerce and internet burstness Game (data intensive applications) Ad targeting (social networks)

Query reque

stOk?

APIDBMS

InjectionDirect DB injection

◦http://www.youtube.com/watch?v=v6bphRHH4sM

Indirect DB injection◦http://www.irongeek.com/i.php?page

=videos/webgoat-sql-injection

You need a tool for the

trace of transactions

interrupt each transaction as you debug and trace

the record of each transaction

Authorization◦ Restrict access to data and restrict the

actions that people may take (when they access data).

Encryption◦ Scramble data so that the data cannot be

read.

Authentication◦ Password check◦ Key protection, not to protect everything!

Role based access control

Inference (aggregation)Basically, inference occurs when

users are able to piece together (aggregate) information to determine a fact that should be protected.

Role cheating

Flight ID Cargo Hold Contents Classification

1254 A Boots Unclassified

1254 B Atomic bomb Top secret

1254 C Butter Unclassified

General Jones (who has a top security clearance) requests information and would see all three.

Civilian Smith (who has no security clearance) requests the data and would see the following data:Flight ID Cargo Hold Contents Classificatio

n

1254 A Boots Unclassified

1254 C Butter Unclassified

When Smith sees that nothing is scheduled for hold B on flight 1254, he might attempt to insert the record, and his insertion will fail due to the unique constraint on cargo space availability.

He has all the data he needs to infer that there is a secret shipment on flight.

He could then cross-reference the flight information table to find out the source and destination of the secret shipment and various other information.

Poly-instantiation: allows different records (hold B) to exist in the same table.

Overbooking!

Other causes such as:◦Count of highly preferred customers◦Average salary

Problem is difficult◦Information?

Content: what is critical?

◦Path? Hold A-C, Hold B? Total space? Probing!

Existing solutions◦Limit access

Role access control Too many restriction could seriously

hinder the functionality

21

22

◦Perturbation Alter the data so that individual

details are accurate but overall generalization are inaccurate.

Include dummy data in the results returned by the query unauthorized.

Protect sensitive data, but also achieve preservation of the properties of the dataset. Sketching with a probability of p. With probability p to use the original data With probability (1-p) to use a replacement

PreservationGiven each query f in the original table T with n rows, build a re-constructible query f’ in the revised table T’ (with n rows), so that the result difference can be controlled in a limited range with a probability of p.

In other words, the expected number of rows that get perturbation is n(1-p). For a domain ∆C, n(1-p)k rows will be expected to lie within the available value range (k ∆C), k[1, 0]. Among total nr rows observed from T’ in the value range (k ∆C), subtracting the n(1-p)k rows, we have the estimation for the number of unperturbed rows. Scaled up by 1/p, we get the total number of original rows (n0), as only a p fraction of rows were retained.

Security and Privacy

f’ = n0/n[n-n0, n0]A = [n-nr, nr]a=Pr(row T) vs. b=Pr(row in perturbed

table T’)Privacy breach, security threshold

> a / bb b’ (sketch does not help to distinguish

the cases)Server Storage (with a) vs. Client retaining

(with b)

OO Design for DB SystemsInjection, inference

◦RBAC (role based access control)◦Use case

http://www.cs.wcupa.edu/~zjiang/intro_uc.ppt

◦Class design is needed for better maintaining the data ownership http://www.cs.wcupa.edu/~zjiang/DB_OO_design.htm

Non-relational DB◦Activity pattern – prediction of future relation,

e.g., credit card securityNonSQL DB

◦Relations in structure for the use.

27

ModelsDatabase role basedApplication role basedApplication function basedApplication role and function

basedApplication table based

28

Model Based on Database Roles

Application authenticates application users: maintain all users in a table

Each user is assigned a role; roles have privileges assigned to them

A proxy user is needed to activate assigned roles; all roles are assigned to the proxy user

Model and privileges are database dependent

29

30

Implementation in SQL Server:◦Use application roles:

Special roles you that are activated at the time of authorization

Require a password and cannot contain members

◦Connect a user to the application role: overrules user’s privileges

31

Implementation in SQL Server (continued):◦ Connect to database as the proxy user◦ Validate the user name and password ◦ Retrieve the application role name◦ Activate the application role

Great article on app roles:◦ SQL Server Security: Pros and Cons of

Application Roles By Brian Kelley◦ http://www.sqlservercentral.com/articles/

Security/sqlserversecurityprosandconsofapplicationroles/1116/

32

Model Based on Application RolesApplication roles are mapped to

real business rolesApplication authenticates usersEach user is assigned to an

application role; application roles are provided with application privileges (read and write)

33

34

Implementation in SQL Server◦Create a database user◦Connect the application to the

database using this user◦Create stored procedures to perform

all database operations

35

Model Based on Application Functions

Application authenticates usersApplication is divided into

functionsConsiderations:

◦Isolates application security from database

◦Passwords must be securely encrypted

◦Must use a real database user◦Granular privileges require more

effort during implementation

36

37

Model Based on Application Roles and Functions

Combination of modelsApplication authenticates usersApplication is divided into

functionsHighly flexible model

38

39

Model Based on Application TablesDepends on the application to

authenticate usersApplication provides privileges to

the user based on tables; not on a role or a function

User is assigned access privilege to each table owned by the application owner

40

Privileges:◦0 -no access◦1 –read only◦2 – read and add◦3 –read, add, and modify◦4 – read, add, modify, and delete◦5 – read, add, modify, delete, and

admin

41

42

Implementation in SQL Server:◦Grant authorization on application

functions to the end user◦Alter authorization table from the

security model based on database roles; incorporate the table and access columns required to support model

43

Data EncryptionPasswords should be kept

confidential and preferably encrypted

Passwords should be compared encrypted:◦Never decrypt the data◦Hash the passwords and compare

the hashes