정책

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

일반적으로 사용 가능 in GitLab 14.4. 피처 플래그 security_orchestration_policies_configuration removed.

GitLab의 정책은 조직 내에서 전역적으로 제어를 시행할 수 있는 방법을 보안 및 규정 준수 팀에 제공합니다. 보안 팀은 다음을 보장할 수 있습니다:

  • 개발 팀 파이프라인에서 보안 스캐너가 적절한 구성으로 시행됩니다.
  • 모든 스캔 작업이 변경이나 조작 없이 실행됩니다.
  • 발견된 결과를 기반으로 Merge Request에 대한 적절한 승인이 제공됩니다.

규정 준수 팀은 모든 Merge Request에 대해 중앙에서 여러 승인자를 강제하고, 조직 요구 사항의 범위 내 프로젝트에 여러 설정이 활성화되거나 잠길 수 있도록 보장합니다.

GitLab은 다음과 같은 보안 정책을 지원합니다:

보안 정책 프로젝트

보안 정책 프로젝트(SPP)는 정책만 포함하는 특별한 유형의 프로젝트로, .gitlab/security-policies/policy.yml YAML 파일에 정책이 저장됩니다.

SPP에 포함된 정책을 강제하려면 해당 SPP를 프로젝트, 서브그룹, 그룹 또는 이들 각각에 다중으로 링크시키면 됩니다. SPP에는 여러 정책이 포함될 수 있지만 이들은 함께 강제됩니다. 그룹이나 서브그룹에 강제된 SPP는 하위 항목, 즉 모든 하위 그룹 및 그들의 프로젝트에 적용됩니다.

Merge Request에서 변경된 정책은 Merge Request이 Merge되는 즉시 적용됩니다. Merge Request을 통과하지 않고 기본 브랜치에 직접 커밋된 정책 변경은 정책 변경이 적용되기까지 최대 10분이 소요될 수 있습니다.

정책 설계 지침

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

  • 최소한의 오버헤드로 정책 시행을 위한 설계
  • 임무분리

정책 시행 설계

정책 범위를 극대화하기 위해 목표를 달성하는 최상위 수준(그룹 수준, 서브그룹 수준 또는 프로젝트 수준)에서 SPP를 링크하세요. 최상위 수준에서의 강제는 SPP 수及대를 최소화하고, 따라서 관리 오버헤드도 최소화됩니다. 정책은 각 수준에서 밑으로 단계적으로 프로젝트에 적용되므로 그룹 수준, 그 상위의 각 서브그룹 및 그 후에 프로젝트 수준에서 생성된 정책이 강제될 수 있습니다.

정책의 상속은 SPP의 최소화와 함께 최대한의 범위를 확보하며 정책 변경을 구현할 때도 도움이 됩니다. 예를 들어, 정책 변경을 테스트하려면 기존 정책을 복사하여 수정된 정책을 먼저 프로젝트에 강제한 다음, 서브그룹에 진행하고, 적용 가능한 경우에는 그룹에도 진행합니다.

note
GitLab SaaS 사용자는 최상위 그룹 또는 서브그룹 전반에 정책을 강제할 수 있지만, GitLab Self-managed 사용자는 자체 인스턴스의 여러 최상위 그룹에 걸쳐 정책을 강제할 수 없습니다.

다음 예는 두 개의 그룹과 그들의 구조를 설명합니다:

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

알파 그룹 (코드 프로젝트 포함) - Finance (서브그룹) - 프로젝트 A - 수금 계정 (서브그룹) - 프로젝트 B - 프로젝트 C - Engineering (서브그룹) - 프로젝트 K - 프로젝트 L - 프로젝트 M

보안 및 규정 준수 그룹 (SPP 포함) - 보안 정책 관리 - 보안 정책 관리 - 보안 정책 프로젝트 - SAST 정책 - 비밀 탐지 정책

이 중 강제된 정책이 없다고 가정할 때, 다음과 같은 예를 고려해보세요:

  • “SAST” 정책이 알파 그룹에서 사용되면 이는 그 하위 그룹인 Finance 및 Engineering과 그들의 프로젝트 및 서브그룹에 적용됩니다. “비밀 탐지” 정책이 “수금 계정” 서브그룹에서도 사용되면 두 정책이 프로젝트 B와 C에 모두 적용됩니다. 그러나 프로젝트 A에는 “SAST” 정책만 적용됩니다.
  • “SAST” 정책이 “수금 계정” 서브그룹에서 사용되면 프로젝트 B와 C에만 적용됩니다. 프로젝트 A에는 정책이 적용되지 않습니다.
  • “비밀 탐지”가 프로젝트 K에 사용되면 프로젝트 K에만 적용됩니다. 다른 서브그룹이나 프로젝트에는 정책이 적용되지 않습니다.

임무 분리

임무 분리는 정책을 성공적으로 시행하기 위해 매우 중요합니다. 보안 및 규정 준수 팀은 정책을 정의하고 개발 팀과 협력해야 합니다. 개발 팀은 정책을 비활성화하거나 수정하거나 우회할 수 없어야 합니다. 정책은 필요한 규정 준수 및 보안 요구 사항을 달성하면서 개발 팀이 목표를 달성할 수 있도록 구현되어야 합니다.

SPP를 강제하는 데 필요한 역할은 링크를 만드는 계층 수준에 따라 달라집니다:

조직 부서 그룹 소유자 서브그룹 소유자 프로젝트 소유자
그룹 예 아니오 아니오
서브그룹 예 예 아니오
프로젝트 예 예 예

정책 실행

SPP의 실행 옵션은 GitLab SaaS 및 GitLab Self-managed 사이에 약간 차이가 있습니다. 주요 차이점은 GitLab SaaS에서만 서브그룹을 생성할 수 있다는 것입니다. 임무 분리를 보장하려면 보다 세분화된 권한 구성이 필요합니다.

서브그룹 및 프로젝트 전체에 정책 강제

Tier: Ultimate Offering: GitLab.com

서브그룹과 프로젝트에 정책을 강제하려면 프로젝트를 포함할 별도의 서브그룹을 만들면 됩니다. 별도의 서브그룹을 만드는 것은 권한을 상속받는 사용자 수를 최소화할 수 있도록 합니다. 보안 팀이 관리하는 SPP와 개발 팀이 관리하는 프로젝트의 서브그룹을 분리함으로써 임무를 분리할 수 있습니다. 보안 팀은 서브그룹 및 프로젝트 소유자의 개입 없이 정책을 추가하거나 변경할 수 있습니다. 서브그룹 및 프로젝트 소유자는 정책을 재정의할 수 없습니다.

필수 조건:

  • SPP에 링크하려면 소유자 역할이 있어야 합니다. 자세한 내용은 임무 분리를 참조하세요.

여러 서브그룹에 걸쳐 정책을 강제하는 과정의 개요:

  1. 권한을 상속받는 사용자 수를 최소화하기 위해 별도의 서브그룹을 생성하세요. 독립적인 서브그룹을 만들면 권한을 상속받는 사용자 수를 최소화할 수 있습니다.
  2. 새 그룹이나 서브그룹에서 정책을 관리하는 또 다른 프로젝트(예: “보안 정책 관리”)를 만들어 보안 정책을 관리하는 주요 위치로 사용하세요. 이를 통해 UI에서 정책을 생성하고 관리할 수 있는 정책 편집기의 주요 위치로 사용됩니다.
  3. 테스트 정책을 만드세요. (테스트를 위해 비활성화된 정책을 생성할 수 있습니다.) 정책을 생성하면 자동으로 그룹 또는 서브그룹 아래에 새 SPP가 생성됩니다. 해당 프로젝트는 policy.yml이나 정책-as-code를 저장하는 데 사용됩니다.
  4. 새로 만든 프로젝트의 프로젝트 권한을 확인하고 보안 팀 멤버만 소유자 역할을 가지도록 설정하세요.
  5. 상속된 권한을 차단하거나 정책 변경을 추가 검토하거나 승인할 추가 제한이 필요한 경우, 추가로 분리된 정책을 만들어 첫 번째 정책에 강제할 수 있습니다. 예를 들어, 정책 변경을 승인할 담당 사용자를 정의할 수 있습니다.
  6. 새로 생성된 SPP에서 필요한 정책을 생성하세요. Security Policy Management 프로젝트의 정책 탭에서 정책 편집기를 사용하거나 새롭게 만든 보안 정책 프로젝트인 Security Policy Management - 보안 정책 프로젝트에 저장된 policy.yml 파일에서 정책을 직접 업데이트할 수 있습니다.
  7. SPP와 링크를 만들기 위해 서브그룹 소유자 또는 프로젝트 소유자로 방문하여 정책 페이지로 이동하여 SPP에 링크를 생성하세요. 프로젝트의 전체 경로를 포함하고 프로젝트 이름은 “-보안 정책 프로젝트”로 끝나야 합니다. 자세한 내용은 보안 정책 프로젝트에 링크를 참조하세요.

그룹, 서브그룹 및 프로젝트 전반에 정책 강제 적용하기

Tier: Ultimate Offering: Self-managed, GitLab Dedicated

여러 그룹에 대한 정책을 강제로 지정하려면 SPP를 포함하는 그룹을 별도로 만들어야 합니다. 프로젝트를 포함하는 그룹과 별도로 분리하여 관리하는 것이 가능합니다. 별도의 그룹을 사용하면 SPP를 보안 팀이 관리하고 프로젝트 그룹을 개발 팀이 관리하는 업무 분리가 가능합니다. 보안 팀은 그룹 소유자의 개입 없이 정책을 추가하거나 변경할 수 있습니다. 서브그룹 및 프로젝트 소유자는 정책을 무력화할 수 없습니다.

필수 조건:

  • SPP에 링크하려면 소유자 역할이어야 합니다. 자세한 내용은 역할 분리를 참조하십시오.
  • 인스턴스 전역으로 승인 그룹을 지원하려면 GitLab 인스턴스 응용 프로그램 설정에서 security_policy_global_group_approvers_enabled을 활성화하십시오.

여러 그룹에 걸쳐 정책을 강제 적용하는 고수준의 작업 흐름:

  1. 정책을 포함하는 별도의 그룹을 만들고 업무 분리를 보장합니다.

    별도의 독립 그룹을 만들면 권한을 상속받는 사용자 수를 최소화할 수 있습니다.

  2. 새 그룹에서 “보안 정책 관리”와 같은 정책을 관리하는 데 사용할 프로젝트를 만듭니다.

    이는 정책 편집기의 주요 위치로서 UI에서 정책을 생성하고 관리할 수 있게 합니다.

  3. 테스트 정책을 만듭니다(테스트를 위해 비활성화된 정책을 만들 수 있습니다).

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

  4. 새로 만든 프로젝트에서 권한을 확인하고 원하는 대로 설정합니다. 기본적으로, 소유자 및 유지 관리자는 정책을 만들고 편집하고 삭제할 수 있습니다.
  5. 상속된 권한을 차단하거나 정책 변경에 대해 추가 리뷰 또는 승인이 필요한 추가적인 제한이 필요한 경우, 첫 번째에 대해 강제할 별도의 정책 집합을 만들 수 있습니다. 예를 들어, 정책 변경을 승인할 책임이 있는 개별 사용자 집합을 정의할 수 있습니다.
  6. SPP의 권한을 설정하여 보안 팀 멤버만 소유자 역할을 가지도록 합니다.
  7. 방금 만든 SPP에서 필요한 정책을 만듭니다.
  8. 그룹 소유자, 서브그룹 소유자 또는 프로젝트 소유자로서 SPP에 방문하여 연결을 만들 수 있습니다. 정책 페이지에 방문하여 SPP에 링크를 만들 수 있습니다. 전체 경로를 포함하고 프로젝트 이름은 “-보안 정책 프로젝트”로 끝나야 합니다. 자세한 내용은 보안 정책 프로젝트에 링크를 참조하십시오.

다중 프로젝트에 대한 정책 강제 적용하기

그룹이나 서브그룹을 정책과 연결하는 것이 충분하지 않은 경우 프로젝트별로 SPP를 연결하는 것이 가능합니다. 이렇게 하면 해당 사항이 없는 프로젝트에서 집행을 필터링할 수 있습니다. 프로젝트 수준에서 SPP 정책을 강제하기 위해 보안 팀만 보안 정책 프로젝트에서 소유자 역할을 가지도록 프로젝트 권한을 사용할 수 있습니다.

프로젝트에 대한 정책을 강제로 지정하려면:

  1. 대상 프로젝트와 동일한 수준에서 보안 정책 프로젝트를 만듭니다.
  2. 보안 정책 프로젝트에서 필요한 정책을 만듭니다.
  3. 대상 프로젝트를 보안 정책 프로젝트에 연결합니다.

보안 정책 프로젝트에 링크

프로젝트, 서브그룹 또는 그룹에 SPP를 연결하여 SPP에 포함된 정책을 강제로 지정합니다.

필수 조건:

  • SPP에 링크하려면 소유자 역할이어야 합니다. 자세한 내용은 역할 분리를 참조하십시오.

프로젝트, 서브그룹 또는 그룹에 SPP를 링크하려면 다음을 수행합니다:

  1. 왼쪽 사이드바에서 검색 또는 이동하여를 선택하고 프로젝트, 서브그룹 또는 그룹을 찾습니다.
  2. 보안 > 정책(Policies)를 선택합니다.
  3. 정책 프로젝트 편집(Edit Policy Project)을 선택하고 드롭다운 디렉터리에서 연결하려는 프로젝트를 검색하여 선택합니다.
  4. 저장을 선택합니다.

보안 정책 프로젝트에 연결을 해제하려면 동일한 단계를 따르되 대화 상자에서 휴지통 아이콘을 대신 선택합니다.

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

프로젝트 정책 페이지에 액세스 권한이 있는 모든 사용자는 프로젝트 소유자가 아닌 경우 연결된 보안 정책 프로젝트로 연결되는 버튼을 볼 수 있습니다.

정책 관리

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

  1. 왼쪽 사이드바에서 검색 또는 이동하여를 선택하여 프로젝트를 찾습니다.
  2. 보안 > 정책(Policies)를 선택합니다.

정책 디렉터리 페이지

정책 편집기

정책 편집기를 사용하여 정책을 만들고 편집하고 삭제할 수 있습니다:

  1. 왼쪽 사이드바에서 검색 또는 이동하여를 선택하여 프로젝트를 찾습니다.
  2. 보안 > 정책(Policies)를 선택합니다.
    • 새로운 정책을 만들려면 정책(New policy)을 선택하여 정책을 만들 유형을 선택합니다.
    • 기존 정책을 편집하려면 선택한 정책 드로어(Drawer)에서 정책 편집(Edit policy)을 선택합니다.

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

  • 시각적 규칙 모드를 사용하여 규칙 블록과 관련된 컨트롤을 사용하여 정책 규칙을 작성하고 미리보기할 수 있습니다.

    정책 편집기 규칙 모드

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

    정책 편집기 YAML 모드

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

정책 생성 또는 편집을 마친 후 Merge Request으로 구성 버튼을 선택하고 결과 Merge Request을 Merge하여 적용하십시오. 이 버튼을 누르면 정책 YAML이 유효성을 검사하고 어떤 오류가 있는지를 표시합니다. 또한, 프로젝트 소유자이고 보안 정책 프로젝트가 이전에 이 프로젝트와 자동으로 연결되지 않은 경우, 첫 번째 정책 Merge Request을 만드는 동시에 자동으로 새 프로젝트가 생성되고 연결됩니다.

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

취약성 확인 마이그레이션 스크립트를 사용하여 정책을 대량으로 생성하거나 보안 정책 프로젝트를 개발 프로젝트와 연결할 수 있습니다. 취약성 확인 마이그레이션 스크립트의 사용 방법과 데모에 대한 지침은 이 비디오를 참조하세요.

문제 해결

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

새로운 보안 정책을 생성하거나 기존 정책을 변경할 때 update-policy-<timestamp> 패턴을 따르는 새 브랜치가 자동으로 생성됩니다. 예를 들어, update-policy-1659094451과 같이 생성됩니다.

만약 그룹이나 인스턴스에 ‘update-policy-' 텍스트를 포함하는 브랜치 이름 패턴을 허용하지 않는 [푸시 규칙](../../project/repository/push_rules.md#validate-branch-names)이 있는 경우, `Branch name 'update-policy-' does not follow the pattern ''`라는 오류가 발생합니다.

해결책은 정책에서 update-policy- 다음에 정수 타임스탬프가 오는 브랜치를 허용하도록 그룹 또는 인스턴스 푸시 규칙을 수정하는 것입니다.

보안 정책 구성의 일반적인 문제 해결

  • 스캐너가 올바르게 구성되어 최신 브랜치에 대한 결과물을 생성하는지 확인하세요. 보안 정책은 결과물이 없을 때 (보안 보고서가 없을 때) 승인을 요구하기 때문에 새로운 취약성이 도입되지 않도록 합니다. 스캔이 성공적으로 완료되고 평가되지 않으면 어떠한 취약성이 있는지 알 수 없습니다.
  • Merge Request 승인 정책의 경우, 정책에서 정의된 각 스캐너에 대한 아티팩트가 소스 및 대상 브랜치 모두에 있어야 합니다. Merge Request 승인 정책이 필요한 결과를 포착하도록 하려면 스캔 실행이 올바르게 구현되고 강제되었는지 확인하세요. 스캔 실행 정책을 사용하는 경우 모든 브랜치에서 강제하는 것이 종종 필요합니다.
  • Merge Request 승인 정책에서의 비교는 성공적으로 완료된 Merge 베이스 파이프라인에 의존합니다. Merge 베이스 파이프라인이 스킵된 경우, Merge Request에서 Merge 베이스 파이프라인이 차단됩니다.
  • SAST 작업에 기반을 둔 스캔 실행 정책을 실행할 때, 타겟 리포지터리에 올바른 코드 파일이 포함되어 있는지 확인하세요. SAST는 리포지터리의 파일 유형에 기반하여 다른 분석기를 실행합니다, 지원되는 파일이 없는 경우 잡을 실행하지 않습니다. 자세한 내용은 SAST CI 템플릿을 참조하세요.
  • 브랜치 구성 충돌을 확인하세요. 예를 들어, 정책이 main에서 규칙을 강제하도록 구성되어 있지만 scope 내 몇몇 프로젝트가 기본 브랜치로 master를 사용하는 경우 정책이 후자에는 적용되지 않습니다. 이 문제를 해결하려면 default 브랜치에 대해 규칙을 일반적으로 강제하거나 프로젝트 이름과 관계 없이 모든 보호된 브랜치에 대해 규칙을 정의하세요.
  • 그룹 또는 하위 그룹 수준에서 생성된 Merge Request 승인 정책은 해당 그룹의 모든 Merge Request에 적용되기까지 시간이 걸릴 수 있습니다.
  • 예약된 스캔 실행 정책은 최소 15분 주기로 실행됩니다. 일정 규칙 유형에 대해 자세히 알아보세요.
  • 파이프라인 예약 시, CRON 스케줄링은 GitLab SaaS의 UTC를 기준으로 하며, 온프레미스 인스턴스의 경우 서버 시간을 기준으로 합니다. 새로운 정책을 테스트할 때 파이프라인이 서버 시간대에서 예약되어 있으므로 제대로 실행되지 않는 것으로 보일 수 있습니다.
  • 스캔 실행 정책을 강제할 때, 보안 정책은 대상 프로젝트에서 스케줄된 파이프라인을 트리거하기 위해 봇을 사용합니다. 봇이 누락된 경우, 자동으로 생성되고 다음 예약된 스캔에 사용됩니다.
  • 보안 정책 프로젝트를 개발 프로젝트 및 해당 개발 프로젝트가 속한 그룹 또는 하위 그룹에 동시에 연결하지 말아야 합니다. 이런 방식으로 링크하는 경우 Scan Result Policy의 승인 규칙이 개발 프로젝트의 Merge Request에 대해서 적용되지 않습니다.
  • Scan Result Policy를 생성할 때, scan_finding 규칙의 severity_levels 배열 또는 vulnerability_states 배열을 비워둘 수 없습니다. 작동하는 규칙에는 적어도 하나의 항목이 있어아 합니다.
  • 프로젝트에 매뉴얼 작업이 있는 경우 Merge Request 승인 정책을 강제하면 완료된 파이프라인 작업을 평가하고 매뉴얼 작업을 무시합니다. 매뉴얼 작업이 실행될 경우 정책이 Merge Request을 다시 평가합니다.

문제가 해결되지 않는 경우, 최근 보고된 버그를 확인하고 새로운 문제를 제기할 수 있습니다.