Tarefa agendada ou login humano: qual identidade a API deve ver?

Uma tarefa agendada e uma pessoa num prompt de login chamam a mesma API com credenciais diferentes, tempos de vida diferentes e proprietários diferentes. A tarefa precisa de um caminho de rede, de uma identidade de aplicação e de um conjunto de permissões; a pessoa precisa de um login, de um segundo fator e de uma sessão. Misturar as duas coisas produz uma automação que se quebra sempre que a palavra-passe da pessoa muda, ou uma política multifator enfraquecida apenas o suficiente para manter uma tarefa cron viva.

Três portões que parecem um só

Uma regra de endereço de origem pergunta de onde veio o pedido. A autenticação pergunta quem está a chamar e que provas foram apresentadas. A autorização pergunta se este sujeito pode realizar esta operação. Uma VPN altera apenas o primeiro dos três, e altera-o para todos os processos do anfitrião e não só para a tarefa, por isso mantenha as três observações separadas no registo do incidente.

É por isso que mudar o nó de saída pode corrigir uma rejeição por endereço de origem e deixar intacto um token inválido. É também por isso que um token de API válido não torna um endpoint privado alcançável a partir de uma tarefa que não tem rota até ele.

O caminho interativo é um mau modelo de automação

Escrever o login de uma pessoa num script é tentador porque funciona uma vez. O script guarda uma palavra-passe, talvez uma semente de palavra-passe de uso único, e depois depende de um desafio concebido para exigir um humano. A atual melhor prática de segurança do OAuth, a RFC 9700, proíbe a concessão resource-owner-password-credentials e explica porque se adequa mal à autenticação de dois fatores e de vários passos.

A alternativa suportada é normalmente um fluxo de cliente confidencial em que o servidor de autorização autentica a aplicação e emite um token. A concessão client-credentials da RFC 6749, secção 4.4, é um exemplo. A sua existência não significa que todas as APIs a aceitem, nem que uma tarefa delegada por um utilizador possa ser substituída por ela, porque essas são perguntas para o proprietário do serviço. Pergunte que modelo sem supervisão o serviço suporta antes de escrever código.

Onde a VPN ainda pertence

Uma VPN pode fornecer o caminho de rede que uma API privada exige, e esse é um papel legítimo. Não autentica a tarefa perante a aplicação e não delimita o que a tarefa pode fazer. Um endereço de saída partilhado também identifica o anfitrião e não a tarefa, pelo que uma entrada na lista de permissões para esse endereço admite todos os processos que nele correm.

Se a tarefa corre num runner partilhado, essa distinção importa mais e não menos. Outro fluxo de trabalho no mesmo anfitrião herda a rota e o endereço, e a API não consegue distingui-los. É a mesma fraqueza de uma palavra-passe partilhada, deslocada um nível abaixo. Coloque a restrição onde a aplicação a pode impor, e isole o runner se não conseguir restringir mais a lista de permissões.

Compare os dois desenhos com honestidade

Um login humano dá-lhe uma pessoa real, um segundo fator real e uma sessão auditável, e não consegue correr sem supervisão. Uma identidade de aplicação dá-lhe execução sem supervisão, um âmbito verificável e uma credencial que pode rodar, e não consegue agir por um utilizador que não delegou nada. Nenhum é uma versão mais fraca do outro; respondem a perguntas diferentes. Escolha perguntando se a tarefa tem de correr sem ninguém presente e se a operação tem de ser atribuída a um utilizador específico.

Se ambas as respostas forem sim, o desenho precisa de um modelo de delegação e não de uma palavra-passe emprestada. Escreva essa decisão onde o próximo responsável de manutenção a encontre.

O que verificar antes da entrega

Execute uma operação permitida e uma negação obrigatória a partir do trabalhador real, e guarde os dois resultados. Depois teste uma credencial expirada e o comportamento quando o caminho de rede não está disponível, porque são essas as duas falhas que acordam alguém a meio da noite.

curl -sS -o /dev/null -w '%{http_code}\n' \
  -H "Authorization: Bearer TOKEN" https://api.example.com/v1/records

Registe o sujeito, o âmbito, o proprietário da rotação e o ambiente de execução junto a esse resultado. É esse registo que torna a rotação seguinte rotina e não incidente. É também a parte que um auditor pede.