Geskeduleerde taak of menslike aanmelding: watter identiteit moet die API sien?

’n Geskeduleerde taak en ’n persoon by ’n aanmeldingsprompt roep dieselfde API met verskillende geloofsbriewe, verskillende leeftye en verskillende eienaars. Die taak benodig ’n netwerkpad, ’n toepassingsidentiteit en ’n stel toestemmings; die persoon benodig ’n aanmelding, ’n tweede faktor en ’n sessie. Om die twee te vermeng lewer outomatisering wat breek wanneer die persoon se wagwoord verander, of ’n multifaktorbeleid wat net genoeg verswak word om ’n cron-taak aan die lewe te hou.

Drie hekke wat soos een lyk

’n Bronadresreël vra waar die versoek vandaan kom. Verifikasie vra wie bel en watter bewyse aangebied is. Magtiging vra of hierdie prinsipaal hierdie bewerking mag uitvoer. ’n VPN verander net die eerste van die drie, en dit verander dit vir elke proses op die gasheer eerder as net vir die taak, so hou die drie waarnemings apart in die insidentverslag.

Dit is waarom die verandering van die uitgangsnodus ’n bronadresverwerping kan oplos en ’n ongeldige token onaangeraak kan laat. Dit is ook waarom ’n geldige API-token nie ’n private eindpunt bereikbaar maak vir ’n taak sonder ’n roete daarheen nie.

Die interaktiewe pad is ’n swak outomatiseringsjabloon

Om ’n persoon se aanmelding te skrip is aanloklik omdat dit een keer werk. Die skrip stoor ’n wagwoord, miskien ’n eenmalige-wagwoordgroep, en dan maak dit staat op ’n uitdaging wat ontwerp is om ’n mens te vereis. Die OAuth-sekuriteitbestehuidigepraktyk, RFC 9700, verbied die resource-owner-password-credentials-toekenning en verduidelik waarom dit swak by tweefaktor- en meervoudigestap-verifikasie pas.

Die ondersteunde alternatief is gewoonlik ’n vertroulike-kliënt-vloei waarin die magtigingsbediener die toepassing verifieer en ’n token uitreik. Die client-credentials-toekenning in RFC 6749 afdeling 4.4 is een voorbeeld. Die bestaan daarvan beteken nie dat elke API dit aanvaar nie, of dat ’n gebruikersgedelegeerde taak daardeur vervang kan word nie, want dit is vrae vir die diens-eienaar. Vra watter onbewaakte model die diens ondersteun voordat jy enige kode skryf.

Waar die VPN steeds hoort

’n VPN kan die netwerkpad verskaf wat ’n private API vereis, en dit is ’n wettige rol. Dit verifieer nie die taak by die toepassing nie, en dit bepaal nie die omvang van wat die taak mag doen nie. ’n Gedeelde uitgangsadres identifiseer ook die gasheer eerder as die taak, so ’n toelatingslys-inskrywing vir daardie adres laat elke proses toe wat daarop loop.

As die taak op ’n gedeelde hardloper loop, maak daardie onderskeid meer eerder as minder saak. ’n Ander werkstroom op dieselfde gasheer erf die roete en die adres, en die API kan die twee nie onderskei nie. Dit is dieselfde swakheid as ’n gedeelde wagwoord, een laag afgeskuif. Plaas die beperking waar die toepassing dit kan afdwing, en isoleer die hardloper as jy die toelatingslys nie nouer kan beperk nie.

Vergelyk die twee ontwerpe eerlik

’n Menslike aanmelding gee jou ’n werklike persoon, ’n werklike tweede faktor en ’n ouditeerbare sessie, en dit kan nie onbewaak loop nie. ’n Toepassingsidentiteit gee jou onbewaakte uitvoering, ’n hersienbare omvang en ’n geloofsbewys wat jy kan roteer, en dit kan nie optree vir ’n gebruiker wat niks gedelegeer het nie. Nie een is ’n swakker weergawe van die ander nie; hulle beantwoord verskillende vrae. Kies deur te vra of die taak sonder iemand teenwoordig moet loop, en of die bewerking aan ’n spesifieke gebruiker toegeskryf moet word.

As albei antwoorde ja is, het die ontwerp ’n delegeringsmodel nodig eerder as ’n geleende wagwoord. Skryf daardie besluit neer waar die volgende instandhouer dit sal vind.

Wat om voor oorhandiging te verifieer

Voer een toegelate bewerking en een vereiste weiering vanaf die werklike werker uit, en hou albei resultate. Toets dan ’n vervalde geloofsbewys en die gedrag wanneer die netwerkpad onbeskikbaar is, want dit is die twee mislukkings wat iemand snags wakker maak.

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

Teken die prinsipaal, die omvang, die rotasie-eienaar en die uitvoeringsomgewing langs daardie resultaat aan. Daardie rekord is wat die volgende rotasie roetine maak eerder as ’n insident. Dit is ook die deel waarvoor ’n ouditeur vra.