저장소 보호
GitLab v19.5Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
요약
리포지터리 보호는 개발 워크플로를 유지하면서 코드베이스에 대한 무단 변경을 막습니다. 여러 보호 방법을 조합하면 조직의 기준을 강제하기 위해 함께 작동하는 검증 지점을 만들 수 있습니다. 상위 GitLab 티어에서는 여러 프로젝트와 그룹에 걸쳐 포괄적인 보안 스캐닝을 적용하고, 컴플라이언스를 강제하며, 취약점을 관리하는 추가 도구를 사용할 수 있습니다.
리포지터리 보호는 개발 워크플로를 유지하면서 코드베이스에 대한 무단 변경을 막습니다. 이러한 제어는 다음을 비롯한 일반적인 개발 과제를 해결하는 데 도움이 됩니다.
- 프로덕션 브랜치나 보호된 브랜치에 실수로 커밋하는 경우.
- 커밋 이력에 민감한 데이터가 노출되는 경우.
- 코드 리뷰 절차가 우회되는 경우.
- 중요한 파일이 무단으로 변경되는 경우.
- 커밋 작성자가 검증되지 않은 경우.
- 기준에 맞지 않는 코드가 메인 브랜치로 들어오는 경우.
여러 보호 방법을 조합하면 조직의 기준을 강제하기 위해 함께 작동하는 검증 지점을 만들 수 있습니다.
상위 GitLab 티어에서는 여러 프로젝트와 그룹에 걸쳐 포괄적인 보안 스캐닝을 적용하고, 컴플라이언스를 강제하며, 취약점을 관리하는 추가 도구를 사용할 수 있습니다. 이러한 환경에서는 일부 보호 방법이 이미 조직 차원에서 강제되고 있을 수 있습니다. 이 고급 보안 도구에 대한 자세한 내용은 애플리케이션 보안을 참고합니다.
보호 방법#
GitLab은 리포지터리를 보호하기 위해 함께 작동하는 여러 보호 방법을 제공합니다. 각 방법은 서로 다른 보안 요구를 다루며, 포괄적인 보호를 위해 조합할 수 있습니다.
| 보호 방법 | 설명 | 사용 시기 | 인스턴스 | 그룹 | 프로젝트 |
|---|---|---|---|---|---|
| 보호된 브랜치 | 코드 안정성과 품질을 보장하기 위해 브랜치 권한을 제어합니다. | 푸시와 머지를 할 수 있는 대상을 제어하거나, 실수로 인한 삭제를 방지하거나, 리뷰를 강제하거나, 강제 푸시 권한을 규제합니다. | ❌ | ✅ | ✅ |
| 머지 리퀘스트 승인 | 변경 사항을 머지하기 전에 승인을 요구하는 리뷰 절차입니다. | 코드 리뷰를 요구하거나, 승인 규칙을 만들거나, 승인 설정을 구성합니다. | ❌ | ✅ | ✅ |
| 푸시 규칙 | 커밋, 파일, 태그가 리포지터리에 들어오기 전에 검증하는 pre-receive Git 훅입니다. | 커밋 내용을 평가하거나, 브랜치 이름 규칙을 강제하거나, 태그 삭제를 막거나, 서명된 커밋을 요구합니다. | ✅ | ✅ | ✅ |
| Code Owners | 코드베이스의 특정 파일과 디렉터리에 대해 전문성을 가진 대상을 정의합니다. | 특정 파일 변경에 전문가 승인을 요구하거나, 코드 유지 관리 담당자를 식별합니다. | ❌ | ❌ | ✅ |
| 상태 확인 | 머지 리퀘스트 상태를 검증하는 외부 시스템 API 호출입니다. | 서드파티 워크플로 도구와 통합하거나, 외부 품질 요구 사항에 맞춰 검증합니다. | ❌ | ❌ | ✅ |
브랜치 규칙#
여러 보호 방법을 관리할 수 있도록 GitLab은 보호된 브랜치, 승인 규칙, 상태 확인을 위한 통합 브랜치 규칙 인터페이스를 제공합니다. 프로젝트 설정의 Branch rules 페이지에서 모든 브랜치 보호를 한곳에서 구성하고, 브랜치 전반의 보호 상태를 확인하며, 복잡한 보호 조합을 관리합니다.
그룹 보호는 그룹 설정에서 보호된 브랜치와 푸시 규칙을 구성합니다. Branch rules 페이지는 프로젝트에서만 사용할 수 있습니다. 그룹 규칙은 그룹 내 모든 프로젝트에 적용되며, 프로젝트별로 만든 규칙과 함께 작동합니다.
보호 전략 구성#
워크플로와 보안 요구 사항에 따라 보호 방법을 선택합니다. 다음은 전략 예시입니다.
기본 보호#
모든 리포지터리에 일관된 보안 기준을 세우려면 다음을 수행합니다.
- 새 프로젝트를 자동으로 보호하도록 그룹의 기본 브랜치 보호를 구성합니다.
- 푸시와 머지를 할 수 있는 대상을 제어하도록 보호된 브랜치를 설정합니다.
- 동료 리뷰를 강제하도록 머지 리퀘스트 승인을 요구합니다.
포괄적 보호#
계층화된 보호로 중요한 프로젝트를 보호하려면 다음을 수행합니다.
- 푸시와 머지를 할 수 있는 대상을 제어하도록 보호된 브랜치와 승인 규칙을 설정합니다.
- 민감한 로직이 들어 있는 파일에 Code Owner 승인을 요구합니다.
- 작성자 신원을 확인하도록 서명된 커밋을 강제합니다.
- 자동화된 테스트로 검증하도록 상태 확인을 추가합니다.
- 모든 프로젝트에 기준을 강제하도록 그룹에 푸시 규칙을 적용합니다.
선택적 보호#
특정 보안 요구 사항을 해결하려면 다음을 수행합니다.
- 파일에 도메인 전문성 리뷰가 필요할 때 Code Owner 승인을 요구합니다.
- 커밋 기준과 콘텐츠 제한을 유지하도록 푸시 규칙을 강제합니다.
- 외부 검증이 필요할 때 상태 확인을 추가합니다.
- 워크플로별 요구 사항에 맞춰 승인 규칙을 구성합니다.
시작하기#
사전 요구 사항:
- 프로젝트에 대한 Maintainer 또는 Owner 권한, 또는 그룹에 대한 Owner 권한이 있어야 합니다.
- 보호가 필요한 브랜치를 식별합니다.
- 컴플라이언스 및 보안 요구 사항을 결정합니다.
리포지터리 보호를 구성하고 적용하려면 다음 단계를 수행합니다.
-
범위를 선택합니다.
- 그룹 규칙은 그룹의 Settings > Repository로 이동합니다.
- 프로젝트별 규칙은 프로젝트의 Settings > Repository > Branch rules로 이동합니다.
-
기본 보호를 설정합니다.
- 기본 브랜치와 그 밖의 중요한 브랜치에 보호된 브랜치를 만듭니다.
- 그룹 설정에서는 Settings > Repository > Protected branches.
- 프로젝트 설정에서는 Settings > Repository > Branch rules.
- Settings > Merge requests > Merge request approvals에서 머지 권한과 승인 요구 사항을 구성합니다.
- 기본 브랜치와 그 밖의 중요한 브랜치에 보호된 브랜치를 만듭니다.
-
리뷰 요구 사항을 추가합니다.
- 특정 파일에 대해
CODEOWNERS파일에 Code Owner를 정의합니다. - Settings > Merge requests에서 승인 규칙을 설정합니다.
- 특정 파일에 대해
-
보안 제어를 활성화합니다.
- 푸시 규칙을 구성합니다.
- 그룹은 Settings > Repository > Push rules.
- 프로젝트는 Settings > Repository > Push rules.
- Settings > Repository > Push rules > Reject unsigned commits에서 서명된 커밋을 활성화합니다.
- 푸시 규칙을 구성합니다.
-
구성을 테스트합니다.
- 테스트용 머지 리퀘스트를 만듭니다.
- 보호 규칙이 올바르게 동작하는지 확인합니다.
- 결과에 따라 설정을 조정합니다.