지리 보안 검토 (Q&A)

Tier: Premium, Ultimate Offering: Self-managed

다음 보안 리뷰는 고객이 자체 GitLab 인스턴스를 실행할 때의 기능에 적용되는 보안 측면에 중점을 두고 지리 기능 세트를 검토합니다. 리뷰 질문은 부분적으로 OWASP 응용 프로그램 보안 검증 표준 프로젝트를 기반으로 하며, owasp.org에서 제공합니다.

비즈니스 모델

애플리케이션 서비스가 제공하는 지리적 영역은 어디인가요?

  • 이는 고객에 따라 다릅니다. Geo는 고객이 여러 지역에 배포할 수 있도록 하며, 고객이 원하는 지역을 선택할 수 있습니다.
  • 지역 및 노드 선택은 전적으로 수동입니다.

데이터 필수 사항

애플리케이션이 수신, 생성 및 처리하는 데이터는 무엇인가요?

  • Geo는 사이트 간에 GitLab 인스턴스에서 보유하는 거의 모든 데이터를 스트리밍합니다. 여기에는 전체 데이터베이스 복제, 사용자 업로드 파일과 같은 대부분의 파일, 그리고 레포지토리 + 위키 데이터가 포함됩니다. 일반적인 구성에서는 공개 인터넷을 통해 발생하며 TLS로 암호화됩니다.
  • PostgreSQL 복제는 TLS로 암호화됩니다.
  • 또한 참조하세요: 오직 TLSv1.2만 지원되어야 함

데이터의 민감도에 따라 카테고리로 분류할 수 있는 방법은 무엇인가요?

  • GitLab의 민감도 모델은 공개 프로젝트, 내부 프로젝트, 개인 프로젝트에 중점을 둡니다. Geo는 이를 모두 차별 없이 복제합니다. “선택적 동기화”는 파일과 레포지토리(하지만 데이터베이스 내용은 아님)에 존재하며, 이를 통해 원할 경우 민감도가 낮은 프로젝트만 부가 사이트로 복제할 수 있습니다.
  • 또한 참조하세요: GitLab 데이터 분류 정책.

애플리케이션에 대해 정의된 데이터 백업 및 보존 요구 사항은 무엇인가요?

  • Geo는 애플리케이션 데이터의 특정 하위 집합을 복제하기 위해 설계되었습니다. 이는 문제의 일부가 아니라 솔루션의 일부분입니다.

최종 사용자

애플리케이션의 최종 사용자는 누구인가요?

  • 부가 사이트는 주요 GitLab 설치(즉, 주요 사이트)와 인터넷 지연 시간 상으로 먼 지역에서 생성됩니다. 이들은 일반적으로 주요 사이트를 이용할 사용자를 위해 마련되어 있으며, 이들은 부가 사이트가 자신에게 더 가깝다고 느낍니다(인터넷 지연 시간 기준).

최종 사용자는 애플리케이션과 어떻게 상호작용하나요?

  • 부가 사이트는 주요 사이트가 제공하는 모든 인터페이스를 제공합니다(특히 HTTP/HTTPS 웹 애플리케이션 및 HTTP/HTTPS 또는 SSH Git 저장소 액세스). 하지만 읽기 전용 활동으로 제한됩니다. 주요 사용 사례는 부가 사이트에서 Git 레포지토리를 클론하는 것으로 구상되지만, 최종 사용자는 GitLab 웹 인터페이스를 사용하여 프로젝트, 이슈, 병합 요청 및 스니펫과 같은 정보를 확인할 수 있습니다.

최종 사용자가 기대하는 보안 요건은 무엇인가요?

  • 복제 과정은 안전해야 합니다. 예를 들어 전체 데이터베이스 내용이나 모든 파일 및 레포지토리를 공개 인터넷을 통해 평문으로 전송하는 것은 일반적으로 용납될 수 없습니다.
  • 부가 사이트는 주요 사이트와 동일한 콘텐츠 접근 제어를 가져야 합니다. 인증되지 않은 사용자는 부가 사이트를 쿼리하여 주요 사이트의 특권 정보에 접근할 수 없어야 합니다.
  • 공격자는 부가 사이트를 주요 사이트로 가장하여 특권 정보에 접근할 수 없어야 합니다.

관리자

애플리케이션에서 누가 관리자 기능을 가지고 있습니까?

  • Geo와 관련된 특정 사항은 없습니다. 데이터베이스에 admin: true로 설정된 모든 사용자는 슈퍼 사용자 권한을 가진 관리자입니다.
  • 더 자세한 내용은 더 세분화된 접근 제어를 참조하세요.
  • Geo 통합의 많은 부분(예: 데이터베이스 복제)은 일반적으로 시스템 관리자가 애플리케이션과 함께 구성해야 합니다.

애플리케이션은 어떤 관리자 기능을 제공합니까?

  • Secondary 사이트는 관리자 접근 권한을 가진 사용자가 추가, 수정 또는 제거할 수 있습니다.
  • 복제 프로세스는 Sidekiq 관리 제어를 통해 제어(시작/중지)할 수 있습니다.

네트워크

라우팅, 스위칭, 방화벽 및 로드 밸런싱과 관련하여 정의된 세부 사항은 무엇입니까?

  • Geo는 primary 사이트와 secondary 사이트가 TCP/IP 네트워크를 통해 서로 통신할 수 있어야 합니다. 특히, secondary 사이트는 primary 사이트의 HTTP/HTTPS 및 PostgreSQL 서비스에 접근할 수 있어야 합니다.

애플리케이션을 지원하는 핵심 네트워크 장치는 무엇입니까?

  • 고객마다 다릅니다.

어떤 네트워크 성능 요구 사항이 존재합니까?

  • primary 사이트와 secondary 사이트 간의 최대 복제 속도는 사이트 간의 사용 가능한 대역폭에 의해 제한됩니다. 강력한 요구 사항은 없으며, 복제를 완료하는 시간(및 primary 사이트의 변경 사항에 따라 유지할 수 있는 능력)은 데이터 세트의 크기, 지연 허용 범위 및 사용 가능한 네트워크 용량의 함수입니다.

애플리케이션을 지원하는 개인 및 공용 네트워크 링크는 무엇입니까?

  • 고객은 자신만의 네트워크를 선택합니다. 사이트가 지리적으로 분리되어 있도록 설계되었기 때문에 일반적인 배포에서는 복제 트래픽이 공용 인터넷을 통해 발생할 것으로 예상되지만, 이는 필수 사항은 아닙니다.

시스템

애플리케이션을 지원하는 운영 체제는 무엇입니까?

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

필요 OS 구성 요소 및 보안 요구 사항에 대한 세부 사항은 무엇입니까?

  • 지원되는 Linux 패키지 설치 방법은 대부분의 구성 요소를 자체적으로 패키징합니다.
  • 시스템에 설치된 OpenSSH 데몬(사용자가 커스텀 인증 방법을 설정해야 함)과 Linux 패키지 제공 또는 시스템 제공 PostgreSQL 데몬에 대한 의존성이 큽니다(이를 TCP에서 수신 대기하도록 구성해야 하며, 추가 사용자와 복제 슬롯을 추가해야 함)를 참고하십시오.
  • 보안 업데이트 처리 과정(예: OpenSSH 또는 기타 서비스에 중대한 취약점이 발생하고 고객이 OS에서 이러한 서비스를 패치하고자 하는 경우)은 비-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에 특정한 값이 있습니다. 일부는 설정 시간에 primary 사이트에서 secondary 사이트로 안전하게 전송되어야 하는 공유 비밀입니다. 우리의 문서에서는 primary 사이트에서 시스템 관리자에게 SSH를 통해 전송한 다음, 같은 방식으로 secondary 사이트로 다시 전송하는 것을 권장합니다. 특히, 여기에는 PostgreSQL 복제 자격 증명 및 데이터베이스의 특정 열을 해독하는 데 사용되는 비밀 키(db_key_base)가 포함됩니다. db_key_base 비밀은 파일 시스템에 암호화되지 않은 상태로 저장되며, /etc/gitlab/gitlab-secrets.json에 여러 비밀과 함께 저장됩니다. 이들에 대한 저장 시 보호는 없습니다.

데이터 처리

애플리케이션이 지원하는 데이터 입력 경로는 무엇입니까?

  • 데이터는 GitLab 자체에서 노출된 웹 애플리케이션을 통해 입력됩니다. 일부 데이터는 GitLab 서버에서 시스템 관리 명령을 사용하여 입력됩니다(예: gitlab-ctl set-primary-node).

  • Secondary 사이트는 또한 primary 사이트에서 PostgreSQL 스트리밍 복사를 통해 입력을 받습니다.

애플리케이션이 지원하는 데이터 출력 경로는 무엇입니까?

  • Primary 사이트는 PostgreSQL 스트리밍 복사를 통해 secondary 사이트로 출력을 보냅니다. 그렇지 않으면 주로 GitLab 자체에서 노출된 웹 애플리케이션 및 최종 사용자가 시작한 SSH git clone 작업을 통해 출력됩니다.

애플리케이션의 내부 구성 요소 간 데이터 흐름은 어떻게 됩니까?

  • Secondary 사이트와 primary 사이트는 HTTP/HTTPS( JSON 웹 토큰으로 보호됨) 및 PostgreSQL 스트리밍 복사를 통해 상호 작용합니다.

  • primary 사이트나 secondary 사이트 내에서는 SSOT가 파일 시스템과 데이터베이스( secondary 사이트의 Geo 추적 데이터베이스 포함)입니다. 다양한 내부 구성 요소가 이러한 저장소에 변경 사항을 만들기 위해 조정됩니다.

정의된 데이터 입력 유효성 검사 요구 사항은 무엇입니까?

  • Secondary 사이트는 primary 사이트의 데이터에 대한 충실한 복제가 필요합니다.

애플리케이션이 저장하는 데이터는 무엇이며 어떻게 저장됩니까?

  • Git 리포지토리와 파일, 이와 관련된 추적 정보, 그리고 GitLab 데이터베이스 내용입니다.

무엇을 암호화해야 합니까? 정의된 키 관리 요구 사항은 무엇입니까?

  • Primary 사이트 및 secondary 사이트는 Git 리포지토리 또는 파일 시스템 데이터를 저장 시 암호화하지 않습니다. 데이터베이스 열의 일부는 db_otp_key를 사용하여 저장 시 암호화됩니다.

  • GitLab 배포의 모든 호스트에서 공유되는 정적 비밀입니다.

  • 전송 중에는 데이터가 암호화되어야 하지만 애플리케이션에서는 비암호화된 상태에서 통신이 진행되는 것을 허용합니다. 두 가지 주요 전송 경로는 secondary 사이트의 PostgreSQL 복제 프로세스와 Git 리포지토리/파일입니다. 두 가지 모두 TLS를 사용하여 보호되어야 하며, 키는 GitLab에 대한 최종 사용자 접근을 위한 기존 구성에 따라 Linux 패키지에서 관리됩니다.

민감한 데이터 유출을 감지하기 위한 기능은 무엇이 있습니까?

  • GitLab 및 PostgreSQL에 대한 모든 연결을 추적하는 포괄적인 시스템 로그가 존재합니다.

전송 중 데이터에 대해 어떤 암호화 요구 사항이 정의되었습니까?

  • (이는 WAN, LAN, SecureFTP, 또는 http: 및 https:와 같은 공개적으로 접근 가능한 프로토콜을 통한 전송을 포함합니다.)
  • 데이터는 전송 중 암호화 옵션을 가져야 하며, 수동 공격과 능동 공격(예: MITM 공격에 대한 방어)이 모두 안전해야 합니다.

접근

응용 프로그램은 어떤 사용자 권한 수준을 지원합니까?

  • Geo는 한 가지 유형의 권한을 추가합니다: secondary 사이트는 HTTP/HTTPS를 통해 파일을 다운로드하고 HTTP/HTTPS를 사용하여 리포지토리를 복제할 수 있는 특수 Geo API에 액세스할 수 있습니다.

사용자 식별 및 인증 요구 사항은 무엇이 정의되었습니까?

  • Secondary 사이트는 공유 데이터베이스(HTTP 액세스) 또는 PostgreSQL 복제 사용자(데이터베이스 복제)를 기반으로 OAuth 또는 JWT 인증을 통해 Geo primary 사이트를 식별합니다. 데이터베이스 복제는 IP 기반 접근 제어 정의도 필요합니다.

사용자 권한 부여 요구 사항은 무엇이 정의되었습니까?

  • Secondary 사이트는 데이터에 대해 읽기만 할 수 있어야 합니다. Primary 사이트의 데이터를 변경할 수 없습니다.

세션 관리 요구 사항은 무엇이 정의되었습니까?

  • Geo JWT는 재생성이 필요하기 전에 단 2분 동안만 지속되도록 정의됩니다.
  • Geo JWT는 다음 특정 범위 중 하나에 대해 생성됩니다:
    • Geo API 액세스.
    • Git 액세스.
    • LFS 및 파일 ID.
    • 업로드 및 파일 ID.
    • 작업 아티팩트 및 파일 ID.

URI 및 서비스 호출에 대한 접근 요구 사항은 무엇이 정의되었습니까?

  • Secondary 사이트는 primary 사이트의 API에 많은 호출을 합니다. 이렇게 파일 복제가 진행됩니다. 이 엔드포인트는 JWT 토큰으로만 접근할 수 있습니다.
  • Primary 사이트는 상태 정보를 얻기 위해 secondary 사이트에 호출을 합니다.

응용 프로그램 모니터링

감사 및 디버그 로그는 어떻게 접근하고, 저장하며, 보호됩니까?

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