When security policies for data center environments are first created and deployed to firewalls, it’s assumed that the assigned IP address will remain the same throughout the life of the policy. These policies are static, blanketed and applied in a generic fashion. With data centers transitioning to virtualized environments, workloads are no longer fixed to a particular location or networking schema.
To address security in the virtualized data center, your firewall security policies should be based on the attributes of the workloads rather than tied to static IP addresses, since the data center environment is highly dynamic. This can be done through Dynamic Address Groups on a next-generation firewall.
Transient workloads are frequently spun up and down to optimize compute resources, repeatedly acquiring new IP addresses. This makes it cumbersome and difficult to manage access-control policies on the firewall when dealing with hundreds or thousands of address groups, each with its own address objects, constant additions, deletions or changes.
Your firewall should support policies that automatically adapt to the dynamic nature of today’s datacenter, which involves constantly adding, moving or removing workloads for optimal use of compute resources. Adaptive policies help enforce consistent security across your dynamic virtual machines and applications.
Dynamic Address Groups decouple security policies from IP addresses and instead build granular security policies based on the attributes of your virtual workloads. Policies on the firewall use tags mapped to workload attributes. For example, the tag on the firewall may be App-Server, which can be mapped to attributes that identify the specified application server regardless of its IP address. The attributes will continue to place the workload in the desired security policy even if the workload gets relocated.
This helps you build security policies that are bound to workloads, enhancing your security posture. Dynamic Address Groups lower operational overhead by reducing dependence between applications and security teams.
Click here to learn more about the 10 things to test for in your future NGFW.