Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © 2013 Curt Hill Database Security An Overview with some SQL.

Similar presentations


Presentation on theme: "Copyright © 2013 Curt Hill Database Security An Overview with some SQL."— Presentation transcript:

1 Copyright © 2013 Curt Hill Database Security An Overview with some SQL

2 The DataBase Administrator The security of a DBMS rests with the DBA This person owns the account that has all the power The DBA giveth and the DBA taketh away the permissions When security fails, then the DBA is fired Copyright © 2013 Curt Hill

3 What needs protection? Confidentiality –Only authorized parties are allowed to view material Includes printing and display –Sometimes just revealing the existence of a person/item is a breach of security Integrity –The ability to modify should be rarer than the ability to view Availability –The system can be made available to authorized parties Copyright © 2013 Curt Hill

4 Why? Competitive advantage –We need to protect our corporate data which may be of help to our competitors –Customers trust us with their data Laws –The US has numerous laws concerning who may and who may not access confidential data Copyright © 2013 Curt Hill

5 What Do We Do? Authentication –Force users to login, have good passwords and change them occasionally Restrict access –Permissions or privileges restrict what a particular user may do Encryption –Prevents the database from being accessed outside of the DBMS Logging –Helps to understand breaches Copyright © 2013 Curt Hill

6 Access Control We can restrict what a user may see or do This often focusses around the notion of roles and permissions Like much in the SQL domain, not very standard Copyright © 2013 Curt Hill

7 SQL Server SQL Server believes in roles Each role expresses the relationship a login has to objects Determines what the user may do The notion of a role is to ease the management of a permissions These permissions may be given or taken away from individuals or to every user who has the same role Copyright © 2013 Curt Hill

8 Role types There are: –Predefined roles connected to a particular database –Fixed roles connected to entire server –User created roles which are connected to a particular database A few of these are considered in the next screens Copyright © 2013 Curt Hill

9 Predefined roles db_owner: Members have full access db_datareader: Members can read all data db_datawriter: Members can add, delete, or modify data in the tables db_securityadmin: Members can modify role membership and manage permissions db_bckupoperator: Members can back up the database Copyright © 2013 Curt Hill

10 Fixed roles SysAdmin: Any member can perform any action on the server ServerAdmin: Any member can set configuration options on the server Security Admin: Any member can manage server security DbCreator: Any member can create, alter, drop, and restore databases. BulkAdmin: Any member can run the bulk insert command Copyright © 2013 Curt Hill

11 Assigning Roles Like many things in SQL Server things can be done by the Management Console or by SQL command –Many of the SQL commands in this area have a unique syntax for SQL Server The SQL command is Create Role Copyright © 2013 Curt Hill

12 Creating a role Syntax is: Create Role role_name Authorization user The role_name is the new role User is the user which owns this role –This may be left out (including Authorization) then the current user owns this role This type of role is then connected with database objects Copyright © 2013 Curt Hill

13 Now what? Once roles are created we may give them permissions –The reserved word is Grant With Grant we connect a permission with a user or role Consider the syntax next Copyright © 2013 Curt Hill

14 Simplified Grant Syntax GRANT permission [ ( column [,...n ] ) ] [,...n ] [ ON securable ] TO principal [,...n ] [ WITH GRANT OPTION ] [ AS principal ] Where –Permission is what they are able to do –Securable may be a table, database, stored procedure among others –Principal is a login or role Copyright © 2013 Curt Hill

15 Permissions The permissions depend on the object considered For a table or view they include: DELETE, INSERT, REFERENCES, SELECT, UPDATE For a stored procedure only EXECUTE For a database there are many –One for most actions Copyright © 2013 Curt Hill

16 An Example Consider the following: Create Role TestRole Grant SELECT ON Faculty TO TestRole Grant Update ON Faculty TO TestRole Permissions not granted are unavailable The table may need to be qualified by the database Copyright © 2013 Curt Hill

17 Deny Blocks a permission Usually used to remove a single permission Syntax is similar to Grant Example: Deny Update ON Faculty TO TestRole Copyright © 2013 Curt Hill

18 Revoke Removes the permission specified by a Grant or Deny Similar syntax Example Revoke Select on Faculty from TestRole Copyright © 2013 Curt Hill

19 Oracle Not the number 1 database without cause Has all the capabilities of the normal database Implements: –Create Role –Grant –Deny –Revoke Although not quite the same syntax Copyright © 2013 Curt Hill

20 Guidelines Restrict permissions to those who actually need them –Common mistake is for too many users to have excessive privileges Web access is usually through a predefined login –Secure it to prevent issues Copyright © 2013 Curt Hill

21 Injection Attacks A common problem is that user input will be used to construct a SQL command An injection attack is using cleverly crafted bad input to subvert the process Consider the next screen for an example Copyright © 2013 Curt Hill

22 Normally Suppose that we have a web form and it asks for an ID that is to come from the faculty table Suppose we read that value into a JavaScript variable and then build a JavaScript string with it: stmt = ‘select * from faculty where naid = ‘ + input Usually the user types in a number and stmt contains: select * from faculty where naid = 512 Copyright © 2013 Curt Hill

23 Attack! In the above you get zero or one rows depending on whether 512 may be found Instead of typing in 512 a hacker types in: 1 or 1 = 1 Now the statement becomes: select * from faculty where naid = 1 or 1 = 1 The whole table is the result Copyright © 2013 Curt Hill

24 Defense The code in the web page cannot just blindly insert user input characters into a SQL statement First the user input characters must be examined Suspicious or unexpected characters need to be removed and the query rejected Some systems have functions to automate this Copyright © 2013 Curt Hill

25 Statistical Databases The Census Bureau, among others, maintains several statistical databases –These are generally publicly available The purpose is to provide for demographic research –Useful for governmental and market research The inherent goal is that no personal information may be observed Copyright © 2013 Curt Hill

26 Attacking It is possible to make a query that shows us an individual’s personal data Find the average salary of all the people who have a title of professor at VCSU who started in 1995 and a degree in CS –This is me and me only The inherent confidentiality requirement has been violated Copyright © 2013 Curt Hill

27 Defense The above is an inference attack –Attempt to get data on an individual from a statistical database The usual approach to an inference attack is to restrict queries that end up with just a few individuals Make queries return a threshold number’s worth of individuals before release Copyright © 2013 Curt Hill


Download ppt "Copyright © 2013 Curt Hill Database Security An Overview with some SQL."

Similar presentations


Ads by Google