Сохраняет ли переключение провайдера ИИ учётные данные и аудит?

Пайплайн ИИ не сохраняет свой уровень безопасности только потому, что повторяет тот же промпт где-то ещё. При переключении могут измениться учётные данные, авторизующие вызов, аккаунт, которому выставят счёт, регион обработки данных и доказательства, доступные для последующей проверки. Если такие изменения происходят внутри цикла повторных попыток SDK, путь обработки сбоя получает больше полномочий, чем было предусмотрено при проверке дизайна.

Я видел, как команды считали резервную конечную точку модели безобидной деталью инфраструктуры. Обычно всё начинается с разумной цели: не останавливать программного агента или рабочий процесс с документами, когда провайдер не отвечает. Затем одна переменная окружения, профиль по умолчанию или глобальная настройка повторных попыток превращают узко одобренный маршрут в не घोषितированный. Запрос выполняется успешно, поэтому никто ничего не замечает, пока финансовый отдел не спрашивает о незнакомом аккаунте или расследование инцидента не может установить, куда ушли данные.

Решение не в более сложной политике повторных попыток. Сначала принимайте решение о полномочиях, затем выполняйте вызов. Сделайте каждое возможное назначение явным и ведите одну цепочку доказательств, которая сохранится даже после частичного сбоя. Доступность важна, но она не оправдывает неясность в вопросе о том, кто действовал за пределами вашей границы.

Резервный маршрут это второй путь полномочий

Резервному маршруту нужна собственная авторизация, потому что он может использовать учётные данные и договорные разрешения, которых никогда не было у основного маршрута. Название «повторная попытка» ничего не меняет.

Маршрут это не только имя хоста и название модели. Он включает провайдера, аккаунт или проект провайдера, ссылку на учётные данные, разрешённый регион, классификацию данных, принятые вами настройки хранения и состояние одобрения. Если хотя бы одно из этих полей отличается, альтернативный вызов имеет другой внешний эффект.

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

Представьте, что программного агента попросили обобщить выгрузку обращений в службу поддержки. Основной маршрут отправляет обезличенный текст в одобренный аккаунт в заданном регионе. После тайм-аута альтернативный клиент читает общие учётные данные из окружения процесса и отправляет тот же текст в личный тестовый аккаунт в другом регионе. Задача выглядит выполненной. Граница безопасности нарушена.

Не решайте эту проблему полным запретом резервных маршрутов. Для некоторых задач существует несколько действительно взаимозаменяемых назначений. Опишите такую эквивалентность как набор конкретных свойств и заставьте маршрутизатор её проверять. Резервное назначение без явно указанного аккаунта, региона и ссылки на учётные данные неполно, даже если оно идеально отвечает на промпт.

Три идентификатора могут меняться независимо

Имя провайдера, платёжный идентификатор и идентификатор учётных данных это отдельные поля, и маршрут должен содержать все три. Предположение, что одно из них подразумевает остальные, создаёт самую распространённую слепую зону при работе с несколькими провайдерами.

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

Во время сбоев это особенно важно, потому что резервный код часто ищет всё, что сработает. Библиотека клиента может выбрать проект по умолчанию. Контейнер может унаследовать учётные данные разработчика. Идентификация рабочей нагрузки после изменения конфигурации может выпустить токен для другого тенанта. В журнале приложения ни одно из этих действий не выглядит драматично. Но каждое из них остаётся внешним действием с другими полномочиями.

Опишите маршрут как полный объект до открытия сетевого соединения. Эта псевдоконфигурация показывает минимальную структуру:

{
  "operation_class": "customer-text-summary",
  "primary": {
    "provider": "provider-a",
    "account": "production-eu",
    "credential_ref": "vault:provider-a-prod-eu",
    "region": "eu",
    "data_class": "redacted-customer-text"
  },
  "fallbacks": [
    {
      "provider": "provider-b",
      "account": "production-backup-eu",
      "credential_ref": "vault:provider-b-backup-eu",
      "region": "eu",
      "data_class": "redacted-customer-text",
      "approval": "destination-specific"
    }
  ],
  "deny_when": ["account_missing", "region_mismatch", "credential_ref_missing"]
}

Конфигурация намеренно скучная. Её цель в том, чтобы SDK не подставлял аккаунт или учётные данные после принятия решения о маршруте. Не храните в этой записи сами секреты. Ссылка на учётные данные указывает, какие полномочия можно использовать, и никогда не должна содержать сам секрет.

Классифицируйте вызывающую сторону отдельно от назначения. Процесс агента может быть достаточно надёжным, чтобы запросить задачу, но не иметь права отправлять её во все аккаунты провайдера, принадлежащие вашей компании. Агент просит. Определитель маршрута решает, существует ли одобренное назначение.

Учётные данные по умолчанию незаметно меняют аккаунт

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

Типичная последовательность выглядит так:

1. Рабочий процесс отправляет запрос через provider A, используя явную ссылку на учётные данные production.
2. Provider A возвращает тайм-аут после того, как запрос достиг неопределённого состояния.
3. Обёртка повторной попытки выбирает provider B и создаёт его клиент с автоматическим поиском учётных данных.
4. Provider B принимает учётные данные из окружения рабочего процесса, например общую роль облака или токен, созданный разработчиком.
5. Рабочий процесс записывает только fallback succeeded и возвращает результат.

Каждая строка может пройти проверку кода, если ревьюеры сосредоточатся на обработке ответа. Проблема скрыта в пропущенных полях. Какой аккаунт принял запрос? В каком регионе он обрабатывался? Можно ли было отправлять этот промпт в выбранное назначение? Означал ли тайм-аут, что provider A тоже завершил первый запрос, оставив две копии данных за пределами предусмотренного маршрута?

Требуйте, чтобы конструктор резервного клиента получал ссылку на учётные данные и утверждение аккаунта. Утверждение это идентификатор, который удалённый сервис должен вернуть для аутентифицированного вызывающего. Если сервис не может предоставить его программно, записывайте аккаунт, выбранный брокером учётных данных, и ограничьте учётные данные так, чтобы они не могли обратиться к непредусмотренному аккаунту.

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

У резервного маршрута также должен быть бюджет. Это не просто ограничение расходов. Ограничивайте число попыток для каждой операции и каждого назначения в заданном временном окне, чтобы сбой у провайдера не заставил очередь разослать одну и ту же чувствительную задачу по нескольким аккаунтам. Если невозможно понять, дошла ли основная попытка до провайдера, пометьте результат как неопределённый и обработайте это состояние явно. Слепые повторы превращают дублирующиеся внешние действия в норму.

Для непрерывной трассировки недостаточно идентификатора запроса

Один идентификатор операции может связать события переключения, но журнал аудита остаётся неполным, если каждая попытка не указывает использованные полномочия. Связь отвечает на вопрос, какие события относятся к одной операции. Поля маршрута отвечают на вопрос, что действительно произошло.

Создайте идентификатор операции до выбора основного маршрута. Сохраняйте его неизменным для пользовательского запроса, запуска агента или задания в очереди. Затем назначайте номер каждой попытке вызова провайдера, включая вызовы, заблокированные до обращения к сети. Полезная запись выглядит так:

{
  "operation_id": "op_7c1d",
  "attempt": 2,
  "parent_attempt": 1,
  "reason": "primary_timeout",
  "provider": "provider-b",
  "account": "production-backup-eu",
  "credential_ref": "vault:provider-b-backup-eu",
  "region": "eu",
  "data_class": "redacted-customer-text",
  "approval_id": "apr_391",
  "result": "sent"
}

Позже запишите событие с результатом, используя тот же идентификатор операции и номер попытки. Добавляйте идентификаторы удалённых запросов, если провайдер их возвращает, но не делайте их основным полем связи. У заблокированных вызовов таких идентификаторов нет, а два провайдера не будут использовать один формат.

Рекомендация W3C Trace Context определяет идентификатор трассировки, который передаётся через границы сервисов, а OpenTelemetry использует этот контекст для связи спанов. Применяйте его для операционной трассировки, если ваши сервисы его поддерживают. Он не заменяет перечисленные выше поля полномочий. Трассировка может точно показать, что запрос прошёл через пять сервисов, но не ответить, какие учётные данные пересекли последнюю границу.

Разделяйте предпринятое действие и завершённое действие. Если маршрутизатор выбрал provider B, но одобрение было отклонено, запишите заблокированную попытку. Если запрос покинул вашу сеть, но соединение оборвалось, запишите неопределённую попытку. Если provider B вернул ответ, зафиксируйте завершение. При расследовании инцидента эти различия необходимы, и агент должен получить результат, который их сохраняет, а не расплывчатую ошибку повторной попытки.

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

Для региона обработки нужен явный путь отказа

Ограничение по региону должно отклонять альтернативный маршрут, который ему не соответствует, даже во время сбоя провайдера. Иногда безопасный резервный вариант это контролируемый отказ.

Не сводите требования к региону к метке региона на панели мониторинга. Определите, что именно ваша организация понимает под этим требованием для конкретного класса данных: место обработки, место хранения, доступ службы поддержки, срок хранения и одобренные субпроцессоры. Определитель маршрута должен исходить из этого решения, а не угадывать по ближайшей конечной точке провайдера.

Распространённая ошибка заключается в том, что для основного маршрута объявляют регион, а затем настраивают глобальный резервный маршрут, наследующий географию провайдера по умолчанию. В обычном режиме основной маршрут выглядит соответствующим требованиям. Резервный появляется в журналах только при ухудшении работы сервиса, когда люди как раз перестают читать детали. Поэтому правила переключения должны содержать явные утверждения о регионе и путь отказа для любого назначения, которое не может подтвердить требуемое свойство.

Учитывайте минимизацию данных на уровне маршрутизации. Если задача может выполняться на обезличенном тексте, обезличивание должно происходить до выбора провайдера, чтобы каждый разрешённый маршрут получал одинаковый сокращённый набор данных. Не рассчитывайте, что интеграция с основным провайдером удалит поля, пока резервная интеграция отправит исходный объект. Контракт маршрута должен указывать разрешённый класс данных, а сборщик полезной нагрузки должен отклонять более широкий класс.

Бывают ситуации, когда оператор может одобрить временное исключение. Оформляйте его как исключение с видимым сроком действия, указанным ответственным и новым событием аудита. Не превращайте его молча в постоянное правило маршрутизации после инцидента. Сбой создаёт давление, подталкивающее расширить границы, но не отменяет причины, по которым эти границы появились.

Сначала маршрутизатор, потом учётные данные

Единый определитель маршрута должен выбрать назначение до того, как клиент провайдера получит учётные данные. Это убирает скрытый второй механизм политики, который появляется, когда каждый SDK самостоятельно управляет повторными попытками, значениями по умолчанию и переключением.

Определителю нужны параметры, относящиеся к самой работе, а не к библиотеке клиента: класс операции, класс данных, идентификатор вызывающей стороны, одобренные назначения, требование к региону, полномочия на расходы и необходимость ручного одобрения назначения. Он возвращает либо один полный маршрут, либо отказ. Он не должен возвращать список расплывчатых вариантов, которые нижестоящий код будет толковать самостоятельно.

Сделайте адаптер провайдера узким. Он получает маршрут, запрашивает указанные учётные данные через одобренную границу секретов, отправляет запрос и сообщает результат. После ошибки он не должен выбирать другого провайдера. Если ему нужно повторить временную транспортную ошибку для того же полностью описанного назначения, запишите это как ещё одну попытку. Если он хочет сменить назначение, он должен вернуть управление определителю маршрута.

Такое разделение также делает проверяемым сложный вопрос: кто одобрил переключение? Ответом должно быть решение о маршруте, связанное с вызывающей стороной, операцией и записью одобрения, а не строка, скрытая в настройках повторных попыток зависимости.

Для команд, работающих с macOS, Sallyport хранит учётные данные агентов в зашифрованном хранилище и записывает сеансы агентов, а также отдельные действия HTTP или SSH, но маршрутизатор всё равно должен указать каждое предполагаемое назначение до того, как попросит Sallyport выполнить вызов.

Не смешивайте шлюз учётных данных с универсальным языком политик. Для правильной реализации не нужна огромная система правил. Фиксированный набор полей маршрута и несколько ясных условий отказа проще проверять, тестировать и объяснять в напряжённой ситуации.

Одобрение должно охватывать назначение

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

Если работа этого требует, используйте две точки принятия решения. Сначала разрешите запуск агента или рабочую нагрузку, чтобы они могли запрашивать действия. Затем требуйте одобрение конкретного назначения, когда маршрут пересекает порог чувствительности, меняет провайдера, использует другой платёжный аккаунт или обрабатывает ограниченный класс данных. Для заранее одобренных эквивалентных маршрутов второе решение может приниматься автоматически, но оно должно основываться на заявленных свойствах маршрута.

В карточке или записи одобрения укажите полномочия агента, цель операции, провайдера, аккаунт, регион, класс данных и срок действия. В ней не нужно показывать секрет, полный промпт или стену внутренних идентификаторов. Но информации должно хватать, чтобы человек заметил превращение производственного аккаунта в ЕС в личный тестовый аккаунт или смену регионального маршрута.

Чтобы избежать усталости от подтверждений, оставляйте подтверждение каждого вызова только для действий, которым оно действительно нужно. Постоянные запросы для обычных заранее одобренных вызовов приучают людей нажимать кнопку автоматически. Решение не в скрытом переключении. Нужен небольшой набор классов маршрутов с честными настройками по умолчанию и отдельное одобрение, когда назначение выходит за пределы такого класса.

Отзыв полномочий так же важен, как их одобрение. Если выяснилось, что агент ведёт себя опасно, завершите его сеанс и запретите новые вызовы с использованием этих полномочий. Если учётные данные или аккаунт провайдера вызывают подозрения, отключите маршрут и заставьте определитель его отклонять. Журнал аудита с зафиксированным временем остановки гораздо полезнее общей заметки о чьём-то изменении конфигурации.

Тестируйте ухудшение работы как производственный сбой

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

Создайте тестовый адаптер провайдера, способный вернуть тайм-аут после принятия запроса, ограничение частоты до его принятия, ошибку аутентификации, некорректный ответ и несоответствие утверждения о регионе. Эти сбои означают разное. Тайм-аут после отправки создаёт неопределённость относительно завершения. Ошибка аутентификации не должна заставлять маршрутизатор искать другие учётные данные в локальном окружении.

Для каждого случая сбоя проверьте пять результатов:

• Определитель выбрал либо полностью описанный альтернативный маршрут, либо отказал.
• Брокер учётных данных получил точную ссылку из выбранного маршрута.
• В журнале аудита есть запись о попытке до внешнего вызова и запись о результате после него.
• Идентификатор операции связывает основную и альтернативную попытки, не смешивая разные задачи.
• Возвращённый статус различает заблокированную, неудачную и неопределённую работу.

Запускайте тесты с основными и резервными учётными данными, намеренно связанными с разными аккаунтами. Если в тестовой среде оба набора указывают на один аккаунт, отсутствие проверки аккаунта может остаться незамеченным. Запускайте тесты и без доступных автоматически найденных учётных данных. Дизайн, работающий только потому, что автоматический поиск его спасает, не доказал наличие границы.

Проверьте поведение очереди. Рабочий процесс может завершиться после отправки запроса, а новый процесс продолжит задачу с новым идентификатором. Убедитесь, что он читает предыдущее состояние операции, сохраняет идентификатор операции и не повторяет неопределённый запрос только потому, что его локальная память пуста. Если бизнес-действие нельзя безопасно повторить, требуйте удалённый токен идемпотентности, когда провайдер его поддерживает, и сохраняйте этот токен в записи попытки.

Наконец, проверьте опыт оператора. Попросите человека, который не писал код маршрута, объяснить одно событие переключения по журналу. Он должен суметь определить вызывающую сторону, исходное назначение, причину изменения, альтернативный аккаунт и регион, решение об одобрении и конечный результат. Если для этого нужны запрос к базе данных и три журнала приложения, дизайн аудита всё ещё слишком раздроблен.

Сохраняйте доказательства после инцидента

Журнал аудита должен оставаться доступным для проверки, даже если провайдер, рабочий процесс или аккаунт администратора, участвовавшие в инциденте, больше не заслуживают доверия. Храните локально достаточно метаданных маршрута, чтобы восстановить принятое решение без обращения к консоли провайдера, которая могла измениться или стать недоступной.

Не храните в журнале исходные значения секретов. Записывайте стабильные ссылки на учётные данные, идентификаторы аккаунтов и криптографические отпечатки, когда это уместно. Ревьюеру нужно доказать, какие полномочия были выбраны, а не получить новый способ их использовать.

Проверяйте журнал по расписанию и во время реагирования на инцидент. Команда sp audit verify в Sallyport проверяет зашифрованный журнал аудита с хеш-цепочкой в автономном режиме и не требует ключа хранилища. Это именно тот тип проверки, который нужен для работы с доказательствами без открытия секретов, позволивших выполнить действия.

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