Bài giảng Bảo mật cơ sở dữ liệu: Chapter 3 - Trần Thị Kim Chi

Bài giảng Bảo mật cơ sở dữ liệu - Chương 3: Access Control Discretionary Access Control trình bày 2 nội dung chính là Access Control và Discretionary Access Control. Đây là một tài liệu hữu ích dành cho các bạn sinh viên ngành Công nghệ thông tin dùng làm tài liệu học tập và nghiên cứu.

apter 3 Access Control Discretionary Access Control Agenda Access Control  Discretionary Access Control Access Control “Access  control”  is  where  security  engineering  meets  computer science Its function is to control which (active) subject have access  to  a  which  (passive)  object  with  some  specific  access  operation subject Access  request Reference monitor object Access Control Determine whether a principal can perform a requested  operation on a target object – – – Principal: user, process, etc Operation: read, write, etc Object: file, tuple, etc Lampson defined the familiar access matrix and its two  interpretations ACLs and capabilities [Lampson70] Why are we still talking about  access control? An access control policy is a specification for an access  decision function The policy aims to achieve – – Permit the principal’s intended function (availability) Ensure security properties are met (integrity, confidentiality) • • Limit to “Least Privilege,” Protect system integrity, Prevent unauthorized  leakage, etc Also known as ‘constraints’ Enable administration of a changeable system (simplicity) Example: Access Control Prof Alice manages access to course objects ‣ Assign access to individual (principal: Bob) ‣ Assign access to aggregate (course­students) ‣ Associate access to relation (students(course)) ‣  Assign students to project groups (student(course, project,  group)) Prof Alice wants certain guarantees ‣ Students cannot modify objects written by Prof Alice ‣ Students cannot read/modify objects of other groups Prof Alice must be able to maintain access policy ‣ Ensure that individual rights do not violate guarantees ‣ However, exceptions are possible – students may distribute  their results from previous assignments for an exam Access Control is Hard Because Access control requirements are domain­specific – Generic approaches over­generalize Access control requirements can change – Anyone could be an administrator The Safety Problem [HRU76] – Can only know what is leaked right now Access is fail­safe, but Constraints are not – And constraints must restrict all future states Safety Problem Determine if an unauthorized permission is leaked given – – An initial set of permissions and An access control system, mainly administrative operations For a traditional approach, the safety problem is  undecidable – – – Access matrix model with multi­operational commands Main culprit is create – create object/subject with own rights Prove reduction of a Turing machine to the multi­operational  access matrix system Safety Problem Result led to Safe, but limited models: take­grant, schematic protection  model, typed access matrix model Further support for models in which the constraints are  implicit in the model  – e.g., lattice models Check safety on each policy change – constraint approach  of RBAC Compare to Other CS Problems Processor design – Hard, but can get some smart people together to construct one,  fixed, testable design Network protocol design – TCP: A small number of control parameters necessary to manage  all reasonable options, within a layered architecture – Constraints, such as DDoS, are ad hoc Software design – Specific goals in mind to achieve function, constraints are ad hoc DAC – additional features and  recent trends Flexibility is enhanced by supporting  different kinds of permissions – – – – Positive vs. negative Strong vs. weak Implicit vs. explicit Content­based Positive and Negative  Permissions Positive permissions  Give access Negative permissions  Deny access Useful to specify exceptions to a given  policy and to enforce stricter control on  particular crucial data items Positive and Negative  Permissions + ­ Main Issue: Conflicts Authorization Conflicts Main solutions: – – – – – No conflicts Negative permissions take precedence Positive permissions take precedence Nothing take precedence Most specific permissions take precedence Weak and Strong Permissions Strong permissions cannot be overwritten Weak permissions can be overwritten by  strong and weak permissions Implicit and Explicit Permissions Some models support implicit permissions Implicit permissions can be derived: – – by a set of propagation rules exploiting the  subject, object, and privilege hierarchies by a set of user­defined derivation rules Derivation Rules: Example Ann can read file F1 from a table if Bob  has an explicit denial for this access Tom has on file F2 all the permissions  that Bob has Derivation rules are a way to concisely  express a set of security requirements Derivation Rules Derivation rules are often expressed  according to logic programming Several research efforts have been carried  out to compare the expressive power of  such languages We need languages based on SQL and/or  XML Content­based Permissions Content­based access control conditions the  access to a given object based on its content This type of permissions are mainly relevant for  database systems As an example, in a RDBMS supporting content­ based access control it is possible to authorize a  subject to access information only of those  employees whose salary is not greater than 30K Content­based Permissions Two most common approaches to enforce  content­based  access  control  in  a  DBMS  are done: – – by associating a predicate (or a Boolean  combination of predicates) with the  permission by defining a view which selects the objects  whose content satisfies a given condition, and  then granting the permission on the view  instead of on the basic objects DAC models ­ DBMS vs OS Increased number of objects to be protected Different granularity levels (relations, tuples,  single attributes) Protection of logical structures (relations, views)  instead of real resources (files) Different architectural levels with different  protection requirements Relevance not only of data physical  representation, but also of their semantics  Cost Benefits Saves about 7.01 minutes per employee, per year in  administrative functions – – Average IT admin salary ­ $59.27 per hour The annual cost saving is:   • $6,924/1000; $692,471/100,000 Reduced Employee downtime  – – – if new transitioning employees receive their system privileges  faster, their productivity is increased 26.4 hours for non­RBAC; 14.7 hours for RBAC For average employee wage of $39.29/hour, the annual  productivity cost savings yielded by an RBAC system:  • $75000/1000; $7.4M/100,000 Agenda Access Control  Discretionary Access Control Matrix­based models Graph­based models Discretionary models specific to databases Graph­based models A graphical model or probabilistic graphical  model (PGM) is a probabilistic model for which  a graph expresses the conditional dependence  structure between random variables.  They are commonly used inprobability theory,  statistics—particularly Bayesian statistics—and  machine learning Graph­based models Access Control  Discretionary Access Control Matrix­based models Graph­based models Discretionary models specific to databases ... Name Position Age Salary Alice Teacher 45 40K Bob Aide 20 20K Cathy Principal 37 60K Dilbert Teacher 50 50K Eve Teacher 33 50K Access Controlled by History Query 1: – – sum_salary(position = teacher) ... ‘creative’ in subject.groups and time.hour ≥ 0 and time.hour