We now dig deeper into the cloud security use-case. As more and more companies embrace cloud, the cloud IT teams are tasked with the responsibility of ensuring that these cloud deployments are secure. Cloud inherently brings in new environments, and these cloud security teams are now faced with ensuring Enterprise security policy consistency across these multiple disparate cloud environments.
VMware NSX Cloud addresses these challenges, offering a common security and micro-segmentation platform across the on-premises and cloud environment. Together with NSX Data Center, it provides a single pane of glass to provision and manages consistent security controls not only for cross-cloud communication but also within each cloud.
Let’s start with VISIBILITY. You can’t protect what you can’t see. As a cloud infrastructure/security team, you may have to manage 1 AWS cloud account (subscription in Azure) and 1 AWS VPC (VNET in Azure) … or you may be managing 500+ accounts/subscriptions, each having multiple VPCs / VNETs. As cloud deployments bring automation and higher levels of agility, the cloud footprint that you would be responsible for can quickly become large and constantly evolve. How do you ensure that this dynamic environment is secure?
Focused on this specific issue, NSX Cloud created the Cloud Service Manager (CSM). CSM sits adjacent to the NSX Manager and provides a complete inventory view for your entire cloud deployment, across multiple clouds, multiple regions, multiple subscriptions/accounts and multiple VPCs/VNETs. This enables you, as a cloud security administrator, to have a single pane of glass to manage security for all your cloud workloads from one screen.
Each tile above provides a summary view that can be drilled down into… starting with cloud, moving to accounts/subscriptions within the cloud, then listing out deployed regions per account/subscription, VPCs / VNETs in each region and finally, a list of all VMs deployed in each VPC. The donut chart indicates status, green for “Managed by NSX” (good), grey for “Not Managed by NSX” and more importantly, red for any errors / quarantined VMs. In one screen, the security admin gets a summary snapshot into his cloud security posture.
Moving beyond visibility, let’s examine Security ENFORCEMENT. Securing a hybrid cloud environment today, without NSX Cloud, implies that you will use security constructs inherently from the underlying platform(s). Hence, you may have NSX on-premise for micro-segmentation within your datacenter, along with a perimeter firewall at the DMZ, then you will program security rules in AWS for each VPC that you are managing, as well as create similar (but not the same) native security groups in Azure for each VNET. As you add more VPCs / VNETs, you go and replicate the security rules/groups. As workloads move across clouds, you go back and update cloud security rules/groups. Also, cloud security group membership is static and needs to be set at time of VM deployment.
Using NSX Cloud enables you to have a single security micro-segmentation policy across your entire hybrid cloud. You can create this security policy based on a rich set of abstractions, e.g., VM names, VM attributes, custom tags etc. As NSX determines group membership dynamically, you do not need to set up security rules at time of VM deployment. As a security admin, you can create a policy even if the VMs are yet to be deployed by the DevOps teams. As these VMs are deployed, NSX discovers these VMs and dynamically allocates security group membership to each. Hence, security rules are enforced at VM bring up. Furthermore, you do not need to replicate these rules across VPCs / VNETs or even clouds. The same security policy can be applied to your entire cloud deployment (default), hence as VMs move from on-premise to cloud, there is no change in the security posture. You can of course, narrow down the scope of the security rules to apply to a specific set of VMs as desired. NSX Cloud’s distributed firewall architecture eliminates additional network hops and traffic because policies are enforced right at the VM.
NSX Cloud also has the Default Quarantine feature, in which a security administrator can, on a per VPC/VNET level, determine NSX response to new VMs instantiated within the VPC/VNET. If Default quarantine is ON, and NSX discovers a new VM instantiated within the VPC / VNET that has a configuration anomaly, e.g., a wrong tag, VM instantiated from a wrong template without the NSX agent, etc., NSX Cloud can automatically isolate the VM and disallow all connectivity to the VM. Default quarantine ensures that rogue and compromised workloads are quarantined and prevented from communicating on the cloud network.
Finally, after we discuss Security Enforcement, let’s close with Security Auditability. In a multi-cloud environment, you will have to collate logs from each cloud footprint, perhaps combining on-premise logs with AWS flow-logs and Azure nsg logs. NSX Cloud provides real-time network trace and visibility into Firewall Rule Invocations. These logs are in industry standard syslog formats and can be data-mined by any SIEM tool of choice. This provides real-time operational visibility into the cloud security posture and provides consistent view of the security constructs between on-prem and public cloud environments.
NSX Data Center already provides granular micro-segmentation through a distributed firewall. NSX Cloud extends this to Public Cloud deployments and provides a single pane of glass for security provisioning and management across the hybrid cloud.
In subsequent blogs, we also examine how NSX Cloud helps with networking and service insertion. This blog is part of a series of NSX Cloud blogs that go over the feature set of NSX Cloud. Learn more about NSX Cloud at NSX Cloud.
More from the NSX Cloud Blog Series:
The post NSX Cloud Blog Series Part 2: A Consistent Security Posture Across Your Hybrid Cloud appeared first on Network Virtualization.