Controle de acesso

Na operação por terminal, quem pode fazer o quê é decidido por quem tem a senha do equipamento. A senha não separa consultar de reconfigurar, não separa o técnico que entrou ontem do que está há dez anos, e uma sessão de terminal, por padrão, não deixa registro. Trazer a operação para a plataforma só resolve isso se a plataforma tiver as distinções que o terminal não tem.

Usuários e funções

A permissão mora na função, não na pessoa. Um usuário é alguém com acesso à plataforma; o que esse alguém pode fazer vem da função que ele exerce.

A diferença entre os dois modelos aparece com o tempo, e aparece como manutenção. Permissão montada pessoa a pessoa começa simples: o primeiro usuário recebe o que precisa, o segundo recebe “igual ao do primeiro”. Dois anos depois, é comum que ninguém saiba por que determinada pessoa tem determinado acesso, e a resposta honesta — porque foi copiado de alguém que talvez também não devesse ter — não é uma resposta que se dê a um auditor nem a um cliente corporativo. Com a permissão na função, o que o atendimento pode fazer está definido num lugar só e vale para todo mundo que atende. Não há lista de permissões por pessoa para manter em dia, nem acesso órfão que sobrevive porque ninguém lembra de onde veio.

As funções são criadas pelo provedor, e não escolhidas de uma lista pronta. Três exemplos comuns numa operação, que precisam de coisas diferentes:

• Atendimento. Precisa ver o estado do assinante, o histórico dele e se a queda é isolada ou parte de uma massiva. Quase tudo de que precisa é leitura.
• Campo. Precisa do que resolve a visita, com o equipamento à frente: a caixa, quem mais está pendurado nela, o sinal e a operação que encerra o atendimento.
• Administração. Precisa de alcance que os outros dois não precisam ter, e é a função de quem responde pela plataforma dentro do provedor.

Os três abrem o mesmo produto e enxergam plataformas diferentes. Não é uma questão de quantidade — é de recorte. O que aparece para cada um é o que aquela função faz.

Cada usuário tem uma função, e uma só. A escolha é deliberada: com acúmulo, o que uma pessoa pode fazer deixa de ser legível na função dela e passa a ser a soma de duas, que ninguém calcula de cabeça na hora de revisar acesso. Quando a mesma pessoa atende e vai a campo — o que é a regra numa operação pequena, não a exceção —, o caminho é uma função que descreva esse trabalho, em vez de duas empilhadas.

Permissão por recurso e ação

A permissão não é uma lista de telas que se pode abrir. A unidade é o par recurso e ação. Ver uma ONU e reprovisionar uma ONU são permissões distintas, sobre o mesmo recurso.

A razão de ser assim é que a maior parte do trabalho de uma operação de rede é leitura. Quem atende e precisa descobrir por que um assinante está sem sinal precisa ver quase tudo — a topologia acima dele, o sinal, os eventos, a massiva que talvez explique a queda. O que essa pessoa não precisa é mudar quase nada.

Um modelo de “pode ver” e “não pode ver” obriga a escolher entre cegar quem atende e dar a quem atende o poder de reprovisionar. As duas escolhas são ruins, e são ruins de um jeito que só aparece depois: a primeira empurra para outra pessoa um chamado que morreria ali, a segunda transforma um erro de clique em um assinante fora do ar. Separar ver de agir, no mesmo recurso, é o que dispensa essa escolha.

Este documento não enumera que ações cada recurso distingue.

O que vale dizer é que a separação alcança as ações entre si, e não apenas ver contra agir. Numa massiva, assumir, resolver e descartar são três permissões, e nenhuma delas vem junto com a leitura. Do lado da configuração, definir um perfil, executar um script e aplicar uma correção sobre muitos equipamentos também são três, distintas entre si e da leitura — ver Perfis e scripts e Eventos e massivas.

Há um caso que parece permissão e não é. Um módulo que não está instalado não é uma permissão negada: ele não existe naquela instalação, para nenhuma função. A diferença está em Arquitetura, e vale conhecê-la antes de investigar por que alguém não está vendo alguma coisa.

Verificado dos dois lados

A mesma regra é aplicada em dois lugares. A interface desenha o que a função permite, e o pedido é recusado do lado do servidor quando a função não permite. Não é redundância: os dois respondem a problemas diferentes, e nenhum deles substitui o outro.

Sem a verificação na interface, o operador convive com botão que não funciona. Ele clica, recebe uma recusa e aprende que a tela promete o que não entrega. O custo aqui não é de segurança, é de uso — e é maior do que parece. No meio de um atendimento, tentar o caminho que não vai dar certo é tempo do assinante na linha. E recusa parece defeito: parte dessas recusas vira chamado interno para um comportamento que está correto.

Sem a verificação do lado do servidor, esconder o botão não é segurança. Deixar de desenhar uma ação não é o mesmo que impedi-la, e cobrir a distância entre as duas coisas é justamente o que um controle de acesso faz. A recusa do lado do servidor é o que faz da permissão uma permissão; o desenho da interface é o que a torna utilizável.

O detalhe de como essa verificação é feita pertence à implantação, e não a um documento público. O que cabe aqui é a propriedade: a função é a fonte da decisão nos dois lados.

Auditoria

Toda ação que altera estado é registrada, com autor e momento. Consultar não entra no registro; provisionar uma ONU, alterar um perfil, executar um script ou mudar uma permissão, sim.

Para que isso serve tem resposta concreta, e ela não é conformidade. São três da manhã, um pedaço da planta está fora, e a pergunta que decide o próximo passo é o que mudou. Sem registro, a reconstrução é feita por conversa: quem estava de plantão, o que cada um lembra de ter feito, em que ordem. A memória de todo mundo é pior às quatro da manhã do que era às três, e a de quem está sob pressão é pior ainda. Com registro, a mesma pergunta tem resposta escrita.

Há um segundo uso, mais frequente e menos citado: procurar no registro e não achar também é resposta. “Alguém mexeu nisso ontem?” é uma hipótese que custa horas enquanto não puder ser descartada. Boa parte do valor de um registro está aí, em descartar hipóteses — e essa é a parte que aparece com frequência, enquanto a outra aparece pouco, e nos piores dias.

O limite é o de qualquer registro: ele só alcança o que passou pela plataforma. O que for feito direto no equipamento, por fora, não entra nele. É um dos argumentos para que o trabalho aconteça dentro dela — não porque o registro seja um fim em si, mas porque o que só existe na memória de quem executou não pode ser revisto por ninguém.

O registro é consultado na própria plataforma e guarda os últimos doze meses. É o mesmo registro que o acompanhamento das operações de provisionamento mostra — não são dois históricos a conciliar, e sim recortes diferentes do mesmo.

Por onde continuar

• Arquitetura — as quatro peças, o barramento e por que um módulo ausente não é uma permissão negada.
• Visão geral — o produto inteiro em uma página, para quem chegou direto aqui.