NIST 800-53 준수

Tier: Ultimate Offering: Self-managed, GitLab Dedicated

이 페이지는 자율 관리 인스턴스를 구성하여 적용 가능한 NIST 800-53 통제를 충족하려는 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 준수를 위한 중요한 고려 사항은 발행된 코드가 코드의 진위를 확인하고 시스템 및 정보 무결성(SI) 통제 가족의 요구 사항을 충족하기 위해 서명해야 할 수도 있다는 것입니다.

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

GitLab 배포의 접근 관리는 각 고객에 따라 고유합니다.

GitLab은 신원 제공자 및 GitLab 네이티브 인증 구성으로 배포를 다루는 다양한 문서를 제공합니다.

GitLab 인스턴스에 대한 인증 방식을 결정하기 전에 조직의 요구 사항을 고려하는 것이 중요합니다.

신원 제공자

GitLab 내의 접근은 UI를 사용하거나 기존 신원 제공자와 통합하여 관리할 수 있습니다.

FedRAMP 요구 사항을 충족하기 위해 기존 신원 제공자가 FedRAMP Marketplace에서 FedRAMP 승인되었는지 확인하세요.

PIV와 같은 요구 사항을 충족하기 위해서는 자체 관리 GitLab에서 네이티브 인증을 사용하는 것보다 신원 제공자를 사용하는 것이 좋습니다.

GitLab은 다양한 신원 제공자 및 프로토콜 구성을 위한 리소스를 제공합니다.

  • LDAP

  • SAML

  • 신원 제공자에 대한 더 많은 정보는 GitLab Docs에서 확인할 수 있습니다.

네이티브 GitLab 사용자 인증 구성

계정 관리 및 분류 - GitLab은 관리자들이 다양한 민감도 및 접근 요구 사항을 가진 사용자를 추적할 수 있도록 합니다.

GitLab은 세분화된 접근 옵션을 제공함으로써 최소 권한 원칙 및 역할 기반 접근 개념을 지원합니다.

프로젝트 수준에서 지원되는 역할은 다음과 같습니다.

  • 게스트

  • 보고자

  • 개발자

  • 유지 관리자

  • 소유자

프로젝트 수준 권한에 대한 추가 세부정보는 문서에서 확인할 수 있습니다.

GitLab은 독특한 권한 요구 사항을 가진 고객을 위한 사용자 정의 역할도 지원합니다.

GitLab은 또한 특별한 사용 사례를 위한 다음 사용자 유형을 지원합니다:

  • 감사 사용자 - 감사 역할은 Admin 영역 및 프로젝트/그룹 설정을 제외한 모든 그룹, 프로젝트 및 기타 리소스에 대한 읽기 전용 접근을 제공합니다. 특정 프로젝트에 접근하여 프로세스를 검증해야 하는 제3자 감사자와 만날 때 감사 역할을 사용할 수 있습니다.

  • 외부 사용자 - 외부 사용자는 조직의 일부가 아닐 수 있는 사용자에게 제한된 접근을 제공하도록 설정할 수 있습니다. 일반적으로 이는 계약자 또는 기타 제3자의 접근 관리를 충족하는 데 사용될 수 있습니다. IA-4(4)와 같은 제어는 비조직 사용자가 회사 정책에 따라 식별되고 관리되어야 함을 요구합니다. 외부 사용자를 설정하면 기본적으로 프로젝트에 대한 접근을 제한하여 조직의 위험을 줄이고 관리자가 조직에 고용되지 않은 사용자를 식별하는 데 도움을 줄 수 있습니다.

  • 서비스 계정 - 서비스 계정은 자동화된 작업을 수용하기 위해 추가될 수 있습니다. 서비스 계정은 라이선스 하에 좌석을 사용하지 않습니다.

Admin 영역 - Admin 영역에서 관리자는 권한 내보내기, 사용자 신원 검토, 그룹 관리 등을 수행할 수 있습니다.

FedRAMP/NIST 800-53 요구 사항을 충족하기 위해 사용할 수 있는 기능:

  • 의심스러운 경우 사용자 비밀번호 재설정.

  • 사용자 잠금 해제. 기본적으로 GitLab은 10회의 로그인 실패 후 사용자를 잠급니다. 사용자는 10분 동안 잠겨 있거나 관리자가 사용자의 잠금을 해제할 때까지 잠겨 있습니다. GitLab 16.5 이상에서 관리자는 API를 사용하여 최대 로그인 시도 횟수 및 잠금 상태로 남아 있는 시간 기간을 구성할 수 있습니다. AC-7 기준에 따라 FedRAMP는 계정 잠금 매개변수 정의에 대해 NIST 800-63B에 의존하며, 기본 설정이 이를 충족합니다.

  • 남용 보고서 또는 스팸 로그 검토. FedRAMP는 조직이 비정상적인 사용에 대해 계정을 모니터링하도록 요구합니다 (AC-2(12)). GitLab은 사용자가 남용 보고서에서 남용을 표시할 수 있도록 하여 관리자가 조사 중에 접근을 제거할 수 있습니다. 스팸 로그는 Admin 영역의 스팸 로그 섹션에 통합되어 있습니다. 관리자는 해당 영역에서 플래그가 지정된 사용자를 제거, 차단 또는 신뢰할 수 있습니다.

  • 비밀번호 저장 매개변수 설정. 저장된 비밀번호는 SC-13에 따라 FIPS 140-2 또는 140-3을 충족해야 합니다. FIPS 모드가 활성화되면 FIPS 준수 암호를 사용하여 PBKDF2+SHA512를 지원합니다.

  • 자격 증명 인벤토리는 관리자가 하나의 위치에서 GitLab 자체 관리 인스턴스에서 사용되는 모든 비밀번호를 검토할 수 있도록 합니다. 자격 증명, 토큰 및 키의 통합된 뷰는 비밀번호를 검토하거나 자격 증명을 회전하는와 같은 요구 사항을 충족하는 데 도움이 될 수 있습니다.

  • 고객 비밀번호 길이 제한 설정. FedRAMP는 IA-5에서 비밀번호 길이 요구 사항을 설정하기 위해 NIST 800-63B에 의존합니다. GitLab은 기본값으로 8자로 설정된 8-128자 비밀번호를 지원합니다. GitLab은 더 긴 비밀번호를 시행하려는 조직이 사용할 수 있는 GitLab UI를 통해 최소 비밀번호 길이 업데이트 지침을 제공합니다. 또한, 자체 관리 고객은 Admin 영역 UI를 통해 복잡성 요구 사항을 구성할 수 있습니다.

  • 기본 세션 기간 설정 - FedRAMP는 설정된 시간 동안 비활성 상태인 사용자는 로그아웃해야 한다고 설정합니다. FedRAMP는 시간 기간을 명시하지 않지만, 특권 사용자가 일반 작업 기간 끝에 로그아웃해야 한다고 명확히 합니다. 관리자는 기본 세션 기간 설정을 설정할 수 있습니다.

  • 신규 사용자 프로비저닝 - 관리자는 Admin 영역 UI를 통해 GitLab 계정을 위한 신규 사용자를 생성할 수 있습니다. IA-5에 따라 GitLab은 신규 사용자가 첫 로그인 시 비밀번호를 변경하도록 요구합니다.

  • 사용자 비활성화 - 관리자는 Admin 영역 UI를 통해 사용자를 제거할 수 있습니다. 사용자를 삭제하는 대신 사용자를 차단하고 모든 접근 권한을 제거할 수 있습니다. 사용자를 차단하면 해당 사용자의 데이터는 저장소에 유지되지만 모든 접근 권한이 제거됩니다. 차단된 사용자는 좌석 수에 영향을 미치지 않습니다.

  • 사용자 비활성화 - 계정 검토 중에 식별된 비활성 사용자는 일시적으로 비활성화될 수 있습니다. 비활성화는 차단과 유사하지만 몇 가지 중요한 차이점이 있습니다. 사용자가 비활성화되어도 GitLab UI에 로그인하는 것을 금지하지 않습니다. 비활성화된 사용자는 로그인하여 다시 활성화될 수 있습니다. 비활성화된 사용자는:

    • 저장소 또는 API에 접근할 수 없습니다.

    • 슬래시 명령을 사용할 수 없습니다. 슬래시 명령에 대한 자세한 내용은 슬래시 명령을 참조하세요.

    • 좌석을 차지하지 않습니다.

추가 식별 방법

이중 인증 - GitLab은 다음의 두 번째 요인을 지원합니다:

  • 시간 기반 일회용 비밀번호

  • WebAuthN 장치

이중 인증 활성화 지침은 문서에서 제공됩니다. FedRAMP를 추구하는 고객은 FedRAMP 승인 및 FIPS 요구 사항을 지원하는 이중 인증 제공자를 고려해야 합니다. FedRAMP에서 승인된 제공자는 FedRAMP Marketplace에서 찾을 수 있습니다. 두 번째 요인을 선택할 때 NIST와 FedRAMP가 이제 피싱 저항 인증(예: WebAuthN)을 사용해야 한다고 명시하고 있다는 점에 유의해야 합니다 (IA-2).

SSH 키

개인 접근 토큰

사용자 접근을 위한 개인 접근 토큰은 FIPS가 활성화된 인스턴스에서 기본적으로 비활성화되어 있습니다.

기타 접근 제어 가족 개념

시스템 사용 알림

연방 요구 사항은 종종 로그인 시 배너의 필요성을 설명합니다. 이는 ID 제공자를 통해 및 GitLab 배너 기능을 통해 구성할 수 있습니다.

외부 연결

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

개인 신원 확인 (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년 동안 저장해야 합니다. 고객 조직은 수집된 데이터의 영향에 따라 국가 기록 보관소(NARA)의 요구 사항을 충족해야 할 수도 있습니다. 수집된 기록의 영향을 검토하고 적용 가능한 준수 요구 사항을 이해하는 것이 중요합니다.

사고 대응 (IR)

감사 이벤트가 구성되면, 해당 이벤트는 모니터링되어야 합니다.

GitLab은 SIEM 또는 기타 보안 도구에서 시스템 경고를 수집하고,

경고 및 사건을 분류하며 이해 관계자에게 알리기 위한 중앙 집중식 관리 인터페이스를 제공합니다.

사고 관리 문서는

GitLab을 사용하여 보안 사고 대응 조직에서 앞서 언급한 활동을 수행하는 방법을 설명합니다.

사고 대응 생애주기

GitLab은 조직의 사고 대응 생애주기를 관리할 수 있습니다.

사고 대응 요구 사항을 충족하는 데 도움이 될 수 있는 다음 리소스를 검토하십시오:

구성 관리 (CM)

변경 관리

GitLab은 기본적으로 변경 관리와 관련된 구성 관리 요구 사항을 충족할 수 있습니다.

이슈와 병합 요청은 변경을 지원하는 주요 방법입니다.

이슈는 변경 사항을 구현하기 전에 메타데이터와 승인을 캡처하는 유연한 플랫폼입니다.

구성 관리 통제를 충족하기 위해 GitLab 문서에서 작업 계획 및 추적에 대한 정보를 검토해 보시기 바랍니다.

병합 요청은 소스 브랜치에서 대상 브랜치로의 변경 사항을 표준화하는 방법을 제공합니다.

NIST 800-53의 맥락에서, 코드를 병합하기 전에 승인을 수집하는 방법과 조직 내에서 코드를 병합할 수 있는 능력을 가진

사람이 누구인지를 고려하는 것이 중요합니다.

GitLab은 병합 요청에서 승인에 대한 다양한 설정을 제공하는 데 도움을 줍니다.

필요한 검토가 완료된 후 적절한 역할만에게 승인 및 병합 권한을 부여하는 것을 고려하십시오.

고려해야 할 추가 병합 설정은 다음과 같습니다:

변경의 테스트 및 검증

CI/CD 파이프라인은 테스트 및 변경 검증의 중요한 요소입니다.

특정 사용 사례를 위한 충분한 테스트 및 검증 파이프라인을 구현하는 것은 고객의 책임입니다.

서비스를 선택할 때 해당 파이프라인이 실행될 위치를 고려하십시오.

외부 서비스에 연결하는 것은 연방 데이터가 저장 및 처리될 수 있는 권한 경계를 위반할 수 있습니다.

GitLab은 FIPS 지원 시스템에서 실행되도록 구성된 러너 컨테이너 이미지를 제공합니다.

GitLab은 보호된 브랜치 구성과 파이프라인 보안 구현에 대한 하드닝 가이드를 제공합니다.

또한 고객은 코드 업데이트 전에 모든 체크가 통과했는지 확인하기 위해 필수 체크를 병합하기 전에 지정하는 것을 고려할 수 있습니다.

컴포넌트 인벤토리

NIST 800-53은 클라우드 서비스 제공자가 컴포넌트 인벤토리를 유지하도록 요구합니다.

GitLab은 기본 하드웨어를 직접 추적할 수는 없지만, 컨테이너 및 종속성 스캐닝을 통해 소프트웨어 인벤토리를 생성할 수 있습니다.

GitLab은 컨테이너 스캐닝 및 종속성 스캐닝이 감지할 수 있는 종속성을 설명합니다.

GitLab은 소프트웨어 컴포넌트 인벤토리에서 사용할 수 있는 종속성 목록 생성을 위한 추가 문서를 제공합니다.

소프트웨어 자재 명세서 지원은 Supply Chain Risk Management 섹션에서 더욱 자세히 설명됩니다.

컨테이너 레지스트리

GitLab은 GitLab 프로젝트용으로 컨테이너 이미지를 저장하는 통합 컨테이너 레지스트리를 제공하며,

이는 고도로 가상화되고 확장 가능한 환경에서 컨테이너를 배포하기 위한 권위 있는 리포지토리로 사용할 수 있습니다.

컨테이너 레지스트리 관리 안내가 검토를 위해 제공됩니다.

비상 계획 (CP)

GitLab은 핵심 비상 계획 요구 사항을 충족하는 데 도움이 되는 지침과 서비스를 제공합니다. 포함된 문서를 검토하고 조직의 비상 계획 활동 요구 사항을 충족하도록 계획하는 것이 중요합니다. 비상 계획은 각 조직마다 다르므로 비상 계획을 수립하기 전에 조직의 요구 사항을 고려하는 것이 중요합니다.

GitLab 아키텍처 선택하기

GitLab은 자체 관리 인스턴스에서 지원되는 아키텍처에 대한 광범위한 문서를 제공합니다. GitLab은 다음 클라우드 서비스 제공업체를 지원합니다:

GitLab은 참조 아키텍처 및 가용성 모델 선택에 도움을 주는 결정 트리를 제공합니다. 대부분의 클라우드 서비스 제공업체는 관리형 서비스에 대해 지역 내 내구성을 제공합니다. 아키텍처를 선택할 때 조직의 다운타임 수용 능력과 데이터의 중요성을 고려하는 것이 중요합니다. GitLab Geo는 추가 복제 및 페일오버 기능을 위해 고려할 수 있습니다.

중요 자산 식별하기

NIST 800-53은 정전 발생 시 우선 복구가 필요한 중요한 자산의 식별을 요구합니다. 고려해야 할 중요한 자산에는 Gitaly 노드와 PostgreSQL 데이터베이스가 포함됩니다. 고객은 필요한 경우 백업 또는 복제가 필요한 추가 자산을 식별해야 합니다.

백업

GitLab Docs는 다음을 포함하여 중요한 구성 요소에 대한 백업 전략을 설명합니다:

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)

계획 통제 가족에는 정책, 절차 및 기타 통제 문서의 유지 관리가 포함됩니다. GitLab을 활용하여 통제 문서의 수명 주기를 관리하는 것을 고려하세요. 예를 들어, 통제 문서는 버전 관리된 상태로 Markdown에 저장할 수 있습니다. 문서에 대한 모든 변경은 조직의 승인 규칙을 강제하는 병합 요청을 통해 이루어져야 합니다. 병합 요청은 통제 문서에 대해 이력이 명확하게 남아 감사 중에 문서 소유자와 같은 적절한 인원에 의해 연례 검토 및 승인을 나타내는 데 사용할 수 있습니다.

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

스캐닝

NIST 800-53은 취약점 및 결함 수정에 대한 지속적인 모니터링을 요구합니다. 인프라 스캐닝 외에도, FedRAMP와 같은 준수 프레임워크는 컨테이너 및 DAST 스캔을 월간 보고 요구 사항에 포함시켰습니다. GitLab은 컨테이너 스캔을 지원하는 보안 도구를 제공하며, 여기에는 Trivy와 Grype 스캐너가 포함됩니다.

또한, GitLab은 종속성 스캐닝 기능을 제공합니다. GitLab의 동적 애플리케이션 보안 테스트(DAST)는 웹 애플리케이션 스캔 요구 사항을 충족하는 데 사용할 수 있습니다. GitLab DAST는 파이프라인에서 실행되도록 구성할 수 있으며, 실행 중인 웹 애플리케이션에 대한 취약성 보고서를 생성할 수 있습니다.

애플리케이션 코드를 보호하고 관리하기 위해 사용할 수 있는 추가 보안 기능에는 다음이 포함됩니다:

패치 관리

GitLab은 릴리스 및 유지 관리 정책을 문서화합니다. GitLab 인스턴스를 업그레이드하기 전에는 업그레이드 계획, 다운타임 없이 업그레이드하기 및 기타 업그레이드 경로에 대한 유용한 안내를 검토해야 합니다.

보안 대시보드는 시간에 따라 취약성 데이터를 추적하도록 설정할 수 있으며, 이를 통해 취약성 관리 프로그램의 추세를 식별하는 데 사용할 수 있습니다.

공급망 위험 관리 (SR)

소프트웨어 자재 명세서

GitLab 종속성 및 컨테이너 스캐너는 SBOM 생성을 지원합니다. 컨테이너 및 종속성 스캐닝에서 SBOM 보고서를 활성화하면 고객 조직이 소프트웨어 공급망 및 소프트웨어 구성 요소와 관련된 고유한 위험을 이해할 수 있도록 할 수 있습니다. GitLab 스캐너는 CycloneDX 형식의 보고서를 지원합니다.

시스템 및 커뮤니케이션 보호 (SC)

FIPS 준수

NIST 800-53을 기반으로 하는 준수 프로그램, 예를 들어 FedRAMP는 적용 가능한 모든 암호 모듈에 대해 FIPS 준수를 요구합니다. GitLab은 FIPS 버전의 컨테이너 이미지를 출시하였으며, FIPS 준수 기준을 충족하기 위한 GitLab 구성 방법에 대한 안내를 제공합니다. FIPS 모드에서 특정 기능은 사용할 수 없거나 지원되지 않는다는 점을 주목하는 것이 중요합니다.

GitLab이 FIPS 준수 이미지를 제공하는 동안, 고객은 기본 인프라를 구성하고 환경을 평가하여 FIPS 인증된 암호화 알고리즘이 강제되고 있는지 확인할 책임이 있습니다.

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

보안 경고, 권고사항 및 지침

GitLab은 보안 취약점을 추적하기 위한 권고사항 데이터베이스를 유지합니다.

GitLab은 CVE 번호 지정 기관(CNA)입니다. 이 페이지를 따라 CVE ID 요청을 생성하세요.

이메일

GitLab은 GitLab 애플리케이션 인스턴스에서 사용자에게 이메일 알림을 전송하는 것을 지원합니다. DHS BOD 18-01 지침에 따르면 도메인 기반 메시지 인증, 보고 및 준수(DMARC)는 스팸 보호를 위해 발신 메시지에 대해 구성되어야 합니다. GitLab은 이 요구 사항을 충족하는 데 도움이 될 수 있는 다양한 이메일 공급자에 대한 SMTP 구성 지침을 제공합니다.

기타 서비스 및 개념

러너

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

  • 최대 작업 타임아웃

  • 민감한 정보 보호

  • 긴 폴링 구성

  • 인증 토큰 보안 및 토큰 회전

  • 민감한 정보 노출 방지

  • 러너 변수

API 활용

GitLab은 애플리케이션을 지원하기 위한 강력한 API 세트를 제공하며, 여기에는 REST 및 GraphQL API가 포함됩니다. API를 보호하는 것은 API 엔드포인트를 호출하는 사용자 및 작업에 대한 인증의 적절한 구성에서 시작됩니다. GitLab은 액세스를 제어하기 위해 액세스 토큰(개인 액세스 토큰은 FIPS에서 지원되지 않음) 및 OAuth 2.0 토큰을 구성하는 것을 권장합니다.

확장

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

추가 리소스

GitLab은 자체 관리 고객을 위한 하드닝 가이드를 제공하며, 여기에는 다음과 같은 주제가 포함됩니다:

GitLab CIS 벤치마크 가이드 - GitLab은 애플리케이션 내 하드닝 결정을 안내하기 위한 CIS 벤치마크를 발표했습니다. 이는 NIST 800-53 통제에 따라 환경을 강화하는 데 이 가이드와 함께 사용할 수 있습니다. CIS 벤치마크의 모든 제안이 NIST 800-53 통제에 직접적으로 일치하지는 않지만, GitLab 인스턴스를 유지하기 위한 모범 사례로 사용됩니다.