Сервис распознавания актов читает загруженные документы и сохраняет результат обработки. Для доступа к хранилищу ему однажды выдали постоянный ключ. Потом ключ скопировали в тестовую среду, добавили в резервный запуск и оставили у инженера для диагностики. Теперь остановить один сервис и прекратить использование его доступа — разные задачи.
Workload Identity позволяет связать доступ с проверяемой идентичностью программы. Вместо распространения постоянного ключа платформа может выдавать временные учётные данные конкретному исполнителю. Секреты при этом не исчезают из мира: меняются способ их получения, срок действия и то, кому доверяют при выдаче.
Что именно подтверждает платформа
Workload — это выполняющаяся программа с определённой задачей и конфигурацией, а не обязательно целая виртуальная машина. Сервис распознавания и сервис выставления счетов могут работать рядом, но нуждаться в разных полномочиях. У одной программы также может быть несколько экземпляров с общей рабочей идентичностью.
Механизм выдачи связывает запущенную программу с разрешённой идентичностью по проверяемым условиям. Нельзя позволить произвольному процессу просто объявить себя бухгалтерией. В модели SPIFFE отдельно описаны идентичность workload и граница доверия; изоляция программ, не позволяющая соседу украсть выданные данные, остаётся существенным условием.
Это не доказательство безошибочности кода. Программа с правильной идентичностью может быть скомпрометирована и пользоваться законными правами. Поэтому распознавателю по-прежнему нужны ограниченный каталог документов и отдельное место записи результатов, а не доступ ко всему аккаунту компании.
Доверять поставщику идентичности недостаточно
Если программа работает в другой среде, можно настроить федерацию: целевая платформа принимает подтверждение внешней системы и на согласованных условиях предоставляет доступ. Такой вариант описан в Workload Identity Federation Google Cloud. Поддержка конкретного ресурса и способ назначения прав требуют проверки.
Здесь важны издатель подтверждения, его получатель и точная принадлежность программы. Поставщик автоматизации может обслуживать тысячи организаций. Доверять любому выпущенному им токену — всё равно что разрешить вход каждому арендатору того же офисного здания.
Условия должны ограничивать нужную организацию, приложение, окружение и другие значимые признаки. Рекомендации Google Cloud отдельно разбирают неоднозначное сопоставление идентичностей и общих издателей. Название, которое другой участник может повторно зарегистрировать после удаления, также не всегда подходит как постоянное доказательство принадлежности.
Кто может запустить программу с этими полномочиями
Рабочий доступ теперь управляется не только хранилищем секретов. Нужно проверить, кто может назначить идентичность, изменить исполняемую программу или запустить другой код от её имени. Если тестовый разработчик способен присвоить своему заданию рабочую идентичность, отсутствие постоянного ключа мало меняет.
Разделяйте тестовую и рабочую среды, выдачу идентичности и разрешение на целевой ресурс. Для расследования сохраняйте, кто запросил доступ, на каком основании и какая операция затем выполнялась. Сами токены в журналы попадать не должны. Общая идентичность всех программ снова затруднит и расследование, и точечное отключение.
Короткий срок токена не останавливает его повторную выдачу
Украденные временные данные могут оставаться пригодными до истечения срока или действия дополнительного механизма отзыва. А пока источник выдачи считает захваченный процесс допустимым, тот может получать новые. Реакция на инцидент должна закрывать основание выдачи и ограничивать доступ к ресурсу, а не просто ждать окончания одного токена.
Уже установленные соединения могут иметь собственный жизненный цикл. Поэтому отключение проверяют и на новом запросе, и на действующем сеансе. Универсального обещания мгновенного прекращения доступа у всех платформ нет; допустимую задержку нужно установить для своей схемы.
Получение новых данных также становится эксплуатационной зависимостью. Давно работающий экземпляр может ещё иметь действующий токен, а новый — не запуститься. Проверяйте обновление доступа посреди длинной задачи, недоступность выдающего сервиса и ограниченные повторы. Просроченные данные нельзя незаметно заменять постоянным административным ключом «для надёжности».
Миграция заканчивается удалением старого пути
Начните с распознавателя и одного хранилища. Настройте идентичность, проверьте чтение разрешённых документов и отказ на соседний каталог. Затем запустите новую копию, дождитесь обновления временных данных и проверьте прекращение доступа. Убедитесь, что библиотека не использовала случайно личный аккаунт разработчика.
Старый постоянный ключ отзывают только после проверки всех нужных потребителей, включая резервные задания. Но оставлять его бессрочно нельзя: иначе новый способ добавился, а прежний риск сохранился. Для внешнего API, принимающего только статический ключ, останется управление секретами. Это нормальная граница внедрения, которую лучше записать, чем объявлять всю платформу работающей без ключей.