InfoGrab DocsInfoGrab Docs

NIST 800-53 컴플라이언스

요약

이 페이지는 적용 가능한 NIST 800-53 컨트롤을 충족하도록 GitLab Self-Managed 인스턴스를 구성하려는 GitLab 관리자를 위한 참조 자료입니다. 이 페이지는 NIST 800-53 컨트롤 패밀리 구조를 따릅니다.

이 페이지는 적용 가능한 NIST 800-53 컨트롤을 충족하도록 GitLab Self-Managed 인스턴스를 구성하려는 GitLab 관리자를 위한 참조 자료입니다. 관리자가 가질 수 있는 요구 사항이 다양하기 때문에 GitLab은 특정 구성 지침을 제공하지 않습니다. NIST 800-53 보안 컨트롤을 충족하는 GitLab 인스턴스를 배포하기 전에 기술적인 세부 사항은 고객 솔루션 아키텍트와 협의해야 합니다.

범위#

이 페이지는 NIST 800-53 컨트롤 패밀리 구조를 따릅니다. 이 페이지의 범위는 주로 GitLab 자체에 대한 구성으로 제한되므로 모든 컨트롤 패밀리가 적용되지는 않습니다. 구성 세부 사항은 플랫폼에 독립적으로 작성되었습니다.

GitLab의 지침은 완전히 컴플라이언스를 충족하는 시스템을 구성하지 않습니다. 정부 데이터를 다루기 전에 다음을 수행해야 합니다.

  • 전체 기술 스택에 대한 추가 구성과 하드닝을 계획합니다.
  • 보안 구성에 대한 독립적인 평가를 고려합니다.
  • 지원되는 클라우드 제공업체 간 배포 차이를 이해하고 제공되는 경우 특정 지침을 따릅니다.

컴플라이언스 기능#

GitLab은 GitLab에서 중요한 컨트롤과 워크플로를 자동화하는 데 사용할 수 있는 여러 컴플라이언스 기능을 제공합니다. NIST 800-53에 맞춰 구성하기 전에 이러한 기본 기능을 먼저 활성화해야 합니다.

컨트롤 패밀리별 구성#

시스템 및 서비스 수급(SA)#

GitLab은 개발 수명 주기 전반에 걸쳐 보안을 통합하는 DevSecOps 플랫폼입니다. GitLab을 사용하면 핵심적으로 SA 컨트롤 패밀리의 다양한 컨트롤을 다룰 수 있습니다.

시스템 개발 수명 주기#

GitLab을 사용하면 이 요구 사항의 핵심을 충족할 수 있습니다. GitLab은 작업을 구성하고 계획·추적할 수 있는 플랫폼을 제공합니다. NIST 800-53은 애플리케이션 개발에 보안을 통합할 것을 요구합니다. CI/CD 파이프라인을 구성하면 코드를 배포하는 동안 지속적으로 테스트하는 동시에 보안 정책을 적용할 수 있습니다. GitLab에는 고객 애플리케이션 개발에 통합할 수 있는 다양한 보안 도구 모음이 포함되어 있으며, 다음을 포함하되 이에 국한되지 않습니다.

CI/CD 파이프라인 외에도 GitLab은 릴리스를 구성하는 방법에 대한 상세 지침을 제공합니다. 릴리스는 CI/CD 파이프라인으로 생성할 수 있으며 리포지터리의 소스 코드 브랜치 스냅샷을 담습니다. 릴리스 생성 방법은 릴리스 생성에서 확인할 수 있습니다. NIST 800-53 또는 FedRAMP 컴플라이언스에서 중요하게 고려할 사항은, 코드의 진위를 검증하고 System and Information Integrity(SI) 컨트롤 패밀리 요구 사항을 충족하기 위해 릴리스된 코드에 서명이 필요할 수 있다는 점입니다.

접근 제어(AC) 및 식별 및 인증(IA)#

GitLab 배포에서 접근 관리는 고객마다 고유합니다. GitLab은 ID 공급자를 사용한 배포와 GitLab 자체 인증 구성을 다루는 다양한 문서를 제공합니다. GitLab 인스턴스에 대한 인증 방식을 결정하기 전에 조직의 요구 사항을 고려하는 것이 중요합니다.

ID 공급자#

GitLab의 접근 권한은 UI로 관리하거나 기존 ID 공급자와 통합하여 관리할 수 있습니다. FedRAMP 요구 사항을 충족하려면 기존 ID 공급자가 FedRAMP Marketplace에서 FedRAMP 승인을 받았는지 확인해야 합니다. PIV와 같은 요구 사항을 충족하려면 GitLab Self-Managed의 자체 인증을 사용하기보다는 ID 공급자를 활용해야 합니다.

GitLab은 다음을 포함해 다양한 ID 공급자와 프로토콜을 구성하기 위한 자료를 제공합니다.

GitLab 자체 사용자 인증 구성#

계정 관리 및 분류 - GitLab은 관리자가 민감도와 접근 요구 사항이 서로 다른 사용자를 추적할 수 있도록 지원합니다. GitLab은 세분화된 접근 옵션을 제공하여 최소 권한 개념과 역할 기반 접근을 지원합니다. 프로젝트 수준에서는 다음 역할을 지원합니다.

  • Guest
  • Reporter
  • Developer
  • Maintainer
  • Owner

프로젝트 수준 권한에 대한 자세한 내용은 문서에서 확인할 수 있습니다. GitLab은 고유한 권한 요구 사항이 있는 고객을 위해 커스텀 역할도 지원합니다.

GitLab은 다음과 같은 고유한 사용 사례를 위한 사용자 유형도 지원합니다.

  • 감사자 사용자 - 감사자 역할은 Admin 영역과 프로젝트/그룹 설정을 제외한 모든 그룹, 프로젝트, 기타 리소스에 읽기 전용 접근 권한을 제공합니다. 프로세스 검증을 위해 특정 프로젝트에 접근해야 하는 외부 감사자와 협업할 때 감사자 역할을 사용할 수 있습니다.
  • 외부 사용자 - 외부 사용자는 조직에 속하지 않은 사용자에게 제한된 접근 권한을 부여하도록 설정할 수 있습니다. 일반적으로 계약직이나 기타 제3자의 접근을 관리하는 데 사용됩니다. IA-4(4)와 같은 컨트롤은 비조직 사용자를 회사 정책에 따라 식별하고 관리할 것을 요구합니다. 외부 사용자를 설정하면 기본적으로 프로젝트 접근을 제한하고 관리자가 조직에 소속되지 않은 사용자를 식별하는 데 도움이 되어 조직의 위험을 줄일 수 있습니다.
  • 서비스 계정 - 서비스 계정은 자동화된 작업을 수행하기 위해 추가할 수 있습니다. 서비스 계정은 라이선스의 시트를 사용하지 않습니다.

Admin 영역 - Admin 영역에서 관리자는 권한을 내보내고, 사용자 신원을 검토하고, 그룹을 관리하는 등 다양한 작업을 수행할 수 있습니다. FedRAMP / NIST 800-53 요구 사항을 충족하는 데 사용할 수 있는 기능은 다음과 같습니다.

  • 침해가 의심되는 경우 사용자 비밀번호를 재설정합니다.
  • 사용자 잠금을 해제합니다. GitLab은 기본적으로 로그인 시도가 10회 실패하면 사용자를 잠급니다. 사용자는 10분간 잠기거나 관리자가 잠금을 해제할 때까지 잠긴 상태로 유지됩니다. 관리자는 API를 사용하여 최대 로그인 시도 횟수와 잠금 유지 시간을 구성할 수 있습니다. AC-7 지침에 따라 FedRAMP는 계정 잠금 매개변수 정의를 NIST 800-63B에 위임하며, 기본 설정이 이를 충족합니다.
  • 남용 신고 또는 스팸 로그를 검토합니다. FedRAMP는 조직이 비정상적인 사용에 대해 계정을 모니터링할 것을 요구합니다(AC-2(12)). GitLab은 사용자가 남용 신고에서 남용 행위를 신고할 수 있도록 지원하며, 관리자는 조사가 진행되는 동안 접근 권한을 제거할 수 있습니다. 스팸 로그는 Admin 영역의 Spam logs 섹션에 통합되어 있습니다. 관리자는 해당 영역에서 신고된 사용자를 제거, 차단하거나 신뢰할 수 있습니다.
  • 비밀번호 저장 매개변수를 설정합니다. 저장된 시크릿은 SC-13에 명시된 대로 FIPS 140-2 또는 140-3을 충족해야 합니다. FIPS 모드가 활성화된 경우 FIPS를 준수하는 암호와 함께 PBKDF2+SHA512가 지원됩니다.
  • 자격 증명 인벤토리를 사용하면 관리자가 GitLab Self-Managed 인스턴스에서 사용되는 모든 시크릿을 한곳에서 검토할 수 있습니다. 자격 증명, 토큰, 키를 통합해서 보면 비밀번호 검토나 자격 증명 교체와 같은 요구 사항을 충족하는 데 도움이 됩니다.
  • 비밀번호 복잡도 요구 사항을 수정합니다. FedRAMP는 IA-5에서 비밀번호 길이 요구 사항 설정을 NIST 800-63B에 위임합니다. GitLab은 8~128자 비밀번호를 지원하며 기본값은 8자입니다.
  • 기본 세션 지속 시간 - FedRAMP는 일정 기간 비활성 상태인 사용자를 로그아웃해야 한다고 규정합니다. FedRAMP는 구체적인 기간을 명시하지는 않지만, 권한이 있는 사용자는 표준 근무 시간이 끝나면 로그아웃되어야 한다고 명확히 밝히고 있습니다. 관리자는 기본 세션 지속 시간을 설정할 수 있습니다.
  • 신규 사용자 프로비저닝 - 관리자는 Admin 영역 UI로 GitLab 계정에 신규 사용자를 생성할 수 있습니다. IA-5를 준수하기 위해 GitLab은 신규 사용자가 최초 로그인 시 비밀번호를 변경하도록 요구합니다.
  • 사용자 프로비저닝 해제 - 관리자는 Admin 영역 UI로 사용자를 제거할 수 있습니다. 사용자를 삭제하는 대신 사용자를 차단하여 모든 접근 권한을 제거할 수도 있습니다. 사용자를 차단하면 모든 접근 권한이 제거되지만 리포지터리의 데이터는 유지됩니다. 차단된 사용자는 시트 수에 영향을 주지 않습니다.
  • 사용자 비활성화 - 계정 검토 중 식별된 비활성 사용자는 일시적으로 비활성화할 수 있습니다. 비활성화는 차단과 비슷하지만 몇 가지 중요한 차이가 있습니다. 사용자를 비활성화해도 GitLab UI 로그인은 막히지 않습니다. 비활성화된 사용자는 로그인하면 다시 활성 상태가 될 수 있습니다. 비활성화된 사용자는 다음과 같습니다.
    • 리포지터리나 API에 접근할 수 없습니다.
    • 슬래시 명령을 사용할 수 없습니다. 자세한 내용은 슬래시 명령을 참고합니다.
    • 시트를 차지하지 않습니다.

추가 식별 방법#

2단계 인증 - GitLab은 다음 2차 인증 수단을 지원합니다.

  • 일회용 비밀번호(OTP) 인증기
  • WebAuthn 디바이스

2단계 인증 활성화 방법은 문서에서 확인할 수 있습니다. FedRAMP를 추진하는 고객은 FedRAMP 승인을 받고 FIPS 요구 사항을 지원하는 2단계 인증 공급자를 고려해야 합니다. FedRAMP 승인 공급자는 FedRAMP Marketplace에서 확인할 수 있습니다. 2차 인증 수단을 선택할 때 NIST와 FedRAMP는 이제 WebAuthn과 같은 피싱 저항 인증을 사용해야 한다고 명시하고 있습니다(IA-2).

SSH 키

  • GitLab은 Git 인증과 통신을 위한 SSH 키 구성 방법에 대해 지침을 제공합니다. 커밋에 서명할 수 있으며, 이를 통해 공개 키를 가진 사람에게 추가 검증을 제공할 수 있습니다.
  • 키는 FIPS 140-2 및 FIPS 140-3 검증 암호 사용과 같이 적용 가능한 강도와 복잡도 요구 사항을 충족하도록 구성해야 합니다. 관리자는 최소 키 기술과 키 길이를 제한할 수 있습니다. 또한 GitLab은 침해된 키를 차단합니다.

개인 액세스 토큰

GitLab은 개인 액세스 토큰을 구성하고 관리하는 방법에 대해 지침을 제공합니다. GitLab은 세분화된 권한을 지원하므로, 해당 사용 사례에 필요한 권한만으로 토큰 범위를 한정할 수 있습니다.

기타 접근 제어 패밀리 개념#

시스템 사용 알림

연방 요구 사항은 로그인 시 배너 표시가 필요하다고 규정하는 경우가 많습니다. 이는 ID 공급자를 통해 구성하거나 GitLab 배너 기능을 통해 구성할 수 있습니다.

외부 연결

모든 외부 연결을 문서화하고 컴플라이언스 요구 사항을 충족하는지 확인하는 것이 중요합니다. 예를 들어 제3자와 API 통합을 구성하면 그 제3자가 고객 데이터를 보호하는 방식에 따라 데이터 처리 요구 사항을 위반할 수 있습니다. 모든 외부 연결을 활성화하기 전에 검토하고 보안 영향을 이해하는 것이 중요합니다. FedRAMP 또는 유사한 인증을 추진하는 고객의 경우, FedRAMP 미승인 서비스나 데이터 영향 수준이 낮은 서비스에 연결하면 권한 부여 경계를 위반할 수 있습니다.

Personal Identity Verification(PIV)

연방 요구 사항을 충족하는 조직에는 PIV 카드가 필요할 수 있습니다. PIV 요구 사항을 충족하려면 GitLab은 고객이 PIV를 지원하는 ID 솔루션을 SAML과 연결하도록 요구합니다. SAML 문서 링크는 이 가이드 앞부분에 제공되어 있습니다.

감사 및 책임 추적성(AU)#

NIST 800-53은 조직이 보안 관련 이벤트를 모니터링하고, 해당 이벤트를 분석하고, 경보를 생성하고, 경보의 중요도에 따라 조사할 것을 요구합니다. GitLab은 Security Information and Event Management(SIEM) 솔루션으로 전달할 수 있는 다양한 보안 이벤트를 모니터링용으로 제공합니다.

이벤트 유형#

GitLab은 스트리밍하거나 데이터베이스에 저장할 수 있는 구성 가능한 감사 이벤트 로그 유형을 설명합니다. 관리자는 자신의 GitLab 인스턴스에서 캡처하고 싶은 이벤트를 구성할 수 있습니다.

로그 시스템

GitLab에는 모든 것을 기록할 수 있는 고급 로그 시스템이 포함되어 있습니다. GitLab은 다양한 출력을 포함하는 로그 시스템 로그 유형에 대한 지침을 제공합니다. 자세한 내용은 링크된 지침을 참고합니다.

이벤트 스트리밍

GitLab 관리자는 이벤트 스트리밍 기능을 사용하여 감사 이벤트를 SIEM 또는 다른 저장 위치로 스트리밍할 수 있습니다. 관리자는 여러 대상을 구성하고 이벤트 헤더를 설정할 수 있습니다. GitLab은 헤더, HTTP·HTTPS 이벤트 페이로드 등을 설명하는 이벤트 스트리밍 예시를 제공합니다.

관리자는 FedRAMP 또는 NIST 800-53 AU-2 요구 사항을 검토하고 필요한 감사 이벤트 유형에 매핑되는 감사 이벤트를 구현하는 것이 중요합니다. AU-2는 다음 이벤트 범주를 정의합니다.

  • 계정 로그온 성공/실패 이벤트
  • 계정 관리 이벤트
  • 객체 접근
  • 정책 변경
  • 권한 기능
  • 프로세스 추적
  • 시스템 이벤트
  • 웹 애플리케이션의 경우
    • 모든 관리자 활동
    • 인증 검사
    • 권한 부여 검사
    • 데이터 삭제
    • 데이터 접근
    • 데이터 변경
    • 권한 변경

관리자는 GitLab에서 이벤트를 활성화할 때 필수 이벤트 유형과 추가적인 조직 요구 사항을 모두 고려해야 합니다.

메트릭

보안 이벤트 외에도 관리자는 가동 시간을 지원하기 위해 애플리케이션 성능에 대한 가시성을 확보하고 싶을 수 있습니다. GitLab은 GitLab 인스턴스에서 지원되는 메트릭에 대한 상세 문서를 제공합니다.

저장소

고객은 컴플라이언스 요구 사항을 충족하는 장기 저장 솔루션에 로그를 저장할 책임이 있습니다. 예를 들어 FedRAMP는 로그를 1년간 저장할 것을 요구합니다. 고객 조직은 수집된 데이터의 영향도에 따라 National Archives and Records Administration 요구 사항도 충족해야 할 수 있습니다. 수집된 기록의 영향도를 검토하고 적용 가능한 컴플라이언스 요구 사항을 이해하는 것이 중요합니다.

인시던트 대응(IR)#

감사 이벤트를 구성한 후에는 해당 이벤트를 모니터링해야 합니다. GitLab은 SIEM 이나 다른 보안 도구에서 시스템 경보를 취합하고, 경보와 인시던트를 분류하고, 이해관계자에게 알리는 중앙 집중식 관리 인터페이스를 제공합니다. 인시던트 관리 문서는 보안 인시던트 대응 조직에서 앞서 언급한 활동을 수행하는 데 GitLab을 어떻게 사용할 수 있는지 설명합니다.

인시던트 대응 수명 주기

GitLab은 조직의 인시던트 대응 수명 주기 전체를 관리할 수 있습니다. 인시던트 대응 요구 사항을 충족하는 데 도움이 될 수 있는 다음 자료를 참고합니다.

구성 관리(CM)#

변경 통제

GitLab은 핵심적으로 변경 통제와 관련된 구성 관리 요구 사항을 충족할 수 있습니다. 이슈와 머지 리퀘스트가 변경을 지원하는 주요 방법입니다.

이슈는 변경을 구현하기 전에 메타데이터와 승인을 기록하는 유연한 플랫폼입니다. GitLab 기능을 사용하여 구성 관리 컨트롤을 충족하는 방법을 완전히 이해하려면 작업 계획 및 추적에 관한 GitLab 문서를 검토하는 것을 고려합니다.

머지 리퀘스트는 소스 브랜치에서 대상 브랜치로 변경 사항을 표준화하는 방법을 제공합니다. NIST 800-53 맥락에서는 코드를 병합하기 전에 승인을 어떻게 수집할지, 조직 내에서 누가 코드를 병합할 권한을 가질지 고려하는 것이 중요합니다. GitLab은 머지 리퀘스트 승인에 사용할 수 있는 다양한 설정에 대한 지침을 제공합니다. 필요한 검토가 완료된 후에만 적절한 역할에 승인 및 병합 권한을 부여하는 것을 고려합니다. 추가로 고려할 병합 설정은 다음과 같습니다.

변경 사항 테스트 및 검증

CI/CD 파이프라인은 변경 사항을 테스트하고 검증하는 데 핵심적인 요소입니다. 특정 사용 사례에 충분한 테스트와 검증 파이프라인을 구현하는 것은 고객의 책임입니다. 서비스를 선택할 때는 해당 파이프라인이 어디에서 실행되는지 고려해야 합니다. 외부 서비스에 연결하면 연방 데이터를 저장하고 처리하도록 허용된 권한 부여 경계를 위반할 수 있습니다. GitLab은 FIPS 활성화 시스템에서 실행되도록 구성된 러너 컨테이너 이미지를 제공합니다. GitLab은 보호된 브랜치를 구성하는 방법과 파이프라인 보안을 구현하는 방법을 포함한 파이프라인 하드닝 지침을 제공합니다. 또한 고객은 코드를 업데이트하기 전에 모든 검사가 통과했는지 확인하기 위해 병합 전에 필수 검사를 지정하는 것을 고려할 수 있습니다.

구성 요소 인벤토리

NIST 800-53은 클라우드 서비스 제공업체가 구성 요소 인벤토리를 유지 관리할 것을 요구합니다. GitLab은 기본 하드웨어를 직접 추적할 수는 없지만, 컨테이너 스캐닝과 의존성 스캐닝을 통해 소프트웨어 인벤토리를 생성할 수 있습니다. GitLab은 컨테이너 스캐닝과 의존성 스캐닝이 탐지할 수 있는 의존성을 설명합니다. GitLab은 소프트웨어 구성 요소 인벤토리에 사용할 수 있는 의존성 목록 생성에 관한 추가 문서도 제공합니다. Software Bill of Materials 지원은 이 문서 뒷부분의 Supply Chain Risk Management에서 다룹니다.

컨테이너 레지스트리

GitLab은 GitLab 프로젝트의 컨테이너 이미지를 저장하는 통합 컨테이너 레지스트리를 제공하며, 이는 고도로 가상화되고 확장 가능한 환경에서 컨테이너를 배포하기 위한 신뢰할 수 있는 리포지터리로 사용할 수 있습니다. 컨테이너 레지스트리 관리 지침을 검토할 수 있습니다.

컨틴전시 플래닝(CP)#

GitLab은 핵심 컨틴전시 플래닝 요구 사항을 충족하는 데 도움이 되는 지침과 서비스를 제공합니다. 포함된 문서를 검토하고 컨틴전시 플래닝 활동에 대한 조직 요구 사항을 충족하도록 그에 맞게 계획하는 것이 중요합니다. 컨틴전시 플래닝은 조직마다 고유하므로 컨틴전시 플랜을 수립하기 전에 조직의 요구 사항을 고려하는 것이 중요합니다.

GitLab 아키텍처 선택

GitLab은 GitLab Self-Managed 인스턴스에서 지원되는 아키텍처에 대한 방대한 문서를 제공합니다. GitLab은 다음 클라우드 서비스 제공업체를 지원합니다.

GitLab은 고객이 참조 아키텍처와 가용성 모델을 선택하도록 돕는 의사 결정 트리를 제공합니다. 대부분의 클라우드 서비스 제공업체는 관리형 서비스에 대해 리전 내 복원력을 제공합니다. 아키텍처를 선택할 때는 조직의 다운타임 허용 범위와 데이터의 중요도를 고려하는 것이 중요합니다. 추가적인 복제와 페일오버 기능이 필요하다면 GitLab Geo를 고려할 수 있습니다.

중요 자산 식별

NIST 800-53은 장애 발생 시 우선적으로 복구할 수 있도록 중요 자산을 식별할 것을 요구합니다. 고려해야 할 중요 자산에는 Gitaly 노드와 PostgreSQL 데이터베이스가 포함됩니다. 고객은 필요에 따라 백업이나 복제가 필요한 추가 자산을 식별해야 합니다.

백업

이 문서는 다음을 포함한 핵심 구성 요소의 백업 전략을 설명합니다.

GitLab Geo

GitLab Geo는 NIST 800-53 컴플라이언스를 추진하는 모든 구현에서 핵심 구성 요소가 될 가능성이 높습니다. 각 사용 사례에 맞게 Geo가 적절히 구성되었는지 확인하려면 제공된 문서를 검토하는 것이 중요합니다.

Geo를 구현하면 다음과 같은 이점이 있습니다.

  • 분산된 개발자가 대규모 리포지터리와 프로젝트를 클론·페치하는 데 걸리는 시간을 분 단위에서 초 단위로 단축합니다.
  • 개발자가 리전 간에 아이디어를 제시하고 병렬로 작업할 수 있도록 지원합니다.
  • 기본 사이트와 보조 사이트 간에 읽기 전용 부하를 분산합니다.
  • GitLab 웹 인터페이스에서 제공되는 데이터를 읽는 것 외에도 프로젝트를 클론하고 페치하는 데 사용할 수 있습니다(제한 사항 참고).
  • 원거리 사무실 간의 느린 연결을 극복하여 분산된 팀의 속도를 높이고 시간을 절약합니다.
  • 자동화된 작업, 커스텀 통합, 내부 워크플로의 로딩 시간을 단축하는 데 도움이 됩니다.
  • 재해 복구 시나리오에서 보조 사이트로 빠르게 페일오버할 수 있습니다.
  • 보조 사이트로의 계획된 페일오버를 지원합니다.

Geo는 다음과 같은 핵심 기능을 제공합니다.

  • 읽기 전용 보조 사이트: 하나의 프라이머리 GitLab 사이트를 유지하면서 분산된 팀을 위한 읽기 전용 보조 사이트도 활성화할 수 있습니다.
  • 인증 시스템 훅: 보조 사이트는 프라이머리 인스턴스로부터 사용자 계정, 로그인과 같은 모든 인증 데이터를 수신합니다.
  • 직관적인 UI: 보조 사이트는 기본 사이트와 동일한 웹 인터페이스를 사용합니다. 또한 쓰기 작업을 차단하고 사용자가 보조 사이트에 있음을 명확히 알리는 시각적 알림이 제공됩니다.

추가 Geo 자료:

PostgreSQL

GitLab은 복제와 페일오버를 사용하는 PostgreSQL 클러스터 구성 방법에 대한 지침을 제공합니다. 데이터의 중요도와 GitLab 인스턴스의 최대 허용 다운타임에 따라 복제와 페일오버를 활성화한 PostgreSQL 구성을 고려합니다.

Gitaly

Gitaly를 구성할 때는 가용성, 복구 가능성, 복원력 사이의 트레이드오프를 고려합니다. GitLab은 NIST 800-53 요구 사항을 충족하는 올바른 구성을 결정하는 데 도움이 되는 Gitaly 기능에 대한 방대한 문서를 제공합니다.

계획(PL)#

Planning 컨트롤 패밀리는 정책, 절차, 기타 통제 문서의 유지 관리를 포함합니다. GitLab을 활용하여 통제 문서의 수명 주기를 관리하는 것을 고려합니다. 예를 들어 통제 문서는 버전 관리 상태로 Markdown에 저장할 수 있습니다. 문서에 대한 모든 변경은 조직의 승인 규칙을 적용하는 머지 리퀘스트를 통해 이루어져야 합니다. 머지 리퀘스트는 통제 문서에 가해진 변경 사항의 명확한 이력을 제공하므로, 감사 시 문서 소유자와 같은 적절한 담당자에 의한 연례 검토와 승인을 입증하는 데 사용할 수 있습니다.

위험 평가 및 시스템·정보 무결성(RA)#

스캐닝#

NIST 800-53은 취약점과 결함 해결에 대한 지속적인 모니터링을 요구합니다. 인프라 스캐닝 외에도 FedRAMP와 같은 컴플라이언스 프레임워크는 컨테이너와 DAST 스캔을 월간 보고 요구 사항에 포함시켰습니다. GitLab은 Trivy와 Grype 스캐너를 포함해 컨테이너 스캐닝을 지원하는 도구를 제공합니다. 또한 GitLab은 의존성 스캐닝 기능도 제공합니다. GitLab의 DAST는 웹 애플리케이션 스캐닝 요구 사항을 충족하는 데 사용할 수 있습니다. GitLab DAST는 파이프라인에서 실행되어 운영 중인 웹 애플리케이션의 취약점 보고서를 생성하도록 구성할 수 있습니다.

애플리케이션 코드를 보호하고 관리하는 데 사용할 수 있는 추가 보안 기능은 다음과 같습니다.

패치 관리#

GitLab은 문서에서 릴리스 및 유지 관리 정책을 설명합니다. GitLab 인스턴스를 업그레이드하기 전에 업그레이드 계획, 다운타임 없는 업그레이드, 기타 업그레이드 경로에 도움이 되는 제공된 지침을 검토합니다.

보안 대시보드는 시간에 따른 취약점 데이터를 추적하도록 구성할 수 있으며, 이를 통해 취약점 관리 프로그램의 추세를 파악할 수 있습니다.

공급망 위험 관리(SR)#

Software Bill of Materials#

GitLab의 의존성 스캐너와 컨테이너 스캐너는 SBOM 생성을 지원합니다. 컨테이너 스캐닝과 의존성 스캐닝에서 SBOM 보고서를 활성화하면 고객 조직이 소프트웨어 공급망과 소프트웨어 구성 요소에 내재된 위험을 이해하는 데 도움이 됩니다. GitLab 스캐너는 CycloneDX 형식 보고서를 지원합니다.

시스템 및 통신 보호(SC)#

FIPS 컴플라이언스#

FedRAMP와 같이 NIST 800-53을 기반으로 하는 컴플라이언스 프로그램은 적용 가능한 모든 암호화 모듈에 대해 FIPS 컴플라이언스를 요구합니다. GitLab은 컨테이너 이미지의 FIPS 버전을 출시했으며 FIPS 컴플라이언스 표준을 충족하도록 GitLab을 구성하는 방법에 대한 지침을 제공합니다. 일부 기능은 FIPS 모드에서 사용할 수 없거나 지원되지 않습니다.

GitLab은 FIPS를 준수하는 이미지를 제공하지만, 기본 인프라를 구성하고 FIPS 검증 암호가 적용되는지 환경을 평가하는 것은 고객의 책임입니다.

시스템 및 정보 무결성(SI)#

보안 경보, 권고, 지시#

GitLab은 소프트웨어와 의존성 관련 보안 취약점을 추적하기 위한 권고 데이터베이스를 유지 관리합니다. GitLab은 CVE Numbering Authority(CNA) 입니다. CVE ID 요청 생성 방법은 이 페이지를 참고합니다.

이메일#

GitLab은 GitLab 애플리케이션 인스턴스에서 사용자에게 이메일 알림을 보내는 기능을 지원합니다. DHS BOD 18-01 지침은 스팸 방지를 위해 발신 메시지에 Domain-based Message Authentication, Reporting & Conformance(DMARC)를 구성해야 한다고 명시합니다. GitLab은 이 요구 사항을 충족하는 데 도움이 될 수 있도록 다양한 이메일 제공업체에 대해 SMTP 구성 지침을 제공합니다.

기타 서비스 및 개념#

러너#

러너는 모든 GitLab 배포에서 다양한 작업과 도구에 필요합니다. 데이터 경계 요구 사항을 유지하기 위해 고객은 권한 부여 경계 내에 셀프 매니지드 러너를 배포해야 할 수 있습니다. GitLab은 러너 구성에 대한 상세 정보를 제공하며, 여기에는 다음과 같은 개념이 포함됩니다.

  • 최대 job 타임아웃
  • 민감 정보 보호
  • 롱 폴링 구성
  • 인증 토큰 보안 및 토큰 교체
  • 민감 정보 노출 방지
  • 러너 변수

API 활용#

GitLab은 애플리케이션을 지원하는 강력한 API 세트를 제공하며, REST와 GraphQL API를 포함합니다. API를 보호하려면 먼저 API 엔드포인트를 호출하는 사용자와 job에 대한 인증을 올바르게 구성해야 합니다. GitLab은 접근을 제어하기 위해 액세스 토큰(FIPS에서는 개인 액세스 토큰 미지원)과 OAuth 2.0 토큰을 구성할 것을 권장합니다.

확장#

확장은 어떤 통합이 구성되어 있는지에 따라 NIST 800-53 요구 사항을 충족할 수 있습니다. 예를 들어 편집기와 IDE 확장은 허용될 수 있지만, 제3자와의 통합은 권한 부여 경계 요구 사항을 위반할 수 있습니다. 데이터가 고객의 권한 부여 경계 밖으로 전송되는 위치를 파악하기 위해 모든 확장을 검증하는 것은 고객의 책임입니다.

추가 자료#

GitLab은 다음과 같은 주제를 다루는 GitLab Self-Managed 고객용 하드닝 가이드를 제공합니다.

GitLab CIS Benchmark 가이드 - GitLab은 애플리케이션의 하드닝 결정을 안내하는 CIS Benchmark를 발행했습니다. 이 가이드와 함께 사용하여 NIST 800-53 컨트롤에 따라 환경을 하드닝할 수 있습니다. CIS Benchmark의 모든 제안이 NIST 800-53 컨트롤과 직접 일치하지는 않지만, GitLab 인스턴스를 유지 관리하기 위한 모범 사례로 활용할 수 있습니다.

NIST 800-53 컴플라이언스

GitLab v19.5
Tier: Ultimate
Offering: GitLab Self-Managed, GitLab Dedicated
원문 보기

요약

이 페이지는 적용 가능한 NIST 800-53 컨트롤을 충족하도록 GitLab Self-Managed 인스턴스를 구성하려는 GitLab 관리자를 위한 참조 자료입니다. 이 페이지는 NIST 800-53 컨트롤 패밀리 구조를 따릅니다.

이 페이지는 적용 가능한 NIST 800-53 컨트롤을 충족하도록 GitLab Self-Managed 인스턴스를 구성하려는 GitLab 관리자를 위한 참조 자료입니다. 관리자가 가질 수 있는 요구 사항이 다양하기 때문에 GitLab은 특정 구성 지침을 제공하지 않습니다. NIST 800-53 보안 컨트롤을 충족하는 GitLab 인스턴스를 배포하기 전에 기술적인 세부 사항은 고객 솔루션 아키텍트와 협의해야 합니다.

범위#

이 페이지는 NIST 800-53 컨트롤 패밀리 구조를 따릅니다. 이 페이지의 범위는 주로 GitLab 자체에 대한 구성으로 제한되므로 모든 컨트롤 패밀리가 적용되지는 않습니다. 구성 세부 사항은 플랫폼에 독립적으로 작성되었습니다.

GitLab의 지침은 완전히 컴플라이언스를 충족하는 시스템을 구성하지 않습니다. 정부 데이터를 다루기 전에 다음을 수행해야 합니다.

  • 전체 기술 스택에 대한 추가 구성과 하드닝을 계획합니다.
  • 보안 구성에 대한 독립적인 평가를 고려합니다.
  • 지원되는 클라우드 제공업체 간 배포 차이를 이해하고 제공되는 경우 특정 지침을 따릅니다.

컴플라이언스 기능#

GitLab은 GitLab에서 중요한 컨트롤과 워크플로를 자동화하는 데 사용할 수 있는 여러 컴플라이언스 기능을 제공합니다. NIST 800-53에 맞춰 구성하기 전에 이러한 기본 기능을 먼저 활성화해야 합니다.

컨트롤 패밀리별 구성#

시스템 및 서비스 수급(SA)#

GitLab은 개발 수명 주기 전반에 걸쳐 보안을 통합하는 DevSecOps 플랫폼입니다. GitLab을 사용하면 핵심적으로 SA 컨트롤 패밀리의 다양한 컨트롤을 다룰 수 있습니다.

시스템 개발 수명 주기#

GitLab을 사용하면 이 요구 사항의 핵심을 충족할 수 있습니다. GitLab은 작업을 구성하고 계획·추적할 수 있는 플랫폼을 제공합니다. NIST 800-53은 애플리케이션 개발에 보안을 통합할 것을 요구합니다. CI/CD 파이프라인을 구성하면 코드를 배포하는 동안 지속적으로 테스트하는 동시에 보안 정책을 적용할 수 있습니다. GitLab에는 고객 애플리케이션 개발에 통합할 수 있는 다양한 보안 도구 모음이 포함되어 있으며, 다음을 포함하되 이에 국한되지 않습니다.

CI/CD 파이프라인 외에도 GitLab은 릴리스를 구성하는 방법에 대한 상세 지침을 제공합니다. 릴리스는 CI/CD 파이프라인으로 생성할 수 있으며 리포지터리의 소스 코드 브랜치 스냅샷을 담습니다. 릴리스 생성 방법은 릴리스 생성에서 확인할 수 있습니다. NIST 800-53 또는 FedRAMP 컴플라이언스에서 중요하게 고려할 사항은, 코드의 진위를 검증하고 System and Information Integrity(SI) 컨트롤 패밀리 요구 사항을 충족하기 위해 릴리스된 코드에 서명이 필요할 수 있다는 점입니다.

접근 제어(AC) 및 식별 및 인증(IA)#

GitLab 배포에서 접근 관리는 고객마다 고유합니다. GitLab은 ID 공급자를 사용한 배포와 GitLab 자체 인증 구성을 다루는 다양한 문서를 제공합니다. GitLab 인스턴스에 대한 인증 방식을 결정하기 전에 조직의 요구 사항을 고려하는 것이 중요합니다.

ID 공급자#

GitLab의 접근 권한은 UI로 관리하거나 기존 ID 공급자와 통합하여 관리할 수 있습니다. FedRAMP 요구 사항을 충족하려면 기존 ID 공급자가 FedRAMP Marketplace에서 FedRAMP 승인을 받았는지 확인해야 합니다. PIV와 같은 요구 사항을 충족하려면 GitLab Self-Managed의 자체 인증을 사용하기보다는 ID 공급자를 활용해야 합니다.

GitLab은 다음을 포함해 다양한 ID 공급자와 프로토콜을 구성하기 위한 자료를 제공합니다.

GitLab 자체 사용자 인증 구성#

계정 관리 및 분류 - GitLab은 관리자가 민감도와 접근 요구 사항이 서로 다른 사용자를 추적할 수 있도록 지원합니다. GitLab은 세분화된 접근 옵션을 제공하여 최소 권한 개념과 역할 기반 접근을 지원합니다. 프로젝트 수준에서는 다음 역할을 지원합니다.

  • Guest
  • Reporter
  • Developer
  • Maintainer
  • Owner

프로젝트 수준 권한에 대한 자세한 내용은 문서에서 확인할 수 있습니다. GitLab은 고유한 권한 요구 사항이 있는 고객을 위해 커스텀 역할도 지원합니다.

GitLab은 다음과 같은 고유한 사용 사례를 위한 사용자 유형도 지원합니다.

  • 감사자 사용자 - 감사자 역할은 Admin 영역과 프로젝트/그룹 설정을 제외한 모든 그룹, 프로젝트, 기타 리소스에 읽기 전용 접근 권한을 제공합니다. 프로세스 검증을 위해 특정 프로젝트에 접근해야 하는 외부 감사자와 협업할 때 감사자 역할을 사용할 수 있습니다.
  • 외부 사용자 - 외부 사용자는 조직에 속하지 않은 사용자에게 제한된 접근 권한을 부여하도록 설정할 수 있습니다. 일반적으로 계약직이나 기타 제3자의 접근을 관리하는 데 사용됩니다. IA-4(4)와 같은 컨트롤은 비조직 사용자를 회사 정책에 따라 식별하고 관리할 것을 요구합니다. 외부 사용자를 설정하면 기본적으로 프로젝트 접근을 제한하고 관리자가 조직에 소속되지 않은 사용자를 식별하는 데 도움이 되어 조직의 위험을 줄일 수 있습니다.
  • 서비스 계정 - 서비스 계정은 자동화된 작업을 수행하기 위해 추가할 수 있습니다. 서비스 계정은 라이선스의 시트를 사용하지 않습니다.

Admin 영역 - Admin 영역에서 관리자는 권한을 내보내고, 사용자 신원을 검토하고, 그룹을 관리하는 등 다양한 작업을 수행할 수 있습니다. FedRAMP / NIST 800-53 요구 사항을 충족하는 데 사용할 수 있는 기능은 다음과 같습니다.

  • 침해가 의심되는 경우 사용자 비밀번호를 재설정합니다.
  • 사용자 잠금을 해제합니다. GitLab은 기본적으로 로그인 시도가 10회 실패하면 사용자를 잠급니다. 사용자는 10분간 잠기거나 관리자가 잠금을 해제할 때까지 잠긴 상태로 유지됩니다. 관리자는 API를 사용하여 최대 로그인 시도 횟수와 잠금 유지 시간을 구성할 수 있습니다. AC-7 지침에 따라 FedRAMP는 계정 잠금 매개변수 정의를 NIST 800-63B에 위임하며, 기본 설정이 이를 충족합니다.
  • 남용 신고 또는 스팸 로그를 검토합니다. FedRAMP는 조직이 비정상적인 사용에 대해 계정을 모니터링할 것을 요구합니다(AC-2(12)). GitLab은 사용자가 남용 신고에서 남용 행위를 신고할 수 있도록 지원하며, 관리자는 조사가 진행되는 동안 접근 권한을 제거할 수 있습니다. 스팸 로그는 Admin 영역의 Spam logs 섹션에 통합되어 있습니다. 관리자는 해당 영역에서 신고된 사용자를 제거, 차단하거나 신뢰할 수 있습니다.
  • 비밀번호 저장 매개변수를 설정합니다. 저장된 시크릿은 SC-13에 명시된 대로 FIPS 140-2 또는 140-3을 충족해야 합니다. FIPS 모드가 활성화된 경우 FIPS를 준수하는 암호와 함께 PBKDF2+SHA512가 지원됩니다.
  • 자격 증명 인벤토리를 사용하면 관리자가 GitLab Self-Managed 인스턴스에서 사용되는 모든 시크릿을 한곳에서 검토할 수 있습니다. 자격 증명, 토큰, 키를 통합해서 보면 비밀번호 검토나 자격 증명 교체와 같은 요구 사항을 충족하는 데 도움이 됩니다.
  • 비밀번호 복잡도 요구 사항을 수정합니다. FedRAMP는 IA-5에서 비밀번호 길이 요구 사항 설정을 NIST 800-63B에 위임합니다. GitLab은 8~128자 비밀번호를 지원하며 기본값은 8자입니다.
  • 기본 세션 지속 시간 - FedRAMP는 일정 기간 비활성 상태인 사용자를 로그아웃해야 한다고 규정합니다. FedRAMP는 구체적인 기간을 명시하지는 않지만, 권한이 있는 사용자는 표준 근무 시간이 끝나면 로그아웃되어야 한다고 명확히 밝히고 있습니다. 관리자는 기본 세션 지속 시간을 설정할 수 있습니다.
  • 신규 사용자 프로비저닝 - 관리자는 Admin 영역 UI로 GitLab 계정에 신규 사용자를 생성할 수 있습니다. IA-5를 준수하기 위해 GitLab은 신규 사용자가 최초 로그인 시 비밀번호를 변경하도록 요구합니다.
  • 사용자 프로비저닝 해제 - 관리자는 Admin 영역 UI로 사용자를 제거할 수 있습니다. 사용자를 삭제하는 대신 사용자를 차단하여 모든 접근 권한을 제거할 수도 있습니다. 사용자를 차단하면 모든 접근 권한이 제거되지만 리포지터리의 데이터는 유지됩니다. 차단된 사용자는 시트 수에 영향을 주지 않습니다.
  • 사용자 비활성화 - 계정 검토 중 식별된 비활성 사용자는 일시적으로 비활성화할 수 있습니다. 비활성화는 차단과 비슷하지만 몇 가지 중요한 차이가 있습니다. 사용자를 비활성화해도 GitLab UI 로그인은 막히지 않습니다. 비활성화된 사용자는 로그인하면 다시 활성 상태가 될 수 있습니다. 비활성화된 사용자는 다음과 같습니다.
    • 리포지터리나 API에 접근할 수 없습니다.
    • 슬래시 명령을 사용할 수 없습니다. 자세한 내용은 슬래시 명령을 참고합니다.
    • 시트를 차지하지 않습니다.

추가 식별 방법#

2단계 인증 - GitLab은 다음 2차 인증 수단을 지원합니다.

  • 일회용 비밀번호(OTP) 인증기
  • WebAuthn 디바이스

2단계 인증 활성화 방법은 문서에서 확인할 수 있습니다. FedRAMP를 추진하는 고객은 FedRAMP 승인을 받고 FIPS 요구 사항을 지원하는 2단계 인증 공급자를 고려해야 합니다. FedRAMP 승인 공급자는 FedRAMP Marketplace에서 확인할 수 있습니다. 2차 인증 수단을 선택할 때 NIST와 FedRAMP는 이제 WebAuthn과 같은 피싱 저항 인증을 사용해야 한다고 명시하고 있습니다(IA-2).

SSH 키

  • GitLab은 Git 인증과 통신을 위한 SSH 키 구성 방법에 대해 지침을 제공합니다. 커밋에 서명할 수 있으며, 이를 통해 공개 키를 가진 사람에게 추가 검증을 제공할 수 있습니다.
  • 키는 FIPS 140-2 및 FIPS 140-3 검증 암호 사용과 같이 적용 가능한 강도와 복잡도 요구 사항을 충족하도록 구성해야 합니다. 관리자는 최소 키 기술과 키 길이를 제한할 수 있습니다. 또한 GitLab은 침해된 키를 차단합니다.

개인 액세스 토큰

GitLab은 개인 액세스 토큰을 구성하고 관리하는 방법에 대해 지침을 제공합니다. GitLab은 세분화된 권한을 지원하므로, 해당 사용 사례에 필요한 권한만으로 토큰 범위를 한정할 수 있습니다.

기타 접근 제어 패밀리 개념#

시스템 사용 알림

연방 요구 사항은 로그인 시 배너 표시가 필요하다고 규정하는 경우가 많습니다. 이는 ID 공급자를 통해 구성하거나 GitLab 배너 기능을 통해 구성할 수 있습니다.

외부 연결

모든 외부 연결을 문서화하고 컴플라이언스 요구 사항을 충족하는지 확인하는 것이 중요합니다. 예를 들어 제3자와 API 통합을 구성하면 그 제3자가 고객 데이터를 보호하는 방식에 따라 데이터 처리 요구 사항을 위반할 수 있습니다. 모든 외부 연결을 활성화하기 전에 검토하고 보안 영향을 이해하는 것이 중요합니다. FedRAMP 또는 유사한 인증을 추진하는 고객의 경우, FedRAMP 미승인 서비스나 데이터 영향 수준이 낮은 서비스에 연결하면 권한 부여 경계를 위반할 수 있습니다.

Personal Identity Verification(PIV)

연방 요구 사항을 충족하는 조직에는 PIV 카드가 필요할 수 있습니다. PIV 요구 사항을 충족하려면 GitLab은 고객이 PIV를 지원하는 ID 솔루션을 SAML과 연결하도록 요구합니다. SAML 문서 링크는 이 가이드 앞부분에 제공되어 있습니다.

감사 및 책임 추적성(AU)#

NIST 800-53은 조직이 보안 관련 이벤트를 모니터링하고, 해당 이벤트를 분석하고, 경보를 생성하고, 경보의 중요도에 따라 조사할 것을 요구합니다. GitLab은 Security Information and Event Management(SIEM) 솔루션으로 전달할 수 있는 다양한 보안 이벤트를 모니터링용으로 제공합니다.

이벤트 유형#

GitLab은 스트리밍하거나 데이터베이스에 저장할 수 있는 구성 가능한 감사 이벤트 로그 유형을 설명합니다. 관리자는 자신의 GitLab 인스턴스에서 캡처하고 싶은 이벤트를 구성할 수 있습니다.

로그 시스템

GitLab에는 모든 것을 기록할 수 있는 고급 로그 시스템이 포함되어 있습니다. GitLab은 다양한 출력을 포함하는 로그 시스템 로그 유형에 대한 지침을 제공합니다. 자세한 내용은 링크된 지침을 참고합니다.

이벤트 스트리밍

GitLab 관리자는 이벤트 스트리밍 기능을 사용하여 감사 이벤트를 SIEM 또는 다른 저장 위치로 스트리밍할 수 있습니다. 관리자는 여러 대상을 구성하고 이벤트 헤더를 설정할 수 있습니다. GitLab은 헤더, HTTP·HTTPS 이벤트 페이로드 등을 설명하는 이벤트 스트리밍 예시를 제공합니다.

관리자는 FedRAMP 또는 NIST 800-53 AU-2 요구 사항을 검토하고 필요한 감사 이벤트 유형에 매핑되는 감사 이벤트를 구현하는 것이 중요합니다. AU-2는 다음 이벤트 범주를 정의합니다.

  • 계정 로그온 성공/실패 이벤트
  • 계정 관리 이벤트
  • 객체 접근
  • 정책 변경
  • 권한 기능
  • 프로세스 추적
  • 시스템 이벤트
  • 웹 애플리케이션의 경우
    • 모든 관리자 활동
    • 인증 검사
    • 권한 부여 검사
    • 데이터 삭제
    • 데이터 접근
    • 데이터 변경
    • 권한 변경

관리자는 GitLab에서 이벤트를 활성화할 때 필수 이벤트 유형과 추가적인 조직 요구 사항을 모두 고려해야 합니다.

메트릭

보안 이벤트 외에도 관리자는 가동 시간을 지원하기 위해 애플리케이션 성능에 대한 가시성을 확보하고 싶을 수 있습니다. GitLab은 GitLab 인스턴스에서 지원되는 메트릭에 대한 상세 문서를 제공합니다.

저장소

고객은 컴플라이언스 요구 사항을 충족하는 장기 저장 솔루션에 로그를 저장할 책임이 있습니다. 예를 들어 FedRAMP는 로그를 1년간 저장할 것을 요구합니다. 고객 조직은 수집된 데이터의 영향도에 따라 National Archives and Records Administration 요구 사항도 충족해야 할 수 있습니다. 수집된 기록의 영향도를 검토하고 적용 가능한 컴플라이언스 요구 사항을 이해하는 것이 중요합니다.

인시던트 대응(IR)#

감사 이벤트를 구성한 후에는 해당 이벤트를 모니터링해야 합니다. GitLab은 SIEM 이나 다른 보안 도구에서 시스템 경보를 취합하고, 경보와 인시던트를 분류하고, 이해관계자에게 알리는 중앙 집중식 관리 인터페이스를 제공합니다. 인시던트 관리 문서는 보안 인시던트 대응 조직에서 앞서 언급한 활동을 수행하는 데 GitLab을 어떻게 사용할 수 있는지 설명합니다.

인시던트 대응 수명 주기

GitLab은 조직의 인시던트 대응 수명 주기 전체를 관리할 수 있습니다. 인시던트 대응 요구 사항을 충족하는 데 도움이 될 수 있는 다음 자료를 참고합니다.

구성 관리(CM)#

변경 통제

GitLab은 핵심적으로 변경 통제와 관련된 구성 관리 요구 사항을 충족할 수 있습니다. 이슈와 머지 리퀘스트가 변경을 지원하는 주요 방법입니다.

이슈는 변경을 구현하기 전에 메타데이터와 승인을 기록하는 유연한 플랫폼입니다. GitLab 기능을 사용하여 구성 관리 컨트롤을 충족하는 방법을 완전히 이해하려면 작업 계획 및 추적에 관한 GitLab 문서를 검토하는 것을 고려합니다.

머지 리퀘스트는 소스 브랜치에서 대상 브랜치로 변경 사항을 표준화하는 방법을 제공합니다. NIST 800-53 맥락에서는 코드를 병합하기 전에 승인을 어떻게 수집할지, 조직 내에서 누가 코드를 병합할 권한을 가질지 고려하는 것이 중요합니다. GitLab은 머지 리퀘스트 승인에 사용할 수 있는 다양한 설정에 대한 지침을 제공합니다. 필요한 검토가 완료된 후에만 적절한 역할에 승인 및 병합 권한을 부여하는 것을 고려합니다. 추가로 고려할 병합 설정은 다음과 같습니다.

변경 사항 테스트 및 검증

CI/CD 파이프라인은 변경 사항을 테스트하고 검증하는 데 핵심적인 요소입니다. 특정 사용 사례에 충분한 테스트와 검증 파이프라인을 구현하는 것은 고객의 책임입니다. 서비스를 선택할 때는 해당 파이프라인이 어디에서 실행되는지 고려해야 합니다. 외부 서비스에 연결하면 연방 데이터를 저장하고 처리하도록 허용된 권한 부여 경계를 위반할 수 있습니다. GitLab은 FIPS 활성화 시스템에서 실행되도록 구성된 러너 컨테이너 이미지를 제공합니다. GitLab은 보호된 브랜치를 구성하는 방법과 파이프라인 보안을 구현하는 방법을 포함한 파이프라인 하드닝 지침을 제공합니다. 또한 고객은 코드를 업데이트하기 전에 모든 검사가 통과했는지 확인하기 위해 병합 전에 필수 검사를 지정하는 것을 고려할 수 있습니다.

구성 요소 인벤토리

NIST 800-53은 클라우드 서비스 제공업체가 구성 요소 인벤토리를 유지 관리할 것을 요구합니다. GitLab은 기본 하드웨어를 직접 추적할 수는 없지만, 컨테이너 스캐닝과 의존성 스캐닝을 통해 소프트웨어 인벤토리를 생성할 수 있습니다. GitLab은 컨테이너 스캐닝과 의존성 스캐닝이 탐지할 수 있는 의존성을 설명합니다. GitLab은 소프트웨어 구성 요소 인벤토리에 사용할 수 있는 의존성 목록 생성에 관한 추가 문서도 제공합니다. Software Bill of Materials 지원은 이 문서 뒷부분의 Supply Chain Risk Management에서 다룹니다.

컨테이너 레지스트리

GitLab은 GitLab 프로젝트의 컨테이너 이미지를 저장하는 통합 컨테이너 레지스트리를 제공하며, 이는 고도로 가상화되고 확장 가능한 환경에서 컨테이너를 배포하기 위한 신뢰할 수 있는 리포지터리로 사용할 수 있습니다. 컨테이너 레지스트리 관리 지침을 검토할 수 있습니다.

컨틴전시 플래닝(CP)#

GitLab은 핵심 컨틴전시 플래닝 요구 사항을 충족하는 데 도움이 되는 지침과 서비스를 제공합니다. 포함된 문서를 검토하고 컨틴전시 플래닝 활동에 대한 조직 요구 사항을 충족하도록 그에 맞게 계획하는 것이 중요합니다. 컨틴전시 플래닝은 조직마다 고유하므로 컨틴전시 플랜을 수립하기 전에 조직의 요구 사항을 고려하는 것이 중요합니다.

GitLab 아키텍처 선택

GitLab은 GitLab Self-Managed 인스턴스에서 지원되는 아키텍처에 대한 방대한 문서를 제공합니다. GitLab은 다음 클라우드 서비스 제공업체를 지원합니다.

GitLab은 고객이 참조 아키텍처와 가용성 모델을 선택하도록 돕는 의사 결정 트리를 제공합니다. 대부분의 클라우드 서비스 제공업체는 관리형 서비스에 대해 리전 내 복원력을 제공합니다. 아키텍처를 선택할 때는 조직의 다운타임 허용 범위와 데이터의 중요도를 고려하는 것이 중요합니다. 추가적인 복제와 페일오버 기능이 필요하다면 GitLab Geo를 고려할 수 있습니다.

중요 자산 식별

NIST 800-53은 장애 발생 시 우선적으로 복구할 수 있도록 중요 자산을 식별할 것을 요구합니다. 고려해야 할 중요 자산에는 Gitaly 노드와 PostgreSQL 데이터베이스가 포함됩니다. 고객은 필요에 따라 백업이나 복제가 필요한 추가 자산을 식별해야 합니다.

백업

이 문서는 다음을 포함한 핵심 구성 요소의 백업 전략을 설명합니다.

GitLab Geo

GitLab Geo는 NIST 800-53 컴플라이언스를 추진하는 모든 구현에서 핵심 구성 요소가 될 가능성이 높습니다. 각 사용 사례에 맞게 Geo가 적절히 구성되었는지 확인하려면 제공된 문서를 검토하는 것이 중요합니다.

Geo를 구현하면 다음과 같은 이점이 있습니다.

  • 분산된 개발자가 대규모 리포지터리와 프로젝트를 클론·페치하는 데 걸리는 시간을 분 단위에서 초 단위로 단축합니다.
  • 개발자가 리전 간에 아이디어를 제시하고 병렬로 작업할 수 있도록 지원합니다.
  • 기본 사이트와 보조 사이트 간에 읽기 전용 부하를 분산합니다.
  • GitLab 웹 인터페이스에서 제공되는 데이터를 읽는 것 외에도 프로젝트를 클론하고 페치하는 데 사용할 수 있습니다(제한 사항 참고).
  • 원거리 사무실 간의 느린 연결을 극복하여 분산된 팀의 속도를 높이고 시간을 절약합니다.
  • 자동화된 작업, 커스텀 통합, 내부 워크플로의 로딩 시간을 단축하는 데 도움이 됩니다.
  • 재해 복구 시나리오에서 보조 사이트로 빠르게 페일오버할 수 있습니다.
  • 보조 사이트로의 계획된 페일오버를 지원합니다.

Geo는 다음과 같은 핵심 기능을 제공합니다.

  • 읽기 전용 보조 사이트: 하나의 프라이머리 GitLab 사이트를 유지하면서 분산된 팀을 위한 읽기 전용 보조 사이트도 활성화할 수 있습니다.
  • 인증 시스템 훅: 보조 사이트는 프라이머리 인스턴스로부터 사용자 계정, 로그인과 같은 모든 인증 데이터를 수신합니다.
  • 직관적인 UI: 보조 사이트는 기본 사이트와 동일한 웹 인터페이스를 사용합니다. 또한 쓰기 작업을 차단하고 사용자가 보조 사이트에 있음을 명확히 알리는 시각적 알림이 제공됩니다.

추가 Geo 자료:

PostgreSQL

GitLab은 복제와 페일오버를 사용하는 PostgreSQL 클러스터 구성 방법에 대한 지침을 제공합니다. 데이터의 중요도와 GitLab 인스턴스의 최대 허용 다운타임에 따라 복제와 페일오버를 활성화한 PostgreSQL 구성을 고려합니다.

Gitaly

Gitaly를 구성할 때는 가용성, 복구 가능성, 복원력 사이의 트레이드오프를 고려합니다. GitLab은 NIST 800-53 요구 사항을 충족하는 올바른 구성을 결정하는 데 도움이 되는 Gitaly 기능에 대한 방대한 문서를 제공합니다.

계획(PL)#

Planning 컨트롤 패밀리는 정책, 절차, 기타 통제 문서의 유지 관리를 포함합니다. GitLab을 활용하여 통제 문서의 수명 주기를 관리하는 것을 고려합니다. 예를 들어 통제 문서는 버전 관리 상태로 Markdown에 저장할 수 있습니다. 문서에 대한 모든 변경은 조직의 승인 규칙을 적용하는 머지 리퀘스트를 통해 이루어져야 합니다. 머지 리퀘스트는 통제 문서에 가해진 변경 사항의 명확한 이력을 제공하므로, 감사 시 문서 소유자와 같은 적절한 담당자에 의한 연례 검토와 승인을 입증하는 데 사용할 수 있습니다.

위험 평가 및 시스템·정보 무결성(RA)#

스캐닝#

NIST 800-53은 취약점과 결함 해결에 대한 지속적인 모니터링을 요구합니다. 인프라 스캐닝 외에도 FedRAMP와 같은 컴플라이언스 프레임워크는 컨테이너와 DAST 스캔을 월간 보고 요구 사항에 포함시켰습니다. GitLab은 Trivy와 Grype 스캐너를 포함해 컨테이너 스캐닝을 지원하는 도구를 제공합니다. 또한 GitLab은 의존성 스캐닝 기능도 제공합니다. GitLab의 DAST는 웹 애플리케이션 스캐닝 요구 사항을 충족하는 데 사용할 수 있습니다. GitLab DAST는 파이프라인에서 실행되어 운영 중인 웹 애플리케이션의 취약점 보고서를 생성하도록 구성할 수 있습니다.

애플리케이션 코드를 보호하고 관리하는 데 사용할 수 있는 추가 보안 기능은 다음과 같습니다.

패치 관리#

GitLab은 문서에서 릴리스 및 유지 관리 정책을 설명합니다. GitLab 인스턴스를 업그레이드하기 전에 업그레이드 계획, 다운타임 없는 업그레이드, 기타 업그레이드 경로에 도움이 되는 제공된 지침을 검토합니다.

보안 대시보드는 시간에 따른 취약점 데이터를 추적하도록 구성할 수 있으며, 이를 통해 취약점 관리 프로그램의 추세를 파악할 수 있습니다.

공급망 위험 관리(SR)#

Software Bill of Materials#

GitLab의 의존성 스캐너와 컨테이너 스캐너는 SBOM 생성을 지원합니다. 컨테이너 스캐닝과 의존성 스캐닝에서 SBOM 보고서를 활성화하면 고객 조직이 소프트웨어 공급망과 소프트웨어 구성 요소에 내재된 위험을 이해하는 데 도움이 됩니다. GitLab 스캐너는 CycloneDX 형식 보고서를 지원합니다.

시스템 및 통신 보호(SC)#

FIPS 컴플라이언스#

FedRAMP와 같이 NIST 800-53을 기반으로 하는 컴플라이언스 프로그램은 적용 가능한 모든 암호화 모듈에 대해 FIPS 컴플라이언스를 요구합니다. GitLab은 컨테이너 이미지의 FIPS 버전을 출시했으며 FIPS 컴플라이언스 표준을 충족하도록 GitLab을 구성하는 방법에 대한 지침을 제공합니다. 일부 기능은 FIPS 모드에서 사용할 수 없거나 지원되지 않습니다.

GitLab은 FIPS를 준수하는 이미지를 제공하지만, 기본 인프라를 구성하고 FIPS 검증 암호가 적용되는지 환경을 평가하는 것은 고객의 책임입니다.

시스템 및 정보 무결성(SI)#

보안 경보, 권고, 지시#

GitLab은 소프트웨어와 의존성 관련 보안 취약점을 추적하기 위한 권고 데이터베이스를 유지 관리합니다. GitLab은 CVE Numbering Authority(CNA) 입니다. CVE ID 요청 생성 방법은 이 페이지를 참고합니다.

이메일#

GitLab은 GitLab 애플리케이션 인스턴스에서 사용자에게 이메일 알림을 보내는 기능을 지원합니다. DHS BOD 18-01 지침은 스팸 방지를 위해 발신 메시지에 Domain-based Message Authentication, Reporting & Conformance(DMARC)를 구성해야 한다고 명시합니다. GitLab은 이 요구 사항을 충족하는 데 도움이 될 수 있도록 다양한 이메일 제공업체에 대해 SMTP 구성 지침을 제공합니다.

기타 서비스 및 개념#

러너#

러너는 모든 GitLab 배포에서 다양한 작업과 도구에 필요합니다. 데이터 경계 요구 사항을 유지하기 위해 고객은 권한 부여 경계 내에 셀프 매니지드 러너를 배포해야 할 수 있습니다. GitLab은 러너 구성에 대한 상세 정보를 제공하며, 여기에는 다음과 같은 개념이 포함됩니다.

  • 최대 job 타임아웃
  • 민감 정보 보호
  • 롱 폴링 구성
  • 인증 토큰 보안 및 토큰 교체
  • 민감 정보 노출 방지
  • 러너 변수

API 활용#

GitLab은 애플리케이션을 지원하는 강력한 API 세트를 제공하며, REST와 GraphQL API를 포함합니다. API를 보호하려면 먼저 API 엔드포인트를 호출하는 사용자와 job에 대한 인증을 올바르게 구성해야 합니다. GitLab은 접근을 제어하기 위해 액세스 토큰(FIPS에서는 개인 액세스 토큰 미지원)과 OAuth 2.0 토큰을 구성할 것을 권장합니다.

확장#

확장은 어떤 통합이 구성되어 있는지에 따라 NIST 800-53 요구 사항을 충족할 수 있습니다. 예를 들어 편집기와 IDE 확장은 허용될 수 있지만, 제3자와의 통합은 권한 부여 경계 요구 사항을 위반할 수 있습니다. 데이터가 고객의 권한 부여 경계 밖으로 전송되는 위치를 파악하기 위해 모든 확장을 검증하는 것은 고객의 책임입니다.

추가 자료#

GitLab은 다음과 같은 주제를 다루는 GitLab Self-Managed 고객용 하드닝 가이드를 제공합니다.

GitLab CIS Benchmark 가이드 - GitLab은 애플리케이션의 하드닝 결정을 안내하는 CIS Benchmark를 발행했습니다. 이 가이드와 함께 사용하여 NIST 800-53 컨트롤에 따라 환경을 하드닝할 수 있습니다. CIS Benchmark의 모든 제안이 NIST 800-53 컨트롤과 직접 일치하지는 않지만, GitLab 인스턴스를 유지 관리하기 위한 모범 사례로 활용할 수 있습니다.