markdown # 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은 애플리케이션 개발에 보안이 통합되어야 하는 것을 요구합니다. GitLab을 사용하여 CI/CD 파이프라인을 구성하여 코드를 지속적으로 테스트하고 동시에 보안 정책을 강제할 수 있습니다. GitLab에는 고객 애플리케이션 개발에 통합할 수 있는 일련의 보안 도구가 포함되어 있으며, 다음과 같습니다.

CI/CD 파이프라인 이외에도 GitLab은 릴리스 구성 방법에 대해 자세한 지침을 제공합니다. 릴리스는 CI/CD 파이프라인을 사용하여 저장소의 어떤 브랜치에서든 스냅샷을 찍을 수 있습니다. 릴리스 생성에 대한 지침은 릴리스 생성에 포함되어 있습니다. NIST 800-53 또는 FedRAMP 규정 준수에 중요한 고려 사항은 릴리스된 코드가 코드의 진정성을 검증하고 시스템 및 정보 무결성 (SI) 컨트롤 패밀리의 요구 사항을 충족시킬 수 있도록 서명되어야 할 수도 있다는 것입니다.

액세스 제어 (AC) 및 식별 및 인증 (IA)

GitLab 배포에서의 액세스 관리는 각 고객마다 독특합니다. GitLab은 식별 공급자와 GitLab 기본 인증 구성에 대한 문서 범위를 제공합니다. GitLab 인스턴스에 대해 인증 접근 방식을 결정하기 전에 기관 요구 사항을 고려하는 것이 중요합니다.

식별 공급자

GitLab 내에서 액세스는 UI를 통해 또는 기존 식별 공급자와 통합하여 관리할 수 있습니다. FedRAMP 요구 사항을 충족시키기 위해 현재의 식별 공급자가 FedRAMP 마켓플레이스에서 FedRAMP 승인을 받았는지 확인해야 합니다. PIV와 같은 요구 사항을 충족하기 위해서는 자체 관리 GitLab에서 기본 인증을 사용하는 대신 식별 공급자를 활용해야 합니다.

GitLab은 다양한 식별 공급자 및 프로토콜 설정에 대해 리소스를 제공하며, 다음을 포함합니다.

기본 GitLab 사용자 인증 구성

계정 관리 및 분류 - GitLab은 관리자에게 사용자를 추적하고 다양한 민감도와 액세스 요구 사항을 가진 사용자를 관리할 수 있는 권한을 부여합니다. GitLab은 프로젝트 수준에서 다음과 같은 역할을 지원합니다.

  • 게스트
  • 기고자
  • 개발자
  • 유지 관리자
  • 소유자

프로젝트 수준 권한에 대한 자세한 내용은 프로젝트 레벨 권한에서 문서에서 찾을 수 있습니다. GitLab은 고유한 권한 요구 사항을 가지는 고객을 위해 사용자 정의 역할을 지원합니다.

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

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

  • 외부 사용자 - 외부 사용자는 조직의 일부가 아닌 사용자에게 제한된 액세스를 제공할 수 있습니다. 일반적으로 이는 계약자 또는 기타 제3자의 액세스를 관리하기 위해 사용됩니다. IA-4(4)와 같은 규제에서 비조직적 사용자는 회사 정책에 따라 식별 및 관리되어야 하므로 외부 사용자 설정은 기본적으로 조직의 액세스를 제한함으로써 조직의 위험을 줄이고 사용자가 어떤 사용자가 조직에 취업하지 않는지 식별하는 것을 보조할 수 있습니다.

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

관리자 영역 - 관리자 영역에서 관리자는 권한 내보내기, 사용자 ID 검토, 그룹 관리 등을 수행할 수 있습니다. FedRAMP / NIST 800-53 요구 사항을 충족시키기 위해 사용할 수 있는 기능은 다음과 같습니다.

추가 식별 방법

이중 인증 - GitLab은 다음과 같은 두 번째 인증 요소를 지원합니다:

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

  • WebAuthN 장치

이중 인증을 활성화하는 방법에 대한 지침은 문서에서 제공됩니다. FedRAMP를 추구하는 고객은 FedRAMP 승인을 받은 이중 인증 공급 업체와 FIPS 요구 사항을 지원하는 곳을 고려해야 합니다. FedRAMP 승인을 받은 공급 업체는 FedRAMP 마켓 플레이스에서 찾을 수 있습니다. 두 번째 인증 요소를 선택할 때 NIST 및 FedRAMP가 이제 WebAuthN과 같은 피싱 방지 인증이 사용되어야 한다는 점이 중요합니다 (IA-2).

SSH 키

개인 액세스 토큰

FIPS 활성화된 인스턴스에서는 사용자 액세스용 개인 액세스 토큰이 기본적으로 비활성화되어 있습니다.

기타 액세스 제어 패밀리 개념

시스템 사용 알림

연방 요구 사항은 종종 로그인 시 배너가 필요하다고 명시합니다. 이는 ID 공급자를 통해 구성될 수 있으며 GitLab 배너 기능을 통해 구성될 수도 있습니다.

외부 연결

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

개인 식별 확인 (PIV)

개인 식별 확인 카드는 연방 요구 사항을 준수해야 하는 기관에 필요할 수 있습니다. PIV 요구 사항을 충족하기 위해 GitLab은 고객이 PIV를 사용 가능하게 하는 ID 솔루션을 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 기능을 활용하여 작업 계획 및 추적을 어떻게 사용하여 구성 관리 요구 사항을 충족시킬 수 있는지 자세히 검토하세요.

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

변경의 테스트 및 확인

CI/CD 파이프라인은 변경을 테스트하고 확인하는 데 중요한 구성 요소입니다. 서비스 선택 시 그 파이프라인이 어디에서 실행될지 고려해야 합니다. 외부 서비스에 연결하는 것은 연방 데이터가 저장 및 처리될 수 있는 허가된 권한 경계를 위반할 수 있습니다. GitLab은 FIPS 활성화 시스템에서 실행되도록 구성된 러너 컨테이너 이미지를 제공합니다. GitLab은 보호된 브랜치를 구성하는 방법 및 파이프라인 보안을 구현하는 방법을 포함한 파이프라인을 위한 견고한 가이드를 제공합니다. 또한, 고객은 코드 변경 병합 전에 필요한 확인을 할당하여 코드 업데이트 전에 모든 확인 사항이 통과되었음을 확인할 수 있도록 할 수 있습니다.

구성 요소 인벤토리

NIST 800-53은 클라우드 서비스 공급 업체가 구성 요소 인벤토리를 유지하도록 요구합니다. GitLab은 직접 하드웨어를 추적할 수는 없지만, 컨테이너 및 종속성 스캔을 통해 소프트웨어 인벤토리를 생성할 수 있습니다. GitLab은 컨테이너 및 종속성 스캔이 감지할 수 있는 종속성에 대한 문서를 개요화하고 있습니다. 목록 작성을 위한 추가 문서를 제공하고 있으며, 이는 소프트웨어 구성 요소 인벤토리에 사용할 수 있습니다. 소프트웨어 부품 목록 지원은 본 문서 하단에서 공급망 리스크 관리 항목에서 자세히 다루고 있습니다.

컨테이너 레지스트리

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

Contingency Planning (CP)

GitLab은 핵심 대비 계획 요구 사항을 충족시킬 수 있는 지침과 서비스를 제공합니다. 조직의 대비 계획 활동 요구 사항을 충족시키기 위해 포함된 문서를 검토하고 그에 맞게 계획을 수립하는 것이 중요합니다. 대비 계획은 각 조직마다 고유하기 때문에 계획을 수립하기 전에 조직의 요구 사항을 고려하는 것이 중요합니다.

GitLab 아키텍처 선택

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

GitLab은 참조 아키텍처 및 가용성 모델 선택을 지원하기 위한 의사 결정 트리를 제공합니다. 대부분의 클라우드 서비스 제공업체는 관리 서비스의 한 지역 내에서 신뢰성을 제공합니다. 아키텍처를 선택할 때 조직의 다운 타임에 대한 허용 한도와 데이터의 중요성을 고려하는 것이 중요합니다. GitLab Geo를 추가 복제 및 장애 조치 기능으로 고려할 수 있습니다.

중요 자산 식별

NIST 800-53은 중요 자산을 식별하여 장애 상황에서 그들의 우선 복구를 보장하는 것을 요구합니다. 고려해야 할 중요 자산은 Gitaly 노드 및 PostgreSQL 데이터베이스입니다. 고객은 적절한 경우 추가 백업이나 복제가 필요한 추가 자산을 식별해야 합니다.

백업

GitLab 문서는 중요 구성 요소에 대한 백업 전략을 설명합니다. 이에는 다음이 포함됩니다:

GitLab Geo

GitLab Geo는 NIST 800-53을 준수하기 위한 모든 구현의 중요한 구성 요소로 간주될 수 있습니다. 각 유스 케이스에 맞게 Geo가 적절하게 구성되었는지 확인하려면 사용 가능한 문서를 검토하는 것이 중요합니다.

Geo를 구현하면 다음과 같은 이점이 제공됩니다:

  • 분산된 개발자들이 큰 저장소 및 프로젝트를 복제하고 가져오는 데 소요되는 시간을 분에서 초로 줄일 수 있습니다.

  • 지역 간에 병렬로 아이디어를 제시하고 작업할 수 있습니다.

  • 기본 및 보조 사이트 간의 읽기 전용 부하를 균형있게 분산할 수 있습니다.

  • 웹 인터페이스에서 사용 가능한 모든 데이터를 읽는 데 사용될 뿐만 아니라 프로젝트를 복제하고 가져오는 데 사용될 수 있습니다. (제한 사항 참조)

  • 먼 사무실 간의 느린 연결을 극복하여 분산된 팀의 속도를 향상시킴으로써 시간을 절약합니다.

  • 자동화된 작업, 사용자 정의 통합 및 내부 워크플로우의 로딩 시간을 줄이는 데 도움이 됩니다.

  • 재해 복구 시나리오에서 보조 사이트로 빠르게 실패를 전환할 수 있습니다.

  • 계획된 보조 사이트로의 장애 조치를 허용합니다.

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

  • 읽기 전용 보조 사이트: 기본 GitLab 사이트를 유지하면서 분산된 팀에 대한 읽기 전용 보조 사이트를 계속 유지할 수 있습니다.

  • 인증 시스템 후크: 보조 사이트는 주요 인스턴스로부터 모든 인증 데이터(사용자 계정 및 로그인과 같은)를 받습니다.

  • 직관적인 UI: 후보 사이트는 기본 사이트와 동일한 웹 인터페이스를 사용합니다. 또한 쓰기 작업을 차단하고 사용자가 보조 사이트에 있는지 명확히하는 시각적인 알림이 있습니다.

추가 Geo 리소스:

PostgreSQL

GitLab은 복제와 장애 조치가 구성된 PostgreSQL 클러스터를 어떻게 구성하는지에 대한 지침을 제공합니다. GitLab 인스턴스의 데이터 중요성 및 최대 허용 다운타임에 따라 PostgreSQL을 복제 및 장애 조치가 활성화된 상태로 구성하는 것을 고려해야 합니다.

Gitaly

Gitaly를 구성할 때 가용성, 복구 가능성 및 탄력성 사이의 교환 관계를 고려해야 합니다. GitLab은 NIST 800-53 요구 사항을 충족시키기 위한 올바른 구성을 결정하는 데 도움이 될 것으로 예상되는 Gitaly 기능에 대한 포괄적인 문서를 제공합니다.

Planning (PL)

계획 통제 모음은 정책, 절차 및 기타 통제 문서의 유지를 포함합니다. GitLab을 활용하여 통제 문서의 라이프사이클을 관리하는 것을 고려해 보세요. 예를 들어, 통제 문서는 Markdown으로 버전 관리 상태로 저장될 수 있습니다. 문서의 모든 변경은 merge 요청을 통해 이루어져야 하며, 이를 통해 조직의 승인 규칙이 강제됩니다. Merge 요청은 통제 문서에 대한 변경 내역을 명확히 보여주며, 이는 감사에서 사용하여 매년 재검토 및 적절한 인원(문서 소유자 등)에 의한 승인을 시연하는 데 사용할 수 있습니다.

Risk Assessment and System and Information Integrity (RA)

스캔

NIST 800-53은 취약성 및 결함 개선을 위한 지속적인 모니터링을 요구합니다. 인프라 스캔에 추가하여 FedRAMP와 같은 준수 프레임워크는 월간 보고 요구 사항으로 컨테이너 및 DAST 스캔을 범위로 정하고 있습니다. GitLab은 컨테이너 스캔을 지원할 수 있는 보안 도구를 제공합니다. 이에는 Trivy 및 Grype 스캐너가 포함됩니다. 또한 GitLab은 의존성 스캔 기능을 제공합니다. GitLab에서 동적 응용 프로그램 보안 테스트(DAST)는 실행 중인 웹 응용 프로그램에 대한 취약성 보고서를 생성하기 위해 파이프라인에서 구성될 수 있습니다.

응용 프로그램 코드를 안전하게 보호하고 관리하기 위해 사용될 수 있는 추가적인 보안 기능은 다음과 같습니다:

패치 관리

GitLab은 설명서에서 릴리스 및 유지 관리 정책을 문서화합니다. GitLab 인스턴스를 업그레이드하기 전에 업그레이드를 계획하고 다운타임 없이 업그레이드하고 다른 업그레이드 경로를 지원할 수 있는 사용 가능한 지침을 검토하십시오.

보안 대시 보드를 구성하여 취약성 데이터를 시간별로 추적할 수 있으며, 이를 사용하여 취약성 관리 프로그램의 추세를 식별할 수 있습니다.

공급망 리스크 관리 (SR)

소프트웨어 부품 목록

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 배포에서도 다양한 작업 및 도구에 대해 러너가 필요합니다. 데이터 경계 요구 사항을 유지하기 위해 고객은 권한 경계에 self-managed 러너를 배포할 필요가 있을 수 있습니다. GitLab은 러너 구성 방법에 대해 자세한 정보를 제공하며, 이는 다음과 같은 개념을 포함합니다:

  • 최대 작업 시간 초과

  • 민감한 정보 보호

  • 롱 폴링 구성

  • 인증 토큰 보안 및 토큰 로테이션

  • 민감한 정보 노출 방지

  • 러너 변수

API 활용

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

확장 기능

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

추가 리소스

GitLab은 self-managed 고객을 위한 견고한 가이드를 제공하는데, 이는 다음과 같은 주제에 대해 다룹니다:

GitLab CIS 벤치마크 가이드 - GitLab은 CIS 벤치마크를 게시하여 NIST 800-53 컨트롤에 따라 환경을 견고히 하는 데 도움이 될 수 있습니다. CIS 벤치마크의 모든 제안이 직접 NIST 800-53 컨트롤과 일치하는 것은 아니지만, GitLab 인스턴스를 유지하는 최선의 방법으로 기능합니다.