A soberania de dados é a capacidade de determinar, a nível físico, jurídico e criptográfico, quem pode aceder a determinados dados e sob que jurisdição. Uma empresa pode estar totalmente em conformidade com o RGPD no papel e, ainda assim, não ter qualquer controlo real sobre o local onde residem as suas palavras-passe. No caso das credenciais empresariais, essa lacuna entre «em conformidade» e «sob controlo» é onde começam as violações de dados, as intimações e as auditorias reprovadas.
O Regulamento Geral sobre a Proteção de Dados (RGPD) estabelece a base de referência que a maioria das organizações utiliza para avaliar as suas práticas de dados: regula a forma como os dados pessoais são recolhidos, armazenados e transferidos e, nos termos do artigo 3.º, o seu âmbito territorial abrange qualquer empresa que trate dados de residentes na UE, independentemente do local da sua sede.
As palavras-passe e os segredos não são dados comuns, razão pela qual a gestão de palavras-passe necessita de um modelo de soberania próprio, distinto do armazenamento geral de ficheiros. Dão acesso a tudo o resto, circulam constantemente entre colaboradores e raramente passam pelas ferramentas de prevenção de perda de dados (DLP) ou de classificação que vigiam contratos e registos de clientes. Uma credencial armazenada no servidor errado, no país errado, sob chaves de cifragem de terceiros, é um risco que a maioria das listas de verificação de conformidade não deteta.
Este artigo analisa o que a soberania significa realmente em três níveis: localização física, cifragem e governação de acessos. Compara os modelos on-premise, com isolamento físico (air gap) e cloud na UE, e mostra onde um gestor de palavras-passe autoalojado e zero-knowledge, como o Passwork, se enquadra nessa decisão.
Pontos principais
- A soberania exige três controlos: localização, cifragem e governação de acessos. Uma falha num deles compromete os restantes.
- As credenciais precisam do seu próprio modelo de segurança. São de elevado valor, circulam constantemente e escapam às ferramentas de DLP habituais.
- A conformidade com o RGPD não aborda quem detém as chaves de cifragem. Um fornecedor em conformidade pode, ainda assim, aceder aos dados dos clientes através de subcontratantes ulteriores ou de pedidos legais.
- A arquitetura zero-knowledge determina se a cifragem na cloud protege efetivamente. Se o fornecedor detém as chaves, a localização do servidor importa menos.
- A implementação on-premise e com isolamento físico maximiza o controlo, mas aumenta a carga operacional. A aplicação de patches, as cópias de segurança e a disponibilidade passam a ser responsabilidade da equipa de TI.
- O alojamento cloud na UE só colmata a lacuna de soberania com cifragem do lado do cliente. A residência dos dados cobre a jurisdição; a cifragem determina quem detém as chaves.
- As afirmações de soberania dos fornecedores requerem verificação por terceiros. A ISO/IEC 27001, a preparação para a NIS2 e os testes de intrusão públicos dão às equipas de aquisições um ponto de partida.
- A escolha da implementação depende de quatro fatores: necessidade de air gap, requisitos de alojamento na UE, dimensão da equipa e política de autoalojamento. Fluxos de trabalho distintos podem recorrer a modelos distintos.
O que significa realmente a soberania de dados para as credenciais
A soberania de dados é a combinação de três controlos distintos: onde os dados se encontram fisicamente, quem detém as chaves de cifragem e quem governa o acesso aos mesmos. A perda de qualquer um dos três compromete a soberania, mesmo que os outros dois sejam sólidos. A maioria dos fornecedores anuncia apenas o primeiro.
- A localização física indica onde estão os servidores. Um gestor de palavras-passe alojado em Frankfurt continua abrangido pelo âmbito territorial do RGPD, mas o mesmo sucede com um alojado na Virgínia, se tratar dados de residentes na UE. A localização importa para a jurisdição, não automaticamente para a exposição jurídica.
- O controlo da cifragem indica quem pode decifrar os dados. Se o fornecedor detém as chaves, um pedido governamental, uma pessoa com acesso interno ou uma violação na infraestrutura do fornecedor podem expor as credenciais, independentemente da localização do servidor.
- A governação de acessos indica quem, dentro da organização, pode ver o quê. O controlo de acesso baseado em funções (RBAC) e os registos de auditoria determinam se o acesso de um colaborador que sai é revogado em minutos ou descoberto seis meses mais tarde.
A verdadeira soberania de dados exige os três elementos. A omissão de qualquer componente reduz a arquitetura a uma lista de verificação de conformidade meramente formal.
Porque as credenciais são uma classe de dados distinta
As credenciais merecem um tratamento separado por serem de elevado valor, de elevada circulação e em grande parte invisíveis para as ferramentas habituais de governação de dados. Um registo de cliente divulgado expõe um único conjunto de dados. Uma palavra-passe de administrador divulgada expõe todos os sistemas a que esse administrador tem acesso e continua a funcionar até que alguém a substitua.
Verizon, no 2026 Data Breach Investigations Report, concluiu que as credenciais roubadas representaram 13 % dos vetores de acesso inicial, mas que esse valor triplicou (39 %) ao longo de toda a progressão da violação de dados. As palavras-passe também circulam constantemente: são partilhadas durante a integração de colaboradores, copiadas para tickets, coladas em conversas de chat e reencaminhadas quando um projeto muda de mãos. As ferramentas de DLP concebidas para detetar a exfiltração de documentos raramente assinalam uma palavra-passe colocada numa mensagem do Slack.
Esta combinação de elevado impacto e baixa visibilidade é a razão pela qual o armazenamento de credenciais necessita do seu próprio modelo de soberania, em vez de herdar a política que abrange o armazenamento geral de ficheiros.
Aprofundar os números
Para uma análise completa do Verizon 2026 DBIR (incluindo vetores de violação, tendências de ransomware e risco de terceiros), consulte a nossa análise do relatório.
Onde o armazenamento cloud padrão introduz atrito jurídico
Os gestores de palavras-passe cloud convencionais introduzem exposição jurídica através de cadeias de subcontratantes ulteriores, transferências transfronteiriças de dados e acesso do pessoal do fornecedor, mesmo quando este cumpre integralmente o RGPD. A cifragem em repouso não elimina estes riscos se quem detém as chaves de decifragem for o fornecedor e não o cliente.
Três pontos de atrito concretos surgem repetidamente nas análises de aquisição:
- Subcontratantes ulteriores. A maioria dos fornecedores cloud recorre a prestadores subcontratados de infraestrutura, monitorização ou suporte. Cada subcontratante ulterior é uma entidade distinta, com a sua própria superfície de acesso. No RGPD, o artigo 28.º, n.º 2 exige que o subcontratante não contrate outro subcontratante (subcontratante ulterior) sem autorização prévia, específica ou geral, por escrito, do responsável pelo tratamento.
- Transferências para países terceiros. O capítulo V do RGPD rege as transferências de dados pessoais para fora da UE/EEE. O artigo 44.º estabelece o princípio geral de que nenhuma transferência pode comprometer o nível de proteção garantido pelo regulamento, e o artigo 46.º exige garantias adequadas, como as cláusulas contratuais-tipo, quando não se aplica nenhuma decisão de adequação. Os cofres de credenciais alojados num país terceiro, ou replicados para um país terceiro para fins de cópia de segurança, enquadram-se inteiramente neste capítulo.
- Acesso do pessoal do fornecedor e pedidos legais. Se o fornecedor puder decifrar tecnicamente os dados dos clientes, esses dados ficam sujeitos a processos judiciais na jurisdição do fornecedor. Uma intimação, um mandado ou uma ordem de divulgação estrangeira podem obrigar ao acesso, independentemente do local onde a empresa está registada.
A NIS2 acrescenta uma quarta perspetiva: o artigo 21.º, n.º 2, alínea d) exige que as entidades essenciais e importantes avaliem a segurança da cadeia de abastecimento, incluindo os fornecedores e as ferramentas que utilizam para gerir credenciais de acesso. Um cofre de palavras-passe alojado junto de um subcontratante ulterior externo que não foi previamente avaliado enquadra-se inteiramente nesse requisito.
Nada disto torna o armazenamento cloud não conforme por defeito. Significa que «em conformidade com o RGPD» é uma condição necessária para a soberania das credenciais.
Exemplo concreto: Exposição jurisdicional
Um gestor de palavras-passe cloud alojado em centros de dados dos EUA está sujeito à legislação norte-americana. Ao abrigo do CLOUD Act, as autoridades policiais dos EUA podem obrigar os prestadores de serviços a entregar dados de clientes. Além disso, a FISA Section 702 permite que os serviços de informações solicitem dados a prestadores de serviços sediados nos EUA. Se o fornecedor controla as chaves de decifragem, tem de cumprir estas ordens federais. O registo da empresa cliente na UE ou as suas políticas internas de segurança não podem anular esta obrigação legal.
Associar as três camadas aos modelos de implementação
Uma lacuna em qualquer uma das camadas volta a abrir a exposição que as outras duas deviam fechar. A tabela abaixo aplica os três controlos da primeira secção, localização, decifragem e acesso, aos modelos entre os quais as organizações realmente escolhem.
| Camada | On-premise | Com isolamento físico | Região cloud na UE |
|---|---|---|---|
| Onde estão os dados | Infraestrutura do próprio cliente | Rede isolada, sem acesso à internet | Centro de dados do fornecedor na UE |
| Quem pode decifrar | Apenas o cliente, arquitetura zero-knowledge | Apenas o cliente, arquitetura zero-knowledge, sem conectividade externa | Depende do modelo de cifragem; seguro apenas com cifragem do lado do cliente |
| Quem governa o acesso | RBAC e registos de auditoria do cliente | RBAC do cliente, mantido manualmente | RBAC do cliente, com o fornecedor a gerir a camada de infraestrutura |
- Com isolamento físico (air gap) designa uma infraestrutura sem qualquer caminho de rede para a internet, a forma mais estrita de isolamento físico.
- Zero-knowledge significa que o fornecedor nunca pode ler os dados, em circunstância alguma.
- A cifragem do lado do cliente é o mecanismo que produz essa garantia: a cifragem e a decifragem ocorrem no dispositivo do utilizador, com uma palavra-passe mestra que o fornecedor nunca recebe nem armazena, pelo que o servidor apenas guarda e transmite texto cifrado.
Um esquema de cifragem do lado do cliente mal implementado, com uma palavra-passe mestra recuperável ou uma função de derivação de chaves fraca, não oferece automaticamente uma garantia zero-knowledge verdadeira. Esta distinção determina se «cifrado na cloud» tem realmente algum significado para a soberania.
On-premise e com isolamento físico: Isolamento total, com custo operacional
A implementação on-premise confere a uma organização controlo físico e criptográfico total sobre o seu cofre de credenciais, porque os dados nunca saem da infraestrutura que a organização possui e administra. O isolamento físico vai um passo além: a infraestrutura não tem qualquer caminho de rede para a internet, o que é a única configuração que elimina por completo a dependência de rede externa.
Isolamento em relação ao fornecedor: Cifragem zero-knowledge
Passwork funciona integralmente dentro do perímetro corporativo, numa infraestrutura que a organização controla de ponta a ponta. O gestor de palavras-passe e segredos cifra e decifra os dados inteiramente do lado do cliente, com uma chave derivada da palavra-passe mestra do utilizador. O servidor nunca recebe nem armazena texto em claro, em momento algum: guarda apenas blobs cifrados e não dispõe de nenhuma chave capaz de os decifrar. Para organizações com requisitos de air gap e políticas de segmentação rigorosas, esta é frequentemente a única arquitetura que cumpre a política de segurança interna.
Uma afirmação destas não deve ser aceite apenas com base na confiança. O código-fonte do Passwork está aberto para que a própria equipa de segurança da organização o audite diretamente, linha a linha, em vez de depender da descrição do fornecedor sobre a forma como a cifragem é implementada.
A contrapartida operacional
Esse nível de isolamento tem um preço, pago em esforço operacional. On-premise transfere a manutenção do servidor, a aplicação de patches, a gestão de cópias de segurança e a responsabilidade pela disponibilidade do fornecedor para a equipa de TI da própria organização. Alguém tem de aplicar atualizações, monitorizar o espaço em disco, gerir certificados TLS e tratar da recuperação de desastres. Para uma equipa de TI pequena, já sobrecarregada com outras prioridades, trata-se de um custo real. As organizações que optam pelo autoalojamento precisam de um administrador de sistemas dedicado ou de um processo interno gerido para manter a implementação atualizada.
A cifragem zero-knowledge do Passwork mantém os dados ilegíveis para todos, exceto para os próprios utilizadores. Consultar a arquitetura nos guias do utilizador antes de comprometer a infraestrutura, ou testar gratuitamente a implementação completa para a ver em funcionamento nos próprios servidores.
Alojamento cloud na UE: Viável, mas apenas com cifragem do lado do cliente
O alojamento cloud na UE pode satisfazer os requisitos jurisdicionais de equipas mais pequenas sem pessoal de infraestrutura dedicado, mas apenas se o fornecedor implementar cifragem do lado do cliente (CSE) obrigatória. Sem CSE, um cofre alojado na UE continua a permitir que o fornecedor decifre os dados dos clientes, o que reabre a mesma exposição que o alojamento na UE devia eliminar.
Num modelo CSE adequado, a palavra-passe mestra nunca sai do dispositivo do utilizador e os servidores do fornecedor processam e armazenam apenas texto cifrado. Mesmo com acesso físico total ao servidor, o fornecedor não consegue ler o conteúdo do cofre. Esta garantia é substancialmente diferente de «os nossos centros de dados estão na UE», que aborda a jurisdição, mas nada diz sobre quem detém as chaves.
O alojamento cloud na UE com CSE reduz a exposição jurídica e satisfaz os requisitos de residência de dados de muitos quadros de conformidade, mas não é a mesma garantia que a soberania total on-premise. A infraestrutura, a camada de rede e o hardware físico permanecem fora do controlo direto do cliente. Para organizações com obrigações de air gap ou políticas rigorosas de autoalojamento, a cloud na UE não é um substituto, independentemente da robustez da cifragem.
On-premise sem zero-knowledge continua a confiar o acesso a texto em claro aos administradores locais. A cloud na UE sem zero-knowledge continua a confiar no pessoal de infraestrutura do fornecedor. Em ambos os casos, a garantia só se mantém quando a palavra-passe mestra nunca sai do dispositivo do utilizador.
Verificar as afirmações dos fornecedores: O que as aquisições devem confirmar
As afirmações de soberania só são tão credíveis quanto as provas de terceiros que as sustentam. Esta verificação aplica-se independentemente do modelo de implementação escolhido: um certificado não indica onde os dados se encontram, mas indica se as restantes afirmações do fornecedor se sustentam. As equipas de aquisições devem basear a decisão de autoalojamento na capacidade administrativa interna e nos requisitos de política, e depois validar o fornecedor pré-selecionado através de certificação independente, auditoria própria e testes de segurança públicos.
Quatro verificações são relevantes na prática:
- Certificação ISO/IEC 27001 confirma que um sistema de gestão de segurança da informação foi auditado de forma independente face à norma internacional. O Passwork possui a certificação ISO/IEC 27001:2022, emitida pela MSECB e verificável através da base de dados IAF CertSearch.
- A preparação para a NIS2 e o RGPD é relevante para qualquer organização abrangida pelo âmbito de um destes regulamentos. Os requisitos de cadeia de abastecimento do artigo 21.º da NIS2 estendem-se às ferramentas que as entidades essenciais e importantes utilizam para gerir credenciais de acesso, enquanto o artigo 32.º do RGPD exige «medidas técnicas e organizativas adequadas», incluindo a cifragem, para qualquer sistema que trate dados pessoais. As organizações que avaliem fornecedores face a estes requisitos podem consultar a abordagem do Passwork à conformidade com a NIS2 como um ponto de referência.
- Direitos de auditoria do código-fonte confirmam que uma afirmação de zero-knowledge é efetivamente verdadeira e não linguagem de marketing. Numa conceção zero-knowledge genuína, o fornecedor não consegue recuperar a palavra-passe mestra de um utilizador individual em circunstância alguma: nem através de uma reposição no backend, nem através de um pedido de suporte, nem sob pressão legal. Se um utilizador a esquecer, os dados que protege perdem-se por conceção, porque o fornecedor nunca teve a chave. O Passwork abre o seu código-fonte às equipas de segurança dos clientes precisamente por esta razão: é a forma de confirmar que a implementação da cifragem corresponde à arquitetura descrita pelo fornecedor.
- Testes de intrusão públicos fornecem provas que vão além da postura de segurança autodeclarada. O Passwork concluiu um teste de intrusão independente através da HackerOne, abrangendo o tratamento seguro de dados, o OWASP Top 10 e o SANS Top 25, a autenticação e o controlo de acesso à API.
Escolher um modelo de implementação: Um modelo de decisão
O modelo de implementação adequado depende de cinco fatores práticos:
- Requisitos de air gap
- Alojamento obrigatório na UE
- Dimensão da equipa de administração
- Política interna de autoalojamento
- Requisitos de controlo da infraestrutura
Confrontar estes fatores com as opções de implementação evita o erro comum de escolher apenas com base no preço ou na notoriedade da marca. Utilize esta matriz de decisão de residência de credenciais para fazer corresponder as restrições da organização a um modelo de implementação:
| Requisito | Modelo recomendado |
|---|---|
| Obrigação de air gap (ICS, ambientes classificados) | On-premise, rede totalmente isolada |
| Residência de dados obrigatória na UE, sem requisito de air gap | On-premise ou cloud na UE com cifragem do lado do cliente (a escolha depende dos requisitos de controlo da infraestrutura) |
| Equipa de TI/administração pequena, capacidade de infraestrutura limitada | Cloud na UE com cifragem do lado do cliente |
| Política interna de autoalojamento rigorosa (regulamentar ou contratual) | On-premise, infraestrutura gerida pelo cliente |
Na prática, nenhuma destas linhas é mutuamente exclusiva. Uma instituição financeira pode operar on-premise para o seu cofre principal e, ao mesmo tempo, aceitar ferramentas baseadas na cloud para fluxos de trabalho de menor sensibilidade. A matriz é um ponto de partida para a conversa com as partes interessadas de segurança e conformidade.
Como a arquitetura do Passwork se enquadra nestas camadas
A implementação autoalojada do Passwork responde à lacuna de soberania descrita ao longo deste artigo, combinando isolamento físico, cifragem zero-knowledge e governação de acessos controlada pelo cliente numa única arquitetura. O cofre é implementado na infraestrutura que o cliente possui, seja um único servidor Linux, um ambiente Windows Server ou um contentor Docker numa rede com isolamento físico.
A cifragem utiliza AES-256 com um desenho zero-knowledge, o que significa que a infraestrutura, caso alguma vez fosse comprometida, apenas contém texto cifrado. O acesso é governado através de permissões baseadas em funções e de um registo de auditoria completo, pelo que os administradores podem ver quem acedeu a que credencial e quando, e revogar o acesso de imediato quando alguém muda de função ou sai. A integração com AD/LDAP e SAML SSO permite que a governação de acessos se ligue à infraestrutura de identidade existente, em vez de funcionar como um silo separado.
Isto não é, deliberadamente, uma afirmação de que o autoalojamento é adequado para todos. As organizações sem requisitos de air gap nem obrigações estritas de autoalojamento podem considerar suficiente uma opção cloud com cifragem do lado do cliente adequada. O ponto é que, quando a soberania total é o requisito, a arquitetura tem de a viabilizar de forma estrutural.
Soberania de dados na gestão de palavras-passe: Como aplicá-la na avaliação
A soberania é um alinhamento contínuo entre o local onde os dados se encontram, quem detém as chaves e quem governa o acesso, e esse alinhamento tem de ser revisto sempre que a infraestrutura, os contratos com fornecedores ou o âmbito regulamentar se alterem.
Comece por mapear a organização face aos quatro fatores da matriz de decisão: requisito de air gap, alojamento obrigatório na UE, dimensão da equipa de administração e política interna de autoalojamento. Esse mapeamento diz mais sobre o modelo de implementação adequado do que a página de marketing de qualquer fornecedor.
A única forma de confirmar que uma arquitetura autoalojada se adequa à infraestrutura é executá-la nela. O Passwork oferece um período de teste gratuito que pode ser implementado nos próprios servidores, com todas as funcionalidades e sem que quaisquer dados saiam do ambiente do cliente.
Perguntas frequentes
O que é a soberania de dados no contexto da gestão de palavras-passe?
A soberania de dados na gestão de palavras-passe significa que a organização, e não um fornecedor terceiro, controla onde os dados de credenciais residem fisicamente, quem detém as chaves de cifragem e quem lhes pode aceder. A conformidade com o RGPD, por si só, não garante a soberania se o fornecedor puder decifrar tecnicamente os dados ou estiver sujeito a pedidos legais de uma jurisdição estrangeira.
A conformidade com o RGPD é suficiente para garantir a soberania das credenciais?
Não. A conformidade com o RGPD aborda obrigações amplas de tratamento de dados, e o capítulo V rege especificamente as transferências transfronteiriças, mas nenhum dos dois define quem detém as chaves de cifragem. Um fornecedor em conformidade com o RGPD pode, ainda assim, decifrar tecnicamente os dados dos clientes, a menos que a arquitetura utilize zero-knowledge ou cifragem do lado do cliente.
Qual é a diferença entre a implementação on-premise e com isolamento físico?
On-premise significa que o software é executado numa infraestrutura propriedade da organização, que pode ainda ter ligação à internet. Com isolamento físico significa que essa infraestrutura não tem qualquer caminho de rede para a internet. O isolamento físico é um subconjunto mais estrito do on-premise, tipicamente exigido em ambientes de defesa, de controlo industrial ou classificados.
O alojamento cloud na UE satisfaz os requisitos de soberania de dados?
O alojamento cloud na UE satisfaz os requisitos jurisdicionais e de residência de dados apenas quando combinado com cifragem do lado do cliente, em que o fornecedor nunca detém as chaves de decifragem. Sem ela, o alojamento na UE resolve a localização, mas não quem pode aceder aos dados, o que deixa uma lacuna de soberania significativa para organizações com requisitos rigorosos.
Contra o que protege, na realidade, a arquitetura zero-knowledge?
A arquitetura zero-knowledge protege contra o comprometimento do lado do servidor, o acesso interno no fornecedor e pedidos legais de dados, porque o servidor armazena apenas texto cifrado. A palavra-passe mestra permanece no dispositivo do utilizador e nunca é transmitida nem armazenada pela infraestrutura do fornecedor.
Como afeta a NIS2 a seleção de fornecedores de gestores de palavras-passe?
O artigo 21.º, n.º 2, alínea d), da NIS2 exige que as entidades essenciais e importantes giram o risco de segurança da cadeia de abastecimento, o que abrange os fornecedores que tratam credenciais de acesso. As organizações abrangidas pela NIS2 devem avaliar as certificações e os testes de segurança dos fornecedores de gestores de palavras-passe como parte das suas próprias obrigações de conformidade.
Passwork Team
Alex Muntyan
Passwork Team