Security in Distributed Systems – A look at Globus

advertisement
Security in Distributed
Systems – A look at Globus
Stephen Rook
srook1@umbc.edu
December 4, 2007
Overview
Background – security’s role in
distributed systems
 Overview of Globus
 Globus Security Policy
 Globus Security Architecture
 Questions

2
Background
Security Overview

Why do we need to consider security
issues for distributed systems?

The main goal is to protect the system and its
resources from unauthorized use.
 Authentication

Ex: Is “Adam” truly Adam, an employee in good-standing
of a company’s branch in New York, or is “Adam” truly
Damien, a recently fired employee whose ultimate goal is
to take down the company server?
 Authorization

Ex: Does Adam have write privileges on a file foo.txt
located on the company’s Los Angeles server?
4
Security Overview (2)

Why is it so difficult to implement security on
distributed systems?

Resources can span many geographic domains.



The system must keep track of where its resources are
located
Ex: An employee on subnetwork A in the U.S. wishes to
access a file stored on the company server on subnetwork C
located in Germany.
For some resources, only certain classes of users can
be allowed access.


Falls under the authorization domain
Ex: Suppose we have two low-level employees, John and
Sam. John should not be able to access Sam’s employment
record even though they both work for the same company.
However, Sam’s supervisor should have access rights.
5
Security Overview (3)

Most distributed systems are heterogeneous
 They
are comprised of mixed types of computers
and resources

Ex: Grid systems
 Need
to define protocols to safely access system
components no matter where such components
reside
6
Globus Overview
Globus
Proposed by Foster, Kesselman, and
Tuecke in 1998
 Version 0.1 (the first) was implemented in
April 2000
 Version 4.1 was released September 2007
 Designed for grid computing
 Security of the vast number of
components in the entire system is the
prime concern

8
Implementation – Earth System
Grid (ESG)




A distributed system that stores and provides a wealth of
climatology data to users.
Some services require authorization and thus users must
be authenticated.
Problem: With so many user accounts, how to ensure
that authentication works correctly while allocating the
majority of processing time to the multitude of data
requests?
Solution: Use global authentication as provided by the
Globus toolkit.

Once authenticated globally, a user is free to use the
subsystems/services that he/she is authorized.

Will return to this point later.
9
Overview
Background – security’s role in distributed
systems
 Overview of Globus
 Globus Security Policy
 Globus Security Architecture
 Questions

10
Globus Security Policy
Globus Security Policy

Security Policy: a collection of general
statements that detail the critical
components of a system and how these
components should be protected.


Effective security mechanisms require a
comprehensive and well-designed security
policy.
Globus’ security policy consists of 8
statements/assumptions.
12
The Global System Consists of
Multiple Subsystems (#1)


Multiple existing disjoint subsystems (most likely
heterogeneous) need to be seamlessly integrated under
a minimal number of standardized security protocols.
Ex: Suppose that companies A, B, & C, offering the
same service, have merged after independently
operating for years. Now suppose that the 3 companies
have merged and wish to integrate their websites.



Most likely, each website is managed by a different security
policy and has different critical resources.
The goal is to integrate the subsystems in such a way so that
membership in the global union does not override the local
security policy of any subsystem.
Thus, the global authority need only consider actions
that span multiple subsystems.
13
Figure 1. (Left) 3 subsystems that run independently of
each other. (Right) The same 3 subsystems connected
to a global authority (G) . The functionality of the 3
subsystems should change very little if at all even though
they are now connected through the global authority.
14
Local Operations are Subject to
Local Security Policies Only (#2)
Complements the first assumption.
 Ex: Suppose that an entity in domain B
wishes to utilize a file housed in domain B.

Local operation.
 Just as if domain B was running
independently of Globus and any other
subsystems.
 Globus should recognize local operations and
not impose further restrictions.

15
Global Operations (#3)
Operations that affect more than 1 domain
in the distributed system.
 Require the initiator to be known in each
domain where the operation is executed.


Ex: If Adam wishes to update a file located in
domains A, B, and C, each domain must
authenticate him before he can be allowed to
perform the update.
16
Operations Between Entities in
Different Domains (#4)


Requires mutual authentication by both
domains.
Extends the previous statement in both
directions.

Ex: Suppose Adam located in domain A wishes to
use a mail server located in domain B.

Not only must Adam be authenticated by domain B to use the
mail server, but the mail server must also be authenticated by
domain A.

The latter condition ensures Adam that he is indeed using the
mail server from domain B and not malicious software.
17
Global Authentication Replaces
Local Authentication (#5)


With many users, authenticating each resource
request locally makes scalability impossible.
Global authentication by Globus supersedes
local authentication.


Improves performance of the distributed system.
Ex: Suppose Adam located in domain A wants
to perform operations in domains B and C.



Adam must be authenticated in domains B and C.
Instead, allow Globus to globally authenticate Adam.
Adam can now be considered authenticated in
domains B and C if both domains recognize Adam.

Recognition takes less processing time than authentication.
18
Controlling Access to Resources
(#6)

Subject to local security only.


Globus would become overwhelmed if it had to track
the security status of the numerous resources.
Ex: Suppose Adam located in domain A wishes
to modify a file located in domain B and has
already been globally authenticated.


Even though Adam has been authenticated, his
access rights to the file still must be checked.
Access rights are checked by the file’s local domain –
in this case domain B.
19
Users can Delegate Rights to
Processes (#7)


A user should be able to copy his/her
authentication and access rights to created
processes.
Ex: Suppose that Adam located in domain A
has been globally authenticated. He wishes to
deploy processes P1 and P2 to repeatedly poll
files located in domains B and C respectively.


Adam can pass his authentication certificate to
processes P1 and P2.
P1 receives access rights for the files needed in
domain B and P2 receives access rights for the files
needed in domain C.
20
Users can Delegate Rights to
Processes (continued)


Globus globally authenticates the processes (verifying
that they are from Adam).
The processes can then begin working in their
respective domains as if they were Adam himself.


Efficient for processes that initiate many remote operations.
Otherwise, domain B would have to contact Adam for
authentication EVERY time that P1 initiated an operation.

The communication cost for this persistent validation may prove
to be prohibitive especially if domains A and B are great
distances apart.
21
A Group of Processes in the Same
Domain can Share Credentials (#8)

Multiple processes attributed to a single user
located in a remote domain can share one set of
authentication and access rights.


Known as credentials.
Ex: Suppose Adam located in domain A has
multiple processes P1, P2, and P3 operating in
domain B.



The 3 processes share a set of credentials.
Credentials are easily modified even if there are a
large number of processes.
Easily scalable – space is conserved since only one
copy of the credentials need be present per domain.
22
Globus Security
Architecture
Globus Architecture Overview

Assumes that local resources are
protected by the local security policy.


Globus need only mediate when requests
span multiple subsystems.
Important implementation issues:
How a user is represented in a remote
domain.
 How remote resources are allocated to users.

24
Globus Architecture Overview
(continued)

Globus architecture is described using entities:





Users
User proxies: processes that are given permission to
act on behalf of a user temporarily.
Resource proxies: processes used to translate a
remote user’s requests into operations that do not
violate a resource’s local security policy.
General processes
Globus has defined four protocols using entities.

Consistent with the aforementioned security policy.
25
Creation of a User Proxy &
Delegating User Rights (#1)


First, a process is created by the user in his/her
local subsystem.
To act as the user, the process must be given an
identifying key linked to the user.



This key is a tuple comprised of the user’s id, name of
the local host, authentication lifetime, etc.
The user then digitally signs the tuple, indicating the
validity of the proxy to remote domains.
The proxy is then provided with the key and
allowed to execute in a remote domain.

It is the responsibility of the local security policy to
protect this key.
26
Requesting the Allocation of a
Remote Resource (#2)



A user proxy (UP) locates the resource proxy
(RP) for the resource it wishes to access.
The UP and RP authenticate each other.
The RP checks if the resource is available.


If the request can be honored, the RP allocates the
resource to the UP.
Otherwise, the RP denies access and it is up to the
UP to try again after some specified passage of time.
27
Allocation of a Resource by a
Remote Process (#3)


Essentially follows the second protocol.
Ex: A resource allocated to a UP may spawn
process Pα that requires an additional resource
R1.

The request to R1’s RP must come from the UP, NOT
Pα.

Advantages: Simplicity and greater security.


Allowing only UPs to initiate resource requests decreases the
potential locations for security breaches.
Disadvantage: scalability is limited due to a single point of
requests (UP).
28
Recognizing a User in a Remote
Domain (#4)


First, the user authenticates globally with
Globus.
A subsystem-wide mapping of the global
authentication to a local authentication is
accessible by the RP.


The exact implementation varies with each domain.
Examples include trees and linked lists.
The user is considered authenticated for domain
X if the RP can find a mapping from the user’s
global authentication to his/her local
authentication for domain X.

The remote domain thus recognizes the user.
29
30
References
1.
2.
3.
4.
Tanenbaum and Van Steen. Distributed
Systems – Principles and Paradigms.
2nd ed. 2007.
Foster and Kesselman. “Globus: A
Metacomputing Infrastructure Toolkit.”
1996.
Foster et al. “A Security Architecture for
Computational Grids.” 1998.
Globus Alliance. http://globus.org.
31
References
5.
Earth System Grid.
http://earthsystemgrid.org.
32
Questions?
33
Download