Permissões: dar acesso sem abrir a casa toda

A conversa sobre permissões começa quase sempre com uma frase que a estraga: «aqui confiamos nas pessoas». Ninguém está a discutir confiança. Um acesso mal desenhado não faz mal por haver alguém mal-intencionado — faz mal porque alguém, de boa-fé e com pressa, altera um valor que não era seu para alterar, apaga uma linha que outra equipa estava a usar, ou responde a um cliente com uma informação que ainda não estava decidida.

Permissões são uma decisão de organização escrita em software. Dizem quem responde por que informação. E, como qualquer decisão de organização, funcionam melhor quando são explícitas do que quando ficam a depender do bom senso de quem está de serviço numa tarde de agosto.

Dois extremos que falham pela mesma razão

Há duas configurações que aparecem por omissão nas empresas, e nenhuma é uma decisão: são a ausência dela.

Na primeira, todos veem tudo. É confortável, não dá trabalho a montar e resolve o arranque. O que produz a seguir é uma empresa onde ninguém pode dizer nada em privado dentro do sistema: os custos, as margens, as notas sobre um cliente difícil, a avaliação de um fornecedor. O que acontece é previsível — essas coisas continuam a existir, mas passam a viver em ficheiros pessoais e conversas laterais, fora do sítio onde o trabalho está registado.

Na segunda, cada um vê só o que é seu. Parece prudente e é o cenário mais caro, porque obriga a perguntar a alguém para fazer qualquer coisa. A pessoa que atende um cliente não consegue ver o projeto dele; quem prepara uma proposta não vê o histórico de quem já lhe vendeu. O resultado é um sistema que todos contornam, e contornar um sistema significa copiar informação para onde ela não devia estar.

Os dois extremos falham pelo mesmo motivo: fazem com que a informação saia do sítio certo. A pergunta útil está no meio, e não é quanto se fecha: é o que é que cada função precisa de ver para poder decidir sem perguntar a ninguém.

Desenhe por função, não por pessoa

O erro mais consequente é dar acessos a nomes. É rápido no dia e caro depois: a pessoa muda de funções e fica com os dois conjuntos; entra alguém para o lugar dela e recebe uma cópia dos acessos do antecessor, sem ninguém perguntar se ainda faz sentido; ao fim de dois anos, quem tem mais permissões na empresa é quem lá está há mais tempo, e não quem precisa.

Desenhar por função inverte isto. Escreve-se uma vez o que a função «comercial», «gestor de projeto» ou «administrativo» precisa de ver, e quem entra ou muda recebe o conjunto da função em que está. As exceções passam a ser visíveis — porque são exceções, e não a regra disfarçada.

Há um teste prático para saber se está bem desenhado: escreva a lista de acessos de uma função antes de saber quem a vai ocupar. Se não conseguir, o que existe não é um desenho de permissões — é um histórico de pedidos atendidos.

Há informação sensível dentro de casa, e não é só a financeira

Quando se pensa em informação reservada pensa-se em salários e margens. São dois exemplos e não são os únicos, e os que se esquecem costumam ser os que criam mais problema.

• Custos por pessoa. Quem os vê consegue calcular quanto custa um colega. É a razão por que a análise de rentabilidade é também uma conversa sobre acessos e não apenas uma conta.
• Notas internas sobre clientes. «Paga tarde», «é o filho que decide». São úteis, são legítimas e não foram escritas para serem lidas por vinte pessoas.
• Dados de contacto da base toda. Uma lista completa de clientes é o ativo comercial da empresa, e sai numa exportação.
• Documentos pessoais de terceiros. Cópias de documentos de identificação, dados de saúde, dados de menores. Chegam por motivos operacionais e ficam no arquivo, ao lado de tudo o resto.

Para cada um destes, o critério a aplicar é o mesmo e é simples de dizer: dar o acesso mínimo necessário para a pessoa fazer o trabalho dela. Não porque uma lei o exija — mas porque, depois de um acidente, a pergunta que se faz é sempre «e porque é que ele conseguia ver isso?», e vale a pena ter resposta.

O acesso que se dá e nunca se retira

Dar acesso é um pedido; retirar acesso não é pedido por ninguém. É toda a assimetria, e é o que faz com que as permissões de qualquer empresa só cresçam. O consultor externo que entrou para um projeto de três meses. O estagiário que ficou com o perfil do supervisor porque «era mais rápido». A pessoa que saiu na sexta-feira e ainda recebe notificações na terça.

A defesa não é vigilância — é uma data. Um acesso dado para um trabalho concreto marca-se com o dia em que deixa de fazer sentido, e revê-se nesse dia. E vale a pena que a saída de alguém da empresa tenha um passo escrito para isto, ao lado da entrega do portátil e do fecho do email, porque é o passo de que ninguém se lembra quando a saída é apressada.

Uma leitura duas ou três vezes por ano chega: quem tem acesso a quê, e porquê. O que costuma aparecer nessa leitura não são falhas de segurança — são pessoas que mudaram de funções e nunca perderam as antigas.

Como decidir isto sem parar a empresa

Não comece pela matriz completa. As matrizes de permissões com quarenta linhas ficam por acabar e, enquanto não acabam, não muda nada. Comece pelo inverso: escreva a lista curta do que seria problemático sair de casa ou ser alterado por engano. Custos, margens, a base de contactos completa, documentos de terceiros, o que sustenta uma fatura.

Para cada item dessa lista, responda a duas perguntas — que funções precisam de o ver e que funções precisam de o alterar. São coisas diferentes, e é o poder de alterar que causa estragos. Tudo o que não estiver na lista pode ficar aberto às equipas que trabalham com ele; abrir por omissão e fechar o que importa é mais praticável do que o contrário.

Feito isto, há uma condição para que não se desfaça: os acessos têm de ser coerentes entre as várias áreas de trabalho, ou as pessoas descobrem por onde entrar. É a pergunta a levar quando se avalia a camada de gestão de uma plataforma, e é a que se torna urgente quando a empresa passa de dez para cinquenta pessoas e deixa de haver alguém que conhece todos os casos de cor.