InfoGrab Docs

저장소 보호

요약

저장소 보호는 개발 워크플로를 유지하면서 코드베이스에 대한 무단 변경을 방지합니다. 다양한 보호 방법을 결합하면 조직의 기준을 시행하기 위해 함께 작동하는 검증 지점을 만들 수 있습니다. 더 높은 GitLab 티어는 여러 프로젝트 및 그룹에 걸쳐 포괄적인 보안 스캐닝을 적용하고 컴플라이언스를 시행하며 취약점을 관리하는 추가 도구에 액세스할 수 있습니다.

저장소 보호는 개발 워크플로를 유지하면서 코드베이스에 대한 무단 변경을 방지합니다. 이러한 제어는 다음을 포함한 일반적인 개발 과제를 해결하는 데 도움이 됩니다:

  • 프로덕션 또는 보호된 브랜치에 실수로 커밋.
  • 커밋 기록에서 민감한 데이터 노출.
  • 우회된 코드 리뷰 프로세스.
  • 중요한 파일에 대한 무단 변경.
  • 확인되지 않은 커밋 작성자 신원.
  • 메인 브랜치에 들어오는 비준수 코드.

다양한 보호 방법을 결합하면 조직의 기준을 시행하기 위해 함께 작동하는 검증 지점을 만들 수 있습니다.

더 높은 GitLab 티어는 여러 프로젝트 및 그룹에 걸쳐 포괄적인 보안 스캐닝을 적용하고 컴플라이언스를 시행하며 취약점을 관리하는 추가 도구에 액세스할 수 있습니다. 이러한 환경에서는 일부 보호 방법이 이미 조직에서 시행되고 있을 수 있습니다. 이러한 고급 보안 도구에 대한 자세한 내용은 애플리케이션 보안을 참조하십시오.

보호 방법#

GitLab은 저장소를 보호하기 위해 함께 작동하는 여러 보호 방법을 제공합니다. 각 방법은 다른 보안 요구를 처리하며 포괄적인 보호를 위해 결합할 수 있습니다.

보호 방법 설명 사용 시기 인스턴스 그룹 프로젝트
보호된 브랜치 코드 안정성과 품질을 보장하기 위해 브랜치 권한을 제어합니다. 푸시 및 머지할 수 있는 사람을 제어하거나, 실수로 삭제를 방지하거나, 리뷰를 시행하거나, 강제 푸시 권한을 규제합니다. ❌ ✅ ✅
MR 승인 변경 사항이 머지되기 전에 승인이 필요한 리뷰 프로세스. 코드 리뷰를 요구하거나, 승인 규칙을 만들거나, 승인 설정을 구성합니다. ❌ ✅ ✅
푸시 규칙 저장소에 들어오기 전에 커밋, 파일 및 태그를 검증하는 사전 수신 Git 훅. 커밋 내용을 평가하거나, 브랜치 이름 규칙을 시행하거나, 태그 제거를 방지하거나, 서명된 커밋을 요구합니다. ✅ ✅ ✅
코드 소유자 코드베이스의 특정 파일 및 디렉토리에 대한 전문성을 보유한 사람을 정의합니다. 특정 파일 변경에 대한 전문가 승인을 요구하거나 코드 유지 관리를 위한 담당자를 식별합니다. ❌ ❌ ✅
상태 확인 MR 상태를 검증하는 외부 시스템에 대한 API 호출. 타사 워크플로 도구와 통합하거나 외부 품질 요구 사항에 대해 검증합니다. ❌ ❌ ✅

브랜치 규칙#

여러 보호 방법을 관리하는 데 도움을 주기 위해 GitLab은 보호된 브랜치, 승인 규칙 및 상태 확인을 위한 통합된 브랜치 규칙 인터페이스를 제공합니다. 프로젝트 설정의 브랜치 규칙 페이지를 사용하여 한 위치에서 모든 브랜치 보호를 구성하고, 브랜치 전체의 보호 상태를 보고, 복잡한 보호 조합을 관리합니다.

Note

그룹 보호의 경우 그룹 설정에서 보호된 브랜치 및 푸시 규칙을 구성합니다. 브랜치 규칙 페이지는 프로젝트에서만 사용할 수 있습니다. 그룹 규칙은 그룹의 모든 프로젝트에 적용되며 생성한 프로젝트별 규칙과 함께 작동합니다.

보호 전략 구성#

워크플로 및 보안 요구 사항에 따라 보호 방법을 선택합니다. 다음은 예시 전략입니다.

기본 보호#

모든 저장소에 일관된 보안 기준을 설정하려면:

  • 새 프로젝트를 자동으로 보호하기 위해 그룹의 기본 브랜치 보호를 구성합니다.
  • 보호된 브랜치를 설정하여 푸시 및 머지할 수 있는 사람을 제어합니다.
  • 동료 검토를 시행하기 위해 MR 승인을 요구합니다.

포괄적인 보호#

계층화된 보호로 중요한 프로젝트를 보안하려면:

  • 보호된 브랜치 및 승인 규칙을 설정하여 푸시 및 머지할 수 있는 사람을 제어합니다.
  • 민감한 로직이 포함된 파일에 대한 코드 소유자 승인을 요구합니다.
  • 작성자 신원을 확인하기 위해 서명된 커밋을 시행합니다.
  • 자동화된 테스트에 대해 검증하기 위해 상태 확인을 추가합니다.
  • 그룹에 푸시 규칙을 적용하여 모든 프로젝트에 기준을 시행합니다.

목표 보호#

특정 보안 요구 사항을 해결하려면:

  • 파일에 도메인 전문 지식 검토가 필요할 때 코드 소유자 승인을 요구합니다.
  • 커밋 기준 및 콘텐츠 제한을 유지하기 위해 푸시 규칙을 시행합니다.
  • 외부 검증이 필요할 때 상태 확인을 추가합니다.
  • 워크플로별 요구 사항에 대한 승인 규칙을 구성합니다.

시작하기#

전제 조건:

  • 프로젝트에 Maintainer 또는 소유자 역할이 있거나 그룹에 소유자 역할이 있어야 합니다.
  • 보호가 필요한 브랜치를 식별합니다.
  • 컴플라이언스 및 보안 요구 사항을 결정합니다.

저장소 보호를 구성하고 구현하려면:

  1. 범위를 선택합니다:

    • 그룹 규칙의 경우 그룹의 설정 > 저장소로 이동합니다.
    • 프로젝트별 규칙의 경우 프로젝트의 설정 > 저장소 > 브랜치 규칙으로 이동합니다.

  2. 기본 보호를 설정합니다:

    • 기본 브랜치 및 기타 중요한 브랜치에 대한 보호된 브랜치를 만듭니다.
      • 그룹 설정에서: 설정 > 저장소 > 보호된 브랜치.
      • 프로젝트 설정에서: 설정 > 저장소 > 브랜치 규칙.
    • 설정 > Merge requests > MR 승인에서 머지 권한 및 승인 요구 사항을 구성합니다.

  3. 검토 요구 사항을 추가합니다:

    • 특정 파일에 대한 CODEOWNERS 파일에 코드 소유자를 정의합니다.
    • 설정 > Merge requests에서 승인 규칙을 설정합니다.

  4. 보안 제어를 활성화합니다:

    • 푸시 규칙을 구성합니다:
      • 그룹의 경우: 설정 > 저장소 > 푸시 규칙.
      • 프로젝트의 경우: 설정 > 저장소 > 푸시 규칙.
    • 설정 > 저장소 > 푸시 규칙 > 서명되지 않은 커밋 거부에서 서명된 커밋을 활성화합니다.

  5. 구성을 테스트합니다:

    • 테스트 MR을 만듭니다.
    • 보호 규칙이 올바르게 트리거되는지 확인합니다.
    • 결과에 따라 설정을 조정합니다.

관련 주제#

저장소 보호

Tier: Free, Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
원문 보기
요약

저장소 보호는 개발 워크플로를 유지하면서 코드베이스에 대한 무단 변경을 방지합니다. 다양한 보호 방법을 결합하면 조직의 기준을 시행하기 위해 함께 작동하는 검증 지점을 만들 수 있습니다. 더 높은 GitLab 티어는 여러 프로젝트 및 그룹에 걸쳐 포괄적인 보안 스캐닝을 적용하고 컴플라이언스를 시행하며 취약점을 관리하는 추가 도구에 액세스할 수 있습니다.

저장소 보호는 개발 워크플로를 유지하면서 코드베이스에 대한 무단 변경을 방지합니다. 이러한 제어는 다음을 포함한 일반적인 개발 과제를 해결하는 데 도움이 됩니다:

  • 프로덕션 또는 보호된 브랜치에 실수로 커밋.
  • 커밋 기록에서 민감한 데이터 노출.
  • 우회된 코드 리뷰 프로세스.
  • 중요한 파일에 대한 무단 변경.
  • 확인되지 않은 커밋 작성자 신원.
  • 메인 브랜치에 들어오는 비준수 코드.

다양한 보호 방법을 결합하면 조직의 기준을 시행하기 위해 함께 작동하는 검증 지점을 만들 수 있습니다.

더 높은 GitLab 티어는 여러 프로젝트 및 그룹에 걸쳐 포괄적인 보안 스캐닝을 적용하고 컴플라이언스를 시행하며 취약점을 관리하는 추가 도구에 액세스할 수 있습니다. 이러한 환경에서는 일부 보호 방법이 이미 조직에서 시행되고 있을 수 있습니다. 이러한 고급 보안 도구에 대한 자세한 내용은 애플리케이션 보안을 참조하십시오.

보호 방법#

GitLab은 저장소를 보호하기 위해 함께 작동하는 여러 보호 방법을 제공합니다. 각 방법은 다른 보안 요구를 처리하며 포괄적인 보호를 위해 결합할 수 있습니다.

보호 방법 설명 사용 시기 인스턴스 그룹 프로젝트
보호된 브랜치 코드 안정성과 품질을 보장하기 위해 브랜치 권한을 제어합니다. 푸시 및 머지할 수 있는 사람을 제어하거나, 실수로 삭제를 방지하거나, 리뷰를 시행하거나, 강제 푸시 권한을 규제합니다. ❌ ✅ ✅
MR 승인 변경 사항이 머지되기 전에 승인이 필요한 리뷰 프로세스. 코드 리뷰를 요구하거나, 승인 규칙을 만들거나, 승인 설정을 구성합니다. ❌ ✅ ✅
푸시 규칙 저장소에 들어오기 전에 커밋, 파일 및 태그를 검증하는 사전 수신 Git 훅. 커밋 내용을 평가하거나, 브랜치 이름 규칙을 시행하거나, 태그 제거를 방지하거나, 서명된 커밋을 요구합니다. ✅ ✅ ✅
코드 소유자 코드베이스의 특정 파일 및 디렉토리에 대한 전문성을 보유한 사람을 정의합니다. 특정 파일 변경에 대한 전문가 승인을 요구하거나 코드 유지 관리를 위한 담당자를 식별합니다. ❌ ❌ ✅
상태 확인 MR 상태를 검증하는 외부 시스템에 대한 API 호출. 타사 워크플로 도구와 통합하거나 외부 품질 요구 사항에 대해 검증합니다. ❌ ❌ ✅

브랜치 규칙#

여러 보호 방법을 관리하는 데 도움을 주기 위해 GitLab은 보호된 브랜치, 승인 규칙 및 상태 확인을 위한 통합된 브랜치 규칙 인터페이스를 제공합니다. 프로젝트 설정의 브랜치 규칙 페이지를 사용하여 한 위치에서 모든 브랜치 보호를 구성하고, 브랜치 전체의 보호 상태를 보고, 복잡한 보호 조합을 관리합니다.

Note

그룹 보호의 경우 그룹 설정에서 보호된 브랜치 및 푸시 규칙을 구성합니다. 브랜치 규칙 페이지는 프로젝트에서만 사용할 수 있습니다. 그룹 규칙은 그룹의 모든 프로젝트에 적용되며 생성한 프로젝트별 규칙과 함께 작동합니다.

보호 전략 구성#

워크플로 및 보안 요구 사항에 따라 보호 방법을 선택합니다. 다음은 예시 전략입니다.

기본 보호#

모든 저장소에 일관된 보안 기준을 설정하려면:

  • 새 프로젝트를 자동으로 보호하기 위해 그룹의 기본 브랜치 보호를 구성합니다.
  • 보호된 브랜치를 설정하여 푸시 및 머지할 수 있는 사람을 제어합니다.
  • 동료 검토를 시행하기 위해 MR 승인을 요구합니다.

포괄적인 보호#

계층화된 보호로 중요한 프로젝트를 보안하려면:

  • 보호된 브랜치 및 승인 규칙을 설정하여 푸시 및 머지할 수 있는 사람을 제어합니다.
  • 민감한 로직이 포함된 파일에 대한 코드 소유자 승인을 요구합니다.
  • 작성자 신원을 확인하기 위해 서명된 커밋을 시행합니다.
  • 자동화된 테스트에 대해 검증하기 위해 상태 확인을 추가합니다.
  • 그룹에 푸시 규칙을 적용하여 모든 프로젝트에 기준을 시행합니다.

목표 보호#

특정 보안 요구 사항을 해결하려면:

  • 파일에 도메인 전문 지식 검토가 필요할 때 코드 소유자 승인을 요구합니다.
  • 커밋 기준 및 콘텐츠 제한을 유지하기 위해 푸시 규칙을 시행합니다.
  • 외부 검증이 필요할 때 상태 확인을 추가합니다.
  • 워크플로별 요구 사항에 대한 승인 규칙을 구성합니다.

시작하기#

전제 조건:

  • 프로젝트에 Maintainer 또는 소유자 역할이 있거나 그룹에 소유자 역할이 있어야 합니다.
  • 보호가 필요한 브랜치를 식별합니다.
  • 컴플라이언스 및 보안 요구 사항을 결정합니다.

저장소 보호를 구성하고 구현하려면:

  1. 범위를 선택합니다:

    • 그룹 규칙의 경우 그룹의 설정 > 저장소로 이동합니다.
    • 프로젝트별 규칙의 경우 프로젝트의 설정 > 저장소 > 브랜치 규칙으로 이동합니다.

  2. 기본 보호를 설정합니다:

    • 기본 브랜치 및 기타 중요한 브랜치에 대한 보호된 브랜치를 만듭니다.
      • 그룹 설정에서: 설정 > 저장소 > 보호된 브랜치.
      • 프로젝트 설정에서: 설정 > 저장소 > 브랜치 규칙.
    • 설정 > Merge requests > MR 승인에서 머지 권한 및 승인 요구 사항을 구성합니다.

  3. 검토 요구 사항을 추가합니다:

    • 특정 파일에 대한 CODEOWNERS 파일에 코드 소유자를 정의합니다.
    • 설정 > Merge requests에서 승인 규칙을 설정합니다.

  4. 보안 제어를 활성화합니다:

    • 푸시 규칙을 구성합니다:
      • 그룹의 경우: 설정 > 저장소 > 푸시 규칙.
      • 프로젝트의 경우: 설정 > 저장소 > 푸시 규칙.
    • 설정 > 저장소 > 푸시 규칙 > 서명되지 않은 커밋 거부에서 서명된 커밋을 활성화합니다.

  5. 구성을 테스트합니다:

    • 테스트 MR을 만듭니다.
    • 보호 규칙이 올바르게 트리거되는지 확인합니다.
    • 결과에 따라 설정을 조정합니다.

관련 주제#