• 보안 정책 프로젝트
• 정책 설계 지침
  • 정책 강제 적용 설계
  • 책임의 분리
• 정책 구현
  • GitLab.com 네임스페이스 전역으로 정책 강제 적용
  • GitLab Dedicated 또는 GitLab Self-managed 인스턴스 전역으로 정책 강제 적용
• 보안 정책 프로젝트에 링크
  • 연결된 보안 정책 프로젝트 보기
• 정책 권고 사항
  • 브랜치 이름
  • 푸시 규칙
• 정책 관리
• 정책 편집기
• 스크립트를 사용하여 프로젝트 일괄 관리
• 문제 해결

정책

정책은 보안 및 규정 준수 팀이 조직 내에서 전역적으로 통제를 강화하기 위한 방법을 제공합니다.

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

• 개발팀 파이프라인에서 보안 스캐너가 적절히 구성되어 강제 적용됨.
• 모든 스캔 작업이 변경이나 수정 없이 실행됨.
• 스캔 결과를 기반으로 병합 요청에 적절한 승인이 제공됨.

규정 준수 팀은 다음을 수행할 수 있습니다:

• 모든 병합 요청에 여러 승인자를 중앙적으로 강제 적용
• 조직적 요구 사항 범위 내의 프로젝트에서 여러 설정을 강제 적용, 예를 들어 병합 요청 및 저장소 설정 활성화 또는 잠금

다음과 같은 정책 유형이 있습니다:

• 스캔 실행 정책. 파이프라인이나 지정된 일정의 일부로 보안 스캔을 강제 적용
• 병합 요청 승인 정책. 프로젝트 수준의 설정과 승인 규칙을 스캔 결과에 기반하여 강제 적용
• 파이프라인 실행 정책. 프로젝트 파이프라인의 일부로 CI/CD 작업 강제 적용

보안 정책 프로젝트

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

보안 정책 프로젝트에 포함된 정책을 강제 적용하려면 프로젝트, 서브그룹, 그룹 또는 각각의 여러 항목에 연결합니다. 보안 정책 프로젝트에는 여러 정책이 포함될 수 있지만 함께 강제 적용됩니다. 그룹 또는 서브그룹에 강제 적용된 보안 정책 프로젝트는 하위 모든 항목, 즉 모든 서브그룹 및 해당 프로젝트를 포함한 하위 모든 항목에 적용됩니다.

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

정책 설계 지침

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

• 최소한의 오버헤드로 정책 강제 적용 설계
• 책임의 분리 보장

정책 강제 적용 설계

정책 범위를 최대화하기 위해 보안 정책 프로젝트를 달성하려는 최상위 수준에 링크하십시오: 그룹 수준, 서브그룹 수준 또는 프로젝트 수준. 최상위 수준에서의 강제 적용은 보안 정책 프로젝트 수 및 따라서 관리 오버헤드를 최소화합니다. 정책은 각 수준에서 프로젝트로 내려가며 그룹 수준, 그것보다 상위의 각 서브그룹에서, 그리고 프로젝트 자체에서 만든 정책에 따라 강제 적용됩니다.

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

기존 그룹이나 서브그룹에 강제 적용된 정책은 해당 그룹 또는 서브그룹에 이미 연결된 경우 새로 생성된 서브그룹과 프로젝트에 자동으로 강제 적용됩니다. 모든 다음 사항이 모두 참인 경우 새로 생성된 서브그룹 및 프로젝트가 정책의 범위 정의에 포함된 경우 (예: 이 그룹의 모든 프로젝트에 적용) 정책 정의의 유효 범위가 모두 참인 경우 (예: 그룹이 보안 정책 프로젝트에 연결되어 있음).

참고: GitLab SaaS 사용자는 자체 SaaS 최상위 그룹 간에 정책을 강제 적용할 수 없지만, 해당 기능을 사용하여 자신의 최상위 그룹이나 서브그룹 전반에 걸쳐 정책을 강제 적용할 수 있습니다. GitLab self-managed 사용자는 자신의 인스턴스에서 여러 최상위 그룹에 걸쳐 정책을 강제 적용할 수 있습니다.

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

• 알파 그룹에는 각각 다수의 프로젝트를 포함하는 두 개의 서브그룹이 있습니다.
• 보안 및 규정 준수 그룹에는 두 개의 정책이 있습니다.

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

• 금융 (서브그룹)
  • 프로젝트 A
  • 수령 계정 (서브그룹)
    • 프로젝트 B
    • 프로젝트 C
• 공학 (서브그룹)
  • 프로젝트 K
  • 프로젝트 L
  • 프로젝트 M

보안 및 규정 준수 그룹 (보안 정책 프로젝트 포함)

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

강제 적용되는 정책이 없다고 가정할 때 다음 예를 고려해 보십시오:

• “SAST” 정책이 알파 그룹에서 강제 적용되면 해당 서브그룹인 금융 및 공학 및 모든 프로젝트 및 해당 서브그룹에 적용됩니다. 또한 “비밀 탐지” 정책이 “수령 계정” 서브그룹에서도 강제 적용되면 두 정책이 프로젝트 B 및 C에 모두 적용됩니다. 그러나 프로젝트 A에는 “SAST” 정책만 적용됩니다.
• “SAST” 정책이 “수령 계정” 서브그룹에서 강제 적용되면 프로젝트 B 및 C에만 적용됩니다. 프로젝트 A에는 정책이 적용되지 않습니다.
• “비밀 탐지” 정책이 프로젝트 K에서 강제 적용되면 프로젝트 K에만 적용됩니다. 다른 서브그룹 또는 프로젝트에는 정책이 적용되지 않습니다.

책임의 분리

책임의 분리는 정책을 성공적으로 구현하는 데 중요합니다. 필요한 규정 준수 및 보안 요구 사항을 충족하면서 개발 팀이 목표를 달성할 수 있도록 하는 정책을 시행하세요.

보안 및 규정 준수 팀:

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

개발 팀:

• 정책을 비활성화하거나 수정하거나 정책을 우회할 수 없어야 합니다.

그룹, 서브그룹 또는 프로젝트에 보안 정책 프로젝트를 강제 적용하려면:

• 해당 그룹, 서브그룹 또는 프로젝트에서 소유자 권한이 있어야 합니다.
• 해당 그룹, 서브그룹 또는 프로젝트에서 manage_security_policy_link 권한을 가진 사용자 정의 역할을 가져야 합니다.

그룹, 서브그룹 및 프로젝트 간의 표준 계층 구조 규칙을 따르는 소유자 역할 및 manage_security_policy_link 권한을 가진 사용자 정의 역할은 다음과 같습니다:

정책 구현

보안 정책 프로젝트의 구현 옵션은 GitLab.com, GitLab Dedicated 및 GitLab self-managed에 약간의 차이가 있습니다. 가장 큰 차이점은 GitLab.com에서 서브그룹만 생성할 수 있다는 점입니다. 책임의 분리 보장을 위해 더 세분화된 권한 구성이 필요합니다.

GitLab.com 네임스페이스 전역으로 정책 강제 적용

사전 요구 사항:

• 보안 정책 프로젝트에 링크하려면 소유자 역할이나 manage_security_policy_link 권한을 가진 사용자 정의 역할이어야 합니다. 자세한 내용은 책임의 분리를 참조하세요.

GitLab.com 네임스페이스의 모든 하위 그룹 및 프로젝트에 걸쳐 전역으로 정책을 시행하는 고수준의 워크플로우는 다음과 같습니다.

1. 상위 그룹에서 Policies 탭을 방문하세요.

2. 하위 그룹에서 Policies 탭으로 이동하여 테스트 정책을 생성하세요.

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

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

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

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

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

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

   적절한 권한이 있는 하위 그룹 소유자나 프로젝트 소유자는 Policies 페이지로 이동하여 보안 정책 프로젝트에 링크를 생성할 수 있습니다. 모든 연결된 그룹, 하위 그룹 및 프로젝트는 보안 정책 프로젝트에서 생성된 모든 정책에 의해 “강제 적용”됩니다. 자세한 내용은 보안 정책 프로젝트에 링크를 참조하세요.

6. 기본적으로 정책이 활성화되어 있으면 모든 연결된 그룹, 하위 그룹 및 프로젝트에 적용됩니다.

   보다 세분화된 시행을 위해 “정책 범위”를 추가하세요. 정책 범위를 사용하면 특정 프로젝트 집합에 대해 정책을 시행하거나 특정 규정 프레임워크 라벨을 포함한 프로젝트에 대해 정책을 시행할 수 있습니다.

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

GitLab Dedicated 또는 GitLab Self-managed 인스턴스 전역으로 정책 강제 적용

사전 요구 사항:

• 보안 정책 프로젝트에 링크하려면 소유자 역할이나 manage_security_policy_link 권한을 가진 사용자 정의 역할이어야 합니다. 자세한 내용은 책임의 분리를 참조하세요.
• 인스턴스 전반에 걸쳐 승인 그룹을 지원하려면 GitLab 인스턴스 애플리케이션 설정에서 security_policy_global_group_approvers_enabled를 활성화하세요.

다중 그룹에 걸쳐 정책을 시행하는 고수준의 워크플로우는 다음과 같습니다:

1. 정책을 포함하는 별도의 그룹을 생성하고 책임을 분리하세요.

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

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

   이것은 UI에서 정책 편집기의 주요 위치로 제공되어 정책을 생성하고 관리할 수 있습니다.

3. 테스트 정책을 생성하세요 (테스트용으로 비활성화된 정책을 만들 수 있습니다).

   정책을 만들면 자동으로 새 보안 정책 프로젝트가 그룹 내에 생성됩니다. 이 프로젝트는 policy.yml 또는 정책-as-코드를 저장하는 데 사용됩니다.

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

   기본적으로 소유자와 유지관리자는 정책을 만들고 편집하고 삭제할 수 있습니다. 개발자는 정책 변경을 제안할 수 있지만 병합할 수는 없습니다.

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

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

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

   적절한 권한이 있는 하위 그룹 소유자나 프로젝트 소유자는 Policies 페이지로 이동하여 보안 정책 프로젝트에 링크를 생성할 수 있습니다. 모든 연결된 그룹, 하위 그룹 및 프로젝트는 보안 정책 프로젝트에서 생성된 모든 정책에 의해 “강제 적용”됩니다. 자세한 내용은 보안 정책 프로젝트에 링크를 참조하세요.

7. 기본적으로 정책이 활성화되어 있으면 모든 연결된 그룹, 하위 그룹 및 프로젝트에 적용됩니다.

   보다 세분화된 시행을 위해 “정책 범위”를 추가하세요. 정책 범위를 사용하면 특정 프로젝트 집합에 대해 정책을 시행하거나 특정 규정 프레임워크 라벨을 포함한 프로젝트에 대해 정책을 시행할 수 있습니다.

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

보안 정책 프로젝트에 링크

그룹, 하위 그룹 또는 프로젝트에 포함된 보안 정책 프로젝트의 정책을 강제 적용하려면 이를 연결합니다. 기본적으로 모든 연결된 엔터티에게 강제 적용됩니다. 각 정책 별로 세분화된 정책을 강제 적용하려면 각 정책에 “정책 범위”를 설정할 수 있습니다.

사전 요구 사항:

• 보안 정책 프로젝트에 링크하려면 소유자 역할이나 manage_security_policy_link 권한을 가진 사용자 정의 역할이어야 합니다. 자세한 내용은 책임의 분리를 참조하세요.

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

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트, 하위 그룹 또는 그룹을 찾습니다.
2. Secure > Policies를 선택하세요.
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 정책으로의 마이그레이션를 참조하세요.

문제 해결

보안 정책을 사용할 때 이러한 문제 해결 팁을 고려하세요:

• 개발 프로젝트 및 개발 프로젝트가 속한 그룹 또는 하위 그룹에 모두 보안 정책 프로젝트를 연결해서는 안 됩니다. 이렇게 연결하면 병합 요청 승인 정책의 승인 규칙이 개발 프로젝트의 병합 요청에 적용되지 않습니다.
• 병합 요청 승인 정책을 만들 때 scan_finding 규칙 유형에 있는 배열 severity_levels 또는 배열 vulnerability_states를 비워둘 수 없습니다. 올바르게 작동하는 규칙을 위해 각 배열에는 적어도 하나의 항목이 있어야 합니다.

문제가 계속되는 경우 최신으로 보고된 버그를 확인하고 신고되지 않은 새 문제를 제기할 수 있습니다.