• 보안 정책 프로젝트
• 정책 디자인 가이드라인
  • 정책 집행 설계
  • 권한 분리
• 정책 실행
  • 하위 그룹 및 프로젝트 전체에 정책 강제하기
  • 그룹, 하위 그룹 및 프로젝트 전체에 정책 강제하기
  • 여러 프로젝트에 정책 적용
• 보안 정책 프로젝트 연결
  • 연결된 보안 정책 프로젝트 보기
• 정책 관리
• 정책 편집기
• 스크립트를 사용하여 프로젝트 대량 관리
• 문제 해결
  • ‘Branch name ‘update-policy-' does not follow the pattern '''
  • 보안 정책 구성의 일반적인 문제 해결

정책

일반 사용 가능(GA) GitLab 14.4에서. 기능 플래그 security_orchestration_policies_configuration 제거됨.

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

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

규정 준수 팀은 모든 병합 요청에 중앙에서 다수의 승인자를 강제로 지정하고, 조직 요구 사항 범위 내의 프로젝트에서 활성화되거나 잠겨 있는 병합 요청 및 저장소 설정과 같은 여러 설정이 활성화되도록 보장할 수 있습니다.

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

• 스캔 실행 정책
• 스캔 결과 정책

보안 정책 프로젝트

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

SPP에 포함된 정책을 집행하려면 해당 SPP를 프로젝트, 서브그룹, 그룹 또는 각각 여러 개에 연결합니다. SPP에는 여러 정책이 포함될 수 있지만 이들은 함께 집행됩니다. 그룹 또는 서브그룹에 강제로 적용된 SPP는 하위 모든 것에 적용되며, 서브그룹 및 해당 프로젝트도 포함됩니다.

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

정책 디자인 가이드라인

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

• 최소한의 오버헤드로 정책 집행 설계
• 권한 분리

정책 집행 설계

정책 범위를 최대화하려면 목표를 달성하는 최상위 수준에 SPP를 연결하십시오. 즉, 그룹 레벨, 서브그룹 레벨 또는 프로젝트 레벨에서 강제 집행합니다. 최상위 수준에서의 집행은 SPP의 수와 따라서 관리를 최소화합니다. 각 레벨에서 정책은 프로젝트에 대해 하향식으로 전파되므로 정책은 상위 레벨에서 적용되며, 그 아래의 각 서브그룹에도 적용됩니다. 그리고 프로젝트 레벨에서 만든 정책에 대해서도 적용됩니다.

정책 상속은 SPP의 최소한의 수로 최대한의 커버리지를 보장할 뿐만 아니라 정책 변경 시에도 도움이 됩니다. 예를 들어, 정책 변경을 테스트하려면 기존 정책을 복사하여 수정된 정책을 먼저 프로젝트에 강제로 적용한 후, 해당 서브그룹에 적용하고, 적용 가능한 경우 그룹에 적용합니다.

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

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

• Alpha 그룹은 두 개의 서브그룹을 포함하고 있으며, 각각에는 여러 프로젝트가 포함되어 있습니다.
• Security and Compliance 그룹에는 두 개의 정책이 포함되어 있습니다.

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

• Finance (서브그룹)
  • 프로젝트 A
  • 수급계정 (서브그룹)
    • 프로젝트 B
    • 프로젝트 C
• Engineering (서브그룹)
  • 프로젝트 K
  • 프로젝트 L
  • 프로젝트 M

Security and Compliance 그룹 (SPP 포함)

• Security Policy Management
• Security Policy Management - security policy project
  • SAST 정책
  • Secret Detection 정책

이미 강제된 정책이 없을 경우 다음 예제를 고려해 보십시오.

• “SAST” 정책이 Alpha 그룹에 강제로 적용되면, 수급계정 및 공학 서브그룹 및 그 모든 프로젝트 및 서브그룹에 적용됩니다. “Secret Detection” 정책이 “수급계정” 서브그룹에도 강제로 적용되면, 두 정책 모두 프로젝트 B 및 C에 적용됩니다. 그러나 프로젝트 A에는 “SAST” 정책만 적용됩니다.
• 만약 “SAST” 정책이 “수급계정” 서브그룹에 강제로 적용되면, 프로젝트 B 및 C에만 적용됩니다. 프로젝트 A에는 정책이 적용되지 않습니다.
• “Secret Detection” 정책이 프로젝트 K에 강제로 적용되면, 프로젝트 K에만 적용됩니다. 다른 서브그룹이나 프로젝트에는 정책이 적용되지 않습니다.

권한 분리

권한 분리는 정책을 성공적으로 실행하는 데 있어서 중요합니다. 보안 및 규정 준수 팀은 정책을 정의하고 개발팀과 협력해야 합니다. 개발팀은 어떠한 예외에 대해서도 정책을 비활성화, 수정 또는 우회할 수 없어야 합니다. 정책은 필요한 규정 준수 및 보안 요구 사항을 달성하면서 개발팀이 목표를 달성할 수 있도록 실행되어야 합니다.

SPP를 강제로 적용하는 데 필요한 역할은 연결되는 계층 수준에 따라 다릅니다.

정책 실행

SPP(Separation of duties Policies)의 실행 옵션은 GitLab SaaS와 GitLab Self-Managed 사이에 약간 차이가 있습니다. 주요 차이점은 GitLab SaaS에서는 하위 그룹을 생성할 수만 있다는 것입니다. 책임의 분리를 보장하려면 더 세밀한 권한 구성이 필요합니다.

하위 그룹 및 프로젝트 전체에 정책 강제하기

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

필수 조건:

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

여러 하위 그룹에 걸쳐 정책을 강제하는 고수준 워크플로우:

1. 정책을 포함하고 책임을 분리하기 위해 하위 그룹을 만드세요.

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

2. 새 그룹이나 하위 그룹에서 “보안 정책 관리”와 같은 정책을 관리할 프로젝트를 생성하세요.

   이것은 UI에서 정책을 만들고 관리할 수 있도록 하는 정책 편집기의 기본 위치로 사용됩니다.

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

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

4. 새롭게 만든 프로젝트의 프로젝트 권한을 확인하고 설정하여 보안 팀의 구성원만이 소유자 역할을 할 수 있도록 합니다.
5. 상속된 권한을 차단하거나 정책 변경을 추가로 검토하거나 승인해야 하는 경우, 첫 번째에 대항하여 강제할 수 있는 추가로 별도로 정책을 만들 수 있습니다. 예를 들어, 정책 변경을 승인하는 담당자로 정의할 수 있습니다.
6. 방금 생성한 SPP에서 필요한 정책을 만드세요. “Security Policy Management” 프로젝트에서 정책 탭 아래에 있는 정책 편집기를 사용하거나 새롭게 만든 보안 정책 프로젝트 “Security Policy Management - security policy project”에 저장된 policy.yml 파일을 직접 업데이트할 수 있습니다.
7. 하위 그룹 소유자 또는 프로젝트 소유자로서, 정책 페이지에 방문하여 SPP에 링크를 만들 수 있습니다. 프로젝트의 전체 경로를 포함하며, 프로젝트 이름은 “- 보안 정책 프로젝트”로 끝나야 합니다. 자세한 내용은 보안 정책 프로젝트에 연결을 참조하십시오.

그룹, 하위 그룹 및 프로젝트 전체에 정책 강제하기

여러 그룹에 걸쳐 정책을 강제하려면 SPP를 포함하는 그룹을 만들어야 합니다. 이 그룹은 프로젝트를 포함하는 그룹과 별도로 유지됩니다. 별도의 그룹을 사용하면 책임의 분리가 가능하며, 보안 팀이 SPP를 관리하고 프로젝트의 그룹이 개발 팀에 의해 관리됩니다. 보안 팀은 그룹 소유자의 개입 없이 정책을 추가하거나 변경할 수 있습니다. 하위 그룹 및 프로젝트 소유자는 정책을 재정의할 수 없습니다.

필수 조건:

• SPP에 링크하려면 소유자 역할이 있어야 합니다. 자세한 내용은 책임의 분리를 참조하십시오.
• 인스턴스 전역에서 승인 그룹을 지원하려면 GitLab 인스턴스 애플리케이션 설정에서 security_policy_global_group_approvers_enabled를 활성화하세요.

여러 그룹에 걸쳐 정책을 강제하는 고수준 워크플로우:

1. 정책을 포함하고 책임을 분리하기 위해 별도의 그룹을 만드세요.

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

2. 새 그룹에서 “보안 정책 관리”와 같은 정책을 관리할 프로젝트를 생성하세요.

   이것은 UI에서 정책을 만들고 관리할 수 있도록 하는 정책 편집기의 기본 위치로 사용됩니다.

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

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

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

여러 프로젝트에 정책 적용

그룹이나 하위 그룹을 정책에 연결하는 것이 세분화되지 않은 경우, 프로젝트별로 최대 SPP를 연결하는 것이 가능합니다. 이를 통해 적용되지 않는 프로젝트는 제외하고 정책을 적용할 수 있습니다. 프로젝트 수준에서 SPP 정책을 적용하려면 보안 정책 프로젝트를 만들고 연결하세요. 보안 정책 프로젝트에서 프로젝트 권한을 사용하여 보안 팀이 보안 정책 프로젝트에서 소유자 역할을 가지도록 합니다.

프로젝트에 정책 적용:

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

보안 정책 프로젝트 연결

프로젝트, 하위 그룹, 또는 그룹에 있는 SPP에 포함된 정책을 적용하려면 연결하세요.

전제 조건:

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

프로젝트, 하위 그룹, 또는 그룹을 SPP에 연결하려면:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트, 하위 그룹 또는 그룹을 찾습니다.
2. Secure > Policies를 선택합니다.
3. 정책 프로젝트 편집을 선택한 후, 드롭다운 목록에서 연결하려는 프로젝트를 검색하고 선택합니다.
4. 저장을 선택합니다.

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

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

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

정책 관리

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

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

정책 편집기

• GitLab 13.4에서 소개됨.

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

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. Secure > Policies를 선택합니다.
   • 새로운 정책을 만들려면 정책 생성을 선택합니다(페이지 헤더에 위치함). 그런 다음 만들 정책의 유형을 선택합니다.
   • 기존 정책을 편집하려면 선택한 정책 서랍에서 정책 편집을 선택합니다.

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

• 시각적인 규칙 모드는 규칙 블록과 관련된 컨트롤을 사용하여 정책 규칙을 구성하고 미리 보는 데 사용됩니다.

  

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

  

두 모드를 자유롭게 사용하고 필요에 따라 언제든지 전환할 수 있습니다. YAML 리소스에 문제가 있거나 규칙 모드에서 지원하지 않는 데이터가 포함된 경우 규칙 모드가 자동으로 비활성화됩니다. YAML이 잘못되었을 경우 정책을 수정하기 전에 YAML 모드를 사용하여 수정해야 규칙 모드를 다시 사용할 수 있습니다.

정책 생성 또는 편집을 완료하면 병합 요청으로 구성 버튼을 선택하여 적용합니다. 이 버튼을 누르면 정책 YAML이 유효성을 검사하고 결과 오류가 표시됩니다. 또한 프로젝트 소유자이고 보안 정책 프로젝트가 이전에 이 프로젝트와 연결되지 않은 경우, 처음으로 정책 병합 요청이 생성되는 동시에 새 프로젝트가 자동으로 만들어져 연결됩니다.

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

Vulnerability-Check Migration 스크립트를 사용하여 개발 프로젝트에 대량으로 정책을 만들거나 보안 정책 프로젝트를 연결할 수 있습니다. Vulnerability-Check Migration 스크립트의 사용 방법 및 데모에 대한 지침은 이 비디오를 참조하세요.

문제 해결

‘Branch name ‘update-policy-' does not follow the pattern '''

새 보안 정책을 생성하거나 기존 정책을 변경하면 update-policy-<timestamp> 패턴을 따르는 새 브랜치가 자동으로 생성됩니다. 예: update-policy-1659094451.

텍스트 update-policy-<timestamp>을 포함하는 브랜치 이름 패턴을 허용하지 않는 그룹이나 인스턴스 푸시 규칙이 있는 경우, ‘' 패턴을 따르지 않는 'Branch name 'update-policy-' does not follow the pattern ''' 오류가 발생합니다.

해결책은 그룹이나 인스턴스 푸시 규칙을 수정하여 정수 타임스탬프가 뒤따르는 update-policy- 패턴을 허용하도록 하는 것입니다.

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

• 스캐너가 올바르게 구성되고 최신 브랜치에 대한 결과를 생성하는지 확인하세요. 보안 정책은 결과가 없을 때(보안 보고서가 없을 때) 승인을 요구하도록 설계되었으며, 이는 새로운 취약점이 도입되지 않도록 보장합니다. 정책에 따라 강제된 스캔이 성공적으로 완료되고 평가되지 않는 한 어떤 취약점이 있는지 알 수 없습니다.
• 병합 요청 승인 정책의 경우 정책에 정의된 각 스캐너에 대한 아티팩트가 소스 및 대상 브랜치 모두에 필요합니다. 병합 요청 승인 정책이 필요한 결과를 포착하도록 하려면 스캔 실행이 올바르게 구현되고 강제되는지 확인하세요. 스캔 실행 정책을 사용하는 경우 ‘모든 브랜치’에 강제 적용하는 것이 이 요구 사항을 해결하는 데 도움이 됩니다.
• 병합 요청 승인 정책에서의 비교는 성공적으로 완료된 병합 베이스 파이프라인에 따라 달립니다. 병합 베이스 파이프라인이 건너뛰어질 경우, 병합 베이스 파이프라인이 있는 병합 요청이 차단됩니다.
• SAST 액션을 기반으로 하는 스캔 실행 정책을 실행할 때 대상 저장소에 올바른 코드 파일이 포함되어 있는지 확인하세요. SAST는 저장소에 있는 파일의 종류에 따라 다른 분석기를 실행합니다만 지원되는 파일이 없는 경우 작업을 실행하지 않습니다. 자세한 내용은 SAST CI 템플릿을 참조하세요.
• 브랜치 구성 충돌을 확인하세요. 예를 들어 정책이 main에 대한 규칙을 강제로 구성되었지만 일부 프로젝트가 기본 브랜치로 master를 사용하는 경우 해당 정책이 적용되지 않습니다. 이 문제를 해결하려면 프로젝트에서 사용하는 이름에 관계 없이 기본 브랜치에 대해 일반적으로 규칙을 강제로 정의하거나 이 문제를 해결하려면 모든 보호된 브랜치에 대해 정책을 강제로 적용할 수 있습니다.
• 그룹이나 서브그룹 수준에서 생성된 병합 요청 승인 정책이 그룹의 모든 병합 요청에 적용되는 데 몇 분이 걸릴 수 있습니다.
• 예약된 스캔 실행 정책은 최소 15분 간격으로 실행됩니다. 일정 규칙 유형에 대해 자세히 알아보세요.
• 파이프라인을 예약할 때 CRON 예약은 GitLab SaaS에서는 UTC를 기준으로 하며, 자체 관리형 인스턴스의 경우 서버 시간을 기준으로 합니다. 새로운 정책을 테스트할 때 파이프라인이 실제로 서버의 시간대에 예약되어 있는 것처럼 보일 수 있습니다.
• 스캔 실행 정책을 강제로 실행할 때 보안 정책은 대상 프로젝트에 있는 봇을 사용하여 예약된 파이프라인을 트리거합니다. 봇이 누락된 경우 자동으로 생성되며, 다음 예약된 스캔에서 사용됩니다.
• 보안 정책 프로젝트를 개발 프로젝트 및 해당 개발 프로젝트가 속한 그룹 또는 서브그룹에 동시에 연결해서는 안 됩니다. 이러한 방식으로 연결하면 스캔 결과 정책에서 승인 규칙이 개발 프로젝트의 병합 요청에 적용되지 않습니다.
• 스캔 결과 정책을 생성할 때 scan_finding 규칙에 있는 배열 severity_levels나 배열 vulnerability_states를 비워둘 수 없습니다. 작동하는 규칙에는 적어도 하나의 항목이 있어야 합니다.
• 병합 요청 승인 정책이 파이프라인에 수동 작업이 포함된 프로젝트에서 강제로 실행될 때 정책은 완료된 파이프라인 작업을 평가하고 수동 작업은 무시합니다. 수동 작업이 실행되면 정책이 MR을 다시 평가합니다.

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