Private Cloud Security for Cisco ACI Infrastructure

S E C U R E Y O U R E V E R Y T H I N G

2PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

TABLE OF CONTENTS

Introduction 3

Cisco ACI Concepts and Services Overview 4 Terminology 4 Design Principles 12

Check Point Integration with Cisco ACI CloudGuard Controller and Cisco APIC 15 Mapping Service Contracts with Check Point Security Policies 16 Connecting Security Gateways to the ACI Infrastucture 18 Deployment Options for Check Point Security Gateways 24

CloudGuard and Cisco ACI Integration Benefits 25

Security Design and Architecture Design Principles 27 Architecture Blueprints 39

Summary 44

3PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

IntroductionAs companies embark on their application and data modernization programs and look to the cloud and

infrastructure required to support their plans, most land on a hybrid cloud strategy with application

and data workloads balanced across both public and private clouds.

Hybrid deployments combine the hyper-scalers’ public cloud benefits of innovation, speed,

consumption, and scale with private benefits of regulatory compliance, performance, data gravity,

and recouping of existing investments. It enables increasingly dynamic workload placement over

time, optimizing for performance, service levels, security, compliance, and cost. In addition, hybrid

deployments establish the same level of operations and management in the public and private cloud

environments, e.g. unified management, flexibility, agility.

Cisco Application Centric Infrastructure (ACI) is a mature SDN (Software Defined Network) that gives

enterprises of all sizes access to “cloud-like” performance, availability, resilience, monitoring, and

automation. For those enterprises that want to build their own on-prem private clouds, Cisco ACI

provides the features to deliver exactly that. Moving to a security model that is not dependent on

network or routing topology allows customers to deliver a fundamentally more secure approach to

data and network security, by leveraging the cloud-like features of Cisco ACI.

Check Point CloudGuard for Cisco ACI delivers industry-leading security management and

enforcement tailored to protecting customer information assets. Security service insertion in modern,

application-centric private and hybrid cloud networks is a sophisticated, yet simple, way to design,

deploy, scale and operate.

4PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Cisco ACI Concepts and ServicesOverviewCisco ACI enables a new open security policy framework that expresses policies using the language of the application rather than network. Policies are defined based on a language that is natural to application owners and not in terms of classical networking constructs like VLANs, IPs, and MAC addresses. This group-policy approach decouples security policy and segmentation from the underlying network topology.

TerminologyApplication Centric Infrastructure—ACIA software-defined data center solution that uses an application-centric policy model to enable rapid application deployment. You should deploy the ACI data center infrastructure in a spine-leaf topology and implement it on Cisco Nexus 9000 series switches.

Cisco APICCisco APIC is the main architectural component of Cisco ACI. It is the unified point of automation and management for the Cisco ACI fabric, policy enforcement, and health monitoring. Cisco APIC is the creation, repository, and enforcement point for Cisco ACI application policies, which you can set based on application-specific network requirements. Cisco APIC also provides policy authority and resolution mechanisms.

To understand how Cisco ACI integrates with Check Point Security Gateways, it is important to define two views: Infrastructure and Logic. Infrastructure relates to all the physical components: switches, routers, etc. Logical relates to all the configurations within the switch fabric to create the communication between the workloads.

ACI Policy ModelThe ACI policy model provides a convenient way to specify application requirements, which the APIC then renders in the network infrastructure. This is an object-oriented model consisting of a number of constructs such as tenants, contexts, bridge domains, end point groups, and service graphs. The policy model is based on promise theory which allows for declarative, scalable, control of intelligent objects. Promise theory relies on the underlying objects handling configuration state changes initiated by the control system. This reduces complexity of the controller and allows for greater scale.

5PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

SpineSpines are special switches that provide the backbone of the ACI fabric. All Leaf switches must connect to the spines and the spines take care of the leaf to leaf traffic. Spine switches often contain many 40 or 100GbE ports. These ports provide the required bandwidth for the ACI fabric.

Figure 1: Cisco ACI Policy Model 1

Figure 2: Spine and Leaf Topology 2

1 Source: Cisco Application Policy Infrastructure Controller Data Center Policy Model - URL: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-731310.html

2 Source: Cisco Data Center Spine-and-Leaf Architecture: Design overview White paper: https://www.cisco.com/c/en/us/products/collat-eral/switches/nexus-7000-series-switches/white-paper-c11-737022.html

6PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

LeafsWithin ACI’s spine-leaf topology, leaf switches are the connection point into the ACI fabric for all endpoints, such as routers, firewalls, etc. By enabling all endpoints to connect at the same layer, leaf switches can be defined based on endpoint roles that are attached to them.

• Computing Leaf Switches – Used to connect to computer systems.

• Service Leaf Switches – Used to connect to Layer 4-7 service devices, such as application load balancers and firewalls.

• IP Storage Leaf Switches – Used to connect to IP storage systems.

• Border Leaf Switches – Used for external connectivity. External routers are supported for routing and policy enforcement for traffic between internal and external endpoints.

• Transit Leaf Switches – Used to connect to the spines on other data centers. It exists only in stretched fabric topologies.

• Management Leaf Switches – Used to connect to the OOB Network for the Operations and Management services for the infrastructure.

Single PodA Pod is a set of interconnected leaf and spine switches (ACI Fabrics) that are under the control of a specific APIC cluster.

Multi-PodThe Multi-Pod 3 is the architecture with multiple ACI fabrics that are under control of single management or administration.

InterPod Network (IPN)All the pods within the topology are interconnected using an IP routed Inter-Pod Network 4, being a type of transport that supports IP Routing and Multicast to allow the interconnection between the Pods, the connectivity within each pod to the IPN takes place on the spine nodes. The IPN is not managed by the APIC and should be configured separately.

3 Source: Cisco ACI Multi-Pod White Paper - URL: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/appli-cation-centric-infrastructure/white-paper-c11-737855.html

4 Source: Cisco ACI Multi-Pod White Paper, Inter-Pod Connectivity Deployment Considerations - URL: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-737855.html#InterPodConnectivi-tyDeploymentConsiderations

7PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Multi-SiteThe Multi-site 5 architecture is the interconnection between multiple APIC cluster domains with their associated pods. A Multi-Site design could also be called a Multi-Fabric design, because it interconnects separate availability zones ( ACI fabrics), each deployed either as a single pod or multiple pods (a Multi-Pod design).

InterSite Network (ISN)The InterSite Network 6 allows all communications between endpoints (EPG’s) connected to different sites (Private Cloud or Public Cloud) can be achieved by establishing site-to-site Virtual Extensible LAN (VXLAN) tunnels across a generic IP network that interconnects different sites. The use of site-to-site VXLAN encapsulation greatly simplifies the configuration and functions required for the intersite IP network. This IP network has no specific functional requirements other than the capability to support routing and increased maximum transmission unit (MTU) size (given the overhead from the VXLAN encapsulation).

TenantA tenant is essentially a ‘container’ used to house other constructs and objects in the policy model (such as contexts, bridge domains, contracts, filters, and application profiles). Tenants can be completely isolated from each other, or can share resources. It also represents a unit of isolation from a policy perspective, but it does not represent a private network. Tenants can represent a customer in a service provider setting, an organization or domain in an enterprise setting, or just a convenient grouping of policies.

Note: VRFs are also known as contexts; each VRF can be associated with multiple bridge domains.

5 Source: Cisco ACI Multi-Site White Paper - URL: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/appli-cation-centric-infrastructure/white-paper-c11-739609.html

6 Source: Cisco ACI Multi-Site White Paper, Intersite Network (ISN) deployment considerations - URL: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-pa-per-c11-739609.html#IntersiteNetworkISNdeploymentconsiderations

7 Source: Operating Cisco Application Centric Infrastructure, Tenants - URL: https://www.cisco.com/c/en/us/td/docs/switches/datacen-ter/aci/apic/sw/1-x/Operating_ACI/guide/b_Cisco_Operating_ACI/b_Cisco_Operating_ACI_chapter_0111.html

Figure 3: Mapping between Networking and Policy for Tenant configuration 7

8PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

The main purpose of a Tenant is of a logical separator for customer, BU, group, etc. It can be used to separate traffic, visibility, or for admin separation. A private network that is intended to be used by multiple tenants and is not created in the common tenant requires explicit configuration to be shared.

As best practice we can find the following Tenant distribution:

• Common: The common tenant is usually used as a shared services tenant. Objects created inside the common tenant are available to other tenants.

• Infrastructure: The infra tenant is used to expand the infrastructure. Multi-Pod and Multi-Site fabrics use the infra tenant to connect the pods or sites to each other. — Examples: Internal DMZ, External DMZ, Restricted Data Center

• Management: Most of the management configuration is performed in the management tenant. Here you’ll assign management IP addresses to switches and configure the contracts that will limit access to the fabric management interfaces.

VRF/Private NetworkA Virtual Routing and Forwarding (VRF) object, or context, is a tenant network (called a private network in the APIC GUI). A tenant can have multiple VRFs. A VRF is a unique Layer 3 forwarding and application policy domain. It is used to define a unique layer 3 forwarding domain within the fabric. One or more VRF can be created inside a tenant, also known as a ‘private network’, and can be viewed as the equivalent of a VRF in the traditional networking world. As each context defines a separate layer 3 domain, IP addresses residing within a context can overlap with addresses in other contexts.

Bridge Domains and SubnetsA Bridge Domain (BD) 8 is a construct used to define a layer 2 boundary within the fabric. BDs can be viewed as somewhat similar to regular VLANs in a traditional switching environment. BDs however are not subject to the same scale limitations as VLANs, and have a number of enhancements such as improved handling of ARP requests and no flooding behavior by default, additionally Bridge domains can span multiple switches and contain multiple subnets, but a subnet is contained within a single bridge domain. Figure 4: Example of a Bridge domain and SVI

8 Source: Cisco Application Centric Infrastructure Fundamentals, Bridge Domains and Subnets - URL: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI-Fundamentals_chapter_010001.html#concept_8FDD3C7A35284B2E809136922D3EA02B

9PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

A BD is a container for subnets. An SVI (Switched Virtual Interface) is a logical router which is configured for a VLAN as a default gateway in order to allow traffic to be routed between VLANs. A subnet defines the gateway (SVI) that will be used within a given bridge domain. This gateway will typically be used by hosts associated with a bridge domain as their first hop gateway. Gateways defined within a bridge domain are pervasive across all leaf switches where that bridge domain is active.

VMM DomainVirtual Machine Manager (VMM) 9 domain profiles specify connectivity policies that enable virtual machine controllers to connect to the ACI fabric. The VMM domain policy is created in APIC and pushed into the leaf switches. VMM domains contain VM controllers, such as VMware vCenter, and the credential(s) required for the ACI API to interact with the VM controller. A VMM domain enables VM mobility within the domain but not across domains. A single VMM domain can contain multiple instances of VM controllers but they must be the same kind.

Endpoint Groups (EPGs)ACI Endpoint Groups 10 (EPGs) provide a new model for mapping applications to the network. Rather than using forwarding constructs such as addressing or VLANs to apply connectivity and policy, EPGs use a grouping of application endpoints. EPGs act as a container for collections of applications, or application components and tiers, that can be used to apply forwarding and policy logic. They allow the separation of network policy, security, and forwarding from addressing and instead apply it to logical application boundaries.

Figure 5: Example of Example of WMM Domain

9 Source: Configure VMM Domain Integration with ACI and UCS B Series, Create the VMM Domain - URL: https://www.cisco.com/c/en/us/support/docs/cloud-systems-management/application-policy-infrastructure-control-ler-apic/118965-config-vmm-aci-ucs-00.html#anc5

10 Source: Cisco Application Centric Infrastructure (ACI) - Endpoint Groups (EPG) Usage and Design - URL: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-731630.html

10PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

There are multiple types of EPGs:

• Application endpoint group – This is the regular EPG we all know and love

• L2 external EPG – An EPG used to contain endpoints from external L2 connectivity (used when extending a BD to an external L2 network)

• L3 external EPG – An EPG used for external L3 connectivity (external routes)

• Management EPGs for out-of-band and in-band access

EPGs are designed to abstract the instantiation of network policy and forwarding from basic network constructs (VLANs and subnets.) This allows applications to be deployed on the network in a model consistent with their development and intent. Endpoints assigned to an EPG can be defined in several ways. Endpoints can be defined by virtual port, physical port, IP address, DNS name, and in the future through identification methods such as IP address plus Layer 4 port and others.

There is no dedicated manner in which EPGs should be deployed and utilized; instead the remainder of this document will cover some typical uses for EPGs. Examples include:

Mapping traditional network constructs to the ACI fabric

• EPG as VLAN

• EPG as a subnet (model classic networking using EPGs)

• EPG as virtual extensible LAN (VXLAN)/Network Virtualization using Generic Routing Encapsulation (NVGRE) virtual network identifier (VNID)

• EPG as a VMware port group

Utilizing the ACI fabric for stateless network abstraction

• EPG as an application component group (web, app, database, etc.)

• EPG as a development phase (development, test, production)

• EPG as a zone (internal, DMZ, shared services, etc.)

Figure 6: Example of different layers in the ACI Policy Model

11PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Application ProfileAn application profile 11 defines the policies, services, and relationships between endpoint groups (EPGs). Application profiles contain one or more EPGs. Modern applications contain multiple components. For example, an e-commerce application could require a web server, a database server, data located in a storage area network, and access to outside resources that enable financial transactions. The application profile contains as many (or as few) EPGs as necessary that are logically related to providing the capabilities of an application.

Service ContractA Service Contract 12 within Cisco ACI defines how EPGs can communicate with each other, defining the Ingress and Egress traffic flows. This is based on an allow list – without a permit contract, traffic is not allowed. Within a contract there are subjects, made up of filters, actions, and labels. A contract can have many subjects.

Service GraphUsing the service graph, Cisco ACI can redirect traffic between security zones to a firewall or a load balancer, without the need for the firewall or the load balancer to be the default gateway for the servers. Cisco ACI can selectively send traffic to L4-L7 devices (for example Check Point Devices).

Figure 7: Service Contract example

11 Source: Cisco Application Centric Infrastructure Fundamentals, Application Profile - URL: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI-Fundamentals_chapter_010001.html#concept_6914B5520ECA4731962F30F93E5A77A6

12 Source: Cisco ACI Contract Guide, How contracts work - URL: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtual-ization/application-centric-infrastructure/white-paper-c11-743951.html#Howcontractswork

12PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Firewall inspection can be transparently inserted in a Layer 2 domain with almost no modification to existing routing and switching configurations. Cisco ACI also allows you to increase the capacity of L4-L7 devices by creating a pool of devices to which Cisco ACI can distribute traffic using Symmetric PBR.

With the service graph, Cisco ACI introduces changes in the operation model. A configuration can now include not only network connectivity—VLANs, IP addresses, and so on—but also the configuration of Access Control Lists (ACLs), load-balancing rules, etc.

Design PrinciplesThe ACI Underlay network, also known as the Physical network, is the composition of all the required protocols that make the overlay network function. The principle of Clos Network defines a circuit switching that arranges a dedicated communications path for a connection between Endpoints for the duration of the connection. This principle is the standard for all modern packet-switched networks focused on Application connectivity.

Figure 8: Examples of Service Graphs for North-South and East-West traffic flows

13PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Some basic principles in the design for all ACI topology:

• Every Spine switch must be connected to every leaf switch

• Every Leaf switch must be connected to every Spine switch

• Leaf Switches must not connect to leaf switches and spine switches must not connect to spine switches

• Everything that is not a leaf switch must not be connected to a spine.

To explain Check Point’s integration with Cisco ACI, we outline three different design models for integrating properly in different Data Center models.

Single Pod DesignThis is the basic and most simple deployment of ACI. Basically it consist of several Spine switches and several leaf switches connected.

Multi-Pod DesignMultipod Fabric is managed by a single APIC Cluster and provides the capability to scale in a multipod topology requiring a special network between the Pods. This is the reason to design the Interpod Network (IPN). This IPN is external to the fabric and not managed by the APIC.

Figure 9: Single Pod Architecture – Check Point and Cisco Systems integration

14PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Multi-Site DesignThis design consists of multiple separate fabrics where each fabric has its own APIC cluster with the possibility to connect separate ACI fabrics using L3Out connectivity and an orchestrator that runs on top of it. This is the reason to deploy the Orchestrator called Multi-site Orchestrator (MSO), enabling the administrators to set up the connectivity between sites and have tenants stretching the sites (Bridge domains and EPG’s can stretch).

There are other topologies that Cisco ACI supports but are not covered in this whitepaper:

• Remote Leaf

• vPod

• cPod

• Cloud Only (Azure/Amazon/Google)

Figure 11: Multiple Architecture – Check Point and Cisco Systems integration

Figure 10: Multi-Pod Architecture – Check Point and Cisco Systems integration

15PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Check Point Integration with Cisco ACICheck Point CloudGuard for ACI 13 is the Check Point Advanced Security solution for the Cisco ACI fabric. The Check Point CloudGuard solution enforces advanced Threat Prevention inside the ACI fabric and provides complete integration between Cisco APICs and the Check Point Security Management Server. It proactively stops malware and zero-day attacks inside the Data Center environment and outside of the fabric. The unified management of virtual and physical gateways simplifies security management across the entire hybrid network.

Check Point CloudGuard for Cisco ACI has two main components:

• The CloudGuard Controller The CloudGuard Controller enables the integration of the Check Point Security Management Server with Cisco APIC and other leading SDN controllers and cloud managers, such as vCenter. The CloudGuard Controller makes dynamic security policies that contain ACI objects and VMs. Controller automatically syncs any object changes directly into the dynamic security policies, without the need for a policy push. It manages CloudGuard gateways and physical gateways, and provides complete visibility for Data Center security. Security policies generated with the CloudGuard Controller can be installed on every Check Point Security Gateway across the network.

• The Check Point Security Gateway The CloudGuard Gateway is a Check Point physical appliance, hyperscale, or virtual system deployed inside the ACI fabric in managed or unmanaged mode, and enforcing the Check Point security policy.

CloudGuard Controller and Cisco APICCheck Point CloudGuard for ACI requires a license attached to the Security Management Server or the Multi-Domain Server. The license is based on the total number of Cisco ACI leaf switches managed by the APICs that are integrated with the Check Point Security Management Server or Multi-Domain Server.

The CloudGuard for ACI license covers the functionality of ACI integration. No additional licenses are required on the gateways to support this functionality. The license covers Management High Availability for the Security Management Server and the Multi-Domain Server. A separate license is required for all processes that are not associated with ACI integration.

13 Source: CloudGuard for ACI R80.10 Administration Guide, URL: https://sc1.checkpoint.com/documents/R80.10/WebAdminGuides/EN/CP_R80.10_vSEC_for_ACI_AdminGuide/html_frameset.htm?topic=documents/R80.10/WebAdminGuides/EN/CP_R80.10_vSEC_for_ACI_AdminGuide/171241

16PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

This includes other management and/or gateway capabilities. The license is perpetual and cumulative. You can always add more leaf licenses.

At the management layer, the CloudGuard Controller, which is included in every Security Management Server, integrates with the Cisco APIC. It consumes metadata which is used in the Check Point access and threat prevention security policies.

For example, CloudGuard Controller learns about objects such as EPG’s from the APIC. Where these are used in the security policies, CloudGuard Controller also monitors EPG membership and updates relevant security gateways with changes in near real-time (~30 seconds). In this way, organizations benefit from using a single abstraction view of their datacenter.

In addition, the Cloudguard controller integrates in a similar way for Azure, AWS, VMware vCenter, VMware NSX-T, etc, enabling true multi-cloud policies.

Mapping Service Contracts with Check Point Security PoliciesTo build the security policies in Check Point Security Gateways, it is crucial to do the mapping between the Application Profile versus Application Control and Threat Prevention Policies. So the mapping is very simple.

Figure 12: Check Point CloudGuard Controller integration with Cisco APIC

17PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Equivalences between Cisco ACI and Check Point Software:

• EPG Consumer → Source/From

• EPG Provider → Destination/To

• Filters → Ports/Applications/Signatures

• Actions → Action (Allow, Deny, Drop)

Once we have the Application Profile built with the Service Graph, we can import the EPG objects through the Datacenter configuration in the Check Point Management Console.

On the physical infrastructure side, Cisco ACI and Check Point Gateways actually interact only after the configurations are created in the logical perspective. This is the importance of having both perspectives to build the Network Policies and the Security Policies.

Figure 13: Mapping Cisco APIC Service Contract with Check Point Security Policies

18PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Below is an example of a Security Policy that is mapped from the Logical Perspective above.

ACI Objects (EPGs, Application Profiles, Tenant, Application EPGs) are imported into the unified security policy and updated in real time via northbound API – no EP attachment required.

Connecting Security Gateways to the ACI InfrastructurePolicy Based Redirect (PBR) 14

PBR is driven by policy on the APIC and enforced on the leaf switches. It is used to control traffic inside a tenant between EPGs, both on the same or on different IP subnets.

Figure 14: Infrastructure view for the traffic flow between EPG’s and Service Bridge

Figure 15: Check Point Security policy example - EPG objects propagated from APIC to the CloudGuard Controller

14 Source: Cisco APIC Layer 4 to Layer 7 Services Deployment Guide, About Policy-Based Redirect - URL: https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/L4-L7_Services_Deployment/guide/b_L4L7_De-ploy_ver211/b_L4L7_Deploy_ver211_chapter_01001.html

19PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Contracts specify which traffic is permitted without inspection by the gateway. When traffic is allowed by a contract, the administrator can apply PBR according to a service-graph template (SGT) and a specific service node for inspection. When traffic is classified on the ingress leaf and PBR identified, the ingress leaf switches the traffic to the PBR service node instead of directly to the destination leaf. After processing on the service node, the flow is passed back to ACI which then switches to the destination leaf switch.

Figure 16: Policy-Based Redirect enables provisioning service appliances

Figure 17: Check Point Service provisioning, before and after insertion

20PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

The CloudGuard Gateways are deployed on their own bridge domain. It is possible to configure both datacenter internal (east-west) and datacenter perimeter (north-south) to use the same Check Point Gateways. In addition, Check Point can integrate with advanced PBR configurations to provide extra resilience with active-backup PBR, and extra capacity with symmetric PBR. Utilizing PBRs is the most widely used and recommended deployment scenario for the Check Point and Cisco ACI integration.

The main Cisco ACI PBR capabilities are as follows:

• PBR works with both physical and virtual service appliances.

• PBR works with service graphs in both managed mode (service-policy mode) and unmanaged mode (network-policy mode).

• PBR works with both bidirectional and unidirectional contracts.

• PBR can be used between L3Out EPG and EPGs, between EPGs, and between L3Out EPGs.

• PBR is supported in Cisco ACI Multi-Pod, Multi-Site, and Remote Leaf environments.

• The load can be distributed across multiple L4-L7 devices (symmetric PBR)

The main use cases for Cisco ACI PBR are as follows:

• Use PBR to insert firewalls or load balancers in the path between endpoints while keeping the default gateway on the Cisco ACI fabric to use distributed routing.

• Use PBR to insert an L4-L7 device in the path between endpoints that are in the same subnet.

• Use PBR to send traffic selectively to L4-L7 devices based on protocol and port filtering.

• Use Symmetric PBR to horizontally scale the performance of L4-L7 devices.

21PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Additionally, Cisco ACI can offer active/stand-by PBR for MultiPod Datacenters. The active path is a Security Gateways or Virtual System cluster giving stateful failover if the active node fails. The Security Design section of this paper will discuss different deployment methods for this.

The complementary mechanism for the failovers is that If the entire cluster fails, an IPSLA health check on ACI will forward all traffic to a backup/standby PBR policy node (cluster or gateway). This gives stateless failover, with a connection reset, and business continuity. This capability is useful for upgrades, maintenance, as well as automated disaster recovery (DRP).

You can distribute the traffic between two different Clusters in different Datacenters using the Active and Stand-By PBR.

Figure 18: Check Point Service provisioning, traffic flows configured in the Service Graph

22PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

L3 Go-To (Routed Mode)In this deployment option, the CloudGuard Gateway works as a layer 3 gateway, with a NIC in each network and traffic redirected to it. This is used to control traffic between bridge domains and to/from the internet. One common scenario is for Datacenter segmentation between different bridges.

Figure 19: Active PBR (green flow), Stand-By traffic flows (Blue flows) configured in the Service Graph

23PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Figure 20: Check Point Service provisioning for L3 Go-To (Routed Mode)

The Check Point L3 GoTo (Routed-Mode) security devices can be deployed in the ACI fabric via service graph. A virtual system instantiated from the L4-L7 routed (GoTo) device is used as the default gateway of end points (EPs) contained in the Bridge Domain connected to its connector. This deployment allows the virtual system to provide the complete range of Check Point capabilities including HTTPS inspection, NAT, IPsec VPN, etc. for the endpoints connected through the bridge domain.

However, in this scenario, it is required the configuration of the virtual system as the default gateway of the application EPs (similar capabilities can be achieved without this requirement using PBR. Configuring the device as a default gateway for the EPs requires disabling Unicast Routing capability on the bridge domain (as it does not provide routing services for the EPs). Disabling unicast routing on a Bridge Domain (BD) causes a design constraint as it prevents the fabric from learning EPs IP addresses.

24PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Deployment Options for Check Point Security GatewaysMaestro Hyper Scale Virtual Security FabricCheck Point Maestro introduces to the industry a new way to utilize current hardware investment and maximize appliance capacity in an easy-to-manage Hyperscale network security solution. With Maestro, organizations can simplify their workflow orchestration and scale up their existing Check Point security gateways on demand — the same way as they can spin up new servers and compute resources in public clouds.

Maestro orchestration enables expansion from a single Check Point gateway orchestration to the capacity and performance of 52 gateways in minutes, giving companies elastic flexibility and enabling massive Terabit/second firewall throughput.

Check Point Maestro brings the scale, agility, and elasticity of the cloud to on premise. Efficient N+1 clustering based on Check Point HyperSync technology, maximizes the capabilities of your existing security gateways. Create your own virtualized private-cloud by stacking multiple Check Point security gateways together. Group them by security feature set, policy, or the assets they protect and further virtualize them with virtual systems technology. With the Maestro Hyperscale Orchestrator, businesses of all sizes can have cloud-level security on premise. Add compute to meet your needs using Maestro Web UI or RESTful APIs – all while minimizing the risk of downtime and maximizing your cost efficiency.

Figure 21: Hyperscale Network Security with Check Point Maestro

25PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Virtual Systems 15 Security Gateways (VSX)Check Point security gateways are recommended to be deployed inside of the ACI fabric to benefit from the flexibility offered by Cisco ACI and PBR. Inside the ACI fabric, Check Point Gateways can be implemented either as CloudGuard Network Security Gateways or as Check Point physical appliances. Both are recommended to be operating in Virtual System eXtension (VSX) mode. All standard main-train Next Generation Threat Prevention (NGTP) security gateway blades are available for industry-leading firewall and threat-prevention capabilities. They are utilized to block threats entering the DC and prevent lateral movement between applications inside the data centre. ClusterXL is also available for stateful failover and resilience.

Since both physical and virtual gateways are fully supported, and are functionally equivalent, the decision of whether to deploy appliances or Check Point VM’s can be based more on projected load, customer preference, flexibility requirements, automation stack, and commercial considerations.

Physical Check Point Security AppliancesCheck Point Security Gateway appliances can be integrated with the ACI fabric and managed by the R80 / R81 Security Management Server. Appliances can be clustered, using VSX VSLS (Virtual System Load Sharing), or standalone, as requirements dictate. The Check Point Maestro product family is also supported. This has many benefits including true hyperscale performance, as well as the ability to segregate different workloads or tenants into different security groups.

Virtual CloudGuard GatewaysThe Check Point CloudGuard Network Security gateways integrate with Cisco ACI Virtual Machine manager (VMM) to provide L4-7 threat prevention using general-purpose virtualized compute. This is attractive for customers wishing to follow a strict “converged” design pattern over the alternatives.

CloudGuard and Cisco ACI Integration BenefitsTogether, Cisco and Check Point provide a powerful solution that gives customers complete traffic visibility and reporting in addition to proactive protection from even the most advanced threats within virtual network environments. The joint solution forms the foundation of an intelligent application delivery network architecture where security seamlessly follows application workloads and accelerates application deployment while maintaining reliability, multi-tenancy and operational workflows. The benefits go beyond the comprehensive threat prevention that Check Point provides:

15 Source: Check Point Virtual Systems - URL: https://www.checkpoint.com/downloads/products/virtual-systems-datasheet.pdf

26PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Auto-quarantine of Infected HostsHosts identified by CloudGuard as infected can be automatically isolated and quarantined. This is accomplished by CloudGuard tagging the infected hosts and sharing this information with the ACI fabric. Additionally, automated remediation services can be triggered by an orchestration platform. Threats can be quickly contained and the appropriate remediation service can be applied to the infected VM.

Context-Aware Security PoliciesThe integration with Cisco’s Application Policy Infrastructure Controller (APIC) shares context with the Check Point CloudGuard controller allowing end point groups (EPG) to be imported and reused within Check Point security policies. This reduces security policy creation time from minutes to seconds. Real-time context sharing of end point groups is maintained so that any changes or new additions are automatically tracked without the need for administrator intervention.

Complete Visibility and ControlCloudGuard for Cisco ACI provides consolidated logging and reporting of threats and security events. Check Point logs are further enriched with ACI context including EPG names and security tags. Additionally, the Check Point SmartEvent platform provides advanced incident tracking and threat analysis across both the physical and virtual data-center network traffic.

Centralized and Unified ManagementSecurity management is simplified with centralized configuration and monitoring of Check Point CloudGuard. Traffic is logged and can be easily viewed within the same dashboard as other gateways. Security reports can be generated to track security compliance across the data center network. A layered approach to policy management allows administrators to segment a single policy into sub-policies for customized protections and delegation of duties per application or segment. With all aspects of security management such as policy management, logging, monitoring, event analysis and reporting centralized via a single dashboard, security administrators get a holistic view of security posture across their organization.

As organizations embrace cloud transformation and convert their data centers into hybrid models, they must have security that can handle a dramatic increase in lateral network traffic between applications in a dynamic and automated way. Check Point CloudGuard Network Security for Cisco ACI addresses these challenges, delivering comprehensive and dynamic security specifically architected for Cisco ACI enabled data centers.

27PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Security Design and ArchitectureDesign PrinciplesCisco ACI and Security Gateways Design – Single PodIn this scenario we have a Single Pod where we can create different tenants according to the data center design. We can distribute the Computing, Service, Monitoring, and Border Leafs in the switch fabric. Check Point Security Gateways can protect the North-South and East-West traffic using the PBR configurations with the traffic flows. In this environment we can deploy Check Point Clusters to provide High-Availability.

Figure 22: Single Pod Architecture integrating the Infrastructure, Management and Logical views

28PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

The overlay configuration is basically the two/three tier with the Spine and Leaf switches, however the most important work is related to the Logical perspective to build the right segmentation architecture as we discussed before:

• Restricted Datacenter Tenant

— Where the Highly-Restricted and Restricted systems should be placed.

— Databases and other highly transactional systems should be placed

— Microsegmentation can be configured here using the Access-Control that could be generated in the Service Contract.

— Traffic inspection makes sense only for specific applications and flows, not for all the traffic.

• Internal DMZ Tenant

— Where the Internal Systems like Intranet or another Business support services should be placed.

— Traffic inspection makes sense for applications that should be protected for the Ingress and Egress traffic. East-West traffic inspection should be placed only and only if we have interaction with the Restricted Data Center tenant.

• External DMZ Tenant

— Where the external or public faced services should be placed and security controls should be the most restrictive for Ingress and Egress traffic.

• Management Tenant (for In-Band/Out-Band)

— Where it provides a convenient means to configure access policies for the fabric nodes being accessible and configurable through the API. Management interfaces of the Check Point appliances should be connected in this tenant.

• Common Tenant

— Where “common services” to the other tenants in the Fabric like Active Directory, DHCP, DNS, NTP and Firewall/IPS.

29PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Cisco ACI and Security Gateways Design – Multiple PodIn this design, we have two Single Pods interconnected through the IPN (InterPod Network). Similarly to the single Pod design, we can create the same tenants, but one of the main differences is the Service Node High-Availability model.

• Active-standby service node pair stretched across pods

• Active-active service node cluster stretched across separate pods

• Independent active-standby service node pair in each pod

Figure 23: Network services deployment 16 options with Cisco ACI Multi-Pod solution

16 Source: Cisco ACI Multi-Pod and Service Node Integration White Paper, ACI service integration - URL: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-pa-per-c11-739571.html#CiscoACIserviceintegration

30PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

The active-standby security gateways are stretched across pods, and can be applied to both north-south and east-west traffic flows. However, such a design creates a hair-pin issue for the traffic passing within the pod with the standby firewall, where all connections will be forwarded to the active firewall located in another pod, creating latency and performance issues on the firewall.

This fail-safe design model should consider Symmetric traffic paths to avoid communication drops by stateful firewalls. Cisco Systems recommends proper design with capacity planning for bandwidth being available across the pods. Be prepared for possible latency that could impact the application communications between the Pods. Wrong configurations in the PBR’s could lead to traffic-path inefficiencies where traffic flows hair-pin across the Interpod Network (IPN).

On the other hand, the active-active security cluster across the pods eliminates any issues related to asymmetric traffic paths with incorrect PBR configuration. The traffic flows are dynamically redirected to the specific firewall node owning the connection state for that specific traffic flow. In the active-active firewalls scenario, consider the performance impact on the cluster nodes during the failover. When one cluster node goes into the down state and all traffic is being redirected and handled by another active member, clusters at each pod must be deployed to maintain the load below 50% for the proper failover.

Check Point supports standard appliances using ClusterXL Active-Active mode from R80.40 release.

The most common and recommended scenario is to deploy independent active-standby security gateways cluster pairs in each pod. In this section we discuss this exact scenario. This design model requires symmetric traffic flows through the service nodes to be maintained. Connection states are not synchronized between independent nodes. This deployment should be used for DRP scenarios, or helping to keep the business working for Window maintenance activities in case of a failure.

However, we can “extend” Switch fabrics according to the design requirements of the Datacenter. The IPN is connecting different ACI pods, allowing Pod-to-Pod communication (East-West) to be an extension of the Underlay infrastructure.

31PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Figure 24: Multi-Pod Architecture integrating the Infrastructure, Management and Logical views

We can deploy a “common tenant” extended in the Switch Fabric between Datacenter 1 - Pod 1 and Datacenter 2 - Pod 1. This distributes resources to provide access control and traffic inspection according to the application flows and customer needs.

In this scenario, if the business requires maximum high-availability between both datacenters, we can create two types of Cluster Architectures:

• Active-Standby Cluster between the Pods where cluster members that are regular appliances can be deployed as Active Member in Datacenter 1 - Pod 1 and Standby Member in Datacenter 2 - Pod 1. For Virtual Systems designs, the best scenario would be VSLS (Virtual System Load Sharing).

• Active-Standby Clusters per Datacenter where two clusters are deployed in each datacenter: Cluster A (Active and Standby members) in Datacenter 1 Pod 1 and Cluster B in Datacenter 2 Pod 1.

• Active-Active Clusters between the Pods wwhere two regular appliances are deployed, one per Pod, and configured with ClusterXL. In R80.40, a new ClusterXL mode called Active-Active was introduced with the following capabilities:

— This mode is designed for a cluster, whose Cluster Members are located in different geographical areas (different sites, different cloud availability zones).

32PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

— The IP addresses of the interfaces on each Cluster Member are on different networks (including the Sync interfaces).

— Each Cluster Member inspects all traffic routed to it and synchronizes the recorded connections to its peer Cluster Members.

— Note: The traffic is not balanced between the members.

Let’s analyze one of the maximum high availability for the Multipod design architecture. In the following diagram we have the following scenario:

• Two Data Centers that can be located in the same region or different regions separated geographically.

• Bridge Domain 1 located in Datacenter 1 Pod 1 and Bridge Domain 2 located in Datacenter 2 Pod 1.

• An “Extended” Service Bridge Domain where we will deploy “Common” services. We can call it the Common Tenant for Security Traffic inspection.

• We have two clusters, each one deployed in the respective datacenter, Cluster 1 deployed in Datacenter 1 Pod 1 and Cluster 2 deployed in Datacenter 2 Pod 1.

Figure 25: Multi-Pod Architecture integrating VSX Clusters per Datacenter

33PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

For this design, a Service contract is created between Bridge 1 to Bridge 2. The idea is to enable the communication between the applications. The Service Graph can enable advanced Access-Control and Traffic Inspection.

In the following diagram, we have three different flows. The yellow flow is focused only on the Service Contract. Filters allow communication between the applications; no advanced traffic inspection is required. The green flow is focused on providing advanced Access-Control policies or Traffic inspection (Intrusion Prevention, Antibot, Application Control, etc). This flow is handled by the Active PBR through the Service Graph. Additionally, we have the Blue flow as Standby or Backup PBR to do failovers between clusters using IPSLA.

Elephant flows, which are used for highly demanding traffic such as backups or data replicas, are supported with Check Point Gateways. However, it is recommended to use only the Firewall and not deep packet inspection for these scenarios, unless the business or InfoSec requirements demand it. A common deployment mistake is to forward all the traffic to the gateways, instead of splitting the traffic through the service contract.

Figure 26: Service Contract configuration (Yellow flow) and Service Graphs – PBR (Green flow for Active-Path and Blue flow for Stand-By path

34PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

The Green flow should point to the Active gateway or Active Virtual System using One-Arm configuration, the interface on the firewall that owns the floating IP address responds to ARP requests with a virtual MAC address (VMAC) between the members in the cluster.

Note: Security Policies should be the same for BOTH Clusters to allow this high-availability.

If the Active Member of the cluster encounters a problem, the Check Point Security Gateway does the failover to the Standby member. PBR is not impacted due to the VMAC being the same and traffic is not impacted due to the connections being synchronized.

This scenario is applicable only at the Cluster level deployed in the Datacenter. While the traffic is processed by the gateways in the Green flow, the Yellow flow traffic will not be impacted. Check Point ClusterXL uses unique physical IP and MAC addresses for the cluster members and virtual IP addresses to represent the cluster itself. Virtual IP addresses do not belong to an actual machine interface. ClusterXL provides an infrastructure that ensures that data is not lost due to a failure, by ensuring that each cluster member is aware of connections passing through the other members. Passing information about connections and other Security Gateway states between the cluster members is known as State Synchronization.

Figure 27: Virtual System failover in the Cluster keeping the sync of connections

35PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Additionally, Virtual System Load Sharing is a cluster technology that assigns traffic for Virtual Systems to different Active VSX Cluster Members. Virtual Systems are deployed in Active-Standby, distributing the loads between the members of the cluster, and consequently providing a good balance between performance, cost, and security.

In the case of a catastrophic scenario, such as the second member of the Cluster 1 in the Datacenter 1 Pod 1 is lost, the importance of IPSLA is clear. The active method of monitoring and reliably reporting on network performance is very useful for complex Data Centers. IPSLA actively monitors traffic continuously. In case of failure in the active member of the cluster, IPSLA will activate the Backup/Standby PBR and begin to forward traffic to Cluster 2, located in Datacenter 2 Pod 1.

The Backup PBR policy (N+M high availability) uses Resilient Hash, because all of the traffic that went through a failed node will be redirected to one of the available nodes. The capacity of the node could be a concern. The node could double the amount of traffic compared with when all of the PBR nodes are available. Instead of using one of the available primary PBR nodes, the traffic that went through a failed node will be redirected to a backup PBR node; other traffic will still be redirected to the same PBR node.

Figure 28: Cluster failure and traffic failover converting stand-by PBR to new Active path PBR for the second Cluster member

36PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

The Cisco ACI IPSLA provides monitoring capabilities on the ACI fabric, allowing SLA probing to occur across the data center network and out to the external network. This is accomplished by configuring an IP SLA monitoring policy, which defines the probe type used during monitoring. The monitoring policy is then associated with monitoring probe profiles, known as "track members". Once configured, track members define an endpoint or next-hop by IP address, the associated monitoring policy, and the scope (bridge domain or L3Out). One or more track members can be assigned to a "track list". Track lists configure thresholds that, if exceeded, determine if a track list is available (up) or unavailable (down).

Figure 29: Cluster Member failure in Pod 2, traffic failover done by the Virtual System and keeping PBR Active Path

37PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Figure 30: Multi-Site Architecture integrating the Infrastructure, Management and Logical views

The organizations have different business requirements (business continuance, disaster avoidance, resource distribution, Digital transformation, Cloud-Centric architecture, etc.) defines as an main objectives the deployment to separate data center fabrics (On-Premises and Public Cloud) and requires the need to be interconnected with each other.

This architecture design is focused to allow the organizations to integrate several sites distributed globally allowing extended connectivity and policy extension between on-premises ACI fabrics and public cloud resources for example an integration with AWS and Azure.

Cisco ACI and Security Gateways Design – Multiple SiteThis architecture allows the organizations to interconnect separate Cisco ACI APIC cluster domains (fabrics), each representing a different region or Data Centers, all as part of the same Cisco ACI Multi-Site domain. Doing so helps ensure multitenant Layer 2 and Layer 3 network connectivity across sites, and it also extends the policy domain end-to-end across the entire system.

38PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Architecture components:

• Two or more ACI fabrics built with Nexus 9x00 switches deployed as leaf and spine nodes.

• One APIC cluster domain in each fabric, for example sites placed in different cities or regions.

• An inter-site policy manager, named Cisco ACI Multi-Site, which is used to manage the different fabrics and to define inter-site policies.

• Check Point Clusters (regular appliances or VSX gateways) placed in the Border Leafs per Cluster Domain in each fabric or Autoscale Security Gateways placed in the Public Clouds, for example Azure and Amazon Web services.

• Check Point MultiDomain that manages several Domains integrating CloudGuard Controller to fetch objects from different APIC Clusters.

Table 1: Mapping Cisco ACI between Public Cloud Providers (Azure/Amazon) 17

17Sources: Cisco Cloud ACI on Microsoft Azure White Paper & Cisco Cloud ACI on AWS White Paper, URL’s: https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-pa-per-c11-742844.html https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-pa-per-c11-741998.html

39PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Architecture BlueprintsVSX Design for Single Tenant Security DeploymentVSX (Virtual System Extension) is a security and VPN solution for large-scale environments, based on the proven security of Check Point Security Gateway. VSX provides comprehensive protection for multiple networks or VLANs within complex infrastructures. It securely connects them to shared resources such as the Internet and/or a DMZ, and allows them to safely interact with each other. Using the Check Point Smart-1 appliance, administrators may configure multiple virtual systems in their environment.

Figure 31: Single Pod VSX Design for Single Tenant Security Deployment – Example

40PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Each Virtual System works as a Security Gateway, typically protecting a specified network. When packets arrive at the VSX Gateway, it sends traffic to the Virtual System protecting the destination network. The Virtual System inspects all traffic and allows or rejects it according to the rules defined in the security policy, thus preventing unauthorized access to the network, which in turn leads to the optimal network resource usage.

This architecture design has the Check Point Security Gateway clusters connected to service leaf switches, in one armed configuration, in order to secure east-west traffic within the tenant. Another cluster is connected to border leaf switches for north-south traffic inspection.

Maestro Design for Large Scale and Multi-Tenant EnvironmentsCheck Point Maestro introduces to the industry a new way to utilize current hardware investment and maximize appliance capacity in an easy-to-manage Hyperscale network security solution. With Maestro, organizations can simplify their workflow orchestration and scale up their existing Check Point security gateways on demand — the same way as they can spin up new servers and compute resources in public clouds. Maestro orchestration enables expansion from a single Check Point Gateway orchestration, to the capacity and performance of 52 gateways in minutes, giving elastic flexibility and enabling massive Terabit/second firewall throughput.

Figure 32: Multi-Pod VSX Design for Multiple Tenant Security Deployment – Example

41PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Maestro can be used to create your own virtualized private-cloud premise by stacking multiple Check Point security gateways together. Group them by security feature set, policy or the assets they protect and further virtualize them with virtual systems technology.

Figure 34: Single-Pod Maestro Design for Large Scale and Multi-Tenant Environments – Example

42PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

In this architecture deployment, 4 security groups exist within the Maestro fabric. Each one is dedicated for a certain protection in the Cisco ACI fabric. One security group is connected to the service lead and responsible for the intra-tenant security (East-West traffic). Another is responsible for the same East-West traffic security for another tenant. Another security group is responsible for the North-South traffic connected to the border leaf. Finally, a security group is responsible for the common tenant.

Figure 35: Multi-Pod Maestro Design for Large Scale and Multi-Tenant Environments – Example

43PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

Check Point Gateways Fleet for Huge Demands of Traffic between ServicesFleet Gateways is using separate appliances which are connected to the service leaf of Cisco ACI. Using symmetric PBR functionality, it is possible to distribute traffic properly among the appliances for East-West traffic inspection.

Figure 36: Multi-Pod Check Point Gateways Fleet for Huge demands of Traffic between Services – Example

44PRIVATE CLOUD SECURITY FOR CISCO ACI INFRASTRUCTURE

SummaryCisco ACI provides effective micro-segmentation for next generation datacenters through the integration of physical and virtual environments under a common policy model for networks, servers, storage and security. Cisco ACI’s application-aware policy model and native security capabilities are leveraged by Check Point CloudGuard to dynamically insert, deploy and orchestrate advanced security protections within software-defined datacenters.

Together, Cisco and Check Point provide a powerful solution that gives customers complete traffic visibility and reporting in addition to proactive protection from even the most advanced threats within virtual network environments. The joint solution forms the foundation of an intelligent application delivery network architecture where security seamlessly follows application workloads and accelerates application deployment while maintaining reliability, multi-tenancy and operational workflows.

Worldwide Headquarters 5 Ha’Solelim Street, Tel Aviv 67897, Israel | Tel: 972-3-753-4555 | Fax: 972-3-624-1100 | Email: info@checkpoint.com

U.S. Headquarters 959 Skyway Road, Suite 300, San Carlos, CA 94070 | Tel: 800-429-4391; 650-628-2000 | Fax: 650-654-4233

www.checkpoint.com

© 2021 Check Point Software Technologies Ltd. All rights reserved.