Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment activer le modèle allow-list (Default Deny IP) de TrustSec dans SDA (Software Defined Access). Ce document fait appel à plusieurs technologies et composants, notamment Identity Services Engine (ISE), Digital Network Architecture Center (DNAC) et Switches (Border and Edge).
Deux modèles Trustsec sont disponibles :
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Voici les étapes à suivre pour activer le modèle Allow-List (IP par défaut refusée) :
Par défaut, le Security Group Tag (SGT) inconnu est configuré pour l'autorisation des périphériques réseau. Le passage à TrustSec Device SGT offre plus de visibilité et aide à créer des SGACL spécifiques au trafic initié par le commutateur.
Naviguez jusqu'à Centres de travail > TrustSec > Stratégie Trustsec > Autorisation de périphérique réseau, puis changez-le en Trustsec_Devices from Unknown
Interface tengigabitethernet 1/0/1 no cts role-based enforcement
Note: Cela peut être fait avec l'utilisation d'un modèle de plage dans DNAC pour plus de simplicité. Sinon, pour chaque commutateur, il est nécessaire de le faire manuellement lors du provisionnement. L'extrait ci-dessous montre comment le faire via un modèle DNAC.
interface range $uplink1 no cts role-based enforcement
Pour plus d'informations sur les modèles DNAC, reportez-vous à cette URL pour le document.
L'idée est que le mappage IP-SGT local soit disponible sur les commutateurs même si tout ISE tombe en panne. Cela garantit que la sous-couche est opérationnelle et que la connectivité aux ressources critiques est intacte
La première étape consiste à lier les services critiques à une SGT (ex - Basic_Network_Services/1000). Certains de ces services incluent :
Exemple :
cts role-based sgt-map <ISE/DNAC Subnet> sgt 1000 cts role-based sgt-map sgt 2 cts role-based sgt-map <Wireless OTT Infra> sgt 1000 cts role-based sgt-map <Underlay OTT AP Subnet> sgt 2 cts role-based sgt-map <Monitoring Tool IP> sgt 1000 cts role-based sgt-map vrf CORP_VN <Voice Gateway and CUCM Subnet> sgt 1000
Un mappage SGT n'est d'aucune utilité tant qu'une SGACL appropriée n'est pas créée à l'aide de la SGT. Par conséquent, notre prochaine étape consisterait à créer une SGACL qui agit en tant que secours local en cas de panne des noeuds ISE (lorsque les services ISE sont hors service, que le tunnel SXP est hors service et donc que les SGACL et le mappage IP SGT ne sont pas téléchargés dynamiquement).
Cette configuration est transmise à tous les noeuds Edge et border.
Liste de contrôle d'accès/contrat basé sur les rôles de secours :
ip access-list role-based FALLBACK permit ip
Périphériques TrustSec à Périphériques TrustSec :
cts role-based permissions from 2 to 2 FALLBACK
Au-dessus de la SGACL Garantir la communication au sein des commutateurs de fabric et des adresses IP de sous-couche
Périphériques TrustSec à SGT 1000 :
cts role-based permissions from 2 to 1000 FALLBACK
Au-dessus de SGACL Assurez la communication des commutateurs et des points d'accès à ISE, DNAC, WLC et outils de surveillance
SGT 1000 vers périphériques TrustSec :
cts role-based permissions from 1000 to 2 FALLBACK
Au-dessus de SGACL Assurez la communication des points d'accès à ISE, DNAC, WLC et outils de surveillance aux commutateurs
La condition est de refuser la plupart du trafic sur le réseau et d'autoriser une moindre mesure. Ensuite, moins de stratégies sont nécessaires si vous utilisez le refus par défaut avec des règles d'autorisation explicites.
Accédez à Centres de travail > Trustsec > Stratégie TrustSec > Matrice > Par défaut et changez-le en Refuser tout dans la règle de capture finale.
Note: Cette image représente (toutes les colonnes sont en rouge par défaut), le refus par défaut a été activé et seul le trafic sélectif peut être autorisé après la création de la SGACL.
Dans l'environnement SDA, de nouvelles balises SGT ne doivent être créées qu'à partir de l'interface graphique DNAC, car il existe de nombreux cas de corruption de base de données en raison d'une non-correspondance de la base de données SGT dans ISE/DNAC.
Afin de créer SGT, connectez-vous à DNAC > Policy > Group-Based Access Control > Scalable Groups > Add Groups, a Page Redirige vers ISE Scalable Group, cliquez sur Add, saisissez le nom SGT et enregistrez-le.
La même SGT se reflète dans DNAC via l'intégration PxGrid. Il s'agit de la même procédure pour toute création future de balises de groupe de sécurité.
Dans l'environnement SDA, la nouvelle SGT doit être créée uniquement à partir de l'interface utilisateur DNAC.
Policy Name: Domain_Users_Access Contract : Permit Enable Policy :√ Enable Bi-Directional :√ Source SGT : Domain Users (Drag from Available Security Group) Destination SGT: Domain_Users, Basic_Network_Services, DC_Subnet, Unknown (Drag from Available Security Group) Policy Name: RFC_Access Contract : RFC_Access (This Contract contains limited ports) Enable Policy :√ Enable Bi-Directional :√ Source SGT : Domain Users (Drag from Available Security Group) Destination SGT: RFC1918 (Drag from Available Security Group)
Afin de créer un contrat, connectez-vous à DNAC et naviguez jusqu'à Policy > Contracts > Add Contracts > Add Required protocol et cliquez sur Save.
Afin de créer un contrat, connectez-vous à DNAC et naviguez jusqu'à Policy > Group-Based Access Control > Group-Based Access-Policies > Add Policies > Create policy (avec les informations fournies) maintenant cliquez sur Save et ensuite sur Deploy.
Une fois que SGACL/Contract est configuré à partir de DNAC, il se reflète automatiquement dans ISE. voici un exemple de vue matrx unidirectionnelle pour un sgt.
La matrice SGACL, comme l'illustre l'image ci-dessous, est un exemple de vue pour le modèle Allow-list (Default Deny).
Afin de vérifier les commutateurs SGT reçus par ISE, exécutez cette commande : show cts environment-data
Afin de vérifier l'application sur l'interface de liaison ascendante, exécutez les commandes suivantes :
Afin de vérifier les mappages IP-SGT configurés localement, exécutez cette commande : sh cts role-based sgt-map all
Afin de vérifier FALLBACK SGACL, exécutez cette commande : sh cts role-based permission
Note: La SGACL poussée par ISE a une priorité sur la SGACL locale.
Afin de vérifier le modèle Allow-list (Default Deny), exécutez cette commande : sh cts role-based permission
Afin de vérifier la SGACL téléchargée depuis ISE, exécutez cette commande : sh cts role-based permission
Afin de vérifier la SGACL téléchargée depuis ISE, exécutez cette commande : show access-list <ACL/Contract Name>
Afin de vérifier les accès aux stratégies SGACL, exécutez cette commande : Show cts role-based counter
Si les deux noeuds ISE sont désactivés, le mappage IP/SGT reçu par ISE est supprimé et tous les DGT sont marqués comme inconnus, et toutes les sessions utilisateur qui existent s'arrêtent après 5 à 6 minutes.
Note: Ce problème ne s'applique que si sgt (xxxx) -> inconnu (0) l'accès SGACL est limité au port DHCP, DNS et proxy Web.
Solution :
Maintenant, si les deux noeuds ise tombent en panne, sgt—>accès inconnu SGACL et la session qui existe sont intacts.
L'extension à la conversion IP s'est produite sur SIP et la communication vocale réelle s'est produite sur RTP entre IP et IP. CUCM et la passerelle vocale ont été ajoutés à DGT_Voice.
Solution :
DNAC provisionne le commutateur avec le VLAN critique pour les données et, selon la configuration, toutes les nouvelles connexions pendant la panne ISE obtiennent le VLAN critique et SGT 3999. La stratégie Refuser par défaut dans trustsec limite la nouvelle connexion à accéder à toutes les ressources réseau.
Solution :
Push SGACL for Critical SGT sur tous les commutateurs Edge et Border à l'aide du modèle DNAC
cts role-based permissions from 0 to 3999 FALLBACK cts role-based permissions from 3999 to 0 FALLBACK
Ces commandes sont ajoutées à la section de configuration.
Note: Toutes les commandes peuvent être combinées en un seul modèle et peuvent être poussées pendant le provisionnement.
Une fois que la machine est dans le VLAN critique en raison de noeuds ISE en panne, il y a une perte de paquet toutes les 3 à 4 minutes (10 pertes max. observées) pour tous les points d'extrémité du VLAN critique.
Observations : Compteurs d'authentification en augmentation lorsque les serveurs sont DEAD. Les clients tentent de s'authentifier auprès de PSN lorsque les serveurs sont marqués comme DEAD.
Solution/Solution :
Idéalement, il ne devrait pas y avoir de demande d'authentification d'un point de terminaison si les noeuds PSN ISE sont hors service.
Poussez cette commande dans radius server avec DNAC :
automate-testeur username auto-test probe-on
Avec cette commande dans le commutateur, il envoie des messages d'authentification de test périodiques au serveur RADIUS. Il recherche une réponse RADIUS à partir du serveur. Un message de réussite n'est pas nécessaire : une authentification échouée suffit car elle indique que le serveur est actif.
Modèle final DNAC :
interface range $uplink1 no cts role-based enforcement ! . cts role-based sgt-map <ISE Primary IP> sgt 1102 cts role-based sgt-map <Underlay Subnet> sgt 2 cts role-based sgt-map <Wireless OTT Subnet>sgt 1102 cts role-based sgt-map <DNAC IP> sgt 1102 cts role-based sgt-map <SXP Subnet> sgt 2 cts role-based sgt-map <Network Monitoring Tool IP> sgt 1102 cts role-based sgt-map vrf CORP_VN <Voice Gateway Subnet> sgt 1102 ! ip access-list role-based FALLBACK permit ip ! cts role-based permissions from 2 to 1102 FALLBACK cts role-based permissions from 1102 to 2 FALLBACK cts role-based permissions from 2 to 2 FALLBACK cts role-based permissions from 0 to 3999 FALLBACK cts role-based permissions from 3999 to 0 FALLBACK
Note: Toutes les interfaces de liaison ascendante dans les noeuds de périphérie sont configurées sans application et on suppose que la liaison ascendante se connecte uniquement au noeud de périphérie. Sur les noeuds de périphérie, les interfaces de liaison ascendante vers les noeuds de périphérie doivent être configurées sans application et cela doit être fait manuellement.