41 облачная среда может месяцами числиться за человеком, который давно перешел в другую команду, и все еще получать от него формальные аппрувы. Именно так ломается владение облачными ресурсами: не громким инцидентом, а тихим несовпадением оргструктуры и тегов. Для русскоязычных DevOps- и platform-команд это знакомая боль: увольнение обрабатывают, а внутренний переход часто проходит мимо инфраструктуры.
Материал о том, как ловить устаревшее владение до аудита безопасности, опубликовал The New Stack. Автор Zeen Rachidi предлагает не ждать квартального ревью, а встроить проверку в обычный процесс offboarding или перевода сотрудника между командами: сначала найти ресурсы, где человек еще указан владельцем, потом назначить нового ответственного, и только после этого отзывать доступы.
Ключевая идея простая: «последний день» не всегда означает увольнение. Чаще это последний день, когда человек реально отвечал за сервис, окружение или кластер. HR меняет должность, IT обновляет доступ к офису и корпоративным приложениям, менеджер поздравляет с новой ролью. А теги вида owner: marcus.reyes@company.com остаются жить своей жизнью. Через восемь месяцев такому бывшему владельцу прилетает запрос на изменение окружения, и он нажимает Approve, потому что разбираться дольше, чем согласовать.
Решение начинается с запроса к данным, которые у большинства зрелых команд уже есть. В AWS автор предлагает сопоставлять owner-теги EC2-инстансов с aws_iam_user_last_accessed_details и искать владельцев, чьи учетные данные не использовались больше 90 дней. Это не доказательство увольнения или перевода, но достаточно сильный сигнал, чтобы потратить 15 минут на проверку, а не обнаружить проблему через полгода на security review.
Для Azure логика похожая, но технически проще: в Entra ID userPrincipalName уже совпадает с идентификатором пользователя, поэтому owner-тег виртуальной машины можно напрямую сопоставить с журналом входов. В GCP такой же схемы на уровне IAM нет: там приходится идти выше, к данным Google Workspace или другого каталога, который выдает идентичность пользователю. Разница между облаками важна, но принцип один: владение облачными ресурсами нельзя держать только в строковом теге, который никто не проверяет.
Вторая часть стратегии — политика, которая не дает ресурсу потерять последнего владельца. Автор приводит пример на Rego для Open Policy Agent: если у ресурса нет активной роли Owner, изменение должно блокироваться. В нормальной реализации owner — это не свободный текст в tags или labels, а роль в IAM, Kubernetes RoleBinding, Terraform/IaC-пайплайне или платформе управления окружениями. Тогда policy engine видит не красивую подпись, а реальное назначение ответственности.
Тут есть неприятная правда для многих компаний: теги любят все, поддерживать их любит почти никто. Они отлично выглядят в FinOps-дашбордах и отчетах по безопасности, пока человек не сменил команду, проект не переехал, а сервис не ушел в режим «оно работает, не трогайте». Чем больше инфраструктуры создается через self-service, тем быстрее расходятся три реальности: кто записан владельцем, кто имеет доступ и кто на самом деле знает, что там происходит.
Практический шаг, который легко добавить в процесс, звучит почти скучно: перед отзывом доступов или переводом человека из команды нужно выполнить запрос по его имени и отправить найденные ресурсы менеджеру или тимлиду на переназначение. Сначала новый владелец, потом отзыв доступа. Для разработчиков это меньше странных аппрувов из прошлого. Для бизнеса — меньше бесхозных окружений, которые продолжают стоить деньги и жить вне понятной зоны ответственности. Для security-команд — меньше сюрпризов на аудите, где внезапно выясняется, что критичный ресурс формально принадлежит человеку из другой части организации.
Проблема будет только расти: внутренние переходы, реорганизации и временные проектные команды стали нормой, а не исключением. Значит, владение облачными ресурсами должно обновляться так же автоматически, как доступы и роли. Иначе каждая новая оргструктура будет оставлять после себя слой инфраструктурной археологии, где бывшие владельцы все еще нажимают кнопки за системы, которые уже давно не их.