Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Commitment ordering wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Serializability wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Relational model wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Functional Database Model wikipedia , lookup
ContactPoint wikipedia , lookup
Database model wikipedia , lookup
Data and Applications Security Developments and Directions Dr. Bhavani Thuraisingham The University of Texas at Dallas Security for Distributed Data Management February 25, 2011 Outline Distributed Database Systems - Architecture, Data Distribution, Functions Security Issues - Discretionary Security, Multilevel Security Secure Heterogeneous and Federated Systems Single Sign-on and Identity Management Assumption: Network is secure; focusing on securing the data Distributed Architecture Database 1 Database 3 DBMS 3 Distributed Processor 3 Site 3 DBMS 1 Distributed Processor 1 Communication Network Site 1 Database 2 Distributed Processor 2 DBMS 2 Site 2 Data Distribution SITE 1 EMP1 DEPT1 SS# Name Salary D# D# Dname MGR 1 2 3 4 5 6 John Paul James Jill Mary Jane 20 30 40 50 60 70 10 20 20 20 10 20 10 C. Sci. Jane 30 English David 40 French Peter D# DEPT2 Dname MGR 50 Math John 20 Physics Paul SITE 2 EMP2 SS# 9 Name Mathew Salary 70 D# 50 7 David 80 30 8 Peter 90 40 Distributed Database Functions Distributed Query Processing - Optimization techniques across the databases Distributed Transaction Management - Techniques for distributed concurrency control and recovery Distributed Metadata Management - Techniques for managing the distributed metadata Distributed Security/Integrity Maintenance - Techniques for processing integrity constraints and enforcing access control rules across the databases Secure Distributed Architecture global user local user Secure Distributed Processor S-DBMS Database Secure Network Secure Distributed Processor S-DBMS Database Secure Distributed Processor S-DBMS Database Discretionary Security Mechanism Discretionary Discretionary Security for distributed database systems Access Control and Authorization Policies enforced across the databases Administration Policies Policies enforced across the databases Identification and Authentication Policies enforced across the databases Security Policy Integration Integrated MLS Network Policy Network Distributed Distributed/ Security Policy for database system A Security Policy for database system B Security Policy for database system C Views for Security SITE 1 EMP1 SS# 1 2 3 4 5 6 Name John Paul James Jill Mary Jane DEPT1 Salary 20 30 40 50 60 70 D# 10 20 20 20 10 20 7 8 Name Mathew David Peter Dname C. Sci. MGR Jane 30 English David 40 French Peter SITE 2 EMP2 SS# 9 D# 10 Salary 70 80 90 D# 50 30 40 D# Paul James Jill Jane MGR 50 Math John 20 Physics Paul EMP-DEPT View (all those who work in the Physics Department) Ename DEPT2 Dname Secure Distributed Database Functions Secure Distributed Database Functions: Distributed Query Processing: Enforce access control rules during query processing across databases; distributed inference control; consider security constraints during distributed query optimization Distributed Transaction Management: Ensure security constraints are satisfied during transaction processing. Metadata management: Enforce access control on distributed metadata Integrity management: Ensure that integrity of the data is maintained while enforcing security across the databases Architecture for Multilevel Security global user local user Multilevel Secure Network Secure Distributed Processor Secure Distributed Processor MLS/DBMS MLS/DBMS MLS/DBMS Multilevel Database Multilevel Database Multilevel Database Secure Distributed Processor Multilevel Distributed Data Model SITE 1 DEPT1 = Unclassified EMP1 = Secret SS# 1 2 3 4 5 6 Name John Paul James Jill Mary Jane Salary 20 30 40 50 60 70 D# 10 20 20 20 10 20 7 8 Name Mathew David Peter Salary 70 80 90 Dname C. Sci. MGR Jane 30 English David 40 French Peter SITE 2 EMP2 = Secret SS# 9 D# 10 D# 50 30 40 DEPT2 = Unclassified D# Dname MGR 50 Math John 20 Physics Paul MLS/DDBMS Functions Distributed Query Processor Functions of an MLS/DDBMS Site A Distributed Transaction Processor Distributed Query Processor Distributed Transaction Processor Functions of an MLS/DDBMS Site B Distributed Metadata Manager Distributed Metadata Manager Distributed Inference Controller Network Distributed Inference Controller Distributed Inference Controller DBMS DBMS Database Database Distributed Inference Controller DBMS Database Interoperability of Heterogeneous Database Systems Database System A Database System B (Relational) (ObjectOriented) Network Transparent access to heterogeneous databases both users and application programs; Query, Transaction processing Database System C (Legacy) Technical Issues on the Interoperability of Heterogeneous Database Systems Heterogeneity with respect to data models, schema, query processing, query languages, transaction management, semantics, integrity, and security policies Federated database management - Collection of cooperating, autonomous, and possibly heterogeneous component database systems, each belonging to one or more federations Interoperability based on client-server architectures Federated Database Management Database System A Database System B Federation F1 Cooperating database systems yet maintaining some degree of autonomy Federation F2 Database System C Schema Integration and Transformation in a Federated Environment External Schema 1.1 External Schema 2.1 External Schema 1.2 Federated Schema for FDS - 2 Federated Schema for FDS - 1 Export Schema for Component A Generic Schema for Component A Component Schema for Component A External Schema 2.2 Export Schema I for Component B Export Schema II for Component B Export Schema for Component C Generic Schema for Component B Generic Schema for Component C Component Schema for Component B Component Schema for Component C Adapted from Sheth and Larson, ACM Computing Surveys, September 1990 Client-Server Architecture: Example Client from Vendor A Client from Vendor B Network Server from Vendor C Database Server from Vendor D Database Security Issues Transforming secure data models Secure architectures: Heterogeneous and federated data management Security impact on schema/data/policy integration Incomparable/Overlapping security levels Inference Control Secure client-server computing Transforming Secure Data Models EMP: Level = Secret SS# Ename Salary D# 1 John 20K 10 2 Paul 30K 20 3 Mary 40K 20 Class EMP is Secret It has 3 instances: John, Paul and Mary Class DEPT is Unclassified DEPT Mgr Level It has 2 instances Math and Physics D# Dname 10 Math Smith U Math is Unclassified 20 Physics Jones C Physics is Confidential Security Architecture: Heterogeneous data management global user local user Secure Network S-Heterogeneous Distributed Processor SDBMS 1 Secure Database 1 S-Heterogeneous Distributed Processor SDBMS 2 Secure Database 2 S-Heterogeneous Distributed Processor SDBMS 3 Secure Database 3 Security Architecture: Federated data management global user Secure Network local user S-Federated Distributed Processor SDBMS 1 Secure Database Database 1 1 S-Federated Distributed Processor SDBMS 2 Secure Database Database 1 2 S-Federated Distributed Processor SDBMS 3 Secure 1 Database 3 Federated Data and Policy Management Data/Policy for Federation Export Data/Policy Export Data/Policy Export Data/Policy Component Data/Policy for Agency A Component Data/Policy for Agency C Component Data/Policy for Agency B Incomparable Security Levels TopSecret Trusted Guard Secret Node B Confidential DBMS A Unclassified Node A Overlapping Security Levels TopSecret Secret Secret Node B Confidential DBMS A Unclassified Node A Inference Control Federated Inference Controller Federated Data Management Export Engine Export Engine Export Engine Inference Controller Component Data System for Agency A Inference Controller Inference Controller Component Data System For Agency C Component Data System for Agency B Secure Client-Server Computing Secure Client 1 Middle Tier: Policy Enforcement Secure Client 2 Secure Client 3 Middle Tier: Schema Enforcement Secure Network Secure Data Server 1 Secure Data Server 2 Comments Techniques for centralize data management have to be extended for a distributed/heterogeneous/federated environment Access control enforced across databases Inference control across databases Web will continue to impact the development of secure distributed data managers Network security is critical Single Sign-On Single sign-on (SSO) is a method of access control that enables a user to log in once and gain access to the resources of multiple software systems without being prompted to log in again. Single sign-off is the reverse process whereby a single action of signing out terminates access to multiple software systems. As different applications and resources support different authentication mechanisms, single sign-on has to internally translate to and store different credentials compared to what is used for initial authentication Single Sign-On Kerberos based Initial sign-on prompts the user for credentials, and gets a Kerberos ticket-granting ticket (TGT.) Additional software applications requiring authentication, such as email clients, wikis, revision control systems, etc, use the ticket-granting ticket to acquire service tickets, proving the user's identity to the mailserver / wiki server / etc. without prompting the user to re-enter credentials. Windows environment - Windows login fetches TGT. Active directory-aware apps fetch service tickets, so user is not prompted to re-authenticate. UNIX/Linux environment - Login via Kerberos PAM modules fetches TGT. Kerberized client applications such as Evolution, Firefox, and SVN use service tickets, so user is not prompted to re-authenticate. Single Sign-On Smart card based: Initial sign on prompts the user for smart card. Additional software applications also use the smart card, without prompting the user to re-enter credentials. Smart card-based single sign-on can either use certificates or passwords stored on the smart card Client Certificate Based: Shared Authentication Schemes which are not Single Sign-On - Single sign on requires that users literally sign in once to establish their credentials. Systems which require the user to log in multiple times to the same identity are inherently not single sign on. For example, an environment where users are prompted to log in to their desktop, then log in to their email using the same credentials, is not single sign on. Shared authentication schemes like OpenID, which require additional sign-on for each web site, are also not single sign on. Single Sign-On Enterprise Single Sign-On - Enterprise single sign-on (E-SSO) systems are designed to minimize the number of times that a user must type their ID and password to sign into multiple applications. - The E-SSO solution automatically logs users in, and acts as a password filler where automatic login is not possible. Each client is typically given a token that handles the authentication, on other E-SSO solutions each client has E-SSO software stored on their computer to handle the authentication. On the server side is usually an E-SSO authentication server that is implemented into the enterprise network. Federated Identity Management Federated identity, or the ‘federation’ of identity, describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration. Identity federation comes in many flavors, including ‘user-controlled’ or ‘user-centric’ scenarios, as well as enterprise controlled or B2B scenarios. Federated Identity Management Federation is enabled through the use of open industry standards and/or openly published specifications, such that multiple parties can achieve interoperability for common use cases. Typical use-cases involve things such as cross-domain, web- based single sign-on, cross-domain user account provisioning, cross-domain entitlement management and cross-domain user attribute exchange. Federated Identity Management Use of identity federation standards can reduce cost by eliminating the need to scale one-off or proprietary solutions. It can increase security and lower risk by enabling an organization to identify and authenticate a user once, and then use that identity information across multiple systems, including external partner websites. It can improve privacy compliance by allowing the user to control what information is shared, or by limiting the amount of information shared. It can drastically improve the end-user experience by eliminating the need for new account registration through automatic ‘federated provisioning’ or the need to redundantly login through cross-domain single sign-on. Federated Identity Management Leading enterprises around the world have deployed identity federation to get closer with partners, improve customer service, accelerate execution of business partnerships and alliances, cut cost and complexity of integrating outsourced services, and free themselves from vendor lock-in. End-users and consumer focused web sites are now beginning to engage in identity federation through the adoption of OpenID, which is an open source specification for enabling federation use-cases. Federated Identity Management The notion of identity federation is extremely broad, and also evolving. It could involve user-to-user, user-to-application as well as application-to-application use-case scenarios at both the browser tier as well as the web services or SOA (serviceoriented architecture) tier. It can involve high-trust, high-security scenarios as well as low-trust, low security scenarios. The levels of identity assurance that may be required for a given scenario are also being standardized through a common and open Identity Assurance Framework. It can involve user-centric use-cases, as well as enterprise- centric use-cases. The term ‘identity federation’ is by design, a generic term, and is not bound to any one specific protocol, technology, implementation or company. Federated Identity Management One thing that is consistent, however, is the fact that ‘federation’ does describe methods of identity portability which are achieved in an open, often standards-based manner – meaning anyone adhering to the open specification or standard can achieve the full spectrum of use-cases and interoperability. Identity federation can be accomplished any number of ways, some of which involve the use of formal Internet standards, such as the OASIS SAML specification, and some of which may involve open source technologies and/or other openly published specifications, (e.g. Information Cards, OpenID, the Higgins trust framework or Novell’s Bandit project).