Git 저장소 보안 강화: 모범 사례와 신뢰할 수 없는 소스

Git 저장소를 보호하는 것은 코드를 비공개로 유지하는 것 이상을 의미합니다. 저장소에는 비밀 정보, 실행 가능한 훅, 공급망 위험, 민감한 기록, 그리고 저장소를 클론하는 모든 개발자에게 영향을 미치는 설정이 포함될 수 있습니다.

좋은 Git 보안 관행은 유출된 자격 증명, 안전하지 않은 자동화, 그리고 알 수 없는 소스의 코드에 대한 우발적인 신뢰를 방지하는 데 도움이 됩니다. 기본 사항은 간단하지만 일관되게 적용해야 합니다.

저장소에 도달하기 전에 비밀 정보 보호

가장 안전한 비밀은 저장소에 절대 들어가지 않는 것입니다. API 키, SSH 개인 키, 클라우드 자격 증명, 데이터베이스 비밀번호, 토큰, .env 파일은 Git에서 완전히 제외해야 합니다.

로컬 비밀 파일을 .gitignore에 추가하세요:

.env
.env.*
*.pem
id_rsa
id_ed25519

.env.example에 주의하세요. 이 파일은 종종 유용하지만, 가짜 플레이스홀더 값만 포함해야 합니다:

DATABASE_URL=postgres://user:password@localhost:5432/app
API_TOKEN=replace-me

"테스트용"이라도 실제 값을 붙여넣지 마세요. Git 기록은 나중에 커밋에서 줄을 삭제한 후에도 이전 버전을 기억합니다.

실수로 비밀을 커밋한 경우, 노출된 것으로 간주하세요. 현재 트리에서 제거하고, 해당 비밀을 발급한 서비스에서 자격 증명을 교체한 후, 기록 정리가 필요한지 결정하세요. 기록을 다시 쓰면 향후 노출을 줄이는 데 도움이 될 수 있지만, 비밀이 복사되지 않았음을 보장하지는 않습니다.

팀은 또한 비밀 스캐닝을 사용해야 합니다. 많은 호스팅된 Git 플랫폼에서 일반적인 토큰 패턴에 대한 스캐닝을 제공합니다. 로컬 사전 커밋 도구는 푸시가 서버에 도달하기 전에 실수를 더 일찍 잡을 수 있습니다.

관련 운영 패턴은 환경 변수 마스터하기: 설정 및 비밀을 참조하세요.

접근 및 브랜치 변경 제한

저장소 보안은 접근 제어에서 시작됩니다. 사람들에게 필요한 최소한의 접근 권한을 부여하세요. 코드 리뷰만 하는 사람에게는 관리자 권한이 필요하지 않을 것입니다. CI 서비스 계정에는 브랜치를 다시 쓸 권한이 필요하지 않을 것입니다.

다음 설정을 정기적으로 검토하세요:

저장소 관리자 및 소유자.
쓰기 접근 권한이 있는 협력자.
배포 키 및 머신 사용자.
자동화에 사용되는 개인용 액세스 토큰.
저장소 이벤트를 수신하는 웹훅.
브랜치 보호 규칙.

보호된 브랜치는 가장 유용한 제어 중 하나입니다. main과 같은 중요한 브랜치의 경우, 병합 전에 풀 리퀘스트, 상태 확인, 리뷰를 요구하세요. 팀에 매우 특별한 이유가 없는 한 강제 푸시를 비활성화하세요.

서명된 커밋이나 서명된 태그는 신뢰 수준이 높은 환경에서도 도움이 될 수 있습니다. 그 자체로 코드를 안전하게 만들지는 않지만, 커밋이나 릴리스 태그가 팀이 인식하는 키로 생성되었음을 증명할 수 있습니다.

릴리스에는 태그를 신중하게 사용하세요. 배포 프로세스가 태그를 신뢰하는 경우, 태그를 생성하거나 이동할 수 있는 사람을 제한하세요. 이동된 릴리스 태그는 감사 및 배포를 혼란스럽게 만들 수 있습니다.

신뢰할 수 없는 저장소 주의

신뢰할 수 없는 소스에서 코드를 클론하는 것은 일반적입니다. 즉시 실행하는 것이 위험한 부분입니다. Git 저장소에는 빌드 스크립트, 패키지 라이프사이클 스크립트, Makefile, 컨테이너, CI 설정, 그리고 사용자 머신에서 코드를 실행하는 지침이 포함될 수 있습니다.

무엇이든 실행하기 전에 저장소를 검사하세요:

git clone --no-checkout https://example.com/project.git
cd project
git log --oneline -5
git status

그런 다음 고위험 파일을 확인하세요:

install.sh 또는 bootstrap.sh와 같은 셸 스크립트.
package.json의 패키지 스크립트.
.github/workflows/, .gitlab-ci.yml 또는 유사한 경로의 CI 파일.
Dockerfile 및 compose 파일.
Makefile.
언어별 종속성 매니페스트.

임의의 README에서 curl | bash 설정 명령을 실행하지 마세요. 프로젝트에 설치 프로그램이 필요한 경우, 다운로드하여 읽고, 가능하다면 일회용 환경에서 실행하세요.

Git 훅은 특별히 언급할 가치가 있습니다. .git/hooks/의 훅은 저장소를 클론할 때 일반적으로 활성 훅으로 전송되지 않습니다. 이는 좋은 점입니다. 그러나 저장소에는 훅을 설치하는 스크립트가 포함될 수 있습니다. 이러한 스크립트를 실행하기 전에 읽어보세요. 훅은 커밋, 병합, 리베이스, 푸시 중에 실행될 수 있기 때문입니다.

알 수 없는 코드의 경우 격리를 사용하세요. 임시 가상 머신, 컨테이너 또는 잠긴 개발 환경은 스크립트가 잘못 작동할 경우 피해 범위를 줄입니다. SSH 키, 클라우드 자격 증명 또는 프로덕션 kubeconfig를 신뢰할 수 없는 코드에 사용되는 환경에 마운트하지 마세요.

저장소 기록 및 파일 정리 유지

저장소가 깔끔하면 보안이 더 쉬워집니다. 대용량 바이너리 파일, 생성된 아카이브, 판매된 비밀, 오래된 설정 덤프는 리뷰를 어렵게 만들고 위험을 증가시킵니다.

로컬 파일에는 .gitignore를, 파일 처리 규칙에는 .gitattributes를 사용하세요. 예를 들어:

*.sh text eol=lf
*.png binary
*.jpg binary

프로젝트에 대용량 파일이 필요한 경우, Git Large File Storage가 적합한지 고려하세요. 표준 Git은 거대한 빌드 아티팩트나 미디어 파일에 적합하지 않습니다. 직접 저장하면 클론 속도가 느려지고 민감한 파일 정리가 어려워질 수 있습니다.

애플리케이션 로직뿐만 아니라 보안에 민감한 변경 사항에 대해서도 풀 리퀘스트를 검토하세요. 다음을 주의하세요:

새로운 자격 증명 또는 토큰.
스크립트의 새로운 네트워크 호출.
종속성 소스 변경.
새로운 CI 권한.
배포 스크립트 변경.
중요한 파일을 숨기는 광범위한 .gitignore 변경.

또한 서브모듈에 주의하세요. 서브모듈은 외부 저장소와 특정 커밋을 가리킵니다. 프로젝트에서 서브모듈을 사용하는 경우, 서브모듈 URL과 업데이트를 신중하게 검토하세요.

전문가를 참여시켜야 할 때

비밀이 공개 저장소에 푸시되었거나, 보호된 브랜치가 예기치 않게 강제 푸시되었거나, 알 수 없는 기여자가 CI 또는 배포 자동화를 변경한 경우 보안 엔지니어, DevOps 리드 또는 사고 대응 담당자를 참여시키세요.

또한 저장소 기록이 변조된 것으로 의심되는 경우 도움을 요청해야 합니다. 특히 회사 환경에서는 빠른 정리보다 증거 보존이 더 중요할 수 있습니다.

Git 저장소 보안은 훈련된 신뢰에 달려 있습니다. 비밀을 저장소 밖으로 유지하고, 접근을 제한하며, 중요한 브랜치를 보호하고, 신뢰할 수 없는 코드를 실행하기 전에 검사하세요. 이러한 습관은 대부분의 저장소 보안 문제가 사고로 발전하기 전에 예방합니다.