GitLab의 Compliance 관련 기능은 개발 및 배포 프로세스에서 규정 준수를 통합하도록 돕습니다. 이번에는 GitLab이 가지고 있는 Compliance 기능(이하 규정 준수)에 대해 설명합니다.
왜 GitLab 인스턴스의 보안과 규정 준수에 대해 알아야할까요?
리스크를 줄이고 비용을 절감하는 것 이외에도 고려해야 할 규정 및 준수 사항이 있습니다.
일반적으로 규제 및 감사는 기업이 규모화 됨에 따라 피할 수 없는 일이며, 관리되기까지 시간이 많이 걸리고 스트레스가 될 수 있습니다. GitLab은 조직의 규정 준수 사항을 만족하고, DevOps 툴의 운영 환경을 보다 안전하게 만들기 위한 몇가지 내장 기능을 가지고 있습니다. 우리가 매일 사용하는 기능들을 포함해서 대부분의 기능들이 무료인 프리티어로 사용할 수 있습니다.
참고: 프리 티어에서 사용할 수 없는 기능 옆에 별표(*)가 있습니다.
TL;DR 목록:
1. MFA 활성화
MFA를 활성화하는 것은 간단하며 계정에 액세스 하기가 더 어려워 공격의 위험을 줄입니다.
GitLab 인스턴스 admin 영역에서 모든 사용자에 대해 MFA를 시행할 수 있습니다. 또한 개별 계정에 대해 MFA를 구성할 수 있습니다.
GitLab Docs에서 MFA 활성화하는 방법을 알 수 있습니다.
MFA에 대한 규정 준수 표준 및 GitLab 제어
MFA는 다음 규정 준수 표준과 관련이 있습니다:
- AICPA TSC CC6.1
- ISO 27001 2013 A9.2.3, A9.2.4, A.9.3.1, A9.4.3
- NIST 800-53 IA-5, IA-5(1), IA-2(1), IA-2(2)
- IAC-02: GitLab은 조직 사용자를 대신하여 행동하는 조직 사용자 및 프로세스를 고유하게 식별하고 인증하는 메커니즘을 구현했습니다.
- IAC-06: GitLab은 중요한 데이터를 저장, 전송 및/또는 처리하는 중요한 시스템 또는 시스템에 대한 콘솔 이외의 액세스 및 원격 네트워크 액세스에 대해 MFA를 강제하기 위한 자동화된 메커니즘을 구현했습니다.
2. 중요한 프로젝트에 대한 액세스 권한 검토
의심할 여지없이 환경에 대한 가장 큰 위험 중 하나는 논리적 접근입니다. 위험을 줄이기 위해 최소 권한 원칙에 따라 액세스를 제한할 것을 권장합니다. 대부분의 조직에서 액세스 변경이 매일 여러 번 발생할 수 있으므로 액세스를 지속적으로 모니터링해야 합니다. GitLab 인스턴스에서 액세스를 적절하게 검토하려면 먼저 GitLab 내의 액세스 보안 구조를 이해하는 것이 중요합니다.
액세스 보안 구조 분석
GitLab에서는 “Guest”, “Reporter”, “Developer”, “Maintainer”, “Owner” and “Administrator” 6가지 역활을 사용자에게 할당할 수 있습니다. GitLab 내에서 권한 있는 액세스는 “Administrator”, “Owners”, “Maintainers” 입니다.
GitLab 관리자는 모든 권한을 받습니다
Owner 및 Maintainer는 이러한 역할에 다음을 포함하되 이에 국한되지 않는 매우 민감한 작업을 수행할 수 있는 권한이 있기 때문에 관리자로 간주됩니다. merge 설정 관리, branch 보호 설정, project 접근 관리, managing access tokens, project 내보내기, issues · merge requests · projects 삭제하기.
권한 있는 액세스는 환경에 대한 가장 높은 위험이므로 이러한 역할을 엄격하게 제어해야 합니다.
최소 권한 원칙에 따라 액세스를 제한하는 것과 관련된 몇 가지 모범 사례는 다음과 같습니다.:
- 권한 있는 액세스가 요청되면 액세스가 프로비저닝 되기 전에 적절한 승인을 받았는지 확인합니다. 가장 좋은 방법은 데이터 소유자와 액세스 권한을 받는 사용자의 관리자로부터 승인을 받는 것입니다.
- 사용자가 직무를 변경하거나 조직을 떠날 때 액세스가 적시에 프로비저닝 해제되고 공유 암호 또는 토큰을 확인하십시오 가장 좋은 방법은 72시간 이내에 이 작업을 수행하는 것입니다.
- 정기적으로 액세스를 검토하여 액세스가 사용자의 업무 책임에 적절하게 맞춰져 있는지 확인하십시오. 가장 좋은 방법은 분기별로 이 작업을 수행하고 데이터 소유자가 액세스 권한을 검토하도록 하는 것입니다.
부적절한 액세스를 식별한 경우 수행할 작업
부적절한 액세스가 확인되면 부적절한 트랜잭션이 수행되지 않았는지 확인하기 위해 사용자의 마지막 로그인 날짜를 확인하고 감사 로그를 확인하여 즉각적인 조치를 취하는 것이 중요합니다. 이러한 조치는 정보의 접근성을 보장하고 잠재적인 노출을 이해하기 위해 식별시 수행되어야 합니다
자세한 내용은 권한 및 역할에 대한 GitLab Docs을 참조하시기 바랍니다.
권한 있는 액세스를 위한 규정 준수 표준 및 GitLab 제어
접근 권한과 관련된 규정 준수 표준:
- AICPA TSC CC6.1, CC6.2, CC6.3
- ISO 27001 2013 A9.2.1, A9.2.2, A9.2.3, A9.4.4
- NIST 800-53 IA-12(4)
- IAC-07: GitLab은 액세스 권한 할당을 관리하는 공식 사용자 등록 및 등록 취소 프로세스를 활용하는 메커니즘을 구현했습니다.
- IAC-16: GitLab은 사용자 및 서비스에 대한 권한 있는 액세스 권한을 제한하고 제어하는 메커니즘을 구 현했습니다.
- IAC-17: GitLab은 사용자에게 할당된 권한을 주기적으로 검토하여 이러한 권한의 필요성을 검증하는 메커니즘을 구현했습니다. 필요한 경우 조직의 사명과 비즈니스 요구 사항을 올바르게 반영하기 위해 권한을 재할당하거나 제거합니다.
3. Protected branches 활성화
GitLab 내에서 역할 기반 액세스를 사용하여 프로젝트 수준에서 리포지토리 및 branch에 대한 액세스 권한을 부여할 수 있습니다. protected branches를 활용하여 특정 branch를 보호하기 위해 추가 제한을 구성할 수 있습니다. 기본 branch를 보호하는 것이 가장 중요합니다. 이 branch를 보통 "master" 또는 "main"이라고 합니다.
보호 규칙과 관련된 몇 가지 모범 사례는 다음과 같습니다.:
- 기본 branch로 직접 커밋 방지
- 커밋이 있을 때 merge request 필요
- 코드를 merge 하기 전에 코드 owner의 승인 필요
Protected branches는 조직의 관리 정책에 따라 구성되어야 합니다. 다음은 권장 사항에 따라 보호 규칙을 구성하는 예시입니다.:
branch 보호 규칙을 구성하는 방법의 예
이 예시는 “developer” and “maintainer” 역할을 가진 모든 사람은 기본 branch로 merge 할 수 있으며 “no one” merge request 없이 기본 branch에 직접 push 할 수 있음을 보여 줍니다. 또한 병합하기 전에 코드 소유자의 승인을 받아야 합니다.
Protected branches 최소한 “maintainer” 권한이 있는 사람이 수정할 수 있습니다. protected branch 설정이 부적절하게 수정되었는지 모니터링하기 위해 audit events를 활용하여 모니터링 제어를 구현하는 것을 고려해야 합니다.
자세한 내용은 protected branches에 대한 GitLab Docs를 참조하시기 바랍니다.
branch 보호를 위한 규정 준수 표준 및 GitLab 제어
Branch protection 설정은 다음 준수 표준과 관련이 있습니다:
- COSO Principle 9
- AICPA TSC CC3.4, CC8.1
- ISO 27001 2013 A12.1.2, A14.2.2, A.14.2.6, A.14.2.9
- NIST 800-53 CM-3, CM-3(2), SA-8(31), SI-6
branch 보호 설정에 관한 GitLab 제어 예시:
- CHG-04: GitLab은 사용자가 무단 변경을 수행할 수 있는 능력을 제한하기 위해 구성 제한을 적용하는 메커니즘을 구현했습니다.
4.Merge Request Approval 설정 *
프로젝트 리포지토리에 대한 변경은 일반적으로 merge request로 시작됩니다. 기본 branch가 보호되는 경우 merge request을 통해 커밋을 수행해야 합니다. 승인 규칙으로 merge request 설정을 구성하면 프로덕션에 배포하기 전에 변경 사항이 적절하게 승인됩니다. merge request 승인 설정 내에서 특정 merge request에 대해 필요한 승인 수와 허용된 승인자를 지정할 수 있습니다.
또한, 변경 관리 내에서 업무 분리를 추가로 시행하는 여러 승인 설정이 있습니다. :
- 작성자에 의한 승인 방지: 활성화된 경우 작성자는 필수 승인 중 하나를 제공할 수 없습니다.
- 커밋을 추가한 사용자의 승인 방지: 활성화되면 병합 요청을 커밋한 사용자도 승인할 수 없습니다.
- merge requests에서 승인 규칙 편집 장지: 활성화된 경우 사용자는 병합 요청에 대한 프로젝트의 승인 규칙을 재정의할 수 없습니다.
- 승인을 위해 사용자 암호 필요: 활성화된 경우 사용자는 승인을 제출하기 전에 먼저 암호로 인증해야 합니다.
- 커밋이 source branch에 추가될 때 모든 승인 제거: 활성화되면 더 많은 변경 사항이 추가될 때 병합 요청에 대한 모든 기존 승인이 제거됩니다.
merge request approval 설정은 조직의 변경 관리 정책에 따라 구성해야 합니다. 위에 요약된 모범 사례에 따라 merge request을 구성하는 방법의 예는 다음과 같습니다.:
merge request를 구성하는 방법의 예
위의 예제에서는 최소한 두 명의 승인자가 필요하다는 것을 알 수 있습니다. 직무 분리를 시행하고 승인 설정을 시행합니다.
변경 관리 정책에 다른 그룹이나 부서(예: 비즈니스 소유자 및 데이터 소유자)의 승인이 필요한 경우 이러한 승인 그룹을 추가 승인 규칙으로 추가할 수 있습니다. 이 설정을 사용하면 조직의 GitLab 인스턴스가 업무 분리를 시행하고 조직 변경 관리 정책을 체계적으로 시행하도록 보장할 수 있습니다.
특정 그룹의 모든 프로젝트가 동일한 병합 요청 승인 설정을 갖도록 하려면 최상위 그룹에서 그룹 승인 설정을 구성할 수 있습니다. 이러한 설정은 그룹에 속한 모든 프로젝트에 적용됩니다.
Merge request approval 설정은 최소한 “maintainer” 권한이 있는 모든 사용자가 수정할 수 있습니다. merge request approval 승인 설정이 부적절하게 수정되었는지 모니터링하려면 audit events를 활용하여 모니터링 제어를 구현하는 것이 좋습니다.
제세한 내용은 merge request 승인 및 설정에 대한 GitLab Docs를 참조하시기 바랍니다.
Merge approval에 대한 규정 준수 표준 및 GitLab 제어
Merge approval 설정은 다음 준수 표준과 관련됩니다:
- COSO Principle 9
- AICPA TSC CC3.4, CC8.1
- ISO 27001 2013 A12.1.2, A14.2.2, A.14.2.6, A.14.2.9,
- NIST 800-53 CM-3, CM-3(2), SA-8(31), SI-6
merge approval 설정에 대한 GitLab 제어 예시:
- CHG-04: GitLab은 사용자가 무단 변경을 수행할 수 있는 능력을 제한하기 위해 구성 제한을 적용하는 메커니즘을 구현했습니다.
5. Audit events 구성 *
audit events는 GitLab 내에서 변경된 사항을 확인하는 방법이며 구성된 설정을 지속적으로 모니터링하기 위한 감지 및 모니터링 제어로 활용할 수 있습니다. audit events에 대한 보고서를 생성한 다음 감사자에게 제공하여 특정 구성 설정에 대한 감사 기간 동안 회사의 규정 준수를 입증할 수 있습니다.
audit events는 그룹, 프로젝트 및 인스턴스 수준에서 구성할 수 있습니다.
GitLab 환경에서 다음 audit events를 모니터링하는 것이 좋습니다.:
- merge approval 설정
- protected branch 설정
앞서 언급했듯이 merge approval 설정과 protected branch 설정은 "maintainer" 권한을 가진 모든 사용자가 수정할 수 있습니다. audit events에 대한 이러한 중요 설정을 모니터링하면 potected branch 설정 또는 merge request 설정이 해당 기간 동안 수정되었는지 여부를 확인할 수 있습니다. 설정이 수정된 경우 잠재적인 영향을 이해하고 설정을 다시 켜는 조사가 발생할 수 있습니다.
다음은 이러한 audit events의 예시 입니다.:
audit events 예시
audit events 예에서는 다음을 볼 수 있습니다. :
- 프로젝트에서 "새 커밋이 MR에 추가될 때 새 승인 필요" merge approval 설정이 해제되었습니다.
- 필요한 승인의 수가 2에서 1로 감소했습니다.
- 기본 branch의 모든 사용자가 merge를 허용합니다. 이러한 변경은 protect branch 설정을 변경하고 이전에 구성된 승인 설정을 merge 합니다.
audit events는 다른 시스템에 전송 이것의 장점은 중앙 집중식 모니터링 및 경고를 위해 보안 정보 및 이벤트 관리(SIEM) 시스템에 통합할 수 있다는 것입니다.
자세한 내용은 audit events와 관련된 GitLab Docs를 참조하시기 바랍니다.
audit events에 대한 규정 준수 표준 및 GitLab 제어
audit events는 다음 규정 준수 표준과 관련됩니다:
- COSO Principle 13
- AICPA TSC CC4.1, CC7.2
- ISO 27001 2013 A12.4.1, A12.4.3
- NIST 800-53 AU-2
audit events에 대한 GitLab 제어 예시:
- CHG-07: audit events는 분기별로 검토되어 핵심 변경 관리 SOD(Segregation Of Duty) 설정에 대한 부적절한 변경이 없는지 확인합니다.
- MON-03: 최소한 다음을 수행할 수 있는 충분한 정보가 포함된 감사 기록을 생성하도록 시스템을 구성합니다. 발생한 이벤트 유형을 설정합니다. 이벤트가 발생한 시간(날짜 및 시간) 사건이 발생한 곳; 사건의 근원; 이벤트의 결과(성공 또는 실패); 및 이벤트와 관련된 모든 사용자/주체의 ID.
GitLab이 규정 주수를 유지하는데 도움이 되셨습니까? 조직에서 간과한 규정 준수 를 유지하는데 도움이 되는 즐겨 찾는 기능이 있으면 의견을 알려 주시기 바랍니다!
조직에서 GitLab에서 제공하는 규정 준수 기능을 활용하는 방법에 대해 자세히 알고 싶으십니까? 자세히 알아보시려면 전문가에게 문의 바랍니다.
참고: 별표는 (*) 프리 티어에서 사용할 수 없는 기능을 나타냅니다.
Cover image by Miguel Á. Padriñán on Pexels
원문: https://about.gitlab.com/blog/2022/07/13/top-5-compliance-features-to-leverage-in-gitlab
GitLab과 GitLab CI/CD 파이프라인 구성 관련하여 지원이 필요하시면 문의하기 로 연락 주십시오.