Контроль привилегий в автоматизированных пайплайнах как базовый элемент защиты

• Почему доступы в CI/CD требуют отдельного контроля
• Что считается привилегией в пайплайне
• Как избыточные права превращаются в риск
• Разделение прав по этапам
• Сервисные учетные записи и временные токены доступа
• Секреты и срок действия полномочий
• Защита среды выполнения pipeline
• Небезопасные триггеры и внешние изменения
• Контроль изменений в конфигурации
• Логирование и проверка использования прав
• Проверяемое происхождение артефактов
• Поэтапная модель внедрения
• Критерии зрелого контроля

Автоматизированный пайплайн связывает разработку, тестирование, сборку и развертывание программного обеспечения. В процессе его работы могут использоваться исходный код, сторонние зависимости, секреты, реестры контейнерных образов, облачные сервисы и инфраструктура рабочей среды. Поэтому CI/CD необходимо рассматривать как критически важную среду, а не как вспомогательный инструмент разработчиков.

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

Почему доступы в CI/CD требуют отдельного контроля

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

Автоматизированный пайплайн связывает разработку, тестирование, сборку и развертывание программного обеспечения. В процессе его работы могут использоваться исходный код, сторонние зависимости, секреты, реестры (хранилище) контейнерных образов, облачные сервисы и инфраструктура рабочей среды. Поэтому CI/CD необходимо рассматривать как критически важную среду, а не как вспомогательный инструмент разработчиков.

Такой подход создает единый доверенный контур. Если злоумышленник получает возможность изменить один этап, он может попытаться использовать полномочия всего пайплайн. Риск возрастает, когда конфигурация позволяет читать секреты, обращаться к облачным API и выполнять действия в production (рабочей среде).

OWASP рекомендует применять принцип минимальных привилегий сразу в нескольких областях. Ограничивать нужно секреты, доступ пайплайн к ресурсам самой CI/CD-платформы и полномочия операционной системы, от имени которой выполняются команды.

CI/CD также следует защищать как производственную среду. Это предполагает регулярное обновление компонентов, контроль доступа, мониторинг событий, защиту среды выполнения и проверку конфигурации.

Что считается привилегией в пайплайне

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



В пайплайне могут использоваться разные субъекты доступа:

- пользователь, запустивший процесс;

- сервисная учетная запись;

- временный токен доступа для отдельной задачи;

- облачная роль;

- учетная запись runner;

- ключ внешнего инструмента;

- подключенное действие или иной компонент автоматизации.

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

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

Права должны назначаться с учетом трех параметров:

- какие ресурсы требуется использовать;

- какие операции необходимо выполнять;

- в течение какого времени доступ должен сохраняться.

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

Как избыточные права превращаются в риск

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

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

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

Отдельный риск связан с совместным использованием учетных данных. OWASP рекомендует не использовать один набор секретов для пайплайна с разным уровнем чувствительности. Права процесса, который работает с тестовым кодом, не должны автоматически распространяться на пайплайн, связанный с рабочей средой (production).

Разделение прав по этапам

Пайплайн следует рассматривать как последовательность самостоятельных операций. Для каждой операции нужно определить необходимые ресурсы и допустимые действия.




Этап сборки

На этапе сборки пайплайн должен иметь доступ к исходному коду и необходимым зависимостям. Ему может потребоваться право создавать локальные результаты сборки и передавать их следующему этапу.

Доступ к production-среде, боевым секретам и административным настройкам инфраструктуры для этой задачи обычно не требуется. Если сборка не публикует артефакты самостоятельно, ей также не требуется право записи в реестр контейнерных образов.

Этап тестирования

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

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

Этап анализа

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

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

Этап публикации

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

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

Этап развертывания

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

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

Такое разделение ограничивает последствия компрометации. Если злоумышленник получает контроль над этапом тестирования, это не должно автоматически давать ему возможность изменить production.

Сервисные учетные записи и временные токены доступа

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

Для каждой такой учетной записи необходимо определить:

- назначение;

- владельца;

- область применения;

- допустимые операции;

- срок действия;

- порядок отзыва;

- перечень регистрируемых событий.

В GitLab для выполнения отдельных задач используется временный токен, который создается при запуске задачи автоматизированного процесса и действует в течение ее выполнения. После ее завершения токен перестает использоваться. Такой механизм предпочтительнее постоянного персонального ключа, если предоставленных прав достаточно для выполнения операции.

GitLab также рекомендует избегать персональных токенов в переменных CI/CD и по возможности использовать токены, предназначенные для задач и проектов. Персональный ключ связывает автоматизацию с конкретным сотрудником и может продолжить действовать после изменения его роли или прекращения работы.

В GitHub аналогичный принцип применяется к GITHUB_TOKEN. Его права следует ограничивать на уровне конкретного workflow, а не оставлять максимально широкими по умолчанию.

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

Секреты и срок действия полномочий

Секретами являются пароли, ключи, сертификаты, токены и другие значения, которые позволяют пройти аутентификацию или получить доступ к ресурсу. В CI/CD они используются регулярно, поэтому требуют отдельной модели защиты.

Секреты могут попасть в открытый доступ через:

- файлы конфигурации;

- исходный код;

- журналы выполнения;

- артефакты;

- кэш;

- дампы ошибок;

- переменные окружения;

- отладочные команды.

OWASP указывает, что секреты нельзя непосредственно указывать в репозиториях и конфигурационных файлах CI/CD. Их следует хранить в специализированной системе и выдавать только тем задачам, которым они действительно необходимы.

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

Постоянные ключи желательно заменять короткоживущими учетными данными. GitHub рекомендует использовать OpenID Connect для получения временного доступа к облачным ресурсам вместо хранения постоянных ключей в секретах workflow.

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

Защита среды выполнения pipeline

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

Операционная учетная запись runner не должна обладать правами администратора без необходимости. OWASP рекомендует не выполнять пайплайн от имени root или другого пользователя с сопоставимыми полномочиями.

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

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

Для чувствительных операций предпочтительны одноразовые среды выполнения. После завершения задачи они уничтожаются вместе с локальным состоянием. Это снижает риск сохранения вредоносных изменений и утечки временных учетных данных.

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

Небезопасные триггеры и внешние изменения

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

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

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

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

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

Контроль изменений в конфигурации

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

OWASP рекомендует хранить конфигурацию пайплайн в системе контроля версий. Изменения должны проходить ревью и выполняться только в рамках защищенного процесса.

Особое внимание нужно уделять следующим изменениям:

- расширению прав временного токена;

- добавлению нового секрета;

- подключению стороннего action;

- смене runner;

- появлению команды публикации;

- изменению условий запуска;

- передаче переменных между этапами;

- изменению адреса реестра контейнерных образов (registry);

- добавлению доступа к облачному ресурсу.

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

GitHub рекомендует фиксировать сторонние actions по полному идентификатору коммита, а не использовать подвижные теги. Это снижает риск незаметной подмены версии после подключения компонента к workflow.

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

Логирование и проверка использования прав

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

В журналах следует отражать:

- запуск и завершение пайплайн;

- запуск и завершение отдельных задач;

- субъект доступа;

- выданные разрешения;

- обращение к секретному хранилищу;

- получение и публикацию артефакта;

- изменение конфигурации;

- доступ к registry;

- выполнение развертывания;

- отказ в выполнении операции.

Логи должны отвечать на несколько вопросов. Какой процесс использовал токен? Какой код выполнялся? К какому ресурсу обращались? Какие изменения были внесены? Соответствовало ли действие назначению конкретного этапа?

OWASP относит недостаточную видимость и слабое журналирование к основным рискам CI/CD. При этом журналы необходимо защищать от изменения и ограничивать доступ к ним. Иначе злоумышленник сможет удалить следы собственных действий.

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

Проверяемое происхождение артефактов

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

SLSA использует для этого понятие provenance. Оно описывает утверждение о том, что определенная build-платформа создала конкретный набор артефактов в ходе выполнения заданного процесса сборки.

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

Проверка provenance должна включать несколько действий:

- проверку подписи;

- проверку доверия к builder;

- сопоставление дайджеста с проверяемым артефактом;

- проверку типа provenance;

- сравнение параметров сборки с ожидаемыми значениями.

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

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

Поэтапная модель внедрения

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



Инвентаризация

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

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

Если владельца доступа невозможно определить, это является признаком недостаточного управления полномочиями.

Классификация операций

Операции следует разделить по уровню воздействия. Чтение открытой зависимости и изменение production не могут относиться к одной категории.

Отдельно необходимо выделить права на:

- чтение;

- запись;

- публикацию;

- изменение конфигурации;

- выполнение административных действий;

- запуск развертывания.

После классификации становится понятнее, какие разрешения можно разделить между этапами и какие требуют дополнительного одобрения.

Разделение прав

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

Доступ к production необходимо отделить от доступа к dev и staging. Такой доступ не должен выдаваться автоматически каждому пайплайн.

Замена постоянных ключей

Постоянные ключи следует заменить временными токенами или федеративной аутентификацией, если это поддерживают CI/CD-платформа и целевой сервис.

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

Техническая проверка

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

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

Регулярный пересмотр

Права необходимо пересматривать после изменения архитектуры, добавления нового сервиса, смены владельца или появления нового окружения.

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

Критерии зрелого контроля

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

- какой этап получил конкретное разрешение;

- зачем ему потребовался этот доступ;

- кто утвердил полномочие;

- когда оно использовалось;

- какие ресурсы были затронуты;

- как быстро доступ можно отозвать;

- какой код и какие параметры использовались при сборке;

- можно ли подтвердить происхождение артефакта;

- какие действия выполнялись после изменения конфигурации.

Если ответы зависят от памяти одного инженера, процесс недостаточно формализован. Информация о полномочиях должна храниться в документации, конфигурации и журналах.

Оценивать эффективность контроля можно с помощью нескольких показателей:

- доля пайплайн с разделенными ролями;

- доля временных токенов среди всех учетных данных;

- количество постоянных ключей с истекшим сроком;

- время от обнаружения избыточного доступа до его отзыва;

- количество job, имеющих доступ к production;

- доля артефактов с подтвержденным происхождением;

- количество изменений workflow, прошедших обязательное ревью.

Такие показатели не заменяют техническую проверку, но помогают руководству видеть состояние контроля и динамику изменений.

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

Надежная модель строится на нескольких принципах:

- минимальные права;

- разделение обязанностей;

- отдельные роли для разных этапов;

- временные токены доступа;

- ограничение срока действия секретов;

- изоляция среды выполнения;

- контроль внешних изменений;

- ревью конфигурации;

- журналирование действий;

- проверка происхождения артефактов.

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

Главный критерий безопасности заключается не в количестве подключенных инструментов. Важно понимать, какие права имеет каждый этап, кто их выдал, как они используются и что произойдет при компрометации конкретной задачи. Именно такая модель превращает CI/CD из неконтролируемого набора автоматических действий в управляемую часть инфраструктуры.