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 Security is important not only at the database level, but the entire database application. Breaches can happen at any of these levels. 2

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

Why shouldn’t you give “ global privileges ” to user accounts? 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 option  Select/insert/update privileges on the DB 5

User types (log-in user and other categories of user types) 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

Once authenticated, switch to DB user based on category Give permissions based on user type (no more, no less!) 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

Global / too many permissions gives greater abilities to attackers 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

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

https://en.wikipedia.org/wiki/Role-based_access_control 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. 11  Must grant each user the correct role(s)

https://en.wikipedia.org/wiki/Discretionary_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 owns, 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/Mandatory_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

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 Give GRANT { ALL PRIVILEGES | privilege-list } authorization ON { object-name } TO { PUBLIC | user-list | role-list } [WITH GRANT OPTION]; Retract REVOKE { ALL PRIVILEGES | privilege-list } authorization ON object-list FROM { PUBLIC | user-list | role-list } [CASCADE | RESTRICT];  Next: See “part2” for GRANT command >>>>>>>