Faça um inventário da identidade de integração antes de girá-la
Uma conta de serviço ou credencial de API representa um caminho de acesso não interativo, não apenas uma string armazenada em um gerenciador de segredos. Antes de escrever um procedimento de rotação, identifique o proprietário da integração, o locatário permitido, as operações permitidas, cada consumidor e o fluxo de trabalho comercial que depende dele. Uma nova credencial com o escopo errado pode aumentar a exposição mesmo que a rotação em si seja concluída sem interrupção. Os requisitos devem, portanto, abordar os limites de acesso e o ciclo de vida em conjunto.
Este artigo propõe requisitos para integrações de plataforma de autenticação. Ele não afirma que EmailAuth oferece suporte a contas de serviço, chaves de API com escopo, credenciais sobrepostas ou qualquer integração específica de gerenciamento de segredos. Nenhuma credencial foi criada, exibida, transmitida, revogada ou testada. Diretrizes de identidade multilocatário do Azure suporta a separação da identidade da autorização e direitos de recursos; a plataforma real deve documentar seu próprio modelo de acesso não interativo suportado.
Defina a menor autoridade pretendida
Crie uma linha de inventário de integração contendo a identidade do serviço, a finalidade comercial, a vinculação do locatário, o escopo do recurso, as operações permitidas, o proprietário, os locais de implantação e a referência de credencial. Armazene apenas uma referência a um local secreto aprovado, não o valor da credencial. Distinguir relatórios somente leitura de exportações, gravações de configuração, gerenciamento de usuários e operações de faturamento. Uma ampla credencial administrativa não deve ser tratada como necessária apenas porque foi conveniente durante uma integração inicial.
Exija que a plataforma explique como a identidade autenticada está vinculada a um locatário e como cada operação verifica esse limite. Um parâmetro de locatário em uma URL ou corpo de solicitação não é uma autorização por si só. Uma credencial usada para um cliente não deve adquirir o escopo de outro cliente alterando um identificador. Estes são critérios de aceitação propostos; nenhum serviço ativo foi testado e nenhuma capacidade atual do produto foi inferida a partir do requisito.
Substituição separada de credenciais do redesenho de acesso
Uma rotação de rotina normalmente deveria preservar a autoridade aprovada enquanto substitui o material secreto. Se a migração também alterar funções, âmbito de inquilino ou acesso a recursos, reveja essas alterações explicitamente. Caso contrário, um procedimento descrito como manutenção pode ocultar uma expansão de acesso. Registre o escopo antigo e o novo pretendido usando identificadores não secretos e compare-os antes de qualquer transição autorizada.
Escolha o tipo de credencial compatível com base na documentação atual da plataforma e na política organizacional. Uma conta de serviço, chave de API, certificado ou identidade de carga de trabalho pode ter diferentes propriedades de emissão, expiração e revogação. Não presuma que toda integração oferece credenciais de curta duração ou que um gerenciador de segredos altera automaticamente a credencial no serviço de destino. O sistema alvo e cada consumidor devem ser coordenados de acordo com suas capacidades reais.
Rotação de sobreposição de escopo para sistemas que o suportam
Tutorial de rotação de credenciais duplas da Microsoft demonstra um padrão específico de Armazenamento do Azure e Key Vault usando duas credenciais. Ele explica um mecanismo para alternar credenciais durante a atualização do material secreto armazenado. Isso é uma evidência do cenário documentado do Azure, e não uma prova de que uma plataforma de autenticação arbitrária suporta duas chaves de API válidas simultaneamente ou a mesma sequência de rotação.
Quando a sobreposição é suportada, o plano proposto deve identificar a referência da credencial de substituição, os consumidores a migrar, a evidência de que cada consumidor utiliza a substituição e o ponto em que a credencial antiga é revogada. A sobreposição pode reduzir a interrupção, mas também deixa temporariamente mais de uma credencial utilizável. Vincule sua duração a um plano aprovado, em vez de deixar a antiga credencial ativa indefinidamente. Se a sobreposição não for suportada, documente a interrupção esperada e o caminho de recuperação autorizado em vez de prometer uma transição perfeita.
Verifique a migração antes de revogar o caminho antigo
Defina evidências que demonstrem o uso bem-sucedido da substituição sem expô-la. Dependendo do fornecedor real, isto pode incluir identificadores de credenciais não secretos em registos aprovados, observações de saúde de integração ou eventos de auditoria suportados. Uma solicitação bem-sucedida de um trabalhador não prova que todos os trabalhos agendados, trabalhadores em segundo plano ou ambientes de recuperação de desastres migraram. O inventário deve contabilizar cada consumidor ou documentar explicitamente a lacuna de cobertura.
A revogação é uma etapa separada com sua própria evidência de resultado. A remoção de um segredo da configuração de um aplicativo não prova que o serviço de destino o invalidou. Por outro lado, revogar a meta antes que todos os consumidores migrem pode interromper os fluxos de trabalho necessários. O respondente autorizado deve verificar a disposição do caminho antigo através de evidências apoiadas em um ambiente aprovado. Este rascunho não executa uma solicitação usando uma credencial antiga ou nova.
Planeje falhas e recuperação sem restaurar cegamente a exposição
Defina condições de interrupção antes da mudança: escopo inesperado do locatário, falta de evidências de auditoria, inventário incompleto do consumidor ou falhas após a migração podem exigir a pausa da transição. A recuperação deve distinguir um erro de implantação de rotina de uma suspeita de comprometimento de credenciais. A reutilização de um segredo comprometido conhecido como uma reversão conveniente pode reintroduzir a própria exposição contida. Exija uma decisão de segurança em vez de tratar todas as credenciais anteriores como material de restauração seguro.
Mantenha o plano livre de valores secretos. Logs e capturas de tela não devem revelar cabeçalhos de autorização, tokens ou cadeias de conexão completas. Se material sensível for acidentalmente exposto, encaminhe-o através do processo de incidentes da organização; não o copie para um canal de solução de problemas mais amplo. As evidências de rotação devem mostrar quem autorizou a ação, qual identidade não secreta foi alterada, quais consumidores foram verificados e o que o serviço alvo informa sobre a revogação.
Uma planilha de aceitação do ciclo de vida de credenciais
Crie uma planilha com identidade de integração, locatário, ações permitidas, referência secreta, lista de consumidores, identificador de credencial atual onde é seguro, estratégia de substituição, proprietário de aprovação, verificações de migração e verificações de revogação. Incluir o modelo de sobreposição suportado e a janela de sobreposição máxima planejada como uma decisão interna, e não como uma garantia inventada do fornecedor. Registre a versão real do fornecedor ou a data da documentação usada para projetar a sequência.
Anexe uma matriz de acesso que cubra leituras, exportações, gravações e operações de ciclo de vida permitidas e negadas em pelo menos dois dispositivos de locatário sintéticos. A rotação não deve alterar esses limites acidentalmente. Inclua uma verificação pós-rotação de que o acesso pretendido ainda funciona e o acesso não permitido permanece negado. São testes defensivos propostos, resultados não executados ou permissão para sondar um inquilino de produção. Mantenha todas as evidências operacionais originais marcadas como abertas até que uma execução autorizada as retenha.
Diagnóstico fictício: um trabalhador agendado esquecido
Uma integração de relatórios fictícia possui um trabalhador interativo e um trabalho de agregação noturno. A equipe atualiza o trabalhador interativo para uma credencial de substituição e vê solicitações bem-sucedidas. A credencial antiga está prestes a ser revogada quando a revisão do inventário revela que o trabalho agendado lê uma referência secreta separada. A verificação interativa bem-sucedida não abrangeu o consumidor noturno.
A resposta proposta é atualizar o plano de migração, obter qualquer aprovação necessária e verificar ambos os consumidores antes de concluir a revogação. Se houver suspeita de que a credencial antiga esteja comprometida, o proprietário do incidente poderá escolher a contenção imediata com uma interrupção controlada do serviço. Nenhuma credencial real, trabalhador ou interrupção foi envolvida neste exemplo fictício. Seu objetivo é distinguir a cobertura completa do consumidor de uma solicitação bem-sucedida.
Exigir a evidência da plataforma antes da publicação
Um requisito de integração útil nomeia tipos de credenciais suportadas, escopos, vinculação de locatário, autoridade de emissão, comportamento de sobreposição, expiração, revogação e evidências de auditoria. Ele deve indicar claramente as limitações, em vez de traduzir um tutorial geral sobre nuvem em uma reivindicação de recurso EmailAuth . As configurações de demonstração do tutorial de origem não são intervalos de rotação universais ou políticas organizacionais.
O catálogo requer uma matriz de acesso e testes negativos para leituras, exportações, gravações e alterações no ciclo de vida do usuário entre locatários. Esses testes permanecem não realizados. A revisão de especialistas humanos, a aplicabilidade da fonte, as rotas de produção, a acessibilidade e a liberação do proprietário também permanecem em aberto. Este rascunho fornece um modelo operacional proposto e um exercício fictício, e não credenciais, concessões de acesso ou evidências de uma rotação concluída.