InfoGrab Docs

NIST 800-53 컴플라이언스

요약

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

이 페이지는 GitLab Self-Managed 인스턴스가 적용 가능한 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은 ID 공급자와의 배포 및 GitLab 기본 인증 구성을 다루는 다양한 문서를 제공합니다. GitLab 인스턴스에 대한 인증 방법을 결정하기 전에 조직의 요구 사항을 고려하는 것이 중요합니다.

ID 공급자#

GitLab의 접근은 UI 또는 기존 ID 공급자와의 통합을 통해 관리할 수 있습니다. FedRAMP 요구 사항을 충족하려면 기존 ID 공급자가 FedRAMP 마켓플레이스에서 FedRAMP 승인을 받았는지 확인하세요. PIV와 같은 요구 사항을 충족하려면 GitLab Self-Managed의 기본 인증을 사용하는 대신 ID 공급자를 활용해야 합니다.

GitLab은 다음을 포함한 다양한 ID 공급자 및 프로토콜 구성을 위한 리소스를 제공합니다:

기본 GitLab 사용자 인증 구성#

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

  • Guest

  • Reporter

  • Developer

  • Maintainer

  • Owner

프로젝트 수준 권한에 대한 추가 세부 정보는 문서에서 확인할 수 있습니다. GitLab은 또한 고유한 권한 요구 사항이 있는 고객을 위한 사용자 정의 역할을 지원합니다.

GitLab은 또한 고유한 사용 사례를 위해 다음과 같은 사용자 유형을 지원합니다:

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

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

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

Admin 영역 - Admin 영역에서 관리자는 권한 내보내기, 사용자 ID 검토, 그룹 관리 등을 할 수 있습니다. FedRAMP / NIST 800-53 요구 사항을 충족하는 데 사용할 수 있는 기능:

  • 침해가 의심될 때 사용자 비밀번호 재설정.

  • 사용자 잠금 해제. 기본적으로 GitLab은 10번의 로그인 시도 실패 후 사용자를 잠급니다. 사용자는 10분 동안 잠기거나 관리자가 사용자를 잠금 해제할 때까지 잠금 상태를 유지합니다. GitLab 16.5 이상에서 관리자는 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에 접근할 수 없습니다.

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

    • 시트를 차지하지 않습니다.

추가 식별 방법#

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

  • 일회용 비밀번호 인증기

  • WebAuthn 장치

이중 인증 활성화 지침은 문서에 제공되어 있습니다. FedRAMP를 추구하는 고객은 FedRAMP 승인을 받고 FIPS 요구 사항을 지원하는 이중 인증 공급자를 고려해야 합니다. FedRAMP 승인 공급자는 FedRAMP 마켓플레이스에서 찾을 수 있습니다. 두 번째 인증 수단을 선택할 때 NIST와 FedRAMP는 이제 WebAuthn과 같은 피싱 저항 인증을 사용해야 한다고 나타내고 있습니다(IA-2).

SSH 키

  • GitLab은 Git과 인증 및 통신하기 위해 SSH 키를 구성하는 방법에 대한 지침을 제공합니다. 커밋에 서명하면 공개 키가 있는 누구에게나 추가적인 검증을 제공합니다.

  • 키는 FIPS 140-2 및 FIPS 140-3 검증된 암호 사용과 같이 적용 가능한 강도 및 복잡성 요구 사항을 충족하도록 구성해야 합니다. 관리자는 최소 키 기술 및 키 길이를 제한할 수 있습니다. 또한 GitLab은 침해된 키를 차단합니다.

개인 액세스 토큰

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

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

시스템 사용 알림

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

외부 연결

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

PIV(개인 신원 확인)

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

감사 및 책임 (AU)#

NIST 800-53은 조직이 보안 관련 이벤트를 모니터링하고, 해당 이벤트를 분석하고, 알림을 생성하고, 알림의 중요도에 따라 알림을 조사해야 한다고 요구합니다. GitLab은 보안 정보 및 이벤트 관리(SIEM) 솔루션으로 라우팅할 수 있는 광범위한 보안 이벤트를 제공합니다.

이벤트 유형#

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

로그 시스템

GitLab은 모든 것을 기록할 수 있는 고급 로그 시스템을 포함합니다. GitLab은 광범위한 출력을 포함하는 로그 유형에 대한 로그 시스템 지침을 제공합니다. 자세한 내용은 링크된 지침을 검토하세요.

이벤트 스트리밍

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

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

  • 성공 및 실패한 계정 로그온 이벤트

  • 계정 관리 이벤트

  • 객체 접근

  • 정책 변경

  • 권한 기능

  • 프로세스 추적

  • 시스템 이벤트

  • 웹 애플리케이션의 경우:

    • 모든 관리자 활동

    • 인증 확인

    • 권한 부여 확인

    • 데이터 삭제

    • 데이터 접근

    • 데이터 변경

    • 권한 변경

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

메트릭

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

스토리지

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

인시던트 대응 (IR)#

감사 이벤트가 구성되면 해당 이벤트를 모니터링해야 합니다. GitLab은 SIEM 또는 기타 보안 도구에서 시스템 알림을 컴파일하고, 알림 및 인시던트를 분류하고, 이해관계자에게 알리기 위한 중앙화된 관리 인터페이스를 제공합니다. 인시던트 관리 문서는 GitLab을 사용하여 보안 인시던트 대응 조직에서 앞서 언급한 활동을 실행하는 방법을 설명합니다.

인시던트 대응 수명 주기

GitLab은 조직의 인시던트 대응 수명 주기 전체를 관리할 수 있습니다. 인시던트 대응 요구 사항을 충족하는 데 도움이 될 수 있는 다음 리소스를 검토하세요:

구성 관리 (CM)#

변경 제어

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

이슈는 변경을 구현하기 전에 메타데이터와 승인을 캡처하기 위한 유연한 플랫폼입니다. GitLab이 구성 관리 컨트롤을 충족하는 데 어떻게 사용될 수 있는지 완전히 이해하기 위해 작업 계획 및 추적에 대한 GitLab 문서를 검토하세요.

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

변경 테스트 및 검증

CI/CD 파이프라인은 변경을 테스트하고 검증하는 중요한 컴포넌트입니다. 고객은 특정 사용 사례에 대한 충분한 테스트 및 검증 파이프라인을 구현할 책임이 있습니다. 서비스를 선택할 때 해당 파이프라인이 실행되는 위치를 고려하세요. 외부 서비스에 연결하면 연방 데이터가 저장되고 처리되도록 허용된 기존 승인 경계를 위반할 수 있습니다. GitLab은 FIPS 지원 시스템에서 실행되도록 구성된 러너 컨테이너 이미지를 제공합니다. GitLab은 보호된 브랜치 구성 방법 및 파이프라인 보안 구현을 포함한 파이프라인 강화 지침을 제공합니다. 또한 고객은 모든 검사가 통과된 후에만 코드를 업데이트할 수 있도록 코드 병합 전에 필수 검사 할당을 고려할 수 있습니다.

컴포넌트 인벤토리

NIST 800-53은 클라우드 서비스 공급자에게 컴포넌트 인벤토리를 유지하도록 요구합니다. GitLab은 기본 하드웨어를 직접 추적할 수 없지만 컨테이너 및 의존성 스캐닝을 통해 소프트웨어 인벤토리를 생성할 수 있습니다. GitLab은 컨테이너 스캐닝 및 의존성 스캐닝이 감지할 수 있는 의존성을 설명합니다. GitLab은 소프트웨어 컴포넌트 인벤토리에 사용할 수 있는 의존성 목록 생성에 관한 추가 문서를 제공합니다. 소프트웨어 자재 목록(SBOM) 지원은 이 문서의 공급망 위험 관리 아래 더 아래에 설명되어 있습니다.

컨테이너 레지스트리

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)#

계획 컨트롤 패밀리에는 정책, 절차 및 기타 제어 문서의 유지 관리가 포함됩니다. GitLab을 사용하여 제어 문서의 수명 주기를 관리하는 것을 고려하세요. 예를 들어 제어 문서는 버전 제어된 상태로 Markdown으로 저장할 수 있습니다. 문서에 대한 변경은 조직의 승인 규칙을 적용하는 머지 요청을 통해 이루어져야 합니다. 머지 요청은 제어 문서에 대한 변경 내역을 제공하며, 감사 중에 문서 소유자와 같은 적절한 담당자의 연간 검토 및 승인을 입증하는 데 사용할 수 있습니다.

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

스캐닝#

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

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

패치 관리#

GitLab은 문서에 릴리스 및 유지 관리 정책을 문서화합니다. GitLab 인스턴스를 업그레이드하기 전에 업그레이드 계획, 다운타임 없이 업그레이드 및 기타 업그레이드 경로에 도움이 될 수 있는 사용 가능한 지침을 검토하세요.

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

공급망 위험 관리 (SR)#

소프트웨어 자재 목록(SBOM)#

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

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

FIPS 컴플라이언스#

FedRAMP와 같이 NIST 800-53을 기반으로 하는 컴플라이언스 프로그램은 모든 해당 암호화 모듈에 대해 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은 다음과 같은 개념을 포함하는 러너 구성에 대한 자세한 정보를 제공합니다:

  • 최대 작업 타임아웃

  • 민감한 정보 보호

  • Long Polling 구성

  • 인증 토큰 보안 및 토큰 교체

  • 민감한 정보 노출 방지

  • 러너 변수

API 활용#

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

확장#

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

추가 리소스#

GitLab은 다음과 같은 주제를 다루는 GitLab Self-Managed 고객을 위한 강화 가이드를 제공합니다:

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

NIST 800-53 컴플라이언스

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

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

이 페이지는 GitLab Self-Managed 인스턴스가 적용 가능한 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은 ID 공급자와의 배포 및 GitLab 기본 인증 구성을 다루는 다양한 문서를 제공합니다. GitLab 인스턴스에 대한 인증 방법을 결정하기 전에 조직의 요구 사항을 고려하는 것이 중요합니다.

ID 공급자#

GitLab의 접근은 UI 또는 기존 ID 공급자와의 통합을 통해 관리할 수 있습니다. FedRAMP 요구 사항을 충족하려면 기존 ID 공급자가 FedRAMP 마켓플레이스에서 FedRAMP 승인을 받았는지 확인하세요. PIV와 같은 요구 사항을 충족하려면 GitLab Self-Managed의 기본 인증을 사용하는 대신 ID 공급자를 활용해야 합니다.

GitLab은 다음을 포함한 다양한 ID 공급자 및 프로토콜 구성을 위한 리소스를 제공합니다:

기본 GitLab 사용자 인증 구성#

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

  • Guest

  • Reporter

  • Developer

  • Maintainer

  • Owner

프로젝트 수준 권한에 대한 추가 세부 정보는 문서에서 확인할 수 있습니다. GitLab은 또한 고유한 권한 요구 사항이 있는 고객을 위한 사용자 정의 역할을 지원합니다.

GitLab은 또한 고유한 사용 사례를 위해 다음과 같은 사용자 유형을 지원합니다:

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

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

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

Admin 영역 - Admin 영역에서 관리자는 권한 내보내기, 사용자 ID 검토, 그룹 관리 등을 할 수 있습니다. FedRAMP / NIST 800-53 요구 사항을 충족하는 데 사용할 수 있는 기능:

  • 침해가 의심될 때 사용자 비밀번호 재설정.

  • 사용자 잠금 해제. 기본적으로 GitLab은 10번의 로그인 시도 실패 후 사용자를 잠급니다. 사용자는 10분 동안 잠기거나 관리자가 사용자를 잠금 해제할 때까지 잠금 상태를 유지합니다. GitLab 16.5 이상에서 관리자는 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에 접근할 수 없습니다.

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

    • 시트를 차지하지 않습니다.

추가 식별 방법#

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

  • 일회용 비밀번호 인증기

  • WebAuthn 장치

이중 인증 활성화 지침은 문서에 제공되어 있습니다. FedRAMP를 추구하는 고객은 FedRAMP 승인을 받고 FIPS 요구 사항을 지원하는 이중 인증 공급자를 고려해야 합니다. FedRAMP 승인 공급자는 FedRAMP 마켓플레이스에서 찾을 수 있습니다. 두 번째 인증 수단을 선택할 때 NIST와 FedRAMP는 이제 WebAuthn과 같은 피싱 저항 인증을 사용해야 한다고 나타내고 있습니다(IA-2).

SSH 키

  • GitLab은 Git과 인증 및 통신하기 위해 SSH 키를 구성하는 방법에 대한 지침을 제공합니다. 커밋에 서명하면 공개 키가 있는 누구에게나 추가적인 검증을 제공합니다.

  • 키는 FIPS 140-2 및 FIPS 140-3 검증된 암호 사용과 같이 적용 가능한 강도 및 복잡성 요구 사항을 충족하도록 구성해야 합니다. 관리자는 최소 키 기술 및 키 길이를 제한할 수 있습니다. 또한 GitLab은 침해된 키를 차단합니다.

개인 액세스 토큰

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

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

시스템 사용 알림

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

외부 연결

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

PIV(개인 신원 확인)

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

감사 및 책임 (AU)#

NIST 800-53은 조직이 보안 관련 이벤트를 모니터링하고, 해당 이벤트를 분석하고, 알림을 생성하고, 알림의 중요도에 따라 알림을 조사해야 한다고 요구합니다. GitLab은 보안 정보 및 이벤트 관리(SIEM) 솔루션으로 라우팅할 수 있는 광범위한 보안 이벤트를 제공합니다.

이벤트 유형#

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

로그 시스템

GitLab은 모든 것을 기록할 수 있는 고급 로그 시스템을 포함합니다. GitLab은 광범위한 출력을 포함하는 로그 유형에 대한 로그 시스템 지침을 제공합니다. 자세한 내용은 링크된 지침을 검토하세요.

이벤트 스트리밍

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

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

  • 성공 및 실패한 계정 로그온 이벤트

  • 계정 관리 이벤트

  • 객체 접근

  • 정책 변경

  • 권한 기능

  • 프로세스 추적

  • 시스템 이벤트

  • 웹 애플리케이션의 경우:

    • 모든 관리자 활동

    • 인증 확인

    • 권한 부여 확인

    • 데이터 삭제

    • 데이터 접근

    • 데이터 변경

    • 권한 변경

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

메트릭

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

스토리지

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

인시던트 대응 (IR)#

감사 이벤트가 구성되면 해당 이벤트를 모니터링해야 합니다. GitLab은 SIEM 또는 기타 보안 도구에서 시스템 알림을 컴파일하고, 알림 및 인시던트를 분류하고, 이해관계자에게 알리기 위한 중앙화된 관리 인터페이스를 제공합니다. 인시던트 관리 문서는 GitLab을 사용하여 보안 인시던트 대응 조직에서 앞서 언급한 활동을 실행하는 방법을 설명합니다.

인시던트 대응 수명 주기

GitLab은 조직의 인시던트 대응 수명 주기 전체를 관리할 수 있습니다. 인시던트 대응 요구 사항을 충족하는 데 도움이 될 수 있는 다음 리소스를 검토하세요:

구성 관리 (CM)#

변경 제어

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

이슈는 변경을 구현하기 전에 메타데이터와 승인을 캡처하기 위한 유연한 플랫폼입니다. GitLab이 구성 관리 컨트롤을 충족하는 데 어떻게 사용될 수 있는지 완전히 이해하기 위해 작업 계획 및 추적에 대한 GitLab 문서를 검토하세요.

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

변경 테스트 및 검증

CI/CD 파이프라인은 변경을 테스트하고 검증하는 중요한 컴포넌트입니다. 고객은 특정 사용 사례에 대한 충분한 테스트 및 검증 파이프라인을 구현할 책임이 있습니다. 서비스를 선택할 때 해당 파이프라인이 실행되는 위치를 고려하세요. 외부 서비스에 연결하면 연방 데이터가 저장되고 처리되도록 허용된 기존 승인 경계를 위반할 수 있습니다. GitLab은 FIPS 지원 시스템에서 실행되도록 구성된 러너 컨테이너 이미지를 제공합니다. GitLab은 보호된 브랜치 구성 방법 및 파이프라인 보안 구현을 포함한 파이프라인 강화 지침을 제공합니다. 또한 고객은 모든 검사가 통과된 후에만 코드를 업데이트할 수 있도록 코드 병합 전에 필수 검사 할당을 고려할 수 있습니다.

컴포넌트 인벤토리

NIST 800-53은 클라우드 서비스 공급자에게 컴포넌트 인벤토리를 유지하도록 요구합니다. GitLab은 기본 하드웨어를 직접 추적할 수 없지만 컨테이너 및 의존성 스캐닝을 통해 소프트웨어 인벤토리를 생성할 수 있습니다. GitLab은 컨테이너 스캐닝 및 의존성 스캐닝이 감지할 수 있는 의존성을 설명합니다. GitLab은 소프트웨어 컴포넌트 인벤토리에 사용할 수 있는 의존성 목록 생성에 관한 추가 문서를 제공합니다. 소프트웨어 자재 목록(SBOM) 지원은 이 문서의 공급망 위험 관리 아래 더 아래에 설명되어 있습니다.

컨테이너 레지스트리

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)#

계획 컨트롤 패밀리에는 정책, 절차 및 기타 제어 문서의 유지 관리가 포함됩니다. GitLab을 사용하여 제어 문서의 수명 주기를 관리하는 것을 고려하세요. 예를 들어 제어 문서는 버전 제어된 상태로 Markdown으로 저장할 수 있습니다. 문서에 대한 변경은 조직의 승인 규칙을 적용하는 머지 요청을 통해 이루어져야 합니다. 머지 요청은 제어 문서에 대한 변경 내역을 제공하며, 감사 중에 문서 소유자와 같은 적절한 담당자의 연간 검토 및 승인을 입증하는 데 사용할 수 있습니다.

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

스캐닝#

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

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

패치 관리#

GitLab은 문서에 릴리스 및 유지 관리 정책을 문서화합니다. GitLab 인스턴스를 업그레이드하기 전에 업그레이드 계획, 다운타임 없이 업그레이드 및 기타 업그레이드 경로에 도움이 될 수 있는 사용 가능한 지침을 검토하세요.

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

공급망 위험 관리 (SR)#

소프트웨어 자재 목록(SBOM)#

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

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

FIPS 컴플라이언스#

FedRAMP와 같이 NIST 800-53을 기반으로 하는 컴플라이언스 프로그램은 모든 해당 암호화 모듈에 대해 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은 다음과 같은 개념을 포함하는 러너 구성에 대한 자세한 정보를 제공합니다:

  • 최대 작업 타임아웃

  • 민감한 정보 보호

  • Long Polling 구성

  • 인증 토큰 보안 및 토큰 교체

  • 민감한 정보 노출 방지

  • 러너 변수

API 활용#

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

확장#

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

추가 리소스#

GitLab은 다음과 같은 주제를 다루는 GitLab Self-Managed 고객을 위한 강화 가이드를 제공합니다:

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