Uma regra que permite um endereço permite quem quer que esteja usando aquele endereço. Num ambiente com usuários móveis, máquinas compartilhadas e , essa é uma afirmação mais fraca do que parece, e o Identity Awareness é como ela se fortalece.

O problema que ele resolve

O firewall vê endereços. A política normalmente quer falar de pessoas: este departamento alcança a aplicação financeira, terceiros não, administradores alcançam interfaces de gerência de qualquer lugar.

O Identity Awareness fornece o mapeamento que falta — qual usuário está no momento em qual endereço — para que uma regra possa referenciar uma identidade e o gateway a resolva no momento da correspondência.

Access Roles

Um Access Role é o objeto que a regra referencia. Ele pode combinar:

  • Usuários ou grupos, tipicamente do .
  • Máquinas, para que uma regra possa exigir um computador corporativo, e não qualquer dispositivo de onde o usuário faça login.
  • Localizações, ou seja, as redes de onde a conexão parte.
  • Clientes de acesso remoto, quando aplicável.

Como as condições se combinam, um Access Role consegue expressar "membro de Finanças, numa máquina do domínio, a partir da rede do escritório" como um único objeto. Essa combinação é onde o recurso ganha seu lugar: a identidade sozinha responde quem, e as condições de máquina e localização respondem se as circunstâncias estão certas.

De onde vêm as identidades

Esta é a parte que determina se uma implantação funciona bem, e as opções trocam cobertura por intrusividade.

O Identity Collector é a resposta usual num ambiente Windows. Um pequeno agente coletor roda num host Windows, assina os logs de eventos de segurança dos controladores de domínio, e encaminha eventos de login ao gateway. Escala bem porque o coletor é quem fala com os controladores, e o gateway recebe um fluxo em vez de consultar.

O Query é o antecessor sem agente: o próprio gateway consulta os controladores de domínio por eventos de login. Não exige software adicional, que é seu apelo, e põe a carga de consulta no gateway.

A autenticação por navegador apresenta um portal cativo. O usuário se autentica num navegador e o gateway aprende o mapeamento. Cobre qualquer um com navegador, incluindo dispositivos fora do domínio, e é intrusiva por natureza: o usuário percebe.

O Identity Agent é software no endpoint que reporta o usuário logado diretamente. Dá o vínculo mais forte e exige implantação e manutenção.

Servidores de terminal precisam de tratamento próprio, porque muitos usuários compartilham um endereço. Sem um mecanismo específico, todos num servidor de terminal aparecem como uma identidade, e as regras não conseguem distingui-los.

A maioria das implantações reais combina fontes: um coletor para máquinas do domínio, e um portal para todo o resto.

Onde a identidade é aplicada

O gateway precisa ter o Identity Awareness habilitado, a fonte de identidade configurada, e o Access Role usado na política. Faltar qualquer um dos três produz uma regra que nunca casa.

A identidade também pode ser compartilhada entre gateways, para que um usuário identificado num gateway seja conhecido por outro sem reautenticar. Isso importa num ambiente com múltiplos gateways e é um passo de configuração, e não um padrão.

O que dá errado

As falhas recorrentes, e como se parecem:

A regra nunca casa. Geralmente a identidade não é conhecida pelo gateway. Verifique se o gateway vê o usuário antes de examinar a regra.

A identidade está obsoleta. Um usuário deslogou ou se moveu, mas o mapeamento persiste até expirar. Uma máquina compartilhada amplifica isso: a identidade do usuário anterior pode ainda estar ligada ao endereço.

Usuários aparecem como desconhecidos. A fonte de identidade não os cobre — um dispositivo fora do domínio, um sistema operacional não suportado, ou um login que o coletor nunca viu porque aconteceu antes de o coletor estar observando.

Todos num servidor de terminal parecem iguais. O caso específico acima, e precisa da solução específica, e não de ajuste.

A ordem de diagnóstico tem o mesmo formato de todo o resto da plataforma: confirme que o gateway conhece a identidade, então confirme que o Access Role a resolve, e então olhe a regra.

O que quem vai prestar o CCSA precisa saber de cor

O Identity Awareness mapeia usuários a endereços para que uma regra possa referenciar uma identidade. Um Access Role combina usuários ou grupos, máquinas, localizações e clientes de acesso remoto num objeto. Fontes de identidade incluem o Identity Collector, que encaminha eventos de login de controladores de domínio e escala bem; o AD Query, sem agente e consultando a partir do gateway; a autenticação por navegador via portal cativo, que cobre dispositivos fora do domínio e é visível ao usuário; e o Identity Agent no endpoint. Servidores de terminal precisam de tratamento específico porque os usuários compartilham um endereço. Uma regra que nunca casa geralmente significa que o gateway não conhece a identidade, então verifique isso antes de examinar a regra.