Política de senhas no Protheus: as regras que valem para todo usuário

A política é o lugar em que se escreve uma regra de senha uma vez só, para o ambiente inteiro. Tamanho mínimo, letras e números, troca periódica, quantas tentativas erradas até bloquear: tudo fica na mesma rotina.

A própria TOTVS recomenda abrir a Política logo depois de instalar o Protheus e definir as regras, porque no padrão as configurações vêm desabilitadas (Não) ou com valores mínimos. Nas versões recentes, porém, regra desabilitada na Política não significa senha livre: há um mínimo que o sistema aplica de qualquer forma.

As seções abaixo descrevem o que cada campo da Política faz. Onde o campo é mais frouxo que esse mínimo, vale o mínimo.

Ficam em Política de Segurança > Regras de Senha.

Repetição de parte da senha

A comparação é com a senha antiga. O exemplo da documentação: se a senha antiga era 135678, a nova não pode conter 135.

Segundo a documentação, a regra é aplicada quando o usuário troca a senha na entrada do sistema: como a senha é armazenada em hash, a validação é feita na autenticação do usuário, durante a troca de senha.

A máscara diz quantas vezes cada tipo de caractere aparece na senha. A ordem não importa.

O detalhe que confunde é o # na primeira posição:

• Com #, a máscara é o mínimo. #Aaa99X aceita TOTvs@1701 e recusa TOTvs@1, que tem só um número.
• Sem #, a máscara é o máximo, e a contagem começa do zero. Pela regra da máscara, Aaa99X aceita @17Tvs e recusa @17Tvsz, que tem mais de duas letras minúsculas.

O exemplo que mais engana é o 9AX sem #. Pela regra da máscara, ele aceita aaa e recusa 123, porque permite no máximo um número, no máximo uma maiúscula e no máximo um caractere especial. Quem escreve 9AX querendo exigir número, maiúscula e especial não está exigindo nada com a máscara. Para exigir pela máscara, use #9AX.

“Troca periódica da senha a cada n dias” define de quanto em quanto tempo a senha vence. Nas regras de senha também ficam “Notificar expiração n dias antes”, que avisa o usuário com antecedência, e “Forçar troca da senha em”, que obriga todos a trocar numa data. Essa data só existe na Política: não dá para forçá-la para usuários ou grupos específicos.

Antes da tabela, o detalhe que a explica: 0 no usuário ou no grupo não é o menor prazo, é “sem prazo nesse nível”. Nas palavras da documentação: “Caso não esteja configurado no usuário/grupo (igual a 0), será respeitado o que estiver configurado na Política”. Por isso o 0 fica fora do “prevalece a menor data”.

A documentação traz esta tabela de casos. Em todos eles a Política está com 21 dias; os prazos do usuário e do grupo também estão em dias:

Para que todos os usuários troquem a senha no mesmo prazo, o passo a passo da documentação (no exemplo, 45 dias) é:

1. No cadastro dos usuários e dos grupos a que eles pertencem, preencha “Troca periódica da senha a cada n dias” com 0.
2. Em Usuário > Senhas > Política, aba Política de Segurança > Regras de senha, preencha “Troca periódica da senha a cada n dias” com o prazo e clique em Confirmar.

Nas versões recentes, esse prazo da Política não pode passar de 3 meses.

A consequência prática: é a Política que liga a troca periódica. Não dá para zerar a Política e exigir troca só de um grupo. A notificação de vencimento também só se configura na Política, mesmo quando o prazo vem do usuário. Nas versões recentes, zerar a Política também não desliga a troca: a senha tem de ser trocada a cada 3 meses de qualquer forma.

A exceção é o atributo Ignorar Troca Periódica de Senha, feito para contas de serviço: usuários que autenticam serviços REST, SOAP ou outro processo em que a troca periódica pode causar indisponibilidade. Segundo a documentação:

• ele desconsidera só a expiração definida nas Políticas e nos Grupos de Usuários. O prazo configurado no cadastro do usuário continua valendo; para desconsiderá-lo também, informe 0 na troca periódica do próprio usuário;
• não está disponível para o usuário Administrador principal;
• não dispensa a primeira troca, se a senha não atender aos requisitos obrigatórios;
• só passa a existir depois da atualização. Por isso, antes de migrar, as contas usadas em serviços precisam estar “com as senhas atualizadas a menos de 30 dias”, já atendendo aos requisitos mínimos obrigatórios, “sendo esta a única forma de evitar indisponibilidades no ambiente”;
• deve ser ativado apenas para contas de serviço, que precisam ser monitoradas de perto. O Dashboard de privilégios ganhou um card com a lista de usuários com o atributo ativo.

A TOTVS apresenta esse atributo como temporário, até a entrega de uma solução definitiva para o mecanismo de autenticação.

Separado da data forçada, o campo Forçar troca de senha, também nas Regras de Senha, decide o que acontece com usuário novo. Ele controla a opção “Forçar troca de senha no próx. logon” da inclusão de usuário:

Não confunda os dois: “Forçar troca da senha em” é uma data que vale para todos os usuários; “Forçar troca de senha” é a regra do primeiro login de quem for criado dali em diante.

Login com maiúsculas e minúsculas

A opção “Usuário case sensitive” define se o login diferencia maiúsculas de minúsculas. Com 1-Sim, mariana.costa e Mariana.Costa são logins diferentes.

Com o dicionário de dados no banco, a documentação avisa que, “para que o modo Case Sensitive do Login do Usuário funcione corretamente, é necessário estar com o Collation correto para o sistema”. Confira a collation do banco antes de ligar a opção.

Ficam em Política de Segurança > Regras de Violação.

Pela documentação da Política, depois de bloqueado o usuário precisa ser desbloqueado pelo administrador, a menos que “Desbloquear usuário após n minutos” esteja configurado. Nesse caso, ele é liberado automaticamente.

Nas versões recentes, o mínimo obrigatório muda esse cenário: três tentativas erradas dentro de um minuto bloqueiam o login por um minuto, com desbloqueio automático, e o número de tentativas só pode ser configurado em 3 ou menos. A documentação das regras obrigatórias não explica como esse bloqueio temporário convive com os campos desta aba; confira no seu ambiente antes de combinar o procedimento de liberação.

Nos parâmetros da mesma aba há dois avisos diferentes:

• Notificar administrador sobre bloqueio: avisa o administrador quando um usuário é bloqueado.
• Notificar sobre tentativa de violação: avisa o administrador quando um usuário tenta entrar depois de esgotar as tentativas.

E, em Múltiplos Terminais:

• Inibir acesso a mais de um terminal: o usuário não pode usar o sistema em mais de um computador. Em job, esse acesso não é inibido.
• Bloquear usuário ao acessar outro terminal: com a opção anterior habilitada, o usuário que entrar num segundo computador é bloqueado.

Recomendação: decida as três regras de bloqueio juntas, e não só o número de tentativas, que nas versões recentes não passa de 3. Teste no seu ambiente o que acontece depois do bloqueio de um minuto: se o usuário ainda depender do administrador para voltar a entrar, preencha o desbloqueio automático ou combine antes quem faz a liberação e em que horário.

Em Outros > Parâmetros fica a opção “Habilita privilégio para usuário do grupo administrador”. Ela define se os usuários do grupo Administradores sofrem as restrições dos privilégios atrelados a eles. Por isso a pergunta “o privilégio vale para o administrador?” não tem uma resposta única: depende dessa opção. O funcionamento dos privilégios está em Privilégios no Protheus: a diferença entre não permitido e negado.

O que fica fora deste artigo

As regras de senha também têm o Single Sign-On, com as modalidades Sistema Operacional, SAML e Active Directory. A aba Integrações configura integrações do tipo oAuth, SAML e SCIM. Há ainda as abas de conexões (proxy e SMTP) e, em Outros, as regras de auditoria. Cada um desses temas merece um artigo próprio.

O cadastro de cada pessoa (login, grupo, filiais, data base) está em Cadastro de usuários no Protheus: o que cada aba decide.