Acesso a dispositivos

Por padrão, qualquer técnico da sua organização pode trabalhar em qualquer dispositivo. Isso funciona bem para um MSP pequeno, mas deixa de funcionar quando existe um júnior que não deveria mexer em servidores, um terceirizado que cobre só um cliente, ou um cliente que faz questão de que a infraestrutura dele seja tratada por duas pessoas, e não por doze.

Este módulo define quem pode fazer o quê em cada dispositivo.

Como entrar

Configurações, seção Segurança, Acesso a dispositivos. Você precisa da permissão de configurações da organização, que o Owner e o Administrador têm por padrão.

O card é exibido para todo mundo, mas quem não tem a permissão recebe um erro ao abri-lo.

As três peças

Para um técnico fazer qualquer coisa em uma máquina, três coisas precisam se encaixar:

1. A permissão do perfil dele. Se ele não tem a permissão de acesso remoto, nenhuma regra de acesso vai concedê-la. As regras restringem, nunca ampliam.
2. O modo da sua organização. O que acontece quando nenhuma regra diz nada.
3. As regras daquele técnico. Os detalhes.

Os dois modos

Permissivo (o padrão): sem nenhuma regra que se aplique, o técnico pode. As regras de negar restringem.

Restritivo: sem nenhuma regra que se aplique, o técnico não pode. As regras de permitir liberam o acesso, uma de cada vez.

O modo é alterado com Salvar modo. Toda alteração é auditada.

Pense bem antes de mudar para restritivo. Nesse modo, um técnico sem regras cadastradas fica sem acesso a nada. Se você vai mudar, cadastre primeiro as regras de permitir e altere o modo depois.

As quatro capacidades

Cada regra permite ou bloqueia uma capacidade específica, não o dispositivo inteiro:

Elas estão ordenadas da mais invasiva para a menos invasiva. Um técnico pode ter patches em um servidor e não ter acesso remoto: são decisões separadas.

Fique atento a uma combinação em particular. O dispositivo aparece na lista se o técnico tiver pelo menos uma capacidade, mas abrir a ficha exige Monitoramento. Um técnico com Execução e sem Monitoramento vai ver o dispositivo na lista dele, clicar nele e receber um erro. Se você conceder qualquer capacidade em um dispositivo, conceda Monitoramento também.

Os cinco escopos

Uma regra se aplica a um destes cinco:

Os dois escopos de Active Directory só aparecem se você já executou uma descoberta de AD. Se nada foi descoberto, o formulário avisa e sugere executar uma.

O que não existe como escopo: uma regra não pode ser definida sobre um grupo de dispositivos do painel, sobre um site nem sobre uma etiqueta. Esses cinco são tudo o que há.

As regras são por pessoa

Uma regra se aplica a um usuário e somente um. Não existem regras por perfil, por equipe nem por grupo de usuários.

Se você quer que dez técnicos tenham a mesma restrição, precisa de dez regras. É a limitação mais incômoda do módulo, e vale conhecê-la antes de desenhar o seu esquema.

Você chega lá pela lista de técnicos, Ver regras. As regras são adicionadas com Adicionar regra e removidas com Excluir regra. As duas ações são auditadas.

Qual regra ganha

Esta é a parte para entender direito, porque ela não funciona do jeito que a maioria das pessoas espera.

Negar nem sempre ganha. A regra mais específica ganha, qualquer que seja o efeito dela.

Ordem de especificidade, da maior para a menor:

1. Dispositivo
2. Grupo do AD
3. Unidade organizacional
4. Cliente
5. Todos os dispositivos

Um permitir em um dispositivo específico ganha de um negar sobre o cliente inteiro. Isso é intencional: permite escrever "negar o cliente inteiro, permitir este dispositivo" e obter exatamente o que está escrito.

Negar só ganha em um empate exato, ou seja, quando as duas regras têm o mesmo escopo e a mesma prioridade.

Prioridade

Toda regra tem um número de prioridade, de 1 a 9999, com 100 como padrão. O número menor ganha, e ele só desempata entre regras do mesmo escopo.

Três exemplos

A especificidade ganha do efeito. Negar Execução no cliente 5 e permitir Execução no dispositivo 42, que pertence a esse cliente. Resultado no 42: permitido.

Empate exato: negar ganha. Permitir Patches no dispositivo 42 e negar Patches no dispositivo 42, os dois com prioridade 100. Resultado: negado.

A prioridade desempata dentro do mesmo escopo. Duas regras sobre o mesmo cliente, uma com prioridade 50 e outra com 100. A de 50 ganha.

Por que o grupo do AD fica acima da OU: um grupo é montado de propósito para juntar máquinas ("Servidores críticos"), enquanto uma OU reflete uma estrutura herdada do domínio. O grupo expressa melhor a intenção.

Quando uma regra de AD não pode ser avaliada

Um dispositivo pode não ter dados de Active Directory por vários motivos: o domínio nunca foi descoberto, a descoberta está desatualizada, o dispositivo não está no domínio, ou não foi possível vinculá-lo.

Nesses casos o KairosLink não adivinha. As regras de grupo do AD e de OU são ignoradas, porque tratar "não tenho dados" como "não pertence a nenhum grupo" transformaria uma permissão em uma negação, ou o contrário.

Uma consequência prática que vale ter em mente: uma regra de AD sobre um dispositivo sem dados descobertos não se aplica, e hoje a tela não diz isso. Se você cadastrou uma regra de grupo e não vê o efeito esperado, confira se o dispositivo tem uma descoberta de AD recente.

O que um técnico sem acesso vê

Na lista de Dispositivos, a máquina não aparece. Ela não fica riscada nem cinza: ela não está ali. E a atualização automática dessa tela respeita o mesmo filtro.

Se ele entrar pelo endereço direto, recebe um erro com o motivo, e isso fica registrado na auditoria.

As ações ficam bloqueadas em todos os lugares. Ele não consegue conectar, executar comandos, aplicar patches nem mexer no monitoramento daquele dispositivo por nenhuma tela do painel. É isso que o módulo garante.

O que ele continua vendo

O filtro de visibilidade se aplica à lista de Dispositivos, não às outras grades. Em patches, monitoramento, antivírus, postura de segurança, DLP, certificados, painel de telas, relatórios e no seletor de dispositivos de um chamado, aquele dispositivo continua legível: nome, cliente, status e os contadores dele.

Ele não consegue agir sobre o dispositivo a partir dali, mas o vê.

Dito de forma direta: o módulo controla a ação, não a visibilidade do nome. Se o seu caso de uso é que um terceirizado não veja nem os nomes das máquinas dos outros clientes, isso está fora do que este módulo resolve.

Os botões não somem

O único que reflete o acesso é o Conectar, que é exibido em cinza com o motivo na dica. Todos os outros (console, arquivos, serviços, processos, patches) são desenhados de qualquer jeito e falham quando usados.

O controle está lá; a pista visual não está.

Perfis de acesso

O Owner nunca fica sem acesso. Ele é isento das regras por design: não há como trancar o dono para fora do próprio parque de dispositivos.

Um Administrador pode ser restringido. Se você cadastrar regras para ele, elas se aplicam. Isso é intencional: permite administradores limitados a um conjunto de clientes.

Técnico e Somente leitura são governados inteiramente pelas permissões do perfil deles mais as regras deles.

Onde ver quem tem acesso ao quê

Você consegue ver em quais dispositivos uma pessoa pode mexer, abrindo as regras dela pela lista de técnicos.

A visão inversa não existe. Não há tela que responda "quem pode mexer neste dispositivo". Se você precisa auditar isso, tem que passar por cada técnico.

O que fica registrado: as mudanças de modo, as regras adicionadas e removidas, e toda tentativa negada.

O que ele não faz hoje

• Não existem regras por perfil nem por grupo de usuários. Uma regra, uma pessoa.
• Uma regra não pode ser definida sobre um grupo de dispositivos do painel, um site ou uma etiqueta.
• O filtro de visibilidade só se aplica à lista de Dispositivos. Nas outras grades o dispositivo continua legível.
• Não existe tela que mostre quem tem acesso a um dispositivo específico.
• Os botões não ficam ocultos conforme o acesso, com exceção do Conectar.
• Uma regra de AD que não pode ser avaliada não gera nenhum aviso em tela nenhuma.

Perguntas frequentes

Por onde eu começo se quero restringir alguém? Cadastre primeiro as regras dele e depois mude o modo, se for preciso. Mudar para restritivo sem regras cadastradas deixa todo mundo sem acesso.

Coloquei um negar no cliente e o técnico continua entrando em um dispositivo. Veja se existe um permitir naquele dispositivo específico: a regra mais específica ganha, qualquer que seja o efeito.

Negar não ganha sempre? Não. Ele só ganha quando empata com um permitir no escopo e na prioridade.

Concedi acesso a um dispositivo e clicar nele dá erro. Abrir a ficha exige a capacidade Monitoramento. Conceda-a junto com a que ele já tinha.

Quero a mesma restrição para dez técnicos. Hoje isso exige dez regras. Não existem regras por perfil nem por grupo.

Cadastrei uma regra de grupo do AD e nada acontece. Se o dispositivo não tem dados descobertos do Active Directory, essa regra é ignorada. Execute uma descoberta de AD.

Posso deixar o Owner sem acesso? Não. Ele é isento por design.

Posso limitar um Administrador? Sim. Administradores podem ser restringidos com regras.

Como eu descubro quem tem acesso a um servidor específico? Hoje não existe tela para isso: você precisa conferir as regras de cada técnico.

Tirei o acesso dele e ele continua vendo o dispositivo em Patches. O filtro que esconde o dispositivo se aplica à lista de Dispositivos. Nas outras grades ele vê, mas não consegue agir.