지오 보안 검토 (Q&A)

Tier: 프리미엄, 얼티메이트 Offering: Self-managed

Geo 기능 세트의 보안 검토는 해당 기능이 고객이 자체 GitLab 인스턴스를 실행하는 경우의 보안 측면에 중점을 둡니다. 검토 질문은 부분적으로 OWASP Application Security Verification Standard Project의 내용을 기반으로 하였습니다.

비즈니스 모델

응용 프로그램 서비스가 작동하는 지역은 어디인가요?

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

데이터 필수 요소

응용 프로그램이 수신, 생성 및 처리하는 데이터는 무엇인가요?

  • Geo는 GitLab 인스턴스에서 보유한 거의 모든 데이터를 스트리밍합니다. 이에는 전체 데이터베이스 복제, 사용자 업로드된 첨부 파일과 같은 대부분의 파일, 그리고 저장소 및 위키 데이터가 포함됩니다. 일반적인 구성에서는 이러한 작업이 공용 인터넷을 통해 TLS 암호화된 상태로 이루어집니다.
  • PostgreSQL 복제는 TLS로 암호화됩니다.
  • 추가 참조: only TLSv1.2 should be supported

어떻게 데이터의 민감도에 따라 카테고리로 분류될 수 있나요?

  • GitLab의 민감도 모델은 공개 프로젝트 대 내부 프로젝트 대 개인 프로젝트 중심입니다. Geo는 이러한 프로젝트를 무차별적으로 복제합니다. 덜 민감한 프로젝트만 Secondary 사이트로 복제할 수 있는 “선택적 동기화”가 있습니다. 이를 통해 원하는 경우 민감도가 낮은 프로젝트만 Secondary 사이트로 복제할 수 있습니다. (데이터베이스 컨텐츠는 제외)
  • 추가 참조: GitLab 데이터 분류 정책

응용 프로그램의 데이터 백업 및 보존 요구 사항은 무엇인가요?

  • Geo는 특정 응용 프로그램 데이터의 복제를 제공하도록 설계되었습니다. 이는 문제의 일부가 아니라 해결책의 일부입니다.

최종 사용자

응용 프로그램의 최종 사용자는 누구인가요?

  • Secondary 사이트는 인터넷 대역에서 떨어진 지역에 생성됩니다. 원래 Primary 사이트를 사용하는 사람들이 Secondary 사이트가 더 가까워(인터넷 대역에서)보인다고 판단하는 사람들을 위해 의도되었습니다.

최종 사용자는 응용 프로그램과 어떻게 상호 작용하나요?

  • Secondary 사이트는 모두 Primary 사이트의 인터페이스를 제공합니다(특히 HTTP/HTTPS 웹 응용 프로그램 및 HTTP/HTTPS 또는 SSH Git 저장소 액세스). 그러나 읽기 전용 활동에 제한됩니다. 주요 사용 사례는 Primary 사이트 대신 Secondary 사이트에서 Git 저장소를 복제하는 것이라고 예상되지만, 최종 사용자는 GitLab 웹 인터페이스를 사용하여 프로젝트, 이슈, 병합 요청, 그리고 스니펫과 같은 정보를 볼 수 있습니다.

최종 사용자는 어떤 보안 기대를 갖고 있나요?

  • 복제 프로세스는 안전해야 합니다. 예를 들어 공용 인터넷을 통해 전체 데이터베이스 내용이나 모든 파일 및 저장소를 평문으로 전송하는 것은 일반적으로 허용되지 않을 것입니다.
  • Secondary 사이트는 Primary 사이트보다 그에 저장된 콘텐츠에 대해 동일한 액세스 컨트롤을 가져야 합니다. 따라서 Secondary 사이트에서 Primary 사이트의 특권있는 정보에 무단으로 액세스할 수 없아야 합니다.
  • 공격자는 Secondary 사이트에서 Primary 사이트로 위장하고 특권 있는 정보에 액세스할 수 없어야 합니다.

관리자

응용 프로그램에서 관리 기능을 가진 사용자는 누구인가요?

  • Geo와 관련된 별도의 사항은 없습니다. ‘admin: true’로 설정된 모든 사용자는 슈퍼 사용자 권한을 가진 관리자로 간주됩니다.
  • 추가 참조: 보다 세분화된 액세스 제어(Geo와 관련 없음).
  • 예를 들어 데이터베이스 복제의 경우 Geo 통합의 많은 부분은 일반적으로 시스템 관리자에 의해 응용 프로그램을 통해 구성되어야 합니다.

응용 프로그램이 제공하는 관리 기능은 무엇인가요?

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

네트워크

경로 지정, 스위칭, 방화벽 및 로드 밸런싱에 관한 세부 정보는 무엇인가요?

  • Geo는 Primary 사이트와 Secondary 사이트가 TCP/IP 네트워크 상에서 서로 통신할 수 있어야 합니다. 특히 Secondary 사이트는 Primary 사이트에서 HTTP/HTTPS 및 PostgreSQL 서비스에 액세스해야 합니다.

응용 프로그램을 지원하는 핵심 네트워크 장치에 관한 세부 정보는 무엇인가요?

  • 고객마다 다릅니다.

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

  • Primary 사이트와 Secondary 사이트 간의 최대 복제 속도는 사이트 간의 사용 가능 대역폭에 의해 제한됩니다. 명시적인 요구 사항은 없으며, 복제 완료 시간 및 Primary 사이트의 변경 내용 추적 능력은 데이터 집합 크기, 지연 허용 한계 및 사용 가능한 네트워크 용량에 영향을 받습니다.

응용 프로그램을 지원하는 비공개 및 공용 네트워크 링크는 무엇인가요?

  • 고객이 자신의 네트워크를 선택할 수 있습니다. 사이트가 지리적으로 분리되어 있기 때문에 전형적인 배포에서는 복제 트래픽이 공용 인터넷을 통해 전달될 것으로 예상되지만, 이는 필수 요구사항이 아닙니다.

시스템

응용 프로그램을 지원하는 운영 체제는 무엇인가요?

  • Geo는 운영 체제에 대해 추가적인 제약사항을 부여하지 않습니다. 자세한 내용은 GitLab 설치 페이지 및 Geo 문서를 참조하시기 바랍니다.

필요한 OS 구성 요소 및 잠금 설정에 관한 세부 정보는 무엇인가요?

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

인프라 모니터링

어떤 네트워크 및 시스템 성능 모니터링 요구사항이 정의되었나요?

  • 지오에 특정하지 않음.

악성 코드 또는 손상된 애플리케이션 구성 요소를 탐지하기 위한 메커니즘이 무엇인가요?

  • 지오에 특정하지 않음.

어떤 네트워크 및 시스템 보안 모니터링 요구사항이 정의되었나요?

  • 지오에 특정하지 않음.

가상화 및 외부화

응용 프로그램의 어떤 측면이 가상화에 적합한가요?

  • 전부.

응용 프로그램을 위한 가상화 요구사항이 무엇인가요?

  • 지오와 관련된 내용은 없지만, GitLab의 모든 요소가 해당 환경에서 완전한 기능을 제공해야 합니다.

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

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

적용 가능한 경우, 클라우드 컴퓨팅 방식은 어떻게 적용되나요?

  • 이에 대한 결정은 운영 상 필요에 따라 고객이 내려야 합니다:

    • “순수” 클라우드 대신 관리형 호스팅
    • AWS-ED2와 같은 “전체 머신” 방식 대신 AWS-RDS 및 Azure와 같은 “호스팅된 데이터베이스” 방식

환경

응용 프로그램을 만드는 데 사용된 프레임워크 및 프로그래밍 언어는 무엇인가요?

  • Ruby on Rails, Ruby.

응용 프로그램에 대한 프로세스, 코드 또는 인프라 종속성이 무엇인가요?

  • 지오와 관련된 특정 내용은 없습니다.

어떤 데이터베이스 및 응용 프로그램 서버가 응용 프로그램을 지원하나요?

  • 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 스트리밍 복제를 통해 상호 작용합니다.
  • 기본 사이트 또는 보조 사이트 내에서 SSOT(System of System/application/Tool)은 파일 시스템과 데이터베이스(특히 보조 사이트의 Geo 추적 데이터베이스)입니다. 다양한 내부 구성 요소는 이러한 저장소에 변경을 가하도록 조정됩니다.

데이터 입력 유효성 검증 요구사항이 무엇인가요?

  • 보조 사이트는 기본 사이트의 데이터의 충실한 복제를 가져야 합니다.

응용 프로그램이 저장하고 있는 데이터와 저장 방법은 무엇인가요?

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

어떤 데이터가 암호화되어야 하며, 어떤 키 관리 요구사항이 정의되어 있나요?

  • 기본 사이트나 보조 사이트는 휴식 중에 Git 저장소 또는 파일 시스템 데이터를 암호화하지 않습니다. 데이터베이스 열의 하위 집합은 db_otp_key를 사용하여 휴식 중에 암호화됩니다.
  • GitLab 배포에서 모든 호스트 간에 공유되는 정적 비밀입니다.
  • 트랜지션 중에 데이터는 암호화되어야 하지만, 애플리케이션은 통신이 암호화되지 않도록 허용합니다. 두 가지 주요 트랜지션은 PostgreSQL의 보조 사이트의 복제 프로세스 및 Git 저장소/파일에 대한 것입니다. 두 가지 모두 TLS를 사용하여 보호되어야 하며, 해당 키는 GitLab에 대한 최종 사용자 액세스를 위한 기존 구성과 동일하게 Linux 패키지에 의해 관리되어야 합니다.

민감한 데이터 유출을 탐지하기 위한 능력은 무엇인가요?

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

데이터의 트랜지션을 위한 암호화 요구사항이 무엇인가요?

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

접근

응용 프로그램은 어떤 사용자 권한 수준을 지원하나요?

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

사용자 확인 및 인증 요구사항이 무엇인가요?

  • 보조 사이트는 공유 데이터베이스에 기반한 Geo 기본 사이트에 대해 OAuth 또는 JWT 인증을 사용하여 식별합니다(데이터베이스 복제의 경우 IP 기반 액세스 제어도 정의되어야 합니다).

사용자 인가 요구사항이 무엇인가요?

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

세션 관리 요구사항이 무엇인가요?

  • Geo JWT는 재생성되기 전에 2분 동안만 유지되도록 정의됩니다.
  • Geo JWT는 다음중 하나에 대해 생성됩니다:
    • Geo API 방문.
    • Git 액세스.
    • LFS 및 File ID.
    • 업로드 및 File ID.
    • 작업 아티팩트 및 File ID.

URI 및 서비스 호출에 대한 액세스 요구사항이 무엇인가요?

  • 보조 사이트는 기본 사이트의 API에 대해 많은 호출을 수행합니다. 예를 들어 파일 복제가 진행됩니다. 이 엔드포인트는 JWT 토큰으로만 액세스할 수 있습니다.
  • 기본 사이트는 또한 보조 사이트에게 상태 정보를 얻기 위해 호출을 수행합니다.

응용 프로그램 모니터링

감사 및 디버그 로그에는 어떻게 액세스하며 저장되며 보호되나요?

  • 구조화된 JSON 로그가 파일 시스템에 기록되고 Kibana 설치에 잠재적으로 분석을 위해 수집됩니다.