Três dicas para proteger seus segredos contra acidentes de IA
No ano passado, o Open Worldwide Application Security Project (OWASP) publicou diversas versões do “ OWASP Top 10 For Large Language Models ”, alcançando um documento 1.0 em agosto e um documento 1.1 em outubro. Esses documentos não apenas demonstram a natureza em rápida evolução dos Grandes Modelos de Linguagem, mas também as formas evolutivas pelas quais eles podem ser atacados e defendidos. Vamos falar neste artigo sobre quatro itens desse top 10 que mais podem contribuir para a divulgação acidental de segredos como senhas, chaves de API e muito mais.
Já sabemos que os LLMs podem revelar segredos porque isso aconteceu. No início de 2023, o GitGuardian relatou que encontrou mais de 10 milhões de segredos em commits públicos do Github. A ferramenta de codificação Copilot AI do Github foi treinada em commits públicos e, em setembro de 2023, pesquisadores da Universidade de Hong Kong publicaram um artigo sobre como criaram um algoritmo que gerou 900 prompts projetados para fazer o Copilot revelar segredos de seus dados de treinamento. Quando esses prompts foram usados, o Copilot revelou mais de 2.700 segredos válidos.
Você pode estar mais familiarizado com a injeção imediata do bug revelado no ano passado que fazia o ChatGPT começar a cuspir dados de treinamento se você pedisse para repetir certas palavras para sempre.
Dica 1: alterne seus segredos
Mesmo que você não ache que publicou acidentalmente segredos no GitHub, vários dos segredos ali contidos foram confirmados em um commit anterior e derrotados em um commit mais recente, portanto, eles não são facilmente aparentes sem revisar todo o seu histórico de commits, não apenas o estado atual de seus repositórios públicos.
Uma ferramenta do GitGuardian, chamada Has My Secret Leaked , permite criptografar um segredo atual com hash e, em seguida, enviar os primeiros caracteres do hash para determinar se há alguma correspondência em seu banco de dados com o que eles encontraram em suas varreduras do GitHub. Uma correspondência positiva não é uma garantia de que seu segredo vazou, mas fornece uma probabilidade potencial de que isso tenha acontecido para que você possa investigar mais detalhadamente.
As advertências sobre a rotação de chave/senha são que você deve saber onde elas estão sendo usadas, o que pode falhar quando forem alteradas e ter um plano para mitigar essa quebra enquanto os novos segredos se propagam para os sistemas que precisam deles. Após a rotação, você deve garantir que os segredos mais antigos tenham sido desativados.
Os invasores não podem usar um segredo que não funciona mais e se os seus segredos que podem estar em um LLM tiverem sido alternados, eles se tornarão nada além de strings inúteis de alta entropia.
Dica 2: limpe seus dados
Embora avisos deliberadamente projetados possam fazer com que os LLMs revelem dados confidenciais, eles também podem fazer isso acidentalmente. A melhor maneira de garantir que o LLM não revele dados confidenciais é garantir que o LLM nunca saiba disso.
Isso é mais focado quando você está treinando um LLM para uso por pessoas que nem sempre pensam nos seus melhores interesses ou pessoas que simplesmente não deveriam ter acesso a determinadas informações. Quer sejam seus segredos ou molho secreto, apenas aqueles que precisam ter acesso a eles devem tê-los… e seu LLM provavelmente não é uma dessas pessoas.
Usar ferramentas de código aberto ou serviços pagos para verificar se há segredos em seus dados de treinamento ANTES de fornecer os dados ao seu LLM ajudará você a remover os segredos. O que o seu LLM não sabe, ele não pode dizer.
Dica 3: aplique patches regularmente e limite privilégios
Recentemente, vimos um artigo sobre o uso de arquivos .env e variáveis de ambiente como uma forma de manter os segredos disponíveis para o seu código, mas fora dele. Mas e se o seu LLM pudesse ser solicitado a revelar variáveis de ambiente… ou fazer algo pior?
Isso combina o item 2 (“Tratamento de saída inseguro”) e o item 8 (“Agência excessiva”).
- Tratamento de saída inseguro:esta vulnerabilidade ocorre quando uma saída LLM é aceita sem escrutínio, expondo sistemas backend. O uso indevido pode levar a consequências graves, como XSS, CSRF, SSRF, escalonamento de privilégios ou execução remota de código.
- Agência Excessiva:Os sistemas baseados em LLM podem empreender ações que levam a consequências não intencionais. O problema surge do excesso de funcionalidade, permissões ou autonomia concedidas aos sistemas baseados em LLM.
É difícil separá-los porque eles podem piorar um ao outro. Se um LLM puder ser induzido a fazer algo e seu contexto operacional tiver privilégios desnecessários, o potencial de uma execução de código arbitrário causar grandes danos se multiplica.
Todo desenvolvedor já viu o desenho animado ” Exploits of a Mom “, onde um garoto chamado `Robert”); DROP TABLE Students;”` apaga o banco de dados de alunos de uma escola. Embora um LLM pareça inteligente, na verdade não é mais inteligente do que um banco de dados SQL. E assim como seu irmão “comediante” faz seu sobrinho repetir palavrões para a vovó, informações ruins podem criar resultados ruins. Ambos devem ser higienizados e considerados indignos de confiança.
Além disso, você precisa configurar proteções em torno do que o LLM ou aplicativo pode fazer, considerando o princípio do menor privilégio . Essencialmente, os aplicativos que usam ou habilitam o LLM e a infraestrutura do LLM não devem ter acesso a quaisquer dados ou funcionalidades de que não sejam absolutamente necessários, para que não possam acidentalmente colocá-los a serviço de um hacker.
A IA ainda pode ser considerada em sua infância e, como acontece com qualquer bebê, não deve ser dada liberdade para vagar por qualquer cômodo que não tenha sido à prova de bebês. Os LLMs podem interpretar mal, ter alucinações e ser deliberadamente desencaminhados. Quando isso acontece, boas fechaduras, boas paredes e bons filtros devem ajudar a evitar que acessem ou revelem.