|
|
|
- Steven Mosley
- 10 years ago
- Views:
Transcription
1 Database Security Sabrina De Capitani di Vimercati, Dip. Elettronica, Universita di Brescia, Brescia, Italy Pierangela Samarati, Dip. di Tecnologie dell'informazione, Universita di Milano, Crema, Italy Sushil Jajodia, Dept. of Information & Software Engineering, George Mason University, Fairfax, VA Introduction All organizations public, governmental or private, small or large depend on computerized information systems for carrying out their daily activity. At the heart of each such information system, there is a database. At a very general level, we can dene a database as a persistent collection of related data, where data are facts that have an implicit meaning. For instance, an employee's name, social security number, or date of birth are all facts that can be recorded in a database. Typically, a database is built to store logically interrelated data representing some aspects of the real world, which must be collected, processed, and made accessible to a given user population. The database is constructed according to a data model which denes the way in which data and interrelationships between them can be represented. The collection of software programs that provide the functionalities for dening, maintaining, and accessing data stored in a database is called a database management system (DBMS). A database can be seen at dierent abstraction levels. Typically a three-level view is adopted (see Figure 1) containing an internal level, describing the physical storage of the database; a conceptual (or logical level) providing the users with a high level description of the real world that the database represents; and an external level describing the views that dierent users or applications have on the stored data. The internal level maps the logical objects supported by the data model to the physical objects (les) of the underlying operating system (see Figure 2). Beside access and processing functionalities, each DBMS must also provide security functionalities to ensure the secrecy, integrity, and availability of the stored data [3]. Providing secrecy means The work of Sabrina De Capitani di Vimercati and Pierangela Samarati was supported in part by the European Community within the FASTER Project in the Fifth (EC) Framework Programme under contract IST
2 ensuring that data will not be disclosed to unauthorized users. Providing integrity means ensuring that data will not be modied in an unauthorized or improper way. In particular, integrity ensures that the stored data correctly reect the real world. Providing availability means ensuring that the database will always be accessible by legitimate users for the accesses they are authorized for. Since ultimately a database is mapped to (i.e., stored as) les of the underlying operating system, one may think that a DBMS does not need to deal with security as security functionalities of the operating system would suce. This is not true, however, since at the operating system level the data interrelationships and their semantics are lost and therefore security restrictions exploiting concepts of the data model cannot be enforced. Some of the dierences between databases and operating systems that make it necessary for a DBMS to support security features are as follows. Protection level A DBMS usually needs to protect data at a ne granularity level (e.g., a record of a le), while an operating system protects data at the le level. Object dierences There is a greater variety of object types in a DBMS than in an operating system. The typical object type in an operating system is a le; in a DBMS there can be relations (tables), tuples (rows within a table), attributes (columns within a table), indexes, metadata, and others. Data interrelationships A database may include many logical objects with complex semantic interrelationships that must be protected. By contrast, the number of physical objects that the operating system protects is less and no semantic interrelationships are supported. Dynamic versus static objects Data objects in a DBMS can be obtained by dynamically aggregating data from dierent physical objects in an operating system. By contrast, les tend to be more static making their protection easier. Lifetime of data The lifetime and frequency of access of data in a DBMS is quite dierent than the lifetime of data stored as les in an operating system. User views of data While in an operating system, users are either granted or denied access to data (les), in a DBMS it is possible to give access to a portion of an object by dening dierent views for dierent users. Because of these dierences, it is clear that some security requirements must be supported by the DBMS itself. Of course, the DBMS can rely on basic security services provided by the 2
3 underlying operating system. Typical security services provided by the operating system that can be exploited by the DBMS are physical security controls, authentication and auditing. Physical security protects againsts intentional or accidental threats, like re or natural disasters. Physical security measures also control the physical access to the computer system on which the database is hosted. Examples of physical measures are the use of locks, security guards, badges, and alarms. Authentication is a means of verifying the identity of a party to another, and is a prerequisite for DBMS security controls to ensure that the correct identity of users is being considered (i.e., users are who they claim to be). The simplest form of authentication is based on the use of passwords: users state their identity with a login identier and provide a secret password. Finally, auditing is the post facto evaluation of a system's activities, whichmust therefore be properly logged. Auditing services can be used to perform o-line analysis to determine possible security violations and to recover the correct state of the database in the case integrity has been compromised. The overall DBMS/OS architecture is depicted in Figure 3. In this chapter, we mainly concentrate on basic security services that are available to users in commercial DBMSs for access control and integrity constraints enforcement. Since these controls cannot cope with Trojan horse attacks, we include a brief description of the multilevel secure DBMSs. We conclude this chapter with a short discussion of the inference problem. 2 Access control policies Access control policies dene the rules according to which access to the database objects is regulated. The most popular class of access control policies is represented by discretionary access control (DAC) policies, where the word discretionary characterizes the fact that users can be given the ability of passing their privileges to others. Discretionary access control policies are based on authorizations rules. An authorization rule states that a subject has the privilege to exercise a given action on a given object. The kind (and granularity) of subjects, objects, and actions that can be referenced in authorizations may be dierent in dierent systems. Subjects Subjects are the entities to which authorizations can be granted. Typically, subjects are users (i.e., identiers corresponding to human entities). User groups can also be dened to which authorizations can be granted; authorizations granted to a group can be enjoyed by all its members. Discretionary access control can be extended with role-based capabilities allowing the denition of roles to which privileges can be granted. Roles are granted to users, and users can dynamically 3
4 activate and deactivate the roles received, thereby turning on and o the corresponding privileges. Intuitively, a role identies a task, and corresponding privileges, that users need to execute to perform organizational activities. While groups are set of users, roles are set of privileges. Note the dierence between groups and roles. Groups are static: users cannot enable and disable group memberships (and corresponding privileges) at their will. By contrast, roles are dynamic and can be activated and deactivated upon explicit request by users. Objects Objects are the entities to be protected. Typically, objects correspond to information container (tables or portion of it) or procedures. In DBMS systems, dierent granularity levels can be supported spanning from the whole database to the single element (e.g., a specic employee's salary) in it. Actions Actions dene the specic operations that subjects can execute on objects. Actions to be supported include the operations corresponding to the basic read, write, delete, create, and execute, which can take on dierent names in relational database systems (for instance, read operations correspond to SELECT actions). Authorizations Authorizations dene which accesses are to be allowed. The simplest form of authorization is a triple (subject,object,action) specifying that subject is authorized to exercise action on object. 3 Relational databases and SQL Since DBMS security constraints can be specied at the logical level (authorizations refer to objects of the data model), we need rst to dene a reference data model. Although dierent models have been proposed in the literature, the relational model is in fact the dominant model and is used in most commercial DBMSs. We therefore limit our discussion to relational DBMSs and the related SQL language. 3.1 Relational databases In the relational model, data are organized as a collection of relations [4]. Intuitively, a relation can be seen as a table; the columns of the table are called attributes and the rows are called tuples. Figure 4 illustrates an example of a relational database composed of two relations, Employee 4
5 and Department, containing information about the employees and the departments of an organization. The corresponding relation schemes, which show the structure of the database, are Employee(name,office,salary,dept) and Department(dept,location,phone,budget). Each relation must have a primary key, that is, a minimal set of attributes such that the relation may not have two distinct tuples with the same values for the key. For instance, with respect to the Employee relation just described, if we expect hat duplicate names can never occur, attribute name can be designated as the primary key. A primary key can also be used to link relations together. As an example, consider the relations in Figure 4. The dept attribute of the Employee relation is said to be a foreign key from the Employee relation to the Department relation, and its values must match those of the primary key dept in the Department relation. Note that the relation containing the primary key and the relation containing the foreign key may be the same. For instance, relation Employee could be extended to include attribute supervisor referencing the relation's primary key name. Primary and foreign keys must satisfy the following integrity constraints. Entity integrity: A primary key can never have null (i.e., undened) value. Referential integrity: If a foreign key of a relation R 1 is the primary key of another relation R 2, then, for each tuple in R 1, the value of the foreign key must be either null or equal to the value of the primary key of a tuple in R 2. Entity integrity guarantees that the value of the primary key can uniquely identify each tuple. Referential integrity guarantees that attributes assume only legitimate values, existing in the real world. For instance, with reference to foreign key dept discussed above, the referential integrity constraint avoids employees from being assigned to a non existent department. 4 SQL privileges An SQL privilege states that a given authorization identier is authorized for a set of actions on a given SQL object. The actions that can be executed on SQL objects are summarized in Figure 5. The specic set of actions applicable to an object depend on the type of the object. For instance, the UPDATE action is applicable to tables, while the EXECUTE action is applicable to routines. Each privilege, which corresponds to the classical notion of an authorization tuple, is represented by a privilege descriptor that includes the following elements: 5
6 the object on which the privilege is granted; the authorization identier of the grantor of the privilege (it is special value SYSTEM for privileges automatically granted to the creator of an object); the authorization identier of the grantee of the privilege; the action that the privilege allows; an indication of whether or not the privilege is grantable to others; an indication of whether or not the privilege has the WITH HIERARCHY OPTION specied (see Section 4.1). An authorization identier can execute all actions allowed by the set of applicable privileges for it. In particular, the set of user privileges for a user identier consists of all privileges dened by the privilege descriptors whose grantee is either that user identier or PUBLIC. Analogously, the set of role privileges for a role name consists of all privileges dened by the privilege descriptors whose grantee is either that role name, PUBLIC, or one of the applicable roles of that role name. 4.1 Privilege management The creator of an object in a database is its owner and can perform any action on the object (the particular cases where the object is a view or a routine are treated in Section 5). Also, it can grant and revoke to others the privileges on the object as well as delegate to others the capability of granting and revoking the privilege (and its administration). Privilege granting Privileges are granted by using the GRANT statement, whose syntax is illustrated in Figure 6. Value ALL PRIVILEGES can be used in place of a specic action to denote all of the actions on <object name> for which the grantor has grantable privilege. If the WITH HIERARCHY OPTION clause is present, then the action must be SELECT and the object must be a table. This clause provides the grantee with SELECT privileges on all subtables (either already existing or that may be dened at a later time) of the table on which the privilege is granted. With the WITH GRANT OPTION clause the grantee receives, beside the privileges, the authority to grant the privilege (with or without grant option) to others. 6
7 As an example, suppose that Alice is the owner of the tables in Figure 4. She can grant any action on these tables to any authorization identier in the SQL environment. A possible sequence of GRANT statements is as follows: By Alice: GRANT UPDATE (salary) ON TABLE Employee TO Bob By Alice: GRANT SELECT ON TABLE Department TO Eve WITH GRANT OPTION By Eve: GRANT SELECT ON TABLE Department TO Dave WITH GRANT OPTION By Eve: GRANT SELECT ON TABLE Department TO Peggy According to these statements, Alice grants the authorization to modify the salary column of the Employee table to Bob. Alice also grants the authorization to retrieve rows of the Department table with the grant option to Eve. Since Eve holds the grant option, she can grant the privilege to others. She grants the SELECT privilege on Department to Dave and to Peggy. The grant option associated with the grant statement for Dave allows him to further propagate the privilege. Privileges granted through grant statements are represented by privilege descriptors as discussed in Section 4. The fact that a privilege descriptor is used to allow the granting of another descriptor (as in the case where Eve grants the privilege to Dave and Peggy) introduces a dependency relationship between descriptors. A privilege descriptor p 2 is said to directly depend on a privilege descriptor p 1 if all the following conditions hold: i) the privilege represented by p 1 is grantable; ii) p 1 and p 2 have the same action and object; and iii) the grantee of p 1 is either the same as the grantor of p 2 or is PUBLIC, or, if the grantor of p 2 is a role name, the grantee of p 1 belongs to the set of applicable roles of the grantor of p 2. Depending on the type of the involved objects, SQL:1999 denes also other notions of dependency; the in-depth discussion of these notions is far beyond the scope of this chapter (we refer the reader to [1] for a more comprehensive treatment). Privilege descriptors, and dependencies between them, can be represented as a graph called privilege dependency graph. The privilege dependency graph is a directed graph such that each node represent a privilege descriptor and each arc from node p 1 to node p 2 represents the fact that p 2 directly depends on p 1. Figure 7(a) illustrates an example of privilege dependency graph for the SELECT privilege on table Department, where, for the sake of clarity, nodes are labeled with the grantee identier. Privilege revocation The REVOKE statement allows authorization identiers to revoke privileges they previously granted (note that an authorization identier can revoke only privileges granted by itself). The SQL syntax for the REVOKE statement is illustrated in Figure 6. A REVOKE statement 7
8 identies the set of all privilege descriptors where the action and object are equal to those specied (explicitly or implicitly) in <action> and <object name>, respectively, the grantor is <grantor>, if specied, or coincides with the non-null element in the current pair huid, rid i, and the grantee is <grantee>. For instance, the REVOKE statement REVOKE SELECT ON Department FROM Mallory, Walter CASCADE executed by Dave identies the privilege descriptors corresponding to the nodes labeled Mallory and Walter in Figure 7(a). The privilege dependency graph after revocation is as illustrated in Figure 7(b). 5 Views and routines In addition to using the privileges described above to provide specic types of access to entire objects, there is also a mechanism within SQL to provide content-based access restrictions. This mechanism is represented by views, which dene a convenient way to refer to specic portions of tables. A view is a virtual table derived from base tables and/or other views. A view is specied by a view denition that is written in SQL. The database stores the view denitions and materializes the views as needed. A view can contain a subset of the data (columns and/or rows) in the tables on which the view is dened. A view can also contain data derived from them or representing an aggregation of them, using the aggregate functions supported by SQL (e.g., SUM, MIN, MAX). Examples of view creation statements are as follows: CREATE VIEW R&D(name,salary) AS SELECT name, salary FROM Employee WHERE dept = `Research & Development' CREATE VIEW MaxSalary(dept,salary) AS SELECT dept,max(salary) FROM Employee GROUP BY dept View R&D is dened to represent name and office attributes of the tuples in the Employee table that satisfy dept = \Research & Development" predicate. By assuming table Employee as in Figure 4, the view will contain the single tuple (Alice,15). View MaxSalary uses data aggregation functions to report the list of departments having employees and the maximum salary paid by each department. 8
9 A user/role can create a view only if it has permission to access all the tables (views or base tables) directly referenced by the view (i.e., appearing in its denition). The creator receives on the view the privileges that it holds on all the tables directly refenced. Also, it receives the grant option for a privilege only if it has the grant option for the privilege on all the tables directly referenced by the view. If it holds a privilege on the view with the grant option, the creator can grant the privilege (and the grant option) to others. The grantees of such privileges need not hold the privileges on the underlying tables to access the view; access to the view only requires the existence of privileges for the view. Views provide therefore a convenient way to enforce selective access on tables not accessible directly. For retrieving purposes, there is no distinction between views and base tables. Therefore, views provide a powerful mechanism for controlling what information can be retrieved. When updates are considered, views and base tables must be treated dierently. In general, users cannot directly update views, particularly when they are created from the combination (join) of two or more base tables. The updatable views can instead appear as targets of statements that change SQL data. The results of changes expressed in this way are dened in terms of corresponding changes to base tables. Like views, routines also provide an eective way to enforce access restrictions. The creator of a routine is granted the EXECUTE privilege on the routine only if it holds all the privileges necessary for the routine to run successfully. The EXECUTE privilege is granted with the grant option if the creator has the grant option for all the privileges necessary for the routine to run. If the creator of a routine holds the EXECUTE privilege with the grant option, it can grant to others the privilege (and the grant option on it). Like for views, the grantees need not hold the privileges necessary for the routine to run in order to execute it (intuitively these accesses are checked against the privileges of the routine creator). 6 Integrity constraints Providing integrity means ensuring that the data stored in the database correctly reect the real world, that is, they have not been modied by unauthorized users or in an improper way. Integrity requires the enforcement of dierent controls and principles, including treatment of transactions. A transaction is a sequence of database actions for which the following ACID properties must be ensured: 9
10 Atomicity: a transaction is either performed in its entirety or not performed at all; Consistency: a transaction must preserve the consistency of the database; Isolation: a transaction should not make its updates visible to other transactions until it is committed; Durability: changes made by a transaction that has committed must never be lost because of subsequent failures. Satisfaction of the properties above requires application of specic controls (e.g., concurrency control) in transaction processing by the DBMS. In this section we focus of integrity constraints that dene what it means for a database to be consistent and that can be specied through the DBMS manipulation language. Integrity constraints, generally referred to simply as constraints, dene the valid states of data in the database by constraining the values in the base tables. The checking of constraints can be performed at the end of an SQL statement or deferred until the end of transaction. If a constraint is not satised, an exception is raised and the SQL statement that caused the constraint to be checked has no eect. SQL:1999 denes dierent types of constraints: table constraints, domain constraints, and assertions. Figure 8 illustrates the general syntax of the SQL statements used to dene constraints. Table constraints A table constraint is either a unique constraint, a referential constraint or a table check constraint which may be specied for tables. A unique constraint species one or more columns of the table as unique columns, that is, no two rows in a table have the same non-null values in the unique columns. To illustrate, consider the following table denition CREATE TABLE Employee (name CHAR(20) oce SMALLINT salary DECIMAL(9,2) dept CHAR(20)) UNIQUE (oce) PRIMARY KEY (name)) 10
11 The unique constraint associated with attribute office states that no value can be present more than once in the office column (intuitively, oces cannot be shared). Note that, as discussed in Section 3.1 the primary key denition implicitely imposes a unicity constraint on the primary key attribute. A referential constraint species one or more columns (called foreign key) in a table T as referencing columns and corresponding referenced columns in some (not necessarily distinct) base table S. For instance, the SQL statement: ALTER TABLE Employee ADD FOREIGN KEY (dept) REFERENCES Department(dept)) modies the denition of the Employee table given above by adding a referential constraint stating that the dept column in the Employee table is a foreign key referencing the dept column in the Department table. As already discussed in Section 3.1, if the foreign key forarowoft is non null, then a row in S must exist such that all the corresponding columns match. If null values are present, satisfaction of the referential constraint depends on the treatment specied for nulls (known as the match type). A table check constraint species a search condition which all rows in the table must satisfy. For instance, attribute oce in the Employee table above could be dened with associated constraint CHECK (oce BETWEEN 10 AND 100) restricting to the range 10 to 100 the possible values for attribute oce. A table check constraint is considered violated if the result of the search condition is false for any row of the table. Note that the constraint is violated if the result is unknown. Domain constraints A domain constraint is a constraint that is specied for a domain. It is similar to table check constraint above but is dened on a domain instead of a specic column. The constraint is then enforced on all the columns dened on the domains, and to all values cast to that domain. 11
12 Assertions An assertion is a named constraint that may relate to the content of individual rows of a table, to the entire contents of a table, or to a state required to exist among a number of tables. Examples of assertions are as follows. CREATE ASSERTION max employee CHECK ((SELECT COUNT(*) FROM Employee ) < 10000) CREATE ASSERTION max salary employee CHECK ((SELECT SUM(salary) FROM Employee) < 0.8*(SELECT SUM(budget) FROM Department)) The rst assertion states that the total number of employees must be less that while the second one states that the total sum of employees' salary must be less that 80% of the budget. In every SQL-session, every constraint has a constraint mode that is a property of that SQLsession. Any type of constraint can be declared to be DEFERRABLE or NOT DEFERRABLE; if it is DEFERRABLE, it can further be declared to be INITIALLY DEFERRED or INITIALLY IMMEDIATE, which dened its state at the beginning of transactions (<constraint characteristics>). The constraint state can be set by the SQL statement \SET CONSTRAINTS <constraint name list> f DEFERRED j IMMEDIATE g", provided the constraint is deferrable. When a transaction is initiated, the constraint mode of each constraint is set to its default. On completion of execution of every SQL-statement, every constraint ischecked whose constraint mode is immediate. 7 Multilevel Secure Databases Discretionary access controls have the limitation that they can be easily circumvented by malicious users. TO illustrate, if the user Alice has been granted the SELECT privilege without the grant option on a particular relation, then she should not be able to grant this privilege to other users. She can easily subvert this intent by making a copy of the relation in question, and as owner can give SELECT privilege on the copy to others. Even if users are trusted not to violate the security in this way, a malicious user can imbed Trojan horses that can do so [3]. Multilevel secure databases enforce mandatory access controls to help eliminate these problems. In a multilevel system, access controls are based on the security labels associated with each user and each data item. Security labels have two components: a hierarchical component (such astop SECRET, SECRET, CONFIDENTIAL, and UNCLASSIFIED, listed in decreasing order of sensitivity) and a set of categories or compartments (such as NUCLEAR, NATO, CONVENTIONAL) 12
13 which could be empty. The security labels are partially ordered as follows: A label X dominates label Y if the hiearchical component of X is greater than or equal to that of Y and if the categories of X contain the categories of Y. The security policy requires that a user may have access to a data item if the security label of the user dominates that of the data item. Thus, a user with a SECRET clearance can have access to a relation with CONFIDENTIAL data, but not a relation with TOP SECRET data. There are multitudes of problems that must be addressed to make multilevel secure DBMSs commercially viable. One of the major diculties is that in a mulilevel secure system, data values may bepolyinstantiated, allowing users with dierent clearance levels to have dierent views of the same object. Refer to Abrams et al. [2] for additional details. 8 Inference Problems An inference problem arises when users can derive some unauthorized information from the information they legally obtain from the database. Many of the inference problems that arise are due to combining data retrieved from the database with external knowledge of the users. The US Census Bureau is particularly concerned about the inference problem since by law it must release to the public aggregate statistics on groups of individuals without releasing information about particular individuals [5]. Another commonly cited example is the US Department of Defense phone book; the entire phone book is considered sensitive but individual numbers are not. References [1] Database Language SQL { Part 2: Foundation (SQL/Foundation). ISO International Standard, ISO/IEC 9075:1999, [2] Marshall D. Abrams, Sushil Jajodia, and Harold J. Podell, eds. Information Security: An Integrated Collection of Essays. IEEE Computer Society Press, Los Alamitos, CA, [3] S. Castano, M.G. Fugini, G. Martella, and P. Samarati. Database Security. Addison Wesley Publishing Company, [4] E.F. Codd. A Relational Model for Large Shared Data Banks. Communications of the ACM, 13(6):377{387, June
14 [5] Dorothy E. Denning. Cryptography and Data Security. Addison-Wesley, Reading, MA,
15 Users... External level external view... external view Conceptual level conceptual schema Internal level internal schema Figure 1: Three-level architecture Users DBMS OS Hardware Figure 2: DBMS/OS high-level architecture 15
16 user identification/authentication User profiles access control integrity authorizations security administrator integrity rules database log auditor Figure 3: Security mechanisms 16
17 name oce salary Employee dept Department dept location phone budget Alice 15 $70,000 Research & Development Eve 5 $50,000 Computer Science Dave 22 $65,000 Electrical Engineering Research & Development South Street $555,000 Computer Science Main Street $1,500,000 Electrical Engineering Park Street $350,000 Figure 4: A simple example of a relational database 17
18 Privilege Object Description SELECT table column name list, or privilege retrieve values from the specied object method list INSERT table or column name list insert rows in the specied object UPDATE table or column name list modify the data within the specied object DELETE table delete rows from the specied object TRIGGER table dene a trigger for the specied object REFERENCES table or column name list specify a foreign key reference from the specied object schema to the foreign key of another object USAGE domain, user-dened type, character allow the usage of the specied object set, collation, or translation UNDER structured type dene a subtype of the specied object EXECUTE SQL-invoked routine execute the specied object Figure 5: SQL privileges 18
19 GRANT ALL PRIVILEGES j <action> ON [ TABLE ] j DOMAIN j COLLATION j CHARACTER SET j TRANSLATION j TYPE <object name> TO <grantee> [f<comma><grantee>g:::] [ WITH HIERARCHY OPTION ] [ WITH GRANT OPTION ] [ GRANTED BY <grantor>] REVOKE [ GRANT OPTION FOR j HIERARCHY OPTION FOR ] <action> ON [ TABLE ] j DOMAIN j COLLATION j CHARACTER SET j TRANSLATION j TYPE <object name> FROM <grantee> [ f <comma><grantee> g::: ] [ GRANTED BY <grantor> ] CASCADE j RESTRICT Figure 6: Syntax of the SQL statements for assigning privileges 19
20 Privilege: SELECT ON Department Mallory Dave Dave Alice Eve Peggy Walter Alice Eve Peggy (a) (b) Figure 7: An example of privilege dependency graph (a) and the graph after a REVOKE statement 20
21 [ CONSTRAINT <constraint name> ] Unique UNIQUE j PRIMARY KEY (<unique column list>) j UNIQUE ( VALUE ) Table Domain Referential Table check [ <constraint characteristics> ] [ CONSTRAINT <constraint name> ] FOREIGN KEY (<referencing columns>) REFERENCES <referenced table and columns> [ MATCH <match type> ] [ <referential triggered action> ] [ <constraint characteristics> ] [ CONSTRAINT <constraint name> ] CHECK (<search condition>) [ <constraint characteristics> ] [ CONSTRAINT <constraint name> ] CHECK (<search condition>) Assertion [ <constraint characteristics> ] CREATE ASSERTION <constraint name> CHECK (<search condition>) [ <constraint characteristics> ] Figure 8: Syntax of the SQL statements for dening constraints 21
Chapter 23. Database Security. Security Issues. Database Security
Chapter 23 Database Security Security Issues Legal and ethical issues Policy issues System-related issues The need to identify multiple security levels 2 Database Security A DBMS typically includes a database
INFO/CS 330: Applied Database Systems
INFO/CS 330: Applied Database Systems Introduction to Database Security Johannes Gehrke [email protected] http://www.cs.cornell.edu/johannes Introduction to DB Security Secrecy:Users should not be
1 Handbook of Information Security Management (1994-95 Yearbook), Auerbach Publishers, 1994, pages 145-160. RELATIONAL DATABASE ACCESS CONTROLS Prof. Ravi S. Sandhu Center for Secure Information Systems
Access Control Models Part I. Murat Kantarcioglu UT Dallas
UT DALLAS Erik Jonsson School of Engineering & Computer Science Access Control Models Part I Murat Kantarcioglu UT Dallas Introduction Two main categories: Discretionary Access Control Models (DAC) Definition:
Trusted RUBIX TM. Version 6. Multilevel Security in Trusted RUBIX White Paper. Revision 2 RELATIONAL DATABASE MANAGEMENT SYSTEM TEL +1-202-412-0152
Trusted RUBIX TM Version 6 Multilevel Security in Trusted RUBIX White Paper Revision 2 RELATIONAL DATABASE MANAGEMENT SYSTEM Infosystems Technology, Inc. 4 Professional Dr - Suite 118 Gaithersburg, MD
Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification
Chapter 5 More SQL: Complex Queries, Triggers, Views, and Schema Modification Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 5 Outline More Complex SQL Retrieval Queries
IT2304: Database Systems 1 (DBS 1)
: Database Systems 1 (DBS 1) (Compulsory) 1. OUTLINE OF SYLLABUS Topic Minimum number of hours Introduction to DBMS 07 Relational Data Model 03 Data manipulation using Relational Algebra 06 Data manipulation
How Can Data Sources Specify Their Security Needs to a Data Warehouse?
How Can Data Sources Specify Their Security Needs to a Data Warehouse? Arnon Rosenthal The MITRE Corporation [email protected] Edward Sciore Boston College (and MITRE) [email protected] Abstract In current warehouse
DISCRETIONARY ACCESS CONTROL. Tran Thi Que Nguyet Faculty of Computer Science & Engineering HCMC University of Technology [email protected].
DISCRETIONARY ACCESS CONTROL Tran Thi Que Nguyet Faculty of Computer Science & Engineering HCMC University of Technology [email protected] Outline 1 2 3 4 Introduction to Discretionary Access
CS377: Database Systems Data Security and Privacy. Li Xiong Department of Mathematics and Computer Science Emory University
CS377: Database Systems Data Security and Privacy Li Xiong Department of Mathematics and Computer Science Emory University 1 Principles of Data Security CIA Confidentiality Triad Prevent the disclosure
IT2305 Database Systems I (Compulsory)
Database Systems I (Compulsory) INTRODUCTION This is one of the 4 modules designed for Semester 2 of Bachelor of Information Technology Degree program. CREDITS: 04 LEARNING OUTCOMES On completion of this
Schema Evolution in SQL-99 and Commercial (Object-)Relational DBMS
Schema Evolution in SQL-99 and Commercial (Object-)Relational DBMS Can Türker Swiss Federal Institute of Technology (ETH) Zurich Institute of Information Systems, ETH Zentrum CH 8092 Zurich, Switzerland
ITM661 Database Systems. Database Security and Administration
ITM661 Database Systems Database Security and Administration Outline Introduction to Database Security Issues Types of Security Threats to databases Database Security and DBA Access Protection, User Accounts,
Database Security. Soon M. Chung Department of Computer Science and Engineering Wright State University [email protected].
Database Security Soon M. Chung Department of Computer Science and Engineering Wright State University [email protected] 937-775-5119 Goals of DB Security Integrity: Only authorized users should be
Chapter 23. Database Security. Security Issues. Database Security
Chapter 23 Database Security Security Issues Legal and ethical issues Policy issues System-related issues The need to identify multiple security levels 2 Database Security A DBMS typically includes a database
CHAPTER 2 DATABASE MANAGEMENT SYSTEM AND SECURITY
CHAPTER 2 DATABASE MANAGEMENT SYSTEM AND SECURITY 2.1 Introduction In this chapter, I am going to introduce Database Management Systems (DBMS) and the Structured Query Language (SQL), its syntax and usage.
Role Based Access Control (RBAC) Nicola Zannone
Role Based Access Control (RBAC) Nicola Zannone 1 DAC and MAC Discretionary Access Control (DAC) Access control determined by the owner of an object Oner can delegate access rights to other users Access
Database Security. Chapter 21
Database Security Chapter 21 Introduction to DB Security Secrecy: 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
Database Security. The Need for Database Security
Database Security Public domain NASA image L-1957-00989 of people working with an IBM type 704 electronic data processing machine. 1 The Need for Database Security Because databases play such an important
Database Security and Authorization
Database Security and Authorization 1 Database Security and Authorization 1.1 Introduction to Database Security Issues 1.2 Types of Security 1.3 Database Security and DBA 1.4 Access Protection, User Accounts,
Role-based access control. RBAC: Motivations
Role-based access control 1 RBAC: Motivations Complexity of security administration For large number of subjects and objects, the number of authorizations can become extremely large For dynamic user population,
SECURITY CHAPTER 24 (6/E) CHAPTER 23 (5/E)
SECURITY CHAPTER 24 (6/E) CHAPTER 23 (5/E) 2 LECTURE OUTLINE Threats and countermeasures Access control mechanisms SQL s grant and revoke Role of views 3 THREATS What are the threats? Loss of integrity
Security and Authorization. Introduction to DB Security. Access Controls. Chapter 21
Security and Authorization Chapter 21 Database Management Systems, 3ed, R. Ramakrishnan and J. Gehrke 1 Introduction to DB Security Secrecy: Users should not be able to see things they are not supposed
2. Basic Relational Data Model
2. Basic Relational Data Model 2.1 Introduction Basic concepts of information models, their realisation in databases comprising data objects and object relationships, and their management by DBMS s that
Instant SQL Programming
Instant SQL Programming Joe Celko Wrox Press Ltd. INSTANT Table of Contents Introduction 1 What Can SQL Do for Me? 2 Who Should Use This Book? 2 How To Use This Book 3 What You Should Know 3 Conventions
Information Security Policy
Essay 7 Information Security Policy Ingrid M. Olson and Marshall D. Abrams This essay discusses information security policy, focusing on information control and dissemination, for automated information
Security Issues in the Database Language SQL W. Timothy Polk and Lawrence E. Bassham
NIST Special Publication 800-8 Security Issues in the Database Language SQL W. Timothy Polk and Lawrence E. Bassham The Database Language SQL (SQL) is a standard interface for accessing and manipulating
BCA. Database Management System
BCA IV Sem Database Management System Multiple choice questions 1. A Database Management System (DBMS) is A. Collection of interrelated data B. Collection of programs to access data C. Collection of data
Database Security. Sarajane Marques Peres, Ph.D. University of São Paulo www.each.usp.br/sarajane
Database Security Sarajane Marques Peres, Ph.D. University of São Paulo www.each.usp.br/sarajane Based on Elsmari x Navathe / Silberschatz, Korth, Sudarshan s books Types of security Legal and ethical
SECURITY MODELS FOR OBJECT-ORIENTED DATA BASES
82-10-44 DATA SECURITY MANAGEMENT SECURITY MODELS FOR OBJECT-ORIENTED DATA BASES James Cannady INSIDE: BASICS OF DATA BASE SECURITY; Discretionary vs. Mandatory Access Control Policies; Securing a RDBMS
Database Security Part 7
Database Security Part 7 Discretionary Access Control vs Mandatory Access Control Elisa Bertino [email protected] Discretionary Access Control (DAC) No precise definition Widely used in modern operating
How To Create A Table In Sql 2.5.2.2 (Ahem)
Database Systems Unit 5 Database Implementation: SQL Data Definition Language Learning Goals In this unit you will learn how to transfer a logical data model into a physical database, how to extend or
Part III. Access Control Fundamentals
Part III Access Control Fundamentals Sadeghi, Cubaleska @RUB, 2008-2009 Course Operating System Security Access Control Fundamentals 105 / 148 10 3.1 Authentication and Access Control 11 Examples for DAC
Access Control: Policies, Models, and Mechanisms
Access Control: Policies, Models, and Mechanisms Pierangela Samarati and Sabrina de Capitani di Vimercati 2 Dipartimento di Tecnologie dell Informazione, Università di Milano Via Bramante 65, 263 Crema
Managing large sound databases using Mpeg7
Max Jacob 1 1 Institut de Recherche et Coordination Acoustique/Musique (IRCAM), place Igor Stravinsky 1, 75003, Paris, France Correspondence should be addressed to Max Jacob ([email protected]) ABSTRACT
ADO and SQL Server Security
ADO and SQL Server Security Security is a growing concern in the Internet/intranet development community. It is a constant trade off between access to services and data, and protection of those services
Chapter 24. Database Security. Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley
Chapter 24 Database Security Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Introduction to Database Security Issues Types of Security Legal and ethical issues: privacy issues
Database security. André Zúquete Security 1. Advantages of using databases. Shared access Many users use one common, centralized data set
Database security André Zúquete Security 1 Advantages of using databases Shared access Many users use one common, centralized data set Minimal redundancy Individual users do not have to collect and maintain
Role Based Access Control: Adoption and Implementation in the Developing World
Role Based Access Control: Adoption and Implementation in the Developing World By Loy A.K. Muhwezi Master s Thesis in Computer Science Thesis number: Supervised By Dr. Martijn Oostdijk Radboud University
Best Practices, Procedures and Methods for Access Control Management. Michael Haythorn
Best Practices, Procedures and Methods for Access Control Management Michael Haythorn July 13, 2013 Table of Contents Abstract... 2 What is Access?... 3 Access Control... 3 Identification... 3 Authentication...
Part A: Data Definition Language (DDL) Schema and Catalog CREAT TABLE. Referential Triggered Actions. CSC 742 Database Management Systems
CSC 74 Database Management Systems Topic #0: SQL Part A: Data Definition Language (DDL) Spring 00 CSC 74: DBMS by Dr. Peng Ning Spring 00 CSC 74: DBMS by Dr. Peng Ning Schema and Catalog Schema A collection
Lecture 6. SQL, Logical DB Design
Lecture 6 SQL, Logical DB Design Relational Query Languages A major strength of the relational model: supports simple, powerful querying of data. Queries can be written intuitively, and the DBMS is responsible
Access Control: Policies, Models, and Mechanisms
Access Control: Policies, Models, and Mechanisms Pierangela Samarati 1 and Sabrina De Capitani di Vimercati 2 1 Dipartimento di Tecnologie dell Informazione Università di Milano Via Bramante 65 263 - Crema
BM482E Introduction to Computer Security
BM482E Introduction to Computer Security Lecture 7 Database and Operating System Security Mehmet Demirci 1 Summary of Lecture 6 User Authentication Passwords Password storage Password selection Token-based
Access Control Basics. Murat Kantarcioglu
UT DALLAS Erik Jonsson School of Engineering & Computer Science Access Control Basics Murat Kantarcioglu Access Control - basic concepts An access control system regulates the operations that can be executed
1 File Processing Systems
COMP 378 Database Systems Notes for Chapter 1 of Database System Concepts Introduction A database management system (DBMS) is a collection of data and an integrated set of programs that access that data.
Welcome to Information Systems Security (503009)
Welcome to (503009) Nguyen Thi Ai Thao Faculty of Computer Science & Engineering HCMC University of Technology [email protected] Course Outline Week Lectures 1 Information systems security: basic
Outline. Data Modeling. Conceptual Design. ER Model Basics: Entities. ER Model Basics: Relationships. Ternary Relationships. Yanlei Diao UMass Amherst
Outline Data Modeling Yanlei Diao UMass Amherst v Conceptual Design: ER Model v Relational Model v Logical Design: from ER to Relational Slides Courtesy of R. Ramakrishnan and J. Gehrke 1 2 Conceptual
Introduction to Databases
Page 1 of 5 Introduction to Databases An introductory example What is a database? Why do we need Database Management Systems? The three levels of data abstraction What is a Database Management System?
B.Sc (Computer Science) Database Management Systems UNIT-V
1 B.Sc (Computer Science) Database Management Systems UNIT-V Business Intelligence? Business intelligence is a term used to describe a comprehensive cohesive and integrated set of tools and process used
Database Design Overview. Conceptual Design ER Model. Entities and Entity Sets. Entity Set Representation. Keys
Database Design Overview Conceptual Design. The Entity-Relationship (ER) Model CS430/630 Lecture 12 Conceptual design The Entity-Relationship (ER) Model, UML High-level, close to human thinking Semantic
Guide to SQL Programming: SQL:1999 and Oracle Rdb V7.1
Guide to SQL Programming: SQL:1999 and Oracle Rdb V7.1 A feature of Oracle Rdb By Ian Smith Oracle Rdb Relational Technology Group Oracle Corporation 1 Oracle Rdb Journal SQL:1999 and Oracle Rdb V7.1 The
DATABASE SECURITY MECHANISMS AND IMPLEMENTATIONS
DATABASE SECURITY MECHANISMS AND IMPLEMENTATIONS Manying Qiu, Virginia State University, [email protected] Steve Davis, Clemson University, [email protected] ABSTRACT People considering improvements in database
DATABASE MANAGEMENT SYSTEM
REVIEW ARTICLE DATABASE MANAGEMENT SYSTEM Sweta Singh Assistant Professor, Faculty of Management Studies, BHU, Varanasi, India E-mail: [email protected] ABSTRACT Today, more than at any previous
Database Security. Database Security Requirements
Database Security Laurie Williams [email protected] John Slankas [email protected] Physical database integrity Logical database integrity Element integrity Auditability Access Control User Authentication
Database and Data Mining Security
Database and Data Mining Security 1 Threats/Protections to the System 1. External procedures security clearance of personnel password protection controlling application programs Audit 2. Physical environment
Relational model. Relational model - practice. Relational Database Definitions 9/27/11. Relational model. Relational Database: Terminology
COS 597A: Principles of Database and Information Systems elational model elational model A formal (mathematical) model to represent objects (data/information), relationships between objects Constraints
The Relational Data Model and Relational Database Constraints
The Relational Data Model and Relational Database Constraints Chapter Outline Relational Model Concepts Relational Model Constraints and Relational Database Schemas Update Operations and Dealing with Constraint
Introduction to Database Systems
Introduction to Database Systems A database is a collection of related data. It is a collection of information that exists over a long period of time, often many years. The common use of the term database
Oracle Database 10g Express
Oracle Database 10g Express This tutorial prepares the Oracle Database 10g Express Edition Developer to perform common development and administrative tasks of Oracle Database 10g Express Edition. Objectives
Computer security Lecture 3. Access control
Computer security Lecture 3 Access control Access control, the basic problem: Efficient representation of access rights Simply listing, per subject and object, what access is allowed and/or denied is very
Authentication, Access Control, and Intrusion Detection Ravi S. Sandhu y and Pierangela Samarati z 1 Introduction An important requirement ofany information management system is to protect information
SQL NULL s, Constraints, Triggers
CS145 Lecture Notes #9 SQL NULL s, Constraints, Triggers Example schema: CREATE TABLE Student (SID INTEGER PRIMARY KEY, name CHAR(30), age INTEGER, GPA FLOAT); CREATE TABLE Take (SID INTEGER, CID CHAR(10),
SQL Server. 2012 for developers. murach's TRAINING & REFERENCE. Bryan Syverson. Mike Murach & Associates, Inc. Joel Murach
TRAINING & REFERENCE murach's SQL Server 2012 for developers Bryan Syverson Joel Murach Mike Murach & Associates, Inc. 4340 N. Knoll Ave. Fresno, CA 93722 www.murach.com [email protected] Expanded
Elena Baralis, Silvia Chiusano Politecnico di Torino. Pag. 1. Active database systems. Triggers. Triggers. Active database systems.
Active database systems Database Management Systems Traditional DBMS operation is passive Queries and updates are explicitly requested by users The knowledge of processes operating on data is typically
1. INTRODUCTION TO RDBMS
Oracle For Beginners Page: 1 1. INTRODUCTION TO RDBMS What is DBMS? Data Models Relational database management system (RDBMS) Relational Algebra Structured query language (SQL) What Is DBMS? Data is one
Completeness, Versatility, and Practicality in Role Based Administration
Completeness, Versatility, and Practicality in Role Based Administration Slobodan Vukanović [email protected] Abstract Applying role based administration to role based access control systems has
Module 7 Security CS655! 7-1!
Module 7 Security CS655! 7-1! Issues Separation of! Security policies! Precise definition of which entities in the system can take what actions! Security mechanism! Means of enforcing that policy! Distributed
Secure cloud access system using JAR ABSTRACT:
Secure cloud access system using JAR ABSTRACT: Cloud computing enables highly scalable services to be easily consumed over the Internet on an as-needed basis. A major feature of the cloud services is that
Physical Database Design Process. Physical Database Design Process. Major Inputs to Physical Database. Components of Physical Database Design
Physical Database Design Process Physical Database Design Process The last stage of the database design process. A process of mapping the logical database structure developed in previous stages into internal
SQL Server. 1. What is RDBMS?
SQL Server 1. What is RDBMS? Relational Data Base Management Systems (RDBMS) are database management systems that maintain data records and indices in tables. Relationships may be created and maintained
Maintaining Stored Procedures in Database Application
Maintaining Stored Procedures in Database Application Santosh Kakade 1, Rohan Thakare 2, Bhushan Sapare 3, Dr. B.B. Meshram 4 Computer Department VJTI, Mumbai 1,2,3. Head of Computer Department VJTI, Mumbai
Chapter 6: Physical Database Design and Performance. Database Development Process. Physical Design Process. Physical Database Design
Chapter 6: Physical Database Design and Performance Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden Robert C. Nickerson ISYS 464 Spring 2003 Topic 23 Database
Demystified CONTENTS Acknowledgments xvii Introduction xix CHAPTER 1 Database Fundamentals CHAPTER 2 Exploring Relational Database Components
Acknowledgments xvii Introduction xix CHAPTER 1 Database Fundamentals 1 Properties of a Database 1 The Database Management System (DBMS) 2 Layers of Data Abstraction 3 Physical Data Independence 5 Logical
SQL DATA DEFINITION: KEY CONSTRAINTS. CS121: Introduction to Relational Database Systems Fall 2015 Lecture 7
SQL DATA DEFINITION: KEY CONSTRAINTS CS121: Introduction to Relational Database Systems Fall 2015 Lecture 7 Data Definition 2 Covered most of SQL data manipulation operations Continue exploration of SQL
TRANSMAT Trusted Operations for Untrusted Database Applications
TRANSMAT Trusted Operations for Untrusted Database s Dan Thomsen Secure Computing Corporation 2675 Long Lake Road Roseville, MN 55113, USA email: [email protected] Abstract This paper presents a technique
Using SAS as a Relational Database
Using SAS as a Relational Database Yves DeGuire Statistics Canada Come out of the desert of ignorance to the OASUS of knowledge Introduction Overview of relational database concepts Why using SAS as a
Security Implications of Distributed Database Management System Models
Security Implications of Distributed Database Management System Models 1 * Dr.C.Sunil Kumar, 2 J.Seetha, 3 S.R.Vinotha 1,2,3 Anna University, Chennai, India E-mail: 1 [email protected], 2 [email protected],
types, but key declarations and constraints Similar CREATE X commands for other schema ëdrop X name" deletes the created element of beer VARCHARè20è,
Dening a Database Schema CREATE TABLE name èlist of elementsè. Principal elements are attributes and their types, but key declarations and constraints also appear. Similar CREATE X commands for other schema
DATABASE SECURITY MECHANISM
DATABASE SECURITY MECHANISM Dorin Iordache Lecturer eng., Romanian Naval Academy Mircea cel Bătrân Fulgerului nr.1, Constanta, 8700, Romania email: [email protected] Abstract Database security was and
The Relational Model. Why Study the Relational Model? Relational Database: Definitions
The Relational Model Database Management Systems, R. Ramakrishnan and J. Gehrke 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Microsoft, Oracle, Sybase, etc. Legacy systems in
The process of database development. Logical model: relational DBMS. Relation
The process of database development Reality (Universe of Discourse) Relational Databases and SQL Basic Concepts The 3rd normal form Structured Query Language (SQL) Conceptual model (e.g. Entity-Relationship
SQL: Queries, Programming, Triggers
SQL: Queries, Programming, Triggers Chapter 5 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 R1 Example Instances We will use these instances of the Sailors and Reserves relations in
ECS 165A: Introduction to Database Systems
ECS 165A: Introduction to Database Systems Todd J. Green based on material and slides by Michael Gertz and Bertram Ludäscher Winter 2011 Dept. of Computer Science UC Davis ECS-165A WQ 11 1 1. Introduction
Example Instances. SQL: Queries, Programming, Triggers. Conceptual Evaluation Strategy. Basic SQL Query. A Note on Range Variables
SQL: Queries, Programming, Triggers Chapter 5 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Example Instances We will use these instances of the Sailors and Reserves relations in our
Chapter 1: Introduction
Chapter 1: Introduction Database System Concepts, 5th Ed. See www.db book.com for conditions on re use Chapter 1: Introduction Purpose of Database Systems View of Data Database Languages Relational Databases
Extended RBAC Based Design and Implementation for a Secure Data Warehouse
Extended RBAC Based Design and Implementation for a Data Warehouse Dr. Bhavani Thuraisingham The University of Texas at Dallas [email protected] Srinivasan Iyer The University of Texas
Chapter 8 A secure virtual web database environment
Chapter 8 Information security with special reference to database interconnectivity Page 146 8.1 Introduction The previous three chapters investigated current state-of-the-art database security services
There are five fields or columns, with names and types as shown above.
3 THE RELATIONAL MODEL Exercise 3.1 Define the following terms: relation schema, relational database schema, domain, attribute, attribute domain, relation instance, relation cardinality, andrelation degree.
The Relational Model. Ramakrishnan&Gehrke, Chapter 3 CS4320 1
The Relational Model Ramakrishnan&Gehrke, Chapter 3 CS4320 1 Why Study the Relational Model? Most widely used model. Vendors: IBM, Informix, Microsoft, Oracle, Sybase, etc. Legacy systems in older models
EECS 647: Introduction to Database Systems
EECS 647: Introduction to Database Systems Instructor: Luke Huan Spring 2013 Administrative Take home background survey is due this coming Friday The grader of this course is Ms. Xiaoli Li and her email
