리포지토리에서 중요한 데이터 제거 정보
git filter-repo와 같은 도구를 사용하여 리포지토리의 기록을 변경할 때는 그 의미를 이해하는 것이 중요합니다. 기록을 다시 작성하려면 공동 작업자와 신중하게 조정하여 성공적으로 실행해야 하며 관리해야 하는 여러 가지 부작용이 있습니다.
제거해야 하는 중요한 데이터가 비밀(예: 암호/토큰/자격 증명)인 경우와 마찬가지로 첫 번째 단계로 해당 비밀을 해지 및/또는 회전해야 합니다. 비밀이 해지되거나 회전되면 더 이상 액세스에 사용할 수 없으며 문제를 해결하는 데 충분할 수 있습니다. 기록을 다시 작성하고 비밀을 제거하는 추가 단계를 거치는 것은 보증되지 않을 수 있습니다.
다시 쓰기 기록의 부작용
기록을 다시 작성하면 다음과 같은 부작용이 발생할 수 있습니다.
- 재확산 위험 높음: 안타깝지만, 중요한 데이터를 리포지토리에 다시 푸시하여 더 큰 혼란을 만들기 쉽습니다. 동료 개발자가 다시 쓰기 전의 복제본을 가지고 있고 다시 쓰기한 후 단순히
git pull을 실행된 후git push를 실행하면 중요한 데이터가 반환됩니다. 복제본을 삭제하고 다시 복제하거나 여러 단계를 신중하게 진행하여 먼저 복제본을 정리해야 합니다. - 다른 개발자의 작업 손실 위험: 다른 개발자가 정리를 시도하는 동안 중요한 데이터가 포함된 분기를 계속 업데이트하는 경우 정리를 다시 실행하거나 작업을 취소해야 합니다.
- 변경된 커밋 해시: 기록을 다시 작성하면 중요한 데이터 _ 및 _ 이후에 제공된 모든 커밋을 도입한 커밋의 해시가 변경됩니다. 변경되지 않는 커밋 해시에 의존하는 모든 도구나 자동화가 손상되거나 문제가 발생합니다.
- 분기 보호 문제: 강제 푸시를 방지하는 분기 보호가 있는 경우 중요한 데이터를 제거하려면 해당 보호를 해제(적어도 일시적으로)해야 합니다.
- 닫힌 끌어오기 요청에 대한 끊어진 Diff 뷰: 중요한 데이터를 제거하려면 끌어오기 요청에서 diff 뷰를 표시하는 데 사용되는 내부 참조를 제거해야 하므로 이러한 diff는 더 이상 볼 수 없습니다. 이는 중요한 데이터를 도입한 PR뿐만 아니라 중요한 데이터 PR이 병합된 후 기록 버전에서 빌드되는 PR에도 해당됩니다(이후 PR이 중요한 데이터를 사용하여 파일을 추가하거나 수정하지 않은 경우에도 마찬가지).
- 열린 끌어오기 요청과의 잘못된 상호 작용: 변경된 커밋 SHA는 다른 PR diff로 인해 발생하며, 이전 PR diff에 대한 주석이 무효화되고 손실되어 작성자와 검토자에게 혼동을 줄 수 있습니다. 리포지토리에서 파일을 제거하기 전에 모든 열려 있는 끌어오기 요청을 병합하거나 닫는 것이 좋습니다.
- 커밋 및 태그에 대한 서명 손실: 커밋이나 태그에 대한 서명은 커밋 해시에 따라 달라집니다. 커밋 해시는 기록 다시 쓰기에 의해 수정되므로 서명은 더 이상 유효하지 않으며 많은 기록 다시 쓰기 도구(
git filter-repo포함)는 단순히 서명을 제거합니다. 실제로git filter-repo는 중요한 데이터 제거 이전의 커밋에 대한 커밋 서명과 태그 서명을 제거합니다. (기술적으로 필요한 경우--refs옵션을git filter-repo로 변경하여 이 문제를 해결할 수 있지만, 기록에 중요한 데이터가 있고 범위에서 중요한 데이터를 도입한 커밋을 포함하는 모든 참조를 지정하도록 주의해야 합니다.) - 다른 사용자를 중요한 데이터로 직접 연결: Git은 커밋 식별자에 기본 제공된 암호화 검사를 사용하여 설계되었으므로 악의적인 개인이 서버에 침입하여 기록을 수정할 수 없습니다. 이는 보안 관점에서 유용하지만 중요한 데이터 관점에서 중요한 데이터를 삭제하는 것은 매우 관련된 조정 프로세스라는 것을 의미합니다. 또한 기록을 수정할 때 기존 클론이 있는 단서가 있는 사용자는 기록 차이를 확인하고 이를 사용하여 중앙 리포지토리에서 제거한 복제에서 중요한 데이터를 빠르고 쉽게 찾을 수 있습니다.
중요한 데이터 노출 정보
리포지토리에서 중요한 데이터를 제거하려면 다음 네 가지 고급 단계가 포함됩니다.
- git-filter-repo를 사용하여 리포지토리를 로컬로 다시 작성
- 로컬로 다시 작성된 기록을 사용하여 GitHub에서 리포지토리 업데이트
- 동료와 협력하여 존재하는 다른 클론을 정리
- 반복 방지 및 향후 중요한 데이터 유출 방지
기록을 다시 작성하고 강제로 푸시하는 경우 중요한 데이터가 있는 커밋은 다른 곳에서도 계속 액세스할 수 있습니다.
- 리포지토리의 모든 클론 또는 포크에서
- GitHub Enterprise Cloud의 캐시된 뷰에서 SHA-1 해시를 통해 직접
- 이를 참조하는 끌어오기 요청을 통해
다른 사용자의 클론 또는 리포지토리 포크에서 중요한 데이터를 제거할 수는 없지만 GitHub 지원 포털 사용.에 문의하여 GitHub Enterprise Cloud에 대한 끌어오기 요청에서 캐시된 뷰 및 중요한 데이터에 대한 참조를 제거할 수 있습니다.
Important
GitHub 지원은(는) 중요하지 않은 데이터를 제거하지 않으며 영향을 받는 자격 증명을 순환하여 위험을 완화할 수 없다고 판단되는 경우에 중요한 데이터를 제거하는 데 도움이 됩니다.
중요한 데이터를 도입한 커밋이 모든 포크에 있는 경우 계속 액세스할 수 있습니다. 포크 소유자와 조정하여 중요한 데이터를 제거하거나 포크를 완전히 삭제하도록 요청해야 합니다. GitHub은(는) 이러한 소유자에 대한 연락처 정보를 제공할 수 없습니다.
리포지토리의 기록을 다시 작성하기로 결정할 때 이러한 제한 사항을 고려하세요.
git-filter-repo를 사용하여 리포지토리의 기록에서 파일 제거
Warning
변경 내용을 스태시한 후에 git filter-repo를 실행할 경우 다른 스태시 명령을 사용하여 변경 내용을 가져올 수 없습니다. git filter-repo를 실행하기 전에, 적용한 모든 변경 내용을 스태시 해제하는 것이 좋습니다. 스태시한 마지막 변경 내용 세트를 스태시 해제하려면 git stash show -p | git apply -R을 실행합니다. 자세한 내용은 Git 도구 - 스태시 및 정리를 참조하세요.
git filter-repo가 작동하는 방식을 설명하기 위해, 리포지토리 기록에서 중요한 데이터를 포함하는 파일을 제거한 다음 실수로 다시 커밋되지 않도록 .gitignore에 추가하는 방법을 보여 드리겠습니다.
-
git filter-repo 도구의 최신 릴리스를 설치합니다.
git-filter-repo는 수동으로 설치하거나 패키지 관리자를 사용하여 설치할 수도 있습니다. 예를 들어, HomeBrew를 사용하여 도구를 설치하려면brew install명령을 사용하세요.brew install git-filter-repo자세한 내용은
newren/git-filter-repo리포지토리의 INSTALL.md를 참조하세요. -
기록에 중요한 데이터가 포함된 리포지토리의 로컬 복사본이 아직 없다면 로컬 컴퓨터에 리포지토리를 복제합니다.
$ git clone https://github.com/YOUR-USERNAME/YOUR-REPOSITORY > Initialized empty Git repository in /Users/YOUR-FILE-PATH/YOUR-REPOSITORY/.git/ > remote: Counting objects: 1301, done. > remote: Compressing objects: 100% (769/769), done. > remote: Total 1301 (delta 724), reused 910 (delta 522) > Receiving objects: 100% (1301/1301), 164.39 KiB, done. > Resolving deltas: 100% (724/724), done. -
리포지토리의 작업 디렉터리로 이동합니다.
cd YOUR-REPOSITORY -
아래의 명령에서
PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA를 (파일 이름이 아닌) 제거할 파일의 경로로 바꾸어서 실행합니다. 이 인수를 사용하면 다음과 같은 작업이 수행됩니다.-
Git이 모든 분기와 태그의 전체 기록을 강제로 처리합니다(체크아웃하지 않음).
-
지정된 파일과 그 결과로 생성된 빈 커밋을 제거합니다.
-
.git/config 파일에 저장된 일부 구성(예: 원격 URL)을 제거합니다. 이 파일은 나중에 복원할 수 있도록 미리 백업해두는 것이 좋습니다.
-
기존 태그 덮어쓰기
$ git filter-repo --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA Parsed 197 commits New history written in 0.11 seconds; now repacking/cleaning... Repacking your repo and cleaning out old unneeded objects Enumerating objects: 210, done. Counting objects: 100% (210/210), done. Delta compression using up to 12 threads Compressing objects: 100% (127/127), done. Writing objects: 100% (210/210), done. Building bitmaps: 100% (48/48), done. Total 210 (delta 98), reused 144 (delta 75), pack-reused 0 Completely finished after 0.64 seconds.Important
중요한 데이터를 포함하는 파일이 이동되었거나 이름이 바뀌어서 다른 경로에 있다면 변경된 경로에 대해서도 이 명령을 실행해야 합니다.
-
-
리포지토리의 기록에서 원하는 모든 항목을 제거했는지 다시 확인합니다.
-
git filter-repo도구는 구성된 원격을 자동으로 제거합니다.git remote set-url명령을 사용하여 원격을 복원합니다. 여기서OWNER및REPO를 리포지토리 세부 정보로 바꿉니다. 자세한 내용은 원격 리포지토리 관리을(를) 참조하세요.git remote add origin https://github.com/OWNER/REPOSITORY.git -
리포지토리의 상태에 만족하고 적절한 원격을 설정했다면 로컬 변경 내용을 강제로 푸시하여 GitHub.com에 리포지토리를 덮어쓰세요. 커밋 기록에서 중요한 데이터를 제거하려면 강제 푸시가 필요합니다.
$ git push origin --force --all > Counting objects: 1074, done. > Delta compression using 2 threads. > Compressing objects: 100% (677/677), done. > Writing objects: 100% (1058/1058), 148.85 KiB, done. > Total 1058 (delta 590), reused 602 (delta 378) > To https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git > + 48dc599...051452f main -> main (forced update) -
태그된 릴리스에서 중요한 파일을 제거하려면 Git 태그에 대해서도 강제로 푸시해야 합니다.
$ git push origin --force --tags > Counting objects: 321, done. > Delta compression using up to 8 threads. > Compressing objects: 100% (166/166), done. > Writing objects: 100% (321/321), 331.74 KiB | 0 bytes/s, done. > Total 321 (delta 124), reused 269 (delta 108) > To https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git > + 48dc599...051452f main -> main (forced update)
GitHub에서 데이터 완전히 제거
git filter-repo를 사용하여 중요한 데이터를 제거하고 변경 내용을 GitHub Enterprise Cloud에 푸시한 후에는 GitHub Enterprise Cloud에서 데이터를 완전히 제거하려면 몇 가지 단계를 더 수행해야 합니다.
-
GitHub Enterprise Importer을(를) 사용하여 리포지토리를 마이그레이션한 경우 패턴
refs/github-services를 따르거나 BFG 도구 또는git filter-repo로 제거할 수 없는 일부 비표준 Git 참조가 있을 수 있습니다. 이 경우 리포지토리의 로컬 복사본에서 다음 명령을 실행하는 참조를 제거합니다.# fetch all refs git ls-remote | grep refs/github-services | cut -f2 | sort -t'/' -k3,4n > github-services-refs.txt # inspect and validate refs to be deleted cat github-services-refs.txt # delete refs in batches export BATCH_SIZE=512 cat github-services-refs.txt | xargs -n $BATCH_SIZE git push origin --delete -
GitHub 지원 포털 사용에 문의하여 GitHub Enterprise Cloud에 대한 끌어오기 요청에서 캐시된 뷰 및 중요한 데이터에 대한 참조를 제거하도록 요청합니다. 리포지토리의 이름 및/또는 제거해야 하는 커밋에 대한 링크를 제공하세요.
Important
GitHub 지원은(는) 중요하지 않은 데이터를 제거하지 않으며 영향을 받는 자격 증명을 순환하여 위험을 완화할 수 없다고 판단되는 경우에 중요한 데이터를 제거하는 데 도움이 됩니다.
-
협력자에게 이전(오염된) 리포지토리 기록에서 만든 분기를 병합하지 ‘않고’ 다시 지정하도록 지시합니다.__ 하나의 병합 커밋은 방금 제거했던 오염된 기록의 일부 또는 전부를 다시 도입할 수 있습니다.
향후 실수로 인한 커밋 방지
기여자가 실수로 커밋하지 못하게 하면 중요한 정보가 노출되지 않도록 방지할 수 있습니다. 자세한 내용은 조직에서 데이터 유출을 방지하기 위한 모범 사례을(를) 참조하세요.
공유해서는 안 되는 항목을 커밋하거나 푸시하지 않도록 하기 위해 수행할 수 있는 몇 가지 작업은 다음과 같습니다.
- git에서 추적하지 않아야 하는 파일에서 중요한 데이터를 찾을 수 있는 경우 해당 파일 이름을
.gitignore에 추가합니다(그리고 다른 개발자가 보호되도록 해당 변경 내용을.gitignore에 커밋하고 푸시해야 함). - 코드에서 비밀 하드코딩을 방지합니다. 환경 변수 또는 Azure Key Vault, AWS Secrets Manager, HashiCorp Vault와 같은 비밀 관리 서비스를 사용하여 런타임에 비밀을 관리하고 삽입합니다.
- 커밋되거나 다른 곳으로 푸시되기 전에 중요한 데이터를 확인하는 사전 커밋 후크를 만들거나 git-secrets나 gitleaks와 같은 사전 커밋 후크에서 잘 알려진 도구를 사용합니다. (선택한 사전 커밋 후크를 설정하도록 각 공동 작업자에게 요청해야 합니다.)
- GitHub Desktop 또는 gitk와 같은 시각적 프로그램을 사용하여 변경 내용을 커밋합니다. 시각적 프로그램을 사용하면 일반적으로 각 커밋을 통해 추가, 삭제 및 수정할 파일을 정확하고 쉽게 확인할 수 있습니다.
- 대신 catch-all 명령
git add .와 명령줄의git commit -a을 사용하지 말고git add filename과git rm filename을 사용하여 파일을 개별적으로 스테이징하세요. - 각 파일 내에서 변경 내용을 개별적으로 검토하고 스테이징하는 데
git add --interactive를 사용합니다. - 커밋을 위해 스테이징한 변경 내용을 검토하는 데
git diff --cached를 사용합니다.-a플래그를 사용하지 않는 한git commit에서 생성되는 정확한 차이입니다. - 리포지토리에 대한 푸시 보호를 사용하도록 설정하여 하드 코딩된 비밀이 포함된 푸시가 코드베이스에 커밋되지 않도록 탐지하고 방지합니다. 자세한 내용은 푸시 보호 정보을(를) 참조하세요.