파일 준비, 커밋 메시지 추가, 푸시. 아니 – 기다려! 그 파일이 아닙니다. 이제 인터넷 검색을 시작해야합니다.
모든 개발자는 과거에 실수로 민감한 파일을 커밋했습니다. 그렇다면 상황을 해결하고 다시 발생하지 않도록하려면 어떻게해야합니까?
이 기사에서는 실수로 민감한 파일을 커밋했을 때 수행 할 작업을 설명하고 기록을 조정하는 데 필요한 Git 명령을 포함합니다.
피해 통제
따라서 실수로 민감한 파일을 커밋했습니다. .env 라고 부르 자 . 대답해야 할 두 가지 중요한 질문이 있습니다.
- 커밋을 원격 저장소로 푸시 했습니까?
- 원격 저장소가 공용입니까?
아직 푸시되지 않음
아직 밀지 않았다면 상황은 전혀 중요하지 않습니다. 이전 커밋으로 돌아갈 수 있습니다 .
git reset HEAD^ --soft 민감한 파일 / 정보를 수정할 수 있도록 파일이 작업 사본에 유지됩니다. 커밋 을 유지하고 민감한 파일 만 제거하려면 다음을 수행하십시오.
git rm .env --cached git commit --amend --amend최신 커밋에서만 사용할 수 있습니다 . 그 위에 많은 커밋을 추가했다면 다음을 사용하십시오.
git rebase -i HEAD~{how many commits to go back?} 이렇게하면 잘못된 커밋을 수정할 수 있으며 수정 후 남은 커밋을 모두 재생하므로 손실되지 않습니다.
이미 푸시 됨
푸시를했다면 퍼블릭 리포지토리와 프라이빗 리포지토리 사이에 중요한 차이가 있습니다.
저장소가 비공개이고 액세스 권한이있는 봇이나 사람이없는 경우 위의 두 명령을 사용하여 마지막 커밋을 쉽게 수정할 수 있습니다.
문제가있는 커밋 위에 많은 커밋을 푸시 한 경우에도 filter-branch 또는 BFG repo cleaner를 사용 하여 git 히스토리에서 민감한 파일 을 제거 할 수 있습니다 .
git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all 그러나 이러한 변경 사항의 두 가지 중요한 측면을 염두에 두십시오.
- 당신은 실제로 역사를 바꾸고 있습니다
다른 사람, 다른 브랜치, 다른 포크 또는 리포지토리의 현재 상태에 의존하는 오픈 풀 리퀘스트가 있다면 그것들을 깨뜨릴 것입니다. 이 경우 저장소를 공개 된 것처럼 취급하고 기록을 변경하지 마십시오.
- 캐시를 지워야합니다.
항상 Git 저장소 공급자의 지원에 문의하여 저장소 캐시를 지우도록 요청해야합니다. 문제가있는 커밋을 수정하거나 기록을 다시 작성하더라도 중요한 파일이있는 이전 커밋은 캐시에 남아 있습니다. 액세스하려면 ID를 알아야하지만 캐시를 지울 때까지 계속 액세스 할 수 있습니다.
공용 저장소로 푸시 된 경우 키를 다시 생성해야합니까?
요컨대, 그렇습니다. 저장소가 공개되었거나 다른 이유로 안전한 장소가 아니라고 생각하는 경우 민감한 정보가 손상된 것으로 간주해야합니다.
리포지토리에서 데이터를 제거하더라도 봇 및 리포지토리의 다른 포크에 대해 아무것도 할 수 없습니다. 그럼 다음 단계는 무엇입니까?
- 모든 키 및 / 또는 암호 비활성화
첫 번째 단계로 이것을하십시오. 키를 비활성화하면 민감한 정보는 쓸모 없게됩니다.
- gitignore 조정
모든 민감한 파일을 .gitignore에 추가하여 git이 추적하지 않도록합니다.
- 민감한 파일 제거
- 의미있는 설명과 함께 수정 사항을 커밋합니다.
실수를 숨기려고하지 마십시오. 다른 공동 작업자와 귀하는 한 달 안에 무슨 일이 있었는지에 대한 설명과이 커밋이 수정 한 사항에 감사 할 것입니다.
Git에 민감한 데이터를 저장할 때 모범 사례
앞으로 이와 같은 상황을 방지하기 위해 다음은 민감한 데이터 저장에 대한 몇 가지 팁입니다.
민감한 데이터를 .env 파일 (또는 다른 플랫폼의 유사한 파일)에 보관
API 키 및 기타 민감한 데이터를 단일 .env 파일에 보관합니다. 이렇게하면 .env 파일이 이미 git에서 제외되었을 때 실수로 새 키를 커밋하지 않습니다.
또 다른 큰 이점은 전역 프로세스 변수를 사용하여 모든 키에 액세스 할 수 있다는 것 입니다.
가능한 경우 API 키 사용
API 키는 손상 될 경우 생성 및 비활성화하기 쉽습니다. 가능하면이를 사용하고 자격 증명 / 비밀번호를 사용하지 마십시오.
빌드 도구에 API 키 추가
API 키는 일반적으로 애플리케이션 빌드 중에 필요합니다. Netlify와 같은 빌드 도구를 사용하면 관리의 보안 영역에 이러한 키를 추가 할 수 있습니다. 이러한 키는 전역 프로세스 변수 를 통해 앱에 자동으로 삽입됩니다 .
.env 파일을 gitignore에 추가
Git이 민감한 정보가 포함 된 파일을 추적하지 않도록하십시오.
.env.template 파일 제공
템플릿 파일은 다른 공동 작업자가 긴 문서를 읽을 필요없이 필요한 API 키를 추가하도록 지시합니다.
원격에서 기록을 변경하지 마십시오
이것을 경험의 법칙으로 사용하십시오. 위의 규칙을 따랐다면 기록을 변경할 필요가 없습니다.
이 정보가 안전을 유지하는 데 도움이 되었기를 바랍니다. 헌신적이지 않거나 좋은 교훈을 얻은 개인적인 경험이 있습니까? Twitter에서 저에게 말 해주세요 :-)