Закажана задача или човечко најавување: чиј идентитет треба да го види API-то?

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

Три порти што изгледаат како една

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

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

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

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

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

Каде VPN сѐ уште припаѓа

VPN може да ја обезбеди мрежната патека што ја бара приватен API, и тоа е легитимна улога. Тој не ја автентицира задачата пред апликацијата и не го ограничува она што задачата смее да го прави. Споделената излезна адреса исто така го идентификува домаќинот, а не задачата, затоа записот во списокот со дозволи за таа адреса го пропушта секој процес што работи на него.

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

Споредете ги двата проекта чесно

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

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

Што да се провери пред предавањето

Извршете една дозволена операција и едно задолжително одбивање од вистинскиот работник и зачувајте ги двата резултати. Потоа тестирајте истечена акредитација и однесувањето кога мрежната патека не е достапна, зашто тоа се двете грешки што некого будат ноќе.

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

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