• 보안 정책 프로젝트
• 정책 설계 지침
  • 정책 시행 설계
  • 업무 분리
• 정책 구현
  • GitLab.com 네임스페이스에서 정책을 전역적으로 시행하기
  • GitLab 전용 또는 GitLab 자체 관리 인스턴스에서 정책을 전역적으로 시행하기
• 보안 정책 프로젝트에 연결하기
  • 연결된 보안 정책 프로젝트 보기
• 정책 권장 사항
  • 브랜치 이름
  • 푸시 규칙
• 정책 관리
• 정책 편집기
• 스크립트를 사용하여 프로젝트를 대량으로 관리하기
• 문제 해결

정책

정책은 보안 및 컴플라이언스 팀이 조직 전체에서 제어를 시행할 수 있는 방법을 제공합니다.

보안 팀은 다음을 보장할 수 있습니다:

• 보안 스캐너가 적절한 구성으로 개발 팀 파이프라인에 적용됩니다.
• 모든 스캔 작업이 변경이나 수정 없이 실행됩니다.
• 해당 발견 결과에 따라 병합 요청에 적절한 승인이 제공됩니다.

컴플라이언스 팀은:

• 모든 병합 요청에서 여러 승인자를 중앙에서 적용할 수 있습니다.
• 병합 요청 및 리포지토리 설정을 활성화하거나 잠그는 등의 조직 요구 사항에 대한 다양한 설정을 프로젝트에 적용할 수 있습니다.

다음 정책 유형이 제공됩니다:

• 스캔 실행 정책. 파이프라인의 일부 또는 지정된 일정에 따라 보안 스캔을 강제합니다.
• 병합 요청 승인 정책. 스캔 결과에 따라 프로젝트 수준 설정 및 승인 규칙을 적용합니다.
• 파이프라인 실행 정책. 프로젝트 파이프라인의 일환으로 CI/CD 작업을 적용합니다.

보안 정책 프로젝트

보안 정책 프로젝트는 정책만을 포함하는 특수 유형의 프로젝트입니다. 정책은 .gitlab/security-policies/policy.yml YAML 파일에 저장됩니다.

보안 정책 프로젝트에 포함된 정책을 시행하려면 이를 프로젝트, 하위 그룹, 그룹, 또는 각 항목의 여러 개에 연결합니다. 보안 정책 프로젝트는 여러 개의 정책을 포함할 수 있지만 동일하게 적용됩니다. 그룹 또는 하위 그룹에서 시행된 보안 정책 프로젝트는 계층 구조 아래의 모든 항목, 모든 하위 그룹 및 해당 프로젝트에 적용됩니다.

병합 요청에서 변경된 정책은 병합 요청이 병합되면 즉시 적용됩니다. 병합 요청을 거치지 않고 기본 브랜치에 직접 커밋된 경우 정책 변경 사항이 적용되기까지 최대 10분이 걸릴 수 있습니다.

정책 설계 지침

정책을 설계할 때 목표는 다음과 같아야 합니다:

• 최소한의 오버헤드로 최대한의 범위를 위한 정책 시행 설계
• 업무 분리 보장

정책 시행 설계

정책 범위를 극대화하려면 목표를 달성할 수 있는 가장 높은 수준에서 보안 정책 프로젝트를 연결하세요: 그룹 수준, 하위 그룹 수준 또는 프로젝트 수준. 가장 높은 수준에서의 시행은 보안 정책 프로젝트 수를 최소화하여 관리 오버헤드를 줄입니다. 정책은 각 수준에서 프로젝트로 내려가며, 그룹 수준, 상위의 각 하위 그룹 및 프로젝트 수준에서 생성된 모든 정책에 대해 시행될 수 있습니다.

정책 상속은 최소한의 보안 정책 프로젝트 수로 최대한의 범위 보장을 보장할 뿐만 아니라 정책 변경을 구현할 때도 도움이 됩니다. 예를 들어, 정책 변경을 테스트하려면 기존 정책을 복사하고 수정된 정책을 먼저 프로젝트에, 다음에 하위 그룹에, 필요한 경우 그룹에 적용할 수 있습니다.

기존 그룹 또는 하위 그룹에서 시행된 정책은 그 아래에서 생성된 모든 새로운 하위 그룹 및 프로젝트에 자동으로 시행됩니다. 단, 다음 조건이 모두 충족되어야 합니다:

• 새 하위 그룹 및 프로젝트가 정책의 범위 정의에 포함됩니다(예: 범위가 이 그룹의 모든 프로젝트를 포함).
• 기존 그룹 또는 하위 그룹이 보안 정책 프로젝트에 이미 연결되어 있습니다.

다음 예시는 두 그룹과 그 구조를 보여줍니다:

• Alpha 그룹은 각각 여러 프로젝트를 포함하는 두 개의 하위 그룹을 포함합니다.
• 보안 및 컴플라이언스 그룹은 두 개의 정책을 포함합니다.

Alpha 그룹 (코드 프로젝트 포함)

• Finance (하위 그룹)
  • 프로젝트 A
  • 계좌 수령 (하위 그룹)
    • 프로젝트 B
    • 프로젝트 C
• Engineering (하위 그룹)
  • 프로젝트 K
  • 프로젝트 L
  • 프로젝트 M

Security and compliance 그룹 (보안 정책 프로젝트 포함)

• 보안 정책 관리
• 보안 정책 관리 - 보안 정책 프로젝트
  • SAST 정책
  • 비밀 감지 정책

정책이 시행되지 않는다고 가정할 때 다음 예를 고려하십시오:

• “SAST” 정책이 Alpha 그룹에서 시행되면 이는 하위 그룹인 Finance와 Engineering, 그리고 그들의 모든 프로젝트 및 하위 그룹에 적용됩니다. “Secret Detection” 정책이 또한 “Accounts receiving” 하위 그룹에서 시행되면 두 정책 모두 프로젝트 B와 C에 적용됩니다. 그러나 “SAST” 정책은 프로젝트 A에는 적용되지 않습니다.
• “SAST” 정책이 “Accounts receiving” 하위 그룹에서 시행되면 이는 프로젝트 B와 C에만 적용됩니다. 프로젝트 A에는 어떤 정책도 적용되지 않습니다.
• “Secret Detection”이 프로젝트 K에서 시행되면 이는 프로젝트 K에만 적용됩니다. 다른 하위 그룹이나 프로젝트에는 어떤 정책도 적용되지 않습니다.

업무 분리

업무 분리는 정책을 성공적으로 구현하는 데 필수적입니다. 필요한 준수 및 보안 요구 사항을 달성하면서 개발 팀이 목표를 달성할 수 있도록 하는 정책을 구현하세요.

보안 및 준수 팀:

• 정책을 정의하고 개발 팀과 협력하여 정책이 그들의 요구를 충족하도록 해야 합니다.

개발 팀:

• 어떠한 식으로든 정책을 비활성화, 수정 또는 우회할 수 없어야 합니다.

그룹, 서브그룹 또는 프로젝트에 대해 보안 정책 프로젝트를 시행하려면 다음 중 하나의 권한이 필요합니다:

• 해당 그룹, 서브그룹 또는 프로젝트의 소유자 역할.
• 해당 그룹, 서브그룹 또는 프로젝트에서 manage_security_policy_link 권한이 있는 사용자 지정 역할.

소유자 역할과 manage_security_policy_link 권한이 있는 사용자 지정 역할은 그룹, 서브그룹 및 프로젝트에 걸쳐 표준 계층 규칙을 따릅니다:

조직 단위	그룹 소유자 또는 그룹 manage_security_policy_link 권한	서브그룹 소유자 또는 서브그룹 manage_security_policy_link 권한	프로젝트 소유자 또는 프로젝트 manage_security_policy_link 권한
그룹	예	아니오	아니오
서브그룹	예	예	아니오
프로젝트	예	예	예

정책 구현

보안 정책 프로젝트의 구현 옵션은 GitLab.com, GitLab 전용 및 GitLab 자체 관리에서 약간 다릅니다. 주요 차이점은 GitLab.com에서는 서브그룹만 생성할 수 있다는 것입니다. 업무 분리를 보장하려면 보다 세부적인 권한 구성이 필요합니다.

GitLab.com 네임스페이스에서 정책을 전역적으로 시행하기

전제 조건:

• 보안 정책 프로젝트에 연결하려면 소유자 역할 또는 manage_security_policy_link 권한이 있는 사용자 지정 역할이 필요합니다. 자세한 내용은 업무 분리를 참조하세요.

GitLab.com 네임스페이스의 모든 서브그룹 및 프로젝트에서 정책을 전역적으로 시행하기 위한 고수준 워크플로우:

1. 상위 그룹의 정책 탭을 방문하세요.

2. 서브그룹에서 정책 탭으로 이동하여 테스트 정책을 만드세요.

   (팁: 테스트를 위해 정책을 비활성화된 상태로 만들 수 있습니다.) 정책을 생성하면 자동으로 상위 그룹 아래에 새로운 보안 정책 프로젝트가 생성됩니다. 이 프로젝트는 policy.yml 또는 정책 대 코드(policy-as-code)를 저장하는 데 사용됩니다.

3. 새로 생성된 프로젝트에서 원하는 대로 권한을 확인하고 설정하세요.

   기본적으로 소유자 및 유지 관리자는 정책을 생성, 편집 및 삭제할 수 있습니다. 개발자는 정책 변경을 제안할 수 있지만 이를 병합할 수는 없습니다.

4. 서브그룹 내에서 생성된 보안 정책 프로젝트에서 필요한 정책을 만드세요.

   정책 탭 아래에서 생성한 Security Policy Management 프로젝트의 정책 편집기를 사용할 수 있습니다. 또는 새로 생성된 보안 정책 프로젝트 Security Policy Management - security policy project에 저장된 policy.yml 파일에서 직접 정책을 업데이트할 수 있습니다.

5. 그룹, 서브그룹 또는 프로젝트를 보안 정책 프로젝트에 연결하세요.

   적절한 권한을 가진 서브그룹 소유자 또는 프로젝트 소유자는 정책 페이지를 방문하여 보안 정책 프로젝트에 대한 링크를 만들 수 있습니다. 전체 경로를 포함하고 프로젝트 이름은 “- security policy project”로 끝나야 합니다. 연결된 모든 그룹, 서브그룹 및 프로젝트는 보안 정책 프로젝트에서 생성된 정책의 “시행 가능” 상태가 됩니다. 자세한 내용은 보안 정책 프로젝트에 링크하기를 참조하세요.

6. 기본적으로 정책이 활성화되면 연결된 그룹, 서브그룹 및 프로젝트의 모든 프로젝트에 시행됩니다.

   보다 세부적인 시행을 위해 “정책 범위”를 추가하세요. 정책 범위를 사용하면 특정 프로젝트 집합에 대해 또는 주어진 준수 프레임워크 레이블 집합이 포함된 프로젝트에 대해 정책을 시행할 수 있습니다.

7. 추가적인 제한이 필요한 경우, 예를 들어 상속된 권한을 차단하거나 정책 변경에 대한 추가 검토 또는 승인을 요구해야 하는 경우, 보안 정책 프로젝트에만 scoped된 추가 정책을 생성하고 추가 승인을 시행할 수 있습니다.

GitLab 전용 또는 GitLab 자체 관리 인스턴스에서 정책을 전역적으로 시행하기

선행 조건:

• 보안 정책 프로젝트에 연결하기 위해 manage_security_policy_link 권한을 가진 소유자 역할 또는 맞춤 역할을 가져야 합니다. 자세한 내용은 업무 분리에 대한 내용을 참조하세요.
• 인스턴스 전역에서 승인 그룹을 지원하기 위해 GitLab 인스턴스 애플리케이션 설정에서 security_policy_global_group_approvers_enabled를 활성화해야 합니다.

여러 그룹에 걸쳐 정책을 시행하기 위한 고급 워크플로우:

1. 정책을 포함할 별도의 그룹을 생성하여 업무 분리를 보장하세요.

   별도의 독립적인 그룹을 생성함으로써 권한을 상속받는 사용자 수를 최소화할 수 있습니다.

2. 새 그룹에서 정책 탭을 방문하세요.

   이는 UI에서 정책을 생성 및 관리할 수 있는 주요 위치로 기능합니다.

3. 테스트 정책을 생성하세요(테스트를 위한 비활성 정책으로 생성할 수 있습니다).

   정책을 생성하는 것은 자동으로 그룹 아래에 새로운 보안 정책 프로젝트를 생성합니다. 이 프로젝트는 policy.yml 또는 코드로서의 정책을 저장하는 데 사용됩니다.

4. 새로 생성된 프로젝트에서 원하는 대로 권한을 확인하고 설정하세요.

   기본적으로 소유자 및 유지 관리자는 정책을 생성, 편집 및 삭제할 수 있습니다. 개발자는 정책 변경을 제안할 수 있지만 이를 병합할 수는 없습니다.

5. 하위 그룹에서 생성된 보안 정책 프로젝트에서 필요한 정책을 생성하세요.

   생성한 Security Policy Management 프로젝트의 정책 탭에서 정책 편집기를 사용할 수 있습니다. 또는 새로 생성된 보안 정책 프로젝트 Security Policy Management - security policy project에 저장된 policy.yml 파일에서 직접 정책을 업데이트할 수 있습니다.

6. 보안 정책 프로젝트에 그룹, 하위 그룹 또는 프로젝트를 연결하세요.

   하위 그룹의 소유자 또는 적절한 권한을 가진 프로젝트 소유자로서 정책 페이지를 방문하여 보안 정책 프로젝트에 대한 링크를 생성할 수 있습니다. 전체 경로를 포함하며, 프로젝트 이름은 “-security policy project”로 끝나야 합니다. 연결된 모든 그룹, 하위 그룹 및 프로젝트는 보안 정책 프로젝트에서 생성된 모든 정책에 의해 “시행 가능”이 됩니다. 자세한 내용은 보안 정책 프로젝트에 연결하기를 참조하세요.

7. 기본적으로 정책이 활성화되면 연결된 그룹, 하위 그룹 및 프로젝트의 모든 프로젝트에 시행됩니다. 보다 세분화된 시행을 원할 경우 정책 범위를 추가하세요. 정책 범위는 특정 프로젝트 집합에 대해 또는 주어진 준수 프레임워크 레이블 집합을 포함한 프로젝트에 대해 정책을 시행할 수 있습니다.

8. 추가적인 제약이 필요한 경우, 예를 들어 상속된 권한을 차단하거나 정책 변경에 대한 추가 검토 또는 승인을 요구하려면 보안 정책 프로젝트에만 국한된 추가 정책을 생성하고 추가 승인을 시행할 수 있습니다.

보안 정책 프로젝트에 연결하기

보안 정책 프로젝트에 포함된 정책을 그룹, 하위 그룹 또는 프로젝트에 대해 시행하기 위해 이들을 연결합니다. 기본적으로 모든 연결된 엔티티는 시행됩니다. 각 정책에 따라 세분화된 정책 시행을 원할 경우 각 정책에 “정책 범위”를 설정할 수 있습니다.

선행 조건:

• 보안 정책 프로젝트에 연결하기 위해 manage_security_policy_link 권한을 가진 소유자 역할 또는 맞춤 역할을 가져야 합니다. 자세한 내용은 업무 분리에 대한 내용을 참조하세요.

그룹, 하위 그룹 또는 프로젝트를 보안 정책 프로젝트에 연결하려면:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트, 하위 그룹 또는 그룹을 찾습니다.

2. 보안 > 정책을 선택하세요.

3. 정책 프로젝트 편집을 선택한 다음, 드롭다운 목록에서 연결할 프로젝트를 검색하고 선택하세요.

4. 저장을 선택하세요.

보안 정책 프로젝트의 연결을 해제하려면 동일한 단계를 따르되 대화상자에서 쓰레기통 아이콘을 선택하세요.

연결된 보안 정책 프로젝트 보기

프로젝트 정책 페이지에 접근할 수 있는 모든 사용자는 프로젝트 소유자가 아닌 경우, 관련 보안 정책 프로젝트에 연결된 버튼을 볼 수 있습니다.

정책 권장 사항

정책을 구현할 때 다음 권장 사항을 고려하세요.

브랜치 이름

정책에서 브랜치 이름을 지정할 때는 기본 브랜치 또는 모든 보호된 브랜치와 같은 보호된 브랜치의 일반적인 범주를 사용해야 합니다. 개별 브랜치 이름은 사용하지 마십시오.

정책은 지정된 브랜치가 해당 프로젝트에 존재할 때만 프로젝트에 적용됩니다. 예를 들어, 귀하의 정책이 main 브랜치에서 규칙을 적용하지만, 범위 내의 일부 프로젝트가 기본 브랜치로 production을 사용하는 경우, 정책은 후자에 대해 적용되지 않습니다.

푸시 규칙

GitLab 17.3 및 이전 버전에서 푸시 규칙을 사용하여 브랜치 이름 검증을 수행할 때는 update-policy- 접두사가 있는 브랜치 생성을 허용하도록 설정해야 합니다. 이 브랜치 이름 접두사는 보안 정책을 생성하거나 수정할 때 사용됩니다. 예를 들어, update-policy-1659094451에서 1659094451은 타임스탬프입니다. 푸시 규칙이 브랜치 생성을 차단하면 다음과 같은 오류가 발생합니다:

브랜치 이름 update-policy-<timestamp>가 패턴 <branch_name_regex>를 따르지 않습니다.

GitLab 17.4 및 이후 버전에서는 브랜치 이름 검증을 적용하는 푸시 규칙에서 보안 정책 프로젝트가 제외됩니다.

정책 관리

정책 페이지에서는 사용 가능한 모든 환경에 배포된 정책을 표시합니다. 정책의 정보(예: 설명 또는 집행 상태)를 확인하고, 배포된 정책을 생성 및 수정할 수 있습니다:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

2. 보안 > 정책을 선택합니다.

정책 편집기

정책 편집기를 사용하여 정책을 생성, 수정 및 삭제합니다:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

2. 보안 > 정책을 선택합니다.
   • 새로운 정책을 생성하려면 정책 새로 만들기를 선택합니다. 이는 정책 페이지의 헤더에 위치해 있습니다. 어떤 유형의 정책을 생성할지 선택할 수 있습니다.
   • 기존 정책을 수정하려면 선택한 정책 드로어에서 정책 수정을 선택합니다.

   정책 편집기에는 두 가지 모드가 있습니다:

   • 시각적 규칙 모드는 규칙 블록 및 관련 컨트롤을 사용하여 정책 규칙을 구성하고 미리 볼 수 있습니다.

     

   • YAML 모드는 .yaml 형식으로 정책 정의를 입력할 수 있으며, 전문가 사용자와 규칙 모드가 지원하지 않는 경우에 적합합니다.

     

     두 가지 모드를 서로 바꿔 가며 사용할 수 있으며 언제든지 전환할 수 있습니다. YAML 리소스가 잘못되었거나 규칙 모드에서 지원하지 않는 데이터를 포함하면 자동으로 규칙 모드가 비활성화됩니다. YAML이 잘못된 경우, 규칙 모드가 다시 사용 가능하려면 YAML 모드를 사용하여 정책을 수정해야 합니다.

3. 변경 사항을 저장하고 적용하려면 병합 요청으로 구성을 선택합니다.

   정책의 YAML가 검증되고 발생한 오류가 표시됩니다.

4. 결과 병합 요청을 검토하고 병합합니다.

   프로젝트 소유자이고 이 프로젝트와 연결된 보안 정책 프로젝트가 없는 경우, 병합 요청이 생성될 때 이 프로젝트에 연결된 보안 정책 프로젝트가 생성됩니다.

스크립트를 사용하여 프로젝트를 대량으로 관리하기

Vulnerability-Check Migration

스크립트를 사용하여 정책을 대량으로 생성하거나 보안 정책 프로젝트를 개발 프로젝트에 연결할 수 있습니다.

Vulnerability-Check Migration 스크립트 사용 방법에 대한 지침 및 시연은 아래를 참조하세요.

Vulnerability-Check 규칙에서 자동화된 스크립트를 사용한 Scan Result Policies로의 마이그레이션.

문제 해결

보안 정책 작업 시 다음 문제 해결 팁을 고려하세요:

• 보안 정책 프로젝트를 개발 프로젝트와 해당 개발 프로젝트가 속하는 그룹 또는 하위 그룹 둘 다에 연결해서는 안 됩니다. 이렇게 연결하면 병합 요청 승인 정책의 승인 규칙이 개발 프로젝트의 병합 요청에 적용되지 않습니다.

• 병합 요청 승인 정책을 만들 때 scan_finding 규칙에서 배열 severity_levels와 배열 vulnerability_states 중 어느 것도 비워둘 수 없습니다. 작동하는 규칙이 되려면 각 배열에 대해 최소한 하나의 항목이 존재해야 합니다.

문제가 지속된다면, 최근 보고된 버그를 확인할 수 있습니다 그리고 새로운 보고되지 않은 문제를 제기할 수 있습니다.