Планирана задача или човешки вход: коя самоличност трябва да види API?

Планирана задача и човек пред екрана за вход извикват същия API с различни удостоверения, различен срок на живот и различни собственици. Задачата се нуждае от мрежов път, самоличност на приложение и набор от разрешения; човекът се нуждае от вход, втори фактор и сесия. Смесването на двете създава автоматизация, която се чупи всеки път, когато паролата на човека се смени, или политика за многофакторна проверка, отслабена точно толкова, колкото да поддържа задача cron жива.

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

Правило за адрес на източника пита откъде идва заявката. Удостоверяването пита кой се обажда и какви доказателства са представени. Оторизацията пита дали този субект може да извърши тази операция. VPN променя само първото от трите и го променя за всеки процес на хоста, а не само за задачата, затова дръжте трите наблюдения отделно в записа за инцидента.

Затова смяната на изходния възел може да поправи отказ по адрес на източника и да остави невалиден токен незасегнат. Затова и валиден токен за API не прави частна крайна точка достъпна от задача, която няма маршрут до нея.

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

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

Поддържаната алтернатива обикновено е поток на поверителен клиент, при който сървърът за оторизация удостоверява приложението и издава токен. Предоставянето client-credentials в RFC 6749, раздел 4.4, е един пример. Самото му съществуване не значи, че всеки API го приема, нито че задача, делегирана от потребител, може да бъде заменена с него, защото това са въпроси към собственика на услугата. Питайте какъв модел без надзор поддържа услугата, преди да пишете код.

Къде VPN все още има място

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

Ако задачата работи на споделен runner, това разграничение е по-важно, не по-малко. Друг работен поток на същия хост наследява маршрута и адреса и API не може да различи двата. Това е същата слабост като споделена парола, преместена едно ниво по-надолу. Поставете ограничението там, където приложението може да го наложи, и изолирайте runner-а, ако не можете да стесните списъка за разрешение.

Сравнете двата дизайна честно

Човешкият вход ви дава реален човек, реален втори фактор и сесия, подлежаща на одит, но не може да работи без надзор. Самоличността на приложението ви дава изпълнение без надзор, прегледим обхват и удостоверение, което можете да ротирате, но не може да действа за потребител, който не е делегирал нищо. Нито едното не е по-слаба версия на другото; те отговарят на различни въпроси. Избирайте, като питате дали задачата трябва да работи без никого, и дали операцията трябва да се приписва на конкретен потребител.

Ако и двата отговора са да, дизайнът се нуждае от модел за делегиране, а не от заета парола. Запишете това решение там, където следващият поддръжник ще го намери.

Какво да проверите преди предаване

Изпълнете една разрешена операция и един задължителен отказ от действителния worker и запазете двата резултата. След това тествайте изтекло удостоверение и поведението, когато мрежовият път е недостъпен, защото това са двете повреди, които будят някого през нощта.

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

Запишете субекта, обхвата, собственика на ротацията и средата за изпълнение до този резултат. Този запис е това, което прави следващата ротация рутинна, а не инцидент. Той е и частта, която одиторът иска.