Defina os escopos antes da criação
Conceda a uma chave apenas as ações e os recursos de que a sua tarefa necessita. Uma integração de monitorização pode precisar de acesso de leitura; uma ferramenta de implementação pode precisar de um conjunto definido de operações de ciclo de vida. Mantenha a autoridade de faturação separada sempre que possível.
Revele com cuidado e armazene em privado
Uma chave real deve ser exibida por meio de um fluxo de criação seguro, protegida em repouso e excluída de URLs, pacotes de navegador e controle de código-fonte. Registre o proprietário, a finalidade e o horário de criação sem expor o segredo em si.
Torne a revogação prática
Emita credenciais separadas por integração para que uma possa ser revogada sem parar tudo. Rode deliberadamente e verifique que a chave antiga já não funciona. Investigue utilizações inesperadas com registos de auditoria limitados.
Teste os limites
Um teste de lançamento útil inclui uma operação permitida, uma operação proibida, uma chave expirada ou revogada e um pedido fora do limite de recursos da chave. A autenticação por si só não é autorização.
Política de chave candidata
O contrato API descreve até dez chaves ativas por conta, com finalidades nomeadas, expiração opcional e restrições de endereço de origem. Os escopos separam leitura, gestão de servidor, faturamento e controle total. Um fluxo de criação deve mostrar o segredo uma única vez e reter apenas uma representação de verificação adequadamente protegida.
Audite sem expor o pedido
Um registro de auditoria útil pode incluir identificador de chave, rota, horário e resultado sem reter senhas ou corpos de solicitação completos. O acesso ao registro ainda precisa de proteção. Defina retenção e exportação em vez de manter histórico operacional sensível indefinidamente.
Dê a cada automação a sua própria credencial
Um verificador de backup, um worker de implantação e uma integração de cobrança não devem compartilhar a mesma chave de acesso total. Nomeie uma chave para sua função, conceda o menor escopo e registre quem é o responsável por ela. Os grupos pretendidos são leitura, servidores, cobrança e total; o mapeamento exato de suas operações deve ser testado quando o API estiver disponível.
Criação, armazenamento e rotação
O modelo de conta proposto permite até dez chaves ativas. Mostre um novo segredo uma única vez e depois retenha apenas o verificador do lado do servidor necessário para autenticá-lo. Armazene a cópia do cliente em um gerenciador de segredos ou em um ambiente de serviço protegido. Faça a rotação introduzindo uma substituta, verificando o worker dependente e depois revogando a chave antiga; nunca coloque uma chave em um URL público ou em um pacote de navegador.
Revogue o acesso, não as evidências
Desativar uma chave deve impedir pedidos futuros, preservando um registo de segurança limitado da sua utilização passada. Se uma credencial pode ter sido exposta, revogue-a prontamente, examine os recursos afetados e substitua quaisquer segredos relacionados. Uma lista de chaves deve mostrar um identificador seguro e metadados de última utilização em vez de segredos em texto simples recuperáveis.
Um pouco mais de clareza.
Esta página consegue criar uma chave API funcional?
Não. A criação de chaves exige um backend de conta autenticado; esta página informativa não emite credenciais.