Security frameworks like Zero Trust entail granting users and devices the least amount of access to resources necessary to do their job. While this requirement seems straightforward in theory, it can be challenging in practice when users and devices number in the hundreds or even thousands. Traditional methods of network segmentation, such as subnets, VLANs, and VRFs, are often unscalable as organizations grow and networks become disparate.
Alternative to traditional network segmentation: role-based policies
Role-based policies can be a more efficient way to enable least-privilege access throughout the network. A role is an identity-driven networking construct that reflects the job the entity performs for the organization. When compared to traditional methods of network segmentation, using role-based policies to control access to a network can make it easier to design, deploy, and run the network.
Migrating to role-based policies is a change that can seem daunting at first. That’s why Aruba developed Aruba Central NetConductor, cloud-native network automation and orchestration services that automatically configure LAN, WLAN, and WAN infrastructure to deliver optimal network performance while defining and enforcing granular security policies that are the foundation of Zero Trust. (New to Aruba Central NetConductor? Check out this 2-minute Central NetConductor overview video.)
Here are some of the most common concerns that IT teams have when considering a migration to role-based policies, and how Aruba Central NetConductor addresses them.
Concern #1: Will role-based policies increase complexity?
IT teams are concerned that designs will require a lot of network infrastructure to determine the enforcement rules and network traffic handling associated with role-based policies. With Central NetConductor, the role construct makes it easy to decide the forwarding and policy enforcement model that you want to take on.
Today, the VLAN construct is commonly used to separate, segment, and ultimately apply rules to different sets of traffic. Aruba’s role-based policies can map a device role, e.g., “camera,” directly into a VLAN using the existing role and policy construct on the network today. Another option is to use a centralized fabric where policy enforcement is performed at strategic hub locations in the network. In this case the role can map a client into a tunnel back to a Gateway to enforce Layer 7 ACLs, DPI, and IPS/IDS. Lastly, that role can also steer clients into a distributed fabric, which pushes the enforcement towards the edge of the network, delivering a more scalable and efficient forwarding design.
The benefit of using Central NetConductor for role-based policies is that enforcement is not based on network configuration but rather identity of an endpoint. There is no need to choose between VLANs, tunnels, or fabrics at the time of network provisioning—the identity of clients can drive the forwarding behavior applied to it. By simplifying the management of ACLs by moving from IP (forwarding configuration) focused to role (dynamic identity) and creating a custom fit for all segmentation use cases, Aruba reduces the policy definition and forwarding design complexity.
Aruba Central NetConductor enables least-privilege access based on identity using a variety of methods.
Concern #2: Will a network redesign for role-based policies take a lot of effort?
Some vendors argue that fabric adoption means starting from scratch. Aruba thinks differently. With Aruba Central NetConductor, organizations can build fabrics in parallel with the infrastructure already in place. Here’s how that works.
Consider an organization that already extensively uses VLANs for segmentation. Central NetConductor builds overlays alongside those VLANs, allowing IT to continue running the traditional network design where it makes sense while, in parallel, realizing the benefits of overlays.
Central NetConductor overlays can also be built on top of third-party networks. This allows organizations that have existing non-Aruba infrastructure in the aggregation and core to get immediate value out of the Aruba architecture without having to rip and replace. Building a network designed for role-based policies alongside your existing architecture significantly reduces the effort associated with migration.
Concern #3: Will role-based policies introduce risk?
Architectural approaches that force a hard swap of infrastructure can add unacceptable risk to the organization. The Aruba approach supports evolution without compromise, minimizing the risk associated with wholesale cutovers from one approach to another.
With Aruba Central NetConductor, teams can run existing networks and fabrics in parallel to extract the greatest value from their investments. When it’s time to make a change, only the role needs to be updated. To move "camera" traffic from a VLAN to an overlay, for example, simply change the role identity, which is determined by information passed by standard RADIUS elements, from "camera VLAN" to "camera overlay"—a simple authorization change with no impact on other entities on the network, no moving endpoints into segments, and no additional configuration required.
Watch Miles Davis illustrate ways to ease migration to role-based policies.
Resources on role-based policies
Check out these resources and learn how Aruba Central NetConductor can help ease adoption.
