정책은 보안 및 컴플라이언스 팀이 조직 전체에 걸쳐 제어를 적용하는 방법을 제공합니다.

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

• 보안 스캐너가 적절한 구성으로 개발 팀 파이프라인에서 적용됩니다.
• 모든 스캔 Job이 변경이나 수정 없이 실행됩니다.
• 해당 발견 결과를 기반으로 머지 리퀘스트에 적절한 승인이 제공됩니다.
• 더 이상 감지되지 않는 취약점이 자동으로 해결되어 취약점 분류 작업 부담이 줄어듭니다.

컴플라이언스 팀은 다음을 적용할 수 있습니다:

• 모든 머지 리퀘스트에 여러 승인자
• 머지 리퀘스트 설정 또는 리포지터리 설정 활성화 또는 잠금과 같은 조직 요구사항에 기반한 프로젝트 설정.

다음 정책 유형을 사용할 수 있습니다:

• 스캔 실행 정책. 파이프라인의 일부로 또는 지정된 일정에 따라 보안 스캔을 적용합니다.
• 머지 리퀘스트 승인 정책. 스캔 결과를 기반으로 프로젝트 수준 설정과 승인 규칙을 적용합니다.
• 파이프라인 실행 정책. CI/CD Job을 프로젝트 파이프라인의 일부로 적용합니다.
  • 예약된 파이프라인 실행 정책(실험). 커밋 활동과 독립적으로 프로젝트 전체에 걸쳐 예약된 주기로 사용자 지정 CI/CD Job을 적용합니다.
• 취약점 관리 정책. 기본 브랜치에서 더 이상 감지되지 않는 취약점을 자동으로 해결합니다.

정책 범위 구성#

policy_scope 키워드#

policy_scope 키워드를 사용하여 지정한 그룹, 프로젝트, 컴플라이언스 프레임워크, 또는 이들의 조합에만 정책을 적용합니다.

policy_scope의 빈 컬렉션#

policy_scope 필드가 빈 컬렉션([])으로 설정되면 해당 필드가 완전히 생략된 것처럼 처리됩니다. 이는 정책이 제한 없이 모든 프로젝트에 적용된다는 의미입니다.

구체적으로:

• projects: { including: [] }는 제로 프로젝트가 아닌 모든 프로젝트에 정책을 적용합니다.
• groups: { including: [] }는 제로 그룹이 아닌 모든 그룹에 정책을 적용합니다.
• compliance_frameworks: []는 프레임워크가 없는 프로젝트가 아닌 모든 프로젝트에 정책을 적용합니다.

이 동작은 빈 컬렉션이 필터가 제공되지 않은 것처럼 처리되는 것에 의존하는 기존 정책과의 하위 호환성을 유지합니다.

정책이 어떤 프로젝트에도 적용되지 않도록 하려면 빈 컬렉션 대신 enabled: false를 설정하세요:

policy_scope:
  projects:
    including:
      - id: 123
enabled: false  # 정책을 완전히 비활성화

match_mode 이해#

여러 범위 조건(예: projects와 groups 모두)을 지정할 때 match_mode 필드는 이러한 조건이 결합되는 방법을 결정합니다:

• all(기본값): 정책은 지정된 조건을 모두 충족하는 프로젝트에만 적용됩니다. 이 모드는 더 제한적이며 기존 정책과의 하위 호환성을 유지합니다.
• any: 정책은 지정된 조건 중 하나를 충족하는 프로젝트에 적용됩니다. 이 모드는 더 허용적이며 단일 정책으로 다른 프로젝트 세트를 대상으로 할 때 유용합니다.

예를 들어, 포함 프로젝트 목록과 포함 그룹 목록을 모두 지정하는 경우:

• match_mode: all을 사용하면 프로젝트가 프로젝트 목록에 있으면서 그리고 지정된 그룹 중 하나에 속해야 합니다.
• match_mode: any를 사용하면 프로젝트가 프로젝트 목록에 있거나 또는 지정된 그룹 중 하나에 속하면 범위에 들어갑니다.

match_mode: any로 excluding과 including 조건을 결합할 때, excluding 조건이 정책의 범위를 넓힌다는 점에 주의하세요. OR 논리는 어떤 조건이든 일치하면 정책이 적용됨을 의미하므로, 그룹 제외 조건(제외된 그룹의 프로젝트를 제외한 모든 프로젝트와 일치)은 including 조건에 무엇이 지정되었든 관계없이 정책이 대부분의 프로젝트에 적용됨을 의미합니다.

예를 들어, 그룹 목록에서 group-2를 제외하고 특정 프로젝트 group-1/project-1-1과 group-2/project-2-1을 포함하는 정책:

policy_scope:
 match_mode: any
 groups:
   excluding:
     - id: 200  # group-2
 projects:
   including:
     - id: 101  # group-1/project-1-1
     - id: 201  # group-2/project-2-1

이 구성으로 정책은 명시적으로 포함된 두 프로젝트뿐만 아니라 group-2 외부의 다른 모든 프로젝트(포함 프로젝트에 나열되지 않은 group-1/project-1-2 등)에도 적용됩니다. 그룹 제외 조건은 group-2에 없는 모든 프로젝트와 일치하며, OR 논리로 인해 하나의 일치만으로 정책이 적용됩니다.

범위 예시#

이 예시에서 스캔 실행 정책은 ID가 2 또는 11인 컴플라이언스 프레임워크가 적용된 모든 프로젝트에서 모든 릴리스 파이프라인에 SAST 스캔을 적용합니다.

---
scan_execution_policy:
- name: Enforce specified scans in every release pipeline
  description: This policy enforces a SAST scan for release branches
  enabled: true
  rules:
  - type: pipeline
    branches:
    - release/*
  actions:
  - scan: sast
  policy_scope:
    compliance_frameworks:
      - id: 2
      - id: 11

이 예시에서 스캔 실행 정책은 ID가 203인 그룹의 모든 프로젝트(모든 하위 서브그룹과 해당 프로젝트 포함)에서 기본 브랜치 파이프라인에 대해 시크릿 감지 및 SAST 스캔을 적용하되 ID가 64인 프로젝트는 제외합니다.

- name: Enforce specified scans in every default branch pipeline
  description: This policy enforces secret detection and SAST scans for the default branch
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  - scan: sast
  policy_scope:
    groups:
      including:
        - id: 203
    projects:
      excluding:
        - id: 64

이 예시에서 스캔 실행 정책은 아카이브된 프로젝트를 제외한 모든 프로젝트에 SAST 스캔을 적용합니다. 이는 스캔되지 않아야 하는 아카이브된 프로젝트가 많을 때 유용합니다.

- name: Enforce SAST scan excluding archived projects
  description: This policy enforces SAST scans but excludes archived projects
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: sast
  policy_scope:
    projects:
      excluding:
        - type: archived

이 예시에서 스캔 실행 정책은 match_mode: any를 사용하여 특정 우선순위 높은 프로젝트 또는 특정 그룹 내의 모든 프로젝트에 시크릿 감지 스캔을 적용합니다. match_mode: any가 없으면 정책이 적용되려면 프로젝트가 프로젝트 목록에 있어야 하고 지정된 그룹 중 하나에 있어야 합니다.

- name: Enforce secret detection on priority projects or security groups
  description: This policy enforces secret detection on specific projects or all projects in security-focused groups
  enabled: true
  rules:
  - type: pipeline
    branches:
    - main
  actions:
  - scan: secret_detection
  policy_scope:
    match_mode: any
    projects:
      including:
        - id: 123  # 보안 그룹 외부의 우선순위 높은 프로젝트
        - id: 456  # 또 다른 중요한 프로젝트
    groups:
      including:
        - id: 78   # 보안 팀의 그룹
        - id: 90   # 컴플라이언스 팀의 그룹

직무 분리#

정책 구현에 있어 직무 분리는 매우 중요합니다. 개발 팀이 목표를 달성할 수 있게 하면서 필요한 컴플라이언스 및 보안 요구사항을 달성하는 정책을 구현하세요.

보안 및 컴플라이언스 팀:

• 정책을 정의하고 정책이 요구사항을 충족하는지 확인하기 위해 개발 팀과 협력해야 합니다.

개발 팀:

• 정책을 비활성화, 수정 또는 우회할 수 없어야 합니다.

그룹, 서브그룹, 또는 프로젝트에 보안 정책 프로젝트를 적용하려면 다음 중 하나가 필요합니다:

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

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

필요한 권한#

보안 정책을 만들고 관리하려면:

• 그룹에 적용된 정책의 경우: 그룹에 대한 Maintainer 또는 Owner 권한이 있어야 합니다.
• 프로젝트에 적용된 정책의 경우:
  • 프로젝트 소유자여야 합니다.
  • 그룹에서 프로젝트를 만들 권한이 있는 그룹 멤버여야 합니다.

정책 권장사항#

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

브랜치 이름#

정책에서 브랜치 이름을 지정할 때 개별 브랜치 이름이 아닌 기본 브랜치 또는 모든 보호된 브랜치와 같은 일반적인 보호된 브랜치 카테고리를 사용하세요.

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

푸시 규칙#

GitLab 17.3 이하에서 브랜치 이름을 유효성 검사하기 위해 푸시 규칙을 사용하는 경우, update-policy- 접두사로 브랜치 생성을 허용하는지 확인하세요. 이 브랜치 이름 접두사는 보안 정책이 생성되거나 수정될 때 사용됩니다. 예를 들어, 1659094451은 타임스탬프인 update-policy-1659094451. 푸시 규칙이 브랜치 생성을 차단하면 다음 오류가 발생합니다:

Branch name `update-policy-<timestamp>` does not follow the pattern `<branch_name_regex>`.

GitLab 17.4 이상에서는 보안 정책 프로젝트가 브랜치 이름 유효성 검사를 적용하는 푸시 규칙에서 제외됩니다.

보안 정책 프로젝트#

보안 정책 프로젝트에서 비공개로 유지하려는 민감한 정보 노출을 방지하기 위해 보안 정책 프로젝트를 다른 프로젝트에 연결할 때:

• 보안 정책 프로젝트에 민감한 콘텐츠를 포함하지 마세요.
• 비공개 보안 정책 프로젝트를 연결하기 전에 대상 프로젝트의 멤버 목록을 검토하여 모든 멤버가 정책 콘텐츠에 액세스해야 하는지 확인합니다.
• 대상 프로젝트의 가시성 설정을 평가하세요.
• 보안 정책 관리 감사 로그를 사용하여 프로젝트 연결을 모니터링합니다.

다음 이유로 민감한 정보 노출을 방지하기 위한 권장사항입니다:

• 공유 가시성: 비공개 보안 프로젝트가 다른 프로젝트에 연결되면 연결된 프로젝트의 Security Policies 페이지에 액세스할 수 있는 사용자가 .gitlab/security-policies/policy.yml 파일의 내용을 볼 수 있습니다. 여기에는 비공개 보안 정책 프로젝트를 공개 프로젝트에 연결하는 것이 포함되며, 이는 공개 프로젝트에 액세스할 수 있는 모든 사람에게 정책 내용을 노출할 수 있습니다.
• 액세스 제어: 비공개 보안 프로젝트가 연결된 프로젝트의 모든 멤버는 원래 비공개 리포지터리에 액세스할 수 없더라도 Policy 페이지에서 정책 파일을 볼 수 있습니다.

보안 및 컴플라이언스 제어#

프로젝트 Maintainer는 그룹 정책 실행을 방해하는 프로젝트에 대한 정책을 만들 수 있습니다. 그룹 정책을 수정할 수 있는 사람을 제한하고 컴플라이언스 요구사항이 충족되고 있는지 확인하기 위해, 중요한 보안 또는 컴플라이언스 제어를 구현할 때:

• 프로젝트 수준에서 파이프라인 실행 정책을 만들거나 수정할 수 있는 사람을 제한하기 위해 사용자 지정 권한을 사용합니다.
• 보안 정책 프로젝트에서 기본 브랜치에 대해 보호된 브랜치를 구성하여 직접 푸시를 방지합니다.
• 지정된 승인자의 검토가 필요한 보안 정책 프로젝트에서 머지 리퀘스트 승인 규칙을 설정합니다.
• 그룹과 프로젝트 모두에 대한 정책의 모든 정책 변경사항을 모니터링하고 검토합니다.

정책 관리#

정책 페이지는 사용 가능한 모든 환경에 대해 배포된 정책을 표시합니다. 정책의 정보(예: 설명 또는 적용 상태)를 확인하고 배포된 정책을 만들고 편집할 수 있습니다:

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Secure > Policies를 선택합니다.

첫 번째 열의 녹색 체크 표시는 정책이 활성화되어 범위 내의 모든 그룹과 프로젝트에 적용됨을 나타냅니다. 회색 체크 표시는 정책이 현재 활성화되지 않았음을 나타냅니다.

정책 편집기#

정책 편집기를 사용하여 정책을 만들고, 편집하고, 삭제합니다:

1. 상단 표시줄에서 Search or go to를 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 Secure > Policies를 선택합니다.

   • 새 정책을 만들려면 Policies 페이지의 헤더에 있는 New policy를 선택합니다. 그런 다음 만들 정책 유형을 선택할 수 있습니다.
   • 기존 정책을 편집하려면 선택된 정책 드로어에서 Edit policy를 선택합니다.

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

   규칙 모드 : 규칙 블록과 관련 제어를 사용하여 정책 규칙을 구성하고 미리봅니다.

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

   언제든지 규칙 모드와 YAML 모드 간에 전환할 수 있습니다. YAML에 오류 또는 지원되지 않는 데이터가 있으면 규칙 모드가 자동으로 꺼집니다. 규칙 모드를 다시 사용하려면 먼저 YAML을 수정하세요.

3. 변경사항을 저장하고 적용하려면 Configure with a merge request를 선택합니다.

   정책의 YAML이 유효성 검사되고 오류가 있으면 표시됩니다.

4. 결과 머지 리퀘스트를 검토하고 머지합니다.

   프로젝트 소유자이고 이 프로젝트에 보안 정책 프로젝트가 연결되어 있지 않으면, 머지 리퀘스트가 생성될 때 보안 정책 프로젝트가 만들어져 이 프로젝트에 연결됩니다.

policy.yml에서 ID 주석 달기#

히스토리

• GitLab 18.1에서 policy.yml 파일에 정의된 annotate_ids 옵션과 함께 실험으로 도입되었습니다.

policy.yml 파일을 단순화하기 위해 GitLab은 프로젝트 ID, 그룹 ID, 사용자 ID, 또는 컴플라이언스 프레임워크 ID와 같은 ID 뒤에 코멘트를 자동으로 추가할 수 있습니다. 주석은 사용자가 각 ID의 의미 또는 출처를 식별하는 데 도움이 되며, policy.yml 파일을 더 쉽게 이해하고 유지 관리할 수 있게 합니다.

이 실험적 기능을 활성화하려면 보안 정책 프로젝트의 .gitlab/security-policies/policy.yml 파일의 experiments 섹션에 annotate_ids 섹션을 추가합니다:

experiments:
  annotate_ids:
    enabled: true

옵션을 활성화한 후 GitLab 정책 편집기로 보안 정책에 대한 변경이 이루어지면 policy.yml 파일의 ID 옆에 주석 코멘트가 생성됩니다.

예를 들어:

# 주석이 달린 ID가 있는 policy.yml 예시
approval_policy:
- name: Your policy name
  # ... 다른 정책 필드 ...
  policy_scope:
    projects:
      including:
      - id: 361 # my-group/my-project
  actions:
  - type: require_approval
    approvals_required: 1
    user_approvers_ids:
    - 75 # jane.doe
    group_approvers_ids:
    - 203 # security-approvers

GitLab Security Policy Bot 사용자#

GitLab Security Policy Bot은 GitLab 인스턴스 전체에서 보안 정책을 실행하는 내부 사용자입니다. 이 봇은 보안 정책과 예약된 파이프라인이 올바르게 작동하는 데 필수적입니다.

Security Policy Bot의 역할:

• 예약된 파이프라인 실행: type: schedule 규칙이 있는 스캔 실행 정책에 정의된 파이프라인을 트리거합니다.
• 컨테이너 스캔 자동화: latest 태그로 이미지가 푸시될 때 컨테이너 스캔 Job을 트리거합니다.
• 정책 적용: 보안 정책에 정의된 대로 보안 스캔 및 컴플라이언스 검사를 실행합니다.
• 파이프라인 생성: 보안 정책이 적용된 프로젝트에서 정책 기반 파이프라인을 생성하고 관리합니다.

계정 특성#

Security Policy Bot의 특성:

• 보안 정책이 적용된 모든 프로젝트에서 자동으로 생성됩니다.
• 프로젝트에서 Guest 권한으로 특정 추가 권한과 함께 실행됩니다.
• 내부 사용자로 표시되어 라이선스 한도에 포함되지 않습니다.
• 정책이 적용될 때 각 프로젝트는 고유한 Security Policy Bot 인스턴스를 갖습니다.

권한 및 액세스#

Security Policy Bot은 최소한의 필수 권한으로 작동합니다:

• 리포지터리 액세스: 정책 실행에 필요한 리포지터리 콘텐츠에 대한 읽기 전용 액세스.
• 파이프라인 생성: 정책 적용을 위한 파이프라인을 만들고 트리거하는 능력.
• CI/CD 변수: 변수 우선순위 규칙에 따라 프로젝트 및 그룹 변수에 대한 액세스.
• 레지스트리 액세스: 적절한 자격 증명으로 구성된 경우 컨테이너 레지스트리에 인증할 수 있습니다.

제한사항#

GitLab Security Policy Bot에 대한 다음 제한사항에 주의하세요:

• 수동 삭제 불가: UI에서 봇을 삭제할 수 없습니다.
• 수정 불가: 사용자 설정이나 권한을 수동으로 변경할 수 없습니다.
• 프로젝트 종속: 각 봇 인스턴스는 특정 프로젝트에 연결되어 있으며 프로젝트 간에 인스턴스를 공유할 수 없습니다.
• 정책 종속: 봇의 기능은 프로젝트에 구성된 보안 정책에 완전히 의존합니다.

보안 트러블슈팅#

Security Policy Bot 기능에 문제가 있는 경우:

예약된 파이프라인이 실행되지 않음#

예약된 파이프라인이 구성된 대로 실행되지 않는 경우:

• 봇 계정이 존재하고 차단되거나 삭제되지 않았는지 확인합니다.
• 보안 정책 구성이 유효한지 확인합니다.
• 봇이 프로젝트에서 필요한 권한을 가지고 있는지 확인합니다.

정책 Job 실패#

정책 Job이 실패하는 경우:

• 봇이 필요한 CI/CD 변수에 액세스할 수 있는지 확인합니다.
• 참조된 CI/CD 구성 파일이 존재하고 액세스 가능한지 확인합니다.
• 특정 오류 메시지에 대해 파이프라인 로그를 검토합니다.

컨테이너 스캔이 트리거되지 않음#

구성된 대로 컨테이너 스캔이 트리거되지 않는 경우:

• 컨테이너 스캔 정책이 올바르게 구성되어 있는지 확인합니다.
• 필요한 경우 봇이 레지스트리 인증 자격 증명을 가지고 있는지 확인합니다.
• latest 태그 푸시가 예상된 정책 규칙을 트리거했는지 확인합니다.

봇 계정 누락#

봇 계정이 더 이상 존재하지 않는 경우:

• 봇 계정을 다시 만들기 위해 보안 정책을 다시 적용하거나 업데이트합니다.
• 봇이 악용 신고를 통해 실수로 차단되거나 삭제된 경우 GitLab 관리자에게 문의합니다.

트러블슈팅#

보안 정책 작업 시 다음 트러블슈팅 팁을 고려하세요:

• 보안 정책 프로젝트를 개발 프로젝트와 개발 프로젝트가 속한 그룹 또는 서브그룹 모두에 연결해서는 안 됩니다. 이런 방식으로 연결하면 개발 프로젝트의 머지 리퀘스트에 머지 리퀘스트 승인 정책의 승인 규칙이 적용되지 않습니다.
• 머지 리퀘스트 승인 정책을 만들 때, scan_finding 규칙의 severity_levels 배열이나 vulnerability_states 배열을 비워둘 수 없습니다. 작동하는 규칙을 위해서는 각 배열에 최소 하나의 항목이 있어야 합니다.
• 프로젝트 소유자는 그룹에서 프로젝트를 만들 권한이 있는 경우 해당 프로젝트에 대한 정책을 적용할 수 있습니다. 그룹 멤버가 아닌 프로젝트 소유자는 정책 추가 또는 편집에 제한이 있을 수 있습니다. 프로젝트의 정책을 관리할 수 없는 경우 그룹 관리자에게 연락하여 그룹에서 필요한 권한이 있는지 확인하세요.
• 정책 충돌의 경우, 가장 최근에 적용된 정책이 우선합니다.

문제가 계속 발생하면 최근 보고된 버그를 조회하고 보고되지 않은 새 이슈를 제기할 수 있습니다.

GraphQL API로 정책 재동기화#

승인이 올바르지 않거나 적용되지 않는 정책 등 정책에서 불일치를 발견한 경우 GraphQL resyncSecurityPolicies 변경을 사용하여 정책을 수동으로 강제 재동기화할 수 있습니다:

mutation {
  resyncSecurityPolicies(input: { fullPath: "group-or-project-path" }) {
    errors
  }
}

fullPath를 보안 정책 프로젝트가 할당된 프로젝트 또는 그룹의 경로로 설정합니다.