Now let me talk a little bit about the process of how to actually
deploy these third-party network introspection surfaces.
There's a couple of prerequisites,
the first thing of course you will not need to have Vcenter.
You need to deploy as NSX-V. You'll need to actually
deploy a partner management console or a Partner Manager,
and then you'll need to obtain a partner OVA
which will be the OVA that gets deployed on the host,
where you deploy the partner surface.
Once you've done that, once you've met the prerequisites,
you can start with the actual surface onboarding.
The first thing in an onboarding is actually deploying the partner management console.
Once you've deployed the partner management console,
you can register that console with NSX manager.
Once that is done, the surface for example
a next-generation fireball surface will appear in the surface catalog of NSX.
Once you've done that, you can then choose pick that partner surface,
and deploy it to select clusters in your environment.
Then once you've done the deployment,
we get to surface consumption.
Surface consumption basically means how am I going to use the surface,
what traffic will I redirect to this next generation firewall, to this IPS.
So, in order to do that, you can create security groups.
Security groups can be created based on security tags for example,
in order to have a very dynamic policy,
and then you can create a redirection policy which you then apply to the security groups,
and select which traffic should be steered to
which of our network introspection services.
Then of course once you've done that on a continuous basis,
you want to monitor the surface,
we provide alerting mechanisms to identify if something is not going to wait shoot,
but a third-party service.
We also enable rapid redeployment of a partner surface if that would be required.
So, let's have a brief look here at
the architecture of how we implement network introspection.
You are using the VM ware service insertion platform.
As I mentioned on the previous slide,
the first thing you will need to do in order to deploy
a network introspection service is to deploy the partner service manager.
Once you've done that, the partner Surface Manager will create a catalog in NSX manager,
and you'll be able to deploy the actual service on a cluster.
Once you do that, when you choose to do that all of the hosts in
the clusterable get the partner surface VM deployed on it.
This part of the surface VM has a couple of
built-in components that allow it to receive data,
to receive packets from the VMware surface insertion platform.
That all happens through the VMCI channel
which is a proprietary channel on the hypervisor.
Between every VM's Phoenix and a distributed switch,
we have something called IO chains.
IO chains are basically slots that allow us to
insert specific surfaces in between the VM,
and the actual distributed switch.
One of these IO chains is used by the distributed firewall,
that slot number two there's in total 16 slots available.
Slot number four through slot number 11 are available for network introspection surfaces.
So, let me quickly walk you through some packet flow here.
Let's say that we have a packet being originated from the VM that you can see here.
First all, the packet is goning to go through the IO chain,
and it's going to go through slot two at which
the distributed firewall matches the packet against distributed firewall rules.
If the flow is allowed,
if the packet is allowed by distributed firewall rule,
the packet is sent back onto the IO chain,
and is then validated against redirection roles.
If the packet matches a redirection rule,
the packet is then redirected to the specified network introspection surface.
For example all next generation firewall,
the packet is processed again,
and if the packet is allowed it's sent back or it's sent on his way to the destination.
So, that was a quick overview of the architecture.
Now, let me talk about a couple of common design patterns.
This slide shows one of the most common micro-segmentation design patterns.
Of course, as you've learned micro-segmentation really allows
customers to segment every workload from every other workloads,
regardless of the underlying network topology.
If you look at this diagram,
you can see that we have two VLANS here connected
to an ESG connected to an edge surfaces gateway.
Can say that the VLAN on the top for example,
this might represent the web VLAN and all of
the VMs that are connected to that VLAN may for example be web VMs,
could represent our web tier.
Let's imagine for this exercise here,
that the VMs at the bottom are connected to an application VLAN.
Now, all the VMs on the web,
and the VMs on the application vVLAN are VMs that don't belong to the same application.
So, there's multiple applications that are on the same vVLAN.
With micro-segmentation, we can of course isolate these VMs from each other,
and we can enforce what we call controlled communication,
which means that we can specify that a VM for application one,
the web tier should only be able to talk to
the application tier for that particular application on a specific port.
So, that's our core micro-segmentation use case on VLAN back networks,
doesn't require any changes to the network,
and it's all implemented using the distributed firewall that
sits at the venuc of every virtual machine.
Now, on top of that with surface insertion,
we can also selectively choose to redirect traffic to a partner service.
This is for example, we can choose any traffic going in or out
of the web tier to be redirected to a partner service,
while any traffic going to or in between
other theories should be handled natively by the distributed firewall.
This was another design pattern,
and this is pretty similar,
but here we're also using network virtualization.
So, network virtualization allows us to virtualize and deliver not just the security,
but also the networking at the time the application is provisioned.
So, that enables complete independency from the underlying physical network,
and also from a security perspective here,
this use case is exactly the same as before,
so the distributed firewall is enforced at the Venuc of every VM,
and at the same venuc we have the ability to
selectively steer traffic to our partner service.
So, now that we've seen the architecture,
we've seen a couple of common deployment patterns,
let me talk a bit about some commonly use cases.
Advanced security for selective application tiers is one of
the main use-cases customers use network introspection for,
and this is what I mentioned earlier, right?
So, customers want to selectively apply layer seven surfaces like
IPS ideas or next generation firewall to a select set of traffic,
interesting traffic for example,
traffic going into the web tier.
So, we enable that with NSX, with redirection roles.
Multi-tenancy is another common use case,
and with service insertion we support the ability to create
multiple surface profiles which can then be applied to a different tedency.
So, you can basically create a one next generation firewall policy,
create another next generation firewall policy on the partner surface,
and then within NSX,
you can specify that for each tenant traffic
should be steered to a different security policy.
DMZ anywhere is another common use case for network introspection.
This is somewhat similar to the first use case in a sense that
the DMZ anywhere customers can choose to make
any workload regardless of where it lives in the environment at DMZ tier,
and then selectively choose if or if not
network introspection should be applied to that DMZ tier.
Remote and branch office perimeter is another use case.
NSX cannot be deployed only in the data center,
but can also be deployed in other locations such as remote and branch office.
Typically in a remote and branch office when customers
leverage technologies such as SD one,
they're also introducing a new network perimeter.
The internet now becomes the local metric perimeter at a branch for
steering all the traffic across from the branch to the main office.
So, because the internet now becomes the new perimeter,
customers typically need next generation firewall surfaces,
and this is another use case for surface insertion with NSX.
Then the last one on the list here is advanced security for VDI.
I mentioned this use-case earlier as well.
Imagine a VDI environment where users access their desktops.
Typically an end-user needs functionality like bureau filtering for example.
You want to limit which categories of urls your users are able to access,
and for that you also need network introspection,
you need a next generation firewall surface that can be
selectively applied to desktops even based on user groups using NSX.
So, let me look at an example here of
advanced security for select application or application tiers.
One thing that you can do with NSX is you can apply security tags.
Security tags make your security policy dynamic.
A security tag can be applied using automation to
a workload or to an application when that application is being provisioned.
Based on a security type being applied a VM
will then become a member of a particular security group
and a representative security policy will then be applied to that group.
So, looking at a quick example here,
this is actually based on something that one of our customers did,
is they had a requirement to specifically apply
surface insertion or a layer seven firewalling to specific applications.
They had grouped their applications or using
network overlays or looking at distributed logical rather here,
but they had grouped their workloads into specific logical switches
based on the confidentiality level of those applications,
and the data that those applications handle.
In case of this customer,
they had four logical switches representing this level of confidentiality,
there's logical switch one that represents confidential,
logical switch two is internal,
logical switch three are public applications,
and logical switch four are non-production applications.
Now, the security requirement for this customer was
to ensure that all the traffic coming in or
going out of the logical switch one to
confidential applications should pass through an X generation firewall.
On top of that, they had an additional requirement.
Any traffic coming into a web tier of an application,
coming into a web server of an application
regardless of which logical switch that application in,
should also pass by a layer seven firewall.
So, in order to do that,
they've applied security tanks to each
of the workloads at the moment the workload is deployed.
So, through automation, when a workload is deployed,
and that workload is a web server,
a web server security tag is uploaded at VM,
sent to database server or an application server.
Then they've created steering policies,
you can see on the left is steering policy that it redirects all traffic coming into
the confidential logical switch to the next generation firewall.
On the right you can see a steering policy that redirects all traffic
coming into any VM that has that web server security tag applied to it,
redirect that as well to the next generation firewall.