WO2022237006A1 - Access control method and apparatus, and device - Google Patents

Abstract

Provided in the embodiments of the present disclosure are an access control method and apparatus, and a device, a storage medium and a program product. The access control method comprises: determining an access control rule for a service applied to a cloud environment, wherein the access control rule specifies a source object, which is allowed to access the service, in the cloud environment; determining a target instance, for which the service is deployed, in the cloud environment; and enabling the access control rule at the target instance. In this way, by means of the embodiments of the present disclosure, distributed access control is realized. In this way, the configuration of a security policy is simplified, and the radius of a fault in the security policy is made controllable, thereby improving the operation and maintenance efficiency of the security policy.

Description

Access control method, device and equipment technical field

Embodiments of the present disclosure mainly relate to the field of computer technology, especially the field of cloud computing. More specifically, the embodiments of the present disclosure relate to an access control method, device, device, computer-readable storage medium, and computer program product used in a cloud environment.

Background technique

Cloud technology, used to enable services hosted in cloud environments, is one of the fastest growing technologies in computing. Cloud computing can provide consumers with resources such as networks, network bandwidth, servers, storage, and applications as services. Taking the public cloud as an example, the server involves many data centers and many services. Some services may have dependencies between them and thus need to interact. In order to ensure the network security of services, security policies for different services are required for access control. Currently, such a security policy is usually implemented by a centralized firewall. However, centralized firewalls have many problems, such as low reliability, low usability, and high cost.

Contents of the invention

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

In a first aspect of the present disclosure, an access control method is provided. The method includes: determining an access control rule applied to a service in a cloud environment, where the access control rule specifies a source object in the cloud environment that is allowed to access the service. The method also includes: determining a target instance in the cloud environment where the service is deployed. The method also includes: enabling access control rules on the target instance.

In this way, distributed access control at instances with services as protected objects is realized. This method simplifies the security policy configuration and makes the failure radius of the security policy controllable, thereby improving the O&M efficiency of the security policy. Therefore, 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 applied to the service includes: determining the access control rule of the security group to which the service belongs as the access control rule applied to the service. With security groups, services that share the same access control rules can be managed uniformly. In this way, the 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 includes at least one of a cloud service, a group of microservices, a microservice or a component. In such an embodiment, services in different layers are allowed to be protected objects. In this way, the flexibility of security policy management can be increased.

In some embodiments of the first aspect, the method further includes: if an instance where the service is deployed is added, enabling access control rules on the added instance. In such an embodiment, in response to service expansion, access control rules can be automatically enabled on the added instances. In this way, the manual configuration of the security policy is simplified, thereby helping to improve the operation and maintenance efficiency of the security policy.

In some embodiments of the first aspect, the method further includes: if the target instance no longer deploys the service, disabling or removing the access control rule on the target instance. In such an embodiment, in response to scaling down of the service, access control rules may be automatically disabled or removed at the scaled down instance. In this way, the manual configuration of the security policy is simplified, thereby helping to improve the operation and maintenance efficiency of the security policy.

In some embodiments of the first aspect, the method further includes: if the target instance no longer deploys the service, disassociate the target instance from the access control rule. For example, target instances can be removed from a security group. In such an embodiment, the security policy may be automatically adjusted in response to scaling down of the service. In this way, the manual configuration of the security policy is simplified, thereby helping to improve the operation and maintenance efficiency of the security policy.

In some embodiments of the first aspect, determining the access control rules includes: creating a security group based on user input, the security group including services and access control rules applied to the services. Using security groups, users can centrally manage services that share the same access control rules. In this way, the 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 includes adding or removing one or more services to or from the security group based on another user input. In this way, access control rules at target instances can be managed simply through the addition or removal of services.

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

In some embodiments of the first aspect, the services in the security group belong to users with the same rights. In this embodiment, by setting user rights, only users with corresponding rights can designate protected objects. 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 on the target instance includes: enabling the access control rule on one or more planes of the service on the target instance, and the plane is any of the following: management plane, storage plane, operation and maintenance plane Plane or business plane. In such an embodiment, distributed access control is refined down to a plane 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 on the target instance includes: issuing the access control rule to the target instance through a controller in an availability zone where the target instance is located. In this way, access control rules can be dispatched to target instances accurately and with low latency.

In some embodiments of the first aspect, different services belonging to a security group are deployed in different cloud environments. Security groups can be used to easily implement security policy management for services in a multi-cloud environment.

In a second aspect of the present 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 the cloud environment, where the access control rule specifies a source object in the cloud environment that is allowed to access the service; an instance determination unit configured to determine the a target instance on which the service is deployed; and a rule enabling unit configured to enable access control rules on the target instance.

In this way, distributed access control at instances with services as protected objects is realized. This method simplifies the security policy configuration and makes the failure radius of the security policy controllable, thereby improving the O&M efficiency of the security policy. Therefore, embodiments of the present disclosure enable reliable and secure access control in a cloud environment.

In some embodiments of the second aspect, the rule determining unit is further configured to: determine the access control rule of the security group to which the service belongs, as the access control rule applied to the service. With security groups, services that share the same access control rules can be managed uniformly. In this way, the 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 includes at least one of a cloud service, a group of microservices, a microservice or a component. In such an embodiment, services in different layers are allowed to be protected objects. In this way, the flexibility of security policy management can be improved.

In some embodiments of the second aspect, the device further includes: a first updating unit configured to enable the access control rule on the added instance if the instance where the service is deployed is added. In such an embodiment, in response to service expansion, access control rules can be automatically enabled on the added instances. In this way, the manual configuration of the security policy is simplified, thereby helping to improve the operation and maintenance efficiency of the security policy.

In some embodiments of the second aspect, the device further includes: a second updating unit configured to disable or remove the access control rule on the target instance if the target instance no longer deploys the service. In such an embodiment, in response to scaling down of the service, access control rules may be automatically disabled or removed at the scaled down instance. In this way, the manual configuration of the security policy is simplified, thereby helping to improve the operation and maintenance efficiency of the security policy.

In some embodiments of the second aspect, the apparatus further includes: a third update unit configured to disassociate the target instance from the access control rule if the target instance no longer deploys services. In such an embodiment, the security policy may be automatically adjusted in response to scaling down of the service. In this way, the manual configuration of the security policy is simplified, thereby helping to improve the operation and maintenance efficiency of the security policy.

In some embodiments of the second aspect, the rule determining unit is further configured to: create a security group based on user input, the security group including the service and the access control rules applied to the service. Using security groups, users can centrally manage services that share the same access control rules. In this way, the 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 updating unit configured to add one or more services to the security group or remove one or more services from the security group based on another user input. In this way, access control rules at target instances can be managed simply through the addition or removal of services.

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

In some embodiments of the second aspect, the services in the security group belong to users with the same rights. In this embodiment, by setting user rights, only users with corresponding rights can designate protected objects. 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: enable the access control rules of the service on one or more planes on the target instance, and the plane is any of the following: management plane, storage plane, operation and maintenance plane or business plane. In such an embodiment, distributed access control is refined down to a plane 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 issue the access control rule to the target instance through the controller of the availability zone where the target instance is located. In this way, access control rules can be dispatched to target instances accurately and with low latency.

In some embodiments of the second aspect, different services belonging to a security group are deployed in different cloud environments. Security groups can be used to easily implement security policy management for services in a multi-cloud environment.

In a third aspect of the present disclosure, there is provided an electronic device comprising: at least one computing unit; at least one memory, the at least one memory being 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 at least one computing unit, the device is caused to implement the method of the first aspect.

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

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

It can be understood 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 used to execute the method provided in the first aspect. Therefore, the explanations or explanations about the first aspect are also applicable to the third aspect, the fourth aspect and the fifth aspect. In addition, for the beneficial effects achieved by the third aspect, the fourth aspect, and the fifth aspect, reference may be made to the beneficial effects in the corresponding methods, which will not be repeated here.

Description of drawings

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

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

Figure 2 shows a schematic diagram of an example cloud environment in which various embodiments of the present disclosure can be implemented;

Fig. 3 shows a schematic diagram of a hierarchical structure of services according to some embodiments of the present disclosure;

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

Figure 5 shows a schematic block diagram of a distributed access control architecture according to some embodiments of the present disclosure;

Fig. 6 shows a schematic diagram of user rights associated with services according to some embodiments of the present disclosure;

Figure 7 shows a schematic diagram of an example security group according to some embodiments of the present disclosure;

Fig. 8 shows a schematic diagram of another example security group according to some embodiments of the present disclosure;

FIG. 9 shows a flowchart of a process of updating a security policy according to some embodiments of the present disclosure;

Figure 10 shows a flow chart of an access control method according to some embodiments of the present disclosure;

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

Figure 12 shows a block diagram of a computing device capable of implementing various embodiments of the present disclosure.

Detailed ways

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

In the description of the embodiments of the present disclosure, the term "comprising" and its similar expressions should be interpreted as an open inclusion, that is, "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 read as "at least one embodiment". The terms "first", "second", etc. may refer to different or the same object. Other definitions, both express and implied, may also be included 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 services in a broad sense provided by the cloud environment, which may refer to the "cloud service" provided to consumers as a whole, or to the components included in the cloud service. The term "cloud" or "cloud environment" may include, but is not limited to, public clouds, private clouds, joint operations clouds, edge clouds, hybrid clouds, and the like.

As mentioned briefly above, in a cloud environment, some services may need to interact with each other. In order to ensure the network security of services, security policies for different services are required for access control. In a conventional approach, a centralized firewall provides network-layer access control to services for each network partition.

Fig. 1 shows a schematic diagram of access control provided by a centralized firewall in a conventional solution. As shown in FIG. 1 , the cloud environment 100 includes multiple network partitions, such as an operation and maintenance zone 121 , a management zone 122 , a isolated (DMZ) zone 123 , a computing zone 124 and a storage zone 125 . These network partitions are connected to firewall 101 via switches 111 , 112 , 113 , 114 and router 105 respectively. If a service in one network partition wants to access a service in another network partition, access control needs to be performed through the firewall 101 . For example, when service A in the operation and maintenance area 121 wants to access service B in the computing area 124, the service is firstly 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 a conventional solution such as the centralized firewall in Figure 1, access control can only control service access across network partitions, and access control of different services within the same network partition is a security blind spot. In addition, the security policies of many services deployed in the cloud environment 100 are all concentrated in the firewall 101. This requires the consumption of a large amount of firewall hardware, which is very expensive.

As the volume of services increases, the ability to continuously upgrade the firewall is also required. When a new service is deployed in the cloud environment 100, there are other services that the new service depends on and other services that depend on the new service. Therefore, it is necessary to open ports to access dependent services for new services, and to open ports to access new services for other services that depend on new services. It can be seen that the security policy in the conventional solution is very complicated and the maintenance cost is high. If you accidentally configure the security policy of a new service incorrectly, it will also affect the security policies of other services behind this security policy. Therefore, the failure radius of this scheme is global. In addition, this conventional solution uses IP-based configuration, which is not easy to use and is prone to errors.

To at least partially address the above problems and 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 target instances in the cloud environment on which the service is deployed are determined. Access control rules specify the source objects in the cloud environment that are allowed to access the service. Enable this access control rule on the target instance. In this way, distributed access control at instances with services as protected objects is realized. This method simplifies the security policy configuration and makes the failure radius of the security policy controllable, thereby improving the O&M efficiency of the security policy. Therefore, 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 FIGS. 1 to 12 .

example environment

FIG. 2 shows a schematic diagram of an example cloud environment 200 in which various embodiments of the present disclosure can be implemented. In general, the cloud environment 200 includes a resource configuration system 203 , a configuration database 202 , a security manager 201 and a resource production system 204 . The security manager 201, the resource configuration system 203 and the configuration database 202 may be deployed in the same or different zones, and the embodiments of the present disclosure are not limited in this respect. Users 250, such as service administrators, security administrators, etc., can interact with the resource configuration system 203, security manager 201, etc. in the 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. network partitions 230 or network partitions 230 alone. Multiple 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 multiple instance 210 or individually as instance 210. Multiple instances 210 may be distributed across multiple network partitions 230 . As an example only, instances 210-1, 210-2 and 210-3 etc. are distributed in network partition 230-1, instances 210-4 and 210-5 etc. are distributed in network partition 230-2, instances 210-6 and 210 -7, etc. are distributed in network partition 230-3, and instances 210-8 and 210-9, etc. are distributed in network partition 230-4.

Instance 210 is deployed with one or more services of the cloud environment. In an embodiment of the present disclosure, the instance 210 may be any suitable virtual resource or physical resource. Virtual resources may include, for example, virtual machines (VMs), containers, and the like. Physical resources may include, for example, physical machines (PMs), bare metal servers, network devices, security devices, interface cards, and so on. It should be understood that the number of network partitions, the number of instances, and the distribution of instances shown in FIG. 2 are exemplary only, 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 create. The resource configuration system 203 may determine an instance 210 for deploying the service, for example, determine which VM, PM or container the service is to be deployed on. Furthermore, the resource configuration system 203 can release such resources to the resource production system 204 and deploy the service in the determined instance 210 . The resource configuration system 203 can store service information and resource configuration information in the configuration database 202 . Configuration database 202 may be, for example, a configuration management database (CMDB). The service information indicates each service in the cloud environment 200, and may optionally indicate a relationship between services. The resource configuration information indicates the instance or instances in which each service is deployed. In other words, resource configuration information indicates service-to-instance relationships.

Services in cloud environment 200 may be structured in any suitable structure. In some embodiments, services in cloud environment 200 may be structured in a hierarchical structure. FIG. 3 shows a schematic diagram of a service hierarchy 300 according to some embodiments of the present disclosure. Hierarchy 300 includes three levels from top to bottom, namely cloud service, microservice group, microservice or component. Microservices or components are services or components that have independent functions and can be deployed independently. A microservice group includes a group of microservices or components with similar characteristics or functions. In the example of FIG. 3 , cloud service 310 includes microservice group 321 and microservice group 322 . Microservice group 321 includes microservice 331 and microservice 332 . Microservice group 322 includes microservice 333 and microservice 334 .

The hierarchical structure 300 shown in Figure 3 can be considered a service tree. In such an embodiment, the resource configuration system 203 may store the service tree in the configuration database 202 as service information. It should be understood that the hierarchical structure 300 including three levels shown in FIG. 3 is exemplary only, and is not intended to limit the scope of the present disclosure. In embodiments of the present disclosure, various services in a cloud environment may be constructed in any suitable number of levels. As an example, each service in the cloud environment can be constructed at two levels of cloud service and microservice.

FIG. 4 shows 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 the service-instance relationship includes five levels, namely L1, L2, L3, L4, and L5. L1 to L3 levels indicate services, namely cloud services 401 , microservice groups 402 , and microservices or components 403 . The L4 level indicates instances 404 of running or deploying microservices or components 403 . The L5 level indicates the instance address 405 of the instance 104 . Herein, an address may include but 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 the embodiments of the present disclosure, an instance deployed with a cloud service refers to an instance deployed with microservices or components under the cloud service, and an instance deployed with a microservice group refers to an instance deployed with microservices under the microservice group or an instance of a component. Therefore, in the example of FIG. 3, the instance deployed with cloud service 310 includes instances deployed with microservices 331, 332, 333 and 334, and the instance deployed with microservice group 321 includes instances deployed with microservices 331, 332, And the instances deployed with the microservice group 322 include the instances deployed with the microservices 333 and 334 .

Continue to refer to Figure 2. The service information (eg, service tree) and resource configuration information (ie, service-instance relationship) 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. Based on the resource configuration information, the security manager 201 determines the target instance on which the service is deployed from the multiple instances 210, such as instance 210-2 and instance 210-8. Then, the security manager 201 enables the access control rule on the target instance. For example, the security manager 201 dispatches access control rules to target instances as security policies.

When receiving an access request from a source object, the target instance determines whether the source object has access rights based on access control rules to accept or deny the access request. To apply access control rules, the target instance can translate the access control rules into executable instructions. Depending on the device type of the target instance (eg, VM, container, etc.), application of access control rules may be accomplished in any suitable manner. For example, an agent can be deployed in the operating system of the target instance. The agent is used to communicate with the security manager 201 and make access control rules take effect on the data plane.

In the cloud environment 200, instance-based distributed access control can be implemented. This greatly reduces the radius of failure of security policies compared to centralized firewalls. Cloud environment 200 may include, but is not limited to, public clouds, private clouds, joint operations clouds, edge clouds, hybrid clouds, and combinations thereof. Furthermore, this distributed access control can be achieved across two or more cloud environments. For example, multiple instances 210 may be provided by different cloud environments.

system structure

An example architecture for implementing distributed access control is described below. FIG. 5 shows a schematic block diagram of a distributed access control architecture 500 according to some embodiments of the present disclosure. In general, the architecture 500 includes a security policy orchestration layer 510 , a security policy scheduling layer 520 and a security policy execution layer 530 . Security policy orchestration layer 510 includes security manager 201 . The security policy scheduling layer 520 includes controllers 521 , 522 and 523 of availability zones. Security policy enforcement layer 530 includes instances 531 , 532 , 533 and 534 in availability zones. In the example in FIG. 5 , controller 521 is the controller of the availability zone where instance 531 is located, controller 522 is the controller of the availability zone where instance 532 is located, and controller 523 is the controller of the availability zone where instances 533 and 534 are located. The controller can be, for example, a dedicated server in an availability zone. The architecture 500 shown in FIG. 5 is exemplary only, and is not intended to limit the scope of the present disclosure. The distributed access control architecture can also be divided 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 the protected service (also referred to as "target service" hereinafter) with corresponding access control rules. Access control rules specify the source objects in cloud environment 200 that are allowed to access the service. In some embodiments, if the service in the cloud environment 200 is structured in a hierarchical structure, the service may belong to any level in the hierarchical structure. In an embodiment having a hierarchical structure 300 as shown in FIG. 3 , the service may include any one of a cloud service, a microservice group, a microservice, or a component. In such an embodiment, services in different layers are allowed to be protected objects. In this way, the flexibility of security policy management can be improved.

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

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

In some embodiments, user permissions associated with the service may be set. In other words, in such an embodiment, the user 505 can only designate services belonging to the user 505 as protection objects. Reference is now made to FIG. 6 . FIG. 6 shows a schematic diagram of user permissions associated with services according to some embodiments of the present disclosure. In the 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 authority. Users 601, 602, and 603 belong to different groups 611, 612, and 613, respectively. The role of the group 611 is the service administrator of the cloud service 621 . Correspondingly, a user belonging to the group 611 (for example, the user 601 ) can select a service from the cloud service 621 and the microservice groups, microservices or components included therein as a protection object. The role of group 612 is a service administrator of cloud service 622 . Correspondingly, a user belonging to the group 612 (for example, the user 602 ) can select a service from the cloud service 622 and the microservice group, microservice or component included therein as a protection object. The role of group 613 is security administrators of system resources 623 . Correspondingly, a user belonging to the group 611 (for example, user 603 ) can select a service from all cloud services and microservice groups, microservices or components as protection objects. In this embodiment, by setting user rights, only users with corresponding rights can designate protected objects. In this way, the reliability and security of access control can be further enhanced.

Refer back to FIG. 5 . As mentioned above, the source objects that are allowed to access the target service may be specified by a pre-configuration file or by user input from user 505 . Policy orchestration module 501 may provide one or more schemas to specify source objects. In some embodiments, source objects may include one or more services in cloud environment 200 . For example, policy orchestration module 501 can provide service patterns to users 505 . In service mode, policy orchestration module 501 presents user 505 with a user interface displaying service information (eg, a service tree). The user 505 can select one or more services through the user interface, and the selected services are allowed to access the target service. In this case, the policy orchestration module 501 may determine the address (eg, IP address) of the instance where the selected service is deployed based on the resource configuration information from the configuration database 202 to determine the access control rule. That is, the determined address is allowed to access the target instance.

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

Alternatively or additionally, in some embodiments, a source object may comprise a collection of addresses in a cloud environment. For example, policy orchestration module 501 can provide address pool mode to user 505 . In the address pool mode, the user 505 can select an address pool from multiple predefined address pools to specify a source object. Each address pool may include a collection of addresses, such as multiple addresses, one or more address ranges, and combinations thereof. The policy orchestration module 501 can determine 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 are described by taking the user input to specify the source object as an example, this is only exemplary. These modes can also be used in cases where a preconfiguration file specifies a source object. For example, a service, one or more addresses, or an address pool can be specified as a source object in a preconfiguration file.

In addition to the source object, user input or a pre-configuration file may also specify the protocol port of the target instance (ie, the destination protocol port) as part of the access control rules. As an example, a port number for Transmission Control Protocol (TCP), such as TCP 443, may be specified. In this way, in the service mode, the access control rule can allow the determined address to access the target instance with the TCP port 443; in the address mode, the access control rule can allow the address entered by the user 505 to access the target instance with the TCP port 443; In the address pool mode, the access control rule can allow addresses in the selected address pool to access the target instance through TCP port 443.

The policy management module 502 in the security manager 201 is used to determine target instances where protected services are deployed. For example, the target instance can be determined based on resource configuration information from the configuration database 202 . The policy management module 502 is also used to manage service information, resource configuration information and security policies. Specifically, the policy management module 502 can monitor service and resource configuration updates. Service updates may include, but are not limited to, the increase of microservices (for example, online), the reduction of microservices (for example, offline), the expansion of microservices, the shrinkage of microservices, the increase of regions, the Changes, changes in availability zones, etc. The update of the service may cause the update of the resource configuration, for example, the increase, decrease, change, etc. of the instances deployed by the service.

In some embodiments, policy management module 502 may receive real-time messages from configuration database 202 to monitor service and resource configuration updates. Such real-time messages are generated in response to and indicate updates to service or resource configurations. Examples of real-time messages may include, but are not limited to, configuration management database instance messages, cloud service view service tree messages, microservice instance messages, cloud location zone 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 of service and resource configurations. For example, policy management module 502 may periodically receive service trees and service-to-instance relationships from configuration database 202 . In such an embodiment, periodic synchronization can be used to avoid information mismatch problems caused by real-time message sending and receiving failures, thereby enhancing the reliability of distributed access control. In the case of the combination of real-time messages and periodic synchronization, it can be ensured that the security manager 201 knows the relationship between services and instances in a timely and reliable manner, so as to accurately determine the target instance.

Additionally, the policy management module 502 can maintain the relationship of protected services and access control rules. When monitoring the update of the service and resource configuration, the policy management module 502 can update the relationship between the service and the access control rule accordingly. For example, if a reduction in services is detected, the policy management module 502 may disassociate the reduced services from the corresponding access control rules. The security manager 201 may further disable or remove the access control rule in the instance where the reduced service is originally deployed. As another example, if an increase of a service is detected, the policy management module 502 may determine an access control rule applied 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 on the target instance. Specifically, the policy scheduling engine 503 can issue access control rules to target instances in the security policy enforcement layer 530. In some embodiments, if the instances in the cloud environment are located in different availability zones, the policy scheduling engine 503 issues the access control rules to the target instance through the controller of the availability zone where the target instance is located. In the example of FIG. 5 , when the target instance includes the instance 531 , the policy scheduling engine 503 can issue the access control rules to the instance 531 through the controller 521 . In the case that the target instance includes the instance 532 , the policy scheduling engine 503 can issue the access control rules to the instance 532 through the controller 522 . In the case that the target instance includes the instance 533 and/or the instance 534 , the policy scheduling engine 503 may issue the access control rules to the instance 533 and/or the instance 534 through the controller 523 .

Distributed access control is realized using the system architecture described above. Security policies are dispatched to instances through policy orchestration and dispatch software technology, which reduces costs compared to hardware firewalls. For each service that needs to be protected, the corresponding access control rules can be enabled on one or more target instances where the service is deployed. The access control rules of different businesses are only on the instance of this service, and different services are physically isolated from each other, which reduces the failure radius when the security policy is wrong. The source object specified by the access control rules can be configured as desired and is not limited to being in a different zone from the target instance. In this way, security blind spots in centralized firewall solutions are eliminated.

security group

Considering that some services may have the same security policy and share the same access control rules, in some embodiments, security groups can be used to manage multiple services sharing the same access control rules. Security manager 201 (eg, policy orchestration module 501 ) can create security groups based on user input. The created security group includes these services and shared access control rules. As an example, the user 505 may create a security group and add services to the security group through a user interface, and specify a source object by specifying a service, address, or address pool. The security manager 201 can take the service added by the user as a member of the security group, and generate the access control rules of the security group based on the specified source object. In some embodiments, security manager 201 may add the determined target instance to a security group. In some embodiments, for example, in the case of applying the RBAC model shown in FIG. 6 , services in a security group may belong to users with the same authority.

In such an embodiment, the security manager 201 may determine the access control rules of the security group as the access control rules applied to the services in the security group. The user 505 can provide subsequent input through the user interface when the security group needs to be updated. Based on subsequent input, the security group may be updated. For example, one or more services may be added to a security group to apply the security group's access control rules to the added services. As another example, one or more services originally belonging to a security group may be removed from the security group.

In addition, the security manager 201 (eg, the policy management module 502 ) can update the security group accordingly when monitoring the update of the service and resource configuration. For example, if a reduction of a service is detected, the security manager 201 may remove the reduced service from the security group to which it originally belongs, so as to disassociate the service from the corresponding access control rule. For another example, if an increase of a service is detected, the security manager 201 may determine the security group to which the added service belongs and add it to the security group, thereby associating the added service with a corresponding access control rule.

With security groups, services that share the same access control rules can be managed uniformly. In this way, the 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 can be deployed in different cloud environments. For example, some services in a security group are deployed in a public cloud, while others are deployed in a private cloud. In this way, cross-cloud management of security policies can be conveniently realized.

FIG. 7 shows a schematic diagram of an example security group 701 according to some embodiments of the present disclosure. FIG. 7 takes the three-level hierarchical structure shown in FIG. 3 as an example, but this is only 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 including cloud service B, microservice group A and microservice C is created. Accordingly, security group 701 includes service directory 702. In the service catalog 702, the entry "identification of cloud service B" indicates that the security group 701 includes cloud service B at the cloud service level, and the entry "identification of microservice group A" indicates that the security group 701 includes microservice group A at the microservice group level , and the entry "identification of microservice C" indicates that the security group 701 includes microservice C at the microservice level.

Based on user input 705, access control rules 703 for the security group are generated. Access control rule 703 will be applied to cloud service B, microservice group A and microservice C belonging to security group 701 . Correspondingly, the security manager 201 enables the access control rule 703 on all instances where the cloud service B, the microservice group A and the microservice C are deployed. In other words, all instances deployed with cloud service B, microservice group A, and microservice C allow access from the source address 10.52.80/24 on TCP port 443.

In the example of FIG. 7 , services in the cloud environment are structured in multiple tiers, and security groups are allowed to include services in different tiers. In this way, the flexibility of security policy management can be increased. Allowing the specified cloud service has the effect of turning parts into wholes, so that users do not have to select each microservice under the cloud service one by one. Allows specifying microservices or components to refine security policy management.

It should be understood that the security group, source address, port number, etc. shown in FIG. 7 are all exemplary, and are not intended to limit the scope of the present disclosure. A security group may include any suitable number of services, such as any suitable number of cloud services, microservice groups, microservices.

In some embodiments, security policy management can be further refined to plane granularity. Access control rules for protected services on one or more planes (also referred to as "target planes" hereinafter) can be enabled on the target instance. The plane can be any of the management plane, storage plane, operation and maintenance plane, or service plane. For example, you can enable protected services with management plane access control rules only on target instances where the access control rules apply to the management plane.

Accordingly, the security manager 201 may maintain instance information about the target plane. The following describes this embodiment by taking a security group as an example with reference to FIG. 8 . FIG. 8 shows a schematic diagram of another example security group 801 according to some embodiments of the present disclosure. FIG. 8 takes the three-level hierarchical structure shown in FIG. 3 as an example, but this is only exemplary and not intended to limit the content of the present 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.

Instances deployed with microservice 810 include instance A, instance B, and instance C, wherein instance B does not involve the target plane, and instances A and C involve the target plane. For instance A, all ports are applied to the target plane, or for instance A the planes are not differentiated. For example C, port A and port C are applied to the target plane, while port B is applied 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 rule 803 is only enabled on port A and port C of instance C.

Correspondingly, the security group 801 includes an instance directory 802 . In the instance directory 802, the entry "identification of instance A" and its subentries indicate instance A and all addresses of instance A, and the entry "identification of instance C" and its subentries indicate instance C, instance C's The address of port A and the address of 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 the port or the plane to which the port applies.

In the example of FIG. 8 , security manager 201 enables access control rule 703 on 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 from the source address 10.52.80/24 on TCP port 443.

In such an embodiment, distributed access control is refined down to a plane granularity. In this way, the accuracy of security policy management can be improved, and the failure radius can be further reduced.

Security Policy Updates

As described with reference to FIG. 5, the policy management module 502 can monitor for updates to service and resource configurations. Based on updates to service and resource configurations, security manager 201 can update security policies. Figure 9 shows a flow diagram of a process 900 for updating security policies according to some embodiments of the present disclosure.

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

If at block 910 it is determined that service scaling exists, process 900 proceeds to block 920 . In other words, process 900 proceeds to block 920 if additional instances of a protected service are deployed. At block 920, the security manager 201 associates the added instance with the access control rules applied to the service. For example, in an embodiment where a security group is created, the added instance may be added to the security group in which the service resides. At block 930, the security manager 201 enables the access control rule on the added instance. For example, the security manager 201 may issue the access control rule to the added instance through the controller of the availability zone where the added instance is located.

If at block 910 it is determined that there is a service shrink, process 900 proceeds to block 940 . In other words, process 900 proceeds to block 940 if the target instance that had a protected service deployed no longer has the service deployed. At block 940, the security manager 201 disassociates the target instance on which the service is no longer deployed from the access control rules applied to the service. For example, in an embodiment 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, the security manager 201 disables or removes the access control rules applied to the service on target instances where the service is no longer deployed. For example, the security manager 201 may send a message or command to the target instance to mark the access control rule as disabled in the target instance, or delete the access control rule locally from the target instance.

The process 900 of automatically updating security policies is described above with respect to services in a broad sense. Process 900 can be applied to services of any granularity. In the embodiment in which services are built with the hierarchical structure shown in FIG. 3 , the services to be scaled up or down may include any one or more of cloud services, microservice groups, microservices or components.

In such embodiments, security policies may be automatically updated in response to updates to service and resource configurations. That is, in response to the expansion of the service, the access control rule can be automatically enabled on the increased instance; in response to the shrinkage of the service, the access control rule can be automatically disabled or removed from the reduced instance. In this way, the manual configuration of the security policy is simplified, thereby helping to improve the operation and maintenance efficiency of the security policy.

EXAMPLE PROCESSES, APPARATUS AND EQUIPMENT

FIG. 10 shows a flowchart of an access control method 1000 according to some embodiments of the present disclosure. The method 1000 can be implemented, for example, by the security manager 201 in FIG. 2 . For convenience of description, the method 1000 is described below with reference to FIGS. 2-8 .

At block 1010, access control rules to apply to services in a cloud environment are determined. Access control rules specify the source objects in the cloud environment that are allowed to access the service. Cloud environments are, for example, public clouds, private clouds, joint operations clouds, edge clouds, hybrid clouds, and combinations thereof. In some embodiments, the service includes at least one of a cloud service, a group of microservices, a microservice, or a component. For example, in the case that a service in a cloud environment is constructed with the hierarchical structure 300 shown in FIG. 3 , the service may include a cloud service, a microservice group, a microservice or a component.

In some embodiments, the source object includes at least one of: one or more services in the cloud environment, one or more addresses in the cloud environment, or a collection of addresses in the cloud environment. For example, one or more of service mode, address mode and 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, the access rule 703 of the security group 701 may be determined as the access control rule applied to cloud service B, microservice group A and microservice C.

In some embodiments, a security group may be created based on user input, the security group including the service and the access control rules applied to the service. For example, security group 701 can be created based on user input 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, security group 701 may be updated based on subsequent input.

In some embodiments, services in a security group belong to users with the same permissions. For example, a BRAC model as shown in FIG. 6 may be set to manage user's security policy configuration for services.

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

At block 1020, target instances in the cloud environment where the service is deployed are determined. For example, the target instance can be determined based on resource configuration information (ie, service-instance relationship). A target instance can be any suitable virtual or physical resource. Virtual resources may include, for example, VMs, containers, and the like. Physical resources may include, for example, PMs, bare metal servers, network devices, security devices, interface cards, and so on. At block 1020, access control rules are enabled on the target instance. For example, security manager 201 dispatches access control rules to the determined one or more target instances.

In some embodiments, access control rules serving services at one or more planes may be enabled on the target instance. The plane can be any of the following: management plane, storage plane, operation and maintenance plane, or service plane. For example, for instance C shown in FIG. 8 , access control rule 803 is only enabled on port A and port C, and port A and port C are applicable to the same plane as access control rule 803 .

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

In some embodiments, the method 1000 further includes: if an instance deployed with the service is added, enabling access control rules on the added instance. The added instance can also be associated with the access control rule at the security manager 201, for example, added to the security group to which the service belongs.

In some embodiments, the method 1000 further includes: disabling or removing the access control rule on the target instance if the service is no longer deployed on the target instance. The target instance can also be disassociated from the access control rules at the 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 apparatus 1100 according to an embodiment of the present disclosure, and the apparatus 1100 may include a plurality of units for performing 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 access control rules applied to services in the cloud environment. Access control rules specify the source objects in the cloud environment that are allowed to access the service. The apparatus 1100 further includes an instance determination unit 1120 configured to determine a target instance in which the service is deployed in the cloud environment. The apparatus 1100 further includes a rule enabling unit 1130 configured to enable access control rules on the target instance.

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

In some embodiments, the service includes at least one of a cloud service, a group of microservices, a microservice, or a component.

In some embodiments, the apparatus 1100 further includes: a first update unit configured to enable access control rules on the added instance if an instance deployed with the service is added.

In some embodiments, the apparatus 1100 further includes: a second update unit configured to disable or remove the access control rule on the target instance if the target instance no longer deploys the service.

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

In some embodiments, the rule determination unit 1110 is further configured to: create a security group based on user input, the security group includes services and access control rules applied to the services.

In some embodiments, the apparatus 1100 further includes: a security group update unit configured to add one or more services to the security group or remove one or more services 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 the cloud environment, one or more addresses in the cloud environment, or a collection of addresses in the cloud environment.

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

In some embodiments, the rule enabling unit 1130 is further configured to: enable the access control rules of the service on one or more planes on the target instance, and the plane is any of the following: management plane, storage plane, operation and maintenance plane or business plane .

In some embodiments, the rule enabling unit 1130 is further configured to issue the access control rule to the target instance through the controller of the availability zone 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 that may be used to implement embodiments of the present disclosure. The device 1200 may be used to implement the security manager 201 or the like. As shown, device 1200 includes computing unit 1201, which may be loaded into RAM and/or ROM according to computer program instructions stored in random access memory (RAM) and/or read only memory (ROM) 1202 or from storage unit 1207 1202 to perform various appropriate actions and processes. In the RAM and/or ROM 1202, various programs and data necessary 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 the bus 1203 .

Multiple components in the device 1200 are connected to the I/O interface 1204, including: an input unit 1205, such as a keyboard, a mouse, etc.; an output unit 1206, such as various types of displays, speakers, etc.; a storage unit 1207, such as a magnetic disk, an optical disk, etc. ; and a communication unit 1208, such as a network card, a modem, a wireless communication transceiver, and the like. The 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 telecommunication networks.

The computing unit 1201 may be various general-purpose and/or special-purpose processing components with processing and computing capabilities. Some examples of computing units 1201 include, but are not limited to, central processing units (CPUs), graphics processing units (GPUs), various dedicated artificial intelligence (AI) computing chips, various computing units that run machine learning model algorithms, digital signal processing processor (DSP), and any suitable processor, controller, microcontroller, etc. The calculation unit 1201 executes various methods and processes described above, such as the method 1000 . For example, in some embodiments, method 1000 may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as storage unit 1207 . In some embodiments, part or all of the computer program may be loaded and/or installed onto device 1200 via RAM and/or ROM and/or communication unit 1208 . When a computer program is loaded into RAM and/or ROM and executed by computing unit 1201, one or more steps of method 1000 described above may be performed. Alternatively, in other embodiments, the computing unit 1201 may be configured to execute the method 1000 in any other suitable manner (for example, by means of firmware).

Program codes for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general-purpose computer, a special purpose computer, or other programmable data processing devices, so that the program codes, when executed by the processor or controller, make the functions/functions specified in the flow diagrams and/or block diagrams Action is implemented. 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 the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A 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, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media would include one or more wire-based electrical connections, portable computer discs, hard drives, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), optical fiber, compact disk read only memory (CD-ROM), optical storage, magnetic storage, or any suitable combination of the foregoing.

In addition, while operations are depicted in a particular order, this should be understood to require that such operations be performed in the particular order shown, or in sequential order, or that all illustrated operations should be performed to achieve desirable results. Under certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while the above discussion contains several specific implementation details, 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 merely example forms of implementing the claims.

Claims (29)

1. An access control method, characterized in that, comprising:

   determining access control rules applied to a service in a cloud environment, the access control rules specifying source objects in the cloud environment that are permitted to access the service;

   determining target instances in the cloud environment on which the service is deployed; and

   Enable the access control rule on the target instance.
2. The method according to claim 1, wherein determining the access control rule applied to the service comprises:

   Determining the access control rule of the security group to which the service belongs as the access control rule applied to the service.
3. The method according to claim 1 or 2, wherein the service includes 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 where the service is deployed is added, the access control rule is enabled on the added instance.
5. The method according to any one of claims 1-4, further comprising:

   If the target instance no longer deploys the service, disable or remove the access control rule on the target instance.
6. The method according to claims 1-5, wherein the method further comprises:

   If the target instance no longer deploys the service, disassociate the target instance from the access control rule.
7. The method according to any one of claims 1-6, wherein determining the access control rule comprises:

   A security group is created based on user input, the security group including the service and the access control rules applied to the service.
8. The method according to claim 7, wherein the method further comprises:

   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 the following:

   one or more services in said cloud environment,

   one or more addresses in said cloud environment, or

   A collection of addresses in the cloud environment.
10. The method according to claim 2, wherein the services in the security group belong to users with the same authority.
11. The method according to any one of claims 1-10, wherein enabling the access control rule on the target instance comprises:

    Enabling the access control rules of the service on one or more planes in the target instance, the plane being any of the following: management plane, storage plane, operation and maintenance plane or service plane.
12. The method according to any one of claims 1-10, wherein enabling the access control rule on the target instance comprises:

    The access control rule is issued to the target instance through the controller of the availability zone where the target instance is located.
13. The method according to claim 2, wherein different services belonging to the security group are deployed in different cloud environments.
14. An access control device, characterized in that it comprises:

    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 determining unit configured to determine a target instance in which the service is deployed in the cloud environment; and

    A rule enabling unit configured to enable the access control rule on the target instance.
15. The method according to claim 14, wherein the rule determining unit is further configured to:

    Determining the access control rule of the security group to which the service belongs as the access control rule applied to the service.
16. The device according to claim 14 or 15, wherein the service includes at least one of a cloud service, a microservice group, a microservice or a component.
17. The device according to any one of claims 14-16, wherein the device further comprises:

    The first update unit is configured to enable the access control rule on the added instance if the instance deployed with the service is added.
18. The device according to any one of claims 14-17, wherein the device further comprises:

    The second update unit is configured to disable or remove the access control rule on the target instance if the target instance no longer deploys the service.
19. The device according to claims 14-18, wherein the device further comprises:

    A third updating unit configured to disassociate the target instance from the access control rule if the target instance no longer deploys the service.
20. The device according to any one of claims 14-19, wherein the rule determining unit is further configured to:

    A security group is created based on user input, the security group including the service and the access control rules applied to the service.
21. The device according to claim 20, further comprising:

    A security group updating unit configured to add one or more services to the security group or remove one or more services from the security group based on another user input.
22. The device according to any one of claims 14-21, wherein the source object includes at least one of the following:

    one or more services in said cloud environment,

    one or more addresses in said cloud environment, or

    A collection of addresses in the cloud environment.
23. The device according to claim 15, wherein the services in the security group belong to users with the same authority.
24. The device according to any one of claims 14-23, wherein the rule enabling unit is further configured to:

    Enabling the access control rules of the service on one or more planes in the target instance, the plane being any of the following: management plane, storage plane, operation and maintenance plane or service plane.
25. The device according to any one of claims 14-23, wherein the rule enabling unit is further configured to:

    The access control rule is issued to the target instance through the controller of the availability zone where the target instance is located.
26. The device according to 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 that, when executed by the at least one computing unit, cause the The electronic device executes the method according to any one of claims 1-13.
28. A computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the method according to any one of claims 1-13 is realized.
29. A computer program product comprising computer-executable instructions, wherein said computer-executable instructions, when executed by a processor, implement the method according to any one of claims 1-13.

Images