Плановая задача или вход человека: какую личность должен видеть 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

Запишите субъект, объём, владельца ротации и среду выполнения рядом с этим результатом. Именно эта запись делает следующую ротацию рутиной, а не инцидентом. Это также та часть, которую запрашивает аудитор.