slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Distributed Database Security PowerPoint Presentation
Download Presentation
Distributed Database Security

Distributed Database Security

958 Vues Download Presentation
Télécharger la présentation

Distributed Database Security

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Distributed Database Security - Goals of DB Security - Distributed Database Security - Secure DDBMS Model: Relational vs. Object-Oriented

  2. Goals of DB Security - Integrity: Only authorized users should be allowed to modify data. - Availability: Making data available to the authorized users and application programs. - Secrecy (or Confidentiality): Protection of data from unauthorized disclosure.

  3. DB Security Mechanisms - Access control - Flow control - Inference control - Encryption

  4. Access Control Methods - Discretionary Access Control grants privileges to users, including the capability to access specific data files, records, or fields in a specific mode (such as read, insert, delete, or update). - Mandatory Access Control classifies users and data into multiple levels of security, and then enforces appropriate rules.

  5. Access Control Using Views The owner of a relation can create a view containing only limited columns and/or tuples, then grants the view to other users.

  6. System (System, user1, SELECT ON EMPLOYEE WITH GRANT OPTION) user1 user2 Revoked Privilege user3 user4 Weakness of Discretionary Access Control Granted Privilege Authorization Graph

  7. Mandatory Access Control - Each data object is assigned a security class. - Each subject (user or program) is assigned a clearance for a security class. - Security classes could be: Top Secret (TS) Secret (S) Confidential (C) Unclassified (U)

  8. Restrictions on Read/Write - Simple Security Property: Subject S is allowed to read object O only if class(S) ≥ class(O). - *-Property: Subject S is allowed to write object O only if class(S) ≤ class(O).

  9. EMP-ID NAME SALARY DEPTNO SECURITY CLASS 1 smith 100000 5 S 2 brown 80000 4 C 1 smith null 5 C Multilevel Relation and Polyinstantiation

  10. Flow Control - Flow control checks that information contained in some data objects does not flow (explicitly or implicitly) into less protected objects. - A clearance for a security class can be assigned to each application program. - Like a DB user, each application program is subjected to the same read/write restrictions.

  11. Covert Channels A covert channel allows information to pass from a higher classification level to a lower classification level through improper means. Example: A distributed DB system has two sites, one with S (secret) level and the other with U (unclassified) level. During the repeated execution of a transaction, the U site agrees to commit all the time while the S site agrees to commit if the bit value is ‘1’ and does not agree to commit if the bit value is ‘0’.

  12. Role-Based Access Control - Mandatory access control is rigid because the security class should be assigned to each subject and data object. -In the real world, access privileges are associated with the role of the person in the organization. (example: bank teller) -Each role is created and is granted/revoked privileges. -Each user is granted/revoked roles.

  13. Inference Control Must prohibit the retrieval of individual data through statistical (aggregate) operations on the database. Example: SELECT MAX(Salary) FROM EMPLOYEE WHERE Dept = ‘CSE’ AND Address LIKE ‘%Cincinnati%’ ; Note: What if only few employees live in Cincinnati?

  14. Solutions for Inference Control - No statistical queries are permitted whenever the number of tuples in the selected population is smaller than a certain number. - Prohibit a sequence of queries that refer to the same population of tuples repeatedly. - Partition the database into groups larger than certain size, and queries can refer to any complete group or set of groups, but never to a subset of a group.

  15. Encryption and PKI (Public Key Infrastructure) - Each user generates a pair of keys: a public key and a private key for encryption and decryption of messages. - Public key and private key are interchangeable: a message encrypted using one key can be decrypted by the other key. - The public key of the pair is made public for others to use, whereas the private key is kept by the owner. - Since the keys are generated by using exponentiation and modulo functions, it is hard to crack them.

  16. PKI (Continued) - If a sender wishes to send a private message to a receiver, the sender encrypts the message using the receiver’s public key. - When the receiver receives the message, he or she decrypts it using the receiver’s private key. No other recipient can decrypt the message because only the receiver knows his or her private key.

  17. Digital Signatures - Like a handwritten signature, a digital signature is a means of associating a mark unique to a person with a body of text. - The message sender generates the digital signature by hashing the message. - The sender encrypts the digital signature using his/her private key first, then encrypts it using the public key of the receiver. - The receiver decrypts the digital signature using his/her private key first, then decrypts it using the public key of the sender. - To validate the message itself, the receiver hashes the message and compare the hash value with the decrypted digital signature.

  18. Secure Electronic Transaction - A buyer encrypts the non-credit card information using the public key of the seller, and encrypts the credit card information using the public key of the credit card company. Then, both are sent to the seller. • The seller decrypts the non-credit card information using his/her private key, and forwards the credit card information (which he/she cannot decrypt) to the credit card company. - The credit card company decrypts the card information using its private key. If the credit card company approves the card information, the transaction goes through.

  19. Distributed database system functions include: 1- distributed query management, 2- distributed transaction processing, 3-distributed metadata management, 4-enforcing security and integrity, across the multiple nodes.

  20. `

  21. Other components of the security policy include policies for integrity, identification and authentication, auditing and accounting. In general, trusted processes perform security critical functions. These processes must be verified to operate correctly.

  22. Partitioned approach

  23. For example: An Unclassified DBMS manages the unclassified data while a Secret DBMS manages Secret data. A user’s query is sent to the DBMS at the user’s level or below the user’s level. Update requests are sent only to the DBMS at the user’s level. For example, a Secret user ’s query is sent to the Secret and Unclassified DBMSs, while a Secret user’s update request is sent only to the Secret DBMS.

  24. Distributed Data and Distributed Control In a multilevel secure distributed database management system (MLS/DDBMS), users cleared at different security levels access and share a distributed database consisting of data at different security levels without violating security. This architecture has been derived from the architecture is based on distributed data and distributed control. In this architecture, the MLS/DDBMS consists of several nodes that are interconnected by a multilevel secure network. In a homogeneous environment, all of the nodes are designed identically. Each node is capable of handling multilevel data. Each node has a MLS/DBMS, which manages the local multilevel database. Each node also has a distributed processing component called the Secure Distributed Processor (SDP).

  25. - The modules of the SDP are similar to those of the DDBMS described above. - These modules are the Secure Distributed Query Processor (SDQP), the Secure Distributed Transaction Manager (SDTM), the Secure Distributed Metadata Manager (SDMM), the Secure Distributed Security Manager (SDSM) and the Secure Distributed Integrity Manager (SDIM). - Multilevel security must be taken into consideration during all of the processing. - First of all, an appropriate security policy has to be formulated. - This policy will depend on the policies of the local DBMS, the network and the distributed processor. - The algorithms for query, update and transaction processing in a DDBMS have to be extended to handle multilevel security. Locking techniques could cause covert channels.

  26. Therefore, algorithms for MLS/DBMSs have to be integrated with algorithms for DDBMSs to handle MLS/DDBMSs. These algorithms are implemented by the SDTM. • - Finally, security and integrity processing techniques for MLS/DBMSs and DDBMSs have to be extended for MLS/DDBMSs. • - For example, in the case of the SDSM, it has to consider multilevel security within functions such as: • - identification, • - authentication, • - enforcing discretionary security controls.

  27. Inference Problem - The inference problem has received a great deal of attention for many years. - There is still work on this problem especially with emerging technologies such as data warehousing, data mining and the web. -Inference is the process of users posing queries and deducing unauthorized information from the legitimate responses that they receive. This problem has been discussed a great deal over the past two decades. However, data mining makes this problem worse. Users now have sophisticated tools that they can employ to get data and deduce patterns that could be sensitive. Without these data mining tools, users would have to be fairly sophisticated in theirreasoning to be able to deduce information from posing queries to the databases. In short, data mining tools make the inference problem quite dangerous.

  28. An extensive investigation of the inference problem for distributed database systems began around 1992. This approach was based on processing security constraints in a multilevel secure distributed database system. Heterogeneous and Federated Systems The earliest effort to investigate multilevel security for heterogeneous and federated database systems began around 1991. The issuesincludesecurity for integrating the federated schemas as well as handling different ranges of security levels. For example, one system could handle the range from Secret to Top-Secret, whileanother system could handle the range from Unclassified to Secret. Much of the work on integrating heterogeneous database schemas in a secure environmentfocused on query processing issues. The approaches examined both the multidatabase and the nonmultidatabase architectures.

  29. Around 1992, the MITRE Corporation began an effort called MUSET (Multilevel Secure Transactions) database system. This effort focused mainly on transaction management in a heterogeneous database system. This effort also investigated concurrency control, recovery and commit protocols for multilevel transactions. A multilevel transaction is a transaction that can operate at multiple security levels. For example, a sub-transaction at one site could operate at the unclassified level, while another sub-transaction at a different site could operate at the Secretlevel. The challenge here is to ensure consistency and at the same time minimize covert channels. Other work on secure distributed database systems includes various concurrency control algorithms for transactions.

  30. Discretionary Security Discretionary security mechanisms enforce rules which specify the types of access that users or groups of users have to the data. Multilevel security controls ensure that users cleared at different security levels access and share a distributed database in which the data is assigned different sensitivity levels without compromising security. Distributed environment users must be authenticated with respect to : - The local system, - The global environment. The authentication mechanism should be: - Centralized: The authenticator needs to have information about all of the users of the system. - Distributed: The various components of the authenticator need to communicate with each other to authenticate a user.

  31. The access control rules enforced in a distributed environment may be: 1- Centralized: Central server needs to check all accesses to the database. 2- Distributed: Appropriate rules need to be located and enforced for a particular access. Often the rules associated with a particular database may also be stored at the same site. 3-Replicated: Each node can carry out the access control checks for the data that it manages.

  32. Security for Emerging Distributed System Technologies Emerging technologies that have evolved in some way fromdistributed databases and their security impact: - Warehouses systems, - Data mining systems, - Collaborative computing systems, - Distributed object systems, - The web. Data warehousing systems: - Ensuring that security is maintained in building a data warehouse from the backend database systems. - Enforcing appropriate access control techniques when retrieving the data from the warehouse.

  33. For example, security policies of the different data sources that form the warehouse have to be integrated to form a policy for the warehouse. This is not a straightforward task, as one has to maintain security rules during the transformations. For example, one cannot give access to an entity in the warehouse, while the same person cannot have access to that entity in the data source. - Enforce the warehouse security policy. - Audit the warehouse. - The inference problem. For example, the warehouse may storeaverage salaries. A user can access average salaries and then deduce the individual salaries in the data sources, which may be sensitive and therefore, the inference problem could become an issue for the warehouse. To date, little work has been reported on security for data warehouses as well as the inference problem for the warehouse. This is an area that needs much research !!

  34. Data mining causes serious security problems. For example, consider a user who has the ability to apply data mining tools. This user can pose various queries and infer a sensitive hypothesis. That is, the inference problem occurs via data mining. There are various ways tohandle this problem. - One is that weare applying only one tool. Furthermore, it is impossible to cover all of the ways that the inference problem could occur. - Another solution to the inference problem is to build an inference controller that can detect the motives of the user and prevent the inference problem from occurring. Such an inference controller lies between the data-mining tool and the data source or database, possibly managed by a DBMS. Distributed data mining systemsare being extended to function in a distributed environment. Security problems may be exacerbated in these systems. This area has received very little attention.

  35. Other emerging technologies that have evolved in some way from distributed databases arecollaborative computing systems, distributed object management systems and the web. Much of the work on securing distributed databases can be applied to securing collaborative computing systems. With respect to distributed object systems security, there is a lot of work by the Object Management Group's Security Special Interest Group. More recently, there has been much work on securing the web. The main issue here is ensuring that the databases, the operating systems, the applications, the web servers, the clients and the network are not only secure, but arealso securely integrated.

  36. Conclusion Distributed database systems are a reality. Many organizations are now deploying distributed database systems. Therefore, we have no choice but to ensure that these systems operate in asecure environment. We believe that as more and more technologies emerge, the impact of securedistributed database systems on these technologies will be significant .