Uma política de palavras-passe deve definir como uma conta é criada, protegida, recuperada e desativada. O comprimento do segredo é apenas uma parte. A organização precisa de distinguir contas humanas, privilégios administrativos, contas técnicas e meios de recuperação, verificando se a autenticação multifator continua efetiva durante todo esse ciclo.
O resultado deste guia é uma política preenchida e um conjunto de critérios de aceitação. O exemplo usa escolhas técnicas explícitas, apresentadas como decisões de uma organização hipotética. Não são um mínimo legal universal imposto pelo RGPD às empresas portuguesas. A política integra-se na política de segurança da informação e deve corresponder às capacidades reais das aplicações.
Inventariar contas antes de escolher regras
Liste os serviços, os tipos de utilizador e a forma de autenticação. Identifique aplicações que usam um serviço central de identidade e aplicações com palavras-passe próprias. Um acesso federado não garante que todas as contas locais de emergência ou de administração tenham sido desativadas.
A cartografia de sistemas permite localizar contas esquecidas em portais de fornecedores, ferramentas de suporte e serviços usados por uma pequena equipa. Para cada sistema, indique o dono, a entidade que administra a identidade e as opções de recuperação. Sem esta informação, uma política central pode abranger apenas uma parte dos acessos.
Distinga contas pessoais de contas de serviço. Uma integração automática precisa de um responsável e de gestão dos seus segredos, mas não deve ser tratada como um trabalhador que introduz uma palavra-passe diariamente. As contas partilhadas exigem análise especial porque dificultam a atribuição de ações e a retirada do acesso a uma única pessoa.
Escolher uma referência e explicar o que significa
O NIST SP 800-63B-4 estabelece, no seu âmbito, pelo menos 15 caracteres para palavras-passe usadas como fator único. Admite um mínimo de oito quando usadas apenas em processos multifator e recomenda permitir um máximo de pelo menos 64. Prevê bloqueio de escolhas comprometidas, limitação de tentativas e ausência de regras arbitrárias de composição ou mudança periódica, exigindo mudança perante compromisso. É uma referência técnica norte-americana, não legislação portuguesa. NIST SP 800-63B-4, secção 3.1.1.2.
O RGPD exige medidas adequadas ao risco, considerando as circunstâncias do tratamento e o estado da técnica. Uma política deve conseguir explicar por que razão as suas escolhas protegem os dados e como são aplicadas. Não basta invocar um número de caracteres ou uma certificação do fornecedor. RGPD, artigo 32.º.
Exemplo preenchido de política
A empresa hipotética presta serviços profissionais e usa aplicações com dados de clientes e trabalhadores. Decide aplicar uma regra comum às contas humanas e medidas adicionais aos acessos privilegiados. O exemplo pressupõe que as aplicações permitem estas configurações; as exceções são tratadas no procedimento descrito adiante.
| Elemento | Decisão da organização no exemplo |
|---|---|
| Contas humanas | Conta individual e palavra-passe com pelo menos 15 caracteres |
| Comprimento aceite | Permitir pelo menos 64 caracteres, sem truncar o segredo |
| Autenticação adicional | MFA nos serviços abrangidos, com prioridade a métodos resistentes a phishing |
| Escolhas fracas | Rejeitar palavras-passe conhecidas como comprometidas ou facilmente previsíveis |
| Alterações | Sem troca periódica automática; mudança perante compromisso ou necessidade fundamentada |
| Privilégios | Conta administrativa separada da conta de utilização diária |
| Recuperação | Procedimento próprio, verificação adequada e registo de alterações |
| Exceções | Dono do risco, limitação compensatória e revisão definida |
A aprovação identifica as aplicações abrangidas e as que ainda não cumprem a configuração. O dono de cada aplicação recebe uma tarefa de implementação. Um documento não deve afirmar que a regra já se aplica a todos os sistemas quando parte da configuração ainda depende de uma migração.
Ajudar o utilizador a criar e guardar segredos
Disponibilize instruções que evitem reutilização e escolhas previsíveis. Uma frase longa pode ser mais fácil de utilizar, mas não deve ser uma expressão pública óbvia ou uma sequência repetida em todas as contas. Um gestor de palavras-passe aprovado pode facilitar a criação de segredos distintos e a sua conservação controlada.
A organização deve definir como se acede ao gestor, como se recupera uma conta e quais os segredos que podem ser partilhados em cofres de equipa. Não transforme um cofre partilhado numa solução para todas as contas individuais. Quando alguém sai, é necessário rever o que essa pessoa podia conhecer e não apenas remover a sua conta do gestor.
A interface deve funcionar com o método aprovado: preenchimento automático, colagem quando aplicável e mensagens de erro compreensíveis. Ensaiar estes percursos reduz a probabilidade de os utilizadores criarem soluções improvisadas. A política de utilização dos recursos informáticos deve indicar onde pedir ajuda e quais os canais autorizados.
MFA: verificar o percurso completo
A autenticação multifator combina fatores distintos. Duas perguntas de conhecimento não criam dois fatores independentes. Também é necessário perceber que métodos estão disponíveis, como são inscritos e o que acontece quando o utilizador perde o equipamento ou muda de número.
Sempre que possível e adequado ao risco, dê prioridade a métodos que reduzam a exposição ao phishing. Os mecanismos não têm todos a mesma resistência a páginas falsas, pedidos fraudulentos ou fadiga de notificações. Explique aos utilizadores o significado de um pedido de aprovação inesperado e o canal para comunicar a situação.
O ensaio deve abranger o início de sessão normal, a inscrição de um novo fator e a recuperação. Uma conta pode exigir MFA diariamente e, mesmo assim, permitir que um pedido informal ao suporte remova essa proteção. A segurança da recuperação deve ser compatível com o acesso que ela devolve.
Contas administrativas e acesso de emergência
Separe o uso diário do exercício de privilégios. A pessoa que administra sistemas não precisa de ler correio ou navegar habitualmente com a mesma conta privilegiada. Defina quais as tarefas autorizadas, como são aprovadas e quais os eventos a registar.
Um acesso de emergência deve ter finalidade e condições próprias. Pode ser necessário quando o serviço central de identidade falha, mas não deve ficar como um caminho fácil para evitar os controlos habituais. Guarde os meios de acesso de forma controlada, limite os destinatários e defina o que será verificado após a utilização.
Num exercício hipotético, a equipa simula a indisponibilidade do serviço de identidade. Confirma que o acesso de emergência permite apenas a recuperação prevista, que a utilização é detetada e que as credenciais são tratadas após o exercício conforme o procedimento. O teste não deve usar dados de clientes desnecessários para demonstrar o funcionamento.
Recuperação sem perguntas pessoais previsíveis
O suporte precisa de um procedimento de identificação e de um limite claro para aquilo que pode alterar. Não deve pedir ao utilizador a palavra-passe atual, códigos de sessão ou outros segredos que permitam assumir a conta. A verificação deve usar os meios previamente definidos para a situação e considerar o risco de engenharia social.
Exemplo preenchido: um trabalhador comunica a perda do telemóvel de autenticação. O suporte confirma a identidade pelo processo aprovado, bloqueia ou revoga o fator perdido conforme a configuração e acompanha a inscrição do novo fator. A mudança fica registada e a pessoa recebe informação sobre o que foi alterado. Se existirem indícios de comprometimento, é acionado também o procedimento de incidente.
Evite concluir que a identidade está confirmada apenas porque a chamada apresenta um número conhecido ou porque o pedido contém informações públicas. O atacante pode conhecer o cargo, a chefia e o endereço de correio do trabalhador. A urgência declarada não deve eliminar os passos essenciais de verificação.
Aplicações antigas e exceções
Uma aplicação pode impor um limite de comprimento incompatível com a política ou não oferecer MFA. Registe a limitação real e a exposição, em vez de escrever que o sistema cumpre por ser usado há muitos anos. Considere restrições de rede, acesso através de um ponto protegido, redução de privilégios ou substituição, conforme a arquitetura.
A exceção deve indicar a conta ou aplicação abrangida, o risco, a medida compensatória, o responsável e uma data de reavaliação. A direção deve conhecer exceções que afetem dados ou operações relevantes. Não use a lista de exceções como um arquivo onde as limitações deixam de ser discutidas.
A configuração segura de Windows e Linux e a revisão do ambiente Microsoft 365 podem revelar diferenças entre regras centrais e contas locais. As medidas devem corresponder às versões e modalidades efetivamente utilizadas, sem pressupor que todas as funcionalidades estão disponíveis em qualquer contrato.
Guardar verificadores e segredos de integração
Se a organização desenvolve aplicações, a política deve incluir requisitos para o armazenamento seguro dos verificadores de palavras-passe e para a proteção do canal de autenticação. Uma palavra-passe não deve ficar em texto simples num ficheiro de configuração ou num registo de diagnóstico. A revisão técnica deve ser feita por quem conhece o mecanismo utilizado.
Os segredos de integração precisam de inventário, acesso limitado e substituição controlada. Evite incluí-los no código-fonte ou em mensagens partilhadas com toda a equipa. Teste a revogação de uma credencial antiga sem interromper desnecessariamente o serviço e confirme quais os sistemas que dependem dela.
A política de logs deve registar eventos úteis de alteração e utilização, sem armazenar os próprios segredos. Pode ser relevante saber que uma chave foi criada ou revogada, quem executou a ação e qual a integração afetada; não é necessário copiar o valor da chave para demonstrar esse facto.
Aceitar a implementação com casos concretos
Prepare contas de ensaio para verificar comprimento, rejeição de escolhas comprometidas, ausência de truncagem, MFA e recuperação. Confirme o comportamento de uma tentativa falhada e a limitação de tentativas. Teste também que uma conta desativada deixa de conseguir entrar pelas vias alternativas conhecidas.
A aceitação deve incluir um caso de entrada, uma mudança de função e uma saída. No caso de saída, confira aplicações externas, sessões ainda válidas e acessos partilhados. Uma pessoa pode perder a conta principal e continuar com acesso através de um portal que não recebe a mesma informação.
Registe os resultados e atribua correções com prioridade. A política torna-se útil quando a equipa consegue demonstrar o ciclo completo, incluindo os caminhos menos frequentes. Uma nova aplicação, um incidente ou uma alteração do método de autenticação deve desencadear a revisão das partes afetadas, mantendo as instruções acessíveis aos utilizadores.