Desativar a chave de API de um provedor antigo parece uma etapa pequena, quase administrativa, no fim de uma migração, mas errar o momento em qualquer direção tem um custo real. Desative cedo demais, antes que todos os sistemas dependentes tenham realmente migrado, e algo que ainda chama a chave antiga quebra inesperadamente. Desative tarde demais, ou nunca, e uma credencial sem uso, mas ainda válida, fica parada como um risco de segurança que ninguém está vigiando ativamente.
O processo mais seguro trata a desativação da chave como um pequeno projeto próprio, com uma sequência definida, e não como algo secundário acrescentado ao fim do trabalho principal da migração:
Primeiro, confirme que não há tráfego na chave antiga, e não apenas a crença de que a migração está concluída. A maioria dos provedores oferece alguma visibilidade de uso para uma determinada chave; verifique isso diretamente, em vez de presumir que o checklist de migração marcado como concluído significa que a chave antiga realmente parou de ser usada na prática.
Deixe a chave antiga válida, mas sem uso, durante uma janela de observação definida depois que você acreditar que a migração está concluída, em vez de desativá-la no momento em que o novo provedor entra no ar. Essa janela, normalmente de algumas semanas, dependendo dos seus padrões de tráfego e ciclos de lançamento, captura qualquer ponto de chamada esquecido, atualização atrasada de aplicativo móvel ou tarefa em lote executada com pouca frequência que ainda faça referência à credencial antiga.
Primeiro desative a chave antiga em vez de excluí-la, se o seu provedor fizer essa distinção. Uma chave desativada que ainda existe como registro é mais fácil de reativar temporariamente se algo inesperado aparecer do que uma totalmente excluída, o que dá a você uma margem de segurança durante a janela de observação sem estendê-la indefinidamente.
Exclua ou revogue totalmente a chave antiga em uma data específica e decidida, e documente que isso foi feito. Uma chave desativada indefinidamente continua sendo uma superfície de ataque que alguém poderia reativar se a própria conta for comprometida algum dia; uma credencial realmente aposentada deve acabar sendo removida de vez, e não deixada em um limbo permanente.
Audite onde a chave antiga estava armazenada, incluindo sistemas de gerenciamento de configuração, gerenciadores de segredos, arquivos de variáveis de ambiente e qualquer documentação ou material de integração de novos membros que possa fazer referência a ela, já que uma chave aposentada que continua anotada em algum lugar como "a chave de API" gera confusão para quem ler essa documentação em seguida, muito depois de a própria chave ter parado de funcionar.
Em uma migração para o My Geocode, a nova chave pode ser delimitada e monitorada desde o primeiro dia usando os cabeçalhos de cota presentes em cada resposta, X-Quota-Used, X-Key-IPs-Used e outros documentados em /docs/rate-limits/, o que facilita confirmar que a nova chave está realmente recebendo o tráfego esperado antes de começar a contagem para aposentar a antiga. Tratar a desativação de credenciais com esse nível de cuidado é um pequeno processo extra em troca de uma redução significativa tanto do risco operacional quanto da exposição de segurança remanescente.
Automações no-code construídas sobre uma etapa de geocodificação exigem uma abordagem de migração diferente da usada em código próprio. Veja como lidar com essa troca.
Trocar de fornecedor de dados de localização não é apenas uma decisão técnica. Veja o que revisar do lado do processamento de dados e da privacidade nessa mudança.