WO2020019839A1 - 一种企业云的创建方法和管理平台 - Google Patents

一种企业云的创建方法和管理平台 Download PDF

Info

Publication number
WO2020019839A1
WO2020019839A1 PCT/CN2019/087890 CN2019087890W WO2020019839A1 WO 2020019839 A1 WO2020019839 A1 WO 2020019839A1 CN 2019087890 W CN2019087890 W CN 2019087890W WO 2020019839 A1 WO2020019839 A1 WO 2020019839A1
Authority
WO
WIPO (PCT)
Prior art keywords
tenant
cloud
enterprise
project
vec
Prior art date
Application number
PCT/CN2019/087890
Other languages
English (en)
French (fr)
Inventor
刘正军
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2020019839A1 publication Critical patent/WO2020019839A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices

Definitions

  • This application relates to the field of information technology security, and more specifically, to a method for creating an enterprise cloud and a management platform.
  • Cloud services are basic public facilities like tap water and electricity. They pursue cost performance and reliability, and provide better services with less management software and hardware costs. But for enterprises, after the information is networked electronically, information security on cloud services becomes even more important.
  • an access policy can be used to set whether different people in the enterprise can use and view the permissions of certain specific resources.
  • personnel in the enterprise cannot access and use some information with a higher level of information security.
  • the cloud resources used by the enterprise do not have security attributes, and personnel in the enterprise can only have cloud resources with one security attribute.
  • an enterprise administrator needs to be manually controlled from top to bottom or needs its own cloud platform adaptation and docking to achieve enterprise organizational structure and enterprise information security.
  • This application provides an enterprise cloud creation method and management platform.
  • different security levels can be set according to the importance, sensitivity, and security of enterprise information to ensure information security within the enterprise.
  • departments within the enterprise and even ordinary employees can have a high ability to control resources and use resources flexibly.
  • a method for creating an enterprise cloud includes: a management platform creates a plurality of virtual enterprise clouds; the management platform receives a first instruction, and adds a tenant to at least one virtual enterprise according to the first instruction Cloud, the at least one virtual enterprise cloud is part or all of the plurality of virtual enterprise clouds.
  • the embodiments of the present application can isolate the underlying shared resources according to the security level or business relevance of the information, and can save the information in different security zones.
  • the virtual enterprise cloud VEC can be understood as the above security zone.
  • An enterprise organization can be divided into one security zone or multiple security zones.
  • Each virtual enterprise cloud VEC can build or provide cloud resources for users or tenants in the VEC based on cloud services.
  • Cloud services can include, but are not limited to, network services, computing services, storage services, and so on.
  • An enterprise root tenant in the field of cloud computing can refer to a tenant account registered on a cloud service. This tenant account has the right to use all cloud services and can manage all resources in the tenant.
  • the enterprise root tenant can be the embodiment of the user's corresponding service resource container carrier and ownership, and the cloud operator can charge fees through the financial account associated with the account.
  • an enterprise tenant can serve as a cloud operation administrator of the virtual enterprise cloud, and can create a virtual enterprise cloud on the underlying cloud service.
  • Management rights for enterprise tenants can include, but are not limited to: building an organizational structure within the enterprise (e.g., the company divides different departments according to different business types), creating a VEC, setting a list of services available and / or disabled in the VEC, and formulating Inter-connectivity strategies, formulate inter-connectivity strategies with external VECs (eg, ordinary tenants, VECs of other enterprises), implement corporate budget systems, and settle and / or analyze corporate expenses.
  • building an organizational structure within the enterprise e.g., the company divides different departments according to different business types
  • creating a VEC setting a list of services available and / or disabled in the VEC
  • formulating Inter-connectivity strategies formulate inter-connectivity strategies with external VECs (eg, ordinary tenants, VECs of other enterprises), implement corporate budget systems, and settle and / or analyze corporate expenses.
  • the enterprise tenant sets permissions, a list of available and / or disabled services, and formulates interconnection and interworking policies between VECs
  • the organizations and employees affiliated to the enterprise enforce compliance to ensure the security of the information enterprise information. For example, if two resources requesting interoperability belong to different VECs, and the enterprise tenant specifies isolation between VECs (that is, resources between different VECs are not allowed to be interconnected), even if the two resources are on the underlying cloud service
  • the resources belong to the same tenant, and the management system does not allow the two resources to communicate with each other.
  • an enterprise tenant can also provide services for the virtual enterprise cloud, allowing the tenant to use services, available billing models, and default tenant resources on the virtual enterprise cloud. Quotas, VEC effective regions, and other information required to operate the virtual enterprise cloud.
  • the management platform can add tenants to multiple VECs that are created.
  • the embodiment of this application does not limit the specific implementation of tenants to VEC.
  • a tenant may apply to join the VEC.
  • a tenant may apply for a VEC that needs to be accessed and used, and an enterprise tenant may review whether the tenant can join the applied VEC.
  • an enterprise tenant may also invite the tenant to join the VEC.
  • the enterprise tenant may specify the VEC that the tenant can access and use, and the management system may add the tenant to the corresponding VEC.
  • an enterprise tenant when adding a tenant, may also specify a quota, a charging mode, etc. for the use of tenant resources, or dynamically adjust it.
  • the quota of tenants in the virtual enterprise cloud is not greater than the quota specified by the underlying cloud service for the tenant, and the sum of the quotas of the same tenant in multiple virtual enterprise clouds does not exceed the quota specified by the underlying cloud service for the tenant.
  • an enterprise tenant can create a VEC, and after adding a tenant, it can view which VECs have been created and the tenants in each VEC. After joining the VEC, the tenant can select a different region after entering the VEC.
  • an enterprise tenant creates multiple VECs, and the multiple VECs are independent of each other, and services within the VEC are controllable and securely compliant. It enables enterprises to have their own independent, complete, secure, compliant, service-controllable, and maintenance-free virtual enterprise cloud. Different security levels can be set according to the importance, sensitivity, and security of enterprise information. While ensuring information security, departments within the enterprise and even ordinary employees can have a higher ability to control resources and use resources flexibly. .
  • VEC may be implemented based on an existing project in Open Stack, and its implementation is simple.
  • the underlying tenant can be mapped to a domain in OpenStack, and there can be multiple projects (projects in OpenStack) below the tenant.
  • the project can be a collection or container of cloud resources, and it can also have permission authentication for these cloud resources and tenants (where the tenant can specify the interworking rules between its own project).
  • VEC can be implemented based on an existing project in Open Stack, and its implementation is simple. Enterprises, departments, and ordinary tenants of the enterprise can remain relatively independent, and can have independent and complete ability to use resources.
  • the management platform receives a first instruction and adds a tenant to at least one virtual enterprise cloud according to the first instruction instruction, and the management platform includes: At least one item of the tenant is added to the at least one virtual enterprise cloud, and each item includes cloud resources that the tenant is allowed to access in the virtual enterprise cloud to which each item belongs.
  • the management platform may add a tenant to at least one virtual enterprise cloud that is created. Specifically, the management platform may add at least one project of the tenant to at least one virtual enterprise cloud, and the project may include cloud resources that the tenant is allowed to access.
  • the management platform configures the access rights of the tenant in the at least one project, so that the tenant has the ability to manage cloud resources included in each project .
  • the tenant has the ability to fully manage allowed cloud resources in the multiple virtual enterprise clouds.
  • tenants added to VEC can have tenant characteristics, and tenants added to VEC can fully control the various infrastructure as a service (IaaS) resources and platform as a service (IaaS) specified by the enterprise tenant.
  • PaaS platform infrastructure services
  • SaaS software infrastructure services
  • tenant added to the VEC is not specifically limited in the embodiment of the present application.
  • a tenant added to VEC represents a specific employee in the enterprise.
  • tenants added to VEC represent a certain department.
  • the tenant added to the VEC represents a certain department (that is, it can be a department tenant)
  • the tenant can serve as a department administrator, and can be used for users and sub-users under it.
  • Departments perform authority setting and management.
  • department tenants can create users, manage users, set the user's permissions in the virtual enterprise cloud, and set other security rules.
  • the tenant added to the VEC may further set some additional security rules based on the rules set by the enterprise tenant (virtual enterprise cloud administrator).
  • the tenant added to the VEC can be set after the enterprise tenant has set the security rules, and the VEC can be additionally set to prohibit network interworking. The ordinary tenants and user accounts connected to it must comply with the security rule.
  • the tenant ET After the enterprise tenant ET has set the security policy, the tenant does not have access to unauthorized VECs or access to unauthorized services. At the same time, the tenants added to the VEC must comply with the security policy set by the corporate tenant ET. That is to say, after the enterprise tenant has created the VEC as an administrator and set the security access policy, the tenants added to the VEC access and operate the resources, and they are forced to follow the VEC, VEC set by the enterprise tenant (enterprise administrator) Access security rules between VECs and other companies' VECs, and between non-VECs.
  • the tenant has the ability to fully manage various permitted cloud resources in the multiple virtual enterprise clouds, which can prevent the enterprise tenant in the prior art from being solely responsible for the resource and security management of all departments in the enterprise.
  • the method further includes: the management platform receives a second instruction; and the management platform records the security rule.
  • the virtual enterprise cloud VEC created on the bottom layer in the embodiment of the present application is defined as a cloud itself, the clouds are independent and not interconnected. Therefore, by default, resources between VECs cannot be communicated and shared.
  • the federation Resources can be shared or communicated between clouds.
  • the enterprise tenant (as the enterprise administrator) can have the ability to set the interconnection and interworking strategy between VECs.
  • the resources between the VECs of the alliance can be directly interconnected with the authorization of the enterprise tenant and the cloud platform has the capability, and the default resources of the system between the non-consortium VECs prohibit the interconnection and interconnection.
  • VECs that establish a federal cloud may be the same enterprise tenant or cross-enterprise tenants, which are not specifically limited in this application.
  • VEC1 and VEC2 are cloud alliances (resources can be interconnected and / or shared between VEC1 and VEC2)
  • VEC2 and VEC3 are cloud alliances (resources can be interconnected and / or shared between VEC2 and VEC3)
  • VEC1 It does not belong to the cloud alliance with VEC3 (that is, resources between VEC1 and VEC3 can be interconnected and / or shared). If the resources between VEC1 and VEC3 need to be communicated and / or shared, an alliance relationship needs to be established between VEC1 and VEC3.
  • an enterprise tenant (as an enterprise administrator) sets two VECs as a federal cloud (that is, resources between the two VECs can be interconnected and interoperable)
  • the management system allows the resources between the two VECs to be interconnected or Interoperability can be handled in accordance with the normal process of resource sharing and / or interworking of corresponding services within the tenant or between tenants on the underlying cloud service.
  • an enterprise tenant (as an enterprise administrator) does not set up an alliance relationship between two VECs, it can be assumed that the VECs are independent from each other, that is, the resources between the VECs cannot be interconnected.
  • the enterprise tenant ET can not only set the alliance relationship between the resources created by the VECs, but also the interconnections between the VECs in the enterprise and other enterprise VECs and external ordinary tenants.
  • whether the resources of the two tenants in the federal cloud can be shared and / or interoperable depends on whether the target tenant agrees to the resource sharing and / or interoperable. As an example, if a tenant shares resources to everyone, other tenants in the federal cloud can share it, otherwise only the specified tenant can share resources.
  • the enterprise tenant (as the enterprise administrator) may also set some other more detailed security rules based on the interconnection and interworking strategy between VECs.
  • an enterprise tenant may set that only network service resources can communicate between the interconnected VECs.
  • an enterprise tenant may set that only specified resources can be communicated and accessed between interconnected VECs. This application does not specifically limit this.
  • the method further includes: the management platform receives a first request; and the management platform determines whether to allow the first item according to the recorded security rules And resource sharing and / or interworking with the second project.
  • first request for the first project for the first tenant to initiate resource sharing and / or interworking to the second project for the second tenant, wherein the first project belongs to the first virtual enterprise cloud and the second project belongs to the second virtual enterprise Enterprise cloud.
  • a first tenant in the first virtual enterprise cloud may share and / or communicate resources in the second enterprise cloud through a service request.
  • the first tenant and the second tenant may be the same tenant or two different tenants on the bottom layer, which is not specifically limited in this application.
  • the management The platform allows resource sharing and / or interworking between the first project and the second project according to the resource sharing and / or interworking process of corresponding services between the first tenant and the second tenant;
  • the security rules do not allow resource sharing and / or interworking between the first virtual enterprise cloud and the second virtual enterprise cloud, and the management platform prohibits resources between the first project and the second project Sharing and / or interworking.
  • the management platform may determine whether two VECs are allowed to communicate with each other according to the recorded alliance relationship between the VECs, which can meet the requirements of inter-cloud interconnection in the enterprise.
  • the management system when the first VEC and the second VEC are in a non-union relationship, when the tenant in the first VEC requests the resources of the second VEC for interconnection, the management system will directly block the first tenant's Resource interconnection between a project and the second project of the second tenant.
  • the management platform may Approve according to the recorded alliance relationship between VECs to determine whether to allow resource interconnection between the first project of the first tenant and the second project of the second tenant (if the relationship between VEC1 and VEC2 is non-alliance, Then the management system prohibits resource interconnection between the first project of the first tenant and the second project of the second tenant).
  • the management system when the first VEC and the second VEC are in an alliance relationship, when the tenants in the first VEC request resources of the second VEC to be interconnected, the management system will allow the tenants in the first VEC to report to the second VEC.
  • Two VEC resource interconnection requests For example, if resource interconnection is requested between VEC1 and VEC2, since the alliance relationship between VEC1 and VEC2 is an established alliance relationship, the management system will treat the tenants in the first VEC as the existing first tenant and second tenant in the bottom The resource sharing and / or interworking processing flow of corresponding services between the two allows the resource sharing and / or interworking between the first project of the first tenant and the second project of the second tenant.
  • the enterprise tenant creates a VEC, which can ensure that the enterprise can still perform access control on resources according to the importance or sensitivity of the information. It can achieve that all departments and employees of the enterprise can freely allocate and use the resources of each VEC, and can also achieve that resources and information do not flow across VEC, thereby avoiding problems such as information leakage.
  • a management platform in a second aspect, includes:
  • a processing module configured to create multiple virtual enterprise clouds that are based on the construction and are used to provide cloud resources
  • the processing module performs the following operations through the receiving module: adding a tenant to at least one virtual enterprise cloud according to the first instruction, the at least one virtual enterprise cloud being a department or all of the plurality of virtual enterprise clouds.
  • the processing module is specifically configured to:
  • Adding at least one item of the tenant to the at least one virtual enterprise cloud and each item includes cloud resources that the tenant is allowed to access in the virtual enterprise cloud to which each item belongs.
  • the processing module is further configured to:
  • the access right of the tenant in the at least one project is configured, so that the tenant has the ability to manage cloud resources included in each project.
  • the receiving module is further configured to receive a second instruction, where the second instruction instructs to set a security rule between the multiple virtual enterprise clouds, so The security rule is used to indicate whether the cloud resources of the multiple virtual enterprise clouds can be shared and / or communicated between the multiple virtual enterprise clouds;
  • the processing module is further configured to record the security rule.
  • the receiving module is further configured to receive a first request, where the first request is used for a first item of a first tenant to a second of a second tenant Project initiation resource sharing and / or interworking, wherein the first project belongs to a first virtual enterprise cloud and the second project belongs to a second virtual enterprise cloud;
  • the processing module is further configured to determine whether to allow resource sharing and / or interworking between the first project and the second project according to the recorded security rules.
  • the processing module is specifically configured to:
  • security rules allow resource sharing and / or interworking between the first virtual enterprise cloud and the second virtual enterprise cloud, resource sharing according to corresponding services between the first tenant and the second tenant And / or an interworking process, allowing resource sharing and / or interworking between the first project and the second project;
  • a management platform includes at least one computing device, and each computing device 1110 may include a processor, a memory, and a communication interface.
  • the memory can be used to store program code and data of the management platform. Therefore, the memory may be a storage unit inside the processor, or an external storage unit independent of the processor, or a component including a storage unit inside the processor and an external storage unit independent of the processor.
  • the memory may include volatile memory (such as random access memory (RAM); the memory may also include non-volatile memory (non-volatile memory), such as read-only memory (read-only memory) (ROM), flash memory (flash memory), hard disk (HDD) or solid-state drive (SSD); the memory may also include a combination of the above types of memory.
  • volatile memory such as random access memory (RAM)
  • non-volatile memory such as read-only memory (read-only memory) (ROM), flash memory (flash memory), hard disk (HDD) or solid-state drive (SSD); the memory may also include a combination of the above types of memory.
  • the memory may be used to store a set of program code, so that the processor invokes the program code stored in the memory to implement the functions of the receiving module and / or the processing module involved in the embodiment of the present invention.
  • the processor may be composed of one or more general-purpose processors, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), and an application-specific integrated circuit (application-specific integrated circuit (ASIC), field programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logical blocks, modules, and circuits described in connection with the present disclosure.
  • the processor may also be a combination that implements computing functions, such as a combination of multiple microprocessors, a combination of a DSP and a microprocessor, and so on.
  • a processor can be used to run programs that handle processing functions in the associated program code. That is, the processor executes the program code to implement the functions of the processing module. For details about the processing module, refer to the related description in the foregoing second aspect.
  • processor may also be a set of processors including at least one computing device, which is not specifically limited in this application.
  • the processors of the at least one computing device are commonly used to run related program code, so as to implement the functions of the foregoing processing modules in this application.
  • processor of each computing device may be individually used to run related program code to implement the functions of the foregoing processing modules in this application.
  • the communication interface may be a wired interface (such as an Ethernet interface) or a wireless interface (such as a cellular network interface or using a wireless local area network interface) for communicating with other modules / devices.
  • a wired interface such as an Ethernet interface
  • a wireless interface such as a cellular network interface or using a wireless local area network interface
  • the communication interface in the embodiment of the present application may be specifically used to receive instruction data and the like sent by an enterprise tenant or a tenant.
  • the processor is configured to call and run the computer program from the memory, so that the management platform executes the method described in the first aspect or any possible implementation manner of the first aspect.
  • the processor When the program is executed, the processor is configured to: create multiple virtual enterprise clouds that are based on the construction and are used to provide cloud resources;
  • the processor performs the following operations through the communication interface: adding a tenant to at least one virtual enterprise cloud according to the first instruction, the at least one virtual enterprise cloud being a department or all of the plurality of virtual enterprise clouds.
  • the processor is specifically configured to:
  • Adding at least one item of the tenant to the at least one virtual enterprise cloud and each item includes cloud resources that the tenant is allowed to access in the virtual enterprise cloud to which each item belongs.
  • the processor is further configured to:
  • the access right of the tenant in the at least one project is configured, so that the tenant has the ability to manage cloud resources included in each project.
  • the communication interface is further configured to: receive a second instruction, the second instruction instructing to set a security rule between the multiple virtual enterprise clouds, and The security rule is used to indicate whether the cloud resources of the multiple virtual enterprise clouds can be shared and / or communicated between the multiple virtual enterprise clouds;
  • the processor is further configured to record the security rule.
  • the communication interface is further configured to receive a first request, where the first request is used for a first item of a first tenant to a second of a second tenant Project initiation resource sharing and / or interworking, wherein the first project belongs to a first virtual enterprise cloud and the second project belongs to a second virtual enterprise cloud;
  • the processor is further configured to determine whether to allow resource sharing and / or interworking between the first project and the second project according to the recorded security rules.
  • the processor is specifically configured to:
  • security rules allow resource sharing and / or interworking between the first virtual enterprise cloud and the second virtual enterprise cloud, resource sharing according to corresponding services between the first tenant and the second tenant And / or an interworking process, allowing resource sharing and / or interworking between the first project and the second project;
  • a computer-readable medium stores program code, and when the computer program code runs on a computer, the computer causes the computer to execute the methods in the foregoing aspects.
  • the medium is non-transient.
  • a chip including a memory, a processor, and a transceiver.
  • the memory is used to store a computer program
  • the processor may be communicatively connected with the transceiver.
  • the memory may be used to store program code and data of the terminal device. Therefore, the memory may be a storage unit inside the processor, or an external storage unit that is independent of the processor, and may also be a component including a storage unit inside the processor and an external storage unit that is independent of the processor.
  • the processor may be a general-purpose processor, and may be implemented by hardware or software.
  • the processor may be a logic circuit, an integrated circuit, etc .; when implemented by software, the processor may be a general-purpose processor, realized by reading software codes stored in a memory, so The memory may be integrated in the processor, may be located outside the processor, and exist independently.
  • the processor is configured to call and run the computer program from the memory, so that the management platform executes the method described in the first aspect or any possible implementation manner of the first aspect.
  • a computer program product includes: computer program code that, when the computer program code runs on a computer, causes the computer to execute the methods in the above aspects.
  • FIG. 1 is a schematic diagram of a system architecture applicable to an embodiment of the present application.
  • FIG. 2 is a method for creating an enterprise cloud according to an embodiment of the present application.
  • FIG. 3 is a schematic flowchart of a possible implementation manner of step 210 in FIG. 2.
  • FIG. 4 is a schematic flowchart of a possible implementation manner of step 220 in FIG. 2.
  • FIG. 5 is a schematic structural diagram of a created VEC model provided by an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a VEC model created by a project according to an embodiment of the present application.
  • FIG. 7 is a schematic flowchart of a tenant complying with a security policy according to an embodiment of the present application.
  • FIG. 8 is a schematic flowchart of a tenant complying with a security policy according to another embodiment of the present application.
  • FIG. 9 is a schematic flowchart of a tenant complying with a security policy according to another embodiment of the present application.
  • FIG. 10 is a schematic block diagram of a management platform 1000 according to an embodiment of the present application.
  • FIG. 11 is a schematic block diagram of a management platform 1100 according to an embodiment of the present application.
  • Cloud services are basic public facilities like tap water and electricity. They pursue cost performance and reliability, and provide better services with less management software and hardware costs. But for enterprises, after the electronic information networking, information security becomes more important.
  • an access policy can be used to set whether different people in the enterprise have the authority to use and view certain specific resources.
  • the method for creating an enterprise cloud provided in the embodiments of the present application can set different security levels according to the importance, sensitivity, and security of enterprise information to ensure information security in the enterprise. At the same time, departments within the enterprise and even ordinary employees can have high resource control and flexible use of resources.
  • FIG. 1 is a schematic diagram of a system architecture applicable to an embodiment of the present application.
  • the system architecture may include a management system 110, an enterprise tenant (ET) 120, a tenant 130, a user interface (UI) 140, and an application programming interface gateway (application programming interface).
  • EN enterprise tenant
  • UI user interface
  • API-GW application programming interface gateway
  • VEC virtual enterprise cloud
  • network services 122 computing services 124
  • storage services 126 storage services 128.
  • the management system 110 may be a centralized control software system or a multi-module multi-service system divided according to service attributes or other factors.
  • the management system 110 may be used to build a model of a virtual enterprise cloud VEC and its security policy based on cloud services (for example, VEC160 and VEC170 created in FIG. 1).
  • a cloud service may be a data center used by an enterprise to obtain required services in an on-demand and easily expandable manner through a network.
  • Cloud services provided by a cloud service provider may include, but are not limited to, network services 122, computing services 124, storage services 126, other services 128, and the like. Enterprises do not need to configure the required hosts, network equipment, storage, applications, etc. Cloud service providers can provide enterprises with corresponding network, computing, storage and other resources through the network.
  • Enterprise tenants 120 and tenants 130 can obtain one or more of the above cloud services (for example, the network) through the network (for example, the user interface UI 140 of the cloud service or the application programming interface gateway API-GW150).
  • Service 122, computing service 124, storage service 126, other services 128, etc. this application does not specifically limit this.
  • the management system 110 may further include an identification and access management (IAM) module.
  • IAM identification and access management
  • the IAM module can provide identity authentication and authority function management for VEC160 and VEC170. It can manage user (for example, employees, systems, or applications) accounts, and can implement authorization and grant of tenants, resources, and operations.
  • an enterprise tenant creates a VEC and specifies a policy for resource interconnection and interoperability between VECs.
  • a series of permissions can be set through the IAM module in the management system 110.
  • the permissions may include, but are not limited to, the tenant's permissions, Permissions in various regions, permissions of tenants and tenants in the organization, permissions to cloud services, operation permissions, etc.
  • the management system 110 may include an IAM module and a security management module of the IAM.
  • the IAM module can save the original identity and access management functions
  • the IAM security management module can be understood as a module specifically for enterprise tenants' IAM modules for security management. For example, when it is confirmed as an enterprise tenant, it can check the permission policy of the security management module of the IAM. In other words, when entering from the IAM module, it is actually necessary to accept the dual authority check of the IAM module and the IAM security management module.
  • the management system 110 may only include: an IAM module, and the IAM module itself may integrate the function of the VEC security policy, that is, the IAM module and the security management module of the IAM may be combined into one module.
  • FIG. 2 is a method for creating an enterprise cloud according to an embodiment of the present application.
  • the method shown in FIG. 2 may include steps 210-220. Steps 210-220 are described in detail below.
  • Step 210 The management platform creates multiple virtual enterprise clouds based on the cloud service.
  • the management platform in the embodiment of the present application may correspond to the management system 110 shown in FIG. 1.
  • the management platform may receive a first instruction sent by an enterprise tenant, and the first instruction may be used to request the management platform to create multiple virtual enterprise clouds on the underlying cloud service.
  • the embodiments of the present application may store information in different security zones according to the security level or business relevance of the information.
  • the virtual enterprise cloud VEC can be understood as the above security zone.
  • An enterprise organization can be divided into a security zone and can be divided into multiple security zones.
  • Each virtual enterprise cloud VEC provides different cloud resource services for users or tenants in the VEC.
  • the cloud resource services may include, but are not limited to, network services, computing services, storage services, and the like.
  • an enterprise tenant (also referred to as an “enterprise root tenant”) may refer to a registered tenant account in the field of cloud computing. This tenant account has the right to use all the cloud services provided and may have the authority to manage all resources in the tenant. .
  • the enterprise root tenant can be the embodiment of the service resource container carrier and ownership owned by the user, and the cloud operator can charge a fee through the financial account associated with the account.
  • an enterprise tenant may serve as a cloud operation administrator of a virtual enterprise cloud, and may create a virtual enterprise cloud.
  • Management rights for enterprise tenants can include, but are not limited to: building an organizational structure within the enterprise (e.g., the company divides different departments according to different business types), creating a VEC, setting a list of services available and / or disabled in the VEC, and formulating Inter-connectivity strategies, formulate inter-connectivity strategies with external VECs (eg, ordinary tenants, VECs of other enterprises), implement corporate budget systems, and settle and / or analyze corporate expenses.
  • the management rights of the enterprise tenant will be described in detail below with reference to FIGS. 3-5, and will not be repeated here.
  • the management platform can create a virtual enterprise cloud VEC object on the underlying cloud service according to the instructions sent by the enterprise tenant, and can save the record.
  • the management platform can save and record security rules between multiple virtual enterprise cloud VECs in multiple virtual enterprise cloud VECs created on the underlying cloud service according to the instructions of the enterprise tenant, the association relationship between the created accounts, Online services available to tenants added to VEC, billing models available to tenants added to VEC, resource quotas available to tenants added to VEC, and more.
  • Step 220 The management platform receives a first instruction and adds a tenant to at least one virtual enterprise cloud according to the first instruction.
  • the management platform may add the tenant to at least one virtual enterprise cloud VEC, and the embodiment of the present application does not limit the specific implementation manner of the tenant to the at least one VEC.
  • a tenant may apply to join the VEC.
  • a tenant may apply for at least one VEC that needs to be accessed and used, and an enterprise tenant may review whether the tenant can join the applied VEC.
  • an enterprise tenant may also invite the tenant to join at least one VEC.
  • the enterprise tenant may specify at least one VEC that the tenant can access and use, and the management system may add the tenant to the corresponding at least one VEC.
  • a tenant may be added to a partially or fully created VEC.
  • a tenant can be added to one of the multiple VECs created.
  • a tenant can also be added to at least two of the VECs created.
  • you can also add all tenants to the created VEC. This application does not specifically limit this.
  • tenant added to the VEC is not specifically limited in the embodiment of the present application.
  • a tenant added to VEC represents a specific employee in the enterprise.
  • tenants added to VEC represent a certain department.
  • a departmental tenant is added to at least one VEC as an example, and the foregoing two specific implementation manners are described in detail with reference to FIG. 4, and details are not described herein again.
  • an enterprise tenant when adding a tenant, may also specify a quota, a charging mode, etc. for the use of tenant resources, or dynamically adjust it.
  • the quota of tenants in the virtual enterprise cloud is not greater than the quota specified for the tenant, and the sum of quotas of the same tenant in multiple virtual enterprise clouds does not exceed the quota specified by the underlying cloud service for the tenant.
  • Tenants added to at least one VEC can have tenant characteristics, that is, tenants added to VEC can fully control the various infrastructure as a service (IaaS) resources specified by the enterprise tenant, Platform-as-a-service (PaaS) resources, software-as-a-service (SaaS) resources.
  • IaaS infrastructure as a service
  • PaaS Platform-as-a-service
  • SaaS software-as-a-service
  • the tenants added to at least one created VEC have the same permissions as ordinary tenants except for the following permissions: they cannot change the relationship between the tenant itself and the virtual enterprise cloud, they cannot increase access to services prohibited by the enterprise tenant, they cannot be changed Enterprise tenant-specified billing packages, quota budgets, and other rules set by corporate tenants.
  • the rights of a tenant added to at least one created VEC may include, but are not limited to: the tenant is not authorized to change the permission rules set by the enterprise tenant, the tenant is not authorized to access unauthorized VEC, the tenant is not authorized to access unauthorized services, the tenant may The permissions of all non-prohibited tenants in the VEC, and the tenants need to abide by the security rules set by the corporate tenants (e.g., the interconnection policies formulated by the corporate tenants and external to the VEC (e.g., ordinary tenants, VECs created by other corporate tenants) .
  • the following describes the management rights of tenants in detail by adding departmental tenants to at least one of the created VECs as an example in conjunction with FIGS. 3-5, and is not repeated here.
  • the tenant added to the VEC represents a certain department (that is, it can be a department tenant)
  • the tenant can serve as a department administrator, and can be used for users and sub-users under it.
  • Departments perform authority setting and management.
  • department tenants can create users, manage users, set the user's permissions in the virtual enterprise cloud, and set other security rules.
  • an enterprise tenant creates multiple VECs, and the multiple VECs are independent of each other, and services within the VEC are controllable. It can enable enterprises to have their own independent, complete, secure, compliant, service-controllable, and maintenance-free virtual enterprise cloud, while enjoying on-demand purchase and elastic scalability. Different security levels can be set according to the importance, sensitivity, and security of enterprise information to ensure enterprises. At the same time, departments within the enterprise and even ordinary employees can have a higher ability to control resources and use resources flexibly.
  • an enterprise tenant ET may have multiple organizations within the enterprise, the organization may specify the affiliation (hierarchical relationship) between departments, and the department tenant may set permissions for its subordinate users and sub-departments And management.
  • the multiple VECs created may be used by multiple tenants in the organization (an organization may include multiple tenants, for example, may include multiple department tenants). Therefore, when the ET sends a request to the UI to create a VEC, , You need to specify the Organization-identity (Org-ID).
  • the virtual enterprise cloud VEC created on the cloud service in the embodiment of the present application is defined as a cloud, and the clouds are independent and not interconnected. Therefore, by default, resources between VECs cannot be communicated and shared.
  • the federation Resources can be shared or interconnected between the clouds.
  • the enterprise tenant (as the enterprise administrator) may have the ability to set the interconnection and interworking strategy between VECs.
  • the Alliance VEC Federal Cloud
  • the Alliance VEC can share resources under the authorization of enterprise tenants and the cloud platform is capable, but the system default resources of the Alliance VEC are not forbidden from interworking.
  • VECs that establish a federal cloud may be the same enterprise tenant or cross-enterprise tenants, which are not specifically limited in this application.
  • VEC1 and VEC2 are cloud alliances (resources can be interconnected and / or shared between VEC1 and VEC2)
  • VEC2 and VEC3 are cloud alliances (resources can be interconnected and / or shared between VEC2 and VEC3)
  • VEC1 It does not belong to the cloud alliance with VEC3 (that is, resources between VEC1 and VEC3 can be interconnected and / or shared). If the resources between VEC1 and VEC3 need to be communicated and / or shared, an alliance relationship needs to be established between VEC1 and VEC3.
  • an enterprise tenant (as an enterprise administrator) sets two VECs as a federal cloud (that is, resources between the two VECs can be interconnected)
  • the management system allows the resources between the corresponding two VECs to be performed. Interconnect or interoperate, and handle in accordance with the normal process of resource sharing and / or interworking of corresponding services within the tenant or between tenants on the cloud service.
  • an enterprise tenant (as an enterprise administrator) does not set up an alliance relationship between two VECs, it can be assumed that the VECs are independent from each other, that is, the resources between the VECs cannot be interconnected.
  • the enterprise tenant ET can not only set the alliance relationship between the resources created by the VECs, but also the interconnections between the VECs in the enterprise and other enterprise VECs and external ordinary tenants.
  • whether the resources of the two tenants in the federal cloud can be shared and / or interoperable depends on whether the target tenant agrees to the resource sharing and / or interoperable. As an example, if a tenant shares resources to everyone, other tenants in the federal cloud can share it, otherwise only the specified tenant can share resources.
  • VEC interconnection and interworking alliance strategy in the embodiment of the present application (resources between different VECs created by the same enterprise tenant cannot be shared and shared, and resources between VECs created by different enterprise tenants cannot be shared and shared, The resources between the VEC and external non-enterprise VEC (the rest other than the VEC) cannot be interconnected or shared).
  • Enterprise tenants can set the interconnection and interworking alliance strategy for any VEC created according to the business needs of the enterprise.
  • the embodiments of this application do not specifically limit the VECs that can be allianced.
  • the enterprise tenant (as the enterprise administrator) may also set some other more detailed security rules based on the interconnection and interworking strategy between VECs.
  • an enterprise tenant may set that only network service resources can communicate between the interconnected VECs.
  • an enterprise tenant can set interconnected VECs to specify that only resources can be communicated and accessed, which is not specifically limited in this application.
  • an enterprise tenant after an enterprise tenant creates multiple virtual enterprise clouds on the underlying cloud service, it can also open services for the virtual enterprise cloud, allowing tenants to use which services on the virtual enterprise cloud, and available billing.
  • Information required for operating the multiple virtual enterprise clouds such as modes, default tenant resource quotas, and regions where VEC is in effect.
  • the region is selected based on the region where the underlying cloud service is activated. After the selection, other tenants who join the virtual enterprise cloud can only select the region specified by the enterprise tenant to use the cloud service. Regions can be dynamically increased. When deleting regions, all resources in the VEC must be released.
  • FIG. 3 is only for helping those skilled in the art to understand the embodiments of the present application, and is not intended to limit the application embodiments to the specific numerical values or specific scenarios shown. Those skilled in the art can obviously make various equivalent modifications or changes according to the example shown in FIG. 3, and such modifications and changes also fall within the scope of the embodiments of the present application.
  • FIG. 3 is a schematic flowchart of a possible implementation manner of step 210 in FIG. 2.
  • the method in FIG. 3 may include steps 310-370. Steps 310-370 are described in detail below.
  • management system shown in FIG. 3 may correspond to the above management platform (ie, correspond to the management system 110 in FIG. 1).
  • step 310 the enterprise tenant ET sends a request to create a virtual enterprise cloud VEC to a user interface (UI).
  • UI user interface
  • ET can create multiple VECs, and ET can send a VEC creation request to the UI.
  • step 315 the UI sends a create VEC request (create VEC) to the management system.
  • the UI can send a request to create a VEC from the ET to the management system.
  • step 320 the management system saves VEC information.
  • the management system can save VEC information after receiving the VEC creation request sent by the UI.
  • step 325 the ET sends a request for adding a VEC area to the UI.
  • the ET may add a region to the VEC.
  • a region may be a division of a VEC resource in a region, and a user may access nearby.
  • a VEC may be divided into regions such as South China and North China.
  • VEC may or may not span regions. As an example, if VEC does not span a region, VEC is valid only within that region.
  • step 330 the UI sends an add VEC region request (add VEC (VEC-ID, region)) to the management system.
  • add VEC VEC-ID, region
  • the UI can send the request to the management system after receiving the request to add the VEC area sent by the ET. Since multiple VEC information is stored in the management system, the UI can specify the VEC-ID when sending the add region VEC to the management system.
  • step 335 the management system adds a regional account (create region account).
  • the management system may add a local tenant account (also referred to as a local sub-account) of the tenant in the region.
  • the added local tenant account can be the associated account of the tenant in the specified region, and has nothing to do with other regions.
  • each region added in the VEC in the embodiment of the present application may have multiple local tenant accounts, but the multiple local tenant accounts belong to one global account.
  • the management system can create a project in a cloud platform (Open Stack), and the mapping relationship between the region and the local tenant account can be achieved through the created project.
  • Open Stack cloud platform
  • the specific implementation of creating VECs and local tenant accounts based on existing projects and domains in OpenStack will be described in detail with reference to FIG. 6, and will not be repeated here.
  • OpenStack can be a cloud computing management platform that can uniformly manage the computing, storage, and network resources of a data center.
  • step 340 the management system saves the association mapping relationship between VEC and region and their local accounts.
  • VEC-1 may include region-1, region-2, and the like, and region-1 may have a local tenant account-1, a local tenant account-2, and the like.
  • step 345 the ET sends a service-list request for setting an enterprise cloud available service to the UI.
  • the ET can specify a list of services available and / or a list of disabled services for each VEC in each region.
  • ET as an administrator can specify a list of services that tenants on VEC-1 can use.
  • the services available to tenants on VEC-1 are: elastic server (ECS), virtual private cloud (VPC), IP multimedia system (IMS), and relational database services. (relational database service, RDS), etc.
  • Tenants on VEC-1 can have the right to create, destroy, change, or otherwise dispose of resources within the authorized services.
  • ET as an administrator can specify a list of services that VEC-1's tenants are prohibited from using.
  • the services that VEC-1's tenants are prohibited from using are: enterprise information portal (EIP), object storage services (object storage service, OBS) and so on.
  • EIP enterprise information portal
  • OBS object storage services
  • Tenants on VEC-1 do not have permission to create, destroy, change, or otherwise dispose of resources within the services that the tenants are prohibited from using.
  • step 350 the UI sends a set VEC service list request (set VEC service-list (VEC-ID, region, service-list)) to the management system.
  • set VEC service-list VEC-ID, region, service-list
  • the UI may send the request to the management system after receiving the request for setting the enterprise cloud available service list sent by the ET, and the request may include setting an available service list and / or a disabled service list in each region for each VEC .
  • step 355 the management system stores a list of services available for each VEC in each region.
  • the management system can list the service list available and / or disabled for each VEC in each region, so as to facilitate the identification and authorization of tenants, resources, and operations. Granted.
  • the ET as an administrator also needs to specify certain characteristics of the services that the tenant can access.
  • step 360 the ET sends a VEC alliance request (trust-VEC-list) to the UI.
  • the VEC created by ET is defined as a cloud.
  • clouds cannot directly communicate with each other, nor can they directly share and use non-network resources such as mirroring.
  • the ET as an administrator can set a relationship between VECs that can interconnect and interoperate (VEC alliance).
  • VEC alliance a relationship between VECs that can interconnect and interoperate
  • the resources between the VECs that set the alliance can be directly interconnected with the authorization of the enterprise tenant and the cloud platform has the capability, and the resources between the VECs that are not the alliance cannot be accessed by default.
  • Enterprise tenants can set the interconnection and interworking alliance strategy for any VEC created according to the business needs of the enterprise.
  • the embodiments of this application do not specifically limit the VECs that can be allianced.
  • the following shows a possible alliance relationship between VECs designated by the ET in the embodiments of the present application, as shown in Table 1.
  • VEC1 and VEC2 can be understood as the two virtual enterprise clouds created by ET through the UI.
  • False can indicate non-union relationship, that is, when the alliance relationship of a certain row and column is False, when the tenant requests the resources of the row and the column to be interconnected, the management system will directly block the corresponding row and Resource interconnection requests for columns.
  • the management system will directly block the first tenant in VEC1. The resource and the second tenant request for interconnection and interworking between the resources in VEC2.
  • the management platform may The alliance relationship between them shall be approved to determine whether the first tenant is allowed to communicate with the resources in VEC1 and the second tenant is in the resources in VEC2. (If the relationship between VEC1 and VEC2 is not a union, the management system Interconnection between the resources of the first tenant in VEC1 and the resources of the second tenant in VEC2 is prohibited).
  • True can indicate an alliance relationship, that is, when the alliance relationship of a certain row and column is True, when the tenant requests the resources of the row and the column to be interconnected, the management system can request the resource interconnection of the corresponding row and column according to the tenant.
  • the resource sharing or interworking process between corresponding services is performed (the management system allows its corresponding row and column resource interconnection requests).
  • the management system can use the Existing normal processes of resource sharing or interworking of corresponding services of the first tenant and the second tenant can be processed, which can allow the first tenant to communicate with the resources in VEC1 and the resources of the second tenant in VEC2.
  • the alliance relationship between VECs shown in Table 1 is taken as an example, that is, the system in Table 1 defaults to the same VEC can be interconnected (for example, the alliance relationship between VEC1 and VEC1 is True, The alliance relationship between VEC2 and VEC2 is True).
  • the setting values shown in Table 1 are default values. As an administrator, ET can modify the default values in Table 1 according to the actual needs of the enterprise.
  • Step 365 The UI sends a VEC alliance request (trust-VEC-list) to the management system.
  • Step 370 The management system saves the VEC alliance relationship.
  • Step 375 The ET sends a request for setting other security rules to the UI.
  • the ET as an administrator can further set the security rules in detail.
  • the ET may send a security rule to the UI to set only network interoperability.
  • the ET may also send to the UI a security rule that sets only specified resources to be accessible.
  • ET can be set according to the organizational structure of the enterprise and the information security level, which is not specifically limited in the embodiments of the present application.
  • Step 380 The UI sends a request for setting other security rules (set VEC security policy (VEC-ID, policy-list)) to the management system.
  • set VEC security policy VEC-ID, policy-list
  • the UI may send a request for setting other security rules to the management system.
  • the request needs to specify a VEC-ID, that is, the UI needs to request a management system for which VEC to set other security rules (security policy).
  • an enterprise tenant creates multiple VECs, and the multiple VECs are independent of each other, and services within the VEC are controllable. It enables enterprises to have their own independent, complete, service-controllable, security-compliant, and maintenance-free virtual enterprise cloud. Different security levels can be set according to the importance, sensitivity, and security of enterprise information, which can ensure that enterprises can still control access to resources based on the importance or sensitivity of the information. At the same time, departments within the enterprise and even ordinary employees can have a higher ability to control resources and use resources flexibly.
  • the tenant may join the created multiple VECs.
  • FIG. 4 describes two specific implementations of adding a department tenant (DT) to a VEC by taking a tenant joining the VEC as a department tenant as an example with reference to FIG. 4.
  • DT department tenant
  • FIG. 4 is only for helping those skilled in the art to understand the embodiments of the present application, and is not intended to limit the embodiments of the application to the specific values or specific scenarios shown.
  • Those skilled in the art can obviously make various equivalent modifications or changes according to the example shown in FIG. 4, and such modifications and changes also fall within the scope of the embodiments of the present application.
  • FIG. 4 is a schematic flowchart of a possible implementation manner of step 220 in FIG. 2.
  • the method in FIG. 4 may include steps 410-445. Steps 410-445 are described in detail below.
  • management system shown in FIG. 4 may correspond to the above management platform (ie, correspond to the management system 110 in FIG. 1).
  • the departmental tenant DT can select the VECs to be accessed and used.
  • the DT can select the VECs to be accessed and used.
  • the ET may specify the VECs that the DT needs to access and use. The two implementations are described below in conjunction with steps 410-415.
  • step 410 the DT sends a selected VEC request (VEC-list) to the UI.
  • Case 1 The DT can send the ET that needs to be accessed or used as the VEC or VEC list created by the administrator to the UI.
  • step 415 the ET sends a VEC request (VEC-list) specifying that the DT is available to the UI.
  • VEC request VEC-list
  • step 420 the UI sends a VEC request (attach department (VEC-list)) for adding the DT to the management system.
  • VEC request attach department (VEC-list)
  • the UI may send the VEC list to the management system after receiving the VEC or VEC list that the DT allows or needs to access sent by the DT or ET.
  • Step 425 The management system records a list of VECs available to the DT.
  • the management system can record the VEC list available for DT.
  • the management system can record the list of VECs available to the DT, if the DT wants to access resources in a certain VEC, the management system can determine whether the DT has the right to access the DT that it wants to access based on the saved VEC list available to the DT. VEC. If the DT does not have permission to access the VEC that it wants to access, the management system can block the request to obtain resources in the VEC. It can realize that information and resources do not flow across VEC, so that the problem of information leakage can be avoided.
  • Step 430 The management system finds that the added DT owns an existing resource.
  • the management system may check whether the added DT has existing resources. If the management system finds that the added DT owns an existing resource and the existing resource does not belong to the VEC created by any ET, the DT can migrate the existing resource to the created VEC.
  • Step 435 The DT sends a request to the UI to migrate the existing resource to a VEC (VEC-ID, region-account).
  • the DT can send a request to the UI to migrate the existing resources to the VEC.
  • the DT may migrate existing resources to a specified VEC in units of a tenant's local account in the region (region-account).
  • the local account can be as described above, which can be achieved by creating a project in Open Stack.
  • Step 440 The UI sends a move to VEC request (migrate to VEC (VEC-ID, region-account)) to the management system.
  • VEC request migrate to VEC (VEC-ID, region-account)
  • the UI can send the request to the management system after receiving the request that the existing resource sent by the DT is migrated to the VEC.
  • the request may include a virtual enterprise cloud ID (VEC-ID) and a local account (region-account) within the region.
  • VEC-ID virtual enterprise cloud ID
  • region-account local account
  • Step 445 The association relationship between the local account and the VEC in the management system recording area.
  • the management system can save the association between the local account in the area and the VEC after migrating the existing resources to the designated virtual enterprise (VEC-ID) by receiving the local account in the area from the UI.
  • VEC-ID designated virtual enterprise
  • an enterprise tenant can create a VEC, and can divide different communication domains according to the organizational structure of the enterprise and its information security level. It can ensure that enterprises can control access to resources based on the importance or sensitivity of the information. It can be achieved that all departments and employees of the enterprise can freely allocate and use resources in each VEC, and can also achieve that resources and information do not flow across VEC, thereby avoiding problems such as information leakage.
  • FIG. 5 is only for helping those skilled in the art to understand the embodiments of the present application, and is not intended to limit the embodiments of the application to the specific values or specific scenarios shown. Those skilled in the art can obviously make various equivalent modifications or changes according to the example shown in FIG. 5, and such modifications and changes also fall within the scope of the embodiments of the present application.
  • FIG. 5 is a schematic structural diagram of a created VEC model provided by an embodiment of the present application.
  • an enterprise tenant ET may include, but is not limited to, creating a VEC, setting a list of services available and / or disabled within the VEC, formulating a strategy for interconnection and interworking between VECs, and establishing an external connection with VEC. (For example, ordinary tenants, VECs of other enterprises), interconnection and interworking strategies, implementation of corporate budget system, settlement and / or analysis of corporate expenses.
  • the authority of the enterprise tenant ET will be described one by one with reference to FIG. 5.
  • an enterprise tenant ET may apply to create multiple VECs on the underlying cloud service, such as yellow cloud, green cloud, and blue cloud.
  • Security domains can be forcibly divided according to information levels (or other purposes), so that information and resources do not flow across VCEs.
  • the enterprise tenant ET may specify the VECs that the tenant needs to use and access.
  • VECs that the tenant needs to use and access.
  • corporate tenants, tenants 1, and tenants 2 can access and use services and resources in Huangyun, and can freely create, destroy, change, or otherwise dispose of resources on Huangyun.
  • Tenant 3 does not have permission to access and use services and resources in Huangyun.
  • an enterprise tenant may add a department to a plurality of VECs (eg, yellow cloud, green cloud, blue cloud) created.
  • VECs eg, yellow cloud, green cloud, blue cloud
  • tenant 1 can be added to all created VECs (for example, yellow cloud, green cloud, and blue cloud)
  • tenant 3 can be added to the created department VECs (for example, green cloud and blue cloud).
  • the enterprise tenant ET may also set a service list and / or a disabled service list that the tenant on the VEC can use.
  • the list of available services on the yellow cloud is: ECS, VPC, IMS, RDS, and the list of disabled services is: EIP, OBS.
  • Enterprise tenants, Tenants 1, and Tenants 2 who can access and use Huangyun can only access and use the list of available services on Huangyun, and are not authorized to access and use the list of disabled services on Huangyun.
  • the enterprise tenant ET can formulate a resource authorization method with the tenant as the control unit on different virtual enterprise cloud VECs according to the actual situation of different enterprises, which can be budget quotas, self-service on demand, etc. (based on the underlying cloud Existing formulations are based on tenant settlement capabilities).
  • the enterprise tenant ET may also set an interconnection and interworking strategy between VECs.
  • the enterprise tenant ET may set an interconnection relationship between each VEC and an external ordinary tenant (for example, a PC in FIG. 5).
  • the PC in FIG. 5 can be used as an ordinary tenant and is a department other than the VEC defined by the enterprise tenant ET.
  • a PC as an ordinary tenant can use all cloud services, but under unauthorized circumstances, it cannot access the resources of any enterprise (that is, the resources of the enterprise may include, but are not limited to, computing, storage, networking, etc.).
  • the tenant shown in Figure 5 can have similar permissions in the authorized VEC as ordinary tenants on cloud services.
  • Tenants added to VEC have the same permissions as ordinary tenants except for the following permissions: they cannot change the relationship between the tenant itself and the virtual enterprise cloud, they cannot increase access to services prohibited by the enterprise tenant, they cannot change the billing package specified by the enterprise tenant, and the quota budget, etc. Rules set by corporate tenants.
  • both the tenant and the user need to enforce compliance with the security policy set by the enterprise tenant ET. If the two resources requesting interworking belong to different VECs, and the enterprise tenant specifies isolation between VECs (that is, resources between different VECs are not allowed to be interconnected), even if the two resources belong to the same tenant, management The system also does not allow interconnection between these two resources.
  • isolation between VECs that is, resources between different VECs are not allowed to be interconnected
  • the tenant added to the VEC has the rights of the tenant, and the tenant may further set some additional security rules based on the rules set by the enterprise tenant (enterprise administrator).
  • the enterprise tenant enterprise administrator
  • the VEC can also be set to prohibit network interworking. The ordinary tenants and user accounts attached to it must comply with the security rule.
  • an enterprise tenant can formulate a security policy.
  • an enterprise tenant can create a virtual enterprise cloud and specify security policy rules.
  • the management system will apply the defined rules to the tenants added to the VEC, and the rules defined by the enterprise tenant will automatically take effect. This design is more in line with the top-down management of the enterprise and can grasp the overall appeal.
  • the tenant has the ability to fully manage the various cloud services and / or cloud resources allowed in the multiple virtual enterprise clouds, which can avoid that the enterprise tenant in the prior art is solely responsible for the resources and resources of all departments in the enterprise. Safety management.
  • a tenant on a cloud service may have multiple projects (projects in Open Stack).
  • the project can be a collection or container of resources, and it can also have permission authentication for these resources and the tenant (where the tenant can specify the resource interworking rules between the belonging project).
  • FIG. 6 is a schematic structural diagram of a VEC model created by a project according to an embodiment of the present application.
  • an enterprise tenant may have multiple projects (for example, project 1, project 2, and project 3).
  • Corresponding enterprises can have multiple VECs (for example, yellow cloud, green cloud, and blue cloud in the embodiments of the present application), which can be implemented through project 1 (project 1), project 2 (project 2), and project 3 (project 3) The VEC created in Figure 5.
  • a tenant can access multiple VEC resources, but the interconnection and interworking relationship between VECs can be customized by each enterprise based on its business and security level. As an example, referring to the tenant 3 in FIG. 6, the tenant 3 may have permission to access resources in the project 2 and project 3, but does not have permission to access resources in the project 1. Even if the resources between project 2 and project 3 belong to the same tenant, since project 2 and project 3 do not belong to the same VEC, the resources between project 2 and project 3 cannot be interconnected by default.
  • the interconnection relationship between VECs can be freely customized by enterprise tenants.
  • VEC can be implemented based on an existing project in Open Stack, and the implementation is simple. Enterprises, departments, and ordinary tenants of the enterprise can remain relatively independent, and can have independent and complete ability to use resources.
  • VEC can provide include, but are not limited to, three services: network domain, computing domain, and storage domain.
  • FIG. 7 is a schematic flowchart of a tenant complying with a security policy according to an embodiment of the present application.
  • the method in FIG. 7 may include steps 710-790. Steps 710-790 are described in detail below.
  • the department tenant DT1 and the department tenant DT2 need to initiate a peer-to-peer connection between the two VPCs through a network service.
  • management system shown in FIG. 7 may correspond to the above management platform (ie, correspond to the management system 110 in FIG. 1).
  • VPC1, VPC2 can belong to two different tenants in different VECs, or can belong to two different tenants in the same VEC.
  • DT1 is the tenant 1 in FIG. 6, and DT2 is the tenant 2 in FIG. 6.
  • VPC1 belongs to the network resource of tenant 1 in Huangyun project 1 shown in FIG. 6, and VPC2 belongs to the network resource of tenant 2 in Huangyun project 1 as an example for detailed description. That is, the tenant 1 requests that the network resources in the project 1 of Huangyun and the network resources of the tenant 2 in the project 1 of Huangyun be interconnected and / or communicated.
  • Step 710 DT1 sends a peer connection request (DT1, VPC1 @ VEC1, DT2, VPC2 @ VEC1) to create a peer connection between VPC1 and VPC2 to the user interface UI.
  • DT1 sends a peer connection request (DT1, VPC1 @ VEC1, DT2, VPC2 @ VEC1) to create a peer connection between VPC1 and VPC2 to the user interface UI.
  • DT1 can initiate a peer-to-peer connection between two designated VPCs (VPC1, VPC2) to the UI, or it can be understood that DT1 requests two designated VPC cloud resources from the UI (the project of tenant 1 in Huangyun and the project of tenant 2 in Huangyun Resources between Project 1).
  • Step 720 The UI sends a peer connection creation request (create VPC peering (DT1, VPC1, DT2, VPC2)) to the management system to the management system.
  • create VPC peering create VPC peering (DT1, VPC1, DT2, VPC2)
  • the UI may send the request to the management system after receiving the request for creating a peer connection between VPC and VPC2 sent by DT1.
  • Step 730 The management system searches for the VEC-IDs to which VPC1 and VPC2 belong.
  • the management system After receiving the request for creating a peer connection between VPC and VPC2 sent by the UI, the management system can find the VEC-IDs to which VPC1 and VPC2 belong. As an example, in the embodiment of the present application, VPC1 and VPC2 belong to the same VEC (the yellow cloud shown in FIG. 6).
  • the management system can determine whether VPC1 and VPC2 can communicate with each other according to the saved alliance relationship between VECs.
  • the alliance relationship between the VECs in the embodiment of the present application is: the same VEC is allowed to communicate with each other. Since VPC1 and VPC2 belong to the same VEC in the embodiment of the present application (the yellow cloud shown in FIG. 6), Therefore, in the embodiment of the present application, VPC1 and VPC2 can communicate with each other. That is, the resources of tenant 1 in project 1 and the resources of tenant 2 in project 1 can be interconnected and / or interoperable.
  • the management system can find the region where the VPC is located and the local account within the region according to the VPC-ID (for example, VPC1, VPC2), and the management system can find the corresponding VEC-ID (for example, according to the local account) , Yellow cloud shown in Figure 6).
  • VPC-ID for example, VPC1, VPC2
  • VEC-ID for example, according to the local account
  • VEC-ID may be a universally unique identifier (UUID), and it may be assumed that UUIDs are not duplicated.
  • the management system queries that the VECs belonging to VPC1 and VPC2 are empty. See Table 1.
  • the alliance relationship may correspond to VEC and ordinary tenant Interconnection strategy between PCs.
  • step 740 if the query result is that VPC1 and VPC2 allow interworking, the management system saves the peer-to-peer connection and sets the status to be accepted.
  • the management system can process according to the corresponding processes or methods in the existing tenant or between tenants of the underlying cloud service (as long as DT2 agrees, the peer-to-peer connection is successfully established).
  • the management system can save the peer-to-peer connection and can set the status of the peer-to-peer connection to be connected.
  • Step 750 DT2 sends a request to view the peer connection to the UI.
  • step 760 the UI sends a query peer connection request (VPC peering) to the operating system.
  • VPC peering a query peer connection request
  • Step 770 DT2 sends a request to the UI to agree to establish a peer-to-peer connection.
  • Step 780 The UI sends a peer connection establishment request (establish VPC peering (VPC1, VPC2)) to the operating system.
  • VPC1, VPC2 peer connection establishment request
  • the UI may send a request to the operating system to establish a peer-to-peer connection between VPC1 and VPC2 after receiving the request to establish a peer-to-peer connection from DT2.
  • Step 790 The operating system updates the status as connection establishment.
  • the operating system can update the status between VPC1 and VPC2 to connection establishment (the resource of tenant 1 in Huangyun's project 1 and The resources of tenant 2 in Huangyun's project 1 can be interconnected and / or interoperable).
  • FIG. 8 is a schematic flowchart of a tenant complying with a security policy according to another embodiment of the present application.
  • the method in FIG. 8 may include steps 810-855. Steps 810-855 are described in detail below.
  • management system shown in FIG. 8 may correspond to the above management platform (ie, correspond to the management system 110 in FIG. 1).
  • the department tenant DT1 and the department tenant DT2 need to create a virtual machine VM through a computing service.
  • DT1 and DT2 can belong to one VEC, or they can belong to different VECs.
  • DT1 is the tenant 1 in FIG. 6
  • DT2 is the tenant 2 in FIG. 6
  • the resource set of the tenant 1 in the yellow cloud is item 1
  • the resource set of the tenant 2 in the green cloud is item 2 as an example. .
  • the mirror resource shared by DT1 needs to be used. It can be understood that the tenant 2 in FIG. 6 wants to request the project 2 in the green cloud to share the tenant 1 in the project 1 in yellow cloud. Mirror resource.
  • Step 810 DT1 sends a request to the user interface UI to share the image to everyone.
  • VEC1 can share the mirror in VEC1 (such as the mirror resource of tenant 1 in Huangyun project 1 in Figure 6) to all users in VEC1 (as in Figure 6, tenant 1 can share Huangyun project 1)
  • the image resource in is shared with other tenants in Huangyun). All users in this VEC1 can use the shared image to create VMs.
  • Step 815 The UI sends a request to the management system to share the image to everyone.
  • the UI can forward the request to the management system after receiving the request from the DT1 for the shared image to everyone.
  • Step 820 The management system sets the image sharing to everyone.
  • the management department can share the image in VEC1 to all users in VEC1 after receiving the request from the UI for the image to everyone.
  • steps 825-840 are used to describe the specific implementation in case one in detail.
  • Step 825 DT2 sends a VM creation request to the UI.
  • Step 830 The UI sends a query image query query (query image (DT2, VEC1, region1)) to the management system.
  • query image query query query image (DT2, VEC1, region1)
  • the UI can send a view mirror request to the management system, and can request the management system to view the list of available images of DT2 under the corresponding account of VEC1 (as shown in Figure 6, tenant 2 can Used mirror list).
  • Step 835 The management system searches for a list of available images of DT2 under the account corresponding to VEC1.
  • the management system can view the list of available images of DT2 under the corresponding account of VEC1 (as shown in Figure 6, tenant 2 under item 1), and other VECs that have an alliance relationship with VEC1. (VEC that can interconnect with VEC1 resources) The shared image under the corresponding account.
  • Step 840 the management system sends a response failure message (response error (not exist)) to the DT2.
  • the alliance relationship between the VECs in the embodiment of the present application is: the same VEC allows intercommunication, because DT2 and DT1 belong to different VECs (as shown in FIG. 6, DT1 belongs to Huang Yun and DT2 belongs to (Green Cloud), therefore, DT2 does not have permission to access the shared image in VEC1 to which DT1 belongs. That is, as shown in FIG. 6, the tenant 2 does not have permission to access the mirror resource shared by the tenant 1 in the project 1.
  • the management system can send a response failure message to DT2.
  • Step 845 DT2 sends a VM creation request (create VM (DT2, VEC1, region1, image-ID)) to the management system.
  • create VM DT2, VEC1, region1, image-ID
  • DT2 can directly specify the image ID (image-ID) to be accessed to the management system through the API, and the management system can determine whether DT2 has permission to access the image based on the image ID.
  • image-ID image-ID
  • Step 850 The management system confirms whether DT2 can access the specified image ID.
  • the management system After receiving the specified image ID sent by DT2, the management system can first confirm whether DT2 has permission to access the specified image ID (for example, whether the specified image ID is private to DT2 and the specified image ID Whether to share it for DT2). Secondly, the management system can communicate with the VEC to which the DT2 belongs (the alliance) according to the image ID.
  • the specified image ID belongs to VEC1 (the specified image ID belongs to the mirror resource of tenant 1 in project 1)
  • DT2 and DT1 belong to different VECs
  • DT1 is tenant 1 in Figure 6, and the resource set of tenant 1 in Huangyun is the project 1
  • DT2 is the tenant 2 in Figure 6, and the resource set of tenant 2 in the green cloud is project 2).
  • the alliance relationship between the VECs in the embodiment of the present application is: the same VEC is allowed to communicate with each other, and different VECs are not allowed to communicate with each other. Therefore, the management system can confirm that DT2 does not have permission to access the specified image ID.
  • step 855 the management system sends a response failure message (response error (not exist)) to the DT2.
  • FIG. 9 is a schematic flowchart of a tenant complying with a security policy according to another embodiment of the present application.
  • the method in FIG. 9 may include steps 910-950. Steps 910-950 are described in detail below.
  • management system shown in FIG. 9 may correspond to the above management platform (ie, correspond to the management system 110 in FIG. 1).
  • the department tenant DT1 and the department tenant DT2 need to initiate access to the shared OBS through the storage service.
  • object storage service OBS can be an object-based mass storage service, which can store data of any type and size, and can manage the stored data in the OBS.
  • Buckets can be used as containers for storing objects in OBS. All data uploaded by users to OBS can be stored in buckets. Users can share buckets to share data stored in OBS. Accessing the OBS is a data plane operation. The operation itself does not carry tenant information. Therefore, the management system can confirm the tenant information corresponding to the initiator when the access sharing is initiated.
  • Step 910 DT1 sends a request (VEC1, share, DT2) to create a bucket and share the bucket to DT2 to the user interface UI.
  • DT1 (belonging to VEC1) can create buckets, and can send the shared buckets to DT2 to the UI, so that DT2 can share the data stored in the buckets.
  • DT2 and DT1 may belong to the same VEC (for example, VEC1), and DT2 may not belong to the same VEC as DT1. The following steps will explain two specific situations.
  • Step 915 The UI sends a bucket creation request (create bucket (VEC1, share, DT2)) to the management system.
  • create bucket VEC1, share, DT2
  • the UI may send a bucket creation request to the management system after receiving the bucket creation request sent by DT1 and sharing the created bucket to DT2. It can also notify the management system that DT1 can share the created bucket to DT2.
  • Step 920 The management system sets bucket sharing to DT2.
  • the management system After receiving the bucket creation request sent by the UI, the management system can set the created bucket to share to DT2, so that DT2 can share the data stored in the bucket.
  • Step 925 DT2 sends a request to the UI to access the bucket (bucket, ak, sk) in VEC1.
  • DT2 can send a request to the UI to access the bucket in VEC1.
  • DT2 may belong to the same VEC (for example, VEC1) as DT1, and DT2 may not belong to the same VEC as DT1.
  • Step 930 The UI sends a DT2 request to the management system to access the bucket (bucket, ak, sk) shared in DT1.
  • the UI can send the request to the management system after receiving the request sent by DT2 to access the bucket shared in DT1.
  • Case 1 DT2 and DT1 belong to the same VEC (VEC1), that is, the VEC to which the access source DT2 belongs is the same as the VEC to which the accessed bucket belongs.
  • DT1 is the tenant 1 in Figure 6
  • DT2 is the tenant 2 in Figure 6. Both DT1 and DT2 belong to Huang Yun.
  • the resources of DT1 in Huangyun are Project 1
  • the resources of DT2 in Huangyun are Project 1.
  • Case 2 DT2 and DT1 do not belong to the same VEC (DT1 belongs to VEC1, DT2 belongs to VEC2), that is, the VEC to which the access source DT2 belongs is different from the VEC to which the accessed bucket belongs.
  • DT1 belongs to Huang Yun
  • DT1's resources in Yellow Cloud are Project 1
  • DT2 belongs to Green Cloud
  • DT2's resources in Green Cloud are Project 2.
  • step 935 the management system checks that the enterprise cloud to which the access source DT2 belongs is VEC1, and the enterprise cloud to which the accessed bucket belongs is VEC1, and the query result is that access is allowed.
  • the management system After receiving the DT2 request from the UI to access the shared bucket in DT1, the management system can check the alliance relationship between the VEC to which the access source DT2 belongs and the VEC to which the accessed bucket belongs.
  • the alliance relationship between the VECs in the embodiment of the present application is that the same VEC allows intercommunication. Since DT2 and DT1 belong to the same VEC (the yellow cloud shown in FIG. 6), the management system It is set to share the bucket created by DT1 to DT2. Therefore, the management system can determine that DT2 allows access to the data stored in the bucket shared by DT1 according to the set interconnection rules.
  • the resources of tenant 1 in project 1 and the resources of tenant 2 in project 1 can be interconnected and / or interoperable.
  • the management system can also confirm the access password of the visitor tenant DT2 after determining that DT2 allows access to the data stored in the bucket shared by DT1.
  • Step 940 The management system sends a successful access message to DT2.
  • the management system can send a successful access message to DT2 after viewing and determining that DT2 allows access to the data stored in the bucket shared by DT1.
  • Step 945 The management system checks that the enterprise cloud to which the access source DT2 belongs is VEC2 (green cloud shown in FIG. 6), and the enterprise cloud to which the accessed bucket belongs is VEC1 (yellow cloud shown in FIG. 6).
  • the alliance relationship between the VECs in the embodiment of the present application is: the same VEC allows interworking. Since DT2 and DT1 belong to different VECs, the management system can according to the set interconnection rules It is determined that DT2 prohibits access to the data stored in the bucket shared by DT1.
  • the tenant 2 does not have permission to access the mirror resource shared by the tenant 1 in the project 1, and the interconnection between the resources of the tenant 1 in the project 1 and the resources of the tenant 2 in the project 2 is prohibited and / Or interoperability.
  • Step 950 The management system sends an access failure message to DT2.
  • the management system can send an access failure message to DT2 after viewing and determining that DT2 prohibits access to the data stored in the bucket shared by DT1.
  • the implementation of the VEC policy is simple and clear. If the resources between VECs are prohibited from interoperating, the management system will directly block the operation. If the resources between VECs are allowed to interwork, the management system will perform a common process. , Can achieve that resources, information does not flow across VEC, thereby avoiding problems such as information leakage.
  • the method for creating an enterprise cloud provided by the embodiment of the present application is described in detail above with reference to FIGS. 1 to 9.
  • the device embodiment (management platform) of the present application will be described in detail below with reference to FIGS. 10 to 11. It should be understood that the description of the method embodiment and the description of the device embodiment correspond to each other. Therefore, for the parts that are not described in detail, reference may be made to the foregoing method embodiment.
  • FIG. 10 is a schematic block diagram of a management platform 1000 according to an embodiment of the present application.
  • the management platform 1000 may include a processing module 1010 and a receiving module 1020.
  • a processing module 1010 configured to create multiple virtual enterprise clouds that are based on the construction and are used to provide cloud resources;
  • the processing module 1010 performs the following operations through the receiving module 1020: adding a tenant to at least one virtual enterprise cloud according to the first instruction, the at least one virtual enterprise cloud being a department or all of the plurality of virtual enterprise clouds.
  • the processing module 1010 is specifically configured to:
  • Adding at least one item of the tenant to the at least one virtual enterprise cloud and each item includes cloud resources that the tenant is allowed to access in the virtual enterprise cloud to which each item belongs.
  • the processing module 1010 is further configured to:
  • the access right of the tenant in the at least one project is configured, so that the tenant has the ability to manage cloud resources included in each project.
  • the receiving module 1020 is further configured to receive a second instruction, where the second instruction instructs to set a security rule between the multiple virtual enterprise clouds, where the security rule is used for Whether the cloud resources of the multiple virtual enterprise clouds can be shared and / or interoperable between the multiple virtual enterprise clouds;
  • the processing module 1010 is further configured to record the security rule.
  • the receiving module 1020 is further configured to receive a first request, where the first request is used for the first project of the first tenant to initiate resource sharing and the second project of the second tenant. / Or interworking, wherein the first item belongs to a first virtual enterprise cloud, and the second item belongs to a second virtual enterprise cloud;
  • the processing module 1010 is further configured to determine whether to allow resource sharing and / or interworking between the first project and the second project according to the recorded security rules.
  • the processing module 1010 is specifically configured to:
  • security rules allow resource sharing and / or interworking between the first virtual enterprise cloud and the second virtual enterprise cloud, resource sharing according to corresponding services between the first tenant and the second tenant And / or an interworking process, allowing resource sharing and / or interworking between the first project and the second project;
  • management platform 1000 may be used to execute the corresponding processes of the methods in FIG. 2 to FIG. 9 in the embodiment of the present application, and the above and other operations and / or functions of each module in the management platform 1000 are In order to implement the corresponding processes of the methods in FIG. 2 to FIG. 9 of the embodiment of the present application, for brevity, details are not described herein again.
  • an enterprise tenant can create multiple VECs on a cloud service.
  • the multiple VECs are independent of each other, and the services within the VEC are controllable. It enables enterprises to have their own independent, complete, secure, compliant, service-controllable, and maintenance-free virtual enterprise cloud on cloud services, while enjoying the agility of on-demand purchase and elastic scalability.
  • Different security levels can be set according to the importance, sensitivity, and security of corporate information to ensure information security.
  • departments within the enterprise and even ordinary employees can have a high ability to control resources and use resources flexibly.
  • FIG. 11 is a schematic block diagram of a management platform 1100 according to an embodiment of the present application.
  • the management platform 1100 includes at least one computing device 1110, and each computing device 1110 may include a communication interface 1111, a processor 1112, and a memory 1113.
  • each computing device 1110 may further include a bus 1114.
  • the communication interface 1111, the processor 1112, and the memory 1113 may be connected to each other through a bus 1114.
  • the bus 1114 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (referred to as an abbreviation). EISA) bus and so on.
  • the bus 1114 can be divided into an address bus, a data bus, a control bus, and the like. For ease of representation, only one thick line is used in FIG. 11, but it does not mean that there is only one bus or one type of bus. among them:
  • the memory 1113 may be used to store program code and data of the management platform. Therefore, the memory 1113 may be a storage unit inside the processor 1112, or an external storage unit independent of the processor 1112, or may include a storage unit inside the processor 1112 and an external storage unit independent of the processor 1112. component.
  • the processor 1112 may be composed of one or more general-purpose processors, such as a central processing unit (CPU), a general-purpose processor, a digital signal processor (DSP), and an application-specific integrated circuit (application- specific integrated circuit (ASIC), field programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logical blocks, modules, and circuits described in connection with the present disclosure.
  • the processor may also be a combination that implements computing functions, such as a combination of multiple microprocessors, a combination of a DSP and a microprocessor, and so on.
  • the processor 1112 may be used to run a program of processing functions in related program code. That is, the processor 1112 executes the program code to implement the functions of the processing module. For details about the processing module, refer to related descriptions in the foregoing embodiments.
  • processor 1112 may also be a set of processors including at least one computing device 1110, which is not specifically limited in this application.
  • the processors of the at least one computing device 1110 are commonly used to run related program code to implement the functions of the processing module of the present application, or to implement the steps shown in FIG. 2 of the present application.
  • the methods described in 210-220, and / or other steps to implement the techniques described herein, etc., are not detailed and limited herein.
  • each computing device 1110 may be individually used to run related program code to implement the functions of the processing module described in this application, or to implement the steps shown in FIG. 2 of the application described above.
  • the methods described in 210-220, and / or other steps to implement the techniques described herein, etc., are not detailed and limited herein.
  • the communication interface 1111 may be a wired interface (such as an Ethernet interface) or a wireless interface (such as a cellular network interface or using a wireless local area network interface) for communicating with other modules / devices.
  • a wired interface such as an Ethernet interface
  • a wireless interface such as a cellular network interface or using a wireless local area network interface
  • the communication interface in the embodiment of the present application may be specifically used to receive instruction data and the like sent by an enterprise tenant or a tenant.
  • the memory 1113 may include volatile memory (for example, random access memory (RAM); the memory may also include non-volatile memory (for example, read-only memory) memory (ROM), flash memory (flash memory), hard disk (HDD), or solid-state drive (SSD); the memory 1113 may also include a combination of the above types of memories.
  • RAM random access memory
  • ROM read-only memory
  • flash memory flash memory
  • HDD hard disk
  • SSD solid-state drive
  • the memory 1113 may be used to store a set of program code, so that the processor 1112 calls the program code stored in the memory 1113 to implement the functions of the communication module and / or the processing module involved in the embodiment of the present invention.
  • the processor 1112 When the program is executed, the processor 1112 is configured to: create multiple virtual enterprise clouds that are based on the construction and are used to provide cloud resources;
  • the processor 1112 performs the following operations through the communication interface 1111: adding a tenant to at least one virtual enterprise cloud according to the first instruction, the at least one virtual enterprise cloud being a department or all of the plurality of virtual enterprise clouds.
  • the processor 1112 is specifically configured to:
  • Adding at least one item of the tenant to the at least one virtual enterprise cloud and each item includes cloud resources that the tenant is allowed to access in the virtual enterprise cloud to which each item belongs.
  • the processor 1112 is further configured to:
  • the access right of the tenant in the at least one project is configured, so that the tenant has the ability to manage cloud resources included in each project.
  • the communication interface 1111 is further configured to: receive a second instruction, where the second instruction instructs to set a security rule between the multiple virtual enterprise clouds, where the security rule is used to: Whether the cloud resources of the multiple virtual enterprise clouds can be shared and / or interoperable between the multiple virtual enterprise clouds;
  • the processor 1112 is further configured to record the security rule.
  • the communication interface 1111 is further configured to receive a first request, where the first request is used for the first project of the first tenant to initiate resource sharing and the second project of the second tenant.
  • the first request is used for the first project of the first tenant to initiate resource sharing and the second project of the second tenant.
  • interworking wherein the first item belongs to a first virtual enterprise cloud, and the second item belongs to a second virtual enterprise cloud;
  • the processor 1112 is further configured to determine whether to allow resource sharing and / or interworking between the first project and the second project according to the recorded security rules.
  • the processor 1112 is specifically configured to:
  • security rules allow resource sharing and / or interworking between the first virtual enterprise cloud and the second virtual enterprise cloud, resource sharing according to corresponding services between the first tenant and the second tenant And / or an interworking process, allowing resource sharing and / or interworking between the first project and the second project;
  • an enterprise tenant can create multiple VECs.
  • the multiple VECs are independent of each other, and the services within the VEC are controllable. It can enable enterprises to have their own independent, complete, security-compliant, service-controllable, and maintenance-free virtual enterprise cloud on cloud services, while enjoying the agility of on-demand purchase and elastic scalability.
  • Different security levels can be set according to the importance, sensitivity, and security of corporate information to ensure information security.
  • departments within the enterprise and even ordinary employees can have a high ability to control resources and use resources flexibly.
  • an embodiment of the present application further provides a computer-readable medium, where the computer-readable medium stores program code, and when the computer program code runs on the computer, the computer executes the methods in the foregoing aspects. .
  • an embodiment of the present application further provides a chip, including a memory, a processor, and a transceiver.
  • the chip may be used to execute the method described in steps 210-220 and / or implement the technology described herein. Other steps, etc.
  • the memory is used to store a program
  • the processor may be communicatively connected with the transceiver.
  • the memory may be used to store program code and data of the terminal device. Therefore, the memory may be a storage unit inside the processor, or an external storage unit that is independent of the processor, and may also be a component including a storage unit inside the processor and an external storage unit that is independent of the processor.
  • the processor may be a general-purpose processor, and may be implemented by hardware or software.
  • the processor may be a logic circuit, an integrated circuit, etc .; when implemented by software, the processor may be a general-purpose processor, realized by reading software codes stored in a memory, so The memory may be integrated in the processor, may be located outside the processor, and exist independently.
  • an embodiment of the present application further provides a computer program product, where the computer program product includes: computer program code that, when the computer program code runs on a computer, causes the computer to execute the methods in the foregoing aspects.
  • a component may be, but is not limited to, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and / or a computer.
  • an application running on a computing device and a computing device can be components.
  • One or more components can reside within a process and / or thread of execution, and a component can be localized on one computer and / or distributed between 2 or more computers.
  • these components can execute from various computer readable media having various data structures stored thereon.
  • a component may pass according to a signal having one or more data packets (e.g., data from two components that interact with another component between a local system, a distributed system, and / or a network, such as the Internet that interacts with other systems through signals).
  • Data packets e.g., data from two components that interact with another component between a local system, a distributed system, and / or a network, such as the Internet that interacts with other systems through signals.
  • system and “network” are often used interchangeably herein.
  • the term “and / or” in this document is only a kind of association relationship describing related objects, which means that there can be three kinds of relationships, for example, A and / or B can mean: A exists alone, A and B exist simultaneously, and exists alone B these three cases.
  • the character "/" in this article generally indicates that the related objects are an "or” relationship.
  • the disclosed systems, devices, and methods may be implemented in other ways.
  • the device embodiments described above are only schematic.
  • the division of the unit is only a logical function division.
  • multiple units or components may be combined or Can be integrated into another system, or some features can be ignored or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, which may be electrical, mechanical or other forms.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, may be located in one place, or may be distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the objective of the solution of this embodiment.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each of the units may exist separately physically, or two or more units may be integrated into one unit.
  • the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium.
  • the technical solution of this application is essentially a part that contributes to the existing technology or a part of the technical solution can be embodied in the form of a software product.
  • the computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in the embodiments of the present application.
  • the aforementioned storage media include: U disks, mobile hard disks, read-only memories (ROMs), random access memories (RAMs), magnetic disks or compact discs and other media that can store program codes .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Automation & Control Theory (AREA)
  • Databases & Information Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本申请提供了一种企业云的创建方法和管理平台。该方法包括：管理平台创建多个虚拟企业云，所述多个虚拟企业云基于云服务构建且用于提供云资源；所述管理平台接收第一指令，根据所述第一指令将租户添加至至少一个虚拟企业云，所述虚拟企业云为所述多个虚拟企业云中的部分或全部。本申请提供的技术方案可以在使用云资源过程中，可以根据企业信息的重要性、敏感性和安全性设定不同的安全等级，可以实现企业的信息安全和/或其他隔离目的。

Description

一种企业云的创建方法和管理平台 技术领域
本申请涉及信息技术安全领域，并且更具体地，涉及一种企业云的创建方法和管理平台。
背景技术
随着技术的发展，云计算的出现可以使得企业不再需要规划、预算、采购服务器、网络、存储以及安全等设备。也不再需要维持庞大、昂贵而与企业主业务无关的IT团队来运维上述物理设备。企业可以租用资源，随用随买，资源规模极具弹性，少到几台服务器，多到上万台服务器。
云服务为如同自来水、电力一样的基础公共设施，追求性价比，可靠性，以较小的管理软硬件成本，提供较好的服务。但是对于企业而言，在信息电子化联网以后，云服务上的信息安全显得尤为重要。
现有技术中，为了保证企业在使用云服务过程中的信息安全，可以通过访问策略设定企业内不同的人员是否能够使用和查看某些特定的资源的权限。但是现有技术中仅仅设置了企业内的人员不能访问和使用一些信息安全级别较高的信息，其使用的云资源不具备安全属性，企业内的人员只能有一种安全属性的云资源。并且现有技术中，企业租户要实现上述企业信息安全，需要企业管理员手工从上至下的管控或需要自己的云平台适配和对接来实现企业组织结构和企业信息安全。
因此，在使用云资源过程中，如何实现企业的信息安全成为当前亟需要解决的问题。
发明内容
本申请提供一种企业云的创建方法和管理平台，可以在使用云资源过程中，可以根据企业信息的重要性、敏感性和安全性设定不同的安全等级，保证企业内信息安全。同时，企业内的部门甚至是普通员工又可以具备较高的资源把控能力和资源灵活使用的能力。
第一方面，提供了一种企业云的创建方法，该方法包括：管理平台创建多个虚拟企业云；所述管理平台接收第一指令，根据所述第一指令将租户添加至至少一个虚拟企业云，所述至少一个虚拟企业云为所述多个虚拟企业云的部分或者全部。
本申请实施例可以根据信息的安全等级或业务相关性，将底层共享的资源进行隔离，可以将信息保存在不同的安全区。虚拟企业云VEC可以理解为上述安全区，一个企业组织内可以划分为一个安全区，也可以划分为多个安全区。每个虚拟企业云VEC可以基于云服务为VEC中的用户或租户构建或提供云资源，云服务可以包括但不限于：网络服务、计算服务、存储服务等。
企业根租户(以下可以简称为“企业租户”)在云计算领域可以指在云服务上注册的租户账号，该租户账号具备使用所有云服务，可以具有管理租户内的一切资源的 权限。企业根租户可以是使用者在对应上所拥有的服务资源容器载体和所有权的体现，云运营商可以通过该账号关联的金融账户收取费用。在本申请实施例中，企业租户可以作为虚拟企业云的云运营管理员，可以在底层云服务上创建虚拟企业云。
企业租户的管理权限可以包括但不限于：构建企业内的组织架构(例如，企业根据不同的业务类型划分不同的部门)、创建VEC、设置VEC内可用和/或禁用的服务列表、制定VEC之间的互联互通策略、制定与VEC外部(例如，普通租户、其他企业的VEC)之间的互联互通策略、实施企业预算制度、对企业费用进行结算和/或分析。
本申请实施例中企业租户在设置权限以及可用和/或禁用的服务列表、制定VEC之间的互联互通策略之后，企业附属各组织、雇员强制遵守，可以保证信息企业信息安全。例如，如果请求互联互通的两个资源属于不同的VEC，且企业租户指定VEC之间隔离(也就是说，不同的VEC之间的资源不允许互联互通)，即使在底层云服务上该两个资源属于同一个租户，管理系统也不允许该两个资源之间进行互联互通。
可选地，在一些实施例中，企业租户在创建虚拟企业云后还可以为该虚拟企业云开通服务，允许租户在该虚拟企业云上使用的服务、可用的计费模式、默认的租户资源配额、VEC生效的区域region等运营该虚拟企业云所需要的信息。
应理解，选定region后加入该虚拟企业云的其他租户只能选择企业租户所指定的region使用云服务。region可动态增加，删除region时需要将VEC内的资源全部释放。
管理平台可以将租户添加至创建的多个VEC中，本申请实施例对租户加入到VEC的具体实现方式不做限制。作为一个示例，租户可以申请加入到VEC，例如，租户可以申请需要访问和使用的VEC，企业租户可以审核该租户是否可以加入到申请的VEC中。作为另一个示例，企业租户也可以邀请租户加入到VEC中，例如，企业租户可以指定租户可以访问和使用的VEC，管理系统可以将租户加入到对应的VEC中。
可选地，在一些实施例中，企业租户在添加租户时也可以指定租户资源使用的配额、计费模式等，或者动态调整。
应理解，一般情况下，虚拟企业云内租户配额不大于底层云服务为租户指定的配额，且同一租户在多个虚拟企业云的配额之和不超过底层云服务为该租户指定的配额。
本申请实施例中企业租户可以在创建VEC，并且在添加完租户之后，可以查看创建了哪些VEC，以及每个VEC中的租户。租户在加入到VEC之后，可以进入VEC后选择不同的区域region。
本申请实施例中，企业租户创建多个VEC，所述多个VEC之间相互独立，VEC内服务可控、安全合规。可以使得企业在内拥有自己独立的、完整的、安全合规的、服务可控的、无需维护的虚拟企业云。可以根据企业信息的重要性、敏感性和安全性设定不同的安全等级，在保证信息安全的同时，企业内的部门甚至是普通员工可以具有较高的自主把控资源和资源灵活使用的能力。
可选地，在一些实施例中，VEC可以基于Open Stack中已有的project实现，其实现简单。
应理解，底层的租户可以映射为Open Stack中的domain，租户下面可以有多个项目(Open Stack中的project)。该项目可以是云资源的集合或容器，同时也可以 具有对这些云资源和租户的权限鉴别(其中，租户可以指定所属项目project之间的互通规则)。
本申请实施例中，VEC可以基于Open Stack中已有的project实现，其实现简单。企业、部门以及企业普通租户之间都可以保持相对独立，可以拥有独立而完整的使用资源的能力。
结合第一方面，在第一方面的某些实现方式中，所述管理平台接收第一指令，根据所述第一指令指示将租户添加至至少一个虚拟企业云，包括：所述管理平台将所述租户的至少一个项目添加至所述至少一个虚拟企业云，每个项目包括所述租户在所述每个项目所属的虚拟企业云中允许访问的云资源。
应理解，管理平台可以在将租户加入到创建的至少一个虚拟企业云，具体的，管理平台可以将租户的至少一个项目添加至至少一个虚拟企业云，项目中可以包括租户允许访问的云资源。
结合第一方面，在第一方面的某些实现方式中，所述管理平台配置所述租户在所述至少一个项目中的访问权限，使得所述租户具备管理每个项目包括的云资源的能力。
所述租户在所述多个虚拟企业云中具备完全管理允许的云资源的能力。也就是说，加入到VEC中的租户可以具备租户特征，加入到VEC中的租户可以完全控制企业租户指定的允许的各种基础设施即服务(infrastructure as a service，IaaS)资源、平台即服务(platform infrastructure as a service，PaaS)资源、软件即服务(software infrastructure as a service，SaaS)资源。在权限方面，加入到VEC中的租户除了以下权限外，和普通租户的权限一样：无法改变租户本身和虚拟企业云关系、无法增加访问企业租户禁止的服务、无法更改企业租户指定的计费套餐、配额预算等企业租户设定的规则。
应理解，本申请实施例中对加入到VEC中的租户不做具体限定。作为一个示例，加入到VEC中的租户代表企业内某个具体的雇员。作为另一个示例，加入到VEC中的租户代表某一个部门。
可选地，在一些实施例中，如果加入到VEC中的租户代表某一个部门(也就是说，可以是一个部门租户)，该租户可以作为为部门管理员，可以对其下的用户以及子部门进行权限设置和管理。例如，部门租户可以创建用户、管理用户、设置所述用户在所述虚拟企业云中的权限、设定其他安全规则。
可选地，在一些实施例中，加入到VEC中的租户还可以在企业租户(虚拟企业云管理员)设定的规则的基础上，进一步额外的设定一些安全规则。作为一个示例，加入到VEC中的租户可以设置在企业租户设定完安全规则之后，还可以额外设定VEC内禁止网络互通，其下挂的普通租户、用户账号均需要遵守该安全规则。
需要说明的是，企业租户禁止的，加入到VEC中的租户不能开通。企业租户允许的，加入到VEC中的租户可以禁止，也可以部分允许。企业租户作为企业管理员，需要遵守自己设定的安全规则。
企业租户ET设定好安全策略之后，租户无权访问未授权的VEC，也无权访问非授权服务。同时，加入到VEC中的租户均需要遵守企业租户ET设定的安全策略。也就是说，在企业租户作为管理员创建好VEC，并设置安全访问策略之后，加入到VEC中的 租户对资源的访问和操作，强制遵循企业租户(企业管理员)设定的VEC内、VEC间以及和其他企业的VEC之间、和非VEC之间的访问安全规则。作为一个示例，如果请求互联互通的两个资源属于不同的VEC，且企业租户指定VEC之间隔离(也就是说，不同的VEC之间的资源不允许互联互通)，即使在底层上该两个资源属于同一个租户，管理系统也不允许该两个资源之间进行互联互通。
本申请实施例中，租户在所述多个虚拟企业云中具备完全管理允许的各种云资源的能力，可以避免现有技术中企业租户全权负责企业内所有部门的资源和安全管理。
结合第一方面，在第一方面的某些实现方式中，所述方法还包括：所述管理平台接收第二指令；所述管理平台记录所述安全规则。
由于本申请实施例中在底层上创建的虚拟企业云VEC，其本身定义为云，云之间都是独立不互联的，因此，默认情况下VEC之间的资源不能互通、共享。
应理解，默认情况下，同一企业租户创建的不同VEC之间的资源不能互通、共享，不同企业租户创建的VEC之间的资源也不能互通、共享，VEC和外部非企业VEC的部分(除VEC后剩余的部分)之间的资源也不能互通、共享。
可选地，在一些实施例中，如果企业内由于业务需求需要实现VEC间的互联互通(也可以理解为在两个VEC之间取得信任，建立“云联盟”或“联邦云”)，联邦云之间可以共享或互通资源，本申请实施例中企业租户(作为企业管理员)可以有能力设置VEC之间的互联互通策略。联盟的VEC之间的资源可以在企业租户授权且云平台具备能力的情况下，可以直接互联互通，而非联盟的VEC之间系统默认资源禁止互联互通。
应理解，建立联邦云的两个VEC可以是同一个企业租户，也可以是跨企业租户，本申请对此不做具体限定。
还应理解，云联盟可以是两个VEC之间相互取得信任，该两个VEC之间的资源可以互通和/或共享，但是云联盟的关系不传递。作为一个示例，VEC1与VEC2为云联盟(VEC1与VEC2之间的资源可以互通和/或共享)，VEC2与VEC3为云联盟(VEC2与VEC3之间的资源可以互通和/或共享)，但是VEC1与VEC3之间不属于云联盟(也就是说，VEC1与VEC3之间的资源可以互通和/或共享)。如果VEC1与VEC3之间的资源需要进行互通和/或共享，需要在VEC1与VEC3之间建立联盟关系。
作为一个示例，如果企业租户(作为企业管理员)设定两个VEC为联邦云(即，两个VEC之间的资源可以互联互通)，则管理系统允许两个VEC之间的资源进行互联或互通，并可以按照底层云服务上已有的租户内或租户间对应服务的资源共享和/或互通的正常流程进行处理。作为另一个示例，如果企业租户(作为企业管理员)未设定两个VEC之间的联盟关系，则可以默认为VEC之间是相互独立的，即VEC之间的资源不可以互联互通。
应理解，企业租户ET作为管理员不仅可以设定创建的VEC间资源的联盟关系，还可以定企业内各VEC与其他企业VEC、外部普通租户之间的互联互通的关系。
还应理解，联邦云内的两个租户的资源是否可以共享和/或互通，还取决于目标租户是否同意进行资源共享和/或互通。作为一个示例，如果租户共享资源给所有人，联邦云内的其他租户都可以共享，否则仅是指定的租户可以进行资源共享。
需要说明的是，本申请实施例中对VEC间的互联互通联盟策略的设置不做具体限定。企业租户可以根据企业的业务需求以及组织架构，对创建的任意VEC设定互联互通联盟策略。
可选地，在一些实施例中，企业租户(作为企业管理员)还可以在VEC之间互联互通策略的基础上，还可以设定一些其他更细化的安全规则。作为一个示例，企业租户可以设定互联互通的VEC之间仅网络服务资源可以互通。作为另一个示例，企业租户可以设定互联互通的VEC之间仅指定资源可以互通、访问。本申请对此不做具体限定。
结合第一方面，在第一方面的某些实现方式中，所述方法还包括：所述管理平台接收第一请求；所述管理平台根据记录的所述安全规则确定是否允许所述第一项目与所述第二项目之间的进行资源共享和/或互通。
应理解，第一请求用于第一租户的第一项目向第二租户的第二项目发起资源共享和/或互通，其中，第一项目属于第一虚拟企业云，第二项目属于第二虚拟企业云。
具体地，第一虚拟企业云中的第一租户可以通过服务请求共享和/或互通第二企业云中的资源。
本申请实施例中，第一租户和第二租户在底层的上可以是同一个租户，也可以是不同的两个租户，本申请对此不做具体限定。
结合第一方面，在第一方面的某些实现方式中，如果所述安全规则允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，所述管理平台按照所述第一租户与所述第二租户之间对应服务的资源共享和/或互通流程，允许所述第一项目与所述第二项目之间进行资源共享和/或互通；如果所述安全规则不允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，所述管理平台禁止所述第一项目与所述第二项目之间进行资源共享和/或互通。
本申请实施例中管理平台可以根据记录的VEC之间的联盟关系，确定两个VEC之间是否可以允许互通，可以满足企业内云间互联互通的需求。
作为一个示例，当第一VEC和第二VEC之间为非联盟的关系时，第一VEC中的租户在请求第二VEC的资源进行互联互通时，管理系统将直接阻断第一租户的第一项目与第二租户的第二项目之间进行资源互联互通。
可选地，在一些实施例中，当第一VEC和第二VEC之间为非联盟的关系，第一VEC中的租户在向第二VEC中的租户请求进行资源互联互通时，管理平台可以根据记录的VEC之间的联盟关系进行进行审批，确定是否允许第一租户的第一项目与第二租户的第二项目之间进行资源互联互通(如果VEC1与VEC2之间的关系为非联盟，则管理系统禁止第一租户的第一项目与第二租户的第二项目之间进行资源互联互通)。
作为另一个示例，当第一VEC和第二VEC之间为联盟的关系时，第一VEC中的租户在请求第二VEC的资源进行互联时，管理系统将允许第一VEC中的租户向第二VEC的资源互联互通请求。例如，如果VEC1与VEC2之间请求资源互联互通时，由于VEC1与VEC2之间的联盟关系为已建立联盟关系，管理系统将第一VEC中的租户按照底层已有的第一租户与第二租户之间对应服务的资源共享和/或互通处理流程，允许第一租户的第一项目与第二租户的第二项目之间进行资源共享和/或互通。
本申请实施例中，企业租户创建VEC，可以保证企业仍然能够根据信息的重要性或敏感性对资源进行访问控制。可以达到企业各部门、各员工之间既可以自由分配、使用各VEC的资源，又可以达到资源、信息不跨VEC流动，从而避免信息泄露等问题。
第二方面，提供了一种管理平台，该管理平台包括：
处理模块，用于创建多个虚拟企业云，所述多个虚拟企业云基于所述构建且用于提供云资源；
所述处理模块通过接收模块执行以下操作：根据所述第一指令将租户添加至至少一个虚拟企业云，所述至少一个虚拟企业云为所述多个虚拟企业云的部门或全部。
结合第二方面，在第二方面的某些实现方式中，所述处理模块具体用于：
将所述租户的至少一个项目添加至所述至少一个虚拟企业云，每个项目包括所述租户在所述每个项目所属的虚拟企业云中允许访问的云资源。
结合第二方面，在第二方面的某些实现方式中，所述处理模块还用于：
配置所述租户在所述至少一个项目中的访问权限，使得所述租户具备管理每个项目包括的云资源的能力。
结合第二方面，在第二方面的某些实现方式中，所述接收模块还用于：接收第二指令，所述第二指令指示设置所述多个虚拟企业云之间的安全规则，所述安全规则用于表示所述多个虚拟企业云的云资源是否能够在所述多个虚拟企业云之间进行共享和/或互通；
所述处理模块还用于：记录所述安全规则。
结合第二方面，在第二方面的某些实现方式中，所述接收模块还用于：接收第一请求，所述第一请求用于第一租户的第一项目向第二租户的第二项目发起资源共享和/或互通，其中，所述第一项目属于第一虚拟企业云，所述第二项目属于第二虚拟企业云；
所述处理模块还用于：根据记录的所述安全规则确定是否允许所述第一项目与所述第二项目之间的进行资源共享和/或互通。
结合第二方面，在第二方面的某些实现方式中，所述处理模块具体用于：
如果所述安全规则允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，按照所述第一租户与所述第二租户之间对应服务的资源共享和/或互通流程，允许所述第一项目与所述第二项目之间进行资源共享和/或互通；
如果所述安全规则不允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，禁止所述第一项目与所述第二项目之间进行资源共享和/或互通。
第三方面，提供了一种管理平台，该管理平台括至少一个计算设备，每个计算设备1110都可以包括：处理器和存储器、通信接口。
该存储器可以用于存储该管理平台的程序代码和数据。因此，该存储器可以是处理器内部的存储单元，也可以是与处理器独立的外部存储单元，还可以是包括处理器内部的存储单元和与处理器独立的外部存储单元的部件。
存储器可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)；存储器也可以包括非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，ROM)、快闪存储器(flash memory)、硬盘(hard  disk drive，HDD)或固态硬盘(solid-state drive，SSD)；存储器还可以包括上述种类的存储器的组合。存储器可用于存储一组程序代码，以便于处理器调用存储器中存储的程序代码以实现本发明实施例中涉及的接收模块和/或处理模块的功能。
处理器可以由一个或者多个通用处理器构成，例如可以是中央处理器(central processing unit，CPU)，通用处理器，数字信号处理器(digital signal processor，DSP)，专用集成电路(application-specific integrated circuit，ASIC)，现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含多个微处理器组合，DSP和微处理器的组合等等。处理器可用于运行相关的程序代码中处理功能的程序。也就是说，处理器执行程序代码可以实现处理模块的功能。其中，关于处理模块具体可参见前述第二方面中的相关阐述。
应理解，处理器还可以是包括至少一台计算设备的处理器的集合，本申请对此不做具体限定。
在一种可能的实施方式中，所述至少一个计算设备的处理器共同用于运行相关的程序代码，以实现本申请上述处理模块的功能。
在另一种可能的实施方式中，每个计算设备的处理器可单独用于运行相关的程序代码，以实现本申请上述处理模块的功能。
通信接口可以为有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与其他模块/设备进行通信。例如，本申请实施例中通信接口具体可用于接收企业租户或租户发送的指令数据等。
所述处理器用于从存储器中调用并运行该计算机程序，使得所述管理平台执行第一方面或第一方面任意一种可能的实现方式中所述的方法。
当程序被执行时，处理器用于：创建多个虚拟企业云，所述多个虚拟企业云基于所述构建且用于提供云资源；
所述处理器通过通信接口执行以下操作：根据所述第一指令将租户添加至至少一个虚拟企业云，所述至少一个虚拟企业云为所述多个虚拟企业云的部门或全部。
结合第三方面，在第三方面的某些实现方式中，所述处理器具体用于：
将所述租户的至少一个项目添加至所述至少一个虚拟企业云，每个项目包括所述租户在所述每个项目所属的虚拟企业云中允许访问的云资源。
结合第三方面，在第三方面的某些实现方式中，所述处理器还用于：
配置所述租户在所述至少一个项目中的访问权限，使得所述租户具备管理每个项目包括的云资源的能力。
结合第三方面，在第三方面的某些实现方式中，所述通信接口还用于：接收第二指令，所述第二指令指示设置所述多个虚拟企业云之间的安全规则，所述安全规则用于表示所述多个虚拟企业云的云资源是否能够在所述多个虚拟企业云之间进行共享和/或互通；
所述处理器还用于：记录所述安全规则。
结合第三方面，在第三方面的某些实现方式中，所述通信接口还用于：接收第一 请求，所述第一请求用于第一租户的第一项目向第二租户的第二项目发起资源共享和/或互通，其中，所述第一项目属于第一虚拟企业云，所述第二项目属于第二虚拟企业云；
所述处理器还用于：根据记录的所述安全规则确定是否允许所述第一项目与所述第二项目之间的进行资源共享和/或互通。
结合第三方面，在第三方面的某些实现方式中，所述处理器具体用于：
如果所述安全规则允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，按照所述第一租户与所述第二租户之间对应服务的资源共享和/或互通流程，允许所述第一项目与所述第二项目之间进行资源共享和/或互通；
如果所述安全规则不允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，禁止所述第一项目与所述第二项目之间进行资源共享和/或互通。
第四方面，提供了一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。该介质为非瞬态的。
第五方面，提供了一种芯片，包括存储器、处理器和收发器，
所述存储器用于存储计算机程序；
所述处理器可以与收发器通信连接。所述存储器可以用于存储所述终端设备的程序代码和数据。因此，所述存储器可以是处理器内部的存储单元，也可以是与处理器独立的外部存储单元，还可以是包括处理器内部的存储单元和与处理器独立的外部存储单元的部件。
可选地，所述处理器可以是通用处理器，可以通过硬件来实现也可以通过软件来实现。当通过硬件实现时，所述处理器可以是逻辑电路、集成电路等；当通过软件来实现时，所述处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，所述存储器可以集成在处理器中，可以位于所述处理器之外，独立存在。
所述处理器用于从存储器中调用并运行该计算机程序，使得所述管理平台执行第一方面或第一方面任意一种可能的实现方式中所述的方法。
第六方面，提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。
附图说明
图1是可应用于本申请实施例的系统架构示意图。
图2是本申请实施例提供的一种企业云的创建方法。
图3是图2中的步骤210的一种可能的实现方式的示意性流程图。
图4是图2中的步骤220的一种可能的实现方式的示意性流程图。
图5是本申请实施例提供的一种创建的VEC模型的示意性结构图。
图6是本申请实施例提供的一种通过project创建的VEC模型的示意性结构图。
图7是本申请实施例提供的一种租户遵守安全策略的示意性流程图。
图8是本申请另一实施例提供的一种租户遵守安全策略的示意性流程图。
图9是本申请另一实施例提供的一种租户遵守安全策略的示意性流程图。
图10是本申请实施例提供的一种管理平台1000的示意性框图。
图11是本申请实施例提供的一种管理平台1100的示意性框图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
云服务为如同自来水、电力一样的基础公共设施，追求性价比，可靠性，以较小的管理软硬件成本，提供较好的服务。但是对于企业而言，在信息电子化联网以后，信息安全显得尤为重要。
下面以企业为例，首先，企业管理者希望其内部的信息资产仅在其内部流转，而无法在非授权情况下流出到互联网上或其他企业、竞争对手。其次，企业内也需要根据所存储和传输的信息资产的重要性、敏感性和保密性设定不同的安全级别，而不同级别的企业信息之间通常是不能随意流动的，尤其是高保密性的信息不能流动至低保密性信息的区域(根据业务需要，不同的部门成员可以同时拥有不同的安全区域的访问权限)，从而可以保证企业信息资产的安全性。
现有技术中，为了保证企业在使用云服务过程中的企业信息安全，可以通过访问策略设定企业内不同的人员是否具有能够使用和查看某些特定的资源的权限。
现有技术中，仅仅设定人员能否使用和查看某些特定的资源，而不能根据企业信息资产的重要性、敏感性和保密性设定不同的安全级别。更不能指定企业信息资产间的流动规则资产流动的规则和具体的人没有关系，除非是具备更改规则的企业租户。其资源不具备安全属性。
企业在保证安全的前提下，又期望给予企业内部门甚至普通员工较高的自主把控资源的能力和资源灵活使用的能力。即可以根据业务诉求，随时随地开通使用企业管理员允许的服务，而无需反复审批、甚至线下控制。
但是，上述现有技术中，企业租户要实现上述企业信息安全(设定人员能否使用和查看某些特定的资源)，需要企业管理员手工从上至下的管控或需要自己的云平台适配和对接云服务来实现企业组织结构和企业信息安全。企业内的部门甚至是普通员工无法具有资源灵活使用的能力。
本申请实施例中提供的种企业云的创建方法，可以根据企业信息的重要性、敏感性和安全性设定不同的安全等级，保证企业内信息安全。同时，企业内的部门甚至是普通员工又可以具有较高的资源把控能力和资源灵活使用能力。
图1是可应用于本申请实施例的系统架构示意图。如图1所示，该系统架构可以包括管理(management)系统110、企业租户(enterprise tenant，ET)120、租户130、用户界面(user interface，UI)140、应用程序编程接口网关(application programming interface gatawate，API-GW)150、虚拟企业云(virtual enterprise clound，VEC)160、VEC170，网络服务122、计算服务124、存储服务126、其他服务128。
管理系统110作为云服务的管理平台，可以是一种集中控制的软件系统，也可以是一种按照服务属性或其他因素划分的多模块多服务系统。本申请实施例中，该管理 系统110可以用于基于云服务构建虚拟企业云VEC及其安全策略的模型(例如，图1中创建的VEC160、VEC170)。
应理解，云服务可以是企业用于通过网络以按需、易扩展的方式获取所需的服务，是一个数据中心。云服务供应商提供的云服务可以包括但不限于：网络服务122、计算服务124、存储服务126、其他服务128等。企业不需要配置所需要的主机、网络设备、存储、应用等，云服务供应商可以通过网络为企业提供相应的网络、计算、存储等资源。
企业租户(enterprise tenant，ET)120、租户130可以通过网络(例如，云服务的用户界面UI 140或应用程序编程接口网关API-GW150)获取上述云服务中的一种或多种(例如，网络服务122、计算服务124、存储服务126、其他服务128等)，本申请对此不做具体限定。
可选地，在一些实施例中，管理系统110还可以包括身份识别与访问管理(indentification and access management，IAM)模块。
IAM模块可以对VEC160、VEC170提供身份认证和权限功能管理，可以管理用户(例如，员工、系统或应用程序)账号，并可以实现对租户、资源、操作的权限鉴定以及授予。
应理解，本申请实施例中企业租户创建VEC并指定VEC间资源互联互通的策略，可以通过管理系统110中的IAM模块设定一系列权限，该权限可以包括但不限于：租户的权限、租户在各个区域(region)内的权限、租户与组织内的租户的权限、对云服务权限、操作权限等。
本申请实施例中构建VEC160、VEC170之后，管理系统110的具体实现架构可以有多种，本申请实施例对此不做具体限定。作为一个示例，管理系统110可以包括：IAM模块、IAM的安全管理模块。其中，IAM模块可以保存原有的身份识别与访问管理功能，IAM的安全管理模块可以理解为是一个专门针对企业租户的IAM模块进行安全管理的模块。例如，当确认为企业租户时，可以对接IAM的安全管理模块进行权限策略检查。也就是说，从IAM模块进入时，实际上需要接受IAM模块和IAM的安全管理模块的双重权限检查。作为另一个示例，管理系统110可以仅包括：IAM模块，IAM模块本身可以整合VEC安全策略的功能，也就是说，上述IAM模块和IAM的安全管理模块可以合成一个模块。
下面结合图1所示的系统架构图，详细描述本申请实施例提供的一种企业云的创建方法。
图2是本申请实施例提供的一种企业云的创建方法。图2所示的方法可以包括：步骤210-220。下面分别对步骤210-220进行详细描述。
步骤210，管理平台基于云服务创建多个虚拟企业云。
本申请实施例中管理平台可以对应于图1所示的管理系统110。
管理平台可以接收企业租户发送的第一指令，该第一指令可以用于请求管理平台在底层云服务上创建多个虚拟企业云。
本申请实施例可以根据信息的安全等级或业务相关性，可以将信息保存在不同的安全区。虚拟企业云VEC可以理解为上述安全区，一个企业组织内可以划分为一个安 全区，可以划分为多个安全区。每个虚拟企业云VEC为VEC中的用户或租户提供不同的云资源服务，该云资源服务可以包括但不限于：网络服务、计算服务、存储服务等。
本申请实施例中企业租户(也可以称为“企业根租户”)在云计算领域可以指注册的租户账号，该租户账号具备使用提供的所有云服务，可以具有管理租户内的一切资源的权限。企业根租户可以是使用者所拥有的服务资源容器载体和所有权的体现，云运营商可以通过该账号关联的金融账户收取费用。在本申请实施例中，企业租户可以作为虚拟企业云的云运营管理员，可以创建虚拟企业云。
企业租户的管理权限可以包括但不限于：构建企业内的组织架构(例如，企业根据不同的业务类型划分不同的部门)、创建VEC、设置VEC内可用和/或禁用的服务列表、制定VEC之间的互联互通策略、制定与VEC外部(例如，普通租户、其他企业的VEC)之间的互联互通策略、实施企业预算制度、对企业费用进行结算和/或分析。下文会结合图3-图5，对企业租户的管理权限进行详细描述，此处不再赘述。
管理平台可以根据企业租户发送的指令，可以在底层云服务上创建虚拟企业云VEC对象，并可以保存该记录。
应理解，管理平台根据企业租户的指令在底层云服务上创建的多个虚拟企业云VEC中可以保存和记录一些多个虚拟企业云VEC之间的安全规则、创建的账号之间的关联关系、加入到VEC中的租户可以使用的上线服务、加入到VEC中的租户可用的计费模式、加入到VEC中的租户可使用的资源配额等等。
还应理解，在企业租户将租户加入到创建的多个虚拟企业云之前，多个虚拟企业云VEC中的资源属于底层云服务。
步骤220，管理平台接收第一指令，根据第一指令将租户添加至至少一个虚拟企业云中。
管理平台可以将租户添加至至少一个虚拟企业云VEC中，本申请实施例对租户加入到至少一个VEC的具体实现方式不做限制。作为一个示例，租户可以申请加入到VEC，例如，租户可以申请需要访问和使用的至少一个VEC，企业租户可以审核该租户是否可以加入到申请的VEC中。作为另一个示例，企业租户也可以邀请租户加入到至少一个VEC中，例如，企业租户可以指定租户可以访问和使用的至少一个VEC，管理系统可以将租户加入到对应的至少一个VEC中。
应理解，本申请实施例中，可以将租户添加到部分或全部创建的VEC中。作为一个示例，可以将租户添加至创建的多个VEC中的一个。作为另一个示例，还可以将租户添加至创建的VEC中的至少两个。作为另一个示例，还可以将租户全部添加至创建的VEC中。本申请对此不做具体限定。
应理解，本申请实施例中对加入到VEC中的租户不做具体限定。作为一个示例，加入到VEC中的租户代表企业内某个具体的雇员。作为另一个示例，加入到VEC中的租户代表某一个部门。下面以将部门租户添加至至少一个VEC作为示例，结合图4对上述两种具体的实现方式进行详细描述，此处不再赘述。
可选地，在一些实施例中，企业租户在添加租户时也可以指定租户资源使用的配额、计费模式等，或者动态调整。
应理解，一般情况下，虚拟企业云内租户配额不大于为租户指定的配额，且同一 租户在多个虚拟企业云的配额之和不超过底层云服务为该租户指定的配额。
加入到至少一个VEC中的租户可以具备租户特征，也就是说，加入到VEC中的租户可以完全控制企业租户指定的允许的各种各种基础设施即服务(infrastructure as a service，IaaS)资源、平台即服务(platform infrastructure as a service，PaaS)资源、软件即服务(software infrastructure as a service，SaaS)资源。
应理解，在权限方面，加入到至少一个创建的VEC中的租户除了以下权限外，和普通租户的权限一样：无法改变租户本身和虚拟企业云关系、无法增加访问企业租户禁止的服务、无法更改企业租户指定的计费套餐、配额预算等企业租户设定的规则。
加入到至少一个创建的VEC中的租户的权限可以包括但不限于：租户无权更改企业租户设定的权限规则、租户无权访问未授权的VEC、租户无权访问非授权服务、租户可以拥有VEC内非禁止的全部租户的权限、租户需要遵守企业租户设定的安全规则(例如，企业租户制定的与VEC外部(例如，普通租户、其他企业租户创建的VEC)之间的互联互通策略)。下文会结合图3-图5，以将部门租户添加至至少一个创建的VEC作为示例，对租户的管理权限进行详细描述，此处不再赘述。
可选地，在一些实施例中，如果加入到VEC中的租户代表某一个部门(也就是说，可以是一个部门租户)，该租户可以作为为部门管理员，可以对其下的用户以及子部门进行权限设置和管理。例如，部门租户可以创建用户、管理用户、设置所述用户在所述虚拟企业云中的权限、设定其他安全规则。
本申请实施例中，企业租户创建多个VEC，所述多个VEC之间相互独立，VEC内服务可控。可以使得企业拥有自己独立的、完整的、安全合规的、服务可控的、无需维护的虚拟企业云，同时享有按需购买、弹性伸缩的敏捷性。并可以根据企业信息的重要性、敏感性和安全性设定不同的安全等级，保证企业。同时，企业内的部门甚至是普通员工可以具有较高的资源自主把控能力和资源灵活使用的能力。
可选地，在一些实施例中，一个企业租户ET在企业内可以有多个组织，组织可以指定部门间的从属关系(层级关系)，部门租户可以对其下属的用户以及子部门进行权限设置和管理。
可选地，创建的多个VEC可以是给组织内的多个租户使用(一个组织内可以包括多个租户，例如，可以包括多个部门租户)，因此，ET在向UI发送创建VEC请求时，需要指定组织标识ID(organization-identity，Org-ID)。
本申请实施例中在云服务上创建的虚拟企业云VEC，其本身定义为云，云之间都是独立不互联的，因此，默认情况下VEC之间的资源不能互通、共享。
应理解，默认情况下，同一企业租户创建的不同VEC之间的资源不能互通、共享，不同企业租户创建的VEC之间的资源也不能互通、共享，VEC和外部非企业VEC的部分(除VEC外剩余的部分)之间的资源也不能互通、共享。
可选地，在一些实施例中，如果企业内由于业务需求需要实现VEC间的互联互通(也可以理解为在两个VEC之间取得信任，建立“云联邦”或“联邦云”)，联邦云之间可以共享或互通资源，本申请实施例中企业租户(作为企业管理员)可以具有设置VEC之间的互联互通策略的能力。联盟的VEC(联邦云)可以在企业租户授权且云平台具备能力的情况下共享资源，而非联盟的VEC之间系统默认资源禁止互联互通。
应理解，建立联邦云的两个VEC可以是同一个企业租户，也可以是跨企业租户，本申请对此不做具体限定。
还应理解，云联盟可以是两个VEC之间相互取得信任，该两个VEC之间的资源可以互通和/或共享，但是云联盟的关系不传递。作为一个示例，VEC1与VEC2为云联盟(VEC1与VEC2之间的资源可以互通和/或共享)，VEC2与VEC3为云联盟(VEC2与VEC3之间的资源可以互通和/或共享)，但是VEC1与VEC3之间不属于云联盟(也就是说，VEC1与VEC3之间的资源可以互通和/或共享)。如果VEC1与VEC3之间的资源需要进行互通和/或共享，需要在VEC1与VEC3之间建立联盟关系。
作为一个示例，如果企业租户(作为企业管理员)设定两个VEC为联邦云(即，两个VEC之间的资源可以互联互通)，则管理系统允许对应的两个VEC之间的资源进行互联或互通，并按照云服务上已有的租户内或租户间对应服务的资源共享和/或互通的正常流程进行处理。作为另一个示例，如果企业租户(作为企业管理员)未设定两个VEC之间的联盟关系，则可以默认为VEC之间是相互独立的，即VEC之间的资源不可以互联互通。
应理解，企业租户ET作为管理员不仅可以设定创建的VEC间资源的联盟关系，还可以定企业内各VEC与其他企业VEC、外部普通租户之间的互联互通的关系。
还应理解，联邦云内的两个租户的资源是否可以共享和/或互通，还取决于目标租户是否同意进行资源共享和/或互通。作为一个示例，如果租户共享资源给所有人，联邦云内的其他租户都可以共享，否则仅是指定的租户可以进行资源共享。
需要说明的是，本申请实施例中VEC间的互联互通联盟策略(同一企业租户创建的不同VEC之间的资源不能互通、共享，不同企业租户创建的VEC之间的资源也不能互通、共享，VEC和外部非企业VEC的部分(除VEC外剩余的部分)之间的资源也不能互通、共享)。企业租户可以根据企业的业务需求，对创建的任意VEC设定互联互通联盟策略，本申请实施例对可以联盟的VEC不做具体限定。
可选地，在一些实施例中，企业租户(作为企业管理员)还可以在VEC之间互联互通策略的基础上，还可以设定一些其他更细化的安全规则。作为一个示例，企业租户可以设定互联互通的VEC之间仅网络服务资源可以互通。作为另一个示例，企业租户可以设定互联互通的VEC之间仅指定资源可以互通、访问，本申请对此不做具体限定。
可选地，在一些实施例中，企业租户在底层云服务上创建多个虚拟企业云后还可以为该虚拟企业云开通服务，允许租户在该虚拟企业云上使用哪些服务，可用的计费模式、默认的租户资源配额、VEC生效的区域region等运营该多个虚拟企业云所需要的信息。
应理解，region选定基于底层云服务开通的region，选定后加入该虚拟企业云的其他租户只能选择企业租户所指定的region使用云服务。region可动态增加，删除region时需要将VEC内的资源全部释放。
下面结合具体的例子，更加详细地描述本申请实施例中的企业租户(企业租户管理员)创建VEC并设定安全规则(包括设定VEC之间的联盟规则)的具体实现方式。应注意，图3的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申 请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据所给出的图3的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图3是图2中的步骤210的一种可能的实现方式的示意性流程图。图3的方法可以包括步骤310-370，下面分别对步骤310-370进行详细描述。
应理解，图3所示的管理系统可以对应于上文中的管理平台(即，对应于图1中的管理系统110)。
步骤310中，企业租户ET向用户界面(user interface，UI)发送创建虚拟企业云VEC请求。
ET作为企业管理员，可以创建多个VEC，ET可以向UI发送创建VEC请求。
步骤315中，UI向管理系统发送创建VEC请求(create VEC)。
UI可以将ET发送的创建VEC请求发送至管理系统。
步骤320中，管理系统保存VEC信息。
管理系统可以在接收到UI发送的创建VEC请求之后，可以保存VEC的信息。
步骤325中，ET向UI发送添加VEC区域的请求。
可选地，ET可以在创建好VEC之后，可以为VEC添加区域(region)。
应理解，区域region可以是VEC资源在地域上的划分，用户可以就近接入，例如，可以将VEC划分为华南、华北等区域。
VEC添加的区域与云服务上的区域之间可以是一一对应的关系，也可以在VEC映射出多个虚拟的区域，本申请对此不做具体限定。
VEC可以跨区域，也可以不跨区域。作为一个示例，如果VEC不跨区域，则VEC仅在该区域内有效。
步骤330中，UI向管理系统发送添加VEC区域请求(add region VEC(VEC-ID，region))。
UI可以在接收到ET发送的添加VEC区域请求之后，可以将该请求发送至管理系统。由于管理系统中保存了多个VEC信息，因此，UI可以在向管理系统发送add region VEC时，可以指定VEC-ID。
步骤335中，管理系统添加区域账号(create region account)。
管理系统可以在接收到UI发送的添加VEC区域请求之后，可以添加租户在该区域(region)的本地租户账号(也可以称为本地子账号)。添加的该本地租户账号可以为该租户在指定的region内的关联账号，与其他region无关。
应理解，本申请实施例中VEC内添加的每个region可以由多个本地租户账号，但该多个本地租户账号均属于一个全局账号。
作为一个示例，管理系统可以在云平台(Open Stack)中创建project，可以通过创建的project实现region与本地租户账号之间的映射关系。下面会结合图6对基于Open Stack中已有的project和domain对创建VEC以及本地租户账号的具体实现方式进行详细描述，此处不再赘述。
应理解，Open Stack可以是一个云计算的管理平台，可以对数据中心的计算、存储、网络资源进行统一管理。
步骤340中，管理系统保存VEC和region及其本地账号的关联映射关系。
管理系统可以保存VEC与region以及region内添加的本地租户账号之间的映射关系。例如，VEC-1可以包括region-1、region-2等，region-1中可以有本地租户账号-1、本地租户账号-2等。
步骤345中，ET向UI发送设置企业云可用服务列表请求(service-list)。
ET可以在创建好VEC之后，可以指定每个VEC在各个region内可用的服务列表和/或禁用的服务列表。
作为一个示例，ET作为管理员可以指定VEC-1上的租户可以使用的服务列表。例如，VEC-1上的租户可以使用的服务有：云服务器(elastic compute service，ECS)、虚拟私有云(virtual private cloud，VPC)、IP多媒体系统(IP multimedia subsystem，IMS)、关系型数据库服务(relational database service，RDS)等。VEC-1上的租户可以在上述授权的服务内具有对资源进行创建、销毁、更改、或其他处置的权限。
作为另一个示例，ET作为管理员可以指定VEC-1的租户禁止使用的服务列表，例如，VEC-1上的租户禁止使用的服务有：企业信息门户(enterprise information portal，EIP)、对象存储服务(object storage service，OBS)等。VEC-1上的租户没有权限在上述租户禁止使用的服务内对资源进行创建、销毁、更改、或其他处置等。
步骤350中，UI向管理系统发送设置VEC服务列表请求(set VEC service-list(VEC-ID，region，service-list))。
UI可以在接收到ET发送的设置企业云可用服务列表请求之后，可以将该请求发送至管理系统，该请求可以包括对每个VEC在各个region内设置可用的服务列表和/或禁用的服务列表。
步骤355中，管理系统保存每个VEC在各个region内可用的服务列表。
管理系统可以在接收到UI发送的设置VEC服务列表请求之后，可以将每个VEC在各个region内可用的服务列表和/或禁用的服务列表，以便于对租户、资源、操作的权限进行鉴定和授予。
可选地，在一些实施例中，ET作为管理员还需要指定租户可访问的服务的某些特性。
步骤360中，ET向UI发送设定VEC联盟请求(trust-VEC-list)。
ET创建的VEC本身定义为云，一般情况下，默认云之间是不能直接互通的，更不能直接共享使用镜像等非网络资源。
可选地，在一些实施例中，如果企业在VEC间有互联互通的需求(期望VEC间可以共享资源)，本申请实施例中ET作为管理员可以设定VEC间可以互联互通的关系(VEC联盟)。其中设定联盟的VEC之间的资源可以在企业租户授权且云平台具备能力的情况下可以直接互联互通，而非联盟的VEC之间的资源默认无法访问。
企业租户可以根据企业的业务需求，对创建的任意VEC设定互联互通联盟策略，本申请实施例对可以联盟的VEC不做具体限定。下面示出本申请实施例中一种可能的ET指定的VEC之间的联盟关系，如表1所示。
表1 VEC间资源联盟关系表
  VEC1 VEC2 PC
VEC1 True False False
VEC2 False True False
PC False False True
应理解，如果企业内由于业务需求需要实现VEC间的互联互通，ET作为管理员不仅需要设定VEC间的联盟关系，还需要指定企业内各VEC与其他企业VEC、外部普通租户(例如，表1中所示的(public cloud，PC))之间的互联互通的关系。
还应理解，PC也就是非本企业租户定义VEC外的部分，VEC1、VEC2可以理解为ET通过UI创建的两个虚拟企业云。
参见表1，False可以表示非联盟关系，也就是说，当某行某列的联盟关系为False时，租户在请求该行和该列的资源进行互联时，管理系统将直接阻断对应行和列的资源互联请求。作为一个示例，VEC1中的第一租户请求与VEC2中的第二租户的资源进行互联互通时，如果VEC1与VEC2之间的联盟关系为False，管理系统将直接阻断第一租户在VEC1中的资源与第二租户在VEC2中的资源之间进行互联互通的请求。
可选地，在一些实施例中，VEC1中的第一租户请求与VEC2中的第二租户的资源进行互联互通时，如果VEC1与VEC2之间的联盟关系为False，管理平台可以根据记录的VEC之间的联盟关系进行进行审批，确定是否允许第一租户在VEC1中的资源与第二租户在VEC2中的资源之间进行互联互通(如果VEC1与VEC2之间的关系为非联盟，则管理系统禁止第一租户在VEC1中的资源与第二租户在VEC2中的资源之间进行互联互通)。
True可以表示联盟关系，也就是说，当某行某列的联盟关系为True时，租户在请求该行和该列的资源进行互联时，管理系统可以将对应行和列的资源互联请求按照租户间对应服务的资源共享或互通流程进行(管理系统允许其对应行和列的资源互联请求)。作为一个示例，第一租户在VEC1中的资源请求与第二租户在VEC2中的资源之间进行互联互通时，如果VEC1与VEC2之间的联盟关系为True，管理系统可以将按照底层云服务上已有的第一租户与第二租户对应服务的资源共享或互通的正常流程进行处理，可以允许第一租户在VEC1中的资源与第二租户在VEC2中的资源之间进行互联互通。
应理解，为了便于描述，以表1所示的VEC间的联盟关系作为示例，也就是说，表1中系统默认同一个VEC可以互联互通(例如，VEC1与VEC1之间的联盟关系为True，VEC2与VEC2之间的联盟关系为True)。但是，表1中所示的设定值为默认值，ET作为管理员可以根据企业的实际需求，对该表1中的默认值进行修改。
步骤365，UI向管理系统发送设定VEC联盟请求(trust-VEC-list)。
步骤370，管理系统保存VEC联盟关系。
步骤375，ET向UI发送设置其他安全规则请求。
可选地，在一些实施例中，ET作为管理员还可以对安全规则进行进一步的细化设置。作为一个示例，该ET可以向UI发送设置仅网络可互通的安全规则。作为另一个示例，该ET还可以向UI发送设置仅指定资源可访问的安全规则。具体的对安全规则的进一步细化，ET可以根据企业的组织架构以及信息安全等级进行设置，本申请实施例不做具体限定。
步骤380，UI向管理系统发送设置其他安全规则请求(set VEC security policy(VEC-ID，policy-list))。
可选地，在一些实施例中，当ET作为管理员需要对安全规则进行进一步的细化设置时，UI可以向管理系统发送设置其他安全规则请求。该请求需要指定VEC-ID，也就是说，UI需要向管理系统请求对哪个VEC设定其他的安全规则(security policy)。
本申请实施例中，企业租户创建多个VEC，所述多个VEC之间相互独立，VEC内服务可控。可以使得企业在内拥有自己独立的、完整的、服务可控的、安全合规的、无需维护的虚拟企业云。可以根据企业信息的重要性、敏感性和安全性设定不同的安全等级，可以保证企业仍然能够根据信息的重要性或敏感性对资源进行访问控制。同时，企业内的部门甚至是普通员工可以具有较高的资源自主把控能力和资源灵活使用的能力。
应理解，企业内租户、部门之间是隔离的，仅在相同企业云、联盟云内，对方租户同意的情况下才可以实现互联互通。这一点在企业云和底层云上是一致的，不因企业云是虚拟的而发生变化。
本申请实施例中企业租户ET可以在创建完VEC之后，租户可以加入到创建的多个VEC中。
下面结合图4，以加入VEC的租户为部门租户作为一个示例，描述将部门租户(department tenant，DT)加入到VEC的两种具体的实现方式。应注意，图4的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据所给出的图4的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图4是图2中的步骤220的一种可能的实现方式的示意性流程图。图4的方法可以包括步骤410-445，下面分别对步骤410-445进行详细描述。
应理解，图4所示的管理系统可以对应于上文中的管理平台(即，对应于图1中的管理系统110)。
本申请实施例中部门租户DT可以选定需要访问和使用的VEC，作为一个示例，DT在加入企业之后，可以选定需要访问和使用的VEC。作为另一个示例，ET可以指定DT需要访问和使用的VEC。下面结合步骤410-415，对上述两种实现方式进行描述。
步骤410，DT向UI发送选定要用的VEC请求(VEC-list)。
情况一：DT可以向UI发送需要访问或使用的ET作为管理员所创建的VEC或VEC列表。
步骤415，ET向UI发送指定DT可用的VEC请求(VEC-list)。
情况二：ET可以在邀请或准许DT加入到VEC时，可以指定DT允许或需要访问的VEC或VEC列表。
步骤420，UI向管理系统发送添加DT可用的VEC请求(attach department(VEC-list))。
UI可以在收到DT或ET发送的DT允许或需要访问的VEC或VEC列表之后，可以将该VEC列表发送至管理系统。
步骤425，管理系统记录DT可用的VEC列表。
管理系统可以在收到UI发送的DT可用的VEC或VEC列表之后，可以记录DT可用的VEC列表。
应理解，管理系统可以在记录DT可用的VEC列表之后，如果DT想要访问某个VEC内的资源，管理系统可以根据保存的DT可用的VEC列表，确定该DT是否有权限访问想要访问的VEC。如果该DT没有权限访问想要访问的VEC，管理系统可以阻断获取VEC内资源的请求。可以实现信息、资源不跨VEC流动，从而可以避免信息泄露的问题。
步骤430，管理系统发现添加的DT拥有已存在的资源。
可选地，在一些实施例中，管理系统可以在记录DT可用的VEC列表之后，可以检查添加的该DT是否有已存在的资源。如果管理系统发现添加的DT拥有已存在的资源，且该已存在的资源未归属到任何ET创建的VEC内，DT可以将该存在的资源迁移至创建的VEC内。
步骤435，DT向UI发送已有资源迁移至VEC请求(VEC-ID，region-account)。
如果DT拥有的已存在的资源未归属到任何ET创建的VEC内，DT可以向UI发送已有资源迁移至VEC的请求。
作为一个示例，DT可以已存在的资源以租户在区域内的本地账号(region-account)为单位迁移至指定VEC内。
应立即，本地账号可以如前文所述，可以通过在Open Stack中创建project来实现。
步骤440，UI向管理系统发送移动至VEC请求(migrate to VEC(VEC-ID，region-account))。
UI可以在接收到DT发送的已有资源迁移至VEC的请求之后，可以将该请求发送至管理系统。该请求可以包括虚拟企业云ID(VEC-ID)以及区域内的本地账号(region-account)。
步骤445，管理系统记录区域内的本地账号与VEC的关联关系。
管理系统可以在收到UI发送的以区域内的本地账号为单位，将已有资源迁移至指定的虚拟企业(VEC-ID)之后，可以保存区域内的本地账号与VEC的关联关系。
本申请实施例中，企业租户可以创建VEC，并可以根据企业组织架构以及其信息安全等级划分不同的通信域。可以保证企业能够根据信息的重要性或敏感性对资源进行访问控制。可以达到企业各部门、各员工之间既可以自由分配、使用各VEC内的资源，又可以达到资源、信息不跨VEC流动，从而避免信息泄露等问题。
上文介绍了本申请实施例中企业租户ET作为企业管理员，如何创建多个VEC并设定VEC之间的安全规则的具体实现方式。下面通过图5介绍本申请实施例中创建的虚拟企业云VEC的模型的一种可能的实现方式。
应注意，图5的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要 将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据所给出的图5的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图5是本申请实施例提供的一种创建的VEC模型的示意性结构图。
参见图5，企业租户ET作为企业管理员，该ET的权限可以包括但不限于：创建VEC、设置VEC内可用和/或禁用的服务列表、制定VEC之间的互联互通策略、制定与VEC外部(例如，普通租户、其他企业的VEC)之间的互联互通策略、实施企业预算制度、对企业费用进行结算和/或分析。
下面结合图5对企业租户ET的权限进行一一说明。
作为一个示例，企业租户ET可以申请在底层云服务上创建多个VEC，例如，黄云、绿云、蓝云。可以根据信息等级(或其他目的)强制划分安全域，从而达到信息、资源不跨VCE流动。
作为另一个示例，该企业租户ET可以指定租户需要使用和访问的VEC。例如，企业租户、租户1、租户2可以访问和使用黄云中的服务和资源，并可以自由的在黄云上的资源进行创建、销毁、更改或其他处置等。而租户3没有权限访问和使用黄云中的服务和资源。
应理解，企业租户可以将部门添加至创建的多个VEC(例如，黄云、绿云、蓝云)中的多个。参见图5，可以将租户1添加至所有创建的VEC(例如，黄云、绿云、蓝云)中，可以将租户3添加至创建的部门VEC中(例如，绿云、蓝云)。
可选地，作为另一个示例，企业租户ET还可以设置VEC上的租户可以使用的服务列表和/或禁用服务列表。例如，对于创建的黄云而言，该黄云上的可用服务列表为：ECS、VPC、IMS、RDS，禁用服务列表为：EIP、OBS。可以访问和使用黄云的企业租户、租户1、租户2仅可以访问和使用黄云上的可用服务列表，而无权访问和使用黄云上的禁用服务列表。
可选地，作为另一个示例，企业租户ET可以根据不同企业的实际情况在不同虚拟企业云VEC上制定以租户为控制单元的资源授权方式，可以是预算配额、按需自助等(基于底层云已有的基于租户的结算能力进行制定)。
可选地，作为另一个示例，企业租户ET还可以设置VEC之间的互联互通策略。作为一个示例，企业租户ET可以设置各个VEC之间、外部普通租户(例如，图5中的PC)之间的互联互通关系。
应理解，图5中的PC可以作为普通租户，是本企业租户ET所定义的VEC之外的部门。PC作为普通租户可以使用所有云服务，但是，在非授权的情况下，无法访问任意企业的资源(即，企业的资源可以包括但不限于：计算、存储、网络等)。
图5所示的租户在授权的VEC内可以拥有和普通租户在云服务上类似的权限。加入到VEC中的租户除了以下权限外，和普通租户的权限一样：无法改变租户本身和虚拟企业云关系、无法增加访问企业租户禁止的服务、无法更改企业租户指定的计费套餐、配额预算等企业租户设定的规则。
企业租户ET设定好安全策略之后，租户以及用户均需要强制遵守企业租户ET设定的安全策略。如果请求互联互通的两个资源属于不同的VEC，且企业租户指定VEC 之间隔离(也就是说，不同的VEC之间的资源不允许互联互通)，即使该两个资源属于同一个租户，管理系统也不允许该两个资源之间进行互联互通。下面会结合图7-9，对租户或雇员均需要遵守企业租户ET设定的安全策略的具体实现方式进行详细说明，此处不再赘述。
可选地，在一些实施例中，加入VEC中的租户具备租户的权限，该租户还可以在企业租户(企业管理员)设定的规则的基础上，进一步额外的设定一些安全规则。作为一个示例，加入VEC中的租户可以在企业租户设置安全规则之后，还可以额外设定VEC内禁止网络互通，其下挂的普通租户、用户账号均需要遵守该安全规则。
需要说明的是，企业租户禁止的，加入VEC中的租户不能开通。企业租户允许的，加入VEC中的租户可以禁止，也可以部分允许。企业租户作为企业管理员，需要遵守自己设定的安全规则。
本申请实施例中，企业租户制定安全策略非常简单、直观。企业租户作为企业管理员可以创建虚拟企业云并指定安全策略规则即可，管理系统会将所定义规则应用到加入到VEC中的租户，并可以自动生效企业租户所定义的规则。这样的设计更符合企业管理者自上而下，可以把握整体的诉求。
本申请实施例中，租户在所述多个虚拟企业云中具备完全管理允许的各种云服务和/或云资源的能力，可以避免现有技术中企业租户全权负责企业内所有部门的资源和安全管理。
本申请实施例中可以基于云平台(Open Stack)中已有的项目(project)概念实现在VEC上添加区域的本地租户账号。下面以图5中创建的VEC为实例，对通过project实现VEC的具体方式进行详细描述。
应理解，云服务上的租户可以有多个项目(Open Stack中的project)。该项目可以是资源的集合或容器，同时也可以具有对这些资源和租户的权限鉴别(其中，租户可以指定所属项目project之间的资源互通规则)。
图6是本申请实施例提供的一种通过project创建的VEC模型的示意性结构图。参见图6，一个企业租户可以可以有多个project(例如，项目1(project 1)、项目2(project 2)、项目3(project 3))。对应于企业可以有多个VEC(例如，本申请实施例中的黄云、绿云、蓝云)，可以通过项目1(project 1)、项目2(project 2)、项目3(project 3)实现图5所示中创建的VEC。
一个租户可以访问多个VEC资源，但是VEC之间的互联互通关系，每个企业可以根据其业务和安全级别进行定制。作为一个示例，参见图6中的租户3，租户3可以有权限访问project 2、project 3中的资源，但是没有权限访问project 1中的资源。project 2与project 3之间的资源即使属于同一个租户，由于project 2与project3不属于同一个VEC，project 2与project 3之间的资源默认不可以进行互联互通。VEC之间的互联互通关系可以由企业租户自由定制。
本申请实施例中，VEC可以基于Open Stack中已有的project实现，实现简单。企业、部门以及企业普通租户之间都可以保持相对独立，可以拥有独立而完整的使用资源的能力。
上文提及，企业租户在创建VEC，并设置安全访问策略之后，租户需要遵守企业 租户ET设定的安全策略。租户在开展业务时，管理系统可以根据设定好的安全规则允许或阻断租户的访问请求。下面会结合图7-9，以部门租户加入到VEC作为一个示例，并分别以网络域、计算域、存储域三种服务为例对部门租户DT需要遵守企业租户ET设定的安全策略进行详细描述。
需要说明的是，VEC可以提供的服务可以包括但不限于网络域、计算域、存储域三种服务。
下面以网络域提供的服务为例，更加详细地描述本申请实施例中的部门租户DT需要遵守企业租户ET设定的安全策略的具体实现方式。应注意，图7的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据所给出的图7的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图7是本申请实施例提供的一种租户遵守安全策略的示意性流程图。图7的方法可以包括步骤710-790，下面分别对步骤710-790进行详细描述。
本申请实施例中，部门租户DT1和部门租户DT2需要通过网络服务发起两个VPC之间的对等连接。
应理解，图7所示的管理系统可以对应于上文中的管理平台(即，对应于图1中的管理系统110)。
两个指定的VPC(VPC1、VPC2)可以属于不同的VEC内的两个不同的租户，也可以属于同一个VEC内的两个不同的租户。
本申请实施例以DT1为图6中的租户1，DT2为图6中的租户2。VPC1属于图6所示的租户1在黄云的项目1中的网络资源、VPC2属于租户2在黄云的项目1中的网络资源作为示例进行详细说明。也就是说，租户1请求其在黄云的项目1中的网络资源与租户2在黄云的项目1中的网络资源进行互联和/或互通。
步骤710，DT1向用户界面UI发送创建VPC1与VPC2的对等连接请求(DT1,VPC1@VEC1，DT2,VPC2@VEC1)。
DT1可以向UI发起两个指定的VPC(VPC1、VPC2)间的对等连接，也可以理解为DT1向UI请求两个指定的VPC云资源(租户1在黄云中的项目1和租户2在黄云中的项目1之间的资源)进行互联互通。
步骤720，UI向管理系统发送创建VPC与VPC2的对等连接请求(create VPC peering(DT1,VPC1，DT2,VPC2))。
UI可以在接收到DT1发送的创建VPC与VPC2的对等连接请求之后，可以将该请求发送至管理系统。
步骤730，管理系统查找VPC1和VPC2所属的VEC-ID。
管理系统可以在接收到UI发送的创建VPC与VPC2的对等连接请求之后，可以查找VPC1和VPC2所属的VEC-ID。作为一个示例，本申请实施例中VPC1和VPC2属于同一个VEC(图6所示的黄云)。
管理系统可以根据保存的VEC之间的联盟关系，确定VPC1和VPC2是否可以互通。作为一个示例，参见表1，本申请实施例的VEC之间的联盟关系为：同一个VEC允许互通，由于本申请实施例中VPC1和VPC2属于同一个VEC(图6所示的黄云)，因此， 本申请实施例中VPC1和VPC2是可以互通。也就是说，租户1在项目1中的资源与租户2在项目1中的资源可以进行互联和/或互通。
具体地，管理系统可以根据VPC-ID(例如，VPC1、VPC2)可以查找到VPC所处的区域region以及该region内的本地账号，管理系统可以根据该本地账号查找到对应的VEC-ID(例如，图6所示的黄云)。
应理解，上述VEC-ID可以是通用唯一标识码(universally unique identifier，UUID)，并且可以假定UUID不会重复。
可选地，在一些实施例中，如果VPC1和VPC2所属的VEC为普通租户PC，则管理系统查询到VPC1和VPC2所属的VEC为空，参见表1，其联盟关系可以对应为VEC与普通租户PC之间的互联互通策略。
步骤740，如果查询结果为VPC1和VPC2允许互通，管理系统保存对等连接，将状态设定为待接受。
管理系统可以在判定VPC1和VPC2之间允许互通之后，可以按照底层云服务已有的租户内或租户间对应的流程或方式进行处理(只要DT2同意，则该对等连接即建立成功)。管理系统可以保存该对等连接，并可以将该对等连接的状态设定为待连接。
步骤750，DT2向UI发送查看对等连接请求。
步骤760，UI向操作系统发送查看对等连接请求(query VPC peering)。
步骤770，DT2向UI发送同意建立对等连接请求。
步骤780，UI向操作系统发送建立对等连接请求(establish VPC peering(VPC1，VPC 2))。
UI可以在接收到DT2发送的同意建立对等连接请求之后，可以向操作系统发送请求建立VPC 1与VPC2之间的对等连接。
步骤790，操作系统更新状态为连接建立。
操作系统可以在接收到UI发送的建立VPC 1与VPC2之间的对等连接请求之后，可以将VPC 1与VPC2之间的状态更新为连接建立(租户1在黄云的项目1中的资源与租户2在黄云的项目1中的资源可以进行互联和/或互通)。
下面以计算域提供的服务为例，更加详细地描述本申请实施例中的部门租户DT需要遵守企业租户ET设定的安全策略的具体实现方式。应注意，图8的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据所给出的图8的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图8是本申请另一实施例提供的一种租户遵守安全策略的示意性流程图。图8的方法可以包括步骤810-855，下面分别对步骤810-855进行详细描述。
应理解，图8所示的管理系统可以对应于上文中的管理平台(即，对应于图1中的管理系统110)。
本申请实施例中，部门租户DT1和部门租户DT2需要通过计算服务创建虚拟机VM。
应理解，DT2在创建VM的过程中，需要使用DT1共享的镜像资源。本申请实施例DT2在选择镜像资源时，可以有两种具体的情况，情况一：DT2可以通过控制台(console)选择可以使用的镜像；情况二：DT2可以直接通过应用程序编程接口(application  programming interface，API)指定需要使用的镜像ID。
DT1和DT2可以属于一个VEC，也可以属于不同的VEC。
本申请实施例以DT1为图6中的租户1，DT2为图6中的租户2，租户1在黄云中的资源集合为项目1，租户2在绿云中的资源集合为项目2作为示例进行说明。
本申请实施例中DT2在创建VM的过程中，需要使用DT1共享的镜像资源，可以理解为图6中的租户2想要请求在绿云中的项目2共享租户1在黄云的项目1中的镜像资源。
步骤810，DT1向用户界面UI发送共享镜像给所有人的请求。
DT1可以将所属的VEC1中的镜像(如图6中，租户1在黄云的项目1中的镜像资源)共享给VEC1中的所有用户(如图6中，租户1可以将黄云的项目1中的镜像资源共享给黄云中的其他租户使用)，该VEC1中的所有用户可以使用共享镜像来创建VM。
步骤815，UI向管理系统发送共享镜像给所有人的请求。
UI可以在接收到DT1发送的共享镜像给所有人的请求之后，可以将该请求转发至管理系统。
步骤820，管理系统设置镜像共享给所有人。
管理系可以在接收到UI发送的镜像给所有人的请求之后，可以将VEC1中的镜像共享给VEC1中的所有用户。
下面通过步骤825-840，详细描述情况一中的具体实现方式。
步骤825，DT2向UI发送创建VM请求。
步骤830，UI向管理系统发送查看镜像请求(query image(DT2，VEC1，region1))。
UI可以在接收到DT2发送的创建VM请求之后，可以向管理系统发送查看镜像请求，可以请求管理系统查看DT2在VEC1对应账号下的可用镜像列表(如图6中，租户2在项目1中可以用的镜像列表)。
步骤835，管理系统查找DT2在VEC1对应账号下的可用镜像列表。
管理系统可以在接收到UI发送的查看镜像请求之后，可以查看DT2在VEC1对应账号(如图6中，租户2在项目1)下的可用镜像列表，还可以查看与VEC1为联盟关系的其他VEC(可以与VEC1资源互联互通的VEC)对应账号下的共享的镜像。
步骤840，管理系统向DT2发送响应失败消息(response error(not exist))。
参见本申请实施例中的表1，本申请实施例的VEC之间的联盟关系为：同一个VEC允许互通，由于DT2和DT1属于不同的VEC(图6所示，DT1属于黄云，DT2属于绿云)，因此，DT2没有权限访问DT1所属的VEC1中共享的镜像。也就是说，如图6所示，租户2没有权限访问租户1在项目1中共享的镜像资源。
因此，管理系统可以向DT2发送响应失败消息。
下面通过步骤845-855，详细描述情况二的具体实现方式。
步骤845，DT2向管理系统发送创建VM请求(create VM(DT2，VEC1，region1，image-ID))。
DT2可以通过API向管理系统直接指定需要访问的镜像ID(image-ID)，管理系统可以根据镜像ID确定DT2是否有权限访问该镜像。
步骤850，管理系统确认DT2是否可访问指定的镜像ID。
管理系统可以在接收到DT2发送的指定要访问的镜像ID后，首先，管理系统可以确认DT2是否有权限访问指定的镜像ID(例如，该指定的镜像ID是否为DT2私有，该指定的镜像ID是否共享给DT2使用)。其次，管理系统可以根据镜像ID所述的VEC与DT2所属的VEC是否互通(联盟)。
由于指定的镜像ID属于VEC1(指定的镜像ID属于租户1在项目1中的镜像资源)，DT2和DT1属于不同的VEC(DT1为图6中的租户1，租户1在黄云中的资源集合为项目1；DT2为图6中的租户2，租户2在绿云中的资源集合为项目2)。参见表1，本申请实施例的VEC之间的联盟关系为：同一个VEC允许互通，不同的VEC不允许互通。因此，管理系统可以确认DT2无权限访问该指定的镜像ID。
步骤855，管理系统向DT2发送响应失败消息(response error(not exist))。
下面以存储域提供的服务为例，更加详细地描述本申请实施例中的部门租户DT需要遵守企业租户ET设定的安全策略的具体实现方式。应注意，图9的例子仅仅是为了帮助本领域技术人员理解本申请实施例，而非要将申请实施例限制于所示例的具体数值或具体场景。本领域技术人员根据所给出的图9的例子，显然可以进行各种等价的修改或变化，这样的修改和变化也落入本申请实施例的范围内。
图9是本申请另一实施例提供的一种租户遵守安全策略的示意性流程图。图9的方法可以包括步骤910-950，下面分别对步骤910-950进行详细描述。
应理解，图9所示的管理系统可以对应于上文中的管理平台(即，对应于图1中的管理系统110)。
本申请实施例中，部门租户DT1和部门租户DT2需要通过存储服务发起访问共享的OBS。
应理解，对象存储服务OBS可以作为一个基于对象的海量存储服务，能够存储任意类型和大小的数据，并可以在OBS中对存储的数据进行管理。
桶(bucket)可以作为OBS中存储对象的容器，用户上传至OBS的数据都可以保存在桶中，用户可以通过共享桶，从而可以共享存储在OBS中的数据。访问OBS属于数据面操作，该操作本身不带有租户信息，因此，可以在发起访问共享的同时管理系统确认发起者对应的租户信息。
步骤910，DT1向用户界面UI发送创建桶并共享桶至DT2的请求(VEC1，share，DT2)。
DT1(属于VEC1)可以创建桶，并可以向UI发送将创建的桶共享至DT2，可以使得DT2可以共享桶中存储的数据。
需要说明的是，DT2可能与DT1属于同一个VEC(例如，VEC1)，DT2也可能与DT1不属于同一个VEC。后面的步骤会分别对两种具体的情况进行说明。
步骤915，UI向管理系统发送创建桶请求(create bucket(VEC1，share，DT2))。
UI可以在接收到DT1发送的创建桶，并可以将创建的桶共享至DT2的请求之后，可以向管理系统发送创建桶请求。并可以通知管理系统DT1可以将创建的桶共享给DT2。
步骤920，管理系统设置桶共享给DT2。
管理系统可以在接收到UI发送的创建桶请求之后，可以将创建的桶设置给共享给DT2，可以使得DT2可以共享桶中存储的数据。
步骤925，DT2向UI发送在VEC1中访问桶请求(bucket，ak，sk)。
DT2可以向UI发送在VEC1中访问桶请求。
本申请实施例中DT2可能与DT1属于同一个VEC(例如，VEC1)，DT2也可能与DT1不属于同一个VEC。
步骤930，UI向管理系统发送DT2请求访问DT1中共享的桶(bucket，ak，sk)。
UI可以在接收到DT2发送的请求访问DT1中共享的桶之后，可以将该请求发送至管理系统。
下面会出现两种情况，情况一：DT2和DT1属于同一个VEC(VEC1)，也就是说，访问来源DT2所属的VEC与被访问桶所属的VEC相同。DT1为图6中的租户1，DT2为图6中的租户2，DT1和DT2均属于黄云，DT1在黄云中的资源为项目1，DT2在黄云中的资源为项目1。
情况二：DT2和DT1不属于同一个VEC(DT1属于VEC1、DT2属于VEC2)，也就是说，访问来源DT2所属的VEC与被访问桶所属的VEC不相同。DT1属于黄云，DT1在黄云中的资源为项目1，DT2属于绿云，DT2在绿云中的资源为项目2。
下面会结合步骤935-940对情况一中的具体实现方式进行详细描述。
步骤935，管理系统查看访问来源DT2所属的企业云为VEC1，被访问桶所属的企业云为VEC1，查询结果为允许访问。
管理系统可以在接收到UI发送的DT2请求访问DT1中共享的桶之后，可以查看访问来源DT2所属的VEC与被访问桶所属的VEC之间的联盟关系。
参见本申请实施例中的表1，本申请实施例的VEC之间的联盟关系为：同一个VEC允许互通，由于DT2和DT1属于相同的VEC(图6所示的黄云)，管理系统已设置将DT1创建的桶共享给DT2，因此，管理系统可以根据设定的互联互通规则，判定DT2允许访问DT1共享的桶中存储的数据。
也就是说，租户1在项目1中的资源与租户2在项目1中的资源可以进行互联和/或互通。
管理系统还可以在判定DT2允许访问DT1共享的桶中存储的数据之后，可以确认访问者租户DT2的访问密码(access key)。
步骤940，管理系统向DT2发送成功访问消息。
管理系统可以在查看判定DT2允许访问DT1共享的桶中存储的数据之后，可以向DT2发送成功访问消息。
下面结合步骤945-950对情况二进行详细描述。
步骤945，管理系统查看访问来源DT2所属的企业云为VEC2(图6所示的绿云)，被访问桶所属的企业云为VEC1(图6所示的黄云)。
参见本申请实施例中的表1，本申请实施例的VEC之间的联盟关系为：同一个VEC允许互通，由于DT2和DT1属于不同的VEC，因此，管理系统可以根据设定的互联互通规则，判定DT2禁止访问DT1共享的桶中存储的数据。
也就是说，如图6所示，租户2没有权限访问租户1在项目1中共享的镜像资源，租户1在项目1中的资源与租户2在项目2中的资源之间禁止进行互联和/或互通。
步骤950，管理系统向DT2发送访问失败消息。
管理系统可以在查看判定DT2禁止访问DT1共享的桶中存储的数据之后，可以向DT2发送访问失败消息。
本申请实施例中，VEC策略实现简单明了，如果禁止VEC之间的资源进行互通，则管理系统将直接阻断操作，如果允许VEC之间的资源进行互通，则管理系统将进行通用流程即可，可以达到资源、信息不跨VEC流动，从而避免信息泄露等问题。
上文结合图1至图9，详细描述了本申请实施例提供的企业云的创建方法，下面将结合图10至图11，详细描述本申请的装置实施例(管理平台)。应理解，方法实施例的描述与装置实施例的描述相互对应，因此，未详细描述的部分可以参见前面方法实施例。
图10是本申请实施例提供的一种管理平台1000的示意性框图，该管理平台1000可以包括处理模块1010、接收模块1020。
处理模块1010，用于创建多个虚拟企业云，所述多个虚拟企业云基于所述构建且用于提供云资源；
所述处理模块1010通过接收模块1020执行以下操作：根据所述第一指令将租户添加至至少一个虚拟企业云，所述至少一个虚拟企业云为所述多个虚拟企业云的部门或全部。
可选地，在一些实施例中，所述处理模块1010具体用于：
将所述租户的至少一个项目添加至所述至少一个虚拟企业云，每个项目包括所述租户在所述每个项目所属的虚拟企业云中允许访问的云资源。
可选地，在一些实施例中，所述处理模块1010还用于：
配置所述租户在所述至少一个项目中的访问权限，使得所述租户具备管理每个项目包括的云资源的能力。
可选地，在一些实施例中，所述接收模块1020还用于：接收第二指令，所述第二指令指示设置所述多个虚拟企业云之间的安全规则，所述安全规则用于表示所述多个虚拟企业云的云资源是否能够在所述多个虚拟企业云之间进行共享和/或互通；
所述处理模块1010还用于：记录所述安全规则。
可选地，在一些实施例中，所述接收模块1020还用于：接收第一请求，所述第一请求用于第一租户的第一项目向第二租户的第二项目发起资源共享和/或互通，其中，所述第一项目属于第一虚拟企业云，所述第二项目属于第二虚拟企业云；
所述处理模块1010还用于：根据记录的所述安全规则确定是否允许所述第一项目与所述第二项目之间的进行资源共享和/或互通。
可选地，在一些实施例中，所述处理模块1010具体用于：
如果所述安全规则允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，按照所述第一租户与所述第二租户之间对应服务的资源共享和/或互通流程，允许所述第一项目与所述第二项目之间进行资源共享和/或互通；
如果所述安全规则不允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，禁止所述第一项目与所述第二项目之间进行资源共享和/或互通。
应理解，根据本申请实施例的管理平台1000可用于执行本申请实施例图2-图9中的各个方法的相应流程，并且管理平台1000中的各个模块的上述和其它操作和/或 功能分别为了实现本申请实施例图2-图9中的各个方法的相应流程，为了简洁，在此不再赘述。
本申请实施例提供的管理平台，企业租户可以在云服务上创建多个VEC，所述多个VEC之间相互独立，VEC内服务可控。可以使得企业在云服务上拥有自己独立的、完整的、安全合规的、服务可控的、无需维护的虚拟企业云，同时享有按需购买、弹性伸缩的敏捷性。并可以根据企业信息的重要性、敏感性和安全性设定不同的安全等级，保证信息安全。同时，企业内的部门甚至是普通员工可以具有较高的自主把控资源和资源灵活使用的能力。
图11是本申请实施例提供的一种管理平台1100的示意性框图。
参见图11，该管理平台1100包括至少一个计算设备1110，每个计算设备1110都可以包括：通信接口1111、处理器1112、存储器1113。
可选地，每个计算设备1110还可以包括总线1114。其中，通信接口1111、处理器1112以及存储器1113可以通过总线1114相互连接；总线1114可以是外设部件互连标准(peripheral component interconnect，简称PCI)总线或扩展工业标准结构(extended industry standard architecture，简称EISA)总线等。所述总线1114可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。其中：
该存储器1113可以用于存储该管理平台的程序代码和数据。因此，该存储器1113可以是处理器1112内部的存储单元，也可以是与处理器1112独立的外部存储单元，还可以是包括处理器1112内部的存储单元和与处理器1112独立的外部存储单元的部件。
处理器1112可以由一个或者多个通用处理器构成，例如可以是中央处理器(central processing unit，CPU)，通用处理器，数字信号处理器(digital signal processor，DSP)，专用集成电路(application-specific integrated circuit，ASIC)，现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。所述处理器也可以是实现计算功能的组合，例如包含多个微处理器组合，DSP和微处理器的组合等等。处理器1112可用于运行相关的程序代码中处理功能的程序。也就是说，处理器1112执行程序代码可以实现处理模块的功能。其中，关于处理模块具体可参见前述实施例中的相关阐述。
应理解，处理器1112还可以是包括至少一台计算设备1110的处理器的集合，本申请对此不做具体限定。
在一种可能的实施方式中，所述至少一个计算设备1110的处理器共同用于运行相关的程序代码，以实现本申请上述处理模块的功能，或以实现本申请上述图2示出的步骤210-220中所述的方法，和/或实现本文所描述的技术的其它步骤等，本申请这里不做详述和限定。
在另一种可能的实施方式中，每个计算设备1110的处理器可单独用于运行相关的程序代码，以实现本申请上述处理模块的功能，或以实现本申请上述图2示出的步骤210-220中所述的方法，和/或实现本文所描述的技术的其它步骤等，本申请这里不做 详述和限定。
通信接口1111可以为有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口)，用于与其他模块/设备进行通信。例如，本申请实施例中通信接口具体可用于接收企业租户或租户发送的指令数据等。
存储器1113可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)；存储器也可以包括非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，ROM)、快闪存储器(flash memory)、硬盘(hard disk drive，HDD)或固态硬盘(solid-state drive，SSD)；存储器1113还可以包括上述种类的存储器的组合。存储器1113可用于存储一组程序代码，以便于处理器1112调用存储器1113中存储的程序代码以实现本发明实施例中涉及的通信模块和/或处理模块的功能。
当程序被执行时，处理器1112用于：创建多个虚拟企业云，所述多个虚拟企业云基于所述构建且用于提供云资源；
所述处理器1112通过通信接口1111执行以下操作：根据所述第一指令将租户添加至至少一个虚拟企业云，所述至少一个虚拟企业云为所述多个虚拟企业云的部门或全部。
可选地，在一些实施例中，所述处理器1112具体用于：
将所述租户的至少一个项目添加至所述至少一个虚拟企业云，每个项目包括所述租户在所述每个项目所属的虚拟企业云中允许访问的云资源。
可选地，在一些实施例中，所述处理器1112还用于：
配置所述租户在所述至少一个项目中的访问权限，使得所述租户具备管理每个项目包括的云资源的能力。
可选地，在一些实施例中，所述通信接口1111还用于：接收第二指令，所述第二指令指示设置所述多个虚拟企业云之间的安全规则，所述安全规则用于表示所述多个虚拟企业云的云资源是否能够在所述多个虚拟企业云之间进行共享和/或互通；
所述处理器1112还用于：记录所述安全规则。
可选地，在一些实施例中，所述通信接口1111还用于：接收第一请求，所述第一请求用于第一租户的第一项目向第二租户的第二项目发起资源共享和/或互通，其中，所述第一项目属于第一虚拟企业云，所述第二项目属于第二虚拟企业云；
所述处理器1112还用于：根据记录的所述安全规则确定是否允许所述第一项目与所述第二项目之间的进行资源共享和/或互通。
可选地，在一些实施例中，所述处理器1112具体用于：
如果所述安全规则允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，按照所述第一租户与所述第二租户之间对应服务的资源共享和/或互通流程，允许所述第一项目与所述第二项目之间进行资源共享和/或互通；
如果所述安全规则不允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，禁止所述第一项目与所述第二项目之间进行资源共享和/或互通。
本申请实施例提供的管理平台，企业租户可以创建多个VEC，所述多个VEC之间相互独立，VEC内服务可控。可以使得企业在云服务上拥有自己独立的、完整的、安 全合规的、服务可控的、无需维护的虚拟企业云，同时享有按需购买、弹性伸缩的敏捷性。并可以根据企业信息的重要性、敏感性和安全性设定不同的安全等级，保证信息安全。同时，企业内的部门甚至是普通员工可以具有较高的自主把控资源和资源灵活使用的能力。
可选地，本申请实施例还提供了一种计算机可读介质，所述计算机可读介质存储有程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。
可选地，本申请实施例还提供了一种芯片，包括存储器、处理器和收发器，所述芯片可以用于执行步骤210-220中所述的方法和/或实现本文所描述的技术的其它步骤等。
具体地，所述存储器用于存储程序；
所述处理器可以与收发器通信连接。所述存储器可以用于存储所述终端设备的程序代码和数据。因此，所述存储器可以是处理器内部的存储单元，也可以是与处理器独立的外部存储单元，还可以是包括处理器内部的存储单元和与处理器独立的外部存储单元的部件。
可选地，所述处理器可以是通用处理器，可以通过硬件来实现也可以通过软件来实现。当通过硬件实现时，所述处理器可以是逻辑电路、集成电路等；当通过软件来实现时，所述处理器可以是一个通用处理器，通过读取存储器中存储的软件代码来实现，所述存储器可以集成在处理器中，可以位于所述处理器之外，独立存在。
可选地，本申请实施例还提供了一种计算机程序产品，所述计算机程序产品包括：计算机程序代码，当所述计算机程序代码在计算机上运行时，使得计算机执行上述各方面中的方法。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请中使用的术语“部件”、“模块”、“系统”等用于表示计算机相关的实体、硬件、固件、硬件和软件的组合、软件、或执行中的软件。例如，部件可以是但不限于，在处理器上运行的进程、处理器、对象、可执行文件、执行线程、程序和/或计算机。通过图示，在计算设备上运行的应用和计算设备都可以是部件。一个或多个部件可驻留在进程和/或执行线程中，部件可位于一个计算机上和/或分布在2个或更多个计算机之间。此外，这些部件可从在上面存储有各种数据结构的各种计算机可读介质执行。部件可根据具有一个或多个数据分组(例如来自与本地系统、分布式系统和/或网络间的另一部件交互的二个部件的数据，例如通过信号与其它系统交互的互联网)的信号通过本地和/或远程进程来通信。
还应理解，在本申请的各实施例中，“第一”、“第二”、“第三”等仅是为了指代不同的对象，并不表示对指代的对象有其它限定。
另外，本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和 /或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (14)

  1. 一种企业云的创建方法，其特征在于，所述方法包括：
    管理平台创建多个虚拟企业云，所述多个虚拟企业云基于云服务构建且用于提供云资源；
    所述管理平台接收第一指令，根据所述第一指令指示将租户添加至至少一个虚拟企业云，所述至少一个虚拟企业云为所述多个虚拟企业云的部分或者全部。
  2. 根据权利要求1所述的方法，其特征在于，所述管理平台接收第一指令，根据所述第一指令指示将租户添加至至少一个虚拟企业云，包括：
    所述管理平台将所述租户的至少一个项目添加至所述至少一个虚拟企业云，每个项目包括所述租户在所述每个项目所属的虚拟企业云中允许访问的云资源。
  3. 根据权利要求2所述的方法，其特征在于，所述方法还包括：
    所述管理平台配置所述租户在所述至少一个项目中的访问权限，使得所述租户具备管理每个项目包括的云资源的能力。
  4. 根据权利要求1至3中任一项所述的方法，其特征在于，所述方法还包括：
    所述管理平台接收第二指令，所述第二指令指示设置所述多个虚拟企业云之间的安全规则，所述安全规则用于表示所述多个虚拟企业云的云资源是否能够在所述多个虚拟企业云之间进行共享和/或互通；
    所述管理平台记录所述安全规则。
  5. 根据权利要求4所述的方法，其特征在于，所述方法还包括：
    所述管理平台接收第一请求，所述第一请求用于第一租户的第一项目向第二租户的第二项目发起资源共享和/或互通，其中，所述第一项目属于第一虚拟企业云，所述第二项目属于第二虚拟企业云；
    所述管理平台根据记录的所述安全规则确定是否允许所述第一项目与所述第二项目之间的进行资源共享和/或互通。
  6. 根据权利要求5所述的方法，其特征在于，所述管理平台根据记录的所述安全规则确定是否允许所述第一项目与所述第二项目之间的进行资源共享和/或互通，包括：
    如果所述安全规则允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，所述管理平台按照所述第一租户与所述第二租户之间对应服务的资源共享和/或互通流程，允许所述第一项目与所述第二项目之间进行资源共享和/或互通；
    如果所述安全规则不允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，所述管理平台禁止所述第一项目与所述第二项目之间进行资源共享和/或互通。
  7. 一种管理平台，其特征在于，所述管理平台包括处理模块和接收模块：
    所述处理模块，用于创建多个虚拟企业云，所述多个虚拟企业云基于所述构建且用于提供云资源；
    所述处理模块通过所述接收模块执行以下操作：根据所述第一指令将租户添加至至少一个虚拟企业云，所述至少一个虚拟企业云为所述多个虚拟企业云的部门或全部。
  8. 根据权利要求7所述的管理平台，其特征在于，所述处理模块具体用于：
    将所述租户的至少一个项目添加至所述至少一个虚拟企业云，每个项目包括所述 租户在所述每个项目所属的虚拟企业云中允许访问的云资源。
  9. 根据权利要求8所述的管理平台，其特征在于，所述处理模块还用于：
    配置所述租户在所述至少一个项目中的访问权限，使得所述租户具备管理每个项目包括的云资源的能力。
  10. 根据权利要求7至9中任一项所述的管理平台，其特征在于，所述接收模块还用于：接收第二指令，所述第二指令指示设置所述多个虚拟企业云之间的安全规则，所述安全规则用于表示所述多个虚拟企业云的云资源是否能够在所述多个虚拟企业云之间进行共享和/或互通；
    所述处理模块还用于：记录所述安全规则。
  11. 根据权利要求10所述的管理平台，其特征在于，所述接收模块还用于：接收第一请求，所述第一请求用于第一租户的第一项目向第二租户的第二项目发起资源共享和/或互通，其中，所述第一项目属于第一虚拟企业云，所述第二项目属于第二虚拟企业云；
    所述处理模块还用于：根据记录的所述安全规则确定是否允许所述第一项目与所述第二项目之间的进行资源共享和/或互通。
  12. 根据权利要求11所述的管理平台，其特征在于，所述处理模块具体用于：
    如果所述安全规则允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，按照所述第一租户与所述第二租户之间对应服务的资源共享和/或互通流程，允许所述第一项目与所述第二项目之间进行资源共享和/或互通；
    如果所述安全规则不允许所述第一虚拟企业云和所述第二虚拟企业云之间进行资源共享和/或互通，禁止所述第一项目与所述第二项目之间进行资源共享和/或互通。
  13. 一种管理平台，其特征在于，所述管理平台包括至少一台计算设备，每个计算设备包括存储器和处理器，
    所述处理器用于执行所述存储器中存储的程序以执行如1至6中任一项所述的方法。
  14. 一种计算机非瞬态存储介质，所述计算机非瞬态存储介质存储有计算机程序，其特征在于，当所述计算机程序被计算设备执行时实现如权利要求1至6中任一项所述的方法。
PCT/CN2019/087890 2018-07-25 2019-05-22 一种企业云的创建方法和管理平台 WO2020019839A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201810825954.4 2018-07-25
CN201810825954.4A CN109117650B (zh) 2018-07-25 2018-07-25 一种企业云的创建方法和管理平台

Publications (1)

Publication Number Publication Date
WO2020019839A1 true WO2020019839A1 (zh) 2020-01-30

Family

ID=64863159

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/087890 WO2020019839A1 (zh) 2018-07-25 2019-05-22 一种企业云的创建方法和管理平台

Country Status (2)

Country Link
CN (1) CN109117650B (zh)
WO (1) WO2020019839A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111832879A (zh) * 2020-04-15 2020-10-27 中国人民解放军军事科学院战争研究院 一种开放式企业级信息系统的信息资源共享与授权方法
CN113472745A (zh) * 2021-05-31 2021-10-01 山东英信计算机技术有限公司 一种基于selinux的openstack公有云多租户隔离方法、系统及终端
WO2022001376A1 (zh) * 2020-06-29 2022-01-06 华为技术有限公司 一种云服务的资源发放方法及相关设备
CN115801833A (zh) * 2022-11-16 2023-03-14 浙江九州云信息科技有限公司 一种企业级公有云资源管理方法及系统
CN116167029A (zh) * 2023-04-23 2023-05-26 汕头市林百欣科学技术中等专业学校 一种基于云计算的计算机系统账户管理方法
WO2023138032A1 (zh) * 2022-01-24 2023-07-27 华为云计算技术有限公司 一种地址空间推荐方法、装置及相关设备

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109117650B (zh) * 2018-07-25 2022-03-18 华为云计算技术有限公司 一种企业云的创建方法和管理平台
CN110009311A (zh) * 2019-04-12 2019-07-12 广东电网有限责任公司信息中心 一种面向电网企业的私有云租户管理方法
CN111309592B (zh) * 2020-01-14 2023-09-19 杭州未名信科科技有限公司 一种权限检查方法、装置、存储介质及终端
CN111597011A (zh) * 2020-04-10 2020-08-28 联通(广东)产业互联网有限公司 一种基于私有云资源模型的连接方法和系统
CN113965505A (zh) * 2021-09-27 2022-01-21 浪潮云信息技术股份公司 不同虚拟私有网络之间云主机互通的方法及实现架构
CN114004585A (zh) * 2021-10-22 2022-02-01 国网重庆市电力公司电力科学研究院 一种电力用户数据管理系统
CN116266839A (zh) * 2021-12-16 2023-06-20 华为云计算技术有限公司 一种对象存储桶的数据访问方法以及云管理平台
CN113947391B (zh) * 2021-12-20 2022-04-08 深圳市明源云采购科技有限公司 基于web的采招系统管理方法、装置、设备及存储介质
WO2023168970A1 (zh) * 2022-03-10 2023-09-14 华为云计算技术有限公司 一种区块链网络的管理方法及相关设备
CN114827275B (zh) * 2022-04-15 2024-03-22 星环信息科技(上海)股份有限公司 一种联邦租户的管理平台和联邦租户的资源管理方法
CN115442236A (zh) * 2022-08-12 2022-12-06 浪潮云信息技术股份公司 一种混合云下虚拟云中心的运营方法
WO2024037224A1 (zh) * 2022-08-15 2024-02-22 华为云计算技术有限公司 一种基于云计算技术的云资源访问控制方法及云管理平台
CN115514634A (zh) * 2022-09-07 2022-12-23 上海浪潮云计算服务有限公司 云中心的管理方法和装置
CN116566844B (zh) * 2023-07-06 2023-09-05 湖南马栏山视频先进技术研究院有限公司 一种基于多云融合的数据管控方法与多云融合管理平台
CN117057891A (zh) * 2023-10-11 2023-11-14 大唐融合通信股份有限公司 一种多租户体系的运营方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150052525A1 (en) * 2013-08-13 2015-02-19 Vmware, Inc. Virtual private networks distributed across multiple cloud-computing facilities
CN104954333A (zh) * 2014-03-28 2015-09-30 华为技术有限公司 一种转发报文的方法、系统
CN105591863A (zh) * 2014-10-20 2016-05-18 中兴通讯股份有限公司 一种实现虚拟私有云网络与外部网络互通的方法和装置
CN105721306A (zh) * 2016-02-04 2016-06-29 杭州数梦工场科技有限公司 一种配置信息的传输方法和装置
CN109117650A (zh) * 2018-07-25 2019-01-01 华为技术有限公司 一种企业云的创建方法和管理平台

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102307185B (zh) * 2011-06-27 2015-02-25 北京大学 适用于存储云内的数据隔离方法
CN105049409A (zh) * 2015-05-28 2015-11-11 合肥城市云数据中心有限公司 分布式云环境下的安全访问控制架构及其访问方法
CN107181808B (zh) * 2017-06-01 2020-05-08 安徽祥云科技有限公司 一种私有云系统及运行方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150052525A1 (en) * 2013-08-13 2015-02-19 Vmware, Inc. Virtual private networks distributed across multiple cloud-computing facilities
CN104954333A (zh) * 2014-03-28 2015-09-30 华为技术有限公司 一种转发报文的方法、系统
CN105591863A (zh) * 2014-10-20 2016-05-18 中兴通讯股份有限公司 一种实现虚拟私有云网络与外部网络互通的方法和装置
CN105721306A (zh) * 2016-02-04 2016-06-29 杭州数梦工场科技有限公司 一种配置信息的传输方法和装置
CN109117650A (zh) * 2018-07-25 2019-01-01 华为技术有限公司 一种企业云的创建方法和管理平台

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111832879A (zh) * 2020-04-15 2020-10-27 中国人民解放军军事科学院战争研究院 一种开放式企业级信息系统的信息资源共享与授权方法
WO2022001376A1 (zh) * 2020-06-29 2022-01-06 华为技术有限公司 一种云服务的资源发放方法及相关设备
CN113472745A (zh) * 2021-05-31 2021-10-01 山东英信计算机技术有限公司 一种基于selinux的openstack公有云多租户隔离方法、系统及终端
CN113472745B (zh) * 2021-05-31 2023-04-07 山东英信计算机技术有限公司 一种基于selinux的openstack公有云多租户隔离方法、系统及终端
WO2023138032A1 (zh) * 2022-01-24 2023-07-27 华为云计算技术有限公司 一种地址空间推荐方法、装置及相关设备
CN115801833A (zh) * 2022-11-16 2023-03-14 浙江九州云信息科技有限公司 一种企业级公有云资源管理方法及系统
CN116167029A (zh) * 2023-04-23 2023-05-26 汕头市林百欣科学技术中等专业学校 一种基于云计算的计算机系统账户管理方法

Also Published As

Publication number Publication date
CN109117650A (zh) 2019-01-01
CN109117650B (zh) 2022-03-18

Similar Documents

Publication Publication Date Title
WO2020019839A1 (zh) 一种企业云的创建方法和管理平台
US10523717B2 (en) Multi cloud policy enactment via organizations to cloud-provider partnerships
RU2598324C2 (ru) Средства управления доступом к онлайновой службе с использованием внемасштабных признаков каталога
JP6559807B2 (ja) コマンド実行に対するユーザアクセスの制御
US9426019B1 (en) Resource pooling and subletting from user to another user
US20110214165A1 (en) Processor Implemented Systems And Methods For Using Identity Maps And Authentication To Provide Restricted Access To Backend Server Processor or Data
US10552796B1 (en) Approval service in a catalog service platform
US8805882B2 (en) Programmatically enabling user access to CRM secured field instances based on secured field instance settings
CN103366135B (zh) 在存储云中由租户驱动的安全系统与方法
US20120167197A1 (en) Enabling granular discretionary access control for data stored in a cloud computing environment
US20230161895A1 (en) Controlling access to cloud resources in data using cloud-enabled data tagging and a dynamic access control policy engine
US6678682B1 (en) Method, system, and software for enterprise access management control
US20080244688A1 (en) Virtualized federated role provisioning
US10432642B2 (en) Secure data corridors for data feeds
JP2017529629A (ja) ホストされたディレクトリサービスによるディレクトリへのアプリケーションアクセスの管理
WO2018095326A1 (zh) 访问权限的确定方法和装置、终端
Jin et al. Role and attribute based collaborative administration of intra-tenant cloud iaas
US9871778B1 (en) Secure authentication to provide mobile access to shared network resources
CN106067119A (zh) 基于私有云的客户关系管理方法
CN106096976A (zh) 小型企业客户关系管理方法
US8631123B2 (en) Domain based isolation of network ports
WO2024037224A1 (zh) 一种基于云计算技术的云资源访问控制方法及云管理平台
Zhang et al. Community-based secure information and resource sharing in Azure cloud IaaS
US20230122504A1 (en) Common Access Management Across Role-Based Access Control and Attribute-Based Access Control
US20240143825A1 (en) Sidecar data services for enforcing data policies

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19841761

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19841761

Country of ref document: EP

Kind code of ref document: A1