Устранение утечки секрета в репозитории

Введение

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

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

Этот туториал проведёт вас через то, что делать, если вы случайно сохранили секрет в своём репозитории или если вас уведомили о секретной утечке в вашем репозитории.

Предпосылки

• У вас есть по крайней мере доступ на запись в репозиторий.
• Необязательно: для репозитория включен параметр Secret scanning.

  Примечание.

  Secret scanning предоставляется бесплатно для общедоступных репозиториев. Он доступен как часть GitHub Secret Protection для частных репозиториев на GitHub Team и GitHub Enterprise Cloud планов.

Шаг 1. Определение секрета и контекст сбора

Соберите столько информации, сколько можно о утечке секрета. Это поможет оценить риск и определить лучший курс действий по исправлению.

1. Определите тип секрета и его поставщик.
   • Например, секрет : GitHub personal access token (PAT), ключ API OpenAI, закрытый ключ SSH?
2. Найдите репозиторий, файл и строку, содержащую утечку секрета.
3. Определите владельца секрета. Это человек или команда, которая создала или несет ответственность за секрет. * CODEOWNERS Проверьте файл репозитория, чтобы определить ответственной команды.
   • Используйте git log -S для поиска журнала фиксаций репозитория, чтобы определить, кто зафиксирует секрет.

Шаг 2. Оценка риска

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

Secret scanning может помочь оценить риск, связанный с оповещением, но если у вас еще нет secret scanning, вы по-прежнему можете выполнить оценку риска на основе информации, доступной для вас.

Вариант 1. Включен параметр Secret scanning

Просмотрите оповещение secret scanning, связанное с утечкой, проверьте метки оповещений и все доступные метаданные:

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

   Примечание.

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

2.        `public exposure` Проверьте метку, чтобы определить, была ли утечка секрета в общедоступный репозиторий.
   

3.        `multiple leaks` Проверьте метку, чтобы определить, предоставляется ли секрет в нескольких расположениях.
   

4. Если секрет является GitHub PAT, проверьте метаданные оповещений о том, когда секрет был последним использован и его область доступа.
5. Оцените, какие службы или приложения зависят от секрета, и рассмотрите возможность простоя или прерывания, если вы немедленно отмените секрет.

Вариант 2. Secret scanning не включен

Если у вас еще нет secret scanning для репозитория, выполните оценку рисков на основе следующего:

1. Проверьте видимость репозитория****. Является ли репозиторий общедоступным?
2. Найдите признаки того, что секрет был использован недавно. Существуют ли последние фиксации или запросы на вытягивание, ссылающиеся на секрет? Существуют ли журналы или следы аудита, показывающие используемый секрет?

3.        **Оцените файл**, содержащий секрет и окружающий **контекст**. Используется ли секрет в сценарии развертывания рабочей среды (более высокий риск) или тестовом файле (более низкий риск)? Связан ли секрет с учетными данными базы данных или ключом администратора (более высокий риск)?
   

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

Шаг 3. Стратегизация исправления

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

Быстро действовать для секретов с высоким риском

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

Если секрет имеет высокий риск (то есть секрет по-прежнему активен, предоставляется в общедоступный репозиторий или является рабочей учетной записью), рекомендуется:

1. Определите приоритет немедленного отзыва секрета. См . шаг 4.

   Примечание.

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

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

Планирование средних и низких рисков секретов

Если секрет является средним и низким риском (то есть секрет больше не активен, предоставляется в частном репозитории или является тестовой или учетной записью разработки), можно спланировать стратегию исправления соответствующим образом:

1. Используя сведения, собранные на шаге 1, найдите ответственный отдел по секрету и оповещайте их о утечке секрета.
2. Объясните, что произошло утечкой и когда. Объясните, что вам потребуется отозвать секрет, создать новый секрет и что затронутые службы потребуют обновления.
3. Сообщите администраторам репозитория и клиентам безопасности о утечке, объясняя все необходимые или уже принятые действия по исправлению.
4. Запланируйте время отзыва и смены вместе с соответствующей командой для координации плавного перехода.

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

Шаг 4. Отмена секрета

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

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

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

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

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

Шаг 5. Определение и обновление затронутых служб

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

Identify

1. Используйте поиск кода GitHub, чтобы проверить весь код, проблемы и запросы на вытягивание секрета.
   • Поиск по всей организации с помощью org:YOUR-ORG "SECRET-STRING".
   • Выполните поиск в репозитории с помощью repo:YOUR-REPO "SECRET-STRING".
2. Проверьте сохраненные ключ развертывания репозитория и секреты и переменные.
   • Нажмите кнопку "Параметры", а затем в разделе "Безопасность" щелкните "Секреты и переменные " или "Развернуть ключи".
3. Проверьте наличие установленных данных GitHub Apps и интеграции, которые могут использовать секрет.

Coordinate

1. Указать Copilot создавать проблемы (и вложенные проблемы) для каждой задачи, связанной с обновлением затронутой службы. См. Использование GitHub Copilot для создания или обновления проблем.
2. Если участвуют несколько заинтересованных лиц, создайте доска проекта для отслеживания хода выполнения и упрощения взаимодействия.

Обновление и проверка

1. Обновите приложение с помощью нового секрета, чтобы приложение правильно использовало новые учетные данные.

   Совет

   Безопасный способ предоставления конфиденциальных учетных данных приложению — через хранилище. Например, вы можете сделать конфиденциальные учетные данные доступными для действий и рабочих процессов GitHub с помощью хранилища "Секреты и переменные" на странице параметров репозитория.

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

Шаг 6. Проверка несанкционированного доступа

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

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

   • Журнал безопасности для личная учетная запись. См . раздел AUTOTITLE.
   • Журнал аудита для вашей организации. См . раздел AUTOTITLE.
   • Журнал аудита для вашего предприятия. См . раздел AUTOTITLE.

   Для журналов аудита на уровне организации и предприятия можно специально искать события, связанные с маркером доступа. См. раздел [AUTOTITLE (организации) и Определение событий журнала аудита, выполняемых маркером доступа](/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/identifying-audit-log-events-performed-by-an-access-token) (предприятия).

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

2. Просмотрите журналы аудита поставщика секретов.

   • Например, для секретов Amazon Web Services (AWS) можно проверить журналы CloudTrail для любых несанкционированных попыток доступа с использованием утечки секрета. См. раздел "Что такое AWS CloudTrail"? в документации по AWS CloudTrail.

Шаг 7. Очистка репозитория

Хотя вы отозвали и обновили секрет в базе кода, секрет по-прежнему может существовать в журнале фиксации репозитория. В идеале следует искать и удалять все экземпляры секрета из репозитория.

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

Вместе с клиентами по обеспечению безопасности репозитория тщательно рассмотрите последствия очистки журнала репозитория в отношении ваших обязательств по соответствию или безопасности. См . раздел AUTOTITLE.

Шаг 8. Разрешение оповещения

1. Закройте оповещение secret scanning в репозитории, выбрав "Закрыть как " и пометив оповещение как "Отозвано".
2. Задокументируйте инцидент в база знаний или системе управления инцидентами вашей команды, включая шаги, принятые для устранения утечки, и все извлеченные уроки.

Шаг 9. Предотвращение дальнейших утечек

Работа с секретными утечками часто нарушает, сложно и занимает много времени. Фокус на обработку секретов всегда должен быть на предотвращении утечки во всех затратах :

1. Убедитесь, что защита от отправки (часть GitHub Secret Protection) включена для репозитория, если это еще не так. Изучите реализацию строгих элементов управления обходом, чтобы только доверенные пользователи могли обойти защиту от принудительной отправки. См . раздел AUTOTITLE.
2. Убедитесь, что в личная учетная запись включена защита push-уведомлений для пользователей, которая защищает вас от случайного отправки поддерживаемых секретов в любые общедоступный репозиторий.
3. Сторонник или реализация рекомендаций по управлению секретами в вашей команде или организации:
   • Используйте переменные среды для хранения секретов вместо жесткой кодировки в базе кода.
   • Используйте средства управления секретами, такие как GitHubв хранилище "Секреты и переменные" на странице параметров репозитория, чтобы безопасно хранить секреты и управлять ими.
   • Регулярно поворачивайте секреты, чтобы свести к минимуму влияние любых потенциальных утечек.
4. Документируйте инциденты и действия по исправлению, чтобы помочь вашей команде узнать о прошлых ошибках и улучшить будущие методики.
5. Выступает за регулярное обучение и подготовку по вопросам безопасности. См. пример: GitHub Курс расширенной безопасности из Microsoft Learn.

Дополнительные материалы

•         [AUTOTITLE](/code-security/secret-scanning/introduction/about-secret-scanning)
  

•         [AUTOTITLE](/code-security/secret-scanning/introduction/about-push-protection)
  

•         [AUTOTITLE](/code-security/secret-scanning/introduction/supported-secret-scanning-patterns)
  

•         [AUTOTITLE](/get-started/learning-about-github/about-github-advanced-security)