Funcionalidades de segurança dos gestores de palavras-passe: Como avaliá-las

Todos os fornecedores de gestores de palavras-passe afirmam oferecer uma segurança robusta. Poucos mostram a documentação de arquitetura ou o resumo do teste de intrusão que permitiria confirmá-lo. É no intervalo entre uma página de segurança e uma afirmação verificada que a due diligence tem de começar.

Avaliar as funcionalidades de segurança de um gestor de palavras-passe significa confrontar com provas, e não com textos de marketing, a arquitetura de cifragem, a força da autenticação, a governação de acessos, a verificação independente, o alinhamento com a conformidade e a resiliência operacional.

Este é um guia de verificação de segurança, não um guia de compra, e integra o guia de gestão de palavras-passe empresarial do Passwork, de âmbito mais alargado. Se ainda estiver a comparar fornecedores quanto ao custo, à implementação e à adequação a DevOps, comece pelo modelo de compra completo com 10 critérios; regresse aqui quando tiver uma lista restrita e precisar de confirmar que as afirmações de segurança se sustentam.

Porque é que «tem cifragem» não é uma resposta de segurança

«Utilizamos cifragem de nível militar» nada diz sobre quem pode decifrar o cofre, como decorreria uma violação ou se algum auditor externo alguma vez testou a afirmação. A cifragem é um requisito mínimo, não um fator diferenciador. O que determina realmente o risco está uma camada abaixo da mensagem de marketing.

Os riscos de errar nesta avaliação continuam a aumentar. O custo médio global de uma violação de dados atingiu 4,99 milhões de dólares em 2026, um aumento de 12 % e um máximo histórico, segundo o Cost of a Data Breach Report 2026 da IBM. O risco associado às credenciais também não desapareceu: o 2026 Data Breach Investigations Report da Verizon concluiu que a exploração de vulnerabilidades subiu para 31 % das violações como primeiro ponto de entrada registado em 2026 e ultrapassou o abuso de credenciais, que desceu para 13 % nessa mesma contagem do primeiro passo. Quando se considera qualquer fase de um ataque, e não apenas o movimento inicial, o abuso de credenciais continua presente em 39 % das violações, o ponto de estrangulamento mais comum do relatório.

Uma afirmação verificada e outra não verificada podem ter exatamente a mesma redação num site. «Os seus dados são cifrados com AES-256» é verdade tanto para um gestor de palavras-passe com uma arquitetura zero-knowledge genuína como para outro em que o fornecedor detém todas as chaves e pode decifrar registos a pedido. A redação, por si só, não indica qual dos dois se está a adquirir. É essa a lacuna que este modelo colmata, um pilar de cada vez.

Todas as afirmações da página de segurança de um fornecedor podem ser verificadas. Os seis pilares abaixo fornecem uma lista fixa do que verificar e de como o fazer.

O modelo de verificação de segurança de gestores de palavras-passe

O modelo de verificação de segurança de gestores de palavras-passe divide a due diligence dos fornecedores em seis pilares: arquitetura de cifragem, segurança da autenticação e das sessões, governação de acessos, verificação independente, alinhamento com a conformidade e resiliência operacional. Aplique a grelha de avaliação abaixo a qualquer fornecedor, atual ou potencial, antes de confiar numa afirmação que não verificou pessoalmente.

Trate a quarta coluna como uma folha de trabalho viva, não como uma descrição. Registe um resultado real, aprovado ou reprovado, para cada pilar à medida que recolhe provas e classifique como reprovado, por predefinição, tudo o que não conseguir verificar num prazo razoável. Um fornecedor que precisa de três e-mails de seguimento para responder a um pedido de documentação também está a revelar algo sobre a forma como irá gerir um incidente.

Cada pilar tem a sua própria secção abaixo, com as perguntas específicas a fazer e o aspeto de uma aprovação ou reprovação na prática.

Pilar 1: Arquitetura de cifragem e conceção zero-knowledge

Uma arquitetura zero-knowledge significa que o fornecedor não consegue ler os dados nem mesmo perante uma obrigação legal, e não apenas que opta por não os consultar. A cifragem em repouso é uma afirmação muito mais fraca: o fornecedor detém as chaves e pode, em princípio, decifrar o cofre. Confundir as duas é a lacuna mais comum na página de segurança de um fornecedor.

Cifragem em repouso vs. zero-knowledge

A cifragem em repouso protege os dados de um agente externo que roube a base de dados. Não os protege do próprio fornecedor, de uma ordem judicial nem de um elemento interno com acesso à base de dados. O zero-knowledge, também descrito como cifragem ponto a ponto quando aplicado a dispositivos sincronizados, colmata essa lacuna: a cifragem e a decifragem ocorrem exclusivamente no cliente, e o servidor armazena apenas texto cifrado e material de chaves cifrado que não consegue decifrar por si só. Arquitetura zero-knowledge é o termo a procurar explicitamente, e não «cifragem forte».

Como testar a afirmação

Os mecanismos importam mais do que o rótulo. As chaves devem ser geradas no lado do cliente com um gerador de números aleatórios criptograficamente seguro, derivadas através de uma função de derivação de chaves (KDF), como PBKDF2 ou Argon2, com um número elevado de iterações, e utilizadas para cifrar os dados dos cofres e dos registos com AES-256. Chaves por cofre ou por registo, em vez de uma única chave mestra que abranja toda a organização, limitam o raio de impacto caso uma chave venha a ser comprometida.

Uma forma útil de testar se a explicação de um fornecedor é real: pedir-lhe que percorra a cadeia desde a palavra-passe mestra até ao registo em texto simples. Numa conceção zero-knowledge genuína, essa cadeia decorre inteiramente no lado do cliente. A palavra-passe mestra deriva uma chave mestra, a chave mestra decifra uma chave privada armazenada, cifrada, no servidor, a chave privada desbloqueia as chaves de cada cofre e as chaves dos cofres desbloqueiam as chaves individuais dos registos, que decifram cada palavra-passe ou segredo. Se a explicação saltar um passo, ou se o servidor tiver de participar para concluir a decifragem, a arquitetura não é zero-knowledge, independentemente do que diga a brochura.

Lista de verificação

• Peça a documentação de arquitetura ou de criptografia
• Confirme onde são geradas as chaves de cifragem: no dispositivo cliente ou no servidor
• Pergunte se as chaves são exclusivas de cada cofre ou partilhadas por toda a organização
• Confirme que KDF é utilizada e qual o número de iterações ou o custo de memória

Pilar 2: Segurança da autenticação e das sessões

A NIST SP 800-63B-4 determina que os verificadores têm obrigatoriamente (SHALL) de permitir a utilização de gestores de palavras-passe e da funcionalidade de preenchimento automático (secção 3.1.1.2). Um fornecedor cujo produto entra em conflito com o preenchimento automático do navegador, ou cuja política predefinida ainda impõe a rotação de palavras-passe a cada 90 dias, está a contrariar a norma atual, e não a proteger a organização.

Força da MFA e das passkeys

A autenticação multifator (MFA) é inegociável, mas nem toda a MFA é igual. Os códigos por SMS são a opção mais fraca e são vulneráveis a ataques de SIM swap. As palavras-passe de utilização única baseadas no tempo (TOTP) são mais fortes e funcionam offline. As notificações push acrescentam comodidade, mas são vulneráveis a prompt bombing, a menos que sejam combinadas com a correspondência de números. As chaves de segurança de hardware e as passkeys, assentes na norma FIDO2, resistem ao phishing por conceção, porque a credencial está vinculada à origem para a qual foi criada. A compatibilidade com passkeys indica um fornecedor que acompanha as normas atuais.

O desbloqueio biométrico também merece uma análise mais atenta. O Face ID ou um leitor de impressões digitais é normalmente uma camada de comodidade sobre a credencial propriamente dita, que desbloqueia uma chave armazenada no dispositivo em vez de substituir completamente a MFA. É um compromisso razoável num dispositivo pessoal, mas confirme o que acontece num dispositivo partilhado ou não gerido: o desbloqueio biométrico, por si só, concede acesso ao cofre ou continua a exigir o passo de autenticação subjacente?

Palavra-passe mestra e regras de sessão

Os requisitos da palavra-passe mestra merecem o mesmo escrutínio. A NIST SP 800-63B-4 define um patamar concreto: um mínimo de 15 caracteres para palavras-passe de fator único e nenhuma exigência de rotação periódica sem indícios de comprometimento. Se a política predefinida de um fornecedor ainda obrigar a alterar a palavra-passe mestra a cada 90 dias, essa política é anterior à norma atual.

O comportamento do tempo limite de sessão e do bloqueio automático determina durante quanto tempo um dispositivo roubado ou deixado sem vigilância continua explorável. Não confie apenas na ficha técnica. Abra a aplicação, deixe-a inativa durante o tempo limite indicado e confirme que é realmente bloqueada. Teste também o que acontece após uma reposição de palavra-passe: todas as outras sessões ativas são revogadas de imediato ou uma sessão antiga num segundo dispositivo continua a funcionar?

Lista de verificação

• Opções de MFA disponíveis: TOTP, push com correspondência de números, chave de hardware, passkey/FIDO2
• Política de palavra-passe mestra: baseada no comprimento, sem rotação em intervalos fixos
• Tempo limite de sessão e bloqueio automático: teste-os diretamente, não se limite a ler a especificação
• Gestão de sessões simultâneas após uma reposição forçada de palavra-passe ou um fim de sessão

Pilar 3: Governação de acessos e menor privilégio

O controlo de acessos baseado em funções (RBAC) parece um simples requisito a assinalar até se testar o que acontece quando alguém sai. Desativar uma conta de início de sessão único (SSO) revoga o acesso baseado no diretório. Não tem qualquer efeito sobre uma palavra-passe partilhada que quatro pessoas já conhecem, uma chave de API em cache num pipeline de CI ou um token armazenado localmente.

Qual a granularidade real do RBAC

Pergunte qual é a granularidade real do RBAC. O acesso ao nível da função («Administrador» versus «Membro») é a opção menos granular. O acesso baseado em grupos, em que as permissões estão associadas a uma equipa ou departamento e as pessoas as herdam por pertencerem ao grupo, escala melhor e corresponde à forma como o controlo de acessos baseado em funções deve funcionar: conceder acesso ao grupo uma vez e depois adicionar ou remover pessoas. O acesso por pasta ou por item, sobreposto aos grupos, é o que permite a um administrador entregar as credenciais de um fornecedor a um prestador de serviços sem abrir o cofre inteiro.

Desativar no SSO não é revogar

Desativar no SSO ou no AD não é revogar o acesso. É desativar no diretório. Um colaborador que sai e que partilhou um início de sessão para um portal de fornecedor, um dispositivo de rede ou uma aplicação legada continua a conhecer essa palavra-passe até alguém a alterar. Verificar a governação de acessos significa perguntar como o fornecedor trata essa lacuna: uma credencial partilhada é assinalada para rotação na saída do colaborador ou fica simplesmente ali, por revogar, indefinidamente?

A urgência não é teórica. O tempo médio de breakout do eCrime, ou seja, o tempo entre o acesso inicial e o movimento lateral, desceu para 29 minutos em 2025, 65 % mais rápido do que em 2024, segundo o 2026 Global Threat Report da CrowdStrike. Uma revisão de acessos anual não deteta uma credencial que deveria ter sido revogada em abril. Uma revogação em tempo real, desencadeada por eventos, deteta.

As identidades de máquina exigem a mesma disciplina

O princípio do menor privilégio tem de abranger as identidades de máquina, e não apenas as pessoas. As chaves de API, as contas de serviço e as credenciais de CI/CD ficam frequentemente fora do modelo de RBAC por completo: são aprovisionadas uma vez e nunca mais revistas. Pergunte se as contas de serviço têm funções próprias com âmbito definido e uma política de rotação, separadas das contas de utilizador interativas, ou se são um acréscimo improvisado ao mesmo sistema de permissões concebido para pessoas.

Aproveite para fazer mais uma pergunta: o fornecedor consegue responder a «quem teve acesso a esta credencial no mês passado», a posteriori, a partir de um registo de auditoria, sem abrir um pedido de suporte? Caso contrário, o menor privilégio é uma declaração de política, e não um controlo efetivamente aplicado.

Pilar 4: Verificação independente: Auditorias, certificações e histórico de violações

Qualquer pessoa pode escrever «segurança de nível empresarial» numa página de destino. Uma certificação de segurança atual e identificada, com um período de validade, um resumo recente de um teste de intrusão e um histórico de incidentes documentado são o que distingue uma afirmação de uma afirmação verificável. Se um fornecedor não apresentar nenhum dos três, considere isso uma resposta.

O que uma certificação prova realmente

A certificação ISO/IEC 27001 confirma que um fornecedor opera um sistema de gestão de segurança da informação certificado, avaliado por um auditor externo acreditado face a uma norma internacional reconhecida, e não uma lista de verificação autoavaliada. Verifique diretamente as datas de emissão e de validade do certificado, em vez de confiar num selo num site: as certificações são normalmente renovadas anualmente e um selo sem data visível pode estar desatualizado há anos.

Um resumo de um teste de intrusão, idealmente realizado por um terceiro independente ou coordenado através de um programa como o HackerOne, mostra se alguém exterior à equipa do fornecedor tentou recentemente penetrar nos sistemas e o que encontrou.

Pergunte também o que a certificação abrange realmente. Uma declaração de âmbito limitada à «TI corporativa» ou a uma única linha de produtos é uma prova mais fraca do que uma que abranja todo o ambiente de produção onde as credenciais estão armazenadas. Alguns fornecedores também abrem o código-fonte à auditoria de clientes ou de investigadores independentes. Trata-se de um sinal mais forte do que um certificado isolado, embora seja suficientemente invulgar para que a sua ausência não seja, por si só, motivo de exclusão.

O histórico de violações é, em si, uma funcionalidade de segurança

A forma como um fornecedor geriu o seu último incidente de segurança, caso tenha tido algum, é, em si mesma, uma funcionalidade de segurança. A ausência total de histórico de incidentes documentado não é plausível para nenhum fornecedor que opere em grande escala. A pergunta mais útil é se o fornecedor mantém um processo de monitorização e divulgação, ou se «nunca tivemos um incidente» é toda a resposta.

O que pedir ao fornecedor

• Certificação de segurança atual (como a ISO/IEC 27001), com datas de emissão e de validade
• Resumo do teste de intrusão mais recente e periodicidade dos testes (no mínimo, anual)

Pilar 5: Alinhamento com a conformidade (NIST, RGPD, NIS2 e regras setoriais)

Um fornecedor que afirma estar «em conformidade com o RGPD» ou «preparado para a NIS2» sem indicar um artigo específico está a fazer uma afirmação de marketing, e não uma afirmação jurídica. O artigo 32.º do RGPD e o artigo 21.º da NIS2 indicam, cada um, medidas técnicas concretas. Associe as afirmações de um fornecedor diretamente a essas cláusulas e deixe a equipa jurídica confirmar o que «em conformidade» significa para as obrigações específicas da organização.

Artigo 32.º do RGPD

O artigo 32.º, n.º 1, alíneas a) e b), do RGPD exige que os responsáveis pelo tratamento e os subcontratantes apliquem «a pseudonimização e a cifragem dos dados pessoais» e «a capacidade de assegurar a confidencialidade, integridade, disponibilidade e resiliência permanentes dos sistemas e dos serviços de tratamento» (RGPD, art. 32.º). No caso de um gestor de palavras-passe, isto corresponde diretamente ao Pilar 1 (arquitetura de cifragem) e ao Pilar 6 (resiliência) acima, e não a uma política de privacidade genérica.

Artigo 21.º da NIS2

O artigo 21.º, n.º 2, da NIS2 é ainda mais específico. A alínea h) do artigo 21.º, n.º 2, exige «políticas e procedimentos relativos à utilização de criptografia e, se for caso disso, de cifragem». A alínea j) do mesmo número exige «a utilização de soluções de autenticação multifator ou de autenticação contínua [...] se for caso disso» (Diretiva (UE) 2022/2555 (NIS2), art. 21.º). As entidades essenciais e importantes abrangidas pela NIS2 precisam de um fornecedor capaz de indicar ambas as cláusulas pelo número, e não de um que diga «sim, temos MFA» sem indicar onde é aplicada. Os requisitos de acesso e de criptografia da NIS2 aprofundam o que conta como conformidade especificamente para organizações europeias.

NIST e regras setoriais

A NIST SP 800-63B-4, abordada no Pilar 2, é a norma específica de autenticação subjacente à linguagem sobre MFA de ambos os enquadramentos. Vale a pena confirmar que a política predefinida de um fornecedor a reflete efetivamente, e não uma regra de rotação mais antiga e mais rígida herdada de uma norma anterior.

As regras setoriais acrescentam-se a estas três. As organizações de saúde acrescentam a Security Rule da HIPAA, as entidades financeiras da UE acrescentam o DORA e os compradores do setor público têm frequentemente requisitos de residência dos dados que nenhum dos anteriores refere diretamente. Nada disto altera a pergunta fundamental a colocar a um fornecedor de gestores de palavras-passe: que artigo ou cláusula cumpre a sua arquitetura, e essa correspondência está documentada ou é apenas afirmada?

Pilar 6: Resiliência operacional, acesso offline, cópias de segurança e modelo de implementação

As garantias de segurança não resistem a uma falha de rede, à perda de um dispositivo ou a um incidente na nuvem do fornecedor, a menos que o fornecedor as tenha concebido para isso. O acesso offline, um processo de cópia de segurança e recuperação testado e um modelo de implementação que não entregue todas as chaves à infraestrutura de uma única empresa são o que mantém um gestor de palavras-passe utilizável, e seguro, quando algo falha.

Falhas de rede e acesso offline

Pergunte o que acontece quando a rede falha a meio de uma sessão. Alguns produtos falham em modo fechado (fail-closed) e impedem os utilizadores de aceder a qualquer credencial até a ligação ser restabelecida. Outros oferecem um modo offline delimitado e só de leitura para os registos que um utilizador tenha marcado explicitamente para armazenamento em cache local cifrada, e voltam a sincronizar tudo assim que a ligação regressa. O modo só de leitura é a predefinição mais segura: criar, editar e eliminar devem exigir uma ligação ativa e autenticada.

Cópia de segurança e recuperação

A cópia de segurança e a recuperação constituem a segunda metade da resiliência. Pergunte como são cifradas as cópias de segurança, quem controla a infraestrutura de cópias de segurança e como é efetivamente testado um restauro completo, e não apenas agendado. Uma cópia de segurança que nunca foi restaurada num exercício é uma esperança, não um plano.

Modelo de implementação e resiliência da infraestrutura

O modelo de implementação determina quem controla as chaves. Um fornecedor totalmente alojado na nuvem detém a infraestrutura, mesmo numa conceção zero-knowledge, o que significa que a disponibilidade e a jurisdição dependem da região de nuvem e da resposta a incidentes desse fornecedor. As implementações autoalojadas e híbridas colocam a infraestrutura, e a escolha do local onde os dados residem fisicamente, nas mãos do cliente, o que é mais importante para organizações com requisitos de residência dos dados, de isolamento físico (air gap) ou setoriais nas áreas da saúde, das finanças, da administração pública ou das infraestruturas críticas.

Pergunte também pelos modos de falha ao nível da infraestrutura. Servidores de aplicação redundantes e um cluster de base de dados corretamente configurado evitam que uma única falha de hardware interrompa totalmente o acesso. Para organizações que operam redes totalmente isoladas ou com isolamento físico, confirme que a implementação funciona de forma contínua sem qualquer ligação de saída à internet; um instalador offline, por si só, não o garante.

Como o Passwork aborda estes seis pilares

Este modelo aplica-se a qualquer fornecedor, incluindo o Passwork. O Passwork é um gestor de palavras-passe e de segredos autoalojado e zero-knowledge, concebido para equipas empresariais e de DevOps. Eis como responde a cada um dos seis pilares acima, com ligações para a mesma documentação que um avaliador externo pediria.

• Arquitetura de cifragem: o Passwork utiliza um modelo de cifragem zero-knowledge no lado do cliente. As chaves são geradas e utilizadas no cliente. O servidor armazena apenas texto cifrado e material de chaves cifrado, que é cifrado uma segunda vez com uma camada AES-256 independente no lado do servidor. As chaves mestras são derivadas através de PBKDF2 com um número elevado de iterações, e os dados dos cofres e dos registos utilizam AES-256 com chaves exclusivas por cofre e por registo, e não uma única chave para toda a organização.
• Autenticação e governação de acessos: o Passwork é compatível com TOTP, WebAuthn/passkeys, desbloqueio biométrico, SSO via SAML e sincronização LDAP/AD, a par de tempos limite de sessão configuráveis e limiares de bloqueio após tentativas de início de sessão falhadas. O RBAC funciona através de funções e grupos personalizados ilimitados, com mapeamento de grupos do AD, para que as alterações no diretório se reflitam automaticamente no acesso aos cofres, sem esperar por um pedido de suporte. As políticas por tipo de cofre vinculam os administradores corporativos à própria categoria do cofre, e não a quem o criou, o que elimina a lacuna dos cofres pessoais não controlados que o acesso ao nível da função, por si só, não deteta.
• Registo de auditoria e verificação independente: todas as ações sobre cofres, pastas e palavras-passe, bem como as ações de administração, ficam registadas num registo de atividade exportável, filtrável por utilizador, data e tipo de ação, que pode alimentar diretamente um SIEM. O Passwork tem certificação ISO 27001 e é submetido anualmente a testes de intrusão externos através do HackerOne; o registo de auditorias e certificações do próprio Passwork é o mesmo tipo de documento que este modelo pede a todos os fornecedores, e não uma afirmação a aceitar sem provas.
• Alinhamento com a conformidade: a implementação autoalojada do Passwork mantém os dados na infraestrutura do cliente, o que simplifica os requisitos de residência dos dados ao abrigo do RGPD e das regras setoriais, e o RBAC vinculado a políticas, a par dos registos de auditoria exportáveis, corresponde às medidas de gestão de riscos do artigo 21.º, n.º 2, da NIS2 e aos controlos do Anexo A da ISO/IEC 27001 relativos à gestão de acessos e ao registo de eventos.
• Resiliência operacional: como o Passwork é executado na infraestrutura do próprio cliente, incluindo redes com isolamento físico, a disponibilidade e a estratégia de cópias de segurança ficam sob o controlo do cliente, e não dependentes do calendário de resolução de incidentes na nuvem de um fornecedor. O modo offline seguro permite aos utilizadores consultar registos especificamente marcados sem ligação ativa, só de leitura, com expiração automática da cache e sincronização completa do registo de atividade quando a ligação é restabelecida.

Conclusão

Nenhum dos seis pilares acima é exótico. São os documentos, as perguntas e os testes concretos que transformam a página de segurança de um fornecedor de uma simples afirmação em algo efetivamente verificado: onde estão as chaves, como se comportam realmente a MFA e as sessões, se a saída de colaboradores abrange as credenciais partilhadas e se um certificado ISO 27001 está efetivamente em vigor, e não apenas prometido.

Escolha o pilar em que a resposta do fornecedor atual é mais fraca e comece aí a próxima conversa de renovação.

Se estiver a avaliar um gestor de palavras-passe, ou a auditar o que já utiliza, experimente o Passwork gratuitamente e aplique este modelo a um cofre autoalojado e zero-knowledge, concebido para responder com provas a cada uma destas perguntas.

Perguntas frequentes

Gestão de palavras-passe empresarial: Guia completo para organizações B2B

Um guia completo para líderes B2B sobre gestão de palavras-passe empresarial. Analisa as opções de implementação (na nuvem, local e híbrida), a arquitetura de segurança e as boas práticas de implementação.

PassworkAlex Muntyan

O que é a cifragem zero-knowledge? Como funciona em 5 minutos

A cifragem zero-knowledge significa que o servidor nunca detém as chaves de decifragem, apenas texto cifrado. Explica como funciona a cadeia de chaves, contra que ameaças protege, o que não protege e como verificar a afirmação de um fornecedor.

PassworkPasswork Team

Requisitos de palavras-passe da NIS2: O que as empresas europeias devem fazer em 2026

As falhas nas credenciais são o principal ponto de reprovação nas auditorias NIS2 em 2026. Este guia aborda os requisitos de palavras-passe do artigo 21.º, o alinhamento com a NIST SP 800-63B, os passos de reforço do AD e as provas de auditoria que os reguladores pedem primeiro.

PassworkAlex Muntyan