각 프로젝트나 그룹에 대해 새 보안 정책을 생성할 수 있지만, 여러 최상위 그룹에 걸쳐 동일한 정책 설정을 복제하는 것은 시간이 많이 걸리고 규정 준수 문제를 야기할 수 있습니다. 정책을 생성하기 전에 정책이 다음 중 어디에 해당하는지 알아야 합니다:

• 특정 프로젝트 또는 그룹에 적용되어야 하는지.
• 여러 프로젝트에 적용되어야 하는지.
• 전체 인스턴스 또는 최상위 그룹에 걸쳐 적용되어야 하는지.

여러 방법으로 정책을 적용할 수 있습니다:

• 단일 프로젝트 또는 그룹의 모든 프로젝트에 정책을 적용하려면 해당 프로젝트나 그룹에 정책을 생성합니다.
• 여러 프로젝트에 걸쳐 정책을 적용하려면 보안 정책 프로젝트를 사용합니다. 보안 정책 프로젝트는 정책만 추가하고 다른 것은 추가하지 않는 특수 유형의 프로젝트입니다. 보안 정책 프로젝트에서 다른 그룹과 프로젝트로 정책을 적용하려면 그룹이나 프로젝트에서 보안 정책 프로젝트로 연결합니다.
• GitLab Self-Managed 인스턴스 전체에 걸쳐 정책과 규정 준수 프레임워크를 함께 적용하려면 인스턴스 관리자가 규정 준수 및 보안 정책 관리 그룹을 사용할 수 있습니다.

정책 설계 지침#

정책을 설계할 때:

• 관리 오버헤드를 최소화하면서 적용 범위를 극대화합니다
• 직무 분리를 보장합니다

적용#

요구 사항을 충족하도록 정책을 적용하려면 다음 요소를 고려합니다:

• 상속: 기본적으로 정책은 연결된 조직 단위와 모든 하위 서브그룹 및 해당 프로젝트에 적용됩니다.
• 범위: 정책 적용을 사용자 정의하려면 요구 사항에 맞게 정책의 범위를 정의할 수 있습니다.

상속#

정책 적용 범위를 극대화하려면 목표를 달성하는 가장 높은 조직 단위(그룹, 서브그룹 또는 프로젝트)에 보안 정책 프로젝트를 연결합니다. 정책은 연결된 조직 단위와 모든 하위 서브그룹 및 해당 프로젝트에 적용됩니다. 가장 높은 지점에서 적용하면 필요한 보안 정책의 수를 최소화하여 관리 오버헤드를 줄입니다.

정책 상속을 사용하여 정책을 점진적으로 롤아웃할 수 있습니다. 예를 들어, 새 정책을 롤아웃할 때 단일 프로젝트에 적용하고 테스트를 수행할 수 있습니다. 테스트가 통과하면 프로젝트에서 제거하고 그룹에 적용하여 정책이 모든 해당 프로젝트에 적용될 때까지 계층 구조를 따라 올라갈 수 있습니다.

기존 그룹 또는 서브그룹에 적용된 정책은 다음 조건이 충족되는 경우 그 아래에 만들어진 새 서브그룹 및 프로젝트에 자동으로 적용됩니다:

• 새 서브그룹과 프로젝트가 정책의 범위 정의에 포함되어 있습니다 (예: 이 그룹의 모든 프로젝트를 포함하는 범위).
• 기존 그룹 또는 서브그룹이 이미 보안 정책 프로젝트에 연결되어 있습니다.

다음 예시는 두 그룹과 그 구조를 보여줍니다:

• Alpha 그룹은 두 개의 서브그룹을 포함하며, 각각 여러 프로젝트를 포함합니다.
• 보안 및 규정 준수 그룹은 두 개의 정책을 포함합니다.

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

• Finance (서브그룹)
  • Project A
  • Accounts receiving (서브그룹)
    • Project B
    • Project C
• Engineering (서브그룹)
  • Project K
  • Project L
  • Project M

보안 및 규정 준수 그룹 (보안 정책 프로젝트 포함)

• Security Policy Management
• Security Policy Management - 보안 정책 프로젝트
  • SAST 정책
  • 비밀 감지 정책

정책이 적용되지 않았다고 가정하면 다음 예시를 고려하세요:

• "SAST" 정책이 Alpha 그룹에 적용되면 정책은 Alpha의 두 서브그룹 Finance와 Engineering, 그리고 모든 프로젝트 및 서브그룹에 적용됩니다. 비밀 감지 정책도 "Accounts receiving" 서브그룹에 적용되면 두 정책 모두 프로젝트 B와 C에 적용됩니다. 그러나 "SAST" 정책만 프로젝트 A에 적용됩니다.
• "SAST" 정책이 "Accounts receiving" 서브그룹에만 적용되면 프로젝트 B와 C에만 적용됩니다. 어떤 정책도 프로젝트 A에 적용되지 않습니다.
• 비밀 감지 정책이 프로젝트 K에만 적용되면 프로젝트 K에만 적용됩니다. 다른 서브그룹이나 프로젝트에는 어떤 정책도 적용되지 않습니다.

범위#

히스토리

• GitLab 16.7에서 security_policies_policy_scope라는 플래그로 도입됨. 기본적으로 활성화됨.
• GitLab 16.11에서 일반적으로 사용 가능해짐. 기능 플래그 security_policies_policy_scope가 제거됨.
• GitLab 17.4에서 그룹별 범위 지정이 도입됨.

다음을 통해 정책의 범위를 세분화할 수 있습니다:

• 규정 준수 프레임워크: 선택된 규정 준수 프레임워크를 가진 프로젝트에 정책을 적용합니다.
• 그룹:
  • 그룹의 모든 하위 서브그룹 및 해당 프로젝트를 포함하여 그룹의 모든 프로젝트. 선택적으로 특정 프로젝트 제외.
  • 모든 그룹의 하위 서브그룹 및 해당 프로젝트를 포함하여 여러 그룹의 모든 프로젝트. 동일한 보안 정책 프로젝트에 연결된 모든 그룹이 정책에 나열될 수 있습니다. 선택적으로 특정 프로젝트 제외.
• 프로젝트: 특정 프로젝트를 포함하거나 제외합니다. 동일한 보안 정책 프로젝트에 연결된 프로젝트만 정책에 나열될 수 있습니다.

이러한 세분화를 동일한 정책에서 함께 적용할 수 있습니다. 그러나 제외가 포함보다 우선합니다.

직무 분리#

직무 분리는 정책을 성공적으로 구현하는 데 필수적입니다. 개발 워크플로우를 지원하면서 필요한 규정 준수 및 보안 요구 사항을 달성하는 정책을 설계합니다.

직무 분리를 구현할 때:

• 정책을 중앙에서 정의하고 개발 팀과 협력하여 정책이 워크플로우를 지원하는지 확인합니다.
• 정책 수정 권한을 권한 있는 역할로만 제한합니다.

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

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

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