DATABASE SECURITY CS4750 Database Systems Prof. Nada Basit Email: - - PowerPoint PPT Presentation

DATABASE SECURITY

CS4750 – Database Systems

• Prof. Nada Basit

Email: basit@virginia.edu Fall 2020 University of Virginia

1

Levels of DB Security

 There are 6 levels that impact database security  Database Level

– database users and authorization

 Application Level

– information management and processing

 Operating System Level

– data storage and protection

 Network Level

– data transmission

 Physical Level

– computer equipment protection

 Human Level

– social engineering protection

2

Security is important not only at the database level, but the entire database application. Breaches can happen at any of these levels.

Question:

 Which DB level is the cause of the most DB break-ins?  Database Level  Application Level  Operating System Level  Network Level  Physical Level  Human Level  Think about it as we go through this material

3

Database Level

4

Database Level

 If you are a super-user on your own database, and you have the

grant permission, you are able to grant permissions onto your database for other users

 Can even grant permissions on certain tables (or cols/rows)  General user:  No global privileges  But global on a particular DB (their own) including the grant

• ption

 Select/insert/update privileges on the DB

5

Why shouldn’t you give “global privileges” to user accounts?

Database Level

 Consider the classification of users (E.g. TA application system)  What is a classification of user that would use that system?

Student/TA/prof

 There is, however, always another type of classification,

especially when you have a log in system

 A user that only knows how to read the login table, and only

knows how to read username and password

 That is the user that most people are going to try to break

into

 That is the user automatically available to anyone that is

trying to log in

 Rule of thumb: if you are going to have a log in system with

username/password you should have a separate user, that is ONLY going to read that login table. That’s it. That user does not need any privileges to do anything else – just reads the login table. Once login is successful, you should change DB users based on the category of user that you are using

6

User types (log-in user and other categories of user types)

Database Level

 Somewhere in the DB your username exists, along with your

password

 When you log in, it gets your user type (e.g. professor, student, etc)  In some php file…  if type == professor  Dbuser = CS4750abc3dAlpha  Change your DB user based on the category  All students have the same db user because they are all part of

the same classification

 Think of the different permissions a student has vs. professor  However, neither should have global permissions (i.e. neither should

be able to drop a table or alter the schema in any way)

 Paying attention to privileges is important, helps prevent against SQL

injection attacks because a drop all tables command will fail!

7

Once authenticated, switch to DB user based on category Give permissions based on user type (no more, no less!)

Database Level

 However what happens is people create a DB user that has global

permissions and then use that same user in every aspect and in every part of their program. Running as super-user

 If someone breaks in, then that attacker has the ability to do

anything and everything! That is bad!

8

Global / too many permissions gives greater abilities to attackers

Access Control Policy

Access control – identify permissions individuals can have/do There are three variations of access control:

 RBAC

(Role-Based Access Control)

 Group-level permission – “what can users of this role do”  Permissions per role; users are only granted role  MAC

(Mandatory Access Control)

 Classification or privacy level  Permissions per classification  DAC

(Discretionary Access Control)

 Personal permission – “who has access, what he/she can do”  Permissions per resource; change often  Least restrictive

9

RBAC – Role-Based Access Control

 In computer systems security, RBAC is an approach to restricting

system access to authorized users

 It is used by the majority of enterprises with more than 500

employees, and can (also) implement mandatory access control (MAC) or discretionary access control (DAC)

 [Although RBAC is different from MAC and DAC access control

frameworks, it can enforce these policies without any complication.]

 When a system implements both MAC and DAC simultaneously,

DAC may refer to one category of access controls that subjects can transfer among each other, and MAC may refer to a second category of access controls that imposes constraints up on the first

10

https://en.wikipedia.org/wiki/Role-based_access_control

RBAC – Role-Based Access Control

 Privileges/limitations defined by roles/job responsibilities  A policy neutral access control mechanism defined around roles and

• privileges. Users with the same role have the same privileges

 Privileges are not assigned to users directly (rather, to their role)  Permissions/privileges per role are normally static  Typically have very few roles, centrally administered, and thus easy to

manage

 Commonly used by large organizations such as commercial and

government organizations.

 Must grant each user the correct role(s)

11

https://en.wikipedia.org/wiki/Role-based_access_control

DAC – Discretionary Access Control

 DAC a type of access control that allows people to manage the

content they own. The controls are discretionary in the sense that…

 A business owner is responsible for deciding who are allowed to

do what on which part of the database

 A data owner can manage the content they own – decide who has

access, add or remove people from the list, and pass the permission to other users (unless restrained by MAC)

 It allows people to revoke or forward privileges easily and

immediately

12

https://en.wikipedia.org/wiki/Discretionary_access_control

DAC – Discretionary Access Control

 Since an individual has complete control over any objects he/she

• wns, DAC is the least restrictive compared to the other access

control policy

 Permissions given to an individual are inherited into other programs

they use, potentially leading to malware being executed without the end user being aware of it

 Permissions per resource are often changed

13

https://en.wikipedia.org/wiki/Discretionary_access_control

MAC – Mandatory Access Control

 MAC a type of access control that is centrally controlled by a security

policy administrator. It constrains the ability of a user to access or generally perform some sort of operation on an object.

 Typically viewed as a classification or privacy level  Users do not have the ability to override the policy (either

accidentally or intentionally.) For example, a user cannot grant access to a restricted table to another user

 Policy administrators to implement organization-wide security

• policies. This allows security administrators to define a central policy

that is guaranteed (in principle) to be enforced for all users

 Not used much in database system nowadays

14

https://en.wikipedia.org/wiki/Mandatory_access_control

Choosing Access Control

 If you have highly confidential or sensitive information on your

business platform, use MAC or RBAC

 If you need to allow certain people to enter, DAC is simplest and

most popular.

 However, if you need a lot of high security, DAC is not a good option

since it is the least restrictive and privileges can inherit and transfer.

15

Database Level

 Encryption  An option inside of a database  MySQL has hashing methods built into it  You can encrypt but you may have to worry about overhead  Only thing that really needs to be encrypted in the DB is the

passwords

 In fact, they should be hashed. Store the hash of the password,

not the password itself

 When you log into MySQL it does a select on the user table where

username=x and password=hash(y) and host like ‘%something%’

 If have more than one match returned – it’ll always take the top

tuple (order matters in this case)

16

Granting privileges

 We talked about various kinds of access control and privileges being

granted/revoked

 So, how do we grant privileges/authorization?  Can use SQL and the “GRANT” command

17

SQL Data Control Language

 Authorization sublanguage to grant privileges to, and revoke

privileges from, users

 Privilege = action (such as creating, executing, reading, updating,

deleting) that a user is permitted to perform on a database object

 Next: See “part2” for GRANT command >>>>>>>

GRANT { ALL PRIVILEGES | privilege-list } ON { object-name } TO { PUBLIC | user-list | role-list } [WITH GRANT OPTION];

Give authorization Retract authorization

REVOKE { ALL PRIVILEGES | privilege-list } ON

• bject-list

FROM { PUBLIC | user-list | role-list } [CASCADE | RESTRICT];

SQL Data Control Language

 Authorization sublanguage to grant privileges to, and revoke

privileges from, users

 Privilege = action (such as creating, executing, reading, updating,

deleting) that a user is permitted to perform on a database object

 Next: See “part2” for GRANT command >>>>>>>

GRANT { ALL PRIVILEGES | privilege-list } ON { object-name } TO { PUBLIC | user-list | role-list } [WITH GRANT OPTION];

Give authorization Retract authorization

REVOKE { ALL PRIVILEGES | privilege-list } ON

• bject-list

FROM { PUBLIC | user-list | role-list } [CASCADE | RESTRICT]; Example: GRANT SELECT, UPDATE ON abc1x.customer TO ‘abc1x_a’@’%’; user.<table> -- permissions to user abc1x_a on table customer % -- indicates the host (use wildcard to connect to any host. Format: accountName@hostName)

Database Level (Summary)

Database Privileges

 Read – read, but not modify  Insert – add new, but no changes  Update – modify, but no delete  References – allowed to create foreign keys  Delete – delete rows  Index – create and delete indices – structure for performance enhancing  Resources – create relations  Alteration – add or delete attributes  Drop – delete relations

20

Database Level (Summary)

 Grant – ability to grant privileges  Encryption of actual data is good, but not enough  Only grant enough privileges to a user to allow them to do their job  Create admin users for admin duties, application users for each

application

 Next: See “part3” for Application Level >>>>>>>

21