Заказани посао или људска пријава: који идентитет API треба да види?

Заказани посао и особа пред екраном за пријаву позивају исти API са различитим акредитивима, различитим трајањем и различитим власницима. Послу је потребан мрежни пут, идентитет апликације и скуп дозвола; особи је потребна пријава, други фактор и сесија. Мешање тога двоје ствара аутоматизацију која се квари кад год се промени лозинка особе, или политику више фактора ослабљену таман толико да cron посао остане жив.

Три капије које изгледају као једна

Правило изворишне адресе пита одакле је захтев дошао. Аутентификација пита ко зове и који су докази представљени. Ауторизација пита сме ли овај субјекат да изврши ову операцију. VPN мења само прву од три и мења је за сваки процес на хосту, а не само за посао, зато три запажања држите одвојено у запису о инциденту.

Зато промена излазног чвора може да поправи одбијање због изворишне адресе и остави неважећи токен нетакнут. Зато и важећи API токен не чини приватну крајњу тачку доступном из посла који до ње нема руту.

Интерактивни пут је лош шаблон за аутоматизацију

Скриптирање људске пријаве је примамљиво јер ради једном. Скрипта чува лозинку, можда и семе једнократне лозинке, а затим зависи од изазова осмишљеног да захтева човека. Најбоља тренутна безбедносна пракса за OAuth, RFC 9700, забрањује доделу resource-owner-password-credentials и објашњава зашто се лоше уклапа у двофакторску и вишекорачну аутентификацију.

Подржана алтернатива обично је ток поверљивог клијента у ком сервер за ауторизацију аутентификује апликацију и издаје токен. Додела client-credentials из RFC 6749, одељак 4.4, један је пример. Њено постојање не значи да је сваки API прихвата, ни да се задатак делегиран од корисника њоме може заменити, јер су то питања за власника услуге. Питајте који модел без надзора услуга подржава пре него што напишете код.

Где VPN још има место

VPN може да обезбеди мрежни пут који приватни API захтева, и то је легитимна улога. Он не аутентификује посао пред апликацијом и не одређује обим онога што посао сме да ради. Дељена излазна адреса такође идентификује хост, а не посао, па унос на листи дозвољених за ту адресу пропушта сваки процес који на њој ради.

Ако посао ради на дељеном извршиоцу, та разлика је важнија, а не мање важна. Други ток рада на истом хосту наслеђује руту и адресу, а API не може да разликује њих двоје. То је иста слабост као дељена лозинка, померена један слој ниже. Ставите ограничење тамо где га апликација може да спроведе и изолујте извршиоца ако листу дозвољених не можете да сузите.

Упоредите два дизајна искрено

Људска пријава даје вам стварну особу, стварни други фактор и сесију која се може ревидирати, али не може да ради без надзора. Идентитет апликације даје вам извршавање без надзора, обим који се може прегледати и акредитацију коју можете да ротирате, али не може да делује за корисника који ништа није делегирао. Ниједно није слабија верзија другог; она одговарају на различита питања. Изаберите питајући мора ли задатак да ради без икога присутног и мора ли се операција приписати одређеном кориснику.

Ако су оба одговора да, дизајну треба модел делегирања, а не позајмљена лозинка. Запишите ту одлуку тамо где ће је наћи следећи одржавалац.

Шта проверити пре предаје

Покрените једну дозвољену операцију и једно обавезно одбијање са стварног runner-а и сачувајте оба резултата. Затим тестирајте истеклу акредитацију и понашање кад мрежни пут није доступан, јер су то два квара која некога буде ноћу.

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

Запишите субјекат, обим, власника ротације и окружење извршавања уз тај резултат. Тај запис чини следећу ротацију рутином, а не инцидентом. То је и део који тражи ревизор.