Organizations are migrating to the cloud because it dramatically reduces IT costs as we make much more efficient use of resources (either ours or by leveraging some cloud provider’s resources at optimal times). When done right, cloud also increases business agility because applications and new capacity can be spun up quickly on demand (on-premises or off), network and services configurations can be updated automatically to suit the changing needs of the applications, and, with enough bacon, unicorns can fly and the IT staff can get home at a reasonable hour.
Whenever you ask a CIO-type at any of these organizations what’s holding them back from all this cloud goodness, though, more often than not the answer has something to do with security: “Don’t trust the cloud…”, “Don’t trust the other guy in the cloud…”, “Cloud’s not compliant…”. You have to be something of a control freak to be a CIO/CISO these days, and, well, isn’t “cloud” all about giving up some control, after all (in return for efficiency and agility)?
Even if you overcome your control issues and you find a cloud you can trust (even if it’s your own private cloud – we can take baby steps here…), if we are going to achieve our instant on-demand application deployment, network provisioning and cost-efficient workload placement process, it turns out all the security stuff can throw another obstacle in our way. Cloud security isn’t like old-fashioned data center security where you could just put a huge firewall in front of the data center and call it good. For secure multi-tenancy and a secure cloud overall, virtually every workload (or “every virtual workload”?) needs to be secured from every other (except for the exceptions we want to make). Some folks call this “microsegmentation”, a fancy word for an old concept, but, a fundamental requirement that cloud deployments need to address. (Spoiler alert: ACI does this very well.)
Cloud networks have to assume there is much more east-west internal traffic than in the old days, which increases the need for security policies to be set up on a per-application or workload basis, and constantly tuned to the evolving application requirements. How are you going to enable all your security policies to work in the right place and do the right thing for each workload? And if you are using all the new whiz-bang next-generation security appliances (with real screws mounting them in real racks, with real cables coming out the back), how do you quickly get them to support virtual workloads and networks that could be anywhere and move to anywhere else as soon as you turn your back? Cloud and security begin to look less compatible after all…
Moreover, with this level of security granularity and pervasiveness, enterprises have tens of thousands to millions of access control lists (ACLs) and firewall rules, and they either lack the operational processes to remove these policies in a timely way when applications are decommissioned or prefer to retain policies because they are uncertain about the potential effect of removal. This can hardly lead to agile anything, let alone posing challenges for both securing the network and auditing the security stance for compliance purposes.
Along comes ACI…
Cisco Application Centric Infrastructure (ACI) is our primary Software Defined Networking (SDN) strategy, primarily to achieve all this data center and cloud automation we are shooting for. And nowhere does this become more evident with the automation of security policy deployment and management to address the problems we just described. In order to avoid rambling on too much about ACI fundamentals, if you need to know how ACI and SDN are related, read this. If you’d like more information on how ACI models network services and security policies, read this.
Perhaps what still confuses people about our ACI story is what exactly we mean by an “application-centric” policy, which coincidentally is fundamental to our security capabilities. First, let’s clarify that in ACI and/or SDN systems, your network policies can now be modeled in software, software that manages or controls your network/infrastructure according to any rules you want to make up (it’s software after all). What’s unique about ACI is that the policy language (the rules that tell your cloud infrastructure what to do) is not modeled on arcane networking concepts like VLAN’s and IP addresses, but on application requirements, and especially how application workloads can and can’t communicate, and what kind of services they are entitled to. Policies are applied to classes of applications or workloads (e.g., the web tier of an application), also called endpoint groups (EPG), which can be either physical or virtual workloads (or containers).
An application policy will consist of the EPG’s that make up the application, and the contracts and services between the EPG’s. This is fundamentally all we need to deploy and provision our application network anywhere, on any cloud resources we want. ACI will ensure that the deployed application is configured to look like the application network profile (as defined by the policy) according to the figure below:
It’s not too hard to imagine (and I won’t bore you with all the details) that the Firewall in the diagram can be automagically provisioned with the right security rules based on the centralized ACI policy for this application type, based on its logical position between the outside user and the web tier of the application. Yes, in the real world, we’d probably have another FW in front of the DB, with a different set of rules (if not elsewhere), but not shown here for expediency sake. Those security restrictions would just have to be further articulated in the application network profile (ANP).
In addition, ACI and the network profile that provisions the application network can take care of routing traffic to physical security devices (also called “service chaining”), regardless of where the workloads are placed, or where they might migrate to in the future. As applications are decommissioned, all the corresponding policies associated with the ANP are automatically removed. This approach enables IT agility without compromising security, therefore automating compliance. In addition, it reduces management complexity through automation.
For advanced threat mitigation and next-generation firewall services, Cisco ACI can also redirect traffic based on policy to external Layer 4 through 7 security devices using service chaining and automate the provisioning of rules for those devices. These two capabilities are not mutually exclusive and can be used concurrently on a per-contract basis, hence potentially allowing the replacement of multiple zone-based stateless firewalls usually spread across the data center network. The capability to enforce policy in the Cisco ACI fabric also enables it to scale without compromise. These advanced security devices can be Cisco’s own appliances like Cisco Adaptive Security Appliance (ASA), or one of a growing ecosystem of security partners including A10 Networks, Citrix, Embrane, F5, Radware and Symantec.
Cisco ACI fabric supports secure multitenancy at scale and enables complete isolation of network traffic and security policy administration for each tenant. All tenants can define their own private networks using one or more contexts (analogous to the Virtual Routing and Forwarding [VRF] construct). Tenant users can define their own ANPs, bridged domains, and security policies for their applications. The Cisco ACI multitenancy security model enables complete separation of management, administration, and troubleshooting for the underlying network infrastructure.
Cisco ACI security enables unified security policy lifecycle management with the capability to enforce policies anywhere in the data center across physical and virtual workloads. It offers complete automation of Layer 4 through 7 security policies and supports a defense-in-depth strategy while enabling deep visibility, automated policy compliance, and accelerated threat detection and mitigation. Cisco ACI is the only approach that focuses on the application by delivering segmentation that is dynamic and application centered.
For a more in-depth overview of the ACI policy model, how it works with a wide range of infrastructure devices like firewalls, and how automated policies are enforced, this is an excellent overview. And this one’s not bad either. In some upcoming blogs, we’ll look in more depth at some of our ecosystem security partners, how ACI works with Cisco ASA in real world deployments, and how ACI seamlessly works with physical and virtual security devices, as well as physical and virtual workloads under one consistent policy.
For the record I work for Cisco and my comment is in support of the blog.
One of the main concepts about ACI is “whitelist policy” which means servers belonging to distinct EPGs are connected to interfaces on the same physical or virtual switch are not allowed to communicate unless there is a whitelist policy to allow communication between these end point groups. In other words, EPGs (end point groups) need to be be configured to allow traffic between them. This is what we call “Zero Trust Model”. This is unlike traditional data center switches where servers communicate unless blacklisted. This means all traffic is allowed unless otherwise specified.