Планова задача чи вхід людини: яку особу має бачити 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

Запишіть суб'єкт, обсяг, власника ротації та середовище виконання поряд із цим результатом. Саме цей запис робить наступну ротацію рутиною, а не інцидентом. Це також та частина, яку просить аудитор.