1Preâmbulo

1.1 Objetivo

Esta Política de Gestão de Passwords estabelece os requisitos e boas práticas para criação, gestão, armazenamento e utilização de passwords corporativas na [ORGANIZAÇÃO]. A política adota as mais recentes recomendações do NIST SP 800-63B (2024), que representam uma mudança paradigmática na segurança de passwords, priorizando comprimento sobre complexidade e eliminando alterações periódicas obrigatórias.

1.2 Âmbito

Esta política aplica-se a:

• Todos os colaboradores, contratados, fornecedores e terceiros com acesso aos sistemas da [ORGANIZAÇÃO]
• Todas as passwords utilizadas para aceder a sistemas corporativos, aplicações, bases de dados, serviços cloud e infraestrutura de rede
• Contas de utilizador, contas administrativas, contas de serviço e contas partilhadas
• Sistemas desenvolvidos internamente e serviços adquiridos externamente

1.3 Conformidade Regulamentar

Esta política assegura conformidade com os seguintes requisitos:

• NIS2 Artigo 21(2)(e): Políticas e procedimentos para avaliar a eficácia das medidas de gestão de riscos de cibersegurança, incluindo controlos de acesso
• NIST SP 800-63B (2024): Digital Identity Guidelines - Authentication and Lifecycle Management
• ISO 27001 A.5.17: Informação de autenticação
• CIS Controls v8 - Control 6: Access Control Management

2Princípios Fundamentais

2.1 Mudança de Paradigma NIST 2024

As novas guidelines do NIST (2024) representam uma revolução na gestão de passwords, baseada em evidência científica e estudos de usabilidade:

2.2 Princípios Orientadores

1. Comprimento Mínimo de 15 Caracteres: O NIST recomenda mínimo de 8, mas boas práticas da indústria indicam 15 caracteres para segurança robusta
2. Suporte até 64 Caracteres: Todos os sistemas devem suportar passwords até 64 caracteres para acomodar passphrases longas
3. Todos os Caracteres Permitidos: Suportar Unicode e todos os caracteres ASCII imprimíveis (incluindo espaços)
4. Sem Alterações Periódicas: Passwords só devem ser alteradas quando há suspeita de compromisso
5. MFA Obrigatório: Autenticação multifator para contas privilegiadas e acesso remoto
6. Gestores de Passwords Incentivados: Ferramenta corporativa aprovada para geração e armazenamento
7. Caminho para Passwordless: Migração progressiva para FIDO2/WebAuthn e passkeys

3Requisitos de Passwords

3.1 Requisitos por Tipo de Conta

3.2 Requisitos Técnicos

• Comprimento: Mínimo 15 caracteres (utilizadores), 20 caracteres (admins), máximo 64 caracteres suportados
• Caracteres Permitidos: Todos os caracteres ASCII imprimíveis (espaço a ~) + Unicode
• Sem Regras de Composição: Não exigir tipos específicos de caracteres (maiúsculas, números, símbolos)
• Sensibilidade a Maiúsculas: Passwords devem ser case-sensitive
• Sem Truncação: Sistema não pode truncar passwords silenciosamente
• Verificação contra Blocklist: Rejeitar passwords comprometidas conhecidas

3.3 Exemplos de Passphrases Fortes

3.4 Calculadora de Força de Password

3.5 Gerador de Passphrases

4Passwords Proibidas

4.1 Verificação contra Blocklists

Todos os sistemas de autenticação da [ORGANIZAÇÃO] devem verificar passwords contra as seguintes blocklists:

4.2 Categorias de Passwords Proibidas

4.3 Implementação Técnica

4.4 Mensagens de Erro

Quando uma password é rejeitada pela blocklist, o sistema deve apresentar mensagens claras:

• Password Comprometida: "Esta password foi exposta em violações de dados conhecidas. Por favor, escolha uma password diferente."
• Password Comum: "Esta password é muito comum e facilmente adivinhável. Por favor, escolha uma password mais forte."
• Dados Organizacionais: "A password não pode conter o nome da empresa ou variações. Por favor, escolha uma password diferente."
• Dados do Utilizador: "A password não pode conter o seu nome ou username. Por favor, escolha uma password diferente."

5Autenticação Multifator (MFA)

5.1 Âmbito Obrigatório

A autenticação multifator (MFA) é obrigatória para:

• Todas as contas administrativas e privilegiadas
• Acesso remoto a sistemas corporativos (VPN, Remote Desktop)
• Acesso a sistemas que processam dados sensíveis (definidos como [CLASSIFICAÇÃO DADOS SENSÍVEIS])
• Acesso a serviços cloud corporativos (Microsoft 365, AWS, Azure, etc.)
• Acesso ao gestor de passwords corporativo
• Reset de passwords e alterações de segurança

5.2 Métodos MFA Aprovados

5.3 Níveis de Garantia de Autenticação (NIST AAL)

5.4 Implementação na [ORGANIZAÇÃO]

Solução MFA Corporativa: [SOLUÇÃO MFA - ex: Microsoft Authenticator, Duo Security, Okta]

Métodos Aprovados:

1. [MÉTODO 1 - ex: Microsoft Authenticator TOTP]
2. [MÉTODO 2 - ex: YubiKey FIDO2 para administradores]
3. [MÉTODO 3 - ex: Passkeys (em piloto)]

5.5 Procedimentos de Backup MFA

Em caso de perda ou indisponibilidade do dispositivo MFA primário:

• Códigos de Backup: Utilizadores devem guardar códigos de recuperação únicos em local seguro (físico)
• Dispositivo MFA Secundário: Registar um segundo dispositivo MFA quando possível
• Processo de Reset: Contactar [HELPDESK/IT SUPPORT] com identificação por [MÉTODO VERIFICAÇÃO - ex: chamada vídeo + ID corporativo]

6Gestores de Passwords Corporativos

6.1 Política de Utilização

A [ORGANIZAÇÃO] reconhece que é humanamente impossível memorizar passwords únicas, longas e complexas para dezenas de sistemas. Por isso, a utilização de gestores de passwords corporativos é obrigatória e incentivada.

6.2 Gestor de Passwords Corporativo Aprovado

6.3 Funcionalidades Obrigatórias

O gestor de passwords corporativo deve suportar:

• Geração de Passwords: Passwords aleatórias até 64 caracteres com entropia elevada
• Cofre Encriptado: Encriptação AES-256 ou superior, zero-knowledge architecture
• Partilha Segura: Cofres de equipa para credenciais partilhadas com auditoria
• Integração Browser: Extensions para preenchimento automático seguro
• Aplicação Móvel: Apps nativas para iOS e Android com autenticação biométrica
• Auditoria de Segurança: Identificação de passwords fracas, reutilizadas ou comprometidas
• MFA Integrado: Suporte para TOTP/HOTP para códigos 2FA
• Logs de Auditoria: Registo de acessos, alterações e partilhas

6.4 Cofres Corporativos

6.5 Master Password

A master password do gestor de passwords é a única password que os utilizadores precisam de memorizar:

• Comprimento Mínimo: 20 caracteres (recomendado 25+)
• Tipo: Passphrase memorável e única
• Nunca Partilhar: Master password é pessoal e intransmissível
• Nunca Escrita: Não deve ser anotada fisicamente ou digitalmente fora do gestor
• MFA Obrigatório: Acesso ao gestor de passwords requer MFA adicional

6.6 Gestores de Passwords Pessoais

Gestores de passwords pessoais (ex: Apple Keychain, Google Password Manager) podem ser utilizados para passwords pessoais, mas não devem ser utilizados para credenciais corporativas da [ORGANIZAÇÃO].

7Armazenamento Seguro de Passwords

7.1 Proibição de Armazenamento Plaintext

7.2 Algoritmos de Hashing Aprovados

Todas as passwords devem ser armazenadas usando funções de hashing criptográfico adequadas:

7.3 Salting Obrigatório

Todas as passwords devem incluir salt criptograficamente seguro:

• Salt Único: Cada password deve ter um salt aleatório único (mínimo 16 bytes, recomendado 32 bytes)
• Geração Segura: Utilizar gerador criptográfico (ex: crypto.getRandomValues(), secrets.token_bytes())
• Armazenamento: Salt deve ser armazenado junto ao hash (não é secreto)
• Sem Reutilização: Nunca reutilizar salts entre utilizadores ou passwords

7.4 Implementação Técnica

from argon2 import PasswordHasher

# Configuração segura
ph = PasswordHasher(
    time_cost=3,        # Iterations
    memory_cost=65536,  # 64 MB
    parallelism=4,      # Threads
    hash_len=32,        # Output length
    salt_len=16         # Salt length
)

# Hashing (ao criar/alterar password)
hash = ph.hash("user_password_here")
# Resultado: $argon2id$v=19$m=65536,t=3,p=4$...

# Verificação (ao autenticar)
try:
    ph.verify(hash, "user_password_attempt")
    # Password correta
except:
    # Password incorreta

7.5 Proteção em Trânsito

Passwords em trânsito (transmissão) devem ser protegidas:

• TLS/HTTPS Obrigatório: Todas as submissões de passwords devem usar TLS 1.2+ (preferencialmente TLS 1.3)
• Certificate Pinning: Para aplicações móveis críticas
• POST Method: Passwords nunca em URL query parameters (usar POST body)
• Sem Logs: Passwords não devem aparecer em logs de aplicação, servidor web ou proxy

7.6 Rotação de Hashing Algorithm

À medida que os algoritmos evoluem, a [ORGANIZAÇÃO] deve:

1. Monitorizar Recomendações: Acompanhar guidelines do NIST e OWASP
2. Plano de Migração: Migrar progressivamente de algoritmos obsoletos (ex: PBKDF2) para modernos (Argon2id)
3. Rehashing Transparente: Ao autenticar com hash legado bem-sucedido, fazer rehash com algoritmo moderno
4. Prazo de Migração: [DATA MIGRAÇÃO COMPLETA]

8Recuperação e Reset de Passwords

8.1 Self-Service Password Reset (SSPR)

A [ORGANIZAÇÃO] disponibiliza um sistema de reset de password self-service para reduzir carga do helpdesk e melhorar experiência do utilizador.

8.2 Fluxo de Reset de Password

1. Identificação do Utilizador: Inserir username ou email corporativo
2. Verificação de Identidade: MFA através de método registado (app authenticator, SMS backup)
3. Geração de Token: Sistema gera token único, criptograficamente seguro
4. Link Temporário: Envio de link de reset com validade de [TEMPO VALIDADE - ex: 1 hora]
5. Nova Password: Utilizador define nova password (sujeita a todas as validações)
6. Confirmação: Sistema confirma alteração e invalida token
7. Notificação: Email de confirmação enviado para endereço registado

8.3 Requisitos de Verificação de Identidade

8.4 Passwords Temporárias

Quando necessário fornecer passwords temporárias (ex: novos colaboradores, reset manual):

• Geração Aleatória: Passwords temporárias devem ser geradas aleatoriamente (mínimo 16 caracteres)
• Única Utilização: Sistema deve forçar alteração no primeiro login
• Validade Curta: Expiração em [PRAZO - ex: 24 horas]
• Canal Seguro: Entregue através de canal seguro (em mão, SMS, email encriptado - nunca plaintext email)
• Sem Reutilização: Password temporária não pode ser reutilizada como password permanente

8.5 Práticas PROIBIDAS

8.6 Auditoria e Logging

Todos os eventos de reset de password devem ser registados:

• Timestamp da solicitação de reset
• Username do utilizador
• Método de verificação utilizado
• Endereço IP de origem
• Sucesso ou falha da operação
• Timestamp da efetivação do reset

Retenção de Logs: [PERÍODO RETENÇÃO - ex: 12 meses]

9Contas de Serviço e Partilhadas

9.1 Princípio da Minimização

A [ORGANIZAÇÃO] adota o princípio de minimizar contas partilhadas. Contas individuais com permissões adequadas são sempre preferíveis a contas partilhadas.

9.2 Contas de Serviço

Contas de serviço são utilizadas por aplicações, scripts e processos automatizados:

9.2.1 Requisitos

• Autenticação Preferencial: Utilizar certificados, chaves SSH ou tokens OAuth em vez de passwords quando possível
• Passwords Longas: Se password necessária, mínimo 32 caracteres, geradas aleatoriamente
• Armazenamento Seguro: Passwords de serviço devem estar em:
  • Cofre do gestor de passwords corporativo, OU
  • Secret management system (ex: [SISTEMA SECRETS - ex: HashiCorp Vault, AWS Secrets Manager]), OU
  • Variáveis de ambiente encriptadas em CI/CD
• Sem Hardcoding: Passwords NUNCA em código fonte, ficheiros de configuração não encriptados ou scripts
• Princípio do Menor Privilégio: Contas de serviço apenas com permissões estritamente necessárias

9.2.2 Rotação de Passwords de Serviço

9.3 Contas Partilhadas

Quando contas partilhadas são inevitáveis (ex: conta redes sociais corporativas, sistema legado):

9.3.1 Requisitos

• Aprovação Obrigatória: Criação de conta partilhada requer aprovação de [RESPONSÁVEL APROVAÇÃO]
• Justificação Documentada: Razão pela qual conta individual não é viável
• Armazenamento no Cofre: Credenciais armazenadas exclusivamente no gestor de passwords corporativo
• MFA Obrigatório: Sempre que o sistema suportar
• Check-out/Check-in: Sistema de checkout para rastreabilidade (quem acedeu quando)
• Lista de Acesso Restrita: Apenas utilizadores autorizados nominalmente

9.3.2 Rotação de Passwords Partilhadas

Passwords de contas partilhadas devem ser alteradas:

• A cada [FREQUÊNCIA - ex: 90 dias]
• Quando um utilizador com acesso deixa a organização
• Quando um utilizador com acesso muda de função e não necessita mais do acesso
• Após qualquer suspeita de compromisso

9.4 Auditoria

O [DEPARTAMENTO IT/SEGURANÇA] deve realizar auditoria trimestral de:

• Inventário de todas as contas de serviço e partilhadas
• Lista de acessos autorizados para cada conta partilhada
• Data da última rotação de password
• Logs de acesso (quem, quando, de onde)
• Oportunidades para eliminar contas partilhadas

10Autenticação Passwordless (Roadmap)

10.1 Visão Estratégica

A [ORGANIZAÇÃO] reconhece que a autenticação passwordless representa o futuro da segurança, eliminando o vetor de ataque mais comum (passwords fracas/roubadas) e melhorando a experiência do utilizador.

10.2 Tecnologias Passwordless

10.3 Vantagens Passwordless

• Segurança Superior: Elimina phishing, credential stuffing, password spraying
• Resistente a Phishing: FIDO2/WebAuthn verifica o domínio, impossível de phishing
• Experiência do Utilizador: Mais rápido e conveniente que digitar passwords
• Redução de Custos: Menos resets de passwords, menos chamadas ao helpdesk
• Conformidade: Alinhado com melhores práticas de Zero Trust

10.4 Plano de Implementação Faseado

Fase 1: Piloto (Q1 [ANO])

• Âmbito: [GRUPO PILOTO - ex: Equipa IT (20 utilizadores)]
• Tecnologia: FIDO2 com YubiKeys + Windows Hello for Business
• Sistemas: Microsoft 365, VPN, sistema administrativo interno
• Sucesso: 90% de adoção, satisfação do utilizador >8/10, zero incidentes

Fase 2: Contas Administrativas (Q2 [ANO])

• Âmbito: Todas as contas admin/privilegiadas ([NÚMERO] contas)
• Tecnologia: FIDO2 obrigatório (YubiKeys distribuídas)
• Sistemas: Acesso administrativo a todos os sistemas críticos
• Requisito: Fallback MFA mantido como backup

Fase 3: Utilizadores Corporativos (Q3-Q4 [ANO])

• Âmbito: Todos os utilizadores corporativos ([NÚMERO] utilizadores)
• Tecnologia: Passkeys (Apple/Google) + Windows Hello + FIDO2 opcional
• Sistemas: Microsoft 365, aplicações SaaS principais, intranet
• Approach: Opt-in inicialmente, obrigatório após período de transição

Fase 4: Integração Completa (2026+)

• Âmbito: Todos os sistemas, incluindo aplicações custom
• Objetivo: 95%+ de autenticações passwordless
• Passwords: Mantidas apenas como fallback de emergência

10.5 Desafios e Mitigações

10.6 Responsáveis

• Sponsor Executivo: [NOME CIO/CISO]
• Project Manager: [NOME PM]
• Implementação Técnica: [EQUIPA IT/SEGURANÇA]
• Formação e Comunicação: [DEPARTAMENTO RH/FORMAÇÃO]