Удаление конфиденциальных данных из репозитория

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

В этой статье

Удаление конфиденциальных данных из репозитория

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

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

Побочные эффекты переписывания журнала

Существует множество побочных эффектов для перезаписи журнала; к ним относятся:

  • Высокий риск повторного восстановления: к сожалению, легко повторно отправить конфиденциальные данные в репозиторий и сделать больший беспорядок. Если у коллег разработчика есть клон до перезаписи, а после перезаписи просто выполняется git pull , за которым следует git push, конфиденциальные данные будут возвращены. Они должны либо отменить их клонирование и повторно клонировать, либо тщательно пройти несколько шагов, чтобы очистить их клон в первую очередь.
  • Риск потери работы других разработчиков: если другие разработчики продолжают обновлять ветви, содержащие конфиденциальные данные во время попытки очистки, вы будете вынуждены повторно выполнить очистку или отменить их работу.
  • Измененные хэши фиксации: журнал перезаписи изменит хэши фиксаций, которые представили конфиденциальные данные и все фиксации, которые пришли после. Любые средства или автоматизация, зависящие от хэшей фиксации, не изменяются, будут нарушены или имеют проблемы.
  • Проблемы защиты ветви. Если у вас есть какие-либо защиты ветви, которые предотвращают принудительная отправка, эти защиты должны быть отключены (по крайней мере временно) для удаления конфиденциальных данных.
  • Неработающее представление диффа для закрытых запросов на вытягивание: удаление конфиденциальных данных потребует удаления внутренних ссылок, используемых для отображения представления диффа в запросах на вытягивание, поэтому вы больше не сможете видеть эти диффы. Это верно не только для pr, который представил конфиденциальные данные, но любой PR, который строится на версии журнала после объединения конфиденциальной данных pr (даже если эти более поздние PR не добавили или не изменяли файл с конфиденциальными данными).
  • Плохое взаимодействие с открытыми запросами на вытягивание: измененная фиксация SHAs приведет к другому диффу PR, и комментарии к старому диффу PR могут стать недействительными и потеряны, что может привести к путанице для авторов и рецензентов. Перед удалением файлов из репозитория рекомендуется объединить или закрыть все открытые запросы на вытягивание.
  • Потерянные подписи для фиксаций и тегов: подписи для фиксаций или тегов зависят от хэшей фиксации; так как хэши фиксации изменяются перезаписями журнала, подписи больше не будут допустимыми, и многие средства перезаписи журнала (включая git filter-repo) просто удаляют подписи. На самом деле удалите git filter-repo подписи фиксации и подписи тегов для фиксаций, которые предстоит удалить конфиденциальные данные. (Технически один может обойти эту проблему с --refs параметром git filter-repo при необходимости, но вам потребуется быть осторожным, чтобы убедиться, что все ссылки, содержащие конфиденциальные данные в их журнале, и которые включают фиксации, которые ввели конфиденциальные данные в диапазоне).
  • Ведущие другие непосредственно к конфиденциальным данным: Git был разработан с помощью криптографических проверок, встроенных в идентификаторы фиксации, чтобы невредимые лица не могли взломать сервер и изменить журнал без уведомления. Это полезно с точки зрения безопасности, но с точки зрения конфиденциальной данных это означает, что удаление конфиденциальных данных является очень вовлеченным процессом координации; Это означает, что при изменении журнала пользователи с существующим клоном заметят расхождение журнала и могут использовать его для быстрого и легкого поиска конфиденциальных данных в их клоне, который вы удалили из центрального репозитория.

Сведения о воздействии конфиденциальных данных

Удаление конфиденциальных данных из репозитория включает четыре шага высокого уровня.

  • Перезапись репозитория локально с помощью репозитория git-filter-repo
  • Обновите репозиторий на GitHub с помощью локально перезаписываемого журнала
  • Координация с коллегами для очистки других клонов, которые существуют
  • Предотвращение повторов и предотвращение будущих разливов конфиденциальных данных

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

  • В любых клонах или вилках репозитория
  • Непосредственно через хэши SHA-1 в кэшированных представлениях на GitHub Enterprise Cloud
  • Через все запросы на вытягивание, ссылающиеся на них

Вы не можете удалить конфиденциальные данные из клонов других пользователей репозитория; Вам придется отправить им инструкции, приведенные в разделе "Убедитесь, что другие копии очищаются: клоны коллег в руководстве git filter-repo , чтобы сделать это самостоятельно". Однако вы можете окончательно удалить кэшированные представления и ссылки на конфиденциальные данные в запросах на вытягивание GitHub Enterprise Cloud путем обращения к .

Important

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

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

Рассмотрим эти ограничения и проблемы в решении переписать журнал репозитория.

Очистка файла из журнала локального репозитория с помощью репозитория git-filter-repo

  1. Установите последний выпуск git filter-repo средства. Вам нужна версия с флагом --sensitive-data-removal , то есть по крайней мере версия 2.47. Можно установить git filter-repo вручную или с помощью диспетчера пакетов. Например, чтобы установить средство с помощью HomeBrew, используйте команду brew install.

    brew install git-filter-repo

    Дополнительные сведения см. в файле INSTALL.md в репозитории newren/git-filter-repo.

  2. Клонируйте репозиторий на локальный компьютер. См . раздел AUTOTITLE.

    git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY

  3. Перейдите в рабочую папку репозитория.

    cd YOUR-REPOSITORY

  4. git filter-repo Выполните команду, чтобы очистить конфиденциальные данные.

    Если вы хотите удалить определенный файл из всех ветвей/тегов/ссылок, выполните следующую команду, заменив PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA git путь к файлу, который нужно удалить, а не только его имя файла (например: src/module/phone-numbers.txt):

    git filter-repo --sensitive-data-removal --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA

    Important

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

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

    git filter-repo --sensitive-data-removal --replace-text ../passwords.txt

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

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

    $ grep -c '^refs/pull/.*/head$' .git/filter-repo/changed-refs
4

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

    $ grep '^refs/pull/.*/head$' .git/filter-repo/changed-refs
refs/pull/589/head
refs/pull/602/head
refs/pull/604/head
refs/pull/605/head

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

  7. Когда вы довольны состоянием репозитория, принудительно отправьте локальные изменения, чтобы перезаписать репозиторий на GitHub.com. --force Хотя это подразумевается--mirror, мы включим его ниже в качестве напоминания о том, что вы принудительно обновляете все ветви, теги и ссылки, и вы отменяете любые изменения, внесенные другими пользователями, возможно, внесли эти ссылки во время очистки репозитория.

    git push --force --mirror origin

    Эта команда не сможет отправить ссылки, начиная с refs/pull/, так как GitHub Enterprise Cloud помечает их как доступные только для чтения. Эти сбои push-уведомлений будут обрабатываться в следующем разделе. Если другие ссылки не удается отправить, скорее всего, вы включили защиту ветвей для этой ветви и потребуется временно отключить ее и повторно выполнить отправку. Повторяйте до тех пор, пока не будут обновлены только ошибки, начиная refs/pull/с ссылки.

Полное удаление данных с сайта GitHub

После удаления git filter-repo конфиденциальных данных и отправки изменений в GitHub Enterprise Cloudнеобходимо выполнить несколько дополнительных действий, чтобы полностью удалить данные из GitHub Enterprise Cloud.

  1. Обратитесь к и укажите следующие сведения:

    • Имя владельца и репозитория под вопросом (например, YOUR-USERNAME/YOUR-REPOSITORY).
    • Количество затронутых запросов на вытягивание, найденных на предыдущем шаге. Это используется службой поддержки для проверки того, сколько будет затронуто.
    • Первая измененная фиксация, сообщаемая git filter-repo (ищите NOTE: First Changed Commit(s) в выходных данных).)
    • Если NOTE: There were LFS Objects Orphaned by this rewrite отображается в выходных данных репозитория git-filter (сразу после первой измененной фиксации), то упоминается, что объекты LFS потерянные и отправьте именованный файл в билет.

    Если вы успешно очищали все ссылки, отличные от PR, и вилки не имеют ссылок на конфиденциальные данные, поддержка будет выполнять следующие действия:

    • Отмена ссылок или удаление всех затронутых PR на GitHub Enterprise Cloud.

    • Запустите сборку мусора на сервере, чтобы удалить конфиденциальные данные из хранилища.

    • Удаление кэшированных представлений.

    • Если объекты LFS участвуют, удалите и(или) удалите потерянные объекты LFS.

    Important

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

  2. Сотрудники должны перебазировать, а не объединить, какие-либо ветви, созданные из старого (запятнавшего) журнала репозитория. Одна фиксация слияния может снова вернуть некоторые или все испорченные журналы, которые вам только что пришлось очистить. Кроме того, им может потребоваться выполнить дополнительные действия. См. статью "Убедитесь, что другие копии удалены: клоны коллег в ручном руководстве git filter-repo ".

Предотвращение случайных фиксаций в будущем

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

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

  • Если конфиденциальные данные, скорее всего, будут найдены в файле, который не должен отслеживаться git, добавьте это имя .gitignore файла в (и убедитесь, что они фиксируются и отправляют изменения таким .gitignore образом, чтобы другие разработчики были защищены).
  • Избегайте жесткого кода секретов в коде. Используйте переменные среды или службы управления секретами, такие как Azure Key Vault, диспетчер секретов AWS или HashiCorp Vault, для управления секретами и внедрения секретов во время выполнения.
  • Создайте перехватчик предварительной фиксации, чтобы проверить наличие конфиденциальных данных перед фиксацией или отправкой в любое место, или использовать хорошо известный инструмент в перехватчике предварительной фиксации, например git-secret или gitleaks. (Обязательно попросите каждого участника совместной работы настроить выбранный перехватчик предварительной фиксации.)
  • Используйте для фиксации изменений визуальную программу, такую как GitHub Desktop или gitk. Как правило, визуальные программы упрощают просмотр файлов, которые будут добавляться, удаляться и изменяться при каждой фиксации.
  • Избегайте использования в командной строе команд catch-all git add . и git commit -a — используйте git add filename и git rm filename, чтобы подготовить каждый файл по отдельности.
  • Используйте git add --interactive для проверки и подготовки каждого отдельного изменения в каждом файле.
  • Используйте git diff --cached для проверки изменений, подготовленных для фиксации. Это точное несовпадение, которое git commit будет производить до тех пор, пока вы не используете флаг -a.
  • Включите защиту push-уведомлений для репозитория, чтобы обнаруживать и предотвращать отправки, содержащие жестко закодированные секреты, не фиксируются в базе кода. Дополнительные сведения см. в разделе Сведения о защите push-уведомлений.

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