Attività pianificata o accesso umano: quale identità deve vedere l’API?

Un’attività pianificata e una persona davanti a una richiesta di accesso chiamano la stessa API con credenziali diverse, durate diverse e proprietari diversi. L’attività ha bisogno di un percorso di rete, di un’identità dell’applicazione e di un insieme di permessi; la persona ha bisogno di un accesso, di un secondo fattore e di una sessione. Mescolare le due cose produce un’automazione che si rompe ogni volta che cambia la password della persona, oppure una politica multifattore indebolita quanto basta per tenere in vita un job cron.

Tre cancelli che sembrano uno solo

Una regola sull’indirizzo di origine chiede da dove è arrivata la richiesta. L’autenticazione chiede chi sta chiamando e quali prove sono state presentate. L’autorizzazione chiede se questo soggetto può eseguire questa operazione. Una VPN cambia solo la prima delle tre, e la cambia per ogni processo dell’host e non solo per l’attività, quindi tenete separate le tre osservazioni nel verbale dell’incidente.

Per questo cambiare il nodo di uscita può correggere un rifiuto dovuto all’indirizzo di origine e lasciare intatto un token non valido. Per questo un token API valido non rende raggiungibile un endpoint privato da un’attività che non ha una rotta verso di esso.

Il percorso interattivo è un cattivo modello di automazione

Scrivere in uno script l’accesso di una persona è tentante perché funziona una volta. Lo script memorizza una password, forse un seme di password monouso, e poi dipende da una sfida progettata per richiedere un umano. La migliore pratica di sicurezza attuale per OAuth, la RFC 9700, vieta la concessione resource-owner-password-credentials e spiega perché si adatta male all’autenticazione a due fattori e a più passaggi.

L’alternativa supportata è di solito un flusso di client riservato in cui il server di autorizzazione autentica l’applicazione ed emette un token. La concessione client-credentials della RFC 6749, sezione 4.4, ne è un esempio. La sua esistenza non significa che ogni API la accetti, né che un’attività delegata da un utente possa essere sostituita da essa, perché queste sono domande per il proprietario del servizio. Chiedete quale modello senza supervisione supporta il servizio prima di scrivere codice.

Dove la VPN ha ancora senso

Una VPN può fornire il percorso di rete richiesto da un’API privata, e questo è un ruolo legittimo. Non autentica l’attività verso l’applicazione e non delimita ciò che l’attività può fare. Un indirizzo di uscita condiviso identifica anche l’host e non l’attività, quindi una voce nella lista di autorizzazione per quell’indirizzo ammette ogni processo che vi viene eseguito.

Se l’attività viene eseguita su un runner condiviso, questa distinzione conta di più, non di meno. Un altro flusso di lavoro sullo stesso host eredita la rotta e l’indirizzo, e l’API non può distinguere i due. È la stessa debolezza di una password condivisa, spostata di un livello più in basso. Mettete la restrizione dove l’applicazione può imporla, e isolate il runner se non potete restringere ulteriormente la lista di autorizzazione.

Confrontate i due progetti con onestà

Un accesso umano vi dà una persona reale, un secondo fattore reale e una sessione verificabile, e non può funzionare senza supervisione. Un’identità dell’applicazione vi dà esecuzione senza supervisione, un ambito verificabile e una credenziale che potete ruotare, e non può agire per un utente che non ha delegato nulla. Nessuna delle due è una versione più debole dell’altra; rispondono a domande diverse. Scegliete chiedendovi se l’attività deve funzionare senza nessuno presente e se l’operazione deve essere attribuita a un utente specifico.

Se entrambe le risposte sono sì, il progetto ha bisogno di un modello di delega e non di una password presa in prestito. Scrivete quella decisione dove la troverà il prossimo manutentore.

Cosa verificare prima della consegna

Eseguite un’operazione consentita e un rifiuto obbligatorio dal worker reale, e conservate entrambi i risultati. Poi provate una credenziale scaduta e il comportamento quando il percorso di rete non è disponibile, perché sono i due guasti che svegliano qualcuno di notte.

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

Annotate il soggetto, l’ambito, il proprietario della rotazione e l’ambiente di esecuzione accanto a quel risultato. È quella registrazione che rende la rotazione successiva una routine e non un incidente. È anche la parte che un revisore chiede.