InfoGrab Docs

보안 정책 프로젝트

요약

보안 정책 프로젝트는 여러 프로젝트에 걸쳐 정책을 강제 적용합니다. 머지 리퀘스트에서 수행된 정책 변경은 머지 리퀘스트가 병합되는 즉시 적용됩니다. 정책은 .gitlab/security-policies/policy.yml YAML 파일에 저장됩니다.

보안 정책 프로젝트는 여러 프로젝트에 걸쳐 정책을 강제 적용합니다. 보안 정책 프로젝트는 정책만 포함하기 위한 특수 유형의 프로젝트입니다. 보안 정책 프로젝트에 포함된 정책을 강제 적용하려면 보안 정책 프로젝트를 정책을 적용할 프로젝트, 서브그룹 또는 그룹에 연결합니다. 보안 정책 프로젝트는 여러 정책을 포함할 수 있지만 함께 강제 적용됩니다. 그룹 또는 서브그룹에 강제 적용된 보안 정책 프로젝트는 모든 서브그룹과 해당 프로젝트를 포함하여 계층 구조 아래의 모든 항목에 적용됩니다.

머지 리퀘스트에서 수행된 정책 변경은 머지 리퀘스트가 병합되는 즉시 적용됩니다. 머지 리퀘스트를 거치지 않고 기본 브랜치에 직접 커밋된 변경은 정책 변경이 적용되기까지 최대 10분이 걸릴 수 있습니다.

정책은 .gitlab/security-policies/policy.yml YAML 파일에 저장됩니다.

보안 정책 프로젝트 구현#

보안 정책 프로젝트의 구현 옵션은 GitLab.com, GitLab Dedicated, GitLab Self-Managed 간에 약간 다릅니다. 주요 차이점은 GitLab.com에서는 서브그룹만 만들 수 있다는 것입니다. 의무 분리를 보장하려면 더 세밀한 권한 구성이 필요합니다.

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

사전 요건:

  • 보안 정책 프로젝트에 연결하려면 소유자(Owner) 권한 또는 manage_security_policy_link 권한이 있는 커스텀 권한이 있어야 합니다. 자세한 내용은 의무 분리를 참조하세요.

GitLab.com 네임스페이스의 모든 서브그룹 및 프로젝트에 걸쳐 전역으로 정책을 강제 적용하는 높은 수준의 워크플로우:

  1. 최상위 그룹에서 Policies 탭을 방문합니다.

  2. 서브그룹에서 Policies 탭으로 이동하여 테스트 정책을 만듭니다.

    테스트를 위해 비활성화된 상태로 정책을 만들 수 있습니다. 정책을 만들면 최상위 그룹 아래에 새 보안 정책 프로젝트가 자동으로 만들어집니다. 이 프로젝트는 policy.yml 또는 코드로서의 정책을 저장하는 데 사용됩니다.

  3. 원하는 대로 새로 만든 프로젝트의 권한을 확인하고 설정합니다.

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

  4. 서브그룹 내에 만들어진 보안 정책 프로젝트에서 필요한 정책을 만듭니다.

    만든 Security Policy Management 프로젝트에서 Policies 탭 아래의 정책 편집기를 사용할 수 있습니다. 또는 새로 만들어진 보안 정책 프로젝트 Security Policy Management - security policy project에 저장된 policy.yml 파일에서 직접 정책을 업데이트할 수 있습니다.

  5. 그룹, 서브그룹 또는 프로젝트를 보안 정책 프로젝트에 연결합니다.

    서브그룹 소유자 또는 적절한 권한이 있는 프로젝트 소유자로서 Policies 페이지를 방문하여 보안 정책 프로젝트에 대한 링크를 만들 수 있습니다. 전체 경로를 포함하고 프로젝트 이름은 "- security policy project"로 끝나야 합니다. 연결된 모든 그룹, 서브그룹, 프로젝트는 보안 정책 프로젝트에서 만들어진 정책에 의해 "강제 적용 가능"하게 됩니다. 자세한 내용은 보안 정책 프로젝트에 연결을 참조하세요.

  6. 기본적으로 정책이 활성화되면 연결된 그룹, 서브그룹, 프로젝트의 모든 프로젝트에 강제 적용됩니다.

    더 세밀한 강제 적용을 위해 정책 범위를 추가합니다. 정책 범위를 사용하면 특정 프로젝트 세트 또는 규정 준수 프레임워크 레이블 세트가 포함된 프로젝트에 대해 정책을 강제 적용할 수 있습니다.

  7. 상속된 권한을 차단하거나 정책 변경에 대한 추가 검토 또는 승인이 필요한 경우와 같은 추가 제한이 필요한 경우 보안 정책 프로젝트에만 범위가 지정된 추가 정책을 만들고 추가 승인을 강제 적용할 수 있습니다.

GitLab Dedicated 또는 GitLab Self-Managed에서 전역으로 정책 강제 적용#

Note

GitLab Self-Managed에서 규정 준수 및 보안 정책 그룹을 사용하여 인스턴스 전반에 걸쳐 보안 정책을 강제 적용할 수도 있습니다.

사전 요건:

  • 보안 정책 프로젝트에 연결하려면 소유자(Owner) 권한 또는 manage_security_policy_link 권한이 있는 커스텀 권한이 있어야 합니다. 자세한 내용은 의무 분리를 참조하세요.
  • 인스턴스 전반에 걸쳐 승인 그룹을 지원하려면 GitLab 인스턴스 애플리케이션 설정에서 security_policy_global_group_approvers_enabled를 활성화합니다.

여러 그룹에 걸쳐 정책을 강제 적용하는 높은 수준의 워크플로우:

  1. 정책을 포함하고 의무 분리를 보장하기 위한 별도의 그룹을 만듭니다.

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

  2. 새 그룹에서 Policies 탭을 방문합니다.

    이것은 정책 편집기의 기본 위치로 사용되어 UI에서 정책을 만들고 관리할 수 있습니다.

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

    정책을 만들면 그룹 아래에 새 보안 정책 프로젝트가 자동으로 만들어집니다. 이 프로젝트는 policy.yml 또는 코드로서의 정책을 저장하는 데 사용됩니다.

  4. 원하는 대로 새로 만든 프로젝트의 권한을 확인하고 설정합니다.

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

  5. 서브그룹에서 만들어진 보안 정책 프로젝트에서 필요한 정책을 만듭니다.

    만든 Security Policy Management 프로젝트에서 Policies 탭 아래의 정책 편집기를 사용할 수 있습니다. 또는 새로 만들어진 보안 정책 프로젝트 Security Policy Management - security policy project에 저장된 policy.yml 파일에서 직접 정책을 업데이트할 수 있습니다.

  6. 그룹, 서브그룹 또는 프로젝트를 보안 정책 프로젝트에 연결합니다.

    서브그룹 소유자 또는 적절한 권한이 있는 프로젝트 소유자로서 Policies 페이지를 방문하여 보안 정책 프로젝트에 대한 링크를 만들 수 있습니다. 전체 경로를 포함하고 프로젝트 이름은 "- security policy project"로 끝나야 합니다. 연결된 모든 그룹, 서브그룹, 프로젝트는 보안 정책 프로젝트에서 만들어진 정책에 의해 "강제 적용 가능"하게 됩니다. 자세한 내용은 보안 정책 프로젝트에 연결을 참조하세요.

  7. 기본적으로 정책이 활성화되면 연결된 그룹, 서브그룹, 프로젝트의 모든 프로젝트에 강제 적용됩니다. 더 세밀한 강제 적용을 위해 정책 범위를 추가합니다. 정책 범위를 사용하면 특정 프로젝트 세트 또는 규정 준수 프레임워크 레이블 세트가 포함된 프로젝트에 대해 정책을 강제 적용할 수 있습니다.

  8. 상속된 권한을 차단하거나 정책 변경에 대한 추가 검토 또는 승인이 필요한 경우와 같은 추가 제한이 필요한 경우 보안 정책 프로젝트에만 범위가 지정된 추가 정책을 만들고 추가 승인을 강제 적용할 수 있습니다.

보안 정책 프로젝트에 연결#

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

사전 요건:

  • 보안 정책 프로젝트에 연결하려면 소유자(Owner) 권한 또는 manage_security_policy_link 권한이 있는 커스텀 권한이 있어야 합니다. 자세한 내용은 의무 분리를 참조하세요.

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

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트, 서브그룹 또는 그룹을 찾습니다.
  2. Secure > Policies를 선택합니다.
  3. Edit Policy Project를 선택한 다음 드롭다운 목록에서 연결할 프로젝트를 검색하고 선택합니다.
  4. Save를 선택합니다.

보안 정책 프로젝트의 연결을 해제하려면 동일한 단계를 따르되 대화 상자에서 휴지통 아이콘을 선택합니다. 동일한 최상위 그룹의 다른 서브그룹이나 완전히 다른 최상위 그룹에서 보안 정책 프로젝트에 연결할 수 있습니다. 그러나 파이프라인 실행 정책을 강제 적용할 때 사용자는 파이프라인을 트리거하기 위해 정책에서 참조하는 CI/CD 구성을 포함하는 프로젝트에 대한 최소한 읽기 전용 접근 권한이 있어야 합니다.

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

프로젝트 정책 페이지에 접근할 수 있지만 프로젝트 소유자가 아닌 사용자는 연결된 보안 정책 프로젝트로 연결하는 버튼을 대신 봅니다.

보안 정책 프로젝트를 하나 이상의 그룹 또는 프로젝트에 연결할 수 있습니다. 연결된 그룹 또는 프로젝트 중 하나에서 보안 정책을 볼 수 있는 권한이 있는 사람은 다른 연결된 그룹 및 프로젝트에서 어떤 보안 정책이 강제 적용되는지 확인할 수 있습니다.

정책 한도 변경#

히스토리

성능상의 이유로 GitLab은 보안 정책 프로젝트에 구성할 수 있는 정책 수를 제한합니다.

Warning

한도를 보안 정책 프로젝트에 현재 저장된 정책 수보다 낮게 줄이면 GitLab은 한도 이후의 정책을 강제 적용하지 않습니다. 정책을 다시 활성화하려면 가장 큰 보안 정책 프로젝트의 정책 수와 일치하도록 한도를 늘립니다.

기본 한도는 다음과 같습니다:

정책 유형 기본 정책 한도
머지 리퀘스트 승인 정책 5
스캔 실행 정책 5
파이프라인 실행 정책 5
취약점 관리 정책 5

GitLab Self-Managed 인스턴스에서 인스턴스 관리자는 전체 인스턴스의 한도를 각 정책 유형별 최대 20개까지 조정할 수 있습니다. 관리자는 특정 최상위 그룹의 한도도 변경할 수 있습니다.

인스턴스의 정책 한도 변경#

사전 요건:

  • 관리자 접근 권한.

조직이 보안 정책 프로젝트에 저장할 수 있는 최대 정책 수를 변경하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > Security and compliance를 선택합니다.
  3. Security policies 섹션을 확장합니다.
  4. 변경하려는 각 정책 유형에 대해 Maximum number of {policy type} allowed per security policy configuration에 새 값을 설정합니다.
  5. Save changes를 선택합니다.

최상위 그룹의 정책 한도 변경#

그룹 한도는 구성된 기본 인스턴스 한도를 초과할 수 있습니다. 최상위 그룹에 대한 보안 정책 프로젝트에 저장할 수 있는 최대 정책 수를 변경하려면:

Note

이 한도를 늘리면 특히 복잡한 정책이 많은 경우 시스템 성능에 영향을 미칠 수 있습니다.

사전 요건:

  • 관리자 접근 권한.

최상위 그룹의 한도를 조정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Overview > Groups를 선택합니다.
  3. 수정할 최상위 그룹의 행에서 Edit를 선택합니다.
  4. 변경하려는 각 정책 유형에 대해 Maximum number of {policy type} allowed per security policy configuration에 새 값을 설정합니다.
  5. Save changes를 선택합니다.

개별 그룹의 한도를 0으로 설정하면 시스템은 인스턴스 전체 기본값을 사용합니다. 이를 통해 한도가 0인 그룹도 기본 인스턴스 구성에 따라 정책을 만들 수 있습니다.

보안 정책 프로젝트 삭제#

히스토리
  • 보안 정책 프로젝트의 삭제 보호가 reject_security_policy_project_deletion이라는 플래그와 함께 GitLab 17.8에서 도입되었습니다. 기본적으로 활성화됩니다.
  • 보안 정책 프로젝트를 포함하는 그룹에 대한 삭제 보호가 reject_security_policy_project_deletion_groups라는 플래그와 함께 GitLab 17.9에서 도입되었습니다. 기본적으로 활성화됩니다.
  • 보안 정책 프로젝트 및 보안 정책 프로젝트가 포함된 그룹에 대한 삭제 보호가 GitLab 17.10에서 일반적으로 사용 가능하게 되었습니다. 기능 플래그 reject_security_policy_project_deletionreject_security_policy_project_deletion_groups가 제거되었습니다.

보안 정책 프로젝트 또는 해당 상위 그룹 중 하나를 삭제하려면 다른 모든 프로젝트 또는 그룹에서 해당 링크를 제거해야 합니다. 그렇지 않으면 연결된 보안 정책 프로젝트 또는 상위 그룹을 삭제하려고 할 때 오류 메시지가 표시됩니다.

보안 정책 프로젝트

Tier: Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

보안 정책 프로젝트는 여러 프로젝트에 걸쳐 정책을 강제 적용합니다. 머지 리퀘스트에서 수행된 정책 변경은 머지 리퀘스트가 병합되는 즉시 적용됩니다. 정책은 .gitlab/security-policies/policy.yml YAML 파일에 저장됩니다.

보안 정책 프로젝트는 여러 프로젝트에 걸쳐 정책을 강제 적용합니다. 보안 정책 프로젝트는 정책만 포함하기 위한 특수 유형의 프로젝트입니다. 보안 정책 프로젝트에 포함된 정책을 강제 적용하려면 보안 정책 프로젝트를 정책을 적용할 프로젝트, 서브그룹 또는 그룹에 연결합니다. 보안 정책 프로젝트는 여러 정책을 포함할 수 있지만 함께 강제 적용됩니다. 그룹 또는 서브그룹에 강제 적용된 보안 정책 프로젝트는 모든 서브그룹과 해당 프로젝트를 포함하여 계층 구조 아래의 모든 항목에 적용됩니다.

머지 리퀘스트에서 수행된 정책 변경은 머지 리퀘스트가 병합되는 즉시 적용됩니다. 머지 리퀘스트를 거치지 않고 기본 브랜치에 직접 커밋된 변경은 정책 변경이 적용되기까지 최대 10분이 걸릴 수 있습니다.

정책은 .gitlab/security-policies/policy.yml YAML 파일에 저장됩니다.

보안 정책 프로젝트 구현#

보안 정책 프로젝트의 구현 옵션은 GitLab.com, GitLab Dedicated, GitLab Self-Managed 간에 약간 다릅니다. 주요 차이점은 GitLab.com에서는 서브그룹만 만들 수 있다는 것입니다. 의무 분리를 보장하려면 더 세밀한 권한 구성이 필요합니다.

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

사전 요건:

  • 보안 정책 프로젝트에 연결하려면 소유자(Owner) 권한 또는 manage_security_policy_link 권한이 있는 커스텀 권한이 있어야 합니다. 자세한 내용은 의무 분리를 참조하세요.

GitLab.com 네임스페이스의 모든 서브그룹 및 프로젝트에 걸쳐 전역으로 정책을 강제 적용하는 높은 수준의 워크플로우:

  1. 최상위 그룹에서 Policies 탭을 방문합니다.

  2. 서브그룹에서 Policies 탭으로 이동하여 테스트 정책을 만듭니다.

    테스트를 위해 비활성화된 상태로 정책을 만들 수 있습니다. 정책을 만들면 최상위 그룹 아래에 새 보안 정책 프로젝트가 자동으로 만들어집니다. 이 프로젝트는 policy.yml 또는 코드로서의 정책을 저장하는 데 사용됩니다.

  3. 원하는 대로 새로 만든 프로젝트의 권한을 확인하고 설정합니다.

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

  4. 서브그룹 내에 만들어진 보안 정책 프로젝트에서 필요한 정책을 만듭니다.

    만든 Security Policy Management 프로젝트에서 Policies 탭 아래의 정책 편집기를 사용할 수 있습니다. 또는 새로 만들어진 보안 정책 프로젝트 Security Policy Management - security policy project에 저장된 policy.yml 파일에서 직접 정책을 업데이트할 수 있습니다.

  5. 그룹, 서브그룹 또는 프로젝트를 보안 정책 프로젝트에 연결합니다.

    서브그룹 소유자 또는 적절한 권한이 있는 프로젝트 소유자로서 Policies 페이지를 방문하여 보안 정책 프로젝트에 대한 링크를 만들 수 있습니다. 전체 경로를 포함하고 프로젝트 이름은 "- security policy project"로 끝나야 합니다. 연결된 모든 그룹, 서브그룹, 프로젝트는 보안 정책 프로젝트에서 만들어진 정책에 의해 "강제 적용 가능"하게 됩니다. 자세한 내용은 보안 정책 프로젝트에 연결을 참조하세요.

  6. 기본적으로 정책이 활성화되면 연결된 그룹, 서브그룹, 프로젝트의 모든 프로젝트에 강제 적용됩니다.

    더 세밀한 강제 적용을 위해 정책 범위를 추가합니다. 정책 범위를 사용하면 특정 프로젝트 세트 또는 규정 준수 프레임워크 레이블 세트가 포함된 프로젝트에 대해 정책을 강제 적용할 수 있습니다.

  7. 상속된 권한을 차단하거나 정책 변경에 대한 추가 검토 또는 승인이 필요한 경우와 같은 추가 제한이 필요한 경우 보안 정책 프로젝트에만 범위가 지정된 추가 정책을 만들고 추가 승인을 강제 적용할 수 있습니다.

GitLab Dedicated 또는 GitLab Self-Managed에서 전역으로 정책 강제 적용#

Note

GitLab Self-Managed에서 규정 준수 및 보안 정책 그룹을 사용하여 인스턴스 전반에 걸쳐 보안 정책을 강제 적용할 수도 있습니다.

사전 요건:

  • 보안 정책 프로젝트에 연결하려면 소유자(Owner) 권한 또는 manage_security_policy_link 권한이 있는 커스텀 권한이 있어야 합니다. 자세한 내용은 의무 분리를 참조하세요.
  • 인스턴스 전반에 걸쳐 승인 그룹을 지원하려면 GitLab 인스턴스 애플리케이션 설정에서 security_policy_global_group_approvers_enabled를 활성화합니다.

여러 그룹에 걸쳐 정책을 강제 적용하는 높은 수준의 워크플로우:

  1. 정책을 포함하고 의무 분리를 보장하기 위한 별도의 그룹을 만듭니다.

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

  2. 새 그룹에서 Policies 탭을 방문합니다.

    이것은 정책 편집기의 기본 위치로 사용되어 UI에서 정책을 만들고 관리할 수 있습니다.

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

    정책을 만들면 그룹 아래에 새 보안 정책 프로젝트가 자동으로 만들어집니다. 이 프로젝트는 policy.yml 또는 코드로서의 정책을 저장하는 데 사용됩니다.

  4. 원하는 대로 새로 만든 프로젝트의 권한을 확인하고 설정합니다.

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

  5. 서브그룹에서 만들어진 보안 정책 프로젝트에서 필요한 정책을 만듭니다.

    만든 Security Policy Management 프로젝트에서 Policies 탭 아래의 정책 편집기를 사용할 수 있습니다. 또는 새로 만들어진 보안 정책 프로젝트 Security Policy Management - security policy project에 저장된 policy.yml 파일에서 직접 정책을 업데이트할 수 있습니다.

  6. 그룹, 서브그룹 또는 프로젝트를 보안 정책 프로젝트에 연결합니다.

    서브그룹 소유자 또는 적절한 권한이 있는 프로젝트 소유자로서 Policies 페이지를 방문하여 보안 정책 프로젝트에 대한 링크를 만들 수 있습니다. 전체 경로를 포함하고 프로젝트 이름은 "- security policy project"로 끝나야 합니다. 연결된 모든 그룹, 서브그룹, 프로젝트는 보안 정책 프로젝트에서 만들어진 정책에 의해 "강제 적용 가능"하게 됩니다. 자세한 내용은 보안 정책 프로젝트에 연결을 참조하세요.

  7. 기본적으로 정책이 활성화되면 연결된 그룹, 서브그룹, 프로젝트의 모든 프로젝트에 강제 적용됩니다. 더 세밀한 강제 적용을 위해 정책 범위를 추가합니다. 정책 범위를 사용하면 특정 프로젝트 세트 또는 규정 준수 프레임워크 레이블 세트가 포함된 프로젝트에 대해 정책을 강제 적용할 수 있습니다.

  8. 상속된 권한을 차단하거나 정책 변경에 대한 추가 검토 또는 승인이 필요한 경우와 같은 추가 제한이 필요한 경우 보안 정책 프로젝트에만 범위가 지정된 추가 정책을 만들고 추가 승인을 강제 적용할 수 있습니다.

보안 정책 프로젝트에 연결#

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

사전 요건:

  • 보안 정책 프로젝트에 연결하려면 소유자(Owner) 권한 또는 manage_security_policy_link 권한이 있는 커스텀 권한이 있어야 합니다. 자세한 내용은 의무 분리를 참조하세요.

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

  1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트, 서브그룹 또는 그룹을 찾습니다.
  2. Secure > Policies를 선택합니다.
  3. Edit Policy Project를 선택한 다음 드롭다운 목록에서 연결할 프로젝트를 검색하고 선택합니다.
  4. Save를 선택합니다.

보안 정책 프로젝트의 연결을 해제하려면 동일한 단계를 따르되 대화 상자에서 휴지통 아이콘을 선택합니다. 동일한 최상위 그룹의 다른 서브그룹이나 완전히 다른 최상위 그룹에서 보안 정책 프로젝트에 연결할 수 있습니다. 그러나 파이프라인 실행 정책을 강제 적용할 때 사용자는 파이프라인을 트리거하기 위해 정책에서 참조하는 CI/CD 구성을 포함하는 프로젝트에 대한 최소한 읽기 전용 접근 권한이 있어야 합니다.

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

프로젝트 정책 페이지에 접근할 수 있지만 프로젝트 소유자가 아닌 사용자는 연결된 보안 정책 프로젝트로 연결하는 버튼을 대신 봅니다.

보안 정책 프로젝트를 하나 이상의 그룹 또는 프로젝트에 연결할 수 있습니다. 연결된 그룹 또는 프로젝트 중 하나에서 보안 정책을 볼 수 있는 권한이 있는 사람은 다른 연결된 그룹 및 프로젝트에서 어떤 보안 정책이 강제 적용되는지 확인할 수 있습니다.

정책 한도 변경#

히스토리

성능상의 이유로 GitLab은 보안 정책 프로젝트에 구성할 수 있는 정책 수를 제한합니다.

Warning

한도를 보안 정책 프로젝트에 현재 저장된 정책 수보다 낮게 줄이면 GitLab은 한도 이후의 정책을 강제 적용하지 않습니다. 정책을 다시 활성화하려면 가장 큰 보안 정책 프로젝트의 정책 수와 일치하도록 한도를 늘립니다.

기본 한도는 다음과 같습니다:

정책 유형 기본 정책 한도
머지 리퀘스트 승인 정책 5
스캔 실행 정책 5
파이프라인 실행 정책 5
취약점 관리 정책 5

GitLab Self-Managed 인스턴스에서 인스턴스 관리자는 전체 인스턴스의 한도를 각 정책 유형별 최대 20개까지 조정할 수 있습니다. 관리자는 특정 최상위 그룹의 한도도 변경할 수 있습니다.

인스턴스의 정책 한도 변경#

사전 요건:

  • 관리자 접근 권한.

조직이 보안 정책 프로젝트에 저장할 수 있는 최대 정책 수를 변경하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > Security and compliance를 선택합니다.
  3. Security policies 섹션을 확장합니다.
  4. 변경하려는 각 정책 유형에 대해 Maximum number of {policy type} allowed per security policy configuration에 새 값을 설정합니다.
  5. Save changes를 선택합니다.

최상위 그룹의 정책 한도 변경#

그룹 한도는 구성된 기본 인스턴스 한도를 초과할 수 있습니다. 최상위 그룹에 대한 보안 정책 프로젝트에 저장할 수 있는 최대 정책 수를 변경하려면:

Note

이 한도를 늘리면 특히 복잡한 정책이 많은 경우 시스템 성능에 영향을 미칠 수 있습니다.

사전 요건:

  • 관리자 접근 권한.

최상위 그룹의 한도를 조정하려면:

  1. 오른쪽 상단에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Overview > Groups를 선택합니다.
  3. 수정할 최상위 그룹의 행에서 Edit를 선택합니다.
  4. 변경하려는 각 정책 유형에 대해 Maximum number of {policy type} allowed per security policy configuration에 새 값을 설정합니다.
  5. Save changes를 선택합니다.

개별 그룹의 한도를 0으로 설정하면 시스템은 인스턴스 전체 기본값을 사용합니다. 이를 통해 한도가 0인 그룹도 기본 인스턴스 구성에 따라 정책을 만들 수 있습니다.

보안 정책 프로젝트 삭제#

히스토리
  • 보안 정책 프로젝트의 삭제 보호가 reject_security_policy_project_deletion이라는 플래그와 함께 GitLab 17.8에서 도입되었습니다. 기본적으로 활성화됩니다.
  • 보안 정책 프로젝트를 포함하는 그룹에 대한 삭제 보호가 reject_security_policy_project_deletion_groups라는 플래그와 함께 GitLab 17.9에서 도입되었습니다. 기본적으로 활성화됩니다.
  • 보안 정책 프로젝트 및 보안 정책 프로젝트가 포함된 그룹에 대한 삭제 보호가 GitLab 17.10에서 일반적으로 사용 가능하게 되었습니다. 기능 플래그 reject_security_policy_project_deletionreject_security_policy_project_deletion_groups가 제거되었습니다.

보안 정책 프로젝트 또는 해당 상위 그룹 중 하나를 삭제하려면 다른 모든 프로젝트 또는 그룹에서 해당 링크를 제거해야 합니다. 그렇지 않으면 연결된 보안 정책 프로젝트 또는 상위 그룹을 삭제하려고 할 때 오류 메시지가 표시됩니다.