CN117203938A

CN117203938A - Systems and methods for segmenting transit capabilities within multi-cloud architectures

Info

Publication number: CN117203938A
Application number: CN202280029063.2A
Authority: CN
Inventors: X·S·伟; S·许
Original assignee: Avidros Systems
Current assignee: Avidros Systems
Priority date: 2021-02-17
Filing date: 2022-02-11
Publication date: 2023-12-08

Abstract

In one embodiment, a computing platform features a controller, one or more transit virtual private cloud networks (VPCs), and a plurality of branch VPCs communicatively coupled to the transit virtual VPCs. The branch VPCs include (i) a first branch VPC associated with a first secure region, and (ii) a second branch VPC associated with a second secure region. Herein, the first security zone is configured to permit the branch gateways of the first branch VPC to communicate with each other while blocking communication with the branch gateway associated with another security zone without a connection policy, which is a set of rules established by an administrator/user of the network regarding permitted connectivity between the different security zones.

Description

System and method for partitioning transit capabilities within a multi-cloud architecture

Cross Reference to Related Applications

The present application claims the benefit of priority from U.S. application Ser. No. 17/368,685, filed on 7/2021, entitled "Multi-Cloud Transit Segmentation" and filed on 2/2021/17, the priority from U.S. provisional patent application Ser. No. 63/150,504, the entire contents of which are incorporated herein by reference.

Technical Field

Embodiments of the present disclosure relate to the field of networking. More particularly, one embodiment of the present disclosure relates to a network isolation architecture adapted to split network traffic in order to enhance security.

Background

In the past few years, cloud computing has provided infrastructure as a service (IaaS), where resources are provided as part of a cloud computing platform (e.g., a public cloud network) and made accessible to tenants as a service. One of these services allows a tenant to run software components (e.g., virtual machine instances such as virtual servers) residing within a cloud computing platform. Such migration of software functionality into cloud computing platforms has led to increased use of virtual networks, such as virtual private cloud networks for different public cloud providers, such asWeb(AWS)、Azure Cloud Services、Cloud、Clouds et al.

Each virtual private cloud network is an on-demand, configurable pool of shared resources that are allocated within the cloud computing platform and provide a level of isolation between different organizations or other entities (hereinafter "users") that use cloud resources. Isolation between one virtual private cloud network user and other users utilizing the same public cloud network infrastructure may be achieved by assigning private Internet Protocol (IP) subnets on a per user basis. For each IP subnet, a public cloud service provider provides processing and/or storage functionality. In particular, AWS provisionElastic Compute Cloud (EC 2) service, but ∈>Different types of virtual machines are provided.

Recently, to increase system throughput, the virtual private cloud networks described above now rely on multiple active peer-to-peer communication links. As an illustrative example, some gateways provide connectivity to cloud software instances stored in a virtual private cloud network. Each of these gateways is configured to support two private IP-based communication links to a pair of gateways (hereinafter "transit) that reside within another type of virtual private cloud network (hereinafter" transit VPC "). However, where the transit VPC provides connectivity to a destination VPC located on a different public cloud network, such network architecture is now of high security concern, as multi-cloud connectivity increases the number of ways in which an attacker can gain access to the virtual private cloud network. Furthermore, when the AWS public cloud network extends beyond the AWS infrastructure, it is significantly dependent on the network infrastructureSecurity measures provided by Transit Gateway are not possible. Furthermore, there is no policy driven option to create security partitions provided by the cloud provider.

Drawings

Embodiments of the application are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements and in which:

FIG. 1 is an exemplary embodiment of a multi-cloud computing platform implemented with security domains that restrict communications between gateways to those residing within the same security domain.

Fig. 2 is an illustrative embodiment of the multi-cloud computing platform of fig. 1 implemented with a first security domain including one or more gateways communicatively coupled to one or more gateways residing within a second security domain through a connection policy.

Fig. 3 is an exemplary embodiment of a transit gateway deployed within the transit virtual network component (VPC/Vnet) of fig. 1-2 including a security domain data store (store) and a connection policy data store.

Fig. 4A-4C illustrate an exemplary embodiment of a Graphical User Interface (GUI) for programming one or more security domains within a multi-cloud computing platform and connection policies associated with the security domains.

5A-5B illustrate exemplary embodiments of operations performed by a controller to create constructs directed to security domains and connection policies associated with the security domains.

Fig. 6A-6B are exemplary embodiments of permitted and non-permitted interoperability between two branch (spoke) gateways residing in different security domains of the multi-cloud computing platform of fig. 1-2.

FIG. 7 is an exemplary embodiment of operations for establishing a multi-cloud mid-transfer partition architecture.

Detailed Description

Embodiments of systems and methods for establishing a multi-cloud computing platform implemented on different types of public cloud network infrastructure that segments data traffic for enhancementSecurity across multiple public cloud networks. Herein, the multi-cloud computing platform enables network isolation through the use of security domains and connection policies. Each security domain identifies a set of gateways that can communicate with each other. The gateways may be deployed within the same virtual network component or within different virtual network components, where the virtual network components may reside within the same area of a public cloud network, within different areas of the same public cloud network, or within different public cloud networks. As an illustrative example, a first set (e.g., one or more) of gateways may be in the network domain defined byOperating within a first virtual network component supported by an underlying network infrastructure provided by A Web Services (AWS) public cloud network, while a second set of gateways may operate within the network component supported by +.>Public cloud network or->The second virtual network component supported by clouds operates within. Each connection policy identifies permitted communications across different security domains.

Herein, for clarity, each virtual network component—e.g., sometimes referred to as a virtual private cloud network for AWS deployment, forDeployed virtual network (VNet), or for +.>Clouds deployed Virtual Cloud Networks (VCNs) -will be referred to herein collectively as "virtual private Cloud networks" or "VPCs" for clarity purposes. Thus, the multi-cloud computing platform may be characterized by the following: (i) A first plurality of virtual network components, each virtual network component operating as a virtual private cloud network (hereinafter "branch VPC") that maintains cloud resources accessible by a set of gateways; (ii) Second oneA plurality of virtual network components, each operating as a virtual private cloud network supporting message routing from/to a branch VPC (hereinafter "transit VPC"); and/or (iii) a shared services networking infrastructure comprising a controller for updating and maintaining data stores of the branch VPCs and/or transit VPCs to maintain routing information according to the deployed security domains and connection policies.

More specifically, according to one embodiment of the present disclosure, each branch VPC includes a set (e.g., two or more) of gateways (hereinafter "branch gateways") communicatively coupled to one or more cloud software instances having one or more particular subnetworks. Some or all of these cloud software instances may include executable applications. Similarly, each transit VPC may feature a gateway cluster that includes a set of gateways. The set of gateways (hereinafter "transit gateways") deployed within the transit VPC control message routing between the branch VPCs, and in effect control message routing between cloud software instances deployed in different branch VPCs. As shown, each of the branch gateway and the transit gateway may be accessed according to a unique classless inter-domain routing (CIDR) routing address to propagate messages through the multi-cloud computing platform.

In addition to being communicatively coupled to the branch gateway, the transit gateway may also be communicatively coupled to one or more network edge devices (e.g., virtual or physical routers, etc.) deployed in a provisioning network (hereinafter "provisioning network devices"). Herein, the transit VPC is configured to control data traffic propagation between a source branch VPC receiving data traffic from the cloud software instance and a destination branch VPC or a preset network. Additionally, according to embodiments of the present disclosure, the transit VPC is further configured to restrict data traffic flow by controlling data traffic propagation to gateways residing in the same security domain or residing in different security domains, so long as a connection policy is established to permit gateway communication between these different security domains.

Further details of logic associated with one embodiment of the scalable multi-cloud computing platform are described below.

I. Terminology

In the following description, certain terminology is used to describe features of the application. In some cases, the terms "logic" and "component" represent hardware, software, or a combination thereof configured to perform one or more functions. As hardware, logic (or components) may include circuitry having data processing or storage functionality. Examples of such circuitry may include, but are not limited to or limited to, a processor (e.g., a microprocessor, one or more processor cores, a programmable gate array, a microcontroller, an application specific integrated circuit, etc.), a semiconductor memory, or combinational logic.

Instead of, or in addition to, the above-described hardware circuitry, logic (or components) may be software in the form of one or more software modules. The software module(s) may be configured to operate as virtual hardware components (e.g., virtual processors) or virtual network devices that include one or more virtual hardware components. The software module(s) may include, but is not limited to, an executable application, an Application Programming Interface (API), a subroutine, a function, a procedure, an applet, a servlet, a routine, a source code, a shared library/dynamic load library, or one or more instructions. The software module(s) may be stored in any type of suitable non-transitory storage medium or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals). Examples of non-transitory storage media may include, but are not limited to: a programmable circuit; a semiconductor memory; non-volatile storage such as volatile memory (e.g., any type of random access memory "RAM"); persistent storage such as non-volatile memory (e.g., read-only memory "ROM", power-supported (power-assisted) RAM, flash memory, phase-change memory, etc.), solid-state drive, hard disk drive, optical disk drive, or portable memory device.

VPC routing table: the VPC routing table is a logical construct for instructing the software instance how to reach the selected destination.The destination may constitute another software instance, which may be identified by a routable network address. The VPC routing table comprises a plurality of entries, wherein each entry comprises a routable network address of a destination and an identifier of a software component having routing functionality, which constitutes a next hop towards the destination (target). The identifier may include, for example, a gateway identifier.

Gateway (GW): the term may be interpreted as virtual or physical logic with data routing functionality. As an illustrative example, a gateway may correspond to virtual logic, such as a data routing software component assigned an Internet Protocol (IP) address within an IP address range associated with a VPC that includes the gateway. Multiple gateways are deployed in a multi-cloud computing platform that can control ingress/egress of data traffic into/from a VPC. Although having a similar architecture, gateways may be identified differently based on their location/operability within a public cloud network. For example, a "branch" gateway is a gateway that supports routing between cloud software instances and "transit" gateways, where each transit gateway is configured to further assist in the propagation of data traffic (e.g., one or more messages) from one branch gateway to another branch gateway within the same branch VPC or within a different VPC. Alternatively, in some embodiments, the gateway may correspond to physical logic, such as an electronic device communicatively coupled to a network and assigned a hardware (MAC) address and an IP address.

IPSec tunnel: secure peer-to-peer communication links established between gateways of adjacent virtual network components, such as adjacent VPCs. The peer-to-peer communication link may be protected by a secure network protocol suite (suite) known as "internet protocol security" (IPSec). These IPSec tunnels are represented in the gateway by Virtual Tunnel Interfaces (VTIs), and tunnel states are represented by VTI states.

Security domain: the controller of the software component associated with the VPC or VPCs permitted to exchange and transmit data implements the network. Thus, VPCs within the same security domain are permitted to communicate with each other, while VPCs within different security domains are unable to communicate without a connection policyAnd (5) information. A "connection policy" is one or more rules that are enforced to allow connectivity across security domains.

Computerized device: the term generally means that any corresponding operations are performed by hardware in combination with software.

Message: information transmitted in a prescribed format and according to a suitable delivery protocol. Thus, each message may be in the form of one or more packets, frames, or any other bit sequence having a prescribed format.

Finally, the terms "or" and/or "as used herein should be interpreted as inclusive, or meaning any one or any combination. As an example, "A, B or C" or "A, B and/or C" means: "any one of the following: a, A is as follows; b, a step of preparing a composite material; c, performing operation; a and B; a and C; b and C; A. b and C). An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.

As this application is susceptible of embodiment in many different forms, this disclosure is to be taken in the form of example of the principles of the application and not in limitation to the specific embodiments shown and described.

General system architecture

Referring now to FIG. 1, a diagram illustrating the utilization of multiple security domains 110 is shown ₁ -110 _N (N.gtoreq.1) exemplary embodiments of the implemented multi-cloud computing platform 100 wherein each security domain 110 ₁ -110 _N Limiting the communication between gateways to those residing within the same security domain. Herein, the multi-cloud computing platform 100 is configured to provide connectivity between the resources 120 of the first public cloud network 125 and the resources 160 of the second public cloud network 165. Herein, according to one embodiment of the present disclosure, the first public cloud network 125 corresponds toWeb Services (AWS) cloud network, and second public cloud network 165 corresponds to +.> A cloud network, which is different from the first public cloud network 125.

According to one embodiment of the present disclosure, the resources 120 of the first public cloud network 125 feature one or more branch VPCs 130, the one or more branch VPCs 130 communicatively coupled to a first transit VPC 140 comprising one or more transit gateways 142. Herein, as shown, a first branch VPC 131 of one or more branch VPCs 130 may be configured with connectivity to some of the cloud software (application) instances 145 and transit gateway(s) 142 of the first transit VPC 140. The network edge devices 147 (e.g., virtual or physical routers) of the pre-set network 149 are communicatively coupled to the transit gateway(s) 142 for transmitting data traffic to the pre-set network 149 and receiving data traffic from the pre-set network 149.

Herein, as for each of the branch VPCs 130, the first branch VPC 131 is configured to exchange data traffic from a cloud appliance (application) instance(s) 145 with selected ones of a set (e.g., two or more) of gateways 135 maintained in the first branch VPC 131 according to a first VPC routing table 155 managed by a controller 150 within the shared VPC 152. Similarly, a second branch VPC 132 of the one or more branch VPCs 130 may be configured with connectivity to some of the cloud software instances 145. In particular, for this embodiment, the second branch VPC 132 is configured to exchange data traffic between some cloud appliance instance(s) 145 and selected ones of a set of gateways 136 maintained in the second branch VPC 132 according to a second VPC routing table 156 also managed by the controller 150. These multiple branch VPCs may formulate a configuration of a first portion of the multi-cloud computing platform 100.

Additionally, according to one embodiment of the present disclosure, the resources 160 of the second public cloud network 165 may feature one or more branch VPCs 170 (such as third, fourth, and fifth branch VPCs 171-173) and a second transit VPC 180 that includes a transit gateway 182. Herein, each of these branch VPCs 171 may be configured to communicate with different cloud software (application) instance(s) 185. For example, according to the third VPC routing table 157 managed by the controller 150, certain cloud application instances 185 may be configured to exchange data traffic with selected ones of a set (e.g., two or more) of gateways 175 maintained in the third branch VPC 171. These multiple branch VPCs may formulate the configuration of this second portion of the multi-cloud computing platform 100.

As shown, a plurality of security domains 110 ₁ -110 _N May be configured to limit communication between branch VPCs across the same public cloud network 125 or 165, or communication between branch VPCs across different public cloud networks 125 and 165, as shown. As an illustrative embodiment, a first security domain 110 ₁ Communication may be restricted to remain between gateway 135 associated with first branch VPC 131 and gateway 175 associated with third branch VPC 171 of first public cloud network 125. Likewise, a second security domain 110 ₂ Communications may be restricted to remain between gateway 136 associated with second branch VPC 132 and gateways 176 and 177 residing within fourth and fifth branch VPCs 172 and 173 of second public cloud network 165. The transit gateway(s) 142 and 182 serve to interconnect the same security domains 110 based on a connection policy (described below) ₁ Or 110 ₂ Internal or different security domains 110 ₁ And 110 ₂ A gateway within the branch VPC within.

These security domains 110 ₁ And 110 ₂ May be accomplished by modifying at least the first transit routing data store 190 associated with the first transit gateway 142 ₁ And a second transit routing data store 190 associated with the second transit gateway 182 ₂ Routing information maintained internally. Transit routing data store 190 ₁ And 190 ₂ A routing table may be constructed. Thus, first transit routing data store 190 is considered prior to routing messages to/from a source branch VPC (e.g., first branch VPC 131) to a destination branch VPC (e.g., third branch VPC 171) ₁ To determine when such communication is secured by the security domain 110 ₁ And 110 ₂ When restricted, whether such communication is available and unavailable.

Referring now to FIG. 2, another illustrative embodiment of the multi-cloud computing platform 100 of FIG. 1 is shown, wherein the multi-cloud computing platform 100 is implemented with a plurality of security domains 200 including a first security domain 210, a second security domain 220, and a third security domain 230. Herein, first security domain 210 includes gateway 135, second security domain 220 includes gateways 136 and 175, and third security domain 230 includes gateways 176 and 177. The gateways 135, 136, and 175 are configured to communicate with each other through the first connection policy 240. As a result, the multi-cloud computing platform 100 provides network isolation between gateways across multiple areas and/or multiple cloud networks through the security domains 210/220 and 230 and connection policies such as the first connection policy 240.

More specifically, as shown in fig. 2, a gateway 136 associated with the second branch VPC 132 (e.g., AWS VPC) and a third branch VPC 171 (e.g.,VNet) may communicate with each other, while gateways 176 and 177 associated with fourth VPC 172 and fifth VPC 173 are isolated and prevented from communicating with gateways 135, 136 and 175. In general, without one of the connection policies (e.g., connection policy 240) providing such connectivity, there is no cross-communication between gateway 135 associated with first security domain 210 and gateways 136 and 171 associated with second security domain 220.

Herein, after a user (e.g., administrator, device user, etc.) sets a connection policy 240, controller 150 accesses content within connection policy 240 to determine that resources maintained in first security domain 210 are permitted to communicate with resources maintained in second security domain 220. In particular, gateways 135/136 associated with branch VPCs 131/132 of first public cloud network 125 and gateways 175 within branch VPCs 171 of second public cloud network 165 may communicate with each other via transit gateways. To achieve this, controller 150 dynamically programs and updates transit routing data store 190 ₁ And 190 ₂ Both so that instances in the branch VPC can communicate with each other via the transit gateways 142 and/or 182.

Referring to FIG. 3, there is shownAn exemplary embodiment of a transit gateway 300 is shown, the transit gateway 300 being one of the transit gateways 142 deployed within the transit VPC 140. The transit gateway 300 constitutes a software component that covers resources of the public cloud network infrastructure, such as for example an AWS-based transit VPC or an AWS-based transit VPC such as in fig. 1VNet is transferred. The software component includes logic that is executed by a (virtual) processor, which is a computing service provided by a cloud provider, and is illustrated for completeness. Herein, according to one embodiment of the present disclosure, the transit gateway 300 includes data traffic processing logic 310, data traffic routing logic 320, and one or more transit routing data stores 330, wherein the transit routing data store 310 can maintain routing information for data traffic sources (e.g., routers of a pre-set network, branch VPCs, other transit VPCs, etc.) that rely on the transit gateway 300 to route incoming messages 340 to destinations.

The data traffic processing logic 310 is configured to receive incoming messages 340 from a data traffic source, such as a branch gateway 135 deployed as part of the branch VPC 131 of fig. 1, the branch gateway 135 being provisioned to access the transit gateway 300. Upon receipt of the incoming message 340, the data traffic processing logic 310 is configured to parse and analyze the incoming message 340 to determine a destination of the incoming message 340. In the event that the destination is reachable from the breakout gateway 135, i.e. any established security domain includes a VPC or network and/or connection policy in which the destination resides, the contents of the incoming message 340 are provided to the data traffic routing logic 320. In the event that the destination is not reachable from the breakout gateway 135, the incoming message 340 is discarded and/or an error message may be provided to the data traffic source and/or controller for reporting to a network administrator.

The data traffic routing logic 320 may be configured to access the transit routing data store 332 in the transit routing data store 330 to determine a next hop (e.g., gateway associated with the destination, transit gateway, etc.) for transmitting content associated with the incoming message 340 thereto. As an illustrative example, as shown in fig. 1, for a transfer from an instance within the first branch VPC 131 to an instance within the third branch VPC 171, the transit route data store 332 may identify transit gateways 182 that overlay cloud infrastructure associated with different cloud providers. Thereafter, the data traffic routing logic 320 may organize content associated with the incoming message 340 (e.g., encapsulate, reinsert into the payload and/or header of the new message, etc.) to generate an outgoing message 350 for transmission to a next hop identified by the transit routing data store 330 and deemed an optimal path based on the selected policy and/or parameters (e.g., hop count to destination, security parameters, etc.).

Security domain formation

Referring now to fig. 4A-4C, an exemplary embodiment of a series of Graphical User Interfaces (GUIs) for establishing security domain(s) and optional connection policies associated with those security domains within a multi-cloud computing platform 100 is shown. Herein, as shown in fig. 4A, the first GUI 400 constitutes a web page accessible by a user to create a security Domain by entering a unique Domain name 420 (e.g., dev Domain) associated with the security Domain within an assigned field 410. Upon selection of the domain name 420 and completion of the process phase (e.g., activation of the "enter" button 425), a security domain is created, but no branch gateway or network edge device is identified. This process may be repeated to create multiple security domains.

When the security domain(s) are created, a connection relationship may be established between the security domains through the second GUI 430 as shown in fig. 4B. In particular, the second GUI 430 may include a graphical element 440, such as a drop down menu listing security domains available on the multi-cloud computing platform 100. By selecting multiple security domains and activating the "add" graphical element 450, a connection policy is generated between the selected security domains. The connection policy permits the branch gateways in the selected security domain to communicate with each other despite the fact that these branch gateways are in different security domains.

Thereafter, as shown in fig. 4C, the third GUI 460 may include an input field 465 to associate each security domain with the transit gateway and populate each security domain with a branch gateway and/or a network edge device (e.g., a router for connecting with a pre-set network) communicatively coupled to the transit gateway. The third GUI 460 establishes network splitting based on identifying the security domain 470, a branch gateway (or network edge device) 480 to be included as a member of the security domain 470, and a transit gateway 490 with which the branch gateway (or network edge device) 480 communicates. These fields may be automatically populated from different entries such that entries of the transit gateway 490 automatically identify the branch gateway (or network edge device) 480 or provide a drop down menu with the branch gateway/edge device options. Although not shown, in a similar graphical representation, it is contemplated that another GUI similar in feature to the third GUI 460 may be used to disassociate a branch gateway or network edge device from an identified security domain.

Referring to fig. 5A-5B, exemplary embodiments of operations performed by a controller to create constructs directed to security domains and connection policies associated with the security domains are shown. Herein, the controller maintains an available route for each transit gateway set forth in the multi-cloud computing platform. In a default state without any security domains, the transit routing data store for each transit gateway may be configured with active connections directed to most, if not all, of the branch VPCs and other transit gateways forming the multi-cloud computing platform (operation 500). However, in response to the creation of the security domain assigned the security domain name, the controller generates a transit routing data store associated with the security domain (operations 510 and 515). In the case where a plurality of security domains are created, the controller receives information associated with any connection policy established between two or more of the plurality of security domains (operation 520). The identification of the connection policy is required to ensure that routing connections associated with the branch gateway placed in the security domain are also populated into the transit routing data store associated with the other connected security domain(s) (operation 525).

Thereafter, the controller receives security domain membership information (operation 530) as each security domain is configured to define the member components of the security domain, i.e., one or more branch gateways and/or network edge devices (e.g., routers of a preset network, etc.), and transit gateways to which the member components are communicatively coupled. Based on the security domain membership information, the controller is configured to: the routing connections to the branch gateway(s) and/or network edge device(s) are included within transit routing data store(s) associated with the security domain maintained in each transit gateway with which at least one of the branch gateway(s) and/or network edge device(s) communicates (operation 540). In addition, the controller determines whether there is a connection policy associated with the security domain and, if so, the controller alters the transit routing data store(s) associated with the "connected" security domain to include routing connections to the branch gateway(s) and/or network edge device(s) (operations 550 and 560). These transit routing data stores belong to transit gateways that communicate with the branch gateway(s) and/or network edge device(s) added to the security domain.

Further, based on the routing connections, the controller dynamically programs and updates the VPC routing table so that instances in different branch VPCs in the same domain can communicate, and instances in different branch VPCs in different security domains are prevented from communicating without a connection policy by removing any such routing connections (operation 570). The controller continues to monitor the security domain, connection policy, and/or removal/addition of member components (operations 580, 585, and 590).

General Security Domain operability

Referring to fig. 6A-6B, an exemplary embodiment of permitted and impermissible interoperability between two tributary gateways residing in different security domains of the multi-cloud computing platform of fig. 1-2. For this illustrated example, the first branch gateway 600 may operate as the first branch gateway 135 residing within the first branch VPC 131 of fig. 1, and the second branch gateway 610 may operate as the second branch gateway 136 residing within the second branch VPC 132. Here, the first breakout gateway 600 resides in a different security domain than the second breakout gateway 610, wherein no connection policy is established between the first breakout gateway 600 and the second breakout gateway 610. As a result, via transit gateway 300, with a first security domain (e.g., security domain 110 of fig. 1) ₁ ) The associated first branch gateway 600 is unable to interact with a second security domain (e.g., security domain 110 of fig. 1) ₂ ) The associated second branch gateway 610 communicates.

In contrast, as shown in fig. 1 and 6B, the first breakout gateway 600 may reside either in the same security domain as the second breakout gateway 610 or in a different security domain, as long as there is a connection policy with these breakout gateways 600 and 610. As a result, via transit gateway 300, a first breakout gateway 600 associated with a first security domain can and is permitted to communicate with a second breakout gateway 610 associated with a second security domain.

V. operational flow

Referring to fig. 7, an exemplary embodiment of operations for relay segmentation of a multi-cloud computing platform through security domains and connection policies is shown. First, a multi-cloud computing platform is generated (operation 700). Herein, the multi-cloud computing platform is characterized as follows: a first set of branch VPCs and a first set of transit VPCs associated with an underlying first public cloud network infrastructure, along with a second set of branch VPCs and a second set of transit VPCs associated with an underlying second public cloud network infrastructure. Thereafter, some or all transit gateways within the transit VPC are enabled for splitting (operation 710). In the event that the transit gateway is not enabled for segmentation, the transit gateway will not be configured as part of any security domain.

Thereafter, a security domain is created and assigned a unique security domain name (operation 720). This operation may proceed sequentially to create two or more security domains (operation 725). Alternatively, the operation may be performed asynchronously (asynchrous), where one or more security domains may be created to dynamically alter the partitioning and cause the controller to update the transit routing data store accordingly. For clarity, the operations will focus on the creation of two security domains.

After the security domain is created, a connection policy may be established to formulate a connection relationship between different security domains (operation 730). The two connected security domains imply that the tributary gateways in each of these security domains can communicate with each other despite the fact that they reside in different domains. Furthermore, the presence of a connection policy is monitored by the controller to ensure that the routing connections associated with the connected branch gateway are replicated for different transit routing data store(s) maintained in the different transit gateway(s).

Thereafter, each security domain is configured to define a member component of the security domain by associating the security domain with one or more branch gateways and a transit gateway to which the branch gateways are communicatively coupled (operation 740). Security domain membership information (e.g., routable network address associated with a branch gateway and its corresponding transit gateway, etc.) is provided to the controller, which along with the connection policy is used to set up routing connections to the branch gateway(s) within the transit routing data store(s) associated with the security domain maintained in each transit gateway with which the branch gateway(s) communicate (operations 750 and 760).

The partitioning of the multi-cloud computing platform is dynamic in that the partitioning may be altered by or changes to the security domain, connection policy, and/or member components (operation 770).

Embodiments of the application may be embodied in other specific forms without departing from the spirit of the disclosure. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the embodiments is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims

1. A computing platform, comprising:

a controller; and

a plurality of branch virtual private cloud networks including (i) a first branch virtual private cloud network associated with a first secure area, and (ii) a second branch virtual private cloud network associated with a second secure area,

wherein the first secure area is configured by the controller to permit the branch gateways of the first branch virtual private cloud network to communicate with each other while blocking communication between the branch gateway of the first branch virtual private cloud network and a branch gateway associated with a second branch virtual private cloud network associated with the second secure area.

2. The computing platform of claim 1, wherein the first and second branch virtual private cloud networks are deployed within a single public cloud network.

3. The computing platform of claim 1, being a multi-cloud computing platform comprising a first branch virtual private cloud network deployed within a first public cloud network and a second branch virtual private cloud network deployed within a second public cloud network different from the first public cloud network.

4. The computing platform of claim 1, wherein the plurality of branch virtual private cloud networks further includes a third branch virtual private cloud network associated with the first security zone such that a gateway associated with the third branch virtual private cloud network is communicatively coupled to a branch gateway of the first branch virtual private cloud network and prevented from communicating with a branch gateway of the second branch private cloud network.

5. The computing platform of claim 1, wherein the controller is configured with access to one or more transit routing data stores that include content that establishes the first security domain and the second security domain.

6. The computing platform of claim 5, wherein the controller is configured to monitor for the presence of a connection policy between the first secure area and the second secure area that, upon detection, allows communication between a branch gateway of the first branch virtual private cloud network operating in the first secure area and a branch gateway of the second branch virtual private cloud network operating within the second secure area.

7. The computing platform of claim 6, wherein the connection policy includes one or more rules enforced to allow cross-security domain connectivity.

8. The computing platform of claim 6, further comprising:

one or more transit virtual private cloud networks,

wherein the controller is configured to replicate any routing connection between a branch gateway of a first branch virtual private cloud network and a branch gateway of a second branch virtual private cloud network maintained within a different routing transit data store, the different routing transit data store being accessible by a transit virtual private cloud network different from the one or more transit virtual private cloud networks.

9. The computing platform of claim 1, further comprising:

one or more transit virtual private cloud networks,

wherein a transit virtual private cloud network of the one or more transit virtual private cloud networks includes data traffic processing logic that, upon receipt of an incoming message, is configured to parse and analyze the incoming message to determine a destination of the incoming message,

providing content associated with the incoming message to the destination in the event that both the destination and the source of the incoming message are members of a first secure area, and

in the event that the destination is a member of the second secure area, the source of the incoming message is a member of the first secure area, and a connection policy is established between the first secure area and the second secure area, content associated with the incoming message is provided to the destination.

10. The computing platform of claim 9, discarding the incoming message and optionally reporting an error message to the source or controller if the destination is a member of a second secure area, the source of the incoming message is a member of a first secure area, and no connection policy is established between the first secure area and the second secure area.

11. A multi-cloud computing platform, comprising:

a first virtual private cloud network operating within a first public cloud network;

a second virtual private cloud network operating within a second public cloud network different from the first public cloud network; and

logic associated with the transit gateway configured to: (i) determining whether a first branch gateway of a first virtual private cloud network operating as a source of content directed to a second branch gateway of a second virtual private cloud network, the second branch gateway of the second virtual private cloud network operating as a destination of the content is a member of a first security domain, (ii) routing the content from the first branch gateway to the second branch gateway when both the first virtual private cloud network and the second virtual private cloud network are members of the first security domain, (iii) determining whether a connection policy exists between the first security domain and the second security domain when the first virtual private cloud network and the second virtual private cloud network are in different security domains, and (iv) preventing communication between the first branch gateway and the second branch gateway when the first virtual private cloud network and the second virtual private cloud network are in different security domains and when no connection policy exists between the first virtual private cloud network and the second virtual private cloud network.

12. The multi-cloud computing platform of claim 11, wherein logic associated with the transit gateway is disposed within the transit gateway and is configured to: (v) Communication between the first and second branch gateways is allowed when (a) the first and second virtual private cloud networks are members of a first security domain, or (b) the first and second virtual private cloud networks are members of different security domains and a connection policy exists between the first and second virtual private cloud networks.

13. The multi-cloud computing platform of claim 11, further comprising:

a first subnet comprising one or more cloud software instances, the cloud software instances comprising a first cloud software instance; and

a second subnet comprising one or more cloud software instances, the cloud software instances comprising a second cloud software instance;

wherein when (a) the first virtual private cloud network and the second virtual private cloud network are members of a first security domain, or (b) the first virtual private cloud network and the second virtual private cloud network are members of different security domains and a connection policy exists between the first virtual private cloud network and the second virtual private cloud network, the first branch gateway of the first virtual private cloud network is operable to transmit information associated with the first cloud software instance to a second cloud instance communicatively coupled to the second branch gateway.

14. The multi-cloud computing platform of claim 11, wherein the connection policy includes one or more rules enforced to allow cross-security domain connectivity.

15. A multi-cloud computing platform, comprising:

a controller; and

a non-transitory storage medium comprising software that, when executed, generates a plurality of branch virtual private cloud networks communicatively coupled to one or more transit virtual private cloud networks, the plurality of branch virtual private cloud networks comprising (i) a first branch virtual private cloud network associated with a first secure area, and (ii) a second branch virtual private cloud network associated with a second secure area,

wherein the first security zone is configured to permit the branch gateways of the first branch virtual private cloud network to communicate with each other while blocking communication between the branch gateways of the first branch virtual private cloud network and the branch gateways associated with the second branch virtual private cloud network associated with the second security zone.

16. The multi-cloud computing platform of claim 15, wherein the controller is configured with access to one or more transit routing data stores that include content that establishes the first security domain and the second security domain.

17. The multi-cloud computing platform of claim 15, wherein the controller is configured to monitor for the presence of a connection policy between the first secure area and the second secure area that, upon detection, allows communication between a branch gateway of the first branch virtual private cloud network operating in the first secure area and a branch gateway of the second branch virtual private cloud network operating within the second secure area.

18. The multi-cloud computing platform of claim 15, wherein said software included within said non-transitory storage medium, when executed, generates one or more transit virtual private cloud networks,

wherein a transit virtual private cloud network of the one or more transit virtual private cloud networks includes data traffic processing logic that, upon receipt of an incoming message, is configured to parse and analyze the incoming message to determine a destination of the incoming message, and

in the event that the destination and the source of the incoming message are both members of a first secure area, the data traffic processing logic is configured to provide content associated with the incoming message to the destination, and

in the event that the destination is a member of the second secure area, the source of the incoming message is a member of the first secure area, and a connection policy is established between the first secure area and the second secure area, the data traffic processing logic is configured to provide content associated with the incoming message to the destination.

19. The multi-cloud computing platform of claim 18, wherein in response to the destination being a member of a second secure area, the source of the incoming message being a member of a first secure area, and no connection policy being established between the first secure area and the second secure area, the data traffic processing logic is configured to discard the incoming message and optionally report an error message to the source or controller.

20. The multi-cloud computing platform of claim 17, wherein the connection policy includes one or more rules enforced to allow cross-security domain connectivity.