Obrigatório
A chave é armazenada em um gerenciador de segredos no lado do servidor ou em uma configuração de ambiente protegida.
Não faça commit dela no controle de versão.
Guia de segurança
Crie integrações mais seguras com práticas recomendadas de segurança de chaves de API
As práticas recomendadas de segurança de chaves de API ajudam a manter uma conexão com a API de IA útil sem facilitar a exposição de credenciais confidenciais. Este guia explica os controles práticos a serem usados antes, durante e depois de uma integração.
Como era feito antes
As integrações mais antigas com a API de IA frequentemente tratavam uma chave como uma sequência de caracteres conveniente, em vez de uma credencial com um ciclo de vida.
- ExposiçãoUma chave colocada diretamente no código do navegador pode ser copiada por qualquer pessoa que carregue o aplicativo.
- ControleAs variáveis de ambiente reduzem vazamentos no código-fonte, mas não substituem o controle de acesso nem a rotação.
- SeparaçãoUma chave separada para cada ambiente torna a investigação de incidentes e a revogação mais precisas.
- PadrãoO padrão mais seguro é manter a chave em um servidor e enviar somente solicitações aprovadas por meio dele.
Como é feito hoje
Um plano de segurança para a API de IA deve declarar o que a integração não pode garantir e, em seguida, oferecer uma alternativa viável para cada limitação.
- Ela não pode tornar privada uma chave do lado do cliente
-
Qualquer coisa enviada para um navegador, pacote para dispositivos móveis ou repositório público pode acabar sendo extraída e reutilizada.
Solução alternativaMova a credencial para um proxy do lado do servidor e exponha apenas a operação específica de que o cliente precisa.
- Ela não pode impedir que todas as solicitações válidas sejam caras
-
Uma credencial roubada ou usada indevidamente ainda pode gerar tráfego, mesmo quando o formato da solicitação parece legítimo.
Solução alternativaDefina limites do provedor, cotas da aplicação, orçamentos de solicitações e alertas para volumes incomuns.
- Ela não consegue identificar uma pessoa a partir de uma credencial compartilhada
-
Uma única chave usada por toda a equipe dificulta atribuir atividades ou investigar um fluxo de trabalho comprometido.
Solução alternativaEmita credenciais separadas ou identidades de serviço autenticadas para pessoas, ambientes e serviços.
- Ela não consegue reparar uma chave que já tenha vazado
-
Excluir uma publicação pública ou remover uma entrada de log não apaga cópias feitas por rastreadores, forks ou sistemas de monitoramento.
Solução alternativaRevogue a chave exposta, emita uma substituta, inspecione o uso e documente o incidente.
O que mudou
O trabalho moderno com APIs de IA trata as credenciais como segredos gerenciados. Antes de conectar uma aplicação, confirme estes requisitos em vez de depender de uma única variável oculta.
Obrigatório
Produção, preparação, desenvolvimento local e testes automatizados usam credenciais separadas.
O isolamento limita o raio de impacto.
Obrigatório
A aplicação autentica os usuários antes de permitir solicitações que consumam a API de IA.
Uma chave do provedor não é uma identidade de usuário final.
Obrigatório
Os logs excluem cabeçalhos de autorização, corpos completos de solicitações e detalhes de erros que contenham segredos.
Revise os logs da aplicação e do provedor.
Obrigatório
A rotação e a revogação têm um responsável, um procedimento documentado e um caminho de recuperação testado.
Um plano só é útil quando pode ser executado.
Opcional
Os alertas de uso e os limites de solicitações são configurados para o provedor e o aplicativo.
Altamente recomendado para produção.
Quem mudou
A mudança é mais visível nas equipes que passaram de um único script experimental para um serviço compartilhado de API de IA com usuários reais e responsabilidade operacional.
-
1
a API de IA é segura para usar
Este guia, com foco na confiança, explica como avaliar os riscos antes de depender de um fluxo de trabalho de API de IA.
-
2
chave de API de IA gratuita
Este guia de acesso esclarece o que verificar antes de usar uma credencial gratuita em um teste ou protótipo.
-
3
provedores de API de IA
Esta visão geral dos provedores ajuda a comparar autenticação, limites, acesso a modelos e políticas operacionais.
Quem mudou
Escolha o padrão de controle que corresponda à etapa e ao formato da sua integração de API de IA, não aquele que é apenas mais rápido de colar em uma demonstração.
1
Você está desenvolvendo um cliente para navegador ou dispositivo móvel
Use um proxy no lado do servidor com autenticação de usuário, validação de solicitações e limites por usuário.
O cliente precisa de acesso a um recurso de API de IA, não à credencial do provedor.
2
Você está executando um serviço de back-end privado
Armazene a chave fora do repositório, restrinja o escopo dela quando houver suporte e mantenha uma chave separada por ambiente.
Um back-end pode proteger o segredo e, ao mesmo tempo, fornecer ao aplicativo acesso controlado à API de IA.
3
Você está testando uma integração de API de IA localmente
Use uma chave de desenvolvimento descartável, um orçamento pequeno de solicitações e fixtures ou mocks quando as chamadas reais forem desnecessárias.
Scripts locais, terminais compartilhados, capturas de tela e registros de depuração são pontos comuns de exposição acidental.
Quem mudou
A diferença entre antes e depois não está em um prompt ou modelo mais complexo. Está na mudança de onde a autoridade reside e na rapidez com que uma credencial comprometida pode ser contida.
Chave no cliente
Mantenha a autoridade por trás do limite da aplicação.
Quem mudou
Os controles de segurança são mais fáceis de adotar antes que uma integração com uma API de IA se torne difícil de alterar.
Coloque em prática um acesso mais seguro à API de IA
Comece com uma rota de servidor protegida, uma credencial de desenvolvimento separada e uma resposta documentada para suspeitas de exposição. Em seguida, adicione boas práticas de registro, limites, rotação e revisão à medida que a integração crescer. O objetivo não é o sigilo perfeito; é ter acesso controlado, responsabilidades claras e um pequeno raio de impacto quando algo der errado.
- Mantenha as chaves do provedor fora dos navegadores e dos repositórios públicos.
- Separe as credenciais por ambiente e serviço.
- Faça a rotação imediatamente quando houver suspeita de exposição.
Seu próprio FAQ
Estas respostas abordam as dúvidas práticas que as pessoas fazem ao aplicar as melhores práticas de segurança de chaves de API a um projeto de API de IA.
Armazene-a no servidor, em uma configuração de ambiente protegida ou em um gerenciador de segredos dedicado. A chave não deve aparecer em JavaScript do navegador, pacotes de aplicativos móveis, controle de versão, capturas de tela ou registros comuns da aplicação.
Uma variável de ambiente é mais segura do que deixar uma chave codificada diretamente, mas é apenas uma camada. O acesso ao host, ao sistema de implantação, aos registros, ao processo de compilação e aos relatórios de erros também deve ser restrito e revisado.
Não. Credenciais separadas permitem revogar uma chave de desenvolvimento sem interromper a produção e facilitam a atribuição de atividades incomuns. Quando for viável, use chaves diferentes para o trabalho local, o ambiente de homologação, a produção e os testes automatizados.
Revogue ou desative a chave imediatamente e, em seguida, crie uma substituta por meio de um canal confiável. Revise o uso e os registros em busca de atividades não autorizadas, remova o segredo do local original e registre o ocorrido para reduzir a probabilidade de a mesma exposição se repetir.
Você deve presumir que qualquer chave enviada a um navegador ou cliente móvel é pública. Coloque a credencial atrás de uma rota do lado do servidor, autentique o solicitante, valide a solicitação e aplique limites antes de encaminhar as chamadas aprovadas para a API de IA.