Что подтверждено источником
Microsoft DART описала инцидент Storm-3068, в котором захват учётной записи через сброс пароля перерос в доступ к Azure DevOps и Kubernetes. Злоумышленник добавил собственные способы аутентификации и использовал доверенные pipeline для получения учётных данных. Это расследование конкретного случая, а не утверждение о компрометации всех таких платформ.
Microsoft DART: Beyond source code: A path to the keys to the kingdom
Далее — редакционный разбор и практические рекомендации Virusologia.
Почему границы команд не равны границам доступа
IAM-команда видит вход, разработчики — изменение сборки, облачная команда — обращение к API. Каждый сигнал может выглядеть допустимым в отдельности. Для проверки защиты нужна общая цепочка: какой пользователь способен изменить pipeline, от чьего имени он исполняется и до каких ресурсов дотягивается.
Минимальная карта доверия
Начните с одного критичного сервиса. Выпишите людей и сервисные аккаунты, репозитории, runner, подключения к средам и точки ручного одобрения. Для каждой связи укажите владельца и доказательство: правило доступа, настройку или журнал. Наличие стрелки в схеме ещё не означает доказанный путь атаки.
Проверка, которую можно провести без production-секретов
Создайте тестовый pipeline в изолированном проекте с фиктивным секретом. Убедитесь, что обычный участник не может сам расширить полномочия, получить секрет защищённой среды или обойти одобрение. Зафиксируйте ожидаемый запрет и фактическое событие в журнале. Реальные токены и клиентские данные для такой проверки не нужны.
Почему смены пароля может не хватить
После захвата аккаунта проверьте способы входа, активные сессии, выданные разрешения приложениям, сервисные подключения и изменения сборок. Рассматривайте каждый дополнительный доступ как отдельный объект отзыва. Порядок восстановления согласуйте с владельцами сервисов, чтобы отзыв полномочий не остановил критичное развёртывание без плана.
Доказательство исправления для руководителя и инженера
Для руководителя нужен ответ, какие сервисы могли быть затронуты и какие полномочия сокращены. Инженеру нужны версии настроек, события отзыва и результат контрольного запуска. Если часть журналов отсутствует, обозначьте этот пробел явно. Отсутствие события в неполном журнале не подтверждает отсутствие доступа.
Пример карточки проверки границы доверия
control: protected_environment_access
project: isolated-validation-lab
identity: test-contributor
resource: synthetic-secret
expected: deny_without_independent_approval
observed: pending
evidence:
policy_revision: pending
audit_event_id: pending
owner: platform-team