Security problems and solutions of the hottest gri

2022-10-15
  • Detail

Abstract: This paper discusses the security problems and security strategies in the lattice computing environment, and introduces the latest lattice security architecture in the world. This structure has been proved to be available by experiments, and it also provides a solid foundation for the development of more advanced mechanisms. Finally, the grid security solution of globus is introduced, and suggestions are put forward for the research of grid security in China

I. Introduction

human application needs are rapidly developing towards high-performance, diversity and multi-function. Many large-scale scientific computing applications not only need a high-performance computer, but also need a network virtual supercomputer composed of multiple machines, multiple systems and multiple scientific instruments. These applications require a variety of geographically distributed and heterogeneous computing resources to be connected through high-speed networks to jointly complete computing problems. Grid computing was born under this background. Although lattice computing has appeared for only a few years, the research on lattice computing has been accelerating significantly recently. Some foreign government departments, research institutions, universities and enterprises have increased investment and launched a new round of research plans and projects, trying to maintain a leading position in this research field and seize the opportunity of the future application market. A similar upsurge of research has emerged in China, and the country will invest a lot of human and financial resources in lattice computing research

One of the biggest advantages of

lattice computing is that it is conducive to the sharing of geographically distributed computing resources and data resources, but these sharing must be based on secure access. This paper will introduce the security problems, security requirements, security policies, security architecture and security solutions involved in lattice computing one by one

second, the security problems faced by lattice computing

the application of lattice computing is different from traditional client/server applications in that it requires the simultaneous use of a large number of resources, dynamic resource requests, the use of resources in multiple management domains, complex communication structures, and strict performance requirements

due to the requirements of scalability, performance and heterogeneity are the goals of any distributed system, but the characteristics of lattice computing lead to the problems that can not be solved by the existing security technology in the distributed system. For example, parallel computing composed of multiple computable resources requires a much more complex security relationship than the client/server model, involving multiple management domains; The dynamic characteristics of lattice computing make it impossible for applications to establish trust relationships between sites before implementation; The inter domain security solution used by lattice must be able to work with different intra domain access control technologies, or even replace them

specifically, the security problems faced by lattice computing can be divided into three categories: the integration of existing systems and technologies; The ability of different host environments to work together; The trust relationship between the host environments that affect each other

technology integration

whether for technical reasons or other reasons, it is unrealistic to expect a certain security technology to solve the security problem of possessive computing. The existing security architecture cannot be replaced overnight. For example, each domain in the grid environment may have one or more registers (such as LDAP directory) for storing user accounts, which cannot be shared with other organizations or domains. Similarly, the authentication mechanism that is considered safe and reliable in the existing environment will continue to be used. Therefore, these technologies that tend to use a single mode or mechanism are unlikely to be easily replaced

in order to succeed, lattice security architecture needs to transition to the integration of existing security architecture and cross platform and cross host mode. This means that the architecture can be implemented by existing security mechanisms (such as Kerberos, PKI), and at the same time, it should be scalable and integrated

ability to work together

services across multiple domains and host environments need to be able to interact and work together. The ability of collaborative work is mainly manifested in the following levels

protocol layer: we need a mechanism for exchanging information between domains, which can be obtained through soap/http

policy layer: in order to have a secure session, each party involved in the collaborative work must be able to specify any strategies it wants, and these strategies must also be easily understood by other parties. In this way, all parties can try to establish a secure communication channel and security semantics related to mutual authentication and trust relationship

authentication layer: we need to have a mechanism to authenticate users in one domain from another. This requirement goes beyond the need to define trust relationships and obtain Federation between security mechanisms (such as Kerberos tickets to X.509 certificates). If a certain identity can be pre-defined to span multiple domains, this is of course the best, but it is often impossible in practice. In order to successfully span multiple domains in a secure environment, it is necessary to realize the mapping of identity and trust, which can be achieved through a proxy server or trust proxy

trust relationship

lattice services need to span multiple security domains, and the trust relationship in these domains plays an important role in point-to-point spanning. Each service should clarify its access requirements, so that entities that need to access these services can access them safely. The trust relationship between endpoints should be clearly described by policies. The trust establishment process may be a one-time activity for each session, or it may be dynamically evaluated for each request. Due to the dynamic nature of lattice, in some cases, it is impossible to establish trust relationships in these domains in advance before the application is executed. In short, the trust relationship in the grid environment is very complex, and it needs to support dynamic, user controlled configuration and instant service management. Instant services are generated by users to perform specific request tasks, and these tasks even include the execution of user code

to sum up, the security problem of grid environment can be divided into the following three research areas:

(1) integrated solutions

focus on how to use existing services and the interface should be abstracted into an extensible architecture

(2) collaborative work capability solution

focuses on how to call services in virtual organizations with different security mechanisms and policies

(3) trust policy solution

focuses on how to define, manage and implement trust policies in a dynamic grid environment

III. security requirements for lattice computing

lattice systems and applications require all standard security functions, including authentication, access control, integrity, privacy and non repudiation. Authentication and access control are mainly discussed here. In particular: (1) provide authentication solutions that allow users, including the process of user computing and the resources used in the process, to prove each other's identities. (2) Try not to change the access control mechanism at any time. Authentication forms the basis of security policy, making each local security policy integrated into a global framework

to develop a security architecture that meets these requirements, the following restrictions need to be met:

single login point: users only need to authenticate once at the beginning of computing; There is no need to re authenticate users when obtaining resources, using resources, releasing resources and internal communication

credit voucher protection: users' vouchers (passwords, keys, etc.) must be protected

interoperability of local security solutions: when the security solution can provide an inter domain access control mechanism, the access to local resources should be determined by the local security mechanism. However, it is unrealistic to change local resources to adapt to inter domain access, This requires one or more entities to act as remote clients/user agents of local resources. "Yucheng City has established a comprehensive strategic cooperative relationship with Shandong South University.

Openness: it requires that the code be open and executable on multiple test beds.

unified authentication structure: inter domain access requires that the security principal (such as a user or a resource) be represented in a minimum and general way 。 Therefore, standard certification standards (such as X.509) must be used

support security group communication: communication may include many processes, which require a group to coordinate their activities. Therefore, it is necessary to support the secure communication of dynamic groups

support multiple implementation schemes: the security policy cannot be specifically determined for a specific application technology. It should be applicable to a large number of public key and password based systems

fourth, the security strategy of lattice computing

in the following discussion, first define the relevant security terms:

subject: it is a participant in the security operation. In the lattice system, a subject is usually a user, a process operation on behalf of the user, a resource (such as a computer or a file), or a process on behalf of the resource, which is performed on the crystalline polymer

credential: it is a message used to prove the identity of the subject. Passwords and authentication are examples of credentials

authentication: it is the process that the subject proves his identity to the requester, usually using a credential. Identification between two parties (requestor and requestee) is mutual identification that identifies each other at the same time (when identifying others, they are also identified)

object: a resource protected by security policies

authorization: it is a process that we decide whether to allow a subject to access or use an object

trust domain: a trust domain is a collection of subjects and objects dominated by a single management and a single security policy

using these terms, define the security policy as follows:

grid environment includes multiple trust domains

this policy element indicates that the lattice security policy must integrate a locally manageable heterogeneous set of users and resources. In general, the grid environment will restrict or not affect local security policies. In this way, we can neither replace the local security policy, nor override the local policy decision. Therefore, lattice security policies must focus on inter domain interactions and map inter domain operations to local security policies

operations within a single trust domain are only affected by local security policies

The grid security policy does not add additional security operations and services in local operations. Local security policies can be implemented in many ways, including firewall, Kerberos, and SSH

for each trust domain, there is an image from global to local principals

in fact, each resource user will have two names, a global name and a local resource name. The image from global name to local name is a specific location description

operations between entities located in different trust domains require mutual authentication

an authenticated global principal image is regarded as a local principal, which is equivalent to the local authentication of the local principal

In other words, in a trust domain, the combination of lattice authentication strategy and local image is satisfied with the security objects in the host domain

all access control decisions are made locally by local principals

this policy component requires that access control decisions remain in the hands of local system administrators

a program or process

Copyright © 2011 JIN SHI