정책
정책은 보안 및 규정 준수 팀에게 조직 내에서 전역적으로 통제를 강화하는 방법을 제공합니다.
보안 팀은 다음을 보장할 수 있습니다:
- 적절한 구성으로 개발 팀 파이프라인에서 보안 스캐너가 강제됩니다.
- 모든 스캔 작업이 변경이나 수정 없이 실행됩니다.
- 스캔 결과에 따라 Merge Request에 적절한 승인이 제공됩니다.
규정 준수 팀은 다음을 수행할 수 있습니다:
- 모든 Merge Request에 중앙에서 다수의 승인자를 강제합니다.
- 조직 요구 사항 범위 내의 프로젝트에 다양한 설정을 강제하거나 잠금을 걸수 있습니다. (예: Merge Request 및 리포지터리 설정 활성화 또는 잠금)
다음과 같은 정책 유형이 있습니다:
- 스캔 실행 정책. 파이프라인의 일부로 보안 스캔을 강제하거나 지정된 일정에 따라 보안 스캔을 실행합니다.
- Merge Request 승인 정책. 스캔 결과에 기반하여 프로젝트 수준의 설정 및 승인 규칙을 강제합니다.
보안 정책 프로젝트
보안 정책 프로젝트(SPP)는 정책만을 담는데 사용되는 특수 유형의 프로젝트입니다. 정책은 .gitlab/security-policies/policy.yml YAML 파일에 저장됩니다.
SPP에 포함된 정책을 강제하려면 프로젝트, 서브그룹, 그룹 또는 이러한 각각의 여러 항목과 연결해야 합니다. SPP에는 여러 정책을 포함할 수 있지만 함께 강제됩니다. 그룹이나 서브그룹에 강제된 SPP는 계층구조 아래의 모든 것에 적용됩니다. 이에는 모든 서브그룹과 해당 프로젝트도 포함됩니다.
Merge Request에서의 정책 변경은 Merge Request이 Merge됨과 동시에 적용됩니다. 그러나 Merge Request을 통과하지 않고 기본 브랜치에 직접 커밋되는 경우 정책 변경이 적용되기까지 최대 10분이 소요될 수 있습니다.
정책 설계 지침
정책을 설계할 때 목표는 다음과 같아야 합니다:
- 최소한의 오버헤드로 정책 강제 설계
- 권한의 분리
정책 강제 설계
정책 범위를 최대화하기 위해 목표를 달성하는 최상위 수준에서 SPP를 연결합니다: 그룹 레벨, 서브그룹 레벨 또는 프로젝트 레벨. 최상위 수준에서의 강제는 SPP 수와 따라서 관리 오버헤드를 최소화합니다. 각 수준에서 정책은 프로젝트로 내려가도록 되어 있어서, 정책은 그룹 수준, 그 상위의 각 서브그룹으로부터 내려가고, 그리고 프로젝트 자체에서 생성된 정책에 대해서도도 강제될 수 있습니다.
정책의 상속은 정책의 최소한의 수만 SPP, 그리고 최대의 범위로 적용되는 것을 보장하는 것뿐만 아니라 정책 변경을 구현할 때에도 도움이 됩니다. 예를 들어, 정책 변경을 테스트하기 위해 기존 정책을 복사하고 수정된 정책을 먼저 프로젝트에, 그 다음 서브그룹에, 그리고 가능한 경우에는 그룹에 강제할 수 있습니다.
다음 예제는 두 개의 그룹과 그들의 구조를 보여줍니다:
- 알파 그룹은 두 개의 서브그룹을 포함하고 있으며, 각각에는 여러 프로젝트가 포함되어 있습니다.
- 보안 및 규정 준수 그룹에는 두 개의 정책이 포함되어 있습니다.
알파 그룹 (코드 프로젝트 포함)
-
금융 (서브그룹)
- 프로젝트 A
- 계정 수신 (서브그룹)
- 프로젝트 B
- 프로젝트 C
-
엔지니어링 (서브그룹)
- 프로젝트 K
- 프로젝트 L
- 프로젝트 M
보안 및 규정 준수 그룹 (SPP 포함)
- 보안 정책 관리
- 보안 정책 관리 - 보안 정책 프로젝트
- SAST 정책
- 비밀 감지 정책
이미 강제된 정책이 없다고 가정하면, 다음 예제를 고려해 보십시오:
- “SAST” 정책이 알파 그룹에서 강제되면 그 하위 그룹, 금융 및 엔지니어링, 및 그들의 모든 프로젝트 및 서브그룹에 적용됩니다. “비밀 감지” 정책이 “계정 수신” 서브그룹에서 강제된 경우, 두 정책은 B 및 C 프로젝트에 적용됩니다. 그러나 A 프로젝트에는 “SAST” 정책만 적용됩니다.
- “SAST” 정책이 “계정 수신” 서브그룹에서 강제되면 B 및 C 프로젝트에만 적용됩니다. 프로젝트 A에는 정책이 적용되지 않습니다.
- “비밀 감지” 정책이 프로젝트 K에서 강제된 경우 프로젝트 K에만 적용됩니다. 다른 서브그룹이나 프로젝트에는 정책이 적용되지 않습니다.
권한의 분리
정책을 성공적으로 구현하기 위해서는 권한의 분리가 극히 중요합니다. 보안 및 규정 준수 팀은 정책을 정의하고 개발 팀과 협력해야 합니다. 개발 팀은 정책을 비활성화하거나 수정하거나 우회할 수 없어야 합니다. 정책은 필요한 준수 및 보안 요구 사항을 충족시키도록 구현되어야 하지만, 개발 팀이 목표를 달성할 수 있도록 허용해야 합니다.
SPP를 강제하는데 필요한 역할은 연결되는 계층 수준에 따라 다릅니다:
| 조직 단위 | 그룹 소유자 | 서브그룹 소유자 | 프로젝트 소유자 |
|---|---|---|---|
| 그룹 | 가능 | 불가능 | 불가능 |
| 서브그룹 | 가능 | 가능 | 불가능 |
| 프로젝트 | 가능 | 가능 | 가능 |
정책 구현
SPP의 구현 옵션은 GitLab SaaS와 GitLab Self-Managed형간에 약간의 차이가 있습니다. 주요 차이점은 GitLab SaaS에서는 서브그룹을 만들 수 있는 것이 유일한 차이입니다. 권한의 분리를 보장하려면 보다 정교한 권한 설정이 필요합니다.
서브그룹과 프로젝트에 걸친 정책 강제
서브그룹과 프로젝트에 대해 정책을 강제하려면, 정책을 포함할 서브그룹을 만들어야 합니다. 이 서브그룹은 프로젝트를 포함하는 서브그룹과 별도로 만들어져야 합니다. 별도의 서브그룹을 사용하면 보안 팀이 SPP를 관리하고 프로젝트의 서브그룹에 대한 개발 팀의 개입 없이 정책을 추가하거나 변경할 수 있습니다. 서브그룹과 프로젝트 소유자는 정책을 무시하거나 무효화할 수 없습니다.
전제 조건:
- SPP에 링크하려면 Owner 역할이 있어야 합니다. 자세한 내용은 권한의 분리를 참조하십시오.
여러 서브그룹에 걸쳐 정책을 강제하기 위한 상위 수준의 워크플로우:
-
정책을 포함하고 권한을 분리하도록 서브그룹을 만듭니다.
독립적인 서브그룹을 만들어 사용자의 권한을 상속받는 사용자의 수를 최소화할 수 있습니다.
-
새 그룹 또는 서브그룹에서 “보안 정책 관리”와 같은 정책을 관리할 프로젝트를 만듭니다.
이것은 정책 편집기의 기본 위치로 사용되어 UI에서 정책을 만들고 관리할 수 있습니다.
-
테스트 정책을 생성해 보세요. (테스트를 위해 비활성화된 정책을 만들 수 있습니다.)
정책을 생성하면 자동으로 새 SPP가 그룹 또는 서브그룹에 만들어집니다. 이 프로젝트는
policy.yml또는 정책으로 코드를 보관하는 데 사용됩니다. - 새로 만들어진 프로젝트에서 프로젝트 권한을 확인하고 보안 팀 멤버만 Owner 역할을 갖도록 설정하십시오.
- 상속된 권한을 차단하거나 정책 변경을 추가적인 검토 또는 승인이 필요하도록 만드는 추가적인 제약 사항이 필요하면, 첫 번째 제약에 대응하는 추가적이고 별개의 정책을 만들 수 있습니다. 예를 들어, 정책 변경에 대해 승인할 역할을 담당하는 개별 사용자들의 단일 집합을 정의할 수 있습니다.
- 새로 만든 SPP에서 필요한 정책을 생성합니다.
Security Policy Management프로젝트의 정책 탭에서 정책 편집기를 사용하거나 새로 만든 보안 정책 프로젝트Security Policy Management - security policy project에 저장된policy.yml파일에서 정책을 직접 업데이트할 수 있습니다. - 서브그룹 소유자 또는 프로젝트 소유자로서, SPP에 대한 링크를 만들어야 합니다. 서브그룹 소유자나 프로젝트 소유자는 정책 페이지를 방문하여 SPP에 대한 연결을 만들 수 있습니다. 프로젝트의 경로를 포함해야 하며 프로젝트의 이름은 “- security policy project”로 끝나야 합니다. 자세한 내용은 보안 정책 프로젝트에 링크를 참조하십시오.
그룹, 서브그룹 및 프로젝트 전반에 걸친 정책 강제 적용
여러 그룹에서 정책을 강제하려면 SPP를 포함하는 그룹을 만들어야 합니다. 이 그룹은 프로젝트를 포함한 그룹과 별도로 유지되어야 합니다. 별도의 그룹을 사용하면 보안 팀이 SPP를 관리하고 프로젝트 그룹을 개발 팀이 관리하여 역할을 분리할 수 있습니다. 보안 팀은 그룹 소유자의 개입 없이 정책을 추가하거나 변경할 수 있습니다. 서브그룹 및 프로젝트 소유자는 정책을 재정의할 수 없습니다.
사전 준비 사항:
- SPP에 링크하려면 소유자 역할이어야 합니다. 자세한 내용은 역할 간 분리를 참조하세요.
- 인스턴스 전역에서 승인 그룹을 지원하려면 GitLab 인스턴스 애플리케이션 설정에서
security_policy_global_group_approvers_enabled를 활성화하세요.
여러 그룹에 걸친 정책을 강제 적용하는 고수준의 워크플로우:
-
별도의 그룹을 만들어 정책을 포함하고 역할을 분리하세요.
별도의 독립 그룹을 생성함으로써 권한을 상속받는 사용자 수를 최소화할 수 있습니다.
-
새 그룹에서 “보안 정책 관리”와 같이 정책을 관리하는 새 프로젝트를 만드세요.
이 프로젝트는 정책 편집기의 기본 위치로 지정되어 UI에서 정책을 만들고 관리할 수 있습니다.
-
실험용 정책을 생성하세요 (테스트를 위해 비활성화된 정책을 만들 수 있습니다).
정책을 만들면 자동으로 새 SPP가 그룹 내에 만들어집니다. 이 프로젝트는
policy.yml또는 정책-코드를 저장하는 데 사용됩니다. - 새로 만든 프로젝트의 권한을 확인하고 원하는대로 설정하세요. 기본적으로 소유자 및 유지 관리자는 정책을 만들고 편집 및 삭제할 수 있습니다.
- 상속된 권한 차단이나 정책 변경에 대한 추가적인 검토 또는 승인이 필요한 경우, 처음에 적용할 추가적인 분리된 정책 세트를 만들 수 있습니다. 예를 들어, 정책 변경을 승인하는 개별 사용자 세트를 정의할 수 있습니다.
- SPP의 권한을 설정하여 보안 팀 멤버만 소유자 역할을 가지도록하세요.
- 방금 만든 SPP에서 필요한 정책을 만드세요.
- 그룹 소유자, 서브그룹 소유자 또는 프로젝트 소유자로서 SPP에 그룹, 서브그룹 또는 프로젝트를 연결할 수 있습니다. 정책 페이지를 방문하여 SPP에 링크를 만들 수 있습니다. 프로젝트의 전체 경로를 포함해야 하며 프로젝트 이름은 “- security policy project”로 끝나야 합니다. 자세한 내용은 보안 정책 프로젝트에 링크를 참조하세요.
다중 프로젝트에 걸친 정책 강제 적용
그룹이나 서브그룹을 정책과 연결하는 것이 충분하지 않은 경우, 프로젝트별로 SPP에 연결할 수 있습니다. 이렇게 하면 해당하지 않는 프로젝트에 대한 강제 적용에서 프로젝트를 필터링할 수 있습니다. 프로젝트 수준에서 SPP 정책을 강제 적용하려면 보안 팀만 보유해야 하는 Owner 역할을 가진 security policy 프로젝트를 만들어야 합니다.
프로젝트에 정책을 강제 적용하는 방법:
- 대상 프로젝트와 동일한 수준에 보안 정책 프로젝트를 만드세요.
- 보안 정책 프로젝트에서 필요한 정책을 만듭니다.
- 대상 프로젝트를 보안 정책 프로젝트에 연결합니다.
보안 정책 프로젝트에 링크
프로젝트, 서브그룹 또는 그룹에 있는 SPP에 포함된 정책을 강제 적용하려면 해당 프로젝트, 서브그룹 또는 그룹에 링크를 만듭니다.
사전 준비 사항:
- SPP에 링크하려면 소유자 역할이어야 합니다. 자세한 내용은 역할 간 분리를 참조하세요.
프로젝트, 서브그룹 또는 그룹을 SPP에 링크하려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트, 서브그룹 또는 그룹을 찾습니다.
- 보안 > 정책을 선택합니다.
- 정책 프로젝트 편집을 선택한 다음 드롭다운 디렉터리에서 링크를 만들 프로젝트를 검색하고 선택합니다.
- 저장을 선택합니다.
보안 정책 프로젝트를 링크 해제하려면 동일한 단계를 따르되 대화 상자에서 휴지통 아이콘을 대신 선택합니다.
연결된 보안 정책 프로젝트 보기
프로젝트 정책 페이지에 액세스할 수 있는 모든 사용자는 해당 프로젝트에 연결된 보안 정책 프로젝트로 연결되는 버튼을 볼 수 있습니다.
정책 관리
정책 페이지는 모든 사용 가능한 환경에 대한 배포된 정책을 표시합니다. 정책의 정보(예: 설명 또는 강제 적용 상태)를 확인하고 배포된 정책을 만들고 편집할 수 있습니다.
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 보안 > 정책을 선택합니다.
정책 편집기
정책 편집기를 사용하여 정책을 만들고 편집하고 삭제할 수 있습니다.
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
-
보안 > 정책을 선택합니다.
- 새로운 정책을 만들려면 정책 만들기를 선택합니다. 이것은 Policies 페이지의 헤더에 위치해 있습니다. 그런 다음 어떤 유형의 정책을 만들지 선택할 수 있습니다.
- 기존 정책을 편집하려면 선택한 정책 창에서 정책 편집을 선택합니다.
정책 편집기에는 두 가지 모드가 있습니다:
-
시각적인 Rule 모드는 규칙 블록과 관련된 제어들을 사용하여 정책 규칙을 구성하고 미리 보기할 수 있습니다.
-
YAML 모드는
.yaml형식으로 정책 정의를 입력할 수 있으며 전문가 사용자 및 규칙 모드가 지원하지 않는 경우에 사용됩니다.
두 모드를 상호교환하여 사용하고 언제든지 모드를 전환할 수 있습니다. YAML 리소스에 오류가 있거나 규칙 모드에서 지원하지 않는 데이터가 포함되어 있는 경우 규칙 모드가 자동으로 비활성화됩니다. YAML에 오류가 있으면 규칙 모드가 다시 사용 가능하도록 하기 전에 YAML 모드를 사용하여 정책을 수정해야 합니다.
정책 편집을 완료하거나 수정한 경우 Merge Request으로 구성 버튼을 선택하고 결과적인 Merge Request을 Merge하여 적용하세요. 이 버튼을 누르면 정책 YAML이 유효성을 검사하고 발생한 오류를 표시합니다. 또한 프로젝트 소유자이고 보안 정책 프로젝트가 이전에 이 프로젝트에 자동으로 연결된 적이 없는 경우, 첫 번째 정책 Merge Request이 만들어지는 동시에 자동으로 새 프로젝트가 만들어져 연결됩니다.
스크립트를 사용한 대량 프로젝트 관리
Vulnerability-Check Migration 스크립트를 사용하여 대량으로 정책을 만들거나 개발 프로젝트에 보안 정책 프로젝트를 연결할 수 있습니다. Vulnerability-Check Migration 스크립트의 사용 방법 및 데모에 대한 자세한 내용은 이 비디오를 참조하세요.
문제 해결
Branch name 'update-policy-<timestamp>' does not follow the pattern '<branch_name_regex>'
새 보안 정책을 만들거나 기존 정책을 변경하면 분기 이름은 자동으로 ‘update-policy-
‘Timestamp’ 이후에 텍스트 update-policy-<timestamp>를 포함하는 분기 이름이 허용되지 않는 그룹 또는 인스턴스 푸시 규칙이 있는 경우, ‘
해결책은 그룹 또는 인스턴스 푸시 규칙을 수정하여 ‘update-policy-` 뒤에 정수 타임스탬프가 따르는 분기를 허용하도록 하는 것입니다.
보안 정책 구성에 대한 일반적인 문제 해결
- 스캐너가 올바르게 구성되어 있고 최신 브랜치에 결과를 생성하는지 확인하세요. 보안 정책은 결과가 없을 때(보안 보고서가 없을 때) 결함이 없음을 보장하기 위해 승인이 필요합니다. 스캔이 올바로 실행되고 강제되는지 확인하여 결과를 확인하세요.
- Merge Request 승인 정책의 경우, 정책에 정의된 각 스캐너에 대한 아티팩트가 소스 및 대상 브랜치에 있는지 확인하세요. Merge Request 승인 정책이 필요한 필수 결과를 포착하기 위해 스캔 실행이 올바르게 구현되고 강제되는지 확인하세요. 스캔 실행 정책을 사용하는 경우, 이를
모든 브랜치에서 강제하면 이러한 필요를 만족하는 경우가 많습니다. - Merge Request 승인 정책의 비교는 성공적인 및 완료된 Merge 베이스 파이프라인에 따라 진행됩니다. Merge 베이스 파이프라인을 건너 뛰는 경우, Merge Request의 Merge 베이스 파이프라인이 차단됩니다.
- SAST 액션을 기반으로 하는 스캔 실행 정책을 실행하는 경우, 대상 리포지터리에 올바른 코드 파일이 있는지 확인하세요. SAST는 리포지터리에 있는 파일의 종류에 따라 다른 분석기를 실행하며, 지원되는 파일이 없는 경우 작업을 실행하지 않습니다. 자세한 내용은 SAST CI 템플릿을 참조하세요.
- 모든 브랜치에서 규칙을 강제하도록 정책을 구성하는 경우, 브랜치 설정 충돌을 확인하세요. 예를 들어, 정책이
main에 대해 규칙을 강제하도록 구성되어 있지만 대상 프로젝트의 일부가 기본 브랜치로master를 사용하고 있는 경우, 정책이 이에 적용되지 않습니다. 이 문제를 해결하기 위해 프로젝트 내에서 사용되는 이름과 관계없이기본 브랜치에 대한 규칙을 일반적으로 정의할 수 있습니다. - 그룹 또는 서브그룹 수준에서 만든 Merge Request 승인 정책이 그룹 내의 모든 Merge Request에 적용되기까지는 시간이 걸릴 수 있습니다.
- Merge Request 승인 정책은 최소 15분 주기로 예약 스캔 실행 정책 중첩 시간입니다. 스케줄 규칙 유형에 대한 자세한 내용은 여기를 확인하세요.
- 파이프
도움말