Redija os segredos antes de colar
Redigir um segredo é substituir uma credencial dentro de um texto —uma chave API, um token, uma palavra-passe ou uma chave privada— por um marcador antes de o texto ser partilhado, para que a informação viaje sem o acesso. Importa porque a forma mais comum de vazar segredos não é um ataque, mas uma colagem: um registo num ticket de suporte, um ficheiro de configuração num chat, um comando de depuração num fórum. Este artigo explica porque essas colagens são tão difíceis de desfazer, o que um scanner como o redator de segredos pode e não pode detetar, e o fluxo —redigir localmente, partilhar a cópia redigida, rodar tudo o que já escapou— que evita que uma colagem prestável se torne um incidente.
Porque os segredos acabam em tickets, chats e registos
Ninguém cola um segredo de propósito. Cola o que rodeia o segredo: o registo de erro que por acaso inclui os cabeçalhos do pedido, o ficheiro de configuração que por acaso guarda a palavra-passe da base de dados três secções abaixo, o comando curl copiado de um terminal onde o token está sentado num cabeçalho Authorization. A resolução de problemas corre sobre contexto, e as credenciais vivem dentro do contexto — é por isso que as mesas de suporte, os canais de chat e os rastreadores de problemas acumulam silenciosamente chaves ativas, tokens de sessão e chaves privadas, escritas por pessoas cuidadosas com pressa que olhavam para a mensagem de erro e não para o cabeçalho acima dela.
O sistema recetor torna então a colagem permanente de formas que o remetente nunca vê. Os tickets são indexados para pesquisa, reencaminhados para fornecedores, exportados para relatórios e guardados durante anos; as mensagens de chat são empurradas para os telefones como notificações, citadas em tópicos e resumidas por bots; os registos são enviados para agregadores com a sua própria retenção e as suas próprias listas de acesso. Um segredo num destes sistemas não está num só lugar — está em cada cópia, cópia de segurança, pré-visualização e notificação que o sistema gerou, a maioria das quais o remetente não consegue enumerar, quanto mais apagar. Essa assimetria —um segundo para colar, nenhuma forma fiável de recuperar— é toda a razão pela qual a redação tem de acontecer antes da colagem, na máquina do remetente, e não como limpeza posterior.
O que um scanner pode detetar: formas, somas e estrutura
A boa notícia é que as credenciais reais são altamente padronizadas, e a varredura de padrões é determinística: o mesmo texto produz sempre as mesmas ocorrências, sem nenhum modelo a adivinhar pelo meio. As chaves dos fornecedores têm formas publicadas —prefixos, comprimentos fixos, alfabetos restritos—, por isso uma chave de acesso da AWS, um token do GitHub, uma chave da Stripe ou um token do Slack podem ser reconhecidos à vista, como quem reconhece um número de telefone num parágrafo. As chaves privadas anunciam-se com as suas linhas de armadura BEGIN e END, e os JSON Web Tokens têm uma estrutura rígida de três segmentos cujos dois primeiros segmentos começam sempre da mesma maneira, porque codificam sempre o mesmo tipo de JSON.
Duas verificações mantêm honesta a camada de padrões. Os números de cartão só são assinalados quando passam a soma de verificação de Luhn, um teste aritmético incorporado em cada número de cartão genuíno, que separa os cartões reais da população muito maior de números longos —encomendas, faturas, carimbos de tempo— que apenas se lhes parecem. E quando as formas se sobrepõem, os padrões específicos ganham aos genéricos, de modo que uma chave de fornecedor conhecida atribuída a uma variável é comunicada uma só vez, com o seu tipo real e as instruções de rotação corretas anexadas. A própria varredura de segredos do GitHub, a primeira fonte abaixo, funciona com o mesmo princípio à escala da plataforma: os parceiros publicam os formatos dos seus tokens e a plataforma casa-os com exatidão. Um scanner local é a mesma ideia, executada no último momento em que ainda pode ajudar — o seu navegador, antes de premir enviar.
O que um scanner não pode detetar: entropia e contexto
Para além das formas de fornecedor, a deteção torna-se probabilística. Uma regra genérica pode procurar atribuições —um nome como password ou api_key junto a um valor— e exigir que o valor pareça aleatório, medido pela entropia de Shannon. Isso apanha uma chave gerada atribuída a uma variável e ignora a palavra password dentro de uma frase, mas o limite é um juízo disfarçado de número: uma palavra-passe humana forte e uma chave de máquina fraca vivem na mesma escala, um segredo real soletrado como frase pontua baixo, e um hash de compilação de aspeto aleatório sem palavras de marcador pontua alto. A entropia diz-lhe que uma cadeia é surpreendente; não pode dizer-lhe que a cadeia é uma credencial.
O contexto é o ponto cego maior, porque quase tudo o que torna um valor perigoso está fora do valor. Um cookie de sessão é apenas letras e dígitos até saber que serviço desbloqueia. Uma palavra-passe de base de dados parece inofensiva dentro de uma cadeia de ligação repartida por três variáveis de ambiente, e um código de utilização única só é sensível durante dez minutos. Os scanners também não veem através da estrutura: um segredo embrulhado em duas linhas de registo, codificado em base64 dentro de um blob, ou capturado numa imagem é invisível para os padrões de texto, por bons que sejam. O resumo honesto é que um scanner apanha com fiabilidade a maioria documentada e bem formada — e que a pré-visualização que lhe mostra, com as ocorrências destacadas no lugar, ainda merece a sua própria vista de olhos de dez segundos, porque os seus olhos conhecem o contexto que os padrões não podem conhecer.
Há mais uma classe a que o scanner é deliberadamente cego, e fica ao lado de uma armadilha: os marcadores de posição. Os valores de documentação —que contêm palavras como example, test, dummy ou your-— são excluídos para que manuais e tutoriais não acendam a tabela de ocorrências. Mas cada exclusão é uma porta: uma chave real que por acaso contém uma dessas palavras, ou uma palavra-passe real preguiçosa posta num valor com aspeto de marcador, passa em silêncio. Trate a lista de exclusão como um controlo de ruído, nunca como uma garantia, e nunca marque uma credencial real com palavras de marcador para calar um scanner.
O problema do exemplo falso canónico
Cada fornecedor publica credenciais de exemplo, e a mais famosa —o par de documentação da AWS construído em redor de AKIAIOSFODNN7EXAMPLE— tem exatamente a forma de uma chave real, porque um exemplo que não parecesse real não ensinaria nada. Os scanners enfrentam então uma bifurcação sem bom valor por omissão. Assinalar os exemplos canónicos, e cada tutorial, manual e registo de formação torna-se um falso alarme, ensinando os leitores a descartar ocorrências por reflexo — a fadiga de alarmes é uma vulnerabilidade em si mesma. Colocá-los numa lista branca, e publicou uma lista de cadeias que nenhum scanner comunicará jamais, um convite para quem queira um esconderijo: uma chave real não pode ser igual ao exemplo, mas uma nota, um nome de ficheiro ou um invólucro em redor de uma chave real pode pedir emprestado o camuflado do exemplo.
A resposta prática é a que o redator de segredos adota: assinalar a forma e deixar a tabela de ocorrências iniciar a conversa. O exemplo canónico contém a palavra example dentro da própria chave, e mesmo assim é assinalado como chave da AWS, porque uma cadeia com forma de fornecedor merece um olhar humano de cada vez — o olhar é barato, e a alternativa é um passe silencioso para tudo o que tenha a mesma forma. Quando escrever documentação, ajude também os scanners dos seus leitores e o seu: use valores obviamente sintéticos, marque-os com palavras de marcador na atribuição circundante, e nunca cole uma chave real num documento e edite alguns caracteres — uma chave real parcialmente editada continua a ser uma fuga de credencial com passos extra, e os scanners também não a distinguem do artigo genuíno.
Rodar, não apenas apagar — e partilhar com segurança
Se um segredo real já foi colado sem redação, a ordem das operações importa e apagar vai para o fim, se for. Suponha que o valor foi copiado —por um índice, uma notificação, uma captura, a citação de um colega— e trate-o como público: vá primeiro ao fornecedor e rode a credencial, revogando a antiga, para que a cadeia vazada deixe de funcionar sobreviva onde sobreviver. Só então apague ou edite a mensagem original, como higiene e não como correção. A orientação de gestão de segredos da OWASP e o projeto gitleaks, ambos listados abaixo, existem para as duas metades desta lição: gerir segredos para que sejam de vida curta e âmbito limitado, e varrer repositórios e históricos supondo que as colagens já aconteceram. O problema companheiro para as capturas do navegador é percorrido em antes de enviar esse ficheiro HAR.
O fluxo seguro de partilha é curto o bastante para se tornar hábito. Primeiro, redija localmente, numa ferramenta que nunca envie o original — a análise pertence ao seu dispositivo, porque enviar texto bruto para um redator remoto repetiria a fuga no ato de a evitar. Segundo, partilhe a cópia redigida no ticket ou no chat, onde ela leva tudo o que um solucionador precisa —extremos, tempos, formas de erro— exceto o acesso. Terceiro, quando a outra parte precisar mesmo da credencial em si, envie-a através de um gestor de segredos ou de uma ligação de partilha expirável e de visualização única, por um canal separado da discussão, e diga-o no ticket para que ninguém a volte a colar. As equipas que adotam esses três passos deixam de depender da vigilância, que é o único controlo que falha sempre no fim, e passam a depender de uma rotina — e as rotinas são o que mantém os segredos fora dos tickets na colagem cansada de sexta-feira tão fiavelmente como na cuidadosa de segunda.