InfoGrab DocsInfoGrab Docs

Geo 보안 검토(Q&A)

요약

다음은 Geo 기능 모음에 대한 보안 검토이며, 자체 GitLab 인스턴스를 운영하는 고객에게 적용되는 보안 측면을 중심으로 다룹니다. 다음 방식의 사용 여부는 운영 요구에 따라 고객이 결정합니다.

다음은 Geo 기능 모음에 대한 보안 검토이며, 자체 GitLab 인스턴스를 운영하는 고객에게 적용되는 보안 측면을 중심으로 다룹니다. 검토 질문은 일부 owasp.org의 OWASP Application Security Verification Standard Project를 기반으로 합니다.

비즈니스 모델#

애플리케이션이 서비스를 제공하는 지리적 영역#

  • 고객마다 다릅니다. Geo를 사용하면 고객이 여러 지역에 배포할 수 있으며, 어느 지역에 배포할지는 고객이 선택합니다.
  • 리전과 노드 선택은 전적으로 수동입니다.

데이터 필수 요소#

애플리케이션이 수신, 생성, 처리하는 데이터#

  • Geo는 GitLab 인스턴스가 보유한 거의 모든 데이터를 사이트 사이로 스트리밍합니다. 여기에는 전체 데이터베이스 복제, 사용자가 업로드한 첨부 파일 같은 대부분의 파일, 리포지터리 및 위키 데이터가 포함됩니다. 일반적인 구성에서는 이 통신이 공용 인터넷을 거치며 TLS로 암호화됩니다.
  • PostgreSQL 복제는 TLS로 암호화됩니다.
  • 관련 내용: TLSv1.2만 지원해야 합니다

민감도에 따른 데이터 분류 방식#

  • GitLab의 민감도 모델은 공개, 내부, 비공개 프로젝트 구분을 중심으로 합니다. Geo는 이를 구분 없이 모두 복제합니다. 파일과 리포지터리에 대해서는 "선택적 동기화"가 제공되며(데이터베이스 콘텐츠에는 제공되지 않습니다), 필요하다면 민감도가 낮은 프로젝트만 보조 사이트로 복제할 수 있습니다.

애플리케이션에 정의된 데이터 백업 및 보존 요구 사항#

  • Geo는 애플리케이션 데이터의 일부 집합을 복제하도록 설계되었습니다. 문제의 일부가 아니라 해결책의 일부입니다.

최종 사용자#

애플리케이션의 최종 사용자#

  • 보조 사이트는 메인 GitLab 설치(기본 사이트)에서 인터넷 지연 시간 기준으로 멀리 떨어진 리전에 생성합니다. 보조 사이트는 평소 기본 사이트를 사용하는 사용자 가운데 인터넷 지연 시간 기준으로 보조 사이트가 자신에게 더 가깝다고 판단하는 사용자를 위한 것입니다.

최종 사용자와 애플리케이션의 상호 작용 방식#

  • 보조 사이트는 기본 사이트가 제공하는 모든 인터페이스 (특히 HTTP/HTTPS 웹 애플리케이션, HTTP/HTTPS 또는 SSH Git 리포지터리 접근)를 제공하지만 읽기 전용 작업으로 제한됩니다. 주된 사용 사례는 기본 사이트 대신 보조 사이트에서 Git 리포지터리를 복제하는 것이지만, 최종 사용자는 GitLab 웹 인터페이스로 프로젝트, 이슈, 머지 리퀘스트, 스니펫 같은 정보를 볼 수도 있습니다.

최종 사용자의 보안 기대치#

  • 복제 과정은 안전해야 합니다. 예를 들어 전체 데이터베이스 내용이나 모든 파일과 리포지터리를 공용 인터넷으로 평문 전송하는 것은 일반적으로 받아들일 수 없습니다.
  • 보조 사이트는 기본 사이트와 동일한 콘텐츠 접근 제어를 갖춰야 합니다. 인증되지 않은 사용자가 보조 사이트에 질의하여 기본 사이트의 권한 있는 정보에 접근할 수 있어서는 안 됩니다.
  • 공격자가 기본 사이트에 대해 보조 사이트를 사칭하여 권한 있는 정보에 접근할 수 있어서는 안 됩니다.

관리자#

애플리케이션에서 관리 권한을 가진 주체#

  • Geo에만 해당하는 내용은 없습니다. 데이터베이스에서 admin: true가 설정된 사용자는 슈퍼유저 권한을 가진 관리자로 간주됩니다.
  • 관련 내용: 더 세분화된 접근 제어 (Geo에만 해당하는 내용은 아닙니다).
  • 데이터베이스 복제를 비롯한 Geo 통합의 상당 부분은 애플리케이션에서 구성해야 하며, 보통 시스템 관리자가 수행합니다.

애플리케이션이 제공하는 관리 기능#

  • 관리자 접근 권한이 있는 사용자는 보조 사이트를 추가, 수정, 제거할 수 있습니다.
  • 복제 과정은 Sidekiq 관리 컨트롤로 제어(시작/중지)할 수 있습니다.

네트워크#

라우팅, 스위칭, 방화벽, 로드 밸런싱에 관해 정의된 세부 사항#

  • Geo는 기본 사이트와 보조 사이트가 TCP/IP 네트워크로 서로 통신할 수 있어야 합니다. 특히 보조 사이트는 기본 사이트의 HTTP/HTTPS 서비스와 PostgreSQL 서비스에 접근할 수 있어야 합니다.

애플리케이션을 지원하는 핵심 네트워크 장치#

  • 고객마다 다릅니다.

네트워크 성능 요구 사항#

  • 기본 사이트와 보조 사이트 사이의 최대 복제 속도는 사이트 간 가용 대역폭에 따라 제한됩니다. 엄격한 요구 사항은 없으며, 복제 완료 시간 (그리고 기본 사이트의 변경을 따라잡는 능력)은 데이터 집합의 크기, 허용 가능한 지연 시간, 가용 네트워크 용량에 따라 결정됩니다.

애플리케이션을 지원하는 사설 및 공용 네트워크 링크#

  • 고객이 직접 네트워크를 선택합니다. 사이트는 지리적으로 분리되도록 설계되었으므로, 일반적인 배포에서는 복제 트래픽이 공용 인터넷을 거칠 것으로 예상되지만 반드시 그래야 하는 것은 아닙니다.

시스템#

애플리케이션을 지원하는 운영 체제#

  • Geo는 운영 체제에 추가 제약을 두지 않습니다(자세한 내용은 GitLab 설치 페이지를 참고합니다). 다만 Geo 문서에 나열된 운영 체제 사용을 권장합니다.

필요한 OS 구성 요소 및 잠금 요건에 관해 정의된 세부 사항#

  • 지원되는 Linux 패키지 설치 방식은 대부분의 구성 요소를 직접 패키징합니다.
  • 시스템에 설치된 OpenSSH 데몬(Geo는 사용자가 사용자 지정 인증 방식을 설정하도록 요구합니다)과 Linux 패키지 또는 시스템이 제공하는 PostgreSQL 데몬 (TCP를 수신하도록 구성해야 하고, 추가 사용자와 복제 슬롯을 추가해야 하는 등)에 대한 의존성이 상당합니다.
  • 보안 업데이트를 처리하는 절차(예를 들어 OpenSSH나 다른 서비스에 중대한 취약점이 있어 고객이 운영 체제에서 해당 서비스를 패치하려는 경우)는 Geo를 사용하지 않는 상황과 동일합니다. OpenSSH 보안 업데이트는 평소의 배포 채널로 사용자에게 제공됩니다. Geo는 여기에 지연을 더하지 않습니다.

인프라 모니터링#

정의된 네트워크 및 시스템 성능 모니터링 요구 사항#

  • Geo에만 해당하는 내용은 없습니다.

악성 코드 및 손상된 애플리케이션 구성 요소 탐지 메커니즘#

  • Geo에만 해당하는 내용은 없습니다.

정의된 네트워크 및 시스템 보안 모니터링 요구 사항#

  • Geo에만 해당하는 내용은 없습니다.

가상화 및 외부화#

가상화에 적합한 애플리케이션 영역#

  • 전부입니다.

애플리케이션에 정의된 가상화 요구 사항#

  • Geo에만 해당하는 내용은 없지만, GitLab의 모든 기능이 그러한 환경에서 온전히 동작해야 합니다.

클라우드 컴퓨팅 모델로 호스팅할 수 있는 제품 영역과 그렇지 않은 영역#

  • GitLab은 "클라우드 네이티브"이며, 이는 제품의 다른 영역과 마찬가지로 Geo에도 적용됩니다. 클라우드 배포는 일반적이며 지원되는 시나리오입니다.

해당하는 경우의 클라우드 컴퓨팅 접근 방식#

  • 다음 방식의 사용 여부는 운영 요구에 따라 고객이 결정합니다.

    • 관리형 호스팅과 "순수" 클라우드
    • AWS-ED2 같은 "전체 머신" 방식과 AWS-RDS, Azure 같은 "호스팅형 데이터베이스" 방식

환경#

애플리케이션 구현에 사용된 프레임워크와 프로그래밍 언어#

  • Ruby on Rails, Ruby.

애플리케이션에 정의된 프로세스, 코드, 인프라 의존성#

  • Geo에만 해당하는 내용은 없습니다.

애플리케이션을 지원하는 데이터베이스와 애플리케이션 서버#

  • PostgreSQL >= 12, Redis, Sidekiq, Puma.

데이터베이스 연결 문자열, 암호화 키, 기타 민감한 구성 요소 보호 방법#

  • Geo에만 해당하는 값이 일부 있습니다. 그중 일부는 설정 시점에 기본 사이트에서 보조 사이트로 안전하게 전달해야 하는 공유 시크릿입니다. GitLab 문서는 이 값을 기본 사이트에서 SSH로 시스템 관리자에게 전달하고, 같은 방식으로 다시 보조 사이트로 전달할 것을 권장합니다. 여기에는 특히 PostgreSQL 복제 자격 증명과 데이터베이스의 특정 칼럼을 복호화하는 데 사용하는 시크릿 키(db_key_base)가 포함됩니다. db_key_base 시크릿은 다른 여러 시크릿과 함께 /etc/gitlab/gitlab-secrets.json에 암호화되지 않은 상태로 파일 시스템에 저장됩니다. 저장 상태에 대한 보호는 없습니다.

데이터 처리#

애플리케이션이 지원하는 데이터 입력 경로#

  • 데이터는 GitLab이 제공하는 웹 애플리케이션으로 입력됩니다. 일부 데이터는 GitLab 서버의 시스템 관리 명령(예를 들어 gitlab-ctl set-primary-node)으로도 입력됩니다.
  • 보조 사이트는 기본 사이트에서 오는 PostgreSQL 스트리밍 복제로도 입력을 받습니다.

애플리케이션이 지원하는 데이터 출력 경로#

  • 기본 사이트는 PostgreSQL 스트리밍 복제로 보조 사이트에 출력합니다. 그 밖에는 주로 GitLab이 제공하는 웹 애플리케이션과 최종 사용자가 시작하는 SSH git clone 작업으로 출력합니다.

애플리케이션 내부 구성 요소 간 데이터 흐름#

  • 보조 사이트와 기본 사이트는 HTTP/HTTPS(JSON 웹 토큰으로 보호)와 PostgreSQL 스트리밍 복제로 상호 작용합니다.
  • 기본 사이트나 보조 사이트 내부에서는 파일 시스템과 데이터베이스 (보조 사이트의 Geo 추적 데이터베이스 포함)가 단일 진실 공급원(Single Source Of Truth, SSOT)입니다. 여러 내부 구성 요소가 이 저장소를 변경하도록 조율됩니다.

정의된 데이터 입력 검증 요구 사항#

  • 보조 사이트는 기본 사이트 데이터를 그대로 복제해야 합니다.

애플리케이션이 저장하는 데이터와 저장 방식#

  • Git 리포지터리와 파일, 이에 관련된 추적 정보, GitLab 데이터베이스 콘텐츠입니다.

암호화 대상 데이터 및 정의된 키 관리 요구 사항#

  • 기본 사이트와 보조 사이트 모두 Git 리포지터리나 파일 시스템 데이터를 저장 상태에서 암호화하지 않습니다. 데이터베이스 칼럼 중 일부는 db_otp_key로 저장 상태에서 암호화됩니다.
  • GitLab 배포의 모든 호스트가 공유하는 정적 시크릿입니다.
  • 전송 중 데이터는 암호화해야 하지만, 애플리케이션은 암호화하지 않은 통신도 허용합니다. 주요 전송 구간은 보조 사이트의 PostgreSQL 복제 과정과 Git 리포지터리·파일 전송 두 가지입니다. 두 구간 모두 TLS로 보호해야 하며, 해당 키는 최종 사용자의 GitLab 접근을 위한 기존 구성에 따라 Linux 패키지가 관리합니다.

민감한 데이터 유출 탐지 기능#

  • GitLab과 PostgreSQL에 대한 모든 연결을 추적하는 포괄적인 시스템 로그가 있습니다.

전송 중 데이터에 정의된 암호화 요구 사항#

  • (여기에는 WAN, LAN, SecureFTP 또는 http:와 https: 같은 공개 접근 가능 프로토콜을 통한 전송이 포함됩니다.)
  • 데이터는 전송 중 암호화를 선택할 수 있어야 하며, 수동 공격과 능동 공격 모두에 안전해야 합니다(예를 들어 MITM 공격이 가능해서는 안 됩니다).

액세스#

애플리케이션이 지원하는 사용자 권한 수준#

  • Geo는 한 가지 권한 유형을 추가합니다. 보조 사이트는 전용 Geo API에 접근하여 HTTP/HTTPS로 파일을 내려받고 HTTP/HTTPS로 리포지터리를 복제할 수 있습니다.

정의된 사용자 식별 및 인증 요구 사항#

  • 보조 사이트는 공유 데이터베이스 기반의 OAuth 또는 JWT 인증(HTTP 접근)이나 PostgreSQL 복제 사용자(데이터베이스 복제)로 Geo 기본 사이트에 자신을 식별합니다. 데이터베이스 복제에는 IP 기반 접근 제어도 정의해야 합니다.

정의된 사용자 권한 부여 요구 사항#

  • 보조 사이트는 데이터를 읽을 수만 있어야 합니다. 기본 사이트의 데이터를 변경할 수 없습니다.

정의된 세션 관리 요구 사항#

  • Geo JWT는 재생성이 필요할 때까지 2분 동안만 유효하도록 정의되어 있습니다.
  • Geo JWT는 다음 특정 범위 중 하나로 생성됩니다.
    • Geo API 접근.
    • Git 접근.
    • LFS 및 File ID.
    • Upload 및 File ID.
    • Job Artifact 및 File ID.

URI 및 서비스 호출에 정의된 액세스 요구 사항#

  • 보조 사이트는 기본 사이트의 API를 여러 번 호출합니다. 예를 들어 파일 복제가 이렇게 진행됩니다. 이 엔드포인트는 JWT 토큰으로만 접근할 수 있습니다.
  • 기본 사이트도 상태 정보를 얻기 위해 보조 사이트를 호출합니다.

애플리케이션 모니터링#

감사 및 디버그 로그의 액세스, 저장, 보호 방식#

  • 구조화된 JSON 로그가 파일 시스템에 기록되며, 추가 분석을 위해 Kibana 설치로 수집할 수도 있습니다.

Geo 보안 검토(Q&A)

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

요약

다음은 Geo 기능 모음에 대한 보안 검토이며, 자체 GitLab 인스턴스를 운영하는 고객에게 적용되는 보안 측면을 중심으로 다룹니다. 다음 방식의 사용 여부는 운영 요구에 따라 고객이 결정합니다.

다음은 Geo 기능 모음에 대한 보안 검토이며, 자체 GitLab 인스턴스를 운영하는 고객에게 적용되는 보안 측면을 중심으로 다룹니다. 검토 질문은 일부 owasp.org의 OWASP Application Security Verification Standard Project를 기반으로 합니다.

비즈니스 모델#

애플리케이션이 서비스를 제공하는 지리적 영역#

  • 고객마다 다릅니다. Geo를 사용하면 고객이 여러 지역에 배포할 수 있으며, 어느 지역에 배포할지는 고객이 선택합니다.
  • 리전과 노드 선택은 전적으로 수동입니다.

데이터 필수 요소#

애플리케이션이 수신, 생성, 처리하는 데이터#

  • Geo는 GitLab 인스턴스가 보유한 거의 모든 데이터를 사이트 사이로 스트리밍합니다. 여기에는 전체 데이터베이스 복제, 사용자가 업로드한 첨부 파일 같은 대부분의 파일, 리포지터리 및 위키 데이터가 포함됩니다. 일반적인 구성에서는 이 통신이 공용 인터넷을 거치며 TLS로 암호화됩니다.
  • PostgreSQL 복제는 TLS로 암호화됩니다.
  • 관련 내용: TLSv1.2만 지원해야 합니다

민감도에 따른 데이터 분류 방식#

  • GitLab의 민감도 모델은 공개, 내부, 비공개 프로젝트 구분을 중심으로 합니다. Geo는 이를 구분 없이 모두 복제합니다. 파일과 리포지터리에 대해서는 "선택적 동기화"가 제공되며(데이터베이스 콘텐츠에는 제공되지 않습니다), 필요하다면 민감도가 낮은 프로젝트만 보조 사이트로 복제할 수 있습니다.

애플리케이션에 정의된 데이터 백업 및 보존 요구 사항#

  • Geo는 애플리케이션 데이터의 일부 집합을 복제하도록 설계되었습니다. 문제의 일부가 아니라 해결책의 일부입니다.

최종 사용자#

애플리케이션의 최종 사용자#

  • 보조 사이트는 메인 GitLab 설치(기본 사이트)에서 인터넷 지연 시간 기준으로 멀리 떨어진 리전에 생성합니다. 보조 사이트는 평소 기본 사이트를 사용하는 사용자 가운데 인터넷 지연 시간 기준으로 보조 사이트가 자신에게 더 가깝다고 판단하는 사용자를 위한 것입니다.

최종 사용자와 애플리케이션의 상호 작용 방식#

  • 보조 사이트는 기본 사이트가 제공하는 모든 인터페이스 (특히 HTTP/HTTPS 웹 애플리케이션, HTTP/HTTPS 또는 SSH Git 리포지터리 접근)를 제공하지만 읽기 전용 작업으로 제한됩니다. 주된 사용 사례는 기본 사이트 대신 보조 사이트에서 Git 리포지터리를 복제하는 것이지만, 최종 사용자는 GitLab 웹 인터페이스로 프로젝트, 이슈, 머지 리퀘스트, 스니펫 같은 정보를 볼 수도 있습니다.

최종 사용자의 보안 기대치#

  • 복제 과정은 안전해야 합니다. 예를 들어 전체 데이터베이스 내용이나 모든 파일과 리포지터리를 공용 인터넷으로 평문 전송하는 것은 일반적으로 받아들일 수 없습니다.
  • 보조 사이트는 기본 사이트와 동일한 콘텐츠 접근 제어를 갖춰야 합니다. 인증되지 않은 사용자가 보조 사이트에 질의하여 기본 사이트의 권한 있는 정보에 접근할 수 있어서는 안 됩니다.
  • 공격자가 기본 사이트에 대해 보조 사이트를 사칭하여 권한 있는 정보에 접근할 수 있어서는 안 됩니다.

관리자#

애플리케이션에서 관리 권한을 가진 주체#

  • Geo에만 해당하는 내용은 없습니다. 데이터베이스에서 admin: true가 설정된 사용자는 슈퍼유저 권한을 가진 관리자로 간주됩니다.
  • 관련 내용: 더 세분화된 접근 제어 (Geo에만 해당하는 내용은 아닙니다).
  • 데이터베이스 복제를 비롯한 Geo 통합의 상당 부분은 애플리케이션에서 구성해야 하며, 보통 시스템 관리자가 수행합니다.

애플리케이션이 제공하는 관리 기능#

  • 관리자 접근 권한이 있는 사용자는 보조 사이트를 추가, 수정, 제거할 수 있습니다.
  • 복제 과정은 Sidekiq 관리 컨트롤로 제어(시작/중지)할 수 있습니다.

네트워크#

라우팅, 스위칭, 방화벽, 로드 밸런싱에 관해 정의된 세부 사항#

  • Geo는 기본 사이트와 보조 사이트가 TCP/IP 네트워크로 서로 통신할 수 있어야 합니다. 특히 보조 사이트는 기본 사이트의 HTTP/HTTPS 서비스와 PostgreSQL 서비스에 접근할 수 있어야 합니다.

애플리케이션을 지원하는 핵심 네트워크 장치#

  • 고객마다 다릅니다.

네트워크 성능 요구 사항#

  • 기본 사이트와 보조 사이트 사이의 최대 복제 속도는 사이트 간 가용 대역폭에 따라 제한됩니다. 엄격한 요구 사항은 없으며, 복제 완료 시간 (그리고 기본 사이트의 변경을 따라잡는 능력)은 데이터 집합의 크기, 허용 가능한 지연 시간, 가용 네트워크 용량에 따라 결정됩니다.

애플리케이션을 지원하는 사설 및 공용 네트워크 링크#

  • 고객이 직접 네트워크를 선택합니다. 사이트는 지리적으로 분리되도록 설계되었으므로, 일반적인 배포에서는 복제 트래픽이 공용 인터넷을 거칠 것으로 예상되지만 반드시 그래야 하는 것은 아닙니다.

시스템#

애플리케이션을 지원하는 운영 체제#

  • Geo는 운영 체제에 추가 제약을 두지 않습니다(자세한 내용은 GitLab 설치 페이지를 참고합니다). 다만 Geo 문서에 나열된 운영 체제 사용을 권장합니다.

필요한 OS 구성 요소 및 잠금 요건에 관해 정의된 세부 사항#

  • 지원되는 Linux 패키지 설치 방식은 대부분의 구성 요소를 직접 패키징합니다.
  • 시스템에 설치된 OpenSSH 데몬(Geo는 사용자가 사용자 지정 인증 방식을 설정하도록 요구합니다)과 Linux 패키지 또는 시스템이 제공하는 PostgreSQL 데몬 (TCP를 수신하도록 구성해야 하고, 추가 사용자와 복제 슬롯을 추가해야 하는 등)에 대한 의존성이 상당합니다.
  • 보안 업데이트를 처리하는 절차(예를 들어 OpenSSH나 다른 서비스에 중대한 취약점이 있어 고객이 운영 체제에서 해당 서비스를 패치하려는 경우)는 Geo를 사용하지 않는 상황과 동일합니다. OpenSSH 보안 업데이트는 평소의 배포 채널로 사용자에게 제공됩니다. Geo는 여기에 지연을 더하지 않습니다.

인프라 모니터링#

정의된 네트워크 및 시스템 성능 모니터링 요구 사항#

  • Geo에만 해당하는 내용은 없습니다.

악성 코드 및 손상된 애플리케이션 구성 요소 탐지 메커니즘#

  • Geo에만 해당하는 내용은 없습니다.

정의된 네트워크 및 시스템 보안 모니터링 요구 사항#

  • Geo에만 해당하는 내용은 없습니다.

가상화 및 외부화#

가상화에 적합한 애플리케이션 영역#

  • 전부입니다.

애플리케이션에 정의된 가상화 요구 사항#

  • Geo에만 해당하는 내용은 없지만, GitLab의 모든 기능이 그러한 환경에서 온전히 동작해야 합니다.

클라우드 컴퓨팅 모델로 호스팅할 수 있는 제품 영역과 그렇지 않은 영역#

  • GitLab은 "클라우드 네이티브"이며, 이는 제품의 다른 영역과 마찬가지로 Geo에도 적용됩니다. 클라우드 배포는 일반적이며 지원되는 시나리오입니다.

해당하는 경우의 클라우드 컴퓨팅 접근 방식#

  • 다음 방식의 사용 여부는 운영 요구에 따라 고객이 결정합니다.

    • 관리형 호스팅과 "순수" 클라우드
    • AWS-ED2 같은 "전체 머신" 방식과 AWS-RDS, Azure 같은 "호스팅형 데이터베이스" 방식

환경#

애플리케이션 구현에 사용된 프레임워크와 프로그래밍 언어#

  • Ruby on Rails, Ruby.

애플리케이션에 정의된 프로세스, 코드, 인프라 의존성#

  • Geo에만 해당하는 내용은 없습니다.

애플리케이션을 지원하는 데이터베이스와 애플리케이션 서버#

  • PostgreSQL >= 12, Redis, Sidekiq, Puma.

데이터베이스 연결 문자열, 암호화 키, 기타 민감한 구성 요소 보호 방법#

  • Geo에만 해당하는 값이 일부 있습니다. 그중 일부는 설정 시점에 기본 사이트에서 보조 사이트로 안전하게 전달해야 하는 공유 시크릿입니다. GitLab 문서는 이 값을 기본 사이트에서 SSH로 시스템 관리자에게 전달하고, 같은 방식으로 다시 보조 사이트로 전달할 것을 권장합니다. 여기에는 특히 PostgreSQL 복제 자격 증명과 데이터베이스의 특정 칼럼을 복호화하는 데 사용하는 시크릿 키(db_key_base)가 포함됩니다. db_key_base 시크릿은 다른 여러 시크릿과 함께 /etc/gitlab/gitlab-secrets.json에 암호화되지 않은 상태로 파일 시스템에 저장됩니다. 저장 상태에 대한 보호는 없습니다.

데이터 처리#

애플리케이션이 지원하는 데이터 입력 경로#

  • 데이터는 GitLab이 제공하는 웹 애플리케이션으로 입력됩니다. 일부 데이터는 GitLab 서버의 시스템 관리 명령(예를 들어 gitlab-ctl set-primary-node)으로도 입력됩니다.
  • 보조 사이트는 기본 사이트에서 오는 PostgreSQL 스트리밍 복제로도 입력을 받습니다.

애플리케이션이 지원하는 데이터 출력 경로#

  • 기본 사이트는 PostgreSQL 스트리밍 복제로 보조 사이트에 출력합니다. 그 밖에는 주로 GitLab이 제공하는 웹 애플리케이션과 최종 사용자가 시작하는 SSH git clone 작업으로 출력합니다.

애플리케이션 내부 구성 요소 간 데이터 흐름#

  • 보조 사이트와 기본 사이트는 HTTP/HTTPS(JSON 웹 토큰으로 보호)와 PostgreSQL 스트리밍 복제로 상호 작용합니다.
  • 기본 사이트나 보조 사이트 내부에서는 파일 시스템과 데이터베이스 (보조 사이트의 Geo 추적 데이터베이스 포함)가 단일 진실 공급원(Single Source Of Truth, SSOT)입니다. 여러 내부 구성 요소가 이 저장소를 변경하도록 조율됩니다.

정의된 데이터 입력 검증 요구 사항#

  • 보조 사이트는 기본 사이트 데이터를 그대로 복제해야 합니다.

애플리케이션이 저장하는 데이터와 저장 방식#

  • Git 리포지터리와 파일, 이에 관련된 추적 정보, GitLab 데이터베이스 콘텐츠입니다.

암호화 대상 데이터 및 정의된 키 관리 요구 사항#

  • 기본 사이트와 보조 사이트 모두 Git 리포지터리나 파일 시스템 데이터를 저장 상태에서 암호화하지 않습니다. 데이터베이스 칼럼 중 일부는 db_otp_key로 저장 상태에서 암호화됩니다.
  • GitLab 배포의 모든 호스트가 공유하는 정적 시크릿입니다.
  • 전송 중 데이터는 암호화해야 하지만, 애플리케이션은 암호화하지 않은 통신도 허용합니다. 주요 전송 구간은 보조 사이트의 PostgreSQL 복제 과정과 Git 리포지터리·파일 전송 두 가지입니다. 두 구간 모두 TLS로 보호해야 하며, 해당 키는 최종 사용자의 GitLab 접근을 위한 기존 구성에 따라 Linux 패키지가 관리합니다.

민감한 데이터 유출 탐지 기능#

  • GitLab과 PostgreSQL에 대한 모든 연결을 추적하는 포괄적인 시스템 로그가 있습니다.

전송 중 데이터에 정의된 암호화 요구 사항#

  • (여기에는 WAN, LAN, SecureFTP 또는 http:와 https: 같은 공개 접근 가능 프로토콜을 통한 전송이 포함됩니다.)
  • 데이터는 전송 중 암호화를 선택할 수 있어야 하며, 수동 공격과 능동 공격 모두에 안전해야 합니다(예를 들어 MITM 공격이 가능해서는 안 됩니다).

액세스#

애플리케이션이 지원하는 사용자 권한 수준#

  • Geo는 한 가지 권한 유형을 추가합니다. 보조 사이트는 전용 Geo API에 접근하여 HTTP/HTTPS로 파일을 내려받고 HTTP/HTTPS로 리포지터리를 복제할 수 있습니다.

정의된 사용자 식별 및 인증 요구 사항#

  • 보조 사이트는 공유 데이터베이스 기반의 OAuth 또는 JWT 인증(HTTP 접근)이나 PostgreSQL 복제 사용자(데이터베이스 복제)로 Geo 기본 사이트에 자신을 식별합니다. 데이터베이스 복제에는 IP 기반 접근 제어도 정의해야 합니다.

정의된 사용자 권한 부여 요구 사항#

  • 보조 사이트는 데이터를 읽을 수만 있어야 합니다. 기본 사이트의 데이터를 변경할 수 없습니다.

정의된 세션 관리 요구 사항#

  • Geo JWT는 재생성이 필요할 때까지 2분 동안만 유효하도록 정의되어 있습니다.
  • Geo JWT는 다음 특정 범위 중 하나로 생성됩니다.
    • Geo API 접근.
    • Git 접근.
    • LFS 및 File ID.
    • Upload 및 File ID.
    • Job Artifact 및 File ID.

URI 및 서비스 호출에 정의된 액세스 요구 사항#

  • 보조 사이트는 기본 사이트의 API를 여러 번 호출합니다. 예를 들어 파일 복제가 이렇게 진행됩니다. 이 엔드포인트는 JWT 토큰으로만 접근할 수 있습니다.
  • 기본 사이트도 상태 정보를 얻기 위해 보조 사이트를 호출합니다.

애플리케이션 모니터링#

감사 및 디버그 로그의 액세스, 저장, 보호 방식#

  • 구조화된 JSON 로그가 파일 시스템에 기록되며, 추가 분석을 위해 Kibana 설치로 수집할 수도 있습니다.