A security group is a group of users, end-point devices, and resources that share access control policies. Security groups
are defined by the administrator in Cisco Identity Services Engine (ISE). As new users and devices are added to the Cisco
TrustSec domain, the authentication server assigns these new entities to the appropriate security groups. Cisco TrustSec assigns
each of the security group a unique 16-bit number whose scope is global in a Cisco TrustSec domain. The number of security
groups in a wireless device is limited to the number of authenticated network entities. You do not have to manually configure
the security group numbers.
After a device is authenticated, Cisco TrustSec tags any packet that originates from that device with an SGT that contains
the security group number of the device. The packet carries this SGT everywhere in the network, in the Cisco TrustSec header.
As the SGT contains the security group of the source, the tag can be referred to as the source SGT (S-SGT). The destination
device is also assigned to a security group (destination SG) that can be referred to as the destination SGT (D-SGT), even
though the Cisco TrustSec packet does not contain the security group number of the destination device.
You can control the operations that users can perform based on the security group assignments of users and destination resources,
using the Security Group Access Control Lists (SGACLs). Policy enforcement in a Cisco TrustSec domain is represented by a
permission matrix, with the source security group numbers on one axis and the destination security group numbers on the other
axis. Each cell in the matrix body contains an ordered list of SGACLs, which specify the permissions that must be applied
to packets originating from the source security group and destined for the destination security group. When a wireless client
is authenticated, the controller downloads all the SGACLs in the matrix cells.
When a wireless client connects to the network, the client pushes all the ACLs to the controller
.
Cisco TrustSec achieves role-based topology-independent access control in a network by assigning users and devices in the
network to security groups and applying access control between the security groups. The SGACLs define access control policies
based on the device identities. As long as the roles and permissions remain the same, changes to the network topology do not
change the security policy. When a user is added to the wireless group, you simply assign the user to an appropriate security
group; the user immediately receives permissions to that group.
The size of ACLs are reduced and their maintenance is simplified with the use of role-based permissions. With Cisco TrustSec,
the number of Access Control Entities (ACEs) that are configured is determined by the number of permissions specified, resulting
in a much smaller number of ACEs.
To know the list of Cisco APs that support SGACL, see the release notes: https://www.cisco.com/c/en/us/support/wireless/catalyst-9800-series-wireless-controllers/products-release-notes-list.html
Note
|
Clients receive zero SGT value and DHCP clients receive an Automatic Private IP Addressing (APIPA) address when TrustSec policy
“unknown to unknown” is denied in TrustSec matrix.
Clients receive correct SGT values and DHCP clients receive an IP address when TrustSec policy “unknown to unknown” is permitted
in TrustSec matrix.
|
The scenarios supported for SGACLs on the Cisco Catalyst 9800 Series Wireless Controller
are:
-
Wireless-to-wireless (within Enterprise network):
-
Flex mode with local switching—SGACL enforcement is done on the egress AP when a packet leaves from a source wireless network
to a destination wireless network.
-
Flex mode with central switching—SGACL enforcement is done on the egress AP. To achieve this, controller
should export IP address to security group tag (IP-SGT) binding over SGT Exchange Protocol (SXP).
-
Wired-to-wireless (DC-to-Enterprise network)—Enforcement takes place when a packet reaches the destination AP.
-
Wireless-to-wired (Enterprise network-to-DC)—Enforcement takes place on the uplink switch when a packet reaches the ingress
of the wired network.
Guidelines and Restrictions
-
SGACL enforcement is carried out on the controller for local mode.
-
SGACL enforcement is carried out on an AP for flex-mode APs performing local switching.
-
SGACL enforcement for wireless clients is carried out either on the upstream switch or on the border gateway in a Branch-to-DC
scenario.
-
SGACL enforcement is not supported for non-IP or IP broadcast or multicast traffic.
-
Per-WLAN SGT assignment is not supported.
-
SGACL enforcement is not carried out for control-plane traffic between an AP and the wireless controller
(for upstream or from upstream traffic).
-
Non-static SGACL configurations are supported only for dynamic SGACL policies received from ISE.
-
Static SGACL configuration on an AP is not supported.
-
In case of Allow List model, you need to explicitly allow DHCP protocol for the client devices to get the DHCP IP address
and then request the controller for SGACL policies.