Download Lecture12 - The University of Texas at Dallas

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).