ProxyKey Abre Código de Criptografia de Armazenamento de API Keys e Detalha Suas Limitações

A ProxyKey, um serviço de proxy de credenciais que armazena chaves de API reais de forma criptografada e fornece tokens virtuais revogáveis para aplicações e agentes de IA, tomou uma decisão transparente em relação à segurança de seus usuários. Em resposta a perguntas frequentes sobre a capacidade do serviço de acessar as chaves de API dos clientes, a empresa optou por não ocultar a realidade em um "nevoeiro de marketing". Em vez disso, a ProxyKey publicou integralmente seu módulo criptográfico e criou uma página dedicada à sua modelo de ameaças, destacando explicitamente a possibilidade de acesso às chaves como a primeira e mais proeminente preocupação.

O cerne da questão reside na própria natureza de um serviço de proxy de credenciais. Para que o proxy possa inserir uma chave de API em uma solicitação ao provedor, ele é obrigado a descriptografar essa chave. Isso significa que, no momento da requisição, a chave em texto plano existe na memória do processo. Essa é uma característica arquitetural inerente, não uma falha de segurança. Consequentemente, um operador do servidor com acesso completo ao sistema tem, tecnicamente, a capacidade de obter o texto plano da chave. Essa limitação é comum a todas as soluções hospedadas dessa categoria, incluindo gerenciadores de senhas e armazenamentos em nuvem. A diferença, segundo a ProxyKey, está na disposição de abordar essa questão abertamente.

A criptografia empregada pela ProxyKey, embora não ofereça uma garantia contra o comprometimento total do servidor ou um operador malicioso, protege contra uma série de cenários de ameaças mais prováveis e concretos. Isso inclui vazamentos de dump de banco de dados, roubo de backups, exposição de logs (já que as chaves e cabeçalhos de autenticação não são registrados em texto plano) e comprometimento isolado do banco de dados (onde os textos cifrados se tornam inúteis sem a chave mestra de criptografia – KEK – do ambiente do processo). Além disso, a proteção se estende ao vazamento de tokens virtuais, que são vinculados a IPs, possuem limites de uso e podem ser revogados instantaneamente. A tabela completa de cenários protegidos e não protegidos está disponível na página de segurança do serviço.

O módulo criptográfico aberto, denominado proxykey-crypto, é composto por aproximadamente 450 linhas de TypeScript, incluindo testes e dependendo apenas do módulo node:crypto. Ele implementa um esquema de criptografia envelope onde cada segredo é criptografado com sua própria chave de dados (DEK) usando AES-256-GCM com um Identificador de Dados Autenticados (AAD) que corresponde ao ID do segredo, impedindo a substituição silenciosa de textos cifrados. A DEK é então encapsulada por uma chave mestra (KEK) que reside exclusivamente no ambiente do processo, não sendo armazenada no banco de dados. A descriptografia ocorre na memória apenas durante o tempo de vida de uma requisição, com a DEK e a cópia em texto plano sendo zeradas em um bloco finally para garantir a limpeza em todos os caminhos de execução, incluindo exceções. Os tokens virtuais armazenados no banco de dados são apenas hashes SHA-256. O repositório inclui 18 testes que cobrem cenários como roundtrip, substituição de texto cifrado/tag/encapsulamento, AAD incorreto e versões de chave inválidas.

A ProxyKey também é explícita sobre o que o código aberto não garante. Primeiro, código aberto não é uma prova formal; embora o esquema possa ser revisado, o repositório não pode provar criptograficamente que o código executado no servidor é exatamente o código publicado. É um ato de transparência, não uma certificação. Segundo, a operação de zerar a memória (fill(0)) é feita em regime de "melhor esforço" (best-effort). O V8, o motor JavaScript, pode ter copiado buffers internamente durante suas operações, e strings imutáveis em JavaScript, como a chave descriptografada, vivem até a coleta de lixo, impossibilitando a garantia de zeramento imediato. A janela de exposição é reduzida, mas não eliminada. Terceiro, embora o comprimento da KEK seja verificado, sua entropia não é. A ausência de uma Função de Derivação de Chave (KDF) é intencional, pois a chave mestra deve ser uma chave aleatória gerada externamente (como com openssl rand -base64 32), e não uma senha. O README do repositório contém uma seção "Design notes" que aborda questões comuns de revisão, como o limite do nonce random para GCM e o motivo pelo qual o encapsulamento da DEK não está vinculado ao AAD (para facilitar a rotação futura da KEK). A empresa incentiva a comunidade a relatar quaisquer vulnerabilidades encontradas na seção de issues.

Para mitigar os riscos associados até mesmo a um "operador" comprometido, a ProxyKey oferece conselhos práticos para usuários de qualquer armazenamento de chaves hospedado. Recomenda-se a criação de chaves com escopo limitado, em vez de chaves mestras. Por exemplo, usar uma chave de projeto com um orçamento de $20 para a API da OpenAI em vez da chave da conta inteira limita o dano potencial a $20 em caso de comprometimento. A configuração de limites no lado do provedor de API serve como uma segunda linha de defesa após os limites do próprio serviço de armazenamento. A rotação regular das chaves originais com o provedor também é crucial para invalidar quaisquer informações que possam ter vazado anteriormente. Para aqueles que buscam o mais alto nível de segurança e não confiam em soluções hospedadas, a ProxyKey sugere a abordagem racional de reproduzir a solução: o esquema é documentado, o módulo criptográfico é aberto, e os usuários podem construir e gerenciar sua própria instalação.

A ProxyKey, disponível em proxykey.org, opera como um serviço gratuito. Este post não é um endosso de segurança cega, mas sim uma declaração clara dos limites de segurança oferecidos, apresentando o código e especificando os aspectos que ainda dependem da confiança. A empresa acredita que essa abordagem transparente é mais honesta e benéfica para todos que precisam escolher onde armazenar suas chaves de API.