Bloquear um único dispositivo da VPN sem desativar a conta inteira

Um funcionário, dois portáteis e apenas um deles deve perder o acesso. Desativar a conta é a alavanca óbvia, mas pune o âmbito errado, enquanto apagar um perfil guardado no endpoint é uma sugestão e não um controlo. A decisão resume-se a três condições: se existe uma identidade de dispositivo que a VPN consiga verificar, se esta ligação concreta a avalia de facto e o que quer que aconteça ao dispositivo em vez de à pessoa. Responda por essa ordem e a aplicação costuma escolher-se sozinha.

Primeira condição: há provas do dispositivo que a VPN consiga verificar?

Um endereço de origem é partilhado atrás do NAT do escritório e muda nas redes móveis. Um nome de anfitrião é o que o dispositivo afirma, um endereço MAC falsifica-se trivialmente e um valor de registo pode ser escrito por qualquer coisa com direitos locais. Nenhum deles é uma identidade até algo a verificar. Uma credencial de dispositivo inscrita em separado, como um certificado emitido para esse endpoint, é a única opção que dá à revogação um alvo mais estreito do que a conta de utilizador.

A credencial só conta se a ligação se autenticar com ela e validar a cadeia em cada tentativa. Um ficheiro guardado no armazém da máquina não prova nada.

Segunda condição: esta ligação avalia-a?

Os atributos do endpoint não são universais. Num ASA, o guia ASDM DAP da Cisco separa a informação AAA do utilizador dos atributos de avaliação do endpoint, e quais atributos estão disponíveis depende do protocolo de acesso remoto em uso, das ferramentas de postura implementadas e da licença. Uma verificação do registo precisa do caminho de recolha suportado e, mesmo assim, relata o que a ferramenta do endpoint viu, não que a máquina seja aquela em que confia.

Portanto a pergunta prática é estreita: neste túnel, com este cliente e este agente de postura, que atributo chega preenchido e fiável? Se a resposta for nenhum, uma política escrita contra ele corresponderá a nada ou a tudo, e ambos os resultados são piores do que o bloqueio de conta que evitava.

Terceira condição: rejeição, remediação ou acesso mais estreito?

Há três resultados disponíveis e não são intercambiáveis. Pode terminar a sessão, o que remove o acesso por completo; pode colocar o dispositivo em quarentena num estado em que só alcança recursos de remediação; ou pode deixar a sessão ativa e cortar a sua ACL de recursos para as poucas coisas de que esse dispositivo ainda precisa. As ações de sessão DAP e as ACL de recursos respondem a perguntas diferentes, pelo que a escolha é sobre quanto dano colateral a pessoa deve absorver.

Para um portátil perdido ou roubado a resposta costuma ser a terminação. Para uma máquina que falhou uma verificação de postura, a remediação é mais gentil e igualmente eficaz.

Decidir o que acontece quando faltam as provas

O caminho predefinido importa mais do que a regra escrita para o bom caso. Se o atributo esperado nunca chegar porque o agente de postura está avariado, uma política que o exige pode cair num predefinido que admite a sessão. Leia o resultado predefinido e teste deliberadamente o caso sem provas, porque é esse o estado que um atacante que remove o agente vai apresentar.

Vários registos DAP correspondentes são agregados em vez de resolvidos por uma simples ordem de primeira correspondência, e a sua prioridade de ACL é um mecanismo separado da seleção de registo. Leia a descrição da agregação no guia antes de assumir que ganha o registo mais rigoroso.

Tratar sessões já existentes e depois testar os dois dispositivos

Alterar uma regra de admissão ou revogar uma credencial não descreve o que acontece a uma sessão já estabelecida que transporta tráfego. Se a remoção imediata for o requisito, siga o procedimento de terminação e reavaliação de sessão suportado pela implementação em vez de esperar pela próxima reconexão. É o passo mais frequentemente omitido durante um incidente, e é a diferença entre uma política e um resultado.

Teste com o mesmo utilizador permitido nas duas máquinas ao abrigo de uma verificação aprovada. O dispositivo bloqueado deve receber exatamente a recusa ou o resultado de remediação pretendidos, e o outro deve conservar apenas os seus recursos autorizados. Isso verifica a fronteira do dispositivo sem revogar o outro acesso aprovado da pessoa.

Se não conseguir tornar esses dois resultados diferentes, o problema são as provas, não a política, e nenhum ajuste de regras o resolverá.