Plānots darbs vai cilvēka pieteikšanās: kādu identitāti API ir jāredz?

Plānots darbs un cilvēks pie pieteikšanās uzvednes izsauc vienu un to pašu API ar atšķirīgiem akreditācijas datiem, atšķirīgu dzīves ilgumu un atšķirīgiem īpašniekiem. Darbam vajadzīgs tīkla ceļš, lietojumprogrammas identitāte un atļauju kopa; cilvēkam vajadzīga pieteikšanās, otrais faktors un sesija. Abu sajaukšana rada automatizāciju, kas salūzt ikreiz, kad mainās cilvēka parole, vai daudzfaktoru politiku, kas vājināta tieši tik daudz, lai cron darbs paliktu dzīvs.

Trīs vārti, kas izskatās kā vieni

Avota adreses noteikums jautā, no kurienes nāca pieprasījums. Autentifikācija jautā, kas zvana un kādi pierādījumi tika uzrādīti. Autorizācija jautā, vai šis subjekts drīkst veikt šo darbību. VPN maina tikai pirmo no trim un maina to katram procesam uz resursdatora, nevis tikai darbam, tāpēc incidenta ierakstā turiet trīs novērojumus atsevišķi.

Tāpēc izejas mezgla maiņa var izlabot noraidījumu avota adreses dēļ un atstāt nederīgu pilnvaru neskartu. Tāpēc arī derīga API pilnvara nepadara privātu galapunktu sasniedzamu no darba, kuram uz to nav maršruta.

Interaktīvais ceļš ir slikta automatizācijas veidne

Cilvēka pieteikšanās skriptēšana ir vilinoša, jo tā darbojas vienu reizi. Skripts saglabā paroli, varbūt vienreizējas paroles sēklu, un pēc tam ir atkarīgs no izaicinājuma, kas veidots, lai prasītu cilvēku. Pašreizējā labākā OAuth drošības prakse, RFC 9700, aizliedz resource-owner-password-credentials piešķīrumu un skaidro, kāpēc tas slikti atbilst divfaktoru un vairāku soļu autentifikācijai.

Atbalstītā alternatīva parasti ir konfidenciāla klienta plūsma, kurā autorizācijas serveris autentificē lietojumprogrammu un izdod pilnvaru. RFC 6749 4.4 sadaļas client-credentials piešķīrums ir viens piemērs. Tā pastāvēšana nenozīmē, ka katrs API to pieņem, vai ka lietotāja deleģētu uzdevumu ar to var aizstāt, jo tie ir jautājumi pakalpojuma īpašniekam. Pajautājiet, kādu bez uzraudzības modeli pakalpojums atbalsta, pirms rakstīt kodu.

Kur VPN joprojām iederas

VPN var nodrošināt tīkla ceļu, ko prasa privāts API, un tā ir likumīga loma. Tas neautentificē darbu lietojumprogrammai un nenosaka, ko darbs drīkst darīt. Koplietota izejas adrese arī identificē resursdatoru, nevis darbu, tāpēc atļauto saraksta ieraksts šai adresei ielaiž katru tajā strādājošo procesu.

Ja darbs darbojas koplietotā runnerī, šī atšķirība ir svarīgāka, nevis mazāk svarīga. Cita darbplūsma tajā pašā resursdatorā manto maršrutu un adresi, un API nevar tās atšķirt. Tā ir tā pati vājība kā koplietota parole, pārvietota vienu slāni zemāk. Novietojiet ierobežojumu tur, kur lietojumprogramma var to īstenot, un izolējiet runneri, ja nevarat sašaurināt atļauto sarakstu.

Salīdziniet abus risinājumus godīgi

Cilvēka pieteikšanās dod īstu cilvēku, īstu otro faktoru un auditējamu sesiju, un tā nevar darboties bez uzraudzības. Lietojumprogrammas identitāte dod izpildi bez uzraudzības, pārskatāmu apjomu un akreditācijas datus, ko varat rotēt, un tā nevar rīkoties lietotāja vārdā, kurš neko nav deleģējis. Neviens nav otra vājāka versija; tie atbild uz dažādiem jautājumiem. Izvēlieties, jautājot, vai darbam jādarbojas bez neviena klātbūtnes un vai darbība jāattiecina uz konkrētu lietotāju.

Ja abas atbildes ir jā, risinājumam vajadzīgs deleģēšanas modelis, nevis aizņemta parole. Pierakstiet šo lēmumu tur, kur to atradīs nākamais uzturētājs.

Kas jāpārbauda pirms nodošanas

Izpildiet vienu atļautu darbību un vienu obligātu noraidījumu no īstā darbinieka, un saglabājiet abus rezultātus. Pēc tam pārbaudiet beigušos akreditācijas datus un uzvedību, kad tīkla ceļš nav pieejams, jo tie ir divi bojājumi, kas naktī pamodina kādu.

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

Pierakstiet subjektu, apjomu, rotācijas īpašnieku un izpildes vidi blakus šim rezultātam. Šis ieraksts ir tas, kas padara nākamo rotāciju par rutīnu, nevis incidentu. Tā ir arī daļa, ko pieprasa auditors.