Geo 보안 검토(Q&A)

Tier: Premium, Ultimate Offering: Self-Managed

Geo 기능 세트의 보안 검토는 고객이 자체 GitLab 인스턴스를 실행하는 경우 해당 기능의 보안 측면에 중점을 둡니다. 본 검토 질문은 일부가 OWASP Application Security Verification Standard Project의 owasp.org에서 기반을 두고 있습니다.

비즈니스 모델

어떤 지리적 지역에서 애플리케이션 서비스가 제공되나요?

  • 이는 고객마다 다릅니다. Geo를 사용하면 여러 지역에 배포할 수 있으며, 고객이 원하는 지역을 선택할 수 있습니다.
  • 지역 및 노드 선택은 완전히 매뉴얼적입니다.

데이터 핵심 기능

애플리케이션이 어떤 데이터를 받고, 생성하며, 처리하나요?

  • Geo는 GitLab 인스턴스에서 보유한 거의 모든 데이터를 스트리밍합니다. 이에는 완전한 데이터베이스 복제, 사용자가 업로드한 첨부 파일과 리포지터리 + 위키 데이터 등이 포함됩니다. 전형적인 구성에서 이는 공개 인터넷을 통해 TLS로 암호화된 상태로 전송됩니다.
  • PostgreSQL 복제는 TLS로 암호화됩니다.
  • 또한 참조: TLSv1.2만 지원해야 함

데이터를 민감도에 따라 어떤 범주로 분류할 수 있나요?

  • GitLab의 민감도 모델은 공개 프로젝트 대 내부 프로젝트 대 개인 프로젝트 중심으로 구성되어 있습니다. Geo는 이들을 모두 구분 없이 복제합니다. “선택적 동기화” 기능이 파일 및 리포지터리(데이터베이스 콘텐츠는 제외)에 대해 제공됩니다. 이를 통해 원하는 경우 민감도가 낮은 프로젝트만 보조 사이트로 복제할 수 있습니다.
  • 또한 참조: GitLab 데이터 분류 정책.

애플리케이션에 대한 데이터 백업 및 보유 요구 사항은 어떻게 정의되었나요?

  • Geo는 특정 애플리케이션 데이터의 복제를 제공하는 데 중점을 둔 설계입니다. 이는 문제 해결의 한 부분으로 구성됩니다.

최종 사용자

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

  • 서로 떨어진 지역(인터넷 지연 관점에서)에 있는 주 GitLab 설치(주 사이트)에서 더 가까운 위치(인터넷 지연 관점에서)에 있는 보조 사이트에 보조 사이트를 생성하고 사용하는 것이 의도되어 있습니다.

최종 사용자가 애플리케이션과 상호 작용하는 방법은 무엇인가요?

  • 보조 사이트는 주 사이트와 동일한 인터페이스를 제공합니다 (주목할 만한 것으로는 HTTP/HTTPS 웹 애플리케이션 및 HTTP/HTTPS 또는 SSH Git 리포지터리 액세스가 포함됨)이지만 읽기 전용 활동에 제한됩니다. 주로 사용 사례는 주 사이트 대신 보조 사이트에서 Git 리포지터리를 복제하는 것이지만 최종 사용자는 GitLab 웹 인터페이스를 사용하여 프로젝트, 이슈, Merge Request 및 스니펫과 같은 정보를 보는 데 사용할 수 있습니다.

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

  • 복제 프로세스는 안전해야 합니다. 예를 들어 공개 인터넷을 통해 전체 데이터베이스 내용이나 모든 파일과 리포지터리를 일반 텍스트로 전송하는 것은 일반적으로 허용되지 않을 것입니다.
  • 보조 사이트는 주 사이트와 동일한 콘텐츠에 대한 액세스 제어를 가져야 합니다. 인증되지 않은 사용자는 보조 사이트를 쿼리함으로써 주 사이트에서 권한이 있는 정보에 액세스해서는 안됩니다.
  • 공격자는 보조 사이트를 이용하여 주 사이트로 가장하고 이를 통해 권한이 있는 정보에 액세스해서는 안됩니다.

관리자

애플리케이션에서 관리 기능을 가진 사용자는 누구인가요?

  • Geo 특정 사항은 없습니다. 데이터베이스에서 admin: true로 설정된 모든 사용자는 슈퍼 사용자 권한을 가진 관리자로 간주됩니다.
  • 또한 참조: 더 세분화된 액세스 제어 (Geo에 특정되지는 않음).
  • Geo의 통합 일부 (데이터베이스 복제 등)는 일반적으로 시스템 관리자에 의해 애플리케이션과 구성되어야 합니다.

애플리케이션이 제공하는 관리 기능은 무엇인가요?

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

네트워크

라우팅, 스위칭, 방화벽 및 로드 밸런싱에 대한 어떤 세부 정보가 정의되었나요?

  • Geo는 주 사이트와 보조 사이트 간에 TCP/IP 네트워크를 통해 통신할 수 있어야 합니다. 특히 보조 사이트는 주 사이트에서 HTTP/HTTPS 및 PostgreSQL 서비스에 액세스할 수 있어야 합니다.

애플리케이션을 지원하는 핵심 네트워크 장치에 대한 어떤 정보가 있나요?

  • 고객에 따라 다릅니다.

네트워크 성능 요구 사항은 무엇인가요?

  • 주 사이트와 보조 사이트 간의 최대 복제 속도는 사이트 간의 사용 가능 대역폭에 의해 제한됩니다. 엄격한 요구 사항은 없으며, 복제 완료 시간(및 주 사이트에서의 변경 사항 추적 능력)은 데이터 집합 크기, 지연에 대한 허용, 및 사용 가능한 네트워크 용량의 함수입니다.

애플리케이션을 지원하는 개인 및 공용 네트워크 링크에 대한 어떤 정보가 있나요?

  • 고객이 자체 네트워크를 선택합니다. 사이트가 지리적으로 분리되도록 의도되었으므로 전형적인 배포에서 복제 트래픽은 공개 인터넷을 통해 전달되지만, 이는 필수 요구 사항은 아닙니다.

시스템

애플리케이션을 지원하는 운영 체제는 무엇인가요?

  • Geo는 운영 체제에 추가 제한을 두지 않습니다(추가 GitLab 설치 페이지에서 자세한 내용을 확인하세요). 그러나 운영 체제 설명서에 나열된 운영 체제를 사용하는 것을 권장합니다.(Geo 문서 확인).

필요한 운영 체제 컴포넌트 및 록다운 요구 사항에 대한 세부 정보는 무엇인가요?

  • 지원되는 Linux 패키지 설치 방법은 대부분의 컴포넌트를 자체적으로 패키징합니다.
  • 시스템 설치된 OpenSSH 데몬에 중요한 의존성이 있습니다(Geo는 사용자가 사용자 지정 인증 방법을 설정하도록 요구하며 Linux 패키지 제공 또는 시스템 제공 PostgreSQL 데몬을 필요로 합니다(이는 TCP 상에서 수신하도록 구성, 추가 사용자 및 복제 슬롯을 추가해야 합니다).
  • 보안 업데이트 처리 절차(예: OpenSSH 또는 기타 서비스에 중대한 취약점이 있을 경우 고객이 해당 서비스를 패치하려는 경우)는 Geo 상황과 비상황을 동일합니다: OpenSSH의 보안 업데이트가 사용자에게 표준 배포 채널을 통해 제공됩니다. Geo는 여기에 지연을 추가하지 않습니다.

인프라 모니터링

네트워크 및 시스템 성능 모니터링 요구 사항은 무엇인가요?

  • Geo에 구체적인 요구 사항은 없습니다.

악성 코드 또는 침해된 애플리케이션 컴포넌트를 탐지하는 메커니즘은 무엇인가요?

  • Geo에 구체적인 메커니즘은 없습니다.

네트워크 및 시스템 보안 모니터링 요구 사항은 무엇인가요?

  • Geo에 구체적인 요구 사항은 없습니다.

가상화 및 외부화

애플리케이션의 어떤 측면이 가상화에 적합한가요?

  • 모든 측면이 적합합니다.

애플리케이션에 대한 가상화 요구 사항은 무엇인가요?

  • Geo에 구체적인 요구 사항은 없지만 GitLab의 모든 것은 그러한 환경에서 완전한 기능을 갖추어야 합니다.

제품의 어떤 측면이 클라우드 컴퓨팅 모델을 통해 호스팅될 수 있고 그렇지 않을 수 있나요?

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

필요한 경우 클라우드 컴퓨팅 방식(관리 호스팅 대 “순수” 클라우드, AWS-EC2와 같은 “전체 기계” 방식 대 AWS-RDS 및 Azure와 같은 “호스팅된 데이터베이스” 방식 등)은 어떻게 적용되나요?

  • 운영 상황을 고려하여 고객이 결정합니다.

환경

어떤 프레임워크와 프로그래밍 언어가 애플리케이션 생성에 사용되었나요?

  • Ruby on Rails, Ruby.

애플리케이션을 위해 정의된 프로세스, 코드 또는 인프라 의존성은 무엇인가요?

  • Geo와 관련된 구체적인 사항은 없습니다.

어떤 데이터베이스와 응용 프로그램 서버가 해당 응용 프로그램을 지원합니까?

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

데이터베이스 연결 문자열, 암호화 키 및 기타 민감한 컴포넌트는 어떻게 저장, 접근 및 무단 감지로부터 보호됩니까?

  • 지리적으로 특정한 값들이 있습니다. 일부는 설정 시 주 사이트에서 보조 사이트로 안전하게 전송되어야 하는 공유 비밀입니다. 저희 문서는 그들을 주 사이트에서 시스템 관리자에게 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 추적 데이터베이스)입니다. 다양한 내부 컴포넌트는 이러한 리포지터리를 수정하기 위해 조정됩니다.

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

  • 보조 사이트는 주 사이트의 데이터를 정확하게 복제해야 합니다.

응용 프로그램이 저장하거나 저장해야 하는 데이터는 무엇이며 어떻게 저장합니까?

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

어떤 데이터가 암호화되어야 할지이며 정의된 키 관리 요구 사항은 무엇입니까?

  • 주 사이트나 보조 사이트 둘 다 데이터 저장 시 Git 리포지터리 또는 파일 시스템 데이터를 암호화하지 않습니다. 데이터베이스의 일부 컬럼은 db_otp_key를 사용하여 정지 저장 보호되어야 합니다.
  • GitLab 배포 내의 모든 호스트에서 공유되는 정적 비밀입니다.
  • 전송 중에는 데이터를 암호화해야 하지만 응용 프로그램은 통신이 암호화되지 않은 채로 진행되도록 허용합니다. 두 가지 주요 전송 방법은 보조 사이트의 PostgreSQL 복제 처리, 그리고 Git 리포지터리/파일의 경우입니다. 이 두 가지는 TLS를 사용하여 보호되어야 하며 그 키는 사용자가 GitLab에 액세스할 때의 기존 설정에 따라 Linux 패키지로 관리됩니다.

민감한 데이터 누출을 감지하기 위한 기능은 무엇입니까?

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

데이터 이동에 대한 암호화 요구 사항은 무엇입니까(네트워크 전송, 로컬 전송, SecureFTP 또는 http: 및 https:와 같은 공개 액세스 프로토콜을 포함하여)?

  • 데이터는 전송 중에 암호화될 수 있어야 하며 매뉴얼 및 적극적 공격에 대해 안전해야 합니다(예: MITM 공격 불가능해야 함).

액세스

해당 응용 프로그램이 지원하는 사용자 권한 수준은 무엇입니까?

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

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

  • 보조 사이트는 공유 데이터베이스(HTTP 액세스) 또는 PostgreSQL 복제 사용자(데이터베이스 복제)를 기반으로 Geo 주 사이트를 식별하기 위해 OAuth 또는 JWT 인증을 사용합니다. 데이터베이스 복제에는 IP 기반 액세스 제어도 정의되어야 합니다.

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

  • 보조 사이트는 데이터를 읽기만 할 수 있어야 합니다. 현재 주 사이트에서 데이터를 변경할 수 없습니다.

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

  • Geo JWT는 2분간만 유효한 것으로 정의되어야 합니다.
  • Geo JWT는 다음 중 하나의 특정 범위를 위해 생성됩니다:
    • Geo API 액세스.
    • Git 액세스.
    • LFS 및 파일 ID.
    • 업로드 및 파일 ID.
    • 작업 아티팩트 및 파일 ID.

URI 및 서비스 호출에 대한 액세스 요구 사항이 정의되었습니까?

  • 보조 사이트는 주 사이트의 API에 많은 호출을 수행합니다. 예를 들어, 파일 복제가 진행되는 방식입니다. 이 엔드포인트는 JWT 토큰으로만 액세스 가능합니다.
  • 주 사이트도 보조 사이트에 상태 정보를 가져오기 위해 호출을 수행합니다.

응용 프로그램 모니터링

정의된 응용 프로그램 감사 요구 사항이 무엇이며 감사 및 디버그 로그는 어떻게 접근, 저장 및 보호됩니까?

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