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

Введение

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

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

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

Предпосылки

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

  Примечание.

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

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

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

1. Определите тип секрета и его поставщик.
   • Например, является ли секрет GitHubpersonal access token PAT, OpenAI API или 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поиск по коду на 's, чтобы проверить весь код, проблемы и pull requests for the secret.
   • Поиск по всей организации с помощью org:YOUR-ORG "SECRET-STRING".
   • Выполните поиск в репозитории с помощью repo:YOUR-REPO "SECRET-STRING".
2. Проверьте сохраненные ключ развертывания репозитория и секреты и переменные.
   • Нажмите кнопку "Параметры", а затем в разделе "Безопасность" щелкните "Секреты и переменные " или "Развернуть ключи".
3. Проверьте наличие установленных GitHub Apps и интеграций, которые могут использовать секрет.

Coordinate

1. Инструктировать 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 оповещение в репозитории, выбрав Close as и пометив его как «Отменено».
2. Задокументируйте инцидент в база знаний или системе управления инцидентами вашей команды, включая шаги, принятые для устранения утечки, и все извлеченные уроки.

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

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

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