Sarcină programată sau autentificare umană: ce identitate ar trebui să vadă API-ul?

O sarcină programată și o persoană la promptul de autentificare apelează același API cu acreditări diferite, durate de viață diferite și proprietari diferiți. Sarcina are nevoie de o cale de rețea, de o identitate a aplicației și de un set de permisiuni; persoana are nevoie de o autentificare, de un al doilea factor și de o sesiune. Amestecarea celor două produce o automatizare care se rupe de fiecare dată când se schimbă parola persoanei, sau o politică cu mai mulți factori slăbită exact atât cât să țină în viață o sarcină cron.

Trei porți care par una singură

O regulă de adresă sursă întreabă de unde a venit cererea. Autentificarea întreabă cine apelează și ce dovezi au fost prezentate. Autorizarea întreabă dacă acest subiect poate efectua această operațiune. Un VPN schimbă doar prima dintre cele trei și o schimbă pentru fiecare proces de pe gazdă, nu doar pentru sarcină, așa că țineți cele trei observații separate în registrul incidentului.

De aceea schimbarea nodului de ieșire poate remedia o respingere din cauza adresei sursă și poate lăsa neatins un token invalid. De aceea un token API valid nu face un punct final privat accesibil dintr-o sarcină care nu are rută către el.

Calea interactivă este un șablon slab de automatizare

Scrierea autentificării unei persoane într-un script este tentantă pentru că funcționează o dată. Scriptul stochează o parolă, poate o sămânță de parolă de unică folosință, iar apoi depinde de o provocare concepută să ceară un om. Cea mai bună practică actuală de securitate pentru OAuth, RFC 9700, interzice acordarea resource-owner-password-credentials și explică de ce se potrivește prost cu autentificarea cu doi factori și cu mai mulți pași.

Alternativa acceptată este de obicei un flux de client confidențial în care serverul de autorizare autentifică aplicația și emite un token. Acordarea client-credentials din RFC 6749, secțiunea 4.4, este un exemplu. Existența ei nu înseamnă că fiecare API o acceptă, nici că o sarcină delegată de un utilizator poate fi înlocuită cu ea, pentru că acestea sunt întrebări pentru proprietarul serviciului. Întrebați ce model fără supraveghere acceptă serviciul înainte de a scrie cod.

Unde VPN-ul încă își are locul

Un VPN poate furniza calea de rețea cerută de un API privat, iar acesta este un rol legitim. Nu autentifică sarcina față de aplicație și nu delimitează ce poate face sarcina. O adresă de ieșire partajată identifică și gazda, nu sarcina, așa că o intrare în lista de permisiuni pentru acea adresă admite fiecare proces care rulează pe ea.

Dacă sarcina rulează pe un runner partajat, această distincție contează mai mult, nu mai puțin. Un alt flux de lucru pe aceeași gazdă moștenește ruta și adresa, iar API-ul nu le poate distinge. Este aceeași slăbiciune ca o parolă partajată, coborâtă un nivel mai jos. Puneți restricția acolo unde aplicația o poate impune și izolați runner-ul dacă nu puteți restrânge lista de permisiuni.

Comparați cele două proiecte cu onestitate

O autentificare umană vă oferă o persoană reală, un al doilea factor real și o sesiune auditabilă, și nu poate rula fără supraveghere. O identitate a aplicației vă oferă execuție fără supraveghere, un domeniu verificabil și o acreditare pe care o puteți roti, și nu poate acționa pentru un utilizator care nu a delegat nimic. Niciuna nu este o versiune mai slabă a celeilalte; răspund la întrebări diferite. Alegeți întrebând dacă sarcina trebuie să ruleze fără nimeni prezent și dacă operațiunea trebuie atribuită unui utilizator anume.

Dacă ambele răspunsuri sunt da, proiectul are nevoie de un model de delegare, nu de o parolă împrumutată. Scrieți acea decizie acolo unde o va găsi următorul responsabil de mentenanță.

Ce de verificat înainte de predare

Rulați o operațiune permisă și o respingere obligatorie de la workerul real și păstrați ambele rezultate. Apoi testați o acreditare expirată și comportamentul când calea de rețea nu este disponibilă, pentru că acestea sunt cele două defecțiuni care trezesc pe cineva noaptea.

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

Notați subiectul, domeniul, proprietarul rotației și mediul de execuție lângă acel rezultat. Acea înregistrare este ce face următoarea rotație o rutină și nu un incident. Este și partea pe care o cere un auditor.