Advanced DBMS: CISY 423 Department f Cmputer Infrmatin Systems KEMU Database Security OBJECTIVES Database Security and Authrizatin Database Users Creating Users/Accunts in cmmercial DBMS Discretinary Access Cntrl Subject-Based Security Object-Based Security Mandatry Access Cntrl The SQL GRANT and REVOKE Statements Security under Shared MS Access databases Database Security and Authrizatin Three very brad issues in DB security: 1. Legal and Ethical cnsideratins - Wh has the right t read What infrmatin? 2. Plicy issues - Wh shuld enfrce security (gvernment, crpratins)? 3. System-Level issues - Where shuld security be enfrced in the system and Hw? As database practitiners, we must prvide a means f preventing unauthrized use f data in a database. Three areas are cnsidered: 1. Access Cntrl: Wh shuld be allwed access t which databases. This is typically enfrced using system level accunts with passwrds. 2. We will investigate: 1. Discretinary Access Cntrl 2. Mandatry Access Cntrl 3. Authrizatin: fr the purpses f: Reading Data - Such as reading anther emplyee's salary (using a SELECT statement fr example). Writing Data - Such as changing a value in a database (using UPDATE r DELETE). 4. Statistical Infrmatin: Enfrcing wh shuld be allwed access t infrmatin derived frm underlying databases (Census example). Here we will fcus n the Authrizatin and Access cntrl aspects.
Database Users Mst cmmercial DBMS include a security subsystem that manages access t schemas and their cntents There is a ntin f a user that pssesses sme authrity t access and manipulate schema bjects. A special user called the System Manager, System Administratr r Database Administratr (DBA) pssesses the authrity t perfrm any peratins n any bject. Oracle Sybase DBMS SYSTEM sa MS SQL-Server sa DB2 DBA user db2admin r db2inst (the instance wner) This is similar t the superuser in an perating system (rt in UNIX r administratr in Windws NT/2000) Respnsibilities f the DBA include: Creating accunts (adding users) Granting and revking privileges Assigning security clearance levels (in MAC) Befre a user can access database bjects, they must be authenticated in the DBMS. Typically, this invlves supplying a valid user name and passwrd t the DBMS. All accunt infrmatin is stred within the DBMS Anther ptin is using an perating system level lgin t authenticate a user t the DBMS. e.g., if yu have been authenticated by the OS n the server, then yu are OK t use the DBMS. A third ptin is t use a distributed authenticatin mechanism such as Kerbers r sme frm f Directry Services (e.g., Nvell r LDAP) t prvide a "single lgin" fr all netwrk, OS and DBMS services. Once a user has been authenticated t the DBMS, a lg-in sessin is established. The sessin remains in effect until it is terminated by the user r by sme kind f failure (DBMS, server, netwrk, client) All majr DBMS allw auditing f lg-in sessins (date/time, username, client inf (IP address, applicatin, etc.)) Creating Users/Accunts in cmmercial DBMS 1. MS SQL Server Can use the perating system (NT) t authenticate Add users with the sp_addlgin prcedure sp_addlgin @lginame= 'newlgin', @passwd= 'newpasswrd', @defdb= 'database', @deflanguage= 'language', @sid= 'sid', @encryptpt= 'encryptin_ptin'
Where @defdb is the default database t be used, @deflanguage is the default language character set t use, @sid is a unique system identifier (aut generated if nt given) and @encryptpt is an ptin t encrypt the passwrd befre it is stred in the system tables. 2. SQL Server Prvides a nice graphical user interface (Enterprise Manager) t create users amng ther things: 3. Oracle In Oracle, the CREATE USER statement can be used t create new users: CREATE USER newuser IDENTIFIED BY newpasswrd DEFAULT TABLESPACE tablespace TEMPORARY TABLESPACE temptablespace QUOTA xm n tablespace; Where tablespace is an existing tablespace in the DBMS, temptablespace is an existing temprary tablespace in the DBMS, and x is sme number f megabytes f quta t allcate t the user.
After the user is created, CONNECT and CREATE SESSION privileges must be granted: GRANT CONNECT, CREATE SESSION TO newuser; T remve a user, the DROP USER statement can be emplyed. If the user has tables r ther bjects in their schema, the DROP USER username CASCADE statement can be emplyed. Oracle als prvides a graphical user interface t create users (part f the Oracle Enterprise Manager):
Discretinary Access Cntrl Typically security fr database authrizatin purpses is implemented in an authrizatin subsystem that mnitrs every transactin in the database. This is part f the DBMS. Authrizatin rules take int accunt a few main ideas: 1. Subjects: Individuals wh perfrm sme activity n the database. Might include specific peple (e.g., user tannd n cis.kemu.edu) r a grup f users (faculty n cisnet). 2. Objects: Database units that require authrizatin in rder t manipulate. Database units might include an entire table, specific clumns in a table, specific rws in a table, etc. 3. Actins: Any actin that might be perfrmed n an bject by a subject. Fr example: Read, Mdify, Insert, Write, Delete, Grant (the ability t grant authrizatins t thers) 4. Cnstraint: A mre specific rule regarding an aspect f the bject and actin. These elements are cmmnly cmbined int an authrizatin table Subject Object Actin Cnstraint Ed Emplyee Read Nne Ed Emplyee Insert Nne Ed Emplyee Mdify Nne Ed Emplyee Grant Nne Bill Emplyee Read Salary < 50,000 Sally PurchaseOrder Insert Ttal < 1,000 Sally PurchaseOrder Mdify Ttal < 1,000 PayrllClerks Emplyee Read Nne What happens as the number f subjects and bjects grws? Presently, n cmmercial DBMS supprts this level f authrizatin flexibility. A DBMS supprts sme basic authrizatin mdels. Applicatin develpers must prvide mre cmplex cnstraint enfrcement. Subject-Based Security Subjects are individually defined in the DBMS and each bject and actin is specified. Fr example, user SMITH (a Subject) has the fllwing authrizatins: Objects Actins EMPLOYEES ORDERS PRODUCTS... Read Y Y Y...
Insert N Y N... Mdify N Y Y... Delete N N N... Grant N N N... Object-Based Security Objects are individually defined in the DBMS and each subject and actin is specified. Fr example, the EMPLOYEES table (an Object) has the fllwing authrizatins: Subjects Actins SMITH JONES GREEN DBA... Read Y Y N Y... Insert N N N Y... Mdify N N N Y... Delete N N N Y... Grant N N N Y... Mandatry Access Cntrl Used in gvernment and ther high-security envirnments. Als called: Multilevel security (MLS) Objects are given a security class r level. Fr example: Tp-Secret Secret Public Subjects are given a security clearance: Tp-secret, Secret, Public Tw main rules are enfrced: 1. N subject can read an bject at a higher level. e.g., a subject with Secret clearance may nt read an bject at Tp-secret level. 2. N subject can write an bject at a lwer level (N write-dwn). e.g., a subject with tp-secret clearance may nt write a secret dcument. In a DBMS, an MLS can be implemented by classifying every clumn, table, etc. and then supplying clearances t each user. Fr example: Trusted Oracle Be aware f cvert channels. Fr example: Salaries f emplyees making mre than $50,000 are secret Salaries f thers are public A user with public clearance pses a query t the database. Any recrds that d nt appear indicate emplyees wh make mre than $50,000.
The SQL GRANT and REVOKE Statements SQL prvides tw main statements fr setting up authrizatin. GRANT is used t grant an actin n an bject t a subject. GRANT actin1, actin2... ON bject1, bject2,... TO subject1, subject2... Anther ptin f the GRANT statement is WITH GRANT OPTION. This allws the grantee t prpagate the authrizatin t anther subject. Fr example, assume we have a database with Tables: emplyees, departments, rders, prducts Users: smith, jnes, green, dba GRANT INSERT, DELETE, UPDATE, SELECT ON emplyees, departments TO smith ; GRANT INSERT, SELECT ON rders TO smith ; GRANT SELECT ON prducts TO smith ; GRANT SELECT ON emplyees, departments TO jnes ; GRANT INSERT, DELETE, UPDATE, SELECT ON emplyees, departments, rders, prducts TO dba WITH GRANT OPTION ; Grants can als be dne n specific clumns in a table: GRANT SELECT ON prducts TO jnes ; GRANT UPDATE ON prducts (price) TO jnes ; If n GRANT statement is issued, it is assumed that n authrizatin is given (e.g., user GREEN abve). REVOKE is used t revke authrizatins frm subjects. REVOKE actin1, actin2,... ON bject1, bject2,... FROM subject1, subject2,... If Ms. Smith leaves the cmpany, then we shuld: REVOKE INSERT, DELETE, UPDATE, SELECT ON emplyees, departments FROM smith ; REVOKE INSERT, SELECT ON rders FROM smith ; REVOKE SELECT ON prducts FROM smith ; Many RDBMS have an ALL PRIVILEGES ptin that will revke all f the privileges n an bject frm a subject:
REVOKE ALL PRIVILEGES ON emplyees, departments, rders, prducts FROM smith ; Nte: Oracle nly supprts granting a set f privileges/actins n ne bject t ne subject within a single statement. GRANT actin1, actin2... ON bject TO subject ; We can grup users int ROLES r GROUPS and grant r revke privileges frm the cllectin. In Oracle we can d smething like: CREATE ROLE purchasing_clerks; GRANT SELECT ON vendrs TO purchasing_clerks; GRANT SELECT, INSERT, UPDATE, DELETE ON purchase_rders TO purchasing_clerks; GRANT SELECT, INSERT, UPDATE, DELETE ON p_items TO purchasing_clerks; GRANT purchasing_clerks TO smith; GRANT purchasing_clerks TO jnes; GRANT purchasing_clerks TO green; Security under Shared MS Access databases Here is a cmprehensive guide t hw MS Access accmplishes this: http://supprt.micrsft.cm/default.aspx?scid=/supprt/access/cntent/secfaq.asp