Senha de VPN salva: quem pode descriptografá-la e quando

Um cliente VPN que mostra uma senha criptografada em seu XML não lhe disse quase nada. O texto cifrado responde apenas que o valor não está armazenado como texto simples naquela representação. Quem pode descriptografá-lo, com qual chave e sob qual contexto de usuário são as perguntas que decidem se o armazenamento ajuda. Responda a elas antes de chamar o arquivo de seguro ou inseguro.

Estabeleça qual objeto está armazenado

Comece pelo modelo de armazenamento documentado do produto. Um cliente pode guardar uma senha recuperável, um token ou uma referência a um cofre de credenciais, e cada um tem exposição diferente. O nome do elemento XML não é o projeto, e uma sequência parecida com base64 também não é prova de criptografia.

Pergunte ao fornecedor ou administrador qual componente lê o valor no momento da conexão.

Depois identifique a API de proteção, se estiver documentada. No Windows, CryptProtectData protege dados com uma chave derivada das credenciais de logon do usuário que criptografa, e a opção no escopo da máquina muda quem pode descriptografar. Esse é um exemplo concreto de por que o escopo importa. Não é evidência de que algum cliente VPN específico use essa API.

Separe uma cópia roubada do uso em tempo de execução

Um cliente que se reconecta sem perguntar precisa de um meio suportado de recuperar a credencial. Proteger uma cópia de backup não remove essa capacidade. Qualquer programa em execução no contexto de usuário correto pode usar o mesmo caminho, e é por isso que o próprio endpoint fica dentro da fronteira de confiança. Permissões de arquivo e privilégios de processo estreitam essa fronteira; não a removem.

É essa distinção que uma alegação sobre arquivo offline costuma errar. A criptografia em repouso pode impedir alguém que copia um arquivo sem a conta. Não impede código que roda como a conta.

As duas afirmações podem ser verdadeiras ao mesmo tempo, e a segunda é a que importa durante a resposta a incidentes.

Leia os controles de acesso que realmente se aplicam

Verifique a ACL do arquivo e do diretório acima dele, não apenas o modo do arquivo. No Windows, compare as permissões efetivas do perfil de usuário com as do serviço ou da tarefa agendada do cliente. Um segredo protegido para um usuário não fica automaticamente protegido de um administrador, nem automaticamente exposto a ele.

icacls "%APPDATA%\Vendor\Client\profiles.xml"
whoami /priv

Registre qual identidade executa o cliente, porque essa identidade é o sujeito da descriptografia.

Para uma frota gerenciada, o controle relevante pode ser o gerenciamento de dispositivos em vez do arquivo. Pergunte se a credencial é custodiada, se pode ser revogada remotamente e qual é o processo quando um dispositivo se perde.

Planeje a exposição em vez de testar a descriptografia

Não execute uma ferramenta de extração desconhecida contra o arquivo para provar um ponto. Pode funcionar, pode danificar o perfil e, de qualquer forma, altera a evidência. Use o projeto documentado e uma avaliação autorizada se a verificação for realmente necessária.

Se a exposição for estabelecida, troque a credencial no dono da identidade.

Apagar a entrada salva não é revogação. Pode impedir aquele cliente de oferecer o valor novamente, e não faz nada quanto a uma cópia já obtida ou a uma sessão já autorizada. Substitua a credencial, encerre as sessões que o dono puder encerrar e registre o que foi trocado e quando.

As perguntas para uma revisão de fornecedor

Pergunte qual segredo é armazenado, qual componente o usa, qual chave de usuário ou de máquina o protege, quais controles de acesso valem para o uso normal e os backups, e como a política de salvamento e a invalidação remota são tratadas. Essas cinco respostas descrevem o projeto; o XML não.

Guarde as respostas com o registro de implantação para que o próximo revisor não repita o exercício.

Uma credencial salva é uma troca entre conveniência e exposição. Faça a troca de propósito e anote quem a aceitou.