Controle de acesso por perfil: as decisões de um CRM

Controle de acesso por perfil parece um tema resolvido: todo sistema tem login, papéis e permissões. Ao especificar o segundo incremento deste CRM de cobrança, apareceram 16 decisões que não estavam resolvidas, 3 delas sobre algo que nem era do produto. Algumas eram previsíveis, como quais permissões existem. Outras só aparecem quando se pergunta: o que acontece se alguém tirar de todos a permissão de administrar, ou se dois usuários de empresas diferentes se chamarem João Silva? Este artigo mostra cada decisão com as alternativas e o motivo da escolha.

O que não é do produto#

A primeira decisão foi tirar coisas da especificação. O mapa do projeto previa, para este incremento, usuários públicos de demonstração, dados fictícios renovados todo dia e arquivos de exemplo para os visitantes do blog. O questionário já tinha decidido como seriam, quando veio a correção: “dados fictícios não entra na nossa série, porque é um projeto à parte: isso não faz parte da especificação do CRM”.

A distinção importa. Um credor de verdade não tem usuários públicos nem uma carteira que se apaga toda madrugada. Se essas regras entrassem na especificação, o produto passaria a carregar requisitos que só existem por causa da vitrine. A demonstração virou um projeto separado, com documento próprio. O que ela precisar do CRM, ela usa como qualquer cliente usaria: usuários, perfis e permissões.

Perfis fixos ou configuráveis#

A escolha contrariou a recomendação, e as consequências apareceram na mesma hora. Permissões configuráveis exigem decidir quais permissões existem, com que perfis o sistema começa e o que impede uma configuração de trancar o sistema. Foram três perguntas a mais, todas necessárias.

Seis permissões, e a separação entre preparar e aplicar#

A lista ficou com seis permissões, uma por ação:

• consultar a carteira;
• enviar e conferir importação;
• confirmar importação;
• alterar configuração (faixas de atraso e títulos a vencer);
• gerenciar usuários;
• gerenciar perfis.

A alternativa era uma permissão por tela, com conferir e confirmar juntos. Separar as duas permite o controle que auditores chamam de “quatro olhos”: quem prepara a carga não é quem a aplica. A especificação torna esse controle possível, sem obrigá-lo. Um credor pequeno, com uma pessoa só no financeiro, não conseguiria operar se ele fosse obrigatório.

O sistema começa com dois perfis editáveis, Gestor (as seis permissões) e Operador (só consultar), e cada usuário tem exatamente um perfil. A opção de somar vários perfis por usuário foi descartada: ela torna difícil responder de onde veio uma permissão, que é a primeira pergunta de qualquer auditoria. A mudança de perfil vale na ação seguinte de quem está logado, e não no próximo login: tirar o acesso de alguém precisa ter efeito imediato. A lógica é a do menor privilégio, que o NIST define como dar a cada usuário só o acesso necessário para a sua tarefa.

O sistema nunca fica sem administrador#

Com perfis configuráveis, uma sequência de cliques razoáveis pode deixar o sistema sem ninguém capaz de administrar. Alguém tira “gerenciar perfis” do perfil Gestor sem perceber que é o único que tem essa permissão. Ou desativa o último gestor. Daí em diante, só quem tem acesso ao servidor resolve.

As alternativas eram deixar acontecer e corrigir por um comando no servidor, ou impedir. A decisão foi impedir: o sistema recusa qualquer alteração que deixe zero usuários ativos com “gerenciar usuários” e “gerenciar perfis” ao mesmo tempo. O comando no servidor continua existindo como última saída. Num projeto comum, essa regra costuma aparecer depois do primeiro incidente, não antes.

Senhas que ninguém mais conhece#

Quem cria um usuário não deveria conhecer a senha dele. Três alternativas foram consideradas:

• o gestor digita a senha e a repassa, e passa a conhecer a senha de cada pessoa;
• um link por e-mail para a pessoa criar a própria senha, o que exige envio de e-mail;
• uma senha temporária, gerada pelo sistema e mostrada uma única vez, com troca obrigatória no primeiro acesso. Foi a escolhida.

Ao escrever a regra, apareceram detalhes que nenhuma pergunta tinha coberto. Por quanto tempo vale a senha temporária? Ficou em 72 horas, o bastante para cobrir um fim de semana. Quem gerencia pode desativar a própria conta? Não. A tela mostra o histórico de acessos de cada usuário? Sim, para quem gerencia. Cada usuário também troca a própria senha, informando a atual, e as outras sessões abertas dele são encerradas.

O e-mail como nome de usuário#

A recomendação era um nome curto, como joana.souza. A decisão foi usar o e-mail, com um motivo que olha para a frente: o mapa do projeto prevê uma fase para assessorias de cobrança que atendem vários credores. Nessa fase, dois “joao.silva” de credores diferentes vão existir no mesmo sistema, e o domínio do e-mail diz quem é quem.

O e-mail é só identificador: nada é enviado para ele. A decisão também trouxe uma premissa registrada, com a área que a validaria: em credores sem domínio próprio, que usam e-mails pessoais, o domínio não distingue nada, e a fase de vários credores vai precisar de outro vínculo.

Uma decisão da vitrine que virou requisito do produto#

Depois de separar a demonstração do produto, uma decisão sobre ela voltou para a especificação. A ideia inicial era que os visitantes do blog só pudessem importar planilhas de exemplo, escolhidas numa lista, para que nenhum dado real entrasse num sistema aberto a qualquer pessoa. A decisão final foi mais realista: o visitante envia o próprio arquivo, como faria um usuário de verdade. Na demonstração, esse arquivo é descartado sem ser lido e trocado por uma planilha fictícia, com um aviso claro antes do envio e na conferência.

Para enviar o próprio arquivo, o visitante precisa saber o que a planilha deve conter. E isso vale para qualquer credor, não só para a vitrine. Por isso entrou na especificação uma regra nova: a tela de importação mostra a tabela das colunas, com o que é obrigatório, o formato e um exemplo, e oferece uma planilha-modelo para baixar, que passa na conferência sem nenhuma recusa. A troca do arquivo e o bloqueio de senhas dos usuários públicos ficaram no documento da demonstração. A orientação do formato ficou na especificação do produto.

As decisões em números#

O que vem a seguir#

A especificação e o plano técnico foram aprovados. O plano usa um modelo de perfil próprio, e não os grupos de permissões que o framework já traz. Os grupos nativos permitem vários por usuário e são organizados por tabela do banco, não por ação do negócio. Cada um dos 16 critérios de aceite vira um teste no navegador, como no incremento 1.