Patent Description:
Recent industry-wide shifts toward cloud-based service delivery and data consumption present new challenges for service providers to route and deliver data while providing security for data stored in private cloud databases. For example, cloud-based providers may employ various real-time adjustment models to efficiently adapt and allocate network resources based on changing security needs. Furthermore, a hybrid cloud computing and storage environment can present added challenges for network security as some portions of a hybrid cloud computing and storage environment may be accessible to a public forum and other portions of a hybrid cloud may be designated for a private forum.

A hybrid cloud computing environment can be a target for unauthorized access to data stored in the hybrid cloud as potential security threats may attempt to penetrate vulnerabilities that can be associated with a hybrid cloud computing and storage environment. Emerging computer-based threats are accelerating a need for increasingly flexible and secure network operations. As data, software, services, applications, and databases are increasingly tied to cloud-based networks, added security functionality and flexibility is desired in cloud-based computing environments, including hybrid cloud computing and storage environments.

<CIT> relates to a data loss prevention system and method for a multi tenant environment. Data can be provided with various tags, and/or security levels.

<CIT> relates to a cloud computing system configured to run virtual machine instances. When accessing configuration resources, a virtual machine provides authentication data to identify itself.

<CIT> relates to a cloud computing abstraction layer, in which a security policy with respect to a security zone is defined, such that the type of security policy can be associated with software workload.

In order to describe the manner in which the above-recited features and other advantages of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:.

A component or a feature that is common to more than one drawing is indicated with the same reference number in each of the drawings.

Various embodiments of the disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure.

In some embodiments, the present technology may receive a request from a first cloud network of a hybrid cloud environment to transmit data to a second cloud network of the hybrid cloud environment, wherein the request may include a security profile related to the data. The security profile can be automatically analyzed to determine access permissions related to the data. Moreover, based at least in part on the access permissions, the data may be allowed to access to the second cloud network.

A communication network can include a system of hardware, software, protocols, and transmission components that collectively allow separate devices to communicate, share data, and access resources, such as software applications. More specifically, a computer network may be a geographically distributed collection of nodes interconnected by communication links and segments for transporting data between end points, such as personal computers, portable devices, and workstations. Many types of networks are available, ranging from local area networks (LANs) and wide area networks (WANs) to overlay and software-defined networks, such as virtual extensible local area networks (VXLANs), and virtual networks such as virtual LANs (VLANs) and virtual private networks (VPNs).

LANs may connect nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, may connect geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines, optical lightpaths, synchronous optical networks (SONET), or synchronous digital hierarchy (SDH) links. LANs and WANs can include layer <NUM> (L2) and/or layer <NUM> (L3) networks and devices.

The Internet is an example of a public WAN that connects disparate networks throughout the world, providing global communication between nodes on various networks. The nodes can communicate over the network by exchanging discrete frames or packets of data according to predefined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). In this context, a protocol can refer to a set of rules defining how the nodes interact with each other. Computer networks may be further interconnected by intermediate network nodes, such as routers, switches, hubs, or access points, which can effectively extend the size or footprint of the network.

Networks can be segmented into sub-networks to provide a hierarchical, multilevel routing structure. For example, a network can be segmented into VLAN sub-networks using subnet addressing to create network segments. This way, a network can allocate various groups of IP addresses to specific network segments and divide the network into multiple logical networks. In a hybrid cloud environment, different sub-networks may be allocated to different parts of the hybrid cloud environment. For example, one or more VLAN sub-networks may be allocated to a private cloud network of the hybrid cloud environment and a public cloud network of the hybrid cloud environment based on security permissions associated with the one or more VLAN sub-networks.

Other networks, such as virtual networks (e.g., VLANs) are also available. For example, one or more LANs can be logically segmented to form a VLAN and allow a group of machines to communicate as if they were in the same physical network, regardless of their actual physical location. Thus, machines located on different physical LANs can communicate as if they were located on the same physical LAN. Interconnections between networks and devices can also be created using routers and tunnels, such as VPN tunnels, as is appreciated by those skilled in the art. In a hybrid cloud computing environment, such a tunnel may include encryption and/or firewalls at either end of the tunnel to serve as a gatekeeper for data transmitted between a private data center (DC)/private cloud network and a public cloud network such as a cloud network provided by a commercial entity. Example public cloud networks are the Microsoft Azure® Cloud, Amazon Web Services®, Oracle® Cloud, and the like.

The various networks can include various hardware or software appliances or nodes to support data communications, security, and provision services. For example, networks can include routers, hubs, switches, APs, firewalls, repeaters, intrusion detectors, servers, VMs, load balancers, application delivery controllers (ADCs), and other hardware or software appliances. Such appliances can be distributed or deployed over one or more physical, overlay, or logical networks. Moreover, appliances can be deployed as clusters, which can be formed using layer <NUM> (L2) and layer <NUM> (L3) technologies. Clusters can provide high availability, redundancy, and load balancing for flows associated with specific appliances or nodes. A flow can include packets that have the same source and destination information. Thus, packets originating from device A to service node B can all be part of the same flow.

Appliances or nodes, as well as clusters, can be implemented in cloud deployments. Cloud deployments can be provided in one or more networks to provision computing services using shared resources. Cloud computing can generally include Internet-based computing in which computing resources are dynamically provisioned and allocated to client or user computers or other devices on-demand, from a collection of resources available via the network (e.g., "the cloud"). Cloud computing resources, for example, can include any type of resource, such as computing, storage, network devices, applications, virtual machines (VMs), services, and so forth. For instance, resources may include service devices (firewalls, deep packet inspectors, traffic monitors, load balancers, etc.), compute/processing devices (servers, CPU's, memory, brute force processing capability), storage devices (e.g., network attached storages, storage area network devices), etc. In addition, such resources may be used to support virtual networks, virtual machines (VM), databases, applications (Apps), etc. Also, services may include various types of services, such as monitoring services, management services, communication services, data services, bandwidth services, routing services, configuration services, wireless services, architecture services, etc..

Cloud controllers and/or other cloud devices can be configured for cloud management. These devices can be pre-configured (i.e., come "out of the box") with centralized management, layer <NUM> (L7) device and application visibility, real time web-based diagnostics, monitoring, reporting, management, and so forth. As such, in some embodiments, the cloud can provide centralized management, visibility, monitoring, diagnostics, reporting, configuration (e.g., wireless, network, device, or protocol configuration), traffic distribution or redistribution, backup, disaster recovery, control, and any other service. In some cases, this can be done without the cost and complexity of specific appliances or overlay management software.

The present technology may address a need in the art for added security in hybrid cloud computing and storage environments ("hybrid cloud"). A hybrid cloud can refer to a cloud network architecture comprised of two or more cloud networks that communicate and/or share data. A hybrid cloud can be an interaction between private and public clouds where a private cloud connects to a public cloud and utilizes public cloud resources in a secure and scalable way. The hybrid cloud model can provide advantages over other cloud models. For example, the hybrid cloud model allows enterprises to protect their existing investment, maintain control of their sensitive data and applications, and maintain control of their network, processing, and storage resources. Additionally, hybrid clouds may allow enterprises to scale their environment as their demand for processing resources and storage increase or decrease. This scaling up or down can occur with minimal to no effect on existing physical network resources such as on-site, physical servers.

While some applications are suitable for traditional physical enterprise data centers/private networks, there are others whose dynamic compute requirements make them ideal for cloud-based deployment. For such applications, a goal is to take advantage of the computing elasticity and economics of cloud computing without sacrificing the security that data assets (e.g., databases, directories, repositories) gain from being located on site within an enterprise's data center. To be a viable hybrid cloud solution, data should be kept secure, applications should not need to be redesigned, and cloud networks should be readily mobile.

<FIG> illustrates an example hybrid cloud computing and storage network illustratively comprising a plurality of cloud networks or "clouds," including a private cloud <NUM> (e.g., enterprise data centers) and a public cloud <NUM> which may be utilized in a publicly-accessible network such as the Internet (not shown). Although current terminology refers to a hybrid cloud comprising a private cloud and a public cloud, it should be understood that many aspects of this disclosure can be practiced in various multi-cloud configurations (e.g., two clouds hosted by third party providers or two enterprise clouds in different locations). The private data center/private cloud <NUM> and public cloud <NUM> can be connected via a communication link <NUM> between private cloud gateway <NUM> and public cloud gateway <NUM>. Data packets and traffic can be exchanged among the devices of the hybrid cloud network using predefined network communication protocols as will be understood by those skilled in the art.

As depicted in <FIG>, each cloud network can have a cloud gateway such as private cloud gateway <NUM> and public cloud gateway <NUM>. Each cloud network may also contain at least one virtual machine (VM) and/or nested VM containers. For example, <FIG> illustrates VM1 <NUM> and VM2 <NUM> in private cloud <NUM> and VM3 <NUM> in public cloud <NUM>. Private cloud gateway <NUM> can be configured as a VM-based gateway running in private cloud <NUM> that may be responsible for establishing communication link <NUM> for communication and data transfer between private cloud <NUM> and public cloud <NUM>. Moreover, public cloud gateway <NUM> may be configured as a VM-based gateway running in public cloud <NUM> that can be responsible for establishing communication link <NUM> for communication and data transfer between private cloud <NUM> and public cloud <NUM>.

Moreover, security group tags associated with private cloud gateway <NUM> and public cloud gateway <NUM> can enhance hybrid cloud network security by preventing data from reaching unauthorized areas of the hybrid cloud or preventing data from leaving areas of the hybrid cloud which the data is restricted to. In some embodiments, private cloud gateway <NUM> can screen requests for data stored in private cloud <NUM> destined for public cloud <NUM> by utilizing security group tags associated with, for example, sub-net VLANs from public cloud <NUM> that are authorized to receive data from private cloud <NUM> by virtue of access permissions associated with the sub-net VLANs from public cloud <NUM>. This can prevent unauthorized data from leaving private cloud <NUM> by denying a request for data in private cloud <NUM> if, for example, the sub-net VLAN from public cloud <NUM> that makes the request does not have a security tag with access permissions to the requested data in private cloud <NUM>.

Likewise, in some embodiments, public cloud gateway <NUM> can screen requests for data stored in public cloud <NUM> destined for private cloud <NUM> by utilizing security group tags associated with, for example, sub-net VLANs from public cloud <NUM> that are authorized to receive data from private cloud <NUM> by virtue of access permissions associated with the sub-net VLANs from public cloud <NUM>. This can prevent unauthorized data from leaving public cloud <NUM> by not allowing the requested data from public cloud <NUM> to leave public cloud <NUM> if, for example, the sub-net VLAN from public cloud <NUM> related to the requested data does not have a security tag with access permissions to private cloud <NUM>.

In some embodiments, one or more firewalls may be used in conjunction with private cloud gateway <NUM> and public cloud gateway <NUM> to facilitate screening of requests for entry and exit from private cloud <NUM> and public cloud <NUM>. For example, private cloud gateway <NUM> and public cloud gateway <NUM> may complement each other by preventing entry of unauthorized data into their respective cloud networks and also preventing data from leaving their respective cloud networks if that data was not authorized to leave the cloud network due to insufficient access permissions for an intended destination (for example, a different cloud network of the hybrid cloud environment). In some embodiments, private cloud gateway <NUM> and public cloud gateway <NUM> may only prevent entry of unauthorized data into their cloud networks. In other embodiments, private cloud gateway <NUM> and public cloud gateway <NUM> may only prevent unauthorized data from leaving their respective cloud networks.

<FIG> also illustrates a hybrid cloud manager <NUM> within the private cloud <NUM> which can be a management plane VM for auto-provisioning resources within the hybrid cloud environment. Specifically, the hybrid cloud manager <NUM> may be a management platform (which could be a VM) operating in private cloud <NUM> or public cloud <NUM> (not shown), and may be generally responsible for providing the hybrid cloud environment operations, translating between private cloud network and public cloud network interfaces, management of cloud resources, dynamic instantiating of cloud gateways and cloud VM components (for example, VM3 <NUM> in public cloud <NUM>) through, for example, the private virtualization platform and public cloud provider APIs. It may also health-monitor the components of the hybrid cloud environment (e.g., the cloud gateways, the one or more private application VMs, and the communication link <NUM>, and provide high availability of those components.

<FIG> also illustrates a virtual supervisor module <NUM> (for example, the Nexus 1000V Switch by Cisco Systems, Inc. ), a hypervisor <NUM> (also called a virtual machine manager) and one or more VM <NUM>, <NUM>. The virtual supervisor module <NUM> in the private cloud <NUM> can be used to create VMs in the public cloud <NUM> or private cloud <NUM>, such as VM1 <NUM>, VM2 <NUM>, and VM3 <NUM>. Each VM can host a private application, even VM3 <NUM> in the public cloud <NUM> can host a private application such that VM3 <NUM> in the public cloud <NUM> executes as if it were within the private cloud <NUM>. The hypervisor <NUM> can be configured by the virtual supervisor module <NUM> and may provide an operating system for one or more VMs.

<FIG> also illustrates communication link <NUM>. Communication link <NUM> can take several forms to include a type of virtual private network (VPN) or a tunnel. Specifically, some embodiments may utilize an open VPN overlay or else an IP security (IPSec) VPN based L3 network extension to provide communication link <NUM>. While offering secure transport connections in a cloud environment, a VPN may not provide a switch infrastructure for providing features such as switching network traffic locally at the cloud, providing consistent enterprise network polices, allowing insertion of various network services (e.g., load balancers, firewalls, etc.), and construction of a sophisticated network topology (e.g., the current systems are connected through a router and multiple VLANs). While IPsec-VPN-based technology can provide customers inter-datacenter network connectivity and relatively sophisticated network topologies, it can only extend the enterprise network at the network layer (Layer <NUM> or "L3" of the illustrative and well-known OSI model). This implies that the overlay networks created at the cloud datacenter (public cloud <NUM>) can be a set of new subnets, where VMs in the public cloud are assigned with new network identities (e.g., IP and MAC addresses). Because of this, many enterprise infrastructures (e.g., access control lists, firewall policies, domain name services, etc.) can be modified in order for the newly attached VM systems to be able to work with rest of the enterprise systems. For example, the IPSec VPN tunnel may prevent penetration of corporate firewalls and Network Address Translation (NAT) devices deep within the enterprise data center (for example, private cloud <NUM>).

Some hybrid cloud technologies, such as embodiments of the presently described technology, can utilize a secure transport layer (e.g., Layer <NUM> or "L4") tunnel as the communication link <NUM> between a first cloud gateway <NUM> in a private cloud <NUM> and a second cloud gateway <NUM> in a public cloud <NUM>, where the secure transport layer tunnel is configured to provide a link layer <NUM> (e.g., Layer <NUM> or "L2") network extension between the private cloud and the public cloud. By establishing a secure transport layer (L4) tunnel <NUM> (e.g., transport layer security (TLS), datagram TLS (DTLS), secure socket layer (SSL), etc.) over the public cloud network <NUM>, the techniques herein may build a secure L2 switch overlay that interconnects cloud resources (public cloud <NUM>) with private cloud <NUM> (e.g., enterprise network backbones). In other words, the secure transport layer tunnel <NUM> can provide a link layer network extension between the private cloud <NUM> and the public cloud <NUM>.

As noted, the cloud gateway <NUM> deployed at the private cloud <NUM> can use an L4 Secure Tunnel to connect to the cloud resources allocated at public cloud <NUM>. The L4 secure tunnel is well-suited for use with corporate firewalls and NAT devices due to the nature of the transport level protocols (e.g., UDP/TCP) and the transport layer ports opened for HTTP/HTTPS in the firewall. The L2 network may extend and connect to each of the cloud VMs, e.g., VM1 <NUM>, VM2 <NUM>, VM3 <NUM> through the cloud gateway <NUM> deployed at the public cloud <NUM>. With an L2 network overlay, all instances of a particular private application VM, e. g, VM3 <NUM> can be seamlessly migrated to the overlay network dynamically created at the public cloud, without any impacts to the existing corporate infrastructure.

As a general practice, a public cloud service provider offers only a limited number of network attachments for each of the cloud VMs, e.g., VM3 <NUM>, and network broadcasting capability. This can prevent enterprise customers from migrating their multi-VLAN network architectural environment into the public cloud datacenter. However, building an L2 network overlay on top of L4 tunnels as described herein reduces the network attachments requirements for cloud VMs and may provide cloud VMs with network broadcasting ability. The techniques herein can allow enterprise customers to deploy consistent enterprise-wide network architectures, even in a hybrid cloud network environment.

<FIG> illustrates a hybrid cloud environment as illustrated in <FIG> being used to migrate a VM from private cloud <NUM> to public cloud <NUM>. In some embodiments, a VM on the private cloud may need to be scaled beyond the current resources of the private cloud or the private cloud may need to be taken off line for a period of time. In some embodiments, it can be desirable to migrate an application on the private cloud <NUM> to the public cloud <NUM> or from public cloud <NUM> to private cloud <NUM> (not shown). <FIG> illustrates VM1 <NUM> on private cloud <NUM> being migrated to public cloud <NUM>. Migration can be managed using virtual supervisor module <NUM> to take VM1 <NUM> offline, and may be migrated using hybrid cloud manager <NUM> to copy the VM1 <NUM> disk image to public cloud <NUM>, and instantiate it in the public cloud <NUM>.

<FIG> illustrates an example hybrid cloud environment. In <FIG>, a public cloud <NUM> can be running, for example, an application or service in VM4 <NUM>. The application or service can be shared by the enterprise private cloud <NUM> and partner private cloud <NUM>. In some embodiments, private cloud <NUM> can act as an intermediary that provides limited access to the enterprise and the partner. It should be understood that many other hybrid cloud network architectures may be utilized besides the example architecture of <FIG>. In some embodiments, a hybrid cloud network may include one or more enterprise private clouds, one or more physical enterprise servers, one or more public clouds, one or more physical public network servers, or any combination of such clouds and servers. In addition, embodiments of the present technology can provide for the secure migration of data, virtual machines, etc. among all of the different cloud networks (public and private) and physical servers in a hybrid cloud computing environment. For example, VM4 <NUM> may be migrated to enterprise private cloud <NUM> and/or partner private cloud <NUM>. Likewise, some embodiments can provide for the migration of, for example, VM3 to enterprise private cloud <NUM> and/or public cloud <NUM>.

<FIG> illustrates an example hybrid cloud environment. Data Center (DC)/private cloud <NUM> may be connected to provider/public cloud <NUM> via secure communication link <NUM>. Private cloud <NUM> can be a cloud-based network designated for a particular enterprise. Private cloud <NUM> may contain sensitive data that is not intended to be shared outside of private cloud <NUM> without authorized access. Provider cloud <NUM> may be a publicly-accessible cloud-based network that is provided by a third party commercial vendor such as Oracle®, Amazon®, Microsoft®, etc. Item <NUM> represents one of many sub-nets, VLAN sub-nets, virtual machines, or other data that can be stored in data center/private cloud <NUM>. Likewise, item <NUM> represents one of many sub-nets, VLAN sub-nets, virtual machines, or other data that can be stored in provider cloud <NUM>. Items <NUM> and <NUM> can represent enforcements points for security policies/hybrid cloud security groups which may dictate the entry and exit of data/applications/VMs from private cloud <NUM> and provider/public cloud <NUM>.

For example, items <NUM> and <NUM> may be gateways which are utilized to enforce hybrid cloud security groups/security policies. Hybrid cloud security groups can be automatically applied to data/applications/VMs that appear in the hybrid cloud network so that the data/applications/VMs are grouped according to authorized hybrid cloud access locations. For instance, an application represented by item <NUM> may be requested for migration to provider cloud <NUM>. If VM <NUM> does not have the appropriate security group tag to exit private cloud <NUM> and enter provider cloud <NUM>, gateway <NUM> can prevent VM <NUM> from leaving private cloud <NUM>.

If VM <NUM> does have the appropriate security group tag to exit private cloud <NUM> and enter provider cloud <NUM>, gateway <NUM> can allow VM <NUM> to leave private cloud <NUM> via secure link/tunnel <NUM>. VM <NUM> may also have its data copied and instantiated in provider/public cloud <NUM> in some embodiments. Gateway <NUM> can act as a gatekeeper, in some embodiments only permitting data from an authorized security group to enter provider/public cloud <NUM>. Secure link <NUM> may be secured with cryptography such that the communications between private cloud <NUM> and public cloud <NUM> are not detectable to outside parties. Furthermore, in some embodiments, secure link/secure tunnel <NUM> may not allow access to or from the Internet in order to enhance security by transmitting all sensitive data/applications/VMs via secure link <NUM> only.

Hybrid cloud security groups may be configured manually by an administrator of the private cloud <NUM> and/or public cloud <NUM>. For instance, an administrator of private cloud <NUM> may configure the present technology to automatically apply security group tags to data/applications/VMs on the basis of, for example, origin IP address, type, author, date created, etc. Upon instantiation of an embodiment of the present technology, all or some of the data/applications/VMs may be assigned to one or more cloud security groups. For example, some data/applications/VMs can be authorized for use by the private cloud, the public cloud only, or both the private and public clouds. This can allow for greater flexibility of movement of data inside a particular cloud environment while preserving security because all data that has a cloud security group tag should only be permitted in authorized areas associated with their respective cloud security group(s).

<FIG> illustrates an example hybrid cloud environment. As in <FIG>, the example embodiment of <FIG> can include data center/private cloud <NUM>, provider/public cloud <NUM>, and secure link/tunnel <NUM>. <FIG> illustrates an example application of hybrid cloud security groups wherein data/applications/VMs (not shown) are requesting exit from private cloud <NUM> in order to enter provider/public cloud <NUM>. As discussed with respect to <FIG>, private cloud gateway <NUM> can verify that any data, applications, VMs, etc. attempting to exit the private cloud <NUM> are authorized to leave private cloud <NUM>.

For example, programming code <NUM> may provide private cloud gateway <NUM> with parameters for authorized entry/exit from private cloud <NUM>. It is understood that programming code <NUM> may be implemented in many other forms besides that shown in <FIG>. Moreover, embodiments of the present technology may utilize one or more programming languages to determine parameters for different hybrid cloud security groups. In some embodiments, programming code <NUM> may provide for entry parameters and/or exit parameters of private cloud <NUM>. <FIG> illustrates that, in some embodiments, data may not be permitted to leave private cloud <NUM> if the hybrid cloud security group tag associated with the data, based on parameters that may be defined by an administrator, does not authorize exit from private cloud <NUM>. For example, if an application from private cloud <NUM> is not a part of a selected subnet that has a security group tag allowing for exit from private cloud <NUM>, the application will be denied exit from private cloud <NUM> as shown at private cloud gateway <NUM>.

In other embodiments, if data requested from private cloud <NUM> has a security group tag authorizing exit from private cloud <NUM>, based on an allowed subnet, said data may be transmitted to provider public cloud <NUM> via secure tunnel <NUM>. Some embodiments may provide for similar screening of transmitted data at provider public gateway <NUM> in order to ensure that the data is part of an authorized security group for access into provider public cloud <NUM>. It is understood that a request for data from private cloud <NUM> may come from within private cloud <NUM>, within provider public cloud <NUM>, or from a third party/parties.

<FIG> illustrates an example hybrid cloud environment. As in <FIG>, the example embodiment of <FIG> can include data center/private cloud <NUM>, provider/public cloud <NUM>, and secure link/tunnel <NUM>. <FIG> illustrates an example application of hybrid cloud security groups wherein data/applications/VMs (not shown) are requesting exit from provider public cloud <NUM> in order to enter private cloud <NUM>. As discussed with respect to <FIG>, public cloud gateway <NUM> can verify that any data, applications, VMs, etc. attempting to exit the public cloud <NUM> are authorized to leave public cloud <NUM>.

For example, programming code <NUM> may provide public cloud gateway <NUM> with parameters for authorized entry/exit from public cloud <NUM>. It is understood that programming code <NUM> may be implemented in many other forms besides that shown in <FIG>. Moreover, embodiments of the present technology may utilize one or more programming languages to determine parameters for different hybrid cloud security groups. In some embodiments, programming code <NUM> may provide for entry parameters and/or exit parameters of public cloud <NUM>. <FIG> illustrates that, in some embodiments, data may not be permitted to leave public cloud <NUM> if the hybrid cloud security group tag associated with the data, based on parameters that may be defined by an administrator, does not authorize exit from public cloud <NUM>. For example, if an application from public cloud <NUM> is not a part of an extended VLAN that has a security group tag allowing for entry into private cloud <NUM> from public cloud <NUM>, the application will be denied exit from public cloud <NUM> as shown at public cloud gateway <NUM>.

In other embodiments, if data requested from public cloud <NUM> has a security group tag authorizing exit from public cloud <NUM>, based on an allowed extended VLAN, said data may be transmitted to private cloud <NUM> via secure tunnel <NUM>. Some embodiments may provide for similar screening of transmitted data at private gateway <NUM> in order to ensure that the data is part of an authorized security group for access into private cloud <NUM>. It is understood that a request for data from provider public cloud <NUM> may come from within provider public cloud <NUM>, within private cloud <NUM>, or from a third party/parties.

<FIG> illustrates an example hybrid cloud environment. As in <FIG>, the example embodiment of <FIG> can include data center/private cloud <NUM>, provider/public cloud <NUM>, and secure link/tunnel <NUM>. <FIG> illustrates an example application of hybrid cloud security groups wherein an instance (not shown) of the hybrid cloud environment is screened for authorization based on the security group associated with the instance. For example, <FIG> shows instance <NUM> attempting access to provider public cloud <NUM>. Instance <NUM> does not have a security group tag authorized for entry into provider public cloud <NUM>. Thus, public cloud gateway <NUM> denies access to instance <NUM> such that instance <NUM> is not allowed to reach hybrid VM <NUM>. On the other hand, if an instance from private cloud <NUM> has a security group tag authorizing exit from private cloud <NUM> and entry into public cloud <NUM>, the instance may be transmitted to provider public cloud <NUM> via secure tunnel <NUM>.

In some embodiments, the present technology can utilize the security structure of the provider public cloud in order to enhance security. For example, if the provider public cloud has its own security parameters/security groups for data entering the public cloud (e.g., Amazon AWS® security groups), embodiments of the present technology may apply those security parameters in place of or in addition to the security parameters of the hybrid cloud security group associated with the data requesting entry into the public cloud.

For example, <FIG> illustrates an example hybrid cloud environment utilizing security parameters/security group settings of a provider public cloud <NUM>. As in <FIG>, the example embodiment of <FIG> can include data center/private cloud <NUM>, provider/public cloud <NUM>, secure link/tunnel <NUM>, and gateways <NUM> and <NUM>. <FIG> illustrates example security parameters/security group settings <NUM>. For example, security group settings <NUM> may be provided by Amazon AWS® and may complement the security features provided by the private cloud <NUM> security group settings by providing additional security requirements for entities requesting access to the provider public cloud <NUM>. It is understood that many other security settings may be used besides what is shown in <FIG>.

<FIG> illustrates an example process <NUM> of the present technology. Process <NUM> begins at <NUM> where a request is received from a first cloud network of a hybrid cloud environment to transmit data to a second cloud network of the hybrid cloud environment. Process <NUM> continues at <NUM> where a security profile of the request is automatically analyzed to determine access permissions. Example process <NUM> concludes at <NUM> where, based at least in part on the access permissions, the data is allowed to access the second cloud network of the hybrid cloud environment. It is understood that embodiments of the present technology may include fewer or more steps than process <NUM>.

<FIG> illustrates an example computer system <NUM> having a chipset architecture that can be used in executing embodiments of the present technology and generating and displaying a graphical user interface (GUI). Computer system <NUM> is an example of computer hardware, software, and firmware that can be used to implement embodiments of the disclosed technology. System <NUM> can include a processor <NUM>, representative of any number of physically and/or logically distinct resources capable of executing software and/or firmware, and utilizing hardware configured to perform identified computations. Processor <NUM> can communicate with a chipset <NUM> that can control input to and output from processor <NUM>. In some embodiments, chipset <NUM> outputs information to output <NUM> (for example, a display) and can read and write information to storage device <NUM> (for example, magnetic media and solid state media). Chipset <NUM> can also read data from and write data to RAM <NUM>. In some embodiments, a bridge <NUM> may be utilized by chipset <NUM> for interfacing with a variety of user interface components <NUM>. Such user interface components <NUM> can include a keyboard, a microphone, touch detection and processing circuitry, a pointing device, such as a mouse, and the like. In general, inputs to system <NUM> can come from any of a variety of sources, machine generated and/or human generated.

Chipset <NUM> can also interface with one or more communication interfaces <NUM> that can have different physical interfaces. Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, as well as personal area networks. Some applications of the methods for generating, displaying, and using the GUI disclosed herein can include receiving ordered datasets over the physical interface or be generated by the system itself by processor <NUM> analyzing data stored in storage <NUM> or <NUM>. Further, the system can receive inputs from a user via user interface components <NUM> and execute appropriate functions, such as browsing functions by interpreting these inputs using processor <NUM>.

It can be appreciated that example system <NUM> can have more than one processor <NUM> or be part of a group or cluster of computing devices networked together to provide greater processing and/or storage capabilities.

Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, and the like.

Devices implementing methods according to these disclosures can comprise hardware, firmware, and/or software, and can use a variety of arrangements or form factors. Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, rackmount devices, standalone devices, and the like.

Moreover, claim language reciting "at least one of" a set indicates that one member of the set or multiple members of the set satisfy the claim.

The techniques disclosed herein can provide increased security with respect to network resources and data in a hybrid cloud environment. Embodiments of the present technology can prevent harmful and/or unauthorized entities from entering the hybrid cloud network environment, which may result in more efficient network routing and high availability of network applications and systems, which in turn may result in fewer processor cycles required to route signals and thus improved efficiency and extended service life of the network processors used to implement some embodiments of the present technology. Thus, the present technology may improve related hardware used in its implementation.

Claim 1:
A method comprising:
receiving a request from a first cloud network of a hybrid cloud environment at a gateway of a second cloud network of the hybrid cloud environment to transmit data from the second cloud network to the first cloud network
performing, at the gateway of the second cloud network, an access determination by automatically analyzing a security group tag associated with the data to determine whether the data is allowed to exit the second cloud network, the automatically analyzing including an analysis of whether the security group tag includes access permissions to the data, the access permissions indicating that the data is allowed to exit the second cloud network and
based at least in part on the access determination, allowing the data to exit the second cloud network via the gateway.