Planita tasko aŭ homa saluto: kiun identecon la API devas vidi?

Planita tasko kaj persono ĉe saluta prompto vokas la saman API per malsamaj legitimiloj, malsamaj vivoj kaj malsamaj posedantoj. La tasko bezonas retan vojon, aplikaĵan identecon kaj aron da permesoj; la persono bezonas saluton, duan faktoron kaj seancon. Miksi la du kreas aŭtomatigon, kiu rompiĝas ĉiufoje kiam la pasvorto de la persono ŝanĝiĝas, aŭ plurfaktoran politikon malfortigitan ĝuste tiom, ke cron-tasko restu viva.

Tri pordegoj, kiuj aspektas kiel unu

Regulo pri fonta adreso demandas, de kie venis la peto. Aŭtentigo demandas, kiu alvokas kaj kiuj pruvoj estis prezentitaj. Rajtigo demandas, ĉu tiu ĉi principulo rajtas plenumi tiun ĉi operacion. VPN ŝanĝas nur la unuan el la tri, kaj ĝi ŝanĝas ĝin por ĉiu procezo sur la gastiganto, ne nur por la tasko, do tenu la tri observojn aparte en la incidenta registro.

Tial ŝanĝi la eliran nodon povas ripari rifuzon pro fonta adreso kaj lasi nevalidan ĵetonon netuŝita. Tial ankaŭ valida API-ĵetono ne faras privatan finpunkton atingebla el tasko sen vojo al ĝi.

La interaga vojo estas malbona ŝablono por aŭtomatigo

Sktipti la saluton de persono tentas, ĉar ĝi funkcias unufoje. La skripto konservas pasvorton, eble semon de unufoja pasvorto, kaj poste dependas de defio desegnita postuli homon. La nuna plej bona sekureca praktiko por OAuth, RFC 9700, malpermesas la permeson resource-owner-password-credentials kaj klarigas, kial ĝi malbone taŭgas por dufaktora kaj plurpaŝa aŭtentigo.

La subtenata alternativo kutime estas fluo de konfida kliento, en kiu la rajtiga servilo aŭtentigas la aplikaĵon kaj eldonas ĵetonon. La permeso client-credentials en RFC 6749 sekcio 4.4 estas unu ekzemplo. Ĝia ekzisto ne signifas, ke ĉiu API akceptas ĝin, nek ke uzanto-delegita tasko povas esti anstataŭigita per ĝi, ĉar tiuj estas demandoj por la serva posedanto. Demandu, kiun senhoman modelon la servo subtenas, antaŭ ol verki ajnan kodon.

Kie VPN ankoraŭ apartenas

VPN povas provizi la retan vojon, kiun privata API postulas, kaj tio estas legitima rolo. Ĝi ne aŭtentigas la taskon al la aplikaĵo, kaj ĝi ne difinas, kion la tasko rajtas fari. Komunigita elira adreso ankaŭ identigas la gastiganton, ne la taskon, do list-ero de permesitaj por tiu adreso enlasas ĉiun procezon funkciantan sur ĝi.

Se la tasko funkcias sur komunigita plenumilo, tiu distingo gravas pli, ne malpli. Alia laborfluo sur la sama gastiganto heredas la vojon kaj la adreson, kaj la API ne povas distingi la du. Tio estas la sama malforto kiel komunigita pasvorto, movita unu tavolon malsupren. Metu la limigon tie, kie la aplikaĵo povas ĝin devigi, kaj izolu la plenumilon, se vi ne povas pli mallarĝigi la permesitan liston.

Komparu la du dezajnojn honeste

Homa saluto donas al vi realan personon, realan duan faktoron kaj revideblan seancon, kaj ĝi ne povas funkcii senhoma. Aplikaĵa identeco donas al vi senhoman plenumon, revideblan amplekson kaj legitimilon, kiun vi povas rotacii, kaj ĝi ne povas agi por uzanto, kiu delegis nenion. Neniu estas malforta versio de la alia; ili respondas al malsamaj demandoj. Elektu demandante, ĉu la tasko devas funkcii sen iu ĉeestanta, kaj ĉu la operacio devas esti atribuata al specifa uzanto.

Se ambaŭ respondoj estas jes, la dezajno bezonas delegadan modelon, ne pruntitan pasvorton. Skribu tiun decidon tie, kie la sekva prizorganto trovos ĝin.

Kion kontroli antaŭ transdono

Rulu unu permesitan operacion kaj unu postulatan rifuzon de la reala laboranto, kaj konservu ambaŭ rezultojn. Poste testu eksvalidiĝintan legitimilon kaj la konduton, kiam la reta vojo ne estas disponebla, ĉar tiuj estas la du paneoj, kiuj vekas iun nokte.

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

Notu la principulon, la amplekson, la rotacian posedanton kaj la plenummedian apud tiu rezulto. Tiu registro estas tio, kio faras la sekvan rotacion rutino anstataŭ incidento. Ĝi ankaŭ estas la parto, kiun petas revizoro.