Download presentation
Presentation is loading. Please wait.
Published byGary Welch Modified over 8 years ago
1
Database Security and Authorization Introduction to DB Security Access Controls Database Security and the DBA Discretionary Access Control The privileges at the account/relation levels Granting and revoking of relation privileges Views and Security Propagation of Privileges Role-Based Authorization Mandatory Access Control Access Control for Multilevel Security Multilevel Relations Discretionary Access Control vs. Mandatory Access Control Introduction to Statistical Database Security Summary Course outlines
2
2 Introduction to DB Security Confidentiality: Users should not be able to see things they are not supposed to. E.g., A student can’t see other students’ grades. Integrity: Users should not be able to modify things they are not supposed to. E.g., Only instructors can assign grades. Availability: Users should be able to see and modify things they are allowed to. To protect databases against these types of threats four kinds of countermeasures can be implemented: Access control Inference control Flow control Encryption
3
3 Access Controls A DBMS typically includes a database security and authorization subsystem that is responsible for ensuring the security portions of a database against unauthorized access. Database security terminologies: A security policy specifies who is authorized to do what. A security mechanism allows us to enforce a chosen security policy. Two types of database security mechanisms: Discretionary security mechanisms - access control Mandatory security mechanisms - access control The security mechanism of a DBMS must include provisions for restricting access to the database as a whole This function is called access control and is handled by creating user accounts and passwords to control login process by the DBMS.
4
4 Database Security and the DBA The database administrator (DBA) is the central authority for managing a database system. The DBA is responsible for the overall security of the database system. The DBA’s responsibilities include: granting privileges to users who need to use the system classifying users and data in accordance with the policy of the organization The DBA has a DBA account in the DBMS Sometimes these are called a system or superuser account These accounts provide powerful capabilities such as: 1.Account creation 2.Privilege granting 3.Privilege revocation 4.Security level assignment Action 1 is access control, whereas 2 and 3 are discretionary and 4 is used to control mandatory authorization
5
5 User Accounts, and Database Audits If a person or group of persons need to access a database system, the individual or group must first apply for a user account. The role of DBA to create a new login (account id and password) for the user Whenever a database access is needed, the user must log in to the DBMS by entering: account id and password. Database audit The DBMS must also keep track of all operations on the database that are applied by a certain user throughout each login session. If any tampering with the database is suspected, a database audit is performed A database audit consists of reviewing the log (audit trail) to examine all accesses and operations applied to the database during a certain period.
6
6 Discretionary Access Control The typical method of enforcing discretionary access control in a database system is based on: the granting and revoking access rights or privileges for objects (tables and views). Creator of a table or a view automatically gets all privileges on it. Types of Discretionary Privileges The account level: At this level, the DBA specifies the particular privileges that each account holds independently of the relations in the database. The relation level (or table level): At this level, the DBA can control the privilege to access each individual relation or view in the database.
7
7 The privileges at the account level The privileges at the account level apply to the capabilities provided to the account itself and can include: the CREATE SCHEMA or CREATE TABLE privilege, to create a schema or base relation; the CREATE VIEW privilege; the ALTER privilege, to apply schema changes such adding or removing attributes from relations; the DROP privilege, to delete relations or views; the MODIFY privilege, to insert, delete, or update tuples; and the SELECT privilege, to retrieve information from the database by using a SELECT query. Types of Discretionary Privileges
8
8 Privileges applied at the relation level This includes base relations and virtual ( view ) relations. The granting and revoking of privileges generally follow an authorization model for discretionary privileges known as the access matrix model where Types of Discretionary Privileges Í The rows of a matrix M represents subjects (users, accounts, programs) Í The columns represent objects (relations, records, columns, views, operations). Í Each position M(i,j) in the matrix represents the types of privileges (read, write, update) that subject i holds on object j.
9
9 Granting and revoking of relation privileges To control the granting and revoking of relation privileges, each relation R in a database is assigned and owner account, which is typically the account that was used when the relation was created in the first place. The owner of a relation is given all privileges on that relation. In SQL2, the DBA can assign and owner to a whole schema by creating the schema and associating the appropriate authorization identifier with that schema, using the CREATE SCHEMA command. The owner account holder can pass privileges on any of the owned relation to other users by granting privileges to their accounts.
10
10 GRANT Command (in SQL) The following privileges can be specified: SELECT (retrieval or read) privilege on R: Gives the account retrieval privilege. this gives the account the privilege to use the SELECT statement on R. MODIFY privileges on R: This gives the account the capability to modify tuples of R. In SQL this privilege is further divided into UPDATE, DELETE, and INSERT privileges to apply the corresponding SQL command to R. In addition, both the INSERT and UPDATE privileges can specify that only certain attributes can be updated by the account. REFERENCES privilege on R: define foreign keys (in other tables) that refer to this column. This gives the account the capability to reference relation R when specifying integrity constraints. The privilege can also be restricted to specific attributes of R. Discretionary Access Control
11
11 GRANT and REVOKE of Privileges GRANT privileges ON object TO users GRANT INSERT, SELECT ON Sailors TO Horatio Horatio can query Sailors or insert tuples into it. GRANT DELETE ON Sailors TO Yuppy WITH GRANT OPTION Yuppy can delete tuples, and also authorize others to do so. GRANT UPDATE (rating) ON Sailors TO Dustin Dustin can update (only) the rating field of Sailors tuples. GRANT SELECT ON ActiveSailors TO Guppy, Yuppy This does NOT allow the ‘uppies to query Sailors directly! REVOKE: mechanism for revoking privileges. When a privilege is revoked from X, it is also revoked from all users who got it solely from X. Security Specification in SQL
12
12 Views and Security Views can be used to present necessary information (or a summary), while hiding details in underlying relation(s). create view cust-loan as select branchname, customer-name from borrower, loan where borrower.loan-number = loan.loan-number Together with GRANT/REVOKE commands, views are a very powerful access control tool. Creator of view has a privilege on the view if (s)he must have the SELET privilege on all underlying tables (involved in the view definition). If the creator of a view loses the SELECT privilege on an underlying table, the view is dropped! If the creator of a view loses a privilege held with the grant option on an underlying table, (s)he loses the privilege on the view as well; so do users who were granted that privilege on the view! GRANT/REVOKE on Views The mechanism of views is an important discretionary authorization mechanism. Security to the Level of a Field! Can create a view that only returns one field of one tuple. (How?) Then grant access to that view accordingly.
13
13 Propagation of Privileges Propagation of Privileges using the GRANT OPTION If a user has a privilege with the GRANT OPTION, can pass privilege on to other users (with or without passing on the GRANT OPTION). GRANT privileges ON object TO users [WITH GRANT OPTION] Whenever the owner A of a relation R grants a privilege on R to another account B, privilege can be given to B with or without the GRANT OPTION. If the GRANT OPTION is given, this means that B can also grant that privilege on R to other accounts. Suppose that B is given the GRANT OPTION by A and that B then grants the privilege on R to a third account C, also with GRANT OPTION. In this way, privileges on R can propagate to other accounts without the knowledge of the owner of R. If the owner account A now revokes the privilege granted to B, all the privileges that B propagated based on that privilege should automatically be revoked by the system.
14
14 Role-Based Authorization In SQL-92, privileges are actually assigned to authorization ids, which can denote a single user or a group of users. In SQL:1999 (and in many current systems), privileges are assigned to roles. Roles can then be granted to users and to other roles. Reflects how real organizations work. Roles permit common privileges for a class of users can be specified just once by creating a corresponding “role” Privileges can be granted to or revoked from roles, just like user Examples: create role teller create role manager grant select on branch to teller grant update ( balance ) on account to teller grant all privileges on account to manager grant teller to manager grant teller to alice, bob grant manager to avi
15
15 Mandatory Access Control The discretionary access control techniques of granting and revoking privileges on relations has traditionally been the main security mechanism for relational database systems. This is an all-or-nothing method In many applications, and additional security policy is needed that classifies data and users based on security classes. This approach as mandatory access control, would typically be combined with the discretionary access control mechanisms. The mandatory access control Based on system-wide policies that cannot be changed by individual users. Each DB object is assigned a security class. Each subject (user or user program) is assigned a clearance for a security class. Rules based on security classes and clearances govern who can read/write which objects. Most commercial systems do not support mandatory access control. Versions of some DBMSs do support it; used for specialized (e.g., military) applications.
16
16 Access Control for Multilevel Security The commonly used model for multilevel security, known as the “Bell-LaPadula” model Bell-LaPadula features: subjects (user, account, program) objects (relation, tuple, column, view, operation) security classes: Top secret (TS), secret (S), confidential (C), unclassified (U), With TS > S> C > U Each object and subject is assigned a class. Subject S can read object O only if class(S) >= class(O) (Simple Security Property) Subject S can write object O only if class(S) <= class(O) (*-Property)
17
17 Multilevel Security in practice - Intuition Consider the following scenario: Dick creates table “Horsie” and gives INSERT privileges to Justin (who doesn’t know about this). Dick modifies the code of an application program used by Justin to additionally write some secret data to table Horsie. Now, Justin can see the secret info. Consequently, under Discretionary access control such case is Qualified Trojan horse problem. Discretionary control has some flaws, such a case could be solved by apply a Mandatory Control Idea is to ensure that information can never flow from a higher to a lower security level. E.g., If Dick has security class C, Justin has class S, and the secret table has class S: Dick’s table, Horsie, has Dick’s clearance, C. Justin’s application has his clearance, S. So, the program cannot write into table Horsie. The mandatory access control rules are applied in addition to any discretionary controls that are in effect. Mandatory Control
18
18 Multilevel Relations To incorporate multilevel security notions into the relational database model, it is common to consider attribute values and tuples as data objects. Hence, each attribute A is associated with a classification attribute C in the schema, and each attribute value in a tuple is associated with a corresponding security classification. In addition, in some models, a tuple classification attribute TC is added to the relation attributes to provide a classification for each tuple as a whole. Hence, a multilevel relation schema R with n attributes would be represented as R(A 1,C 1,A 2,C 2, …, A n,C n,TC) where each Ci represents the classification attribute associated with attribute A i. Case study Users with S and TS clearance will see both rows; a user with C will only see the 2nd row; a user with U will see no rows. If user with C tries to insert : Allowing insertion violates key constraint Disallowing insertion tells user that there is another object with key 101 that has a class > C! Problem resolved by treating class field as part of key. CBrownPinto102 SRedSalsa101 classcolorbnamebid
19
19 Discretionary Access Control vs. Mandatory Access Control Discretionary Access Control (DAC): DAC policies are characterized by a high degree of flexibility, which makes them suitable for a large variety of application domains. The main drawback of DAC models is their vulnerability to malicious attacks, such as Trojan horses embedded in application programs. Mandatory policies: By contrast, mandatory policies ensure a high degree of protection in a way, they prevent any illegal flow of information. Mandatory policies have the drawback of being too rigid and they are only applicable in limited environments. In many practical situations, discretionary policies are preferred because they offer a better trade-off between security and applicability.
20
20 Introduction to Statistical Database Security (1/2) Statistical databases: are used mainly to produce statistics on various populations. may contain confidential data on individuals, which should be protected from user access. Users are permitted to retrieve statistical information on the populations, such as averages, sums, counts, maximums, minimums, and standard deviations. Statistical database security techniques must prohibit the retrieval of individual data. Notions: A population is a set of tuples of a relation (table) that satisfy some selection condition. Statistical queries involve applying statistical functions to a population of tuples.
21
21 For example, we may want to retrieve the number of individuals in a population or the average income in the population. However, statistical users are not allowed to retrieve individual data, such as the income of a specific person. Security techniques must prohibit the retrieval of individual data. This can be achieved by prohibiting queries that retrieve attribute values and by allowing only queries (called statistical queries) that involve statistical aggregate functions such as COUNT, SUM, MIN, MAX, AVERAGE, and STANDARD DEVIATION. It is DBMS’s responsibility to ensure confidentiality of information about individuals, Provision of privacy protection of users in a statistical database is paramount. Observation In some cases such as a population consisting of a small number of tuples, it is possible to infer the values of individual tuples from a sequence statistical queries. Introduction to Statistical Database Security (1/2)
22
22 Summary Three main security objectives: secrecy, integrity, availability. DB admin is responsible for overall security. Designs security policy, maintains an audit trail, or history of users’ accesses to DB. Two main approaches to DBMS security: discretionary and mandatory access control. Discretionary control based on notion of privileges. Mandatory control based on notion of security classes. Statistical DBs try to protect individual data by supporting only aggregate queries, but often, individual information can be inferred.
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.