Gestores de Passwords para PME em 2026: Bitwarden, 1Password ou Keeper — Qual Escolher?

✎ Duarte Spínola  | 

A gestão de credenciais continua a ser um dos vectores de ataque mais explorados em pequenas e médias empresas. Segundo o Relatório de Investigação de Violações de Dados da Verizon de 2024, mais de 80% das violações confirmadas envolvem credenciais roubadas, reutilizadas ou fracas. Para uma PME portuguesa com 25 utilizadores, a escolha de um gestor de passwords não é uma questão de conforto — é uma camada de controlo de acesso que separa um incidente contido de uma violação notificável ao CNPD ao abrigo do RGPD.

Este artigo compara as três soluções mais relevantes para PME em 2026 — Bitwarden, 1Password e Keeper — em nove dimensões técnicas e operacionais, incluindo implementação self-hosted com Docker, integração com Entra ID e Google Workspace, e custos reais para 25 utilizadores.

Neste artigo

  1. Cenários de Uso em PME
  2. Comparação Técnica: Funcionalidades Essenciais
  3. Bitwarden: Cloud vs Self-Hosted
  4. 1Password Teams e Business
  5. Keeper Business
  6. Implementação Self-Hosted Bitwarden com Docker
  7. Integração com Entra ID e Google Workspace
  8. Análise de Custos: 25 Utilizadores
  9. Segurança, Recuperação e Migração
  10. Checklist Pré-Produção
  11. Artigos Relacionados

Cenários de Uso em PME

Uma PME portuguesa típica enfrenta três cenários de gestão de credenciais que determinam qual a solução mais adequada:

Cenário 1 — Escritório único, 10-50 utilizadores, sem requisitos de compliance externo. A prioridade é facilidade de implementação e custo reduzido. As equipas partilham credenciais de redes sociais, ferramentas SaaS e acessos a fornecedores. Bitwarden Cloud (plano Teams) ou 1Password Teams resolvem este caso com configuração mínima.

Cenário 2 — Multi-site ou equipas externas, requisitos de auditoria. A empresa precisa de registos de auditoria exportáveis, políticas de password granulares e integração com o fornecedor de identidade corporativo (Entra ID ou Google Workspace). 1Password Business e Keeper Business oferecem SSO/SAML nativo, SCIM e logs de auditoria detalhados. Bitwarden Business também suporta SSO, mas o SCIM requer a edição Business com o add-on Enterprise.

Cenário 3 — Requisitos de soberania de dados ou compliance sectorial. A empresa opera em saúde, finanças ou defesa e tem de manter todos os dados dentro da UE ou on-premise. Bitwarden self-hosted é a única das três que permite alojamento totalmente sob controlo, incluindo em infraestrutura portuguesa (AWS Lisboa, Azure North Europe, ou servidor físico).

Comparação Técnica: Funcionalidades Essenciais

A tabela seguinte resume as funcionalidades críticas para PME nas três plataformas, baseada na documentação oficial de cada fornecedor (Bitwarden Business, 1Password Business, Keeper Enterprise Guide):

Funcionalidade Bitwarden (Business) 1Password (Business) Keeper (Business)
SSO/SAML 2.0 Sim (SAML 2.0, OIDC) Sim (SAML 2.0, OIDC) Sim (SAML 2.0, OIDC)
SCIM provisioning Sim (Enterprise add-on) Sim (incluído no Business) Sim (incluído no Business)
Vault sharing por equipa Sim (Collections + Groups) Sim (Vaults + Groups) Sim (Folders + Teams + Roles)
Audit logs Sim (exportáveis em CSV/JSON) Sim (Item History + Audit Log) Sim (compliance reporting, SOC2)
Compliance SOC 2 Type II Sim Sim Sim
Compliance ISO 27001 Sim Sim Sim
Zero-knowledge Sim (cliente encripta) Sim (Secret Key + Master Password) Sim ( KeeperSecurity DNA)
Emergency access Sim (granted access) Sim (Recovery Kit + Master Password) Sim (Emergency Access feature)
Recuperação de conta Sim (admin reset, org key) Sim (RecoveryKit + team recovery) Sim (Admin-initiated recovery)
Políticas de password Sim (complexity, rotation) Sim (Master Password Policy) Sim (enforcement, rotation, complexity)
Passkeys Sim (armazenamento nativo) Sim (armazenamento nativo) Sim (armazenamento nativo)
2FA integrado Sim (Duo, FIDO2, YubiKey) Sim (Duo, FIDO2, YubiKey) Sim (Duo, FIDO2, YubiKey)
API pública Sim Sim Sim ( Keeper Commander CLI)
Self-hosted Sim (Docker) Não Não

Notas sobre compliance

As três soluções mantêm certificações SOC 2 Type II e ISO 27001. Keeper destaca-se pela certificação FedRAMP, HIPAA e GDPR-ready, sendo a opção mais robusta para sectores regulamentados. 1Password publica o seu relatório SOC 2 através de 1password.com/security. Bitwarden fornece documentação de compliance em bitwarden.com/compliance.

Bitwarden: Cloud vs Self-Hosted

Bitwarden é o único dos três fornecedores que oferece uma opção self-hosted sem custo de licença adicional, através do deployment self-hosted oficial e do projecto comunitário Vaultwarden (implementação leve em Rust, anteriormente conhecido como bitwarden_rs).

Bitwarden Cloud (Teams ou Business)

A versão cloud é gerida integralmente pela Bitwarden Inc., com datacenters nos EUA. A implementação demora menos de 30 minutos — criar organização, convidar utilizadores, configurar colecções e grupos. O plano Teams destina-se a 2-50 utilizadores; o plano Business é necessário para SSO, SCIM, políticas avançadas e directory connector.

Vantagens: configuração trivial, atualizações automáticas, sem manutenção de infraestrutura, backups geridos.

Desvantagens: dados em datacenters norte-americanos, dependência do fornecedor para disponibilidade, limitações de customização.

Bitwarden Self-Hosted (oficial)

A versão self-hosted oficial da Bitwarden corre o mesmo stack que a cloud — MSSQL, Identity, API, Notifications, entre outros contentores. Requer Docker e Docker Compose, com um mínimo de 4 GB de RAM e 2 vCPU. A licença é gratuita para utilizadores ilimitados, mas as funcionalidades Business (SSO, SCIM, políticas) requerem uma licença Business paga para cada utilizador, mesmo em self-hosted.

Vantagens: soberania total de dados, latência reduzida, sem dependência do fornecedor para disponibilidade.

Desvantagens: manutenção de infraestrutura, responsabilidade de backups, actualizações manuais.

Vaultwarden (alternativa leve)

Vaultwarden é uma implementação independente, compatível com as APIs Bitwarden, que corre num único contentor Docker com SQLite ou PostgreSQL. É adequado para PME até ~50 utilizadores. Não é oficialmente suportado pela Bitwarden Inc., mas é amplamente usado e mantido ativamente no GitHub.

Vantagens: footprint mínimo (~50 MB RAM), configuração em 5 minutos, compatível com clientes oficiais Bitwarden.

Desvantagens: sem suporte oficial, algumas funcionalidades Business não estão disponíveis (SCIM nativo, directory connector completo).

1Password Teams e Business

1Password oferece dois planos para PME: Teams e Business.

1Password Teams

Destinado a 2-50 utilizadores, o plano Teams inclui vaults partilhados, gestão de permissões por vault, 2 GB de armazenamento por utilizador para documentos, e o 1Password Watchtower (monitorização de passwords comprometidas em violações conhecidas). Não inclui SSO/SAML nem políticas de master password.

1Password Business

O plano Business adiciona SSO/SAML 2.0 (com Entra ID, Google Workspace, Okta, entre outros), SCIM para provisionamento automático, políticas de segurança (master password complexity, 2FA obrigatório, bloqueio de acesso fora do horário), e relatórios de auditoria. O modelo de segurança do 1Password é distintivo pela Secret Key — uma chave de 128 bits gerada por dispositivo que combina com a master password para derivar a chave de encriptação. Isto significa que mesmo que a master password seja comprometida, o atacante necessita também da Secret Key armazenada no dispositivo.

Vaults e partilha: 1Password organiza credenciais em vaults. Cada vault pode ser partilhado com equipas específicas. Um utilizador pode pertencer a múltiplos vaults, e permissões são granulares (ver, editar, importar, exportar, administrar).

Audit logs: o plano Business mantém um registo de auditoria com eventos de início de sessão, alterações de vault, uso de itens e exportações. Os logs são acessíveis via painel de administração e exportáveis em CSV.

Keeper Business

Keeper Business é o plano intermédio da Keeper Security, posicionado entre o plano Personal/Family e o plano Enterprise. A documentação completa está em docs.keepersecurity.com.

Arquitectura de segurança

Keeper usa uma arquititectura zero-knowledge chamada KeeperSecurity DNA: a encriptação ocorre no cliente antes de qualquer dado ser enviado para o servidor. Cada registo é encriptado com uma chave AES-256 única, derivada de uma chave de vault AES-256, que por sua vez é protegida pela master password do utilizador (com PBKDF2 ou Argon2id). Os servidores Keeper nunca recebem dados em texto simples.

Funcionalidades Business

  • SSO/SAML 2.0 com Entra ID, Google Workspace, Okta, PingIdentity
  • SCIM 2.0 para provisionamento automático de utilizadores
  • Keeper Bridge para integração com Active Directory on-premise
  • Compliance reporting com dashboards de auditoria e exportação para SIEM
  • KeeperFill para preenchimento automático em browsers e aplica móveis
  • BreachWatch (add-on) — monitorização contínua de credenciais em bases de dados de violações
  • Records de auditoria com eventos de acesso, modificação, partilha e exportação

Keeper Commander CLI

Keeper inclui uma ferramenta CLI (Keeper Commander) que permite gestão via terminal, integração com pipelines CI/CD e automação de rotação de passwords:

# Instalar Keeper Commander
pip3 install keeper-security

# Login interativo
keeper-shell login

# Listar todos os records de um vault
keeper-shell ls

# Roterizar uma password específica por ID
keeper-shell rotate -f strong <record_uid>

Esta capacidade de automação via CLI é uma vantagem distintiva para equipas DevOps que necessitam de rotação programática de segredos em infraestruturas.

Implementação Self-Hosted Bitwarden com Docker

A implementação self-hosted oficial da Bitwarden usa Docker Compose com múltiplos contentores. O processo abaixo segue a documentação oficial de instalação self-hosted.

Pré-requisitos

  • Servidor Linux (Ubuntu 22.04+ ou Debian 12+ recomendado)
  • Docker 24+ e Docker Compose v2
  • 4 GB RAM mínimo (8 GB recomendado)
  • 2 vCPU mínimo
  • 50 GB disco (SSD)
  • Domínio com registo DNS apontando para o servidor
  • Certificado TLS (Let’s Encrypt ou comercial)

Passo 1 — Instalar Docker

# Instalar Docker em Ubuntu/Debian
curl -fsSL https://get.docker.com | sh

# Verificar instalação
docker –version
docker compose version

# Adicionar utilizador actual ao grupo docker
sudo usermod -aG docker $USER

Passo 2 — Obter a installation key

Registar uma instalação em bitwarden.com/host para obter a installation key e o installation id necessários para o ficheiro de configuração.

Passo 3 — Descarregar e executar o instalador

# Criar directoria de instalação
sudo mkdir -p /opt/bitwarden
sudo chown $USER:$USER /opt/bitwarden
cd /opt/bitwarden

# Descarregar o script de instalação
curl -Lso bitwarden.sh \
https://go.bitwarden.com/on-premise-install.sh
chmod +x bitwarden.sh

# Executar instalação interactiva
./bitwarden.sh install

O instalador solicita o domínio, installation id, installation key e configura o ficheiro ./docker-compose.yml e ./global.env automaticamente.

Passo 4 — Configurar SSL

O instalador gera certificados Let’s Encrypt automaticamente se o domínio estiver correctamente apontado. Alternativamente, editar ./global.env:

# Em ./global.env
SSL_CERT_DIR=/opt/bitwarden/ssl
SSL_DIR=/opt/bitwarden/ssl

Passo 5 — Iniciar os serviços

# Iniciar todos os contentores
./bitwarden.sh start

# Verificar estado dos contentores
docker compose ps

# Ver logs em tempo real
docker compose logs -f

Os contentores incluem: bitwarden-nginx (reverse proxy), bitwarden-api, bitwarden-identity, bitwarden-admin, bitwarden-icons, bitwarden-notifications, bitwarden-events, bitwarden-mssql (base de dados).

Passo 6 — Configurar organização e licença

Após o arranque, aceder a https://dominio.pt e criar a conta de administrador. Depois, criar uma organização Business e aplicar a licença obtida no portal Bitwarden. Configurar colecções (equivalentes a vaults) e grupos conforme a estrutura de equipas.

Implementação Vaultwarden (alternativa leve)

Para PME que pretendem uma implementação mais simples com menos recursos:

# Criar ficheiro docker-compose.yml para Vaultwarden
cat << ‘EOF’ > docker-compose.yml
version: ‘3’
services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
environment:
– DOMAIN=https://vault.dominio.pt
– SIGNUPS_ALLOWED=false
– ADMIN_TOKEN=token_admin_seguro_aqui
– WEBSOCKET_ENABLED=true
volumes:
– ./vw-data:/data
ports:
– “80:80”
– “443:443”
EOF

# Iniciar o contentor
docker compose up -d

# Verificar estado
docker compose ps

Aceder a https://vault.dominio.pt/admin com o admin token para configurar SMTP, SSO e políticas. Configurar um reverse proxy (Caddy ou Traefik) para TLS automático.

Backups

O backup é da responsabilidade do administrador em self-hosted. Recomenda-se a estratégia 3-2-1:

# Backup da base de dados MSSQL (implementação oficial)
docker exec bitwarden-mssql \
/opt/mssql-tools/bin/sqlcmd -S localhost -U SA \
-P $SA_PASSWORD -Q “BACKUP DATABASE vault TO DISK = ‘/backup/vault.bak'”

# Sincronizar backup para armazenamento remoto
rclone sync /opt/bitwarden/backups remote:bitwarden-backups/

# Para Vaultwarden, basta copiar a directoria de dados
tar -czf vw-backup-$(date +%F).tar.gz vw-data/
rclone copy vw-backup-$(date +%F).tar.gz remote:vw-backups/

Automatizar com cron:

# /etc/cron.d/bitwarden-backup — backup diário às 02:00
0 2 * * * root /opt/bitwarden/backup.sh >> /var/log/bitwarden-backup.log 2>&1

Integração com Entra ID e Google Workspace

A integração com o fornecedor de identidade corporativo é o passo que transforma um gestor de passwords numa camada de identidade coerente. As três plataformas suportam SSO via SAML 2.0 e provisionamento via SCIM 2.0.

Integração com Microsoft Entra ID

As três soluções têm guias oficiais para integração com Entra ID (anteriormente Azure AD):

Bitwarden: a documentação de SSO com Entra ID descreve a configuração SAML 2.0. No portal Entra ID, criar uma Enterprise Application non-gallery, configurar os URLs de Assertion Consumer Service (ACS) do Bitwarden e o Identifier (Entity ID). No painel de administração Bitwarden, inserir o Entity ID, o URL de login e o certificado X.509 exportado do Entra ID.

Para provisionamento SCIM, o SCIM connector da Bitwarden é um contentor Docker separado que actua como intermediário entre o Entra ID e a instância Bitwarden:

# Descarregar o SCIM connector
git clone https://github.com/bitwarden/scim-pack.git
cd scim-pack

# Configurar variáveis de ambiente
cp .env.example .env
# Editar .env com:
# – BW_API_KEY=chave_da_organização
# – BW_SCIM_API_KEY=chave_scim_da_organização
# – BW_DOMAIN=https://vault.dominio.pt

# Iniciar o SCIM connector
docker compose up -d

No Entra ID, configurar o provisionamento de utilizadores apontando para o URL do SCIM connector (https://scim.dominio.pt/scim/v2) com a chave SCIM como bearer token.

1Password: a integração com Entra ID está documentada em support.1password.com/sso-azure-ad. No portal Entra ID, criar uma aplicação a partir da galeria (1Password está listado). O 1Password Business suporta JIT (Just-In-Time) provisioning, pelo que o SCIM é opcional — os utilizadores são criados automaticamente na primeira autenticação SSO. Para provisionamento anticipado, configurar SCIM via 1Password SCIM Bridge, que corre como um contentor Docker ou função AWS Lambda.

# Iniciar o 1Password SCIM Bridge com Docker
docker run -d \
–name op-scim \
-p 443:8443 \
-e OP_SCIM_MASTER_PASSWORD=master_segura \
-v ./op-scim-data:/data \
1password/scim:latest

Keeper: a integração com Entra ID segue a documentação oficial de SSO com Entra ID. No painel de administração Keeper (Keeper Business Console), navegar para SSO Configuration e seleccionar Microsoft Entra ID. Importar o ficheiro de metadados Federation Metadata do Entra ID. Para SCIM, o Keeper suporta provisionamento directo via Entra ID sem connector adicional — basta configurar o URL SCIM e o bearer token no portal Entra ID.

Integração com Google Workspace

Bitwarden: a configuração de SSO com Google Workspace está descrita em bitwarden.com/help/google-sso. No Google Workspace Admin Console, adicionar uma aplicação SAML personalizada com os URLs ACS e Entity ID do Bitwarden. Exportar o certificado e o URL de início de sessão para o painel Bitwarden.

1Password: a documentação está em support.1password.com/sso-google. O processo é similar ao Entra ID — criar aplicação SAML no Google Workspace e importar metadados no 1Password.

Keeper: descrito em docs.keepersecurity.com — SSO with Google. Keeper fornece um assistente de configuração que gera os metadados necessários para importar directamente no Google Workspace.

Considerações sobre provisionamento automático

O provisionamento via SCIM garante que quando um utilizador é desactivado no Entra ID ou Google Workspace, o acesso ao gestor de passwords é também desactivado. Sem SCIM, a desactivação manual no gestor de passwords é um passo que pode ser omitido, criando uma janela de acesso indevido. Para PME com rotatividade de pessoal, o SCIM reduz significativamente o risco de contas órfãs.

Análise de Custos: 25 Utilizadores

Os preços abaixo refletem as tabelas oficiais publicadas em Julho de 2025 nos respectivos sites. Valores em USD por utilizador/mês, com conversão indicativa para EUR (taxa 1 USD ≈ 0,92 EUR).

Bitwarden

Plano Preço (USD/util./mês) 25 utilizadores/mês Anual (USD)
Teams 3,00 75,00 900,00
Business 4,00 100,00 1 200,00
Enterprise (add-on) +3,00/util. +75,00 +900,00

Fonte: bitwarden.com/pricing/business

O plano Teams é suficiente para a maioria das PME até 50 utilizadores. O plano Business adiciona SSO, SCIM, políticas avançadas e directory connector. O add-on Enterprise é necessário para funcionalidades como SCIM automático via connector dedicado e autenticação por chave.

Self-hosted não elimina o custo por utilizador para funcionalidades Business — a licença é por utilizador independentemente do modelo de alojamento. A poupança está na eliminação do custo de infraestrutura cloud gerida, não na licença.

1Password

Plano Preço (USD/util./mês) 25 utilizadores/mês Anual (USD)
Teams Starter 19,95 (fixo até 10 util.) 19,95 (até 10) 239,40
Teams 7,99 199,75 2 397,00
Business 7,99 + 1,00 (SSO pack) 224,75 2 697,00

Fonte: 1password.com/pricing

O Teams Starter é o plano de entrada (máximo 10 utilizadores, custo fixo). O plano Teams suporta utilizadores ilimitados. O plano Business adiciona SSO, SCIM, políticas e relatórios de auditoria. O SSO Pro Pack (add-on de 1,00 USD/util./mês) é necessário para SSO/SAML no plano Business a partir de 2025.

Keeper

Plano Preço (USD/util./mês) 25 utilizadores/mês Anual (USD)
Business 3,75 93,75 1 125,00
Business + BreachWatch +1,25/util. +31,25 +375,00
Enterprise 5,00+ (orçamento) ~125,00 ~1 500,00

Fonte: keepersecurity.com/business

O plano Business inclui SSO/SAML, SCIM, audit logs e compliance reporting. BreachWatch (monitorização de violações) é um add-on. O plano Enterprise adiciona gestão de roles avançada, MSP e integrações SIEM.

Comparação de TCO anual para 25 utilizadores (USD)

Solução Plano recomendado TCO anual Notas
Bitwarden Cloud Business Business 1 200 SSO, SCIM via connector, self-hosted opcional
Bitwarden Self-Hosted Business Business + infra. 1 200 + ~600 Infra. estimada: VPS 2 vCPU/8 GB (~50 USD/mês)
1Password Business Business + SSO Pack 2 697 SSO, SCIM incluídos, Secret Key
Keeper Business Business 1 125 SSO, SCIM, audit incluídos
Keeper Business + BreachWatch Business + BreachWatch 1 500 Monitorização de violações incluída

Bitwarden e Keeper são significativamente mais económicos que 1Password. A diferença de ~1 500 USD anuais entre Bitwarden Business e 1Password Business pode ser material para uma PME. No entanto, o modelo de Secret Key do 1Password oferece uma camada de segurança adicional que algumas organizações valorizam acima do custo.

Segurança, Recuperação e Migração

Segurança Zero-Knowledge

As três soluções implementam arquitectura zero-knowledge, mas com diferenças importantes na implementação:

Bitwarden: a encriptação ocorre no cliente com AES-256-CBC, derivando a chave da master password via PBKDF2 (default 600 000 iterações) ou Argon2id (recomendado desde 2024). O servidor nunca recebe a master password nem as chaves de encriptação. A organização tem uma chave de organização (org key) que permite partilha de colecções, encriptada com a chave pública de cada utilizador.

1Password: além da master password, o 1Password exige uma Secret Key de 34 caracteres gerada por dispositivo. A combinação de master password + Secret Key deriva a chave de encriptação via HKDF-SHA512. Mesmo que a master password seja fraca ou comprometida, a Secret Key (armazenada localmente) torna os ataques offline impraticáveis. Esta é a diferença arquitectural mais significativa face aos concorrentes.

Keeper: usa encriptação AES-256-GCM no cliente, com chaves derivadas via PBKDF2 (default 100 000 iterações, configurável até 10 milhões) ou Argon2id. Cada registo tem uma chave única, encriptada com a chave de vault, que é encriptada com a chave derivada da master password. O Keeper suporta ainda KeeperFill para preenchimento seguro e integração com browsers.

Recuperação de Conta e Emergency Access

Bitwarden: administradores de organização podem executar reset de master password para utilizadores (requer que a funcionalidade esteja activada antes da perda). O Emergency Access permite designar um contacto que pode solicitar acesso ao vault — após um período de espera configurável (1-30 dias), se não for negado, o contacto recebe acesso.

1Password: a recuperação depende do Recovery Kit gerado na criação da conta — um documento PDF com a Secret Key. Sem a Secret Key, a recuperação é impossível mesmo para administradores. Em plano Business, administradores podem iniciar a recuperação de equipa, que gera uma nova Secret Key. O Emergency Kit deve ser guardado offline (cópia impressa ou USB).

Keeper: administradores Business podem iniciar recuperação de conta que permite ao utilizador redefinir a master password. O Emergency Access permite designar contactos de emergência com períodos de espera configuráveis. Keeper suporta ainda Master Password Recovery via código de recuperação gerado na criação da conta.

Migração entre Gestores

A migração entre gestores de passwords é um processo que deve ser planeado e testado. As três plataformas suportam importação e exportação em formatos standard (CSV, JSON).

Exportação de Bitwarden:

# Exportar vault pessoal via CLI
bw export –output ./bitwarden-export.csv –format csv

# Exportar organização (requer auth como administrador)
bw export –organizationid <org_id> \
–output ./bitwarden-org-export.json –format json

Exportação de 1Password:

# Export via 1Password CLI (op)
op signin
op vault export –format csv –output ./1password-export.csv “Nome do Vault”

# Alternativa: exportar via aplicação desktop
# File > Export All Items > CSV

Exportação de Keeper:

# Export via Keeper Commander
keeper-shell export –format json –output ./keeper-export.json

# Alternativa: export via interface web
# Settings > Export > JSON

Importação em Bitwarden:

# Importar ficheiro CSV/JSON via CLI
bw import –format 1password –path ./1password-export.csv

# Formatos suportados: bitwarden, 1password, keeper, lastpass, chrome, firefox, csv, json
bw import –format keeper –path ./keeper-export.json

Considerações de migração:

  • Ficheiros anexos (documentos, imagens) nem sempre são incluídos nas exportações standard — verificar manualmente
  • Campos personalizados e notas seguras podem perder metadados na exportação CSV — preferir JSON quando disponível
  • Após migração, as passwords antigas devem ser rotacionadas como boa prática, especialmente se a migração resultar de um incidente de segurança
  • Testar a migração com 3-5 utilizadores piloto antes de executar para a organização completa
  • O processo de migração deve ser documentado e executado numa janela de manutenção planeada

Políticas de Password para PME

As três plataformas permitem definir políticas de master password e passwords de vault:

Política Bitwarden 1Password Keeper
Complexidade mínima Sim (comprimento, maiúsculas, números, símbolos) Sim (Master Password Policy) Sim (comprimento, complexidade)
Rotação obrigatória Sim (intervalo configurável) Não (desaconselhado pelo NIST) Sim (intervalo configurável)
Verificação contra violações Sim (Data Breach Report) Sim (Watchtower) Sim (BreachWatch, add-on)
Reutilização bloqueada Sim (password history) Sim (Watchtower) Sim (password strength audit)
Master password reset Sim (admin-initiated) Sim (team recovery) Sim (admin recovery)
2FA obrigatório Sim (Business) Sim (Business) Sim (Business)
Bloqueio automático Sim (configurável) Sim (configurável) Sim (configurável)

A rotação obrigatória de passwords, embora suportada, é desaconselhada pelo NIST SP 800-63B (secção 5.1.1.2), que recomenda a rotação apenas mediante suspeita de compromisso. As políticas devem priorizar comprimento mínimo (16+ caracteres), verificação contra bases de violações e bloqueio de reutilização.

Checklist Pré-Produção

Antes de colocar um gestor de passwords em produção para uma PME, verificar todos os pontos seguintes:

  • [ ] Domino configurado com registo DNS A/AAAA apontando para o servidor (self-hosted)
  • [ ] Certificado TLS válido instalado (Let’s Encrypt ou comercial) — sem TLS, o gestor de passwords não deve entrar em produção
  • [ ] Backup automático configurado e testado (pelo menos uma restauração de teste executada com sucesso)
  • [ ] Política de master password definida (mínimo 16 caracteres, complexidade exigida)
  • [ ] 2FA obrigatório activado para todos os utilizadores
  • [ ] SSO/SAML configurado e testado com Entra ID ou Google Workspace
  • [ ] SCIM provisioning activado (se aplicável) — desactivação de utilizadores testada end-to-end
  • [ ] Colecções/vaults e grupos estruturados conforme organograma da empresa
  • [ ] Emergency Access configurado para pelo menos o administrador principal
  • [ ] Audit logs acessíveis e exportação testada (CSV/JSON para SIEM ou arquivo)
  • [ ] Política de bloqueio automático configurada (recomendado: 15 minutos em desktop, imediato em mobile)
  • [ ] Plano de recuperação de conta documentado e testado com utilizador piloto
  • [ ] Aplicações cliente (browser extension, desktop, mobile) instaladas e testadas em pelo menos um dispositivo por plataforma
  • [ ] Formulário de onboarding criado para novos utilizadores (criação de conta, instalação de extensão, primeiro login SSO)
  • [ ] Comunicação interna enviada com data de activação, contactos de suporte e instruções de acesso
  • [ ] Monitorização de disponibilidade configurada (uptime check no UptimeRobot, Pingdom ou equivalente)

Artigos Relacionados

Fontes

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário