O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como ativar o modelo de lista de permissões (Default Deny IP) do TrustSec no Software Defined Access (SDA). Este documento envolve várias tecnologias e componentes que incluem Identity Services Engine (ISE), Digital Network Architecture Center (DNAC) e Switches (Borda e Borda).
Há dois modelos Trustsec disponíveis:
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software e hardware:
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.
Estas são as etapas para ativar o modelo Allow-List (IP de negação padrão):
Por padrão, a SGT (Security Group Tag) desconhecida é configurada para autorização de dispositivo de rede. A alteração para o TrustSec Device SGT oferece mais visibilidade e ajuda a criar SGACL específico para o tráfego iniciado pelo Switch.
Navegue até Centros de trabalho > TrustSec > Política Trustsec > Autorização de dispositivo de rede e altere-a para Trustsec_Devices de Desconhecido
Interface tengigabitethernet 1/0/1 no cts role-based enforcement
Note: Isso pode ser feito com o uso de um modelo de intervalo no DNAC para simplificar. Caso contrário, para cada switch, é necessário fazer manualmente durante o provisionamento. O trecho abaixo mostra como fazer isso através de um modelo de DNAC.
interface range $uplink1 no cts role-based enforcement
Para obter mais informações sobre modelos de DNAC, consulte este URL para o documento.
A ideia é que o mapeamento IP-SGT local esteja disponível nos switches mesmo que todo ISE fique inoperante. Isso garante que a Subcamada esteja ativa e que a conectividade com os recursos críticos esteja intacta
A primeira etapa é vincular serviços críticos a um SGT (ex - Basic_Network_Services/1000). Alguns desses serviços incluem:
Exemplo:
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
Um mapeamento SGT não tem utilidade até que um SGACL relevante seja criado usando o SGT e, portanto, nossa próxima etapa seria criar um SGACL que atue como um Fallback local no caso de os nós do ISE ficarem inativos (quando os serviços do ISE estão inativos, o túnel SXP fica inativo e, portanto, o SGACL e o mapeamento SGT IP não são baixados dinamicamente).
Essa configuração é enviada para todos os nós de borda e borda.
Contrato/ACL com base em função de retorno:
ip access-list role-based FALLBACK permit ip
Dispositivos TrustSec para dispositivos TrustSec:
cts role-based permissions from 2 to 2 FALLBACK
Acima da SGACL Garanta a comunicação com switches de malha e IPs subjacentes
Dispositivos TrustSec para SGT 1000:
cts role-based permissions from 2 to 1000 FALLBACK
Acima da SGACL Garanta a comunicação de switches e access points com ISE, DNAC, WLC e ferramentas de monitoramento
Dispositivos SGT 1000 para TrustSec:
cts role-based permissions from 1000 to 2 FALLBACK
Acima da SGACL Garanta a comunicação de pontos de acesso com ISE, DNAC, WLC e ferramentas de monitoramento para switches
O requisito é negar a maioria do tráfego na rede e permitir uma menor extensão. Em seguida, serão necessárias menos políticas se você usar a negação padrão com regras de permissão explícitas.
Navegue até Centros de trabalho > Trustsec > Política TrustSec > Matriz > Padrão e altere-o para Negar tudo na regra de captura final.
Note: Esta imagem representa (Todas as colunas estão em vermelho por padrão), a negação padrão foi ativada e somente o tráfego seletivo pode ser permitido após a criação da SGACL.
No ambiente SDA, o New SGT só deve ser criado a partir da GUI do DNAC, pois há vários casos de corrupção do banco de dados devido à incompatibilidade do banco de dados SGT no ISE/DNAC.
Para criar SGT, faça login em DNAC > Policy > Group-Based Access Control > Scalable Groups > Add Groups, uma página o redireciona para ISE Scalable Group, clique em Add, insira o nome SGT e salve-o.
O mesmo SGT reflete no DNAC através da integração PxGrid. Este é o mesmo procedimento para toda a futura criação de SGT.
No ambiente SDA, o New SGT deve ser criado somente a partir da GUI do 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)
Para criar um Contrato, faça login no DNAC e navegue para Política > Contratos > Adicionar contratos > Adicionar protocolos necessários e clique em Salvar.
Para criar um Contrato, faça login no DNAC e navegue para Política > Controle de acesso baseado em grupo > Políticas de acesso baseadas em grupo > Adicionar políticas > Criar política (com as informações fornecidas) agora clique em Salvar e em Implantar.
Depois que o SGACL/Contrato é configurado a partir do DNAC, ele reflete automaticamente no ISE. abaixo está um exemplo de exibição de matriz unidirecional para um sgt.
A GACL Matrix, como mostrado na imagem abaixo, é uma exibição de exemplo para o modelo Allow-list (Default Deny).
Para verificar os switches SGT recebidos pelo ISE, execute este comando: show cts environment-data
Para verificar a aplicação na interface de uplink, execute estes comandos:
Para verificar os mapeamentos IP-SGT configurados localmente, execute este comando: sh cts role-based sgt-map all
Para verificar FALLBACK SGACL, execute este comando: sh cts role-based permit
Note: A SGACL enviada pelo ISE tem uma prioridade sobre a SGACL local.
Para verificar o modelo Allow-list (Default Deny), execute este comando: sh cts role-based permit
Para verificar o SGACL baixado do ISE, execute este comando: sh cts role-based permit
Para verificar o SGACL baixado do ISE, execute este comando: show access-list <ACL/Contract Name>
Para verificar os acertos da política SGACL, execute este comando: Show cts role-based counter
Caso ambos os nós do ISE estejam inoperantes, o mapeamento de IP para SGT recebido pelo ISE é removido e todos os DGTs são marcados como desconhecidos, e todas as sessões de usuário existentes são interrompidas após 5 a 6 minutos.
Note: Esse problema é aplicável somente quando sgt (xxxx) -> desconhecido (0) O acesso SGACL é limitado a DHCP, DNS e porta proxy da Web.
Solução:
Agora, se ambos os nós do ise ficarem inativos, sgt SGACL—>ocorrências desconhecidas e a sessão existente estiver intacta.
A extensão para conversão de IP aconteceu no SIP e a comunicação de voz real ocorre sobre o RTP entre IP e IP. CUCM e Gateway de Voz foram adicionados ao DGT_Voice.
Solução:
O DNAC provisiona o switch com VLAN crítica para dados e, conforme a configuração, todas as novas conexões durante a interrupção do ISE obtêm VLAN crítica e SGT 3999. A política Default Deny in trustsec restringe a nova conexão para acessar qualquer recurso de rede.
Solução:
Empurre SGACL para SGT crítico em todos os switches de borda e borda usando o modelo DNAC
cts role-based permissions from 0 to 3999 FALLBACK cts role-based permissions from 3999 to 0 FALLBACK
Esses comandos são adicionados à seção de configuração.
Note: Todos os comandos podem ser combinados em um único modelo e podem ser enviados durante o provisionamento.
Quando a máquina está em uma VLAN crítica devido aos nós do ISE desativados, há uma queda de pacote a cada 3 a 4 minutos (máximo de 10 descartes observados) para todos os endpoints em uma VLAN crítica.
Observações: Os contadores de autenticação aumentam quando os servidores estão INATIVOS. Os clientes tentam autenticar com PSN quando os servidores foram marcados como DEAD.
Solução/Solução alternativa:
Idealmente, não deve haver nenhuma solicitação de autenticação de um endpoint se os nós PSN do ISE estiverem inativos.
Empurre este comando no servidor radius com DNAC:
teste automático-testador-automático-nome de usuário-teste automático
Com esse comando no switch, ele envia mensagens periódicas de autenticação de teste ao servidor RADIUS. Ele procura uma resposta RADIUS do servidor. Uma mensagem de êxito não é necessária - uma autenticação com falha é suficiente porque mostra que o servidor está ativo.
Modelo final do 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: Todas as interfaces de uplink em nós de borda são configuradas sem aplicação e presume-se que o uplink se conecta somente ao nó de borda. Nos nós de borda, as interfaces de uplink em direção aos nós de borda precisam ser configuradas sem imposição e isso precisa ser feito manualmente.