Passbolt: gestor de passwords self-hosted para equipas de PME

Para gestão de segredos técnicos (chaves de API, certificados, tokens de infraestrutura), o OpenBao é a ferramenta adequada; para as credenciais do dia-a-dia da equipa — logins de SaaS, acessos a fornecedores, contas partilhadas — a maior parte das equipas ainda partilha por e-mail, folhas de cálculo ou mensagens, sem rasto de quem tem acesso a quê. O Passbolt ataca esse problema pela origem: é um gestor de passwords open-source desenhado desde o início para partilha em equipa, com encriptação OpenPGP end-to-end e um modelo de permissões granular por utilizadores, grupos e pastas. Pode alojar-se no servidor da própria PME, o que mantém as credenciais dentro da empresa. A comparação com os gestores cloud está no artigo sobre Bitwarden, 1Password e Keeper; este guia cobre o cenário self-hosted.

Neste artigo

1. O que é o Passbolt
2. Edições: CE vs Pro vs Cloud
3. Instalação em PME: Docker ou pacote Debian
4. Configuração inicial
5. Integração de browser
6. Segurança
7. Passbolt vs Bitwarden/Vaultwarden vs cloud
8. Erros Comuns
9. Checklist

O que é o Passbolt

O Passbolt é uma plataforma de gestão de credenciais orientada a equipas, distribuída sob licença AGPL (Affero General Public License) v3. Três características distingui-la de um gestor pessoal adaptado a equipas:

Partilha granular por pastas e grupos. As credenciais (passwords, TOTP, notas encriptadas, campos personalizados) organizam-se em pastas privadas e partilhadas. A partilha faz-se a utilizadores ou grupos, e cada grupo tem um gestor responsável por adicionar e remover membros. Um administrador pode delegar a gestão de um grupo num utilizador comum sem lhe dar as chaves da organização.

OpenPGP end-to-end. Cada utilizador gera um par de chaves OpenPGP (Pretty Good Privacy, o padrão aberto de encriptação) no momento da criação da conta; cada segredo é encriptado individualmente para cada utilizador que tem acesso. O servidor nunca vê segredos em texto claro nem as chaves privadas — a encriptação e a desencriptação acontecem no cliente (white paper de segurança.pdf)). Todos os segredos são assinados, o que permite verificar criptograficamente a identidade de quem os criou. A própria empresa prefere o termo “encriptação end-to-end” a “zero-knowledge”, por ser um conceito verificável e com limites claros.

Roles simples. O modelo tem duas roles de sistema — admin e user — mais roles de grupo e permissões por recurso ou pasta (Roles and Permissions). O admin gere a instância: utilizadores, grupos, notificações, MFA (Multi-Factor Authentication). O utilizador cria e partilha os seus recursos. Dois detalhes que surpreendem quem vem de outras ferramentas: só o administrador cria grupos; e, para adicionar ou remover membros, é preciso ser group manager desse grupo — um admin que não o seja fica limitado a um pedido ao gestor, porque só quem acede aos segredos do grupo os pode encriptar para o novo membro. O group manager não cria grupos nem ganha direitos extra sobre os recursos.

Edições: CE vs Pro vs Cloud

A página de preços oficial confirma três edições:

Desde a versão 5.13, a mudança de edição faz-se a partir da própria aplicação, na página de subscription — sem reinstalar (blog oficial). Todo o código, incluindo as features Pro, é open source; a chave de subscrição apenas as activa.

Para uma PME, o CE cobre o essencial: gestão e partilha de passwords, pastas privadas e partilhadas, gestão de utilizadores e grupos, autenticação por chave secreta (2FA), extensões de browser e CLI (Command Line Interface), API aberta, RBAC e expiração de passwords. A integração com Active Directory/LDAP, o SSO, o activity log, o SCIM e as políticas de password/passphrase ficam para o Pro — relevante quando a PME já tem um AD e quer provisionamento automático ou imposição de políticas.

Instalação em PME: Docker ou pacote Debian

Há duas vias principais: pacote nativo Debian/Ubuntu (mais acessível a quem não opera contentores) ou Docker. Nota que a própria documentação oficial de instalação CE em Docker (guia Docker) classifica o método como algo avançado — assume familiaridade com Docker e recomenda outra via a quem não a tem. Dentro do Docker, a via recomendada é docker compose, que segue estes passos:

1. Descarregar o ficheiro de exemplo docker-compose-ce.yaml e o respectivo ficheiro SHA512SUM (os comandos exactos constam do guia oficial; o compose sobe um contentor Passbolt e um MariaDB).
2. Verificar o checksum do ficheiro descarregado.
3. Confirmar um serviço NTP activo no anfitrião — o guia lista-o nos requisitos para evitar erros de autenticação GPG (a página FAQ sugere o chrony). Ajustar as variáveis de ambiente — nomeadamente o APP_FULL_BASE_URL com o endereço pelo qual a instância vai ser acedida — e fixar a tag da imagem na versão pretendada em vez de latest, como o guia recomenda para ambientes que não sejam de teste.
4. Arrancar os contentores com docker compose up -d.
5. Criar o primeiro utilizador admin dentro do contentor, com o comando register_user e a role admin (sintaxe completa no guia).

Os comandos não se reproduzem aqui porque variam entre versões; o guia oficial mantém-nos actualizados. O repositório docker oficial é o passbolt_docker no GitHub.

Para quem prefere pacote nativo em vez de contentores, a via Debian/Ubuntu passa por um script oficial de configuração do repositório Passbolt (com verificação SHA512 antes de executar) seguido da instalação do pacote passbolt-ce-server (guia Debian, guia Ubuntu 26.04). Durante a instalação, o assistente do pacote configura MariaDB, Nginx e o TLS (Transport Layer Security) — Let’s Encrypt automático ou certificados próprios. É possível pré-responder às perguntas do instalador para uma instalação não interactiva — a página de non-interactive mode documenta os parâmetros debconf. Há ainda guias para Ubuntu, Red Hat, Raspberry Pi e imagens cloud (AWS, DigitalOcean) na mesma secção de instalação.

Configuração inicial

Após a instalação, o fluxo oficial de configuração inicial:

1. Aceder ao servidor pelo browser — a primeira página mostra o healthcheck do ambiente; resolver os problemas apontados antes de continuar.
2. Criar a conta do primeiro administrador — o assistente gera o convite e o fluxo de setup.
3. Gerar ou importar a chave OpenPGP pessoal — a chave identifica o utilizador e encripta os seus segredos; a passphrase que a protege é a porta de entrada para todas as passwords, pelo que deve ser forte e, em caso de perda, não há recuperação no CE (account recovery por escrow é feature Pro).
4. Instalar a extensão de browser quando o assistente a pedir.
5. Convidar os restantes utilizadores — cada um completa o seu setup, gera a sua chave e fica visível no workspace de utilizadores.
6. Criar grupos e pastas partilhadas — por equipa ou função (ex.: “Redes”, “Faturação”), atribuir group managers e partilhar as pastas com os grupos.
7. Rever as definições da organização — idioma, notificações por e-mail, fornecedores de MFA activos.

As permissões por recurso e pasta seguem o modelo read/update/owner; a partilha de uma pasta aplica-se ao seu conteúdo. Na prática, o padrão que funciona em equipas pequenas: pastas partilhadas por grupo + gestor de grupo que faz o onboarding.

Integração de browser

A extensão não é um extra: é o cliente que encripta e desencripta. O servidor serve apenas dados encriptados; a lógica criptográfica vive na extensão, distribuída e assinada através das lojas oficiais, para que um comprometimento do servidor não comprometa o código de encriptação (porquê a extensão). Está disponível para Chrome, Firefox e Edge, com apps desktop para Windows e apps móveis para iOS e Android na página de downloads. O login na web app é feito pela extensão: a passphrase desbloqueia a chave privada guardada no armazenamento local do browser, e a partir daí o preenchimento automático, a geração de passwords e a partilha funcionam dentro do fluxo de navegação.

Segurança

O modelo de segurança assenta em três pilares que a página oficial de segurança documenta com auditorias publicadas:

OpenPGP end-to-end. As chaves privadas nunca saem do dispositivo do utilizador; o servidor funciona como repositório de dados encriptados e retransmissor de mensagens. A autenticação também usa o protocolo GnuPG — não há password de servidor que, comprometida, revele os segredos.

Self-hosted = soberania de dados. Alojando no servidor da PME (na sala de servidores, num VPS (Virtual Private Server) europeu ou num Raspberry Pi), as credenciais não passam por infraestrutura de terceiros. A organização controla a rede, a firewall e o ciclo de vida dos dados, o que simplifica o enquadramento no RGPD (Regulamento Geral sobre a Proteção de Dados) e elimina preocupações com o Cloud Act norte-americano.

Backups do servidor. Um backup completo inclui quatro peças: dump da base de dados, chaves GPG (GNU Privacy Guard) do servidor — pública e privada —, ficheiro de configuração passbolt.php e certificados TLS (guia oficial de backup). Em Docker, a documentação mostra como copiar as chaves para fora do contentor com docker compose cp (backup em Docker). As boas práticas constam das subpáginas do guia (instalação por fontes, por pacotes e em Docker): intervalos adequados ao uso, cópias off-site ou noutro ambiente além do live, backup encriptado e local seguro, e exercícios de teste ao restauro — as chaves do servidor são a peça sem a qual o restore é inútil.

Passbolt vs Bitwarden/Vaultwarden vs cloud

A comparação de gestores para PME cobre o mercado cloud em detalhe; aqui o ângulo é o self-hosted:

Escolha prática: equipas técnicas que querem partilha estruturada por grupos e mantêm os dados dentro da empresa → Passbolt CE. PME que quer self-hosted com o ecossistema Bitwarden → Vaultwarden (ou Bitwarden oficial, mais pesado). Sem capacidade de operar servidores → cloud, aceitando os dados fora da empresa.

Erros Comuns

Checklist

• [ ] Domínio e DNS prontos, com HTTPS válido (Let’s Encrypt ou certificado próprio)
• [ ] Método de instalação escolhido: pacote Debian/Ubuntu (mais simples) ou Docker compose (doc oficial: método algo avançado)
• [ ] Comandos de instalação copiados do guia oficial da versão corrente, com verificação SHA512
• [ ] APP_FULL_BASE_URL correcto antes do primeiro arranque
• [ ] SMTP configurado e testado (convites e notificações)
• [ ] Primeiro admin criado, passphrase da chave PGP forte e guardada em local seguro
• [ ] Backup configurado: dump da BD, chaves GPG do servidor, passbolt.php, certificados — off-site e testado
• [ ] Grupos e pastas partilhadas definidos antes de convidar a equipa
• [ ] MFA activado na organização (a política que exige MFA a todos os utilizadores é feature Pro)
• [ ] Extensões de browser distribuídas a partir das lojas oficiais
• [ ] Plano de actualizações agendado (imagem Docker ou repositório apt)
• [ ] Política de saída definida: remover utilizador = revogar acesso; segredos reassinados para quem fica