Upload
daquan-burch
View
26
Download
1
Tags:
Embed Size (px)
DESCRIPTION
Data and Applications Security Developments and Directions. Dr. Bhavani Thuraisingham The University of Texas at Dallas Security for Distributed Data Management October 1, 2010. Outline. Distributed Database Systems Architecture, Data Distribution, Functions Security Issues - PowerPoint PPT Presentation
Citation preview
Data and Applications Security Developments and Directions
Dr. Bhavani Thuraisingham
The University of Texas at Dallas
Security for Distributed Data Management
October 1, 2010
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
Communication NetworkDistributed Processor 1
DBMS 1
Data-base 1 Data-
base 3
Data-base 2 DBMS 2
DBMS 3
Distributed Processor 2
Distributed Processor 3
Site 1
Site 2
Site 3
Data Distribution
EMP1
SS# Name Salary
1 John 20 2 Paul 303 James 404 Jill 50
605 Mary6 Jane 70
D#
102020 201020
DnameD# MGR
10 30 40
Jane David Peter
DEPT1
SITE 1
SITE 2EMP2
SS# Name Salary9 Mathew 70
D#50
DnameD# MGR
50 Math John
Physics
DEPT2
David 80 30
Peter 90 40
7
8
C. Sci. English French
20 Paul
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
localuserlocaluser
SecureNetworkSecureNetwork
SecureDistributedProcessor
SecureDistributedProcessorDistributedProcessor
S-DBMS
DatabaseDatabase
S-DBMS S-DBMS
DatabaseDatabase DatabaseDatabase
SecureDistributedProcessor
SecureDistributedProcessorDistributedProcessor
SecureDistributedProcessor
SecureDistributedProcessorDistributedProcessor
Discretionary Security Mechanism
Access Control and AuthorizationPolicies
AdministrationPolicies Identification and Authentication Policies
Discretionary
Security
Discretionary
Security
Access Control and AuthorizationPolicies enforced across the databases
AdministrationPolicies enforcedacross the databases
Identification and Authentication Policies enforcedacross the databases
Discretionary
SecurityDiscretionarySecurity for distributed database systems
Security Policy Integration
Network
Distributed
MLS Network
Distributed/
Network
Distributed
Integrated Policy
Security Policyfor database systemA
Security Policyfor database systemB
Security Policyfor database systemC
Views for Security
EMP1
SS# Name Salary
1 John 202 Paul 303 James 404 Jill 50
605 Mary6 Jane 70
D#
102020201020
DnameD# MGR
10
30
40
Jane
David
Peter
DEPT1
SITE 1
C. Sci.
English
French
SITE 2EMP2
SS# Name Salary9 Mathew 70
D#50
DnameD# MGR
50 Math John
Physics
DEPT2
David 80 30
Peter 90 40
7
8 20 Paul
Ename
PaulJamesJillJane
EMP-DEPT View(all those who work in the Physics Department)
Secure Distributed Database Functions
Secure Distributed Database Functions:
Distributed Query Processing: Enforce access control rulesduring 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
localuser
Multilevel SecureNetwork
SecureDistributedProcessor
MLS/DBMS
MultilevelDatabase
MLS/DBMS MLS/DBMS
MultilevelDatabase
MultilevelDatabase
SecureDistributedProcessor
SecureDistributedProcessor
Multilevel Distributed Data Model
EMP1 = Secret
SS# Name Salary
1 John 202 Paul 303 James 404 Jill 50
605 Mary6 Jane 70
D#
102020201020
DnameD# MGR
10
30
40
Jane
David
Peter
DEPT1 = UnclassifiedSITE 1
C. Sci.
English
French
SITE 2EMP2 = Secret
SS# Name Salary9 Mathew 70
D#50
DnameD# MGR
50 Math John
Physics
DEPT2 = Unclassified
David 80 30
Peter 90 40
7
8 20 Paul
MLS/DDBMS Functions
DistributedQueryProcessor
DistributedTransactionProcessor
DistributedMetadataManager
Functionsof an MLS/DDBMS
Site A
Functionsof an MLS/DDBMS
Site B
DistributedQueryProcessor
DistributedTransactionProcessor
DistributedMetadataManager
Distributed Inference Controller
Network
Distributed
InferenceController
Distributed
InferenceController
DistributedInference Controller
DBMS DBMS DBMS
Database Database Database
Network
Distributed
InferenceController
Distributed
InferenceController
DistributedInference Controller
DBMS DBMS DBMS
Database Database Database
Interoperability of Heterogeneous Database Systems
Database System A Database System B
Network
Database System C(Legacy)
Transparent accessto heterogeneousdatabases - both usersand application programs;Query, Transactionprocessing
(Relational) (Object-Oriented)
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
Database System C
Cooperating databasesystems yet maintainingsome degree ofautonomy
Federation F1
Federation F2
Schema Integration and Transformation in a Federated Environment
Adapted from Sheth and Larson, ACM Computing Surveys, September 1990
Component Schema for Component A
Component Schema for Component B
Component Schema for Component C
Generic Schema for Component A
Generic Schemafor Component B
Generic Schemafor Component C
Export Schemafor Component A
Export Schema Ifor Component B
Export Schemafor Component C
Federated Schemafor FDS - 1
Federated Schemafor FDS - 2
ExternalSchema 1.2 Schema 2.1
ExternalSchema 2.2
ExternalSchema 1.1
Export Schema IIfor Component B
External
Client-Server Architecture: Example
Network
Clientfrom Vendor A
Clientfrom Vendor B
Serverfrom Vendor C Server
from Vendor D
Database 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 SecretIt has 3 instances:
John, Paul and Mary
DEPT
D# Dname Mgr
10 Math Smith U
20 Physics Jones C
Level
Class DEPT is UnclassifiedIt has 2 instances Math and Physics
Math is UnclassifiedPhysics is Confidential
Security Architecture: Heterogeneous data management
global user
localuserlocaluser
Secure Network
S-HeterogeneousDistributedProcessor
S-HeterogeneousDistributedProcessorDistributedProcessor
SDBMS 1
SecureDatabase
1
Secure
1
SDBMS 2 SDBMS 3
S-HeterogeneousDistributedProcessor
S-HeterogeneousDistributedProcessorDistributedProcessor
S-HeterogeneousDistributedProcessor
S-HeterogeneousDistributedProcessorDistributedProcessor
SecureDatabase
2
SecureDatabase
3
Security Architecture: Federated data management
global user
localuserlocaluser
Secure Network
S-FederatedDistributedProcessor
S-FederatedDistributedProcessorDistributedProcessor
SDBMS 1
SecureDatabase
11
SecureDatabase
11
SDBMS 2 SDBMS 3
S-FederatedDistributedProcessor
S-FederatedDistributedProcessorDistributedProcessor
S-FederatedDistributedProcessor
S-FederatedDistributedProcessorDistributedProcessor
SecureDatabase
21
SecureDatabase
3
1
global user
localuserlocaluser
Secure Network
S-FederatedDistributedProcessor
S-FederatedDistributedProcessorDistributedProcessor
SDBMS 1
Secure
1
SecureDatabase
1
SDBMS 2 SDBMS 3
S-FederatedDistributedProcessor
S-FederatedDistributedProcessorDistributedProcessor
S-FederatedDistributedProcessor
S-FederatedDistributedProcessorDistributedProcessor
SecureDatabase
2
SecureDatabase
3
Federated Data and Policy Management
ExportData/Policy
ComponentData/Policy for
Agency A
Data/Policy for Federation
ExportData/Policy
ComponentData/Policy for
Agency C
ComponentData/Policy for
Agency B
ExportData/Policy
Incomparable Security Levels
Node B
Node A
Confidential
TopSecret
Trusted Guard
DBMS AUnclassified
Secret
Confidential
TopSecret
Trusted Guard
DBMS AUnclassified
Secret
Inference Control
ExportEngine
Component Data System for Agency A
Federated Data Management
ExportEngine
ComponentData SystemFor Agency C
ComponentData Systemfor Agency B
ExportEngine
Federated Inference Controller
Inference Controller
Inference Controller
Inference Controller
ExportEngine
Component Data System for Agency A
Federated Data Management
ExportEngine
ComponentData SystemFor Agency C
ComponentData Systemfor Agency B
ExportEngine
Federated Inference Controller
Inference Controller
Inference Controller
Inference Controller
ExportEngine
Component Data System for Agency A
Federated Data Management
ExportEngine
ComponentData SystemFor Agency C
ComponentData Systemfor Agency B
ExportEngine
Federated Inference Controller
Inference Controller
Inference Controller
Inference Controller
ExportEngine
Component Data System for Agency A
Federated Data Management
ExportEngine
ComponentData SystemFor Agency C
ComponentData Systemfor Agency B
ExportEngine
Federated Inference Controller
Inference Controller
Inference Controller
Inference Controller
Secure Client-Server Computing
Secure Client 1
SecureClient 2
SecureClient 3
SecureData Server 1
SecureData Server 2
Secure NetworkMiddle Tier:Policy Enforcement
Middle Tier:Schema Enforcement
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 (service-oriented 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).