CN115344873A

CN115344873A - Access control method, device and equipment

Info

Publication number: CN115344873A
Application number: CN202110831636.0A
Authority: CN
Inventors: 孙应孔; 朱小平
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2021-05-12
Filing date: 2021-07-22
Publication date: 2022-11-15
Also published as: WO2022237006A1

Abstract

Embodiments of the present disclosure provide access control methods, apparatuses, devices, storage media and program products. In an access control method, an access control rule applied to a service in a cloud environment is determined. The access control rule specifies a source object in the cloud environment that is allowed to access the service. A target instance of the service deployed in the cloud environment is determined, and the access control rule is enabled at the target instance. In this way, embodiments of the present disclosure enable distributed access control. In this way, the configuration of the security policy is simplified, and the fault radius of the security policy is controllable, so that the operation and maintenance efficiency of the security policy can be improved.

Description

Access control method, device and equipment

Technical Field

The embodiment of the disclosure mainly relates to the technical field of computers, in particular to the field of cloud computing. More particularly, embodiments of the present disclosure relate to access control methods, apparatuses, devices, computer-readable storage media and computer program products for use in a cloud environment.

Background

Cloud technology is used for realizing hosted services in a cloud environment, and is one of the fastest-developing technologies in the field of computers. Cloud computing may provide resources such as networks, network bandwidth, servers, storage, applications, etc. as services to consumers. Taking a public cloud as an example, a cloud refers to numerous data centers and numerous services. Some services may have dependencies between them and therefore require interaction. In order to guarantee the network security of the service, security policies for different services are required for access control. Currently, such security policies are typically implemented by centralized firewalls. However, centralized firewalls have a number of problems such as low reliability, low ease of use, high cost, and the like.

Disclosure of Invention

Embodiments of the present disclosure provide a scheme for access control.

In a first aspect of the present disclosure, an access control method is provided. The method comprises the following steps: an access control rule is determined that applies to a service in the cloud environment, the access control rule specifying source objects in the cloud environment that are allowed to access the service. The method further comprises the following steps: a target instance of a service deployed in a cloud environment is determined. The method further comprises the following steps: access control rules are enabled at the target instance.

In this way, distributed access control at the instance is achieved with the service as the protected object. The mode simplifies the configuration of the security policy, and enables the fault radius of the security policy to be controllable, thereby improving the operation and maintenance efficiency of the security policy. Accordingly, embodiments of the present disclosure enable reliable and secure access control in a cloud environment.

In some embodiments of the first aspect, determining the access control rule to apply to the service comprises: an access control rule of a security group to which the service belongs is determined as an access control rule applied to the service. With security groups, services sharing the same access control rules can be managed uniformly. In this way, security policy management can be simplified and the operation and maintenance efficiency of the security policy can be improved.

In some embodiments of the first aspect, the service comprises at least one of a cloud service, a micro-service set, a micro-service, or a component. In such an embodiment, services in different hierarchies are allowed to be protected objects. In this way, the flexibility of security policy management may be increased.

In some embodiments of the first aspect, the method further comprises: if an instance deployed with a service is added, access control rules are enabled at the added instance. In such embodiments, the access control rules may be automatically enabled at the added instance in response to the expansion of the service. In this way, manual configuration of the security policy is simplified, thereby contributing to an increase in the operation and maintenance efficiency of the security policy.

In some embodiments of the first aspect, the method further comprises: if the target instance is no longer deploying the service, the access control rules are disabled or removed at the target instance. In such embodiments, access control rules may be automatically disabled or removed at the reduced instances in response to the reduction of the service. In this way, manual configuration of the security policies is simplified, thereby contributing to an increase in operation and maintenance efficiency of the security policies.

In some embodiments of the first aspect, the method further comprises: if the target instance is no longer deploying the service, the target instance is disassociated from the access control rules. For example, the target instance may be removed from the security group. In such embodiments, the security policy may be automatically adjusted in response to the reduction of the service. In this way, manual configuration of the security policy is simplified, thereby contributing to an increase in the operation and maintenance efficiency of the security policy.

In some embodiments of the first aspect, determining the access control rule comprises: a security group is created based on user input, the security group including a service and access control rules applied to the service. With a security group, users can uniformly manage services that share the same access control rules. In this way, security policy management can be simplified and the operation and maintenance efficiency of the security policy can be improved.

In some embodiments of the first aspect, the method further comprises: based on another user input, one or more services are added to or removed from the security group. In this way, access control rules at the target instance may be managed simply by the addition or removal of services.

In some embodiments of the first aspect, the source object comprises at least one of: one or more services in a cloud environment, one or more addresses in a cloud environment, or a set of addresses in a cloud environment. In this way, source objects can be flexibly and conveniently specified in a variety of ways.

In some embodiments of the first aspect, the services in the security group belong to users having the same privileges. In such an embodiment, by setting the user rights, only the user having the corresponding rights can specify the protected object. In this way, the reliability and security of access control can be enhanced.

In some embodiments of the first aspect, enabling the access control rule at the target instance comprises: enabling, at the target instance, access control rules for the service at one or more planes, the planes being any of: management plane, storage plane, operation and maintenance plane, or traffic plane. In such embodiments, distributed access control is refined to flat granularity. In this way, the accuracy of security policy management can be improved, and the failure radius can be further reduced.

In some embodiments of the first aspect, enabling the access control rule at the target instance comprises: and issuing the access control rule to the target instance through the controller of the available area where the target instance is located. In this way, access control rules can be accurately scheduled to a target instance with low latency.

In some embodiments of the first aspect, different services belonging to the security group are deployed in different cloud environments. By utilizing the security group, the security policy management of services in a multi-cloud environment can be conveniently realized.

In a second aspect of the disclosure, an access control device is provided. The device includes: a rule determination unit configured to determine an access control rule applied to a service in a cloud environment, the access control rule specifying a source object in the cloud environment that is allowed to access the service; an instance determination unit configured to determine a target instance in a cloud environment in which a service is deployed; and a rule enabling unit configured to enable the access control rule at the target instance.

In some embodiments of the second aspect, the rule determination unit is further configured to: an access control rule of a security group to which the service belongs is determined as an access control rule applied to the service. With a security group, services sharing the same access control rules can be managed uniformly. In this way, security policy management can be simplified and the operation and maintenance efficiency of the security policy can be improved.

In some embodiments of the second aspect, the service comprises at least one of a cloud service, a micro-service set, a micro-service, or a component. In such an embodiment, services in different hierarchies are allowed as protected objects. In this way, the flexibility of security policy management may be increased.

In some embodiments of the second aspect, the apparatus further comprises: a first updating unit configured to enable the access control rule at the added instance if the instance deployed with the service is added. In such embodiments, the access control rules may be automatically enabled at the added instance in response to the expansion of the service. In this way, manual configuration of the security policy is simplified, thereby contributing to an increase in the operation and maintenance efficiency of the security policy.

In some embodiments of the second aspect, the apparatus further comprises: a second updating unit configured to disable or remove the access control rule at the target instance if the target instance is no longer deploying the service. In such embodiments, access control rules may be automatically disabled or removed at the reduced instances in response to the reduction of the service. In this way, manual configuration of the security policies is simplified, thereby contributing to an increase in operation and maintenance efficiency of the security policies.

In some embodiments of the second aspect, the apparatus further comprises: a third updating unit configured to disassociate the target instance from the access control rule if the target instance is no longer deploying the service. In such embodiments, the security policy may be automatically adjusted in response to the reduction of the service. In this way, manual configuration of the security policy is simplified, thereby contributing to an increase in the operation and maintenance efficiency of the security policy.

In some embodiments of the second aspect, the rule determination unit is further configured to: a security group is created based on user input, the security group including a service and access control rules applied to the service. With a security group, users can uniformly manage services that share the same access control rules. In this way, security policy management can be simplified and the operation and maintenance efficiency of the security policy can be improved.

In some embodiments of the second aspect, the apparatus further comprises: a security group update unit configured to add or remove one or more services to or from the security group based on another user input. In this way, access control rules at the target instance may be managed simply by the addition or removal of services.

In some embodiments of the second aspect, the source object comprises at least one of: one or more services in a cloud environment, one or more addresses in a cloud environment, or a set of addresses in a cloud environment. In this way, source objects can be flexibly and conveniently specified in a variety of ways.

In some embodiments of the second aspect, the services in the security group belong to users having the same rights. In such an embodiment, by setting the user rights, only the user having the corresponding rights can specify the protected object. In this way, the reliability and security of access control can be enhanced.

In some embodiments of the second aspect, the rule enabling unit is further configured to: enabling, at the target instance, access control rules for the service at one or more planes, the planes being any of: a management plane, a storage plane, an operation and maintenance plane, or a traffic plane. In such embodiments, distributed access control is refined to flat granularity. In this way, the accuracy of security policy management can be improved, and the failure radius can be further reduced.

In some embodiments of the second aspect, the rule enabling unit is further configured to: and issuing the access control rule to the target instance through the controller of the available area where the target instance is located. In this way, access control rules can be accurately scheduled to target instances with low latency.

In some embodiments of the second aspect, different services belonging to the security group are deployed in different cloud environments. By utilizing the security group, the security policy management of services in a multi-cloud environment can be conveniently realized.

In a third aspect of the present disclosure, there is provided an electronic device comprising: at least one computing unit; at least one memory coupled to the at least one computing unit and storing instructions for execution by the at least one computing unit, the instructions when executed by the at least one computing unit, causing the apparatus to implement the method of the first aspect.

In a fourth aspect of the present disclosure, a computer-readable storage medium is provided, having a computer program stored thereon, wherein the computer program is executed by a processor to perform the method of the first aspect.

In a fifth aspect of the present disclosure, there is provided a computer program product comprising computer executable instructions which, when executed by a processor, implement part or all of the steps of the method of the first aspect.

It will be appreciated that the computing system of the third aspect, the computer storage medium of the fourth aspect or the computer program product of the fifth aspect provided above are all adapted to perform the method provided by the first aspect. Therefore, explanations or illustrations regarding the first aspect are equally applicable to the third, fourth, and fifth aspects. In addition, the beneficial effects achieved by the third aspect, the fourth aspect and the fifth aspect can refer to the beneficial effects in the corresponding methods, and are not described herein again.

Drawings

The above and other features, advantages and aspects of various embodiments of the present disclosure will become more apparent by referring to the following detailed description when taken in conjunction with the accompanying drawings. In the drawings, like or similar reference characters designate like or similar elements, and wherein:

FIG. 1 shows a schematic diagram of access control provided by a centralized firewall;

FIG. 2 illustrates a schematic diagram of an example cloud environment in which embodiments of the present disclosure can be implemented;

FIG. 3 illustrates a schematic diagram of a hierarchy of services, according to some embodiments of the present disclosure;

FIG. 4 illustrates an example structure of resource configuration information, according to some embodiments of the present disclosure;

FIG. 5 illustrates a schematic block diagram of a distributed access control architecture in accordance with some embodiments of the present disclosure;

FIG. 6 illustrates a schematic diagram of user permissions associated with a service, in accordance with some embodiments of the present disclosure;

fig. 7 illustrates a schematic diagram of an example security group, in accordance with some embodiments of the present disclosure;

fig. 8 illustrates a schematic diagram of another example security group, in accordance with some embodiments of the present disclosure;

FIG. 9 illustrates a flow diagram of a process of updating security policies in accordance with some embodiments of the present disclosure;

FIG. 10 illustrates a flow chart of an access control method according to some embodiments of the present disclosure;

FIG. 11 shows a schematic block diagram of an access control device according to some embodiments of the present disclosure; and

FIG. 12 illustrates a block diagram of a computing device capable of implementing various embodiments of the present disclosure.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather are provided for a more complete and thorough understanding of the present disclosure. It should be understood that the drawings and the embodiments of the disclosure are for illustration purposes only and are not intended to limit the scope of the disclosure.

In describing embodiments of the present disclosure, the terms "include" and its derivatives should be interpreted as being inclusive, i.e., "including but not limited to. The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first," "second," and the like may refer to different or the same object. Other explicit and implicit definitions are also possible below.

As used herein, the term "cloud service" refers to a service that is presented to an end consumer as a whole to allow the end consumer to access hosted resources. The term "service" refers to a service provided by a cloud environment in a broad sense, which may refer to both "cloud service" provided to a consumer as a whole, and components included in the cloud service. The term "cloud" or "cloud environment" may include, but is not limited to, public clouds, private clouds, corporate clouds, edge clouds, hybrid clouds, and the like.

As mentioned briefly above, in a cloud environment, some services may need to interact between themselves. In order to guarantee the network security of the service, security policies for different services are required for access control. In conventional approaches, network layer access control for services of each network partition is provided by a centralized firewall.

Fig. 1 shows a schematic diagram of access control provided by a centralized firewall in a conventional scheme. As shown in FIG. 1, cloud environment 100 includes a plurality of network partitions, such as an operation and maintenance zone 121, a management zone 122, a quarantine (DMZ) zone 123, a computing zone 124, and a storage zone 125. These network partitions are connected to the firewall 101 via

switches

111, 112, 113, 114 and router 105, respectively. Services in one network partition need access control through firewall 101 if they are to access services in another network partition. For example, in the case where service a of the operation and maintenance area 121 is to access service B of the computing area 124, the traffic is first routed to the firewall 101 for access control. In the event that firewall 101 determines that service a is allowed to access service B, the traffic is forwarded to computing area 124.

In conventional approaches such as the centralized firewall of fig. 1, access control can only govern service access across network partitions, while access control of different services within the same network partition is a security blind spot. Furthermore, the security policies of many services deployed in cloud environment 100 are all concentrated on firewall 101. This requires a large amount of firewall hardware consumption and is costly.

As the amount of service increases, the ability to upgrade firewalls is also needed. When a new service is deployed in cloud environment 100, there are other services on which the new service depends and other services that depend on the new service. It is therefore necessary to provision ports for accessing the dependent services for the new service, while it is necessary to provision ports for accessing the new service for other services that are dependent on the new service. It can be seen that the security policy in the conventional scheme is very complex and maintenance cost is high. If the security policy of the new service is inadvertently configured incorrectly, the security policies of other services that are behind the security policy may also be affected. Thus, the failure radius of this scheme is global. In addition, such conventional schemes employ IP-based configurations, which are not highly user-friendly and error-prone.

To address, at least in part, the above problems, as well as other potential problems, various embodiments of the present disclosure provide a scheme for access control. In general, according to various embodiments described herein, access control rules applied to a service in a cloud environment and a target instance of the service deployed in the cloud environment are determined. The access control rule specifies a source object in the cloud environment that is allowed to access the service. The access control rule is enabled at the target instance. In this way, distributed access control at the instance is achieved with the service as the protected object. The mode simplifies the configuration of the security policy, and enables the fault radius of the security policy to be controllable, thereby improving the operation and maintenance efficiency of the security policy. Accordingly, embodiments of the present disclosure enable reliable and secure access control in a cloud environment.

Various example embodiments of the present disclosure are described below with reference to fig. 1 through 12.

Example Environment

Fig. 2 illustrates a schematic diagram of an example cloud environment 200 in which embodiments of the present disclosure can be implemented. In general, cloud environment 200 includes a resource configuration system 203, a configuration database 202, a security manager 201, and a resource production system 204. Security manager 201 may be deployed in the same or different zones as resource configuration system 203 and configuration database 202, embodiments of the present disclosure are not limited in this respect. A user 250, such as a service administrator, security administrator, etc., may interact with resource configuration system 203, security manager 201, etc. in cloud environment 200.

Resource production system 204 is used to implement services provided by cloud environment 200 and may include one or more network partitions, such as network partitions 230-1, 230-2, 230-3, and 230-4, which may also be collectively referred to as multiple network partitions 230 or network partitions 230 individually. The plurality of network partitions 230 may include instances 210-1, 210-2, 210-3, 210-4, 210-5, 210-6, 210-7, 210-8, and 210-9, which may also be collectively referred to as a plurality of instances 210 or individually as instances 210. Multiple instances 210 may be distributed across multiple network partitions 230. By way of example only, instances 210-1, 210-2, and 210-3 are distributed in network partition 230-1, instances 210-4 and 210-5 are distributed in network partition 230-2, instances 210-6 and 210-7 are distributed in network partition 230-3, and instances 210-8 and 210-9 are distributed in network partition 230-4.

Instance 210 is deployed with one or more services of a cloud environment. In embodiments of the present disclosure, the instances 210 may be any suitable virtual or physical resource. The virtual resources may include, for example, virtual Machines (VMs), containers, and the like. The physical resources may include, for example, physical Machines (PMs), bare metal servers, network devices, security devices, interface cards, and the like. It should be understood that the number of network partitions, the number of instances, and the distribution of instances shown in fig. 2 are merely exemplary, and are not intended to limit the scope of the present disclosure. In embodiments of the present disclosure, a cloud environment may include any suitable number of network partitions and instances.

Resource configuration system 203 is used to create and deploy services. For example, user 250 may interact with resource configuration system 203 to specify a service to be created. The resource configuration system 203 may determine an instance 210 for deploying the service, e.g., determine which VM or VM, PM, or container the service is to be deployed in. In turn, the resource configuration system 203 can release such resources to the resource production system 204 and deploy the service at the determined instance 210. The resource configuration system 203 may store the service information and the resource configuration information in the configuration database 202. The configuration database 202 may be, for example, a Configuration Management Database (CMDB). The service information indicates individual services in the cloud environment 200, and may optionally indicate relationships between the services. The resource configuration information indicates one or more instances at which the respective service is deployed. In other words, the resource configuration information indicates a service to instance relationship.

The services in cloud environment 200 may be constructed in any suitable structure. In some embodiments, services in cloud environment 200 may be built in a hierarchical structure. FIG. 3 illustrates a schematic diagram of a hierarchy 300 of services according to some embodiments of the present disclosure. The hierarchy 300 includes three levels, from top to bottom, cloud services, micro-service groups, micro-services or components. Micro-services or components refer to independently deployable services or components with independent functionality. A microservice group includes a set of microservices or components that are close in features or functionality. In the example of fig. 3, cloud service 310 includes micro-service group 321 and micro-service group 322. Microservice group 321 includes microservice 331 and microservice 332. Microservice group 322 includes microservice 333 and microservice 334.

The hierarchy 300 shown in FIG. 3 may be viewed as a service tree. In such embodiments, the resource configuration system 203 may store the service tree as service information in the configuration database 202. It should be understood that the hierarchy 300 shown in fig. 3, including three levels, is merely exemplary and is not intended to limit the scope of the present disclosure. In embodiments of the present disclosure, the individual services in the cloud environment may be built in any suitable number of tiers. As an example, individual services in a cloud environment may be built in two tiers of cloud services and microservices.

Fig. 4 illustrates an example structure of resource configuration information 400 according to some embodiments of the present disclosure. In the example of FIG. 4, the resource configuration information 400 or service to instance relationship includes five levels, namely L1, L2, L3, L4, L5. The L1 to L3 tiers indicate services, namely cloud services 401, micro service groups 402, micro services or components 403. The L4 hierarchy indicates the running or deployment of an instance 404 of the microservice or component 403. The L5 level indicates an instance address 405 of the instance 104. Herein, the address may include, but is not limited to, an Internet Protocol (IP) address, such as an IPv4 address, an IPv6 address, and may also include other types of addresses.

In embodiments of the present disclosure, an instance deployed with a cloud service refers to an instance deployed with a microservice or component under the cloud service, and an instance deployed with a microservice group refers to an instance deployed with a microservice or component under the microservice group. Thus, in the example of fig. 3, the instance deployed with cloud service 310 includes instances deployed with

microservices

331, 332, 333, and 334, the instance deployed with microservice group 321 includes instances deployed with

microservices

331, 332, and the instance deployed with microservice group 322 includes instances deployed with

microservices

333, 334.

With continued reference to fig. 2. Service information (e.g., service trees) and resource configuration information (i.e., service-to-instance relationships) stored in the configuration database 202 are sent to the security manager 201. The security manager 201 is used to configure and manage security policies for the resource production system 204. The security manager 201 determines a protected service as a protection object based on the service information, and determines an access control rule applied to the service. Security manager 201 determines a target instance, such as instance 210-2 and instance 210-8, from the plurality of instances 210, to deploy the service based on the resource configuration information. The security manager 201 then enables the access control rule at the target instance. For example, security manager 201 schedules the access control rules as security policies to the target instances.

Upon receiving an access request from a source object, the target instance determines whether the source object has access rights to accept or deny the access request based on the access control rules. To apply the access control rule, the target instance may convert the access control rule into an executable instruction. Application of the access control rules may be implemented in any suitable manner depending on the device type (e.g., VM, container, etc.) of the target instance. For example, an agent may be deployed in the operating system of the target instance. The agent is used to communicate with the security manager 201 and validate the access control rules in the data plane.

In cloud environment 200, instance-based distributed access control may be implemented. This greatly reduces the failure radius of the security policy compared to a centralized firewall. Cloud environment 200 may include, but is not limited to, public clouds, private clouds, corporate clouds, edge clouds, hybrid clouds, and combinations thereof. Further, such distributed access control may be implemented across two or more cloud environments. For example, multiple instances 210 may be provided by different cloud environments.

System architecture

An example architecture for implementing distributed access control is described below. Fig. 5 illustrates a schematic block diagram of a distributed access control architecture 500 in accordance with some embodiments of the present disclosure. In general, architecture 500 includes a security policy orchestration layer 510, a security policy scheduling layer 520, and a security policy enforcement layer 530. Security policy orchestration layer 510 includes security manager 201. The security policy scheduling layer 520 includes

controllers

521, 522, and 523 of available zones. The security policy enforcement layer 530 includes

instances

531, 532, 533, and 534 in the usable area. In the example of fig. 5, controller 521 is a controller of the available area where instance 531 is located, controller 522 is a controller of the available area where instance 532 is located, and controller 523 is a controller of the available areas where

instances

533 and 534 are located. The controller may be, for example, a dedicated server in the availability zone, or the like. The architecture 500 shown in fig. 5 is merely exemplary, and is not intended to limit the scope of the present disclosure. The distributed access control architecture may also be partitioned in other ways.

The security manager 201 includes a policy orchestration module 501, a policy management module 502, and a policy scheduling engine 503. The policy orchestration module 501 is used to associate a protected service (hereinafter may also be referred to as a "target service") with a corresponding access control rule. The access control rules specify source objects in the cloud environment 200 that are allowed to access the service. In some embodiments, if a service in cloud environment 200 is built in a hierarchy, the service may belong to any level of the hierarchy. In an embodiment having a hierarchy 300 as shown in FIG. 3, the service may include any of a cloud service, a group of micro-services, a micro-service, or a component. In such an embodiment, services in different hierarchies are allowed to be protected objects. In this way, the flexibility of security policy management may be increased.

In some embodiments, the services and corresponding access control rules may be specified in a provisioning file. The policy orchestration module 501 may read the pre-configured file and determine therefrom the protected services and the corresponding access control rules.

In some embodiments, the protected service and corresponding access control rules may be specified by user 505. For example, user 505 may be presented with a user interface that displays service information (e.g., a service tree). User 505 may select a protected service through a user interface and may specify source objects that are allowed to access the service.

In some embodiments, user permissions associated with a service may be set. In other words, in such embodiments, user 505 may only specify services belonging to user 505 as protected objects. Reference is now made to fig. 6. FIG. 6 illustrates a schematic diagram of user permissions associated with a service, according to some embodiments of the present disclosure. In a Role Based Access Control (RBAC) model 600 shown in fig. 6, users belonging to the same group have the same role and have the same permissions.

Users

601, 602, 603 belong to

different groups

611, 612, 613, respectively. The role of group 611 is a service administrator of cloud services 621. Accordingly, a user (e.g., user 601) belonging to group 611 can select a service as a protected object from cloud service 621 and its included micro-service group, micro-service, or component. The role of group 612 is a service administrator of cloud services 622. Accordingly, a user (e.g., user 602) belonging to group 612 can select a service from cloud service 622 and its included micro-service groups, micro-services, or components as a protected object. The role of group 613 is as a security administrator of system resources 623. Accordingly, a user (e.g., user 603) belonging to group 611 is able to select a service as a protected object from all cloud services and micro service groups, micro services, or components. In such an embodiment, by setting user rights, only users having the corresponding rights can specify the protected object. In this way, the reliability and security of access control can be further enhanced.

Reference is made back to fig. 5. As mentioned above, the source objects that are allowed to access the target service may be specified by a provisioning file or user input from user 505. The policy orchestration module 501 may provide one or more schemas to specify the source objects. In some embodiments, the source object may include one or more services in cloud environment 200. For example, policy orchestration module 501 may provide a service pattern to user 505. In service mode, policy orchestration module 501 presents a user interface to user 505 that displays service information (e.g., a service tree). User 505 may select one or more services through a user interface, the selected services being allowed to access the target service. In this case, policy orchestration module 501 may determine an address (e.g., an IP address) to deploy the instance of the selected service based on the resource configuration information from configuration database 202 to determine the access control rules. That is, the determined address is allowed to access the target instance.

Alternatively or additionally, in some embodiments, the source object may include one or more addresses in a cloud environment. For example, policy orchestration module 501 may provide an address pattern to user 505. In address mode, the user 505 may directly enter an address through the user interface to specify a source object. Policy orchestration module 501 may determine the access control rules based on the address entered by user 505. That is, the address entered by user 505 is allowed to access the target instance.

Alternatively or additionally, in some embodiments, the source object may comprise a set of addresses in a cloud environment. For example, policy orchestration module 501 may provide user 505 with an address pool pattern. In the address pool mode, user 505 may select an address pool from a predefined plurality of address pools to specify a source object. Each address pool may include a set of addresses, such as multiple addresses, one or more address ranges, and combinations thereof. The policy orchestration module 501 may determine the access control rules based on the selected address pool. That is, addresses in the selected address pool are allowed to access the target instance.

Although the service mode, the address mode, and the address pool mode have been described by taking the example in which the user input specifies the source object, this is only exemplary. These modes may also be used in the case where the provisioning file specifies a source object. For example, a service, one or more addresses, or a pool of addresses may be specified in the provisioning file as a source object.

In addition to the source object, the user input or provisioning file may also specify the protocol port of the target instance (i.e., the destination protocol port) as part of the access control rules. As an example, a port number of a Transmission Control Protocol (TCP), such as TCP 443, may be specified. As such, in service mode, the access control rule may be to allow the determined address to access the target instance at the TCP 443 port; in address mode, the access control rule may be to allow the address entered by user 505 to access the target instance at the TCP 443 port; in address pool mode, the access control rule may be to allow addresses in the selected address pool to access the target instance at the TCP 443 port.

The policy management module 502 in the security manager 201 is used to determine that a target instance of the protected service is deployed. For example, the target instance may be determined based on resource configuration information from configuration database 202. Policy management module 502 is also used to manage service information, resource configuration information, and security policies. In particular, the policy management module 502 may monitor updates to service and resource configurations. The update of a service may include, but is not limited to, an increase of a microservice (e.g., online), a decrease of a microservice (e.g., offline), an expansion of a microservice, a reduction of a microservice, an increase of a region (region), a change of a region, a change of an available region, and the like. The update of the service may result in an update of the resource configuration, such as an increase, decrease, change, etc. of the instances deployed by the service.

In some embodiments, the policy management module 502 may receive real-time messages from the configuration database 202 to monitor updates to service and resource configurations. Such real-time messages are generated in response to and indicative of updates to the service or resource configuration. Examples of real-time messages may include, but are not limited to, configuration management database instance messages, cloud service view service tree messages, micro-service instance messages, cloud location area messages, and the like.

Alternatively or additionally, in some embodiments, the policy management module 502 may periodically synchronize service information and resource configuration information with the configuration database 202 to monitor updates to the service and resource configurations. For example, policy management module 502 may periodically receive the service tree and service and instance relationships from configuration database 202. In such embodiments, with periodic synchronization, the problem of information mismatch due to real-time messaging failures can be avoided, thereby enhancing the reliability of distributed access control. In the case of real-time messaging combined with periodic synchronization, it can be ensured that the security manager 201 knows the service-to-instance relationship timely and reliably, thereby accurately determining the target instance.

Additionally, policy management module 502 may maintain the relationship of protected services to access control rules. Upon monitoring an update of the service and resource configuration, the policy management module 502 may update the relationship of the service and the access control rules accordingly. For example, if a reduction in service is monitored, the policy management module 502 may disassociate the reduced service from the corresponding access control rule. The security manager 201 may further disable or remove the access control rule at the instance that the reduced service was originally deployed. As another example, if an increase in service is monitored, the policy management module 502 may determine an access control rule that applies to the added service and associate the added service with the access control rule.

The policy scheduling engine 503 in the security manager 201 is used to enable access control rules at the target instance. In particular, the policy scheduling engine 503 may issue the access control rules to the target instance in the security policy enforcement layer 530. In some embodiments, if an instance in the cloud environment is located in a different availability zone, the policy scheduling engine 503 issues the access control rules to the target instance through the controller of the availability zone in which the target instance is located. In the example of fig. 5, where the target instance includes instance 531, the policy scheduling engine 503 may issue the access control rules to the instance 531 through the controller 521. Where the target instance includes instance 532, policy scheduling engine 503 may issue the access control rules to instance 532 via controller 522. Where the target instance includes instance 533 and/or instance 534, policy scheduling engine 503 may issue the access control rules to instance 533 and/or instance 534 via controller 523.

Distributed access control is achieved using the system architecture described above. The security policies are scheduled to instances by policy orchestration and scheduling software techniques, which reduces cost compared to hardware firewalls. For each service that needs protection, the corresponding access control rules may be enabled at one or more target instances where the service is deployed. The access control rules of different services are only on the instance of the service, and the different services are physically isolated from each other, so that the fault radius generated when the security policy is wrong is reduced. The source objects specified by the access control rules may be configured as desired and are not limited to being located in a different region than the target instance. In this way, security blind spots in centralized firewall solutions are eliminated.

Security group

Given that some services may have the same security policy and share the same access control rules, in some embodiments, a security group may be utilized to manage multiple services that share the same access control rules. Security manager 201 (e.g., policy orchestration module 501) may create a security group based on user input. The created security group includes these services and the shared access control rules. By way of example, user 505 may create and add services to a security group through a user interface and specify source objects by specifying services, addresses, or pools of addresses. The security manager 201 may take the service added by the user as a member of a security group and generate access control rules for the security group based on the specified source objects. In some embodiments, the security manager 201 may add the determined target instance to the security group. In some embodiments, for example where the RBAC model shown in fig. 6 is applied, services in a security group may belong to users with the same rights.

In such embodiments, the security manager 201 may determine the access control rules of the security group as the access control rules that apply to the services in the security group. When the security group needs to be updated, the user 505 may provide subsequent input through the user interface. Based on subsequent inputs, the security group may be updated. For example, one or more services may be added to a security group to apply access control rules of the security group to the added services. As another example, one or more services originally belonging to a security group may be removed from the security group.

Further, upon monitoring updates to the service and resource configurations, the security manager 201 (e.g., policy management module 502) may update the security groups accordingly. For example, if a reduction in a service is monitored, the security manager 201 may remove the reduced service from the security group to which it originally belongs, thereby disassociating the service from the corresponding access control rule. As another example, if an addition of a service is monitored, the security manager 201 may determine and add to the security group to which the added service belongs, thereby associating the added service with a corresponding access control rule.

With security groups, services sharing the same access control rules can be managed uniformly. In this way, security policy management can be simplified and the operation and maintenance efficiency of the security policy can be improved.

In the case of a multi-cloud environment, services in the same security group may be deployed in different cloud environments. For example, some services in a security group are deployed in a public cloud, while other services are deployed in a private cloud. In this way, cross-cloud management of security policies can be conveniently implemented.

Fig. 7 illustrates a schematic diagram of an example security group 701, according to some embodiments of the present disclosure. Fig. 7 exemplifies the three-level hierarchy shown in fig. 3, but this is merely exemplary and not intended to limit the scope of the present disclosure. As shown in fig. 7, based on user input 704, a security group 701 is created that includes cloud service B, micro service group a, and micro service C. Accordingly, security group 701 includes service directory 702. In service directory 702, the entry "identification of cloud service B" indicates that security group 701 includes cloud service B at the cloud service level, the entry "identification of microservice group a" indicates that security group 701 includes microservice group a at the microservice group level, and the entry "identification of microservice C" indicates that security group 701 includes microservice C at the microservice level.

Based on the user input 705, access control rules for security groups 703 are generated. The access control rules 703 will apply to cloud service B, micro service group a, and micro service C belonging to the security group 701. Accordingly, security manager 201 enables access control rules 703 at all instances where cloud service B, micro service group a, and micro service C are deployed. In other words, all instances deployed with cloud service B, micro service group A, and micro service C allow access of source address 10.52.80/24 with TCP 443 port.

In the example of fig. 7, services in a cloud environment are built in multiple tiers, and security groups are allowed to include services in different tiers. In this way, the flexibility of security policy management may be increased. Allowing a given cloud service to have a zero-in-one role allows a user to not have to select individual micro-services under the cloud service one by one. Allowing specified microservices or components enables security policy management to be refined.

It should be understood that the security groups, source addresses, port numbers, etc. shown in fig. 7 are exemplary and are not intended to limit the scope of the present disclosure. The security group may include any suitable number of services, such as any suitable number of cloud services, micro-service groups, micro-services.

In some embodiments, management of security policies may be further refined to flat granularity. Access control rules for protected services in one or more planes (hereinafter also referred to as "target planes") may be enabled at the target instance. The plane may be any of a management plane, a storage plane, an operation and maintenance plane, or a traffic plane. For example, where the access control rules apply to the management plane, the access control rules for the protected service at the management plane may be enabled only at the target instance.

Accordingly, security manager 201 can maintain information of instances about the target plane. Such an embodiment is described below with reference to fig. 8, taking a security group as an example. Fig. 8 shows a schematic diagram of another example security group 801, in accordance with some embodiments of the present disclosure. Fig. 8 exemplifies the three-level hierarchy shown in fig. 3, but this is merely exemplary and not intended to limit the disclosure. The security group 801 includes at least microservices 810 and access control rules 803. The security group 801 may also include other services not shown.

The instances where the microservice 810 is deployed include instance A, instance B, and instance C, where instance B does not refer to a target plane, and instances A and C refer to a target plane. For example a, all ports should be used for the target plane, or no planes are distinguished for example a. For instance C, port a and port C apply to the target plane, while port B applies to a plane other than the target plane. In this case, instance A and instance C are determined as target instances. Further, for instance C, access control rules 803 are enabled only at port a and port C of instance C.

Accordingly, the security group 801 includes an instance catalog 802. In instance directory 802, the entry "identification of instance A" and sub-entries therebelow indicate all addresses of instance A and instance A, and the entry "identification of instance C" and sub-entries therebelow indicate the addresses of instance C, port A of instance C, and port C of instance C. Although not shown, the instance directory 802 may also include other entries or sub-entries for indicating the type of port or plane to which the port applies.

In the example of FIG. 8, security manager 201 enables access control rules 703 at all ports of instance A, port A and port C of instance C. In other words, all ports of instance A, port A and port C of instance C allow access of source address 10.52.80/24 with TCP 443 port.

In such embodiments, distributed access control is refined to flat granularity. In this way, the accuracy of security policy management can be improved, and the failure radius can be further reduced.

Updating of security policies

As described with reference to fig. 5, the policy management module 502 may monitor updates to service and resource configurations. Based on the update of the service and resource configuration, security manager 201 may update the security policy. Fig. 9 illustrates a flow diagram of a process 900 of updating security policies, in accordance with some embodiments of the disclosure.

At block 910, security manager 201 determines whether service expansion or contraction exists based on the monitored updates to the service and resource configurations. For example, security manager 201 may determine whether there is service expansion or contraction based on real-time messages received from configuration database 202 or periodic synchronization with configuration database 202.

If it is determined at block 910 that there is service expansion, process 900 proceeds to block 920. In other words, if an instance is added where some protected service is deployed, process 900 proceeds to block 920. At block 920, security manager 201 associates the added instance with the access control rule applied to the service. For example, in embodiments where a security group is created, the added instances may be added to the security group where the service resides. At block 930, security manager 201 enables the access control rule at the added instance. For example, the security manager 201 may issue the access control rule to the added instance through a controller of an available area in which the added instance is located.

If it is determined at block 910 that a service short exists, process 900 proceeds to block 940. In other words, if the target instance that originally deployed a certain protected service is no longer deployed with that service, process 900 proceeds to block 940. At block 940, security manager 201 disassociates the target instance that is no longer deployed with the service from the access control rules applied to the service. For example, in embodiments where a security group is created, the security manager 201 may remove the target instance from the security group where the service is located. At block 950, security manager 201 disables or removes the access control rules applied to the service at the target instance no longer deployed with the service. For example, security manager 201 may send a message or command to the target instance to mark the access control rule as disabled at the target instance or to delete the access control rule locally to the target instance.

The process 900 of automatically updating security policies is described above with respect to a service in a broad sense. The process 900 may be applicable to services of any granularity. In embodiments where services are built in a hierarchical structure as shown in FIG. 3, the services that are expanded or contracted may include any one or more of a cloud service, a group of micro-services, a micro-service, or a component.

In such embodiments, the security policy may be automatically updated in response to updates to the service and resource configuration. That is, in response to expansion of the service, the access control rules may be automatically enabled at the added instance; access control rules may be automatically disabled or removed at the reduced instances in response to the contraction of the service. In this way, manual configuration of the security policy is simplified, thereby contributing to an increase in the operation and maintenance efficiency of the security policy.

Example Processes, apparatus, and devices

Fig. 10 illustrates a flow diagram of an access control method 1000 in accordance with some embodiments of the present disclosure. Method 1000 may be implemented, for example, by security manager 201 in fig. 2. For ease of description, the method 1000 is described below with reference to fig. 2-8.

At block 1010, an access control rule applied to a service in the cloud environment is determined. The access control rule specifies a source object in the cloud environment that is allowed to access the service. Cloud environments are, for example, public clouds, private clouds, corporate clouds, edge clouds, hybrid clouds, and combinations thereof. In some embodiments, the service includes at least one of a cloud service, a micro-service set, a micro-service, or a component. For example, where a service in a cloud environment is built in the hierarchy 300 shown in FIG. 3, the service may include a cloud service, a group of microservices, a microservice, or a component.

In some embodiments, the source object includes at least one of: one or more services in a cloud environment, one or more addresses in a cloud environment, or a set of addresses in a cloud environment. For example, one or more of a service mode, an address mode, and an address pool mode may be provided to the user.

In some embodiments, the access control rule of the security group to which the service belongs may be determined as the access control rule applied to the service. For example, access rules 703 of security group 701 may be determined as access control rules that apply to cloud service B, micro service group a, and micro service C.

In some embodiments, a security group may be created based on user input, the security group including the service and access control rules applied to the service. For example, security group 701 may be created based on

user inputs

704 and 705. In some embodiments, one or more services may also be added to or removed from the security group based on another user input. For example, the security group 701 may be updated based on subsequent inputs.

In some embodiments, services in a security group belong to users having the same permissions. For example, a BRAC model as shown in fig. 6 may be provided to manage the security policy configuration of a user for a service.

In some embodiments, different services belonging to a security group are deployed in different cloud environments. In other words, distributed access control may be implemented across multiple clouds.

At block 1020, a target instance of the service deployed in the cloud environment is determined. For example, the target instance may be determined based on resource configuration information (i.e., service to instance relationships). The target instance may be any suitable virtual or physical resource. The virtual resources may include, for example, VMs, containers, and the like. The entity resources may include, for example, PMs, bare metal servers, network devices, security devices, interface cards, and the like. At block 1020, access control rules are enabled at the target instance. For example, security manager 201 schedules the access control rule to the determined one or more target instances.

In some embodiments, access control rules for services in one or more planes may be enabled at the target instance. The plane may be any one of: a management plane, a storage plane, an operation and maintenance plane, or a traffic plane. For example, for instance C shown in fig. 8, access control rules 803 are only enabled at port a and port C, which apply to the same plane as access control rules 803.

In some embodiments, the access control rules may be issued to the target instance by a controller of the availability zone in which the target instance is located. For example, if the target instance includes instance 531 shown in FIG. 5, the access control rules may be issued to instance 531 by controller 521.

In some embodiments, the method 1000 further comprises: if an instance is added that is deployed with the service, access control rules are invoked on the added instance. The added instance may also be associated with the access control rule at the security manager 201, e.g. to a security group to which the service belongs.

In some embodiments, the method 1000 further comprises: if the target instance no longer deploys the service, the access control rules are disabled or removed at the target instance. The target instance may also be disassociated from the access control rules at security manager 201. In some embodiments, the target instance may be removed from the security group to which the service belongs.

Fig. 11 shows a block diagram of an access control device 1100 according to an embodiment of the disclosure, the device 1100 may comprise a plurality of units for performing the corresponding steps in the method 1000 as discussed in fig. 10. As shown in fig. 11, the apparatus 1100 includes a rule determination unit 1110 configured to determine an access control rule applied to a service in a cloud environment. The access control rules specify source objects in the cloud environment that are allowed to access the service. The apparatus 1100 further comprises an instance determination unit 1120 configured to determine a target instance of the service deployed in the cloud environment. The apparatus 1100 further comprises a rule enabling unit 1130 configured to enable the access control rule at the target instance.

In some embodiments, the rule determining unit 1110 is further configured to: an access control rule of a security group to which the service belongs is determined as an access control rule applied to the service.

In some embodiments, the service comprises at least one of a cloud service, a micro-service set, a micro-service, or a component.

In some embodiments, the apparatus 1100 further comprises: a first updating unit configured to enable the access control rule at the added instance if the instance deployed with the service is added.

In some embodiments, the apparatus 1100 further comprises: a second updating unit configured to disable or remove the access control rule at the target instance if the target instance is no longer deploying the service.

In some embodiments, the apparatus 1100 further comprises: a third updating unit configured to remove the target instance from the security group if the target instance no longer deploys the service.

In some embodiments, the rule determining unit 1110 is further configured to: a security group is created based on user input, the security group including a service and access control rules applied to the service.

In some embodiments, the apparatus 1100 further comprises: a security group update unit configured to add or remove one or more services to or from the security group based on another user input.

In some embodiments, the source object includes at least one of: one or more services in a cloud environment, one or more addresses in a cloud environment, or a set of addresses in a cloud environment.

In some embodiments, services in a security group belong to users having the same permissions.

In some embodiments, the rule enabling unit 1130 is further configured to: enabling, at the target instance, access control rules for the service at one or more planes, the planes being any of: a management plane, a storage plane, an operation and maintenance plane, or a traffic plane.

In some embodiments, the rule enablement unit 1130 is further configured to: and issuing the access control rule to the target instance through the controller of the available area where the target instance is located.

In some embodiments, different services belonging to a security group are deployed in different cloud environments.

Fig. 12 shows a schematic block diagram of an example device 1200, which may be used to implement embodiments of the present disclosure. The device 1200 may be used to implement the security manager 201, etc. As shown, device 1200 includes a computing unit 1201 that may perform various appropriate actions and processes according to computer program instructions stored in Random Access Memory (RAM) and/or Read Only Memory (ROM) 1202 or loaded into RAM and/or ROM 1202 from a storage unit 1207. In the RAM and/or ROM 1202, various programs and data required for the operation of the device 1200 may also be stored. The computing unit 1201 and the RAM and/or ROM 1202 are connected to each other via a bus 1203. An input/output (I/O) interface 1204 is also connected to bus 1203.

Various components in device 1200 are connected to I/O interface 1204, including: an input unit 1205 such as a keyboard, a mouse, or the like; an output unit 1206 such as various types of displays, speakers, and the like; a storage unit 1207 such as a magnetic disk, optical disk, or the like; and a communication unit 1208 such as a network card, modem, wireless communication transceiver, etc. A communication unit 1208 allows the device 1200 to exchange information/data with other devices over a computer network, such as the internet, and/or various telecommunications networks.

The computing unit 1201 may be a variety of general purpose and/or special purpose processing components having processing and computing capabilities. Some examples of the computing unit 1201 include, but are not limited to, a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), various specialized Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and so forth. The computing unit 1201 performs the various methods and processes described above, such as the method 1000. For example, in some embodiments, the method 1000 may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 1207. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device 1200 via RAM and/or ROM and/or the communication unit 1208. When loaded into RAM and/or ROM and executed by computing unit 1201, may perform one or more of the steps of method 1000 described above. Alternatively, in other embodiments, the computing unit 1201 may be configured to perform the method 1000 in any other suitable manner (e.g., by way of firmware).

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, causes the functions/acts specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, while operations are depicted in a particular order, this should be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable subcombination.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. An access control method, comprising:

determining an access control rule to apply to a service in a cloud environment, the access control rule specifying a source object in the cloud environment that is allowed to access the service;

determining a target instance of the service deployed in the cloud environment; and

enabling the access control rule at the target instance.

2. The method of claim 1, wherein determining the access control rule to apply to the service comprises:

determining an access control rule of a security group to which the service belongs as the access control rule applied to the service.

3. The method of claim 1 or 2, wherein the service comprises at least one of a cloud service, a microservice group, a microservice, or a component.

4. The method according to any one of claims 1-3, further comprising:

if an instance deployed with the service is added, the access control rule is enabled at the added instance.

5. The method according to any one of claims 1-4, further comprising:

disabling or removing the access control rule at the target instance if the target instance is no longer deploying the service.

6. The method of claims 1-5, further comprising:

disassociating the target instance from the access control rule if the target instance is no longer deploying the service.

7. The method of any of claims 1-6, wherein determining the access control rule comprises:

creating a security group based on user input, the security group including the service and the access control rules applied to the service.

8. The method of claim 7, further comprising:

based on another user input, one or more services are added to or removed from the security group.

9. The method according to any one of claims 1-8, wherein the source object comprises at least one of:

one or more services in the cloud environment,

one or more addresses in the cloud environment, or

A set of addresses in the cloud environment.

10. The method of claim 2, wherein services in the security group belong to users having the same privileges.

11. The method of any of claims 1-10, wherein enabling the access control rule at a target instance comprises:

enabling the access control rules for the service at the target instance in one or more planes, the planes being any of: management plane, storage plane, operation and maintenance plane, or traffic plane.

12. The method of any of claims 1-10, wherein enabling the access control rule at the target instance comprises:

and issuing the access control rule to the target instance through a controller of the available area where the target instance is located.

13. The method of claim 2, wherein different services belonging to the security group are deployed in different cloud environments.

14. An access control device, comprising:

a rule determination unit configured to determine an access control rule to apply to a service in a cloud environment, the access control rule specifying a source object in the cloud environment that is allowed to access the service;

an instance determination unit configured to determine a target instance of the service deployed in the cloud environment; and

a rule enabling unit configured to enable the access control rule at the target instance.

15. The method of claim 14, wherein the rule determination unit is further configured to:

16. The apparatus of claim 14 or 15, wherein the service comprises at least one of a cloud service, a micro service group, a micro service, or a component.

17. The apparatus according to any one of claims 14-16, further comprising:

a first updating unit configured to enable the access control rule at an added instance if the instance in which the service is deployed is added.

18. The apparatus according to any one of claims 14-17, further comprising:

a second updating unit configured to disable or remove the access control rule at the target instance if the target instance is no longer deploying the service.

19. The apparatus of claims 14-18, further comprising:

a third updating unit configured to disassociate the target instance from the access control rule if the target instance is no longer deploying the service.

20. The apparatus according to any of claims 14-19, wherein the rule determining unit is further configured to:

21. The apparatus of claim 20, further comprising:

a security group update unit configured to add or remove one or more services to or from the security group based on another user input.

22. The apparatus according to any one of claims 14-21, wherein the source object comprises at least one of:

one or more services in the cloud environment,

one or more addresses in the cloud environment, or

A set of addresses in the cloud environment.

23. The apparatus of claim 15, wherein services in the security group belong to users having the same privileges.

24. The apparatus according to any of claims 14-23, wherein the rule enabling unit is further configured to:

25. The apparatus according to any of claims 14-23, wherein the rule enabling unit is further configured to:

26. The apparatus of claim 15, wherein different services belonging to the security group are deployed in different cloud environments.

27. An electronic device, comprising:

at least one computing unit;

at least one memory coupled to the at least one computing unit and storing instructions for execution by the at least one computing unit, the instructions when executed by the at least one computing unit, cause the electronic device to perform the method of any of claims 1-13.

28. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-13.

29. A computer program product comprising computer executable instructions, wherein the computer executable instructions, when executed by a processor, implement the method of any one of claims 1-13.