Tarefa programada ou inicio de sesión humano: que identidade debe ver a API?

Unha tarefa programada e unha persoa diante dun indicador de inicio de sesión chaman á mesma API con credenciais distintas, vidas distintas e propietarios distintos. A tarefa necesita un camiño de rede, unha identidade de aplicación e un conxunto de permisos; a persoa necesita un inicio de sesión, un segundo factor e unha sesión. Mesturar ambos produce unha automatización que rompe cada vez que cambia o contrasinal da persoa, ou unha política multifactor debilitada xusto o suficiente para manter viva unha tarefa cron.

Tres portas que parecen unha soa

Unha regra de enderezo de orixe pregunta de onde veu a solicitude. A autenticación pregunta quen chama e que probas se presentaron. A autorización pregunta se este suxeito pode realizar esta operación. Unha VPN só cambia a primeira das tres, e cámbiaa para cada proceso do host e non só para a tarefa, así que manteña as tres observacións separadas no rexistro do incidente.

Por iso cambiar o nodo de saída pode corrixir un rexeitamento por enderezo de orixe e deixar intacto un token inválido. Tamén por iso un token de API válido non fai que un extremo privado sexa alcanzable desde unha tarefa que non ten ruta cara a el.

O camiño interactivo é unha mala plantilla de automatización

Programar o inicio de sesión dunha persoa é tentador porque funciona unha vez. O script almacena un contrasinal, quizais unha semente de contrasinal dun só uso, e despois depende dun desafío deseñado para esixir un humano. A mellor práctica actual de seguridade de OAuth, a RFC 9700, prohibe a concesión resource-owner-password-credentials e explica por que encaixa mal coa autenticación de dous factores e de varios pasos.

A alternativa admitida adoita ser un fluxo de cliente confidencial no que o servidor de autorización autentica a aplicación e emite un token. A concesión client-credentials da RFC 6749, sección 4.4, é un exemplo. Que exista non significa que toda API a acepte, nin que unha tarefa delegada por un usuario poida substituírse por ela, porque esas son preguntas para o propietario do servizo. Pregunte que modelo sen supervisión admite o servizo antes de escribir código.

Onde segue encaixando a VPN

Unha VPN pode proporcionar o camiño de rede que esixe unha API privada, e ese é un papel lexítimo. Non autentica a tarefa ante a aplicación nin delimita que pode facer a tarefa. Un enderezo de saída compartido tamén identifica o host e non a tarefa, así que unha entrada na lista de permitidos para ese enderezo admite cada proceso que se execute nel.

Se a tarefa se executa nun runner compartido, esa distinción importa máis, non menos. Outro fluxo de traballo no mesmo host herda a ruta e o enderezo, e a API non pode distinguir os dous. É a mesma debilidade ca un contrasinal compartido, desprazada unha capa abaixo. Pon a restrición onde a aplicación poida impoñela, e illa o runner se non pode acoutar máis a lista de permitidos.

Compare os dous deseños con honestidade

Un inicio de sesión humano dálle unha persoa real, un segundo factor real e unha sesión auditable, e non pode executarse sen supervisión. Unha identidade de aplicación dálle execución sen supervisión, un alcance revisable e unha credencial que pode rotar, e non pode actuar por un usuario que non delegou nada. Ningún é unha versión máis débil do outro; responden a preguntas distintas. Escolla preguntando se a tarefa debe executarse sen ninguén presente e se a operación debe atribuírse a un usuario concreto.

Se ambas as respostas son si, o deseño necesita un modelo de delegación e non un contrasinal prestado. Escriba esa decisión onde a atope o próximo responsable de mantemento.

Que verificar antes da entrega

Execute unha operación permitida e unha denegación obrigatoria desde o traballador real, e conserve ambos os resultados. Despois probe unha credencial caducada e o comportamento cando o camiño de rede non está dispoñible, porque esas son as dúas fallas que espertan a alguén pola noite.

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

Anote o suxeito, o alcance, o propietario da rotación e a contorna de execución xunto a ese resultado. Ese rexistro é o que converte a seguinte rotación en rutina e non en incidente. Tamén é a parte que pide un auditor.