지오 보안 검토 (질문 및 답변)

Tier: 프리미엄, 얼티메이트 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는 응용 프로그램 데이터의 특정 부분을 복제하기 위해 설계되었습니다. 이것은 문제의 일부가 아니라 솔루션의 일부입니다.

최종 사용자

응용 프로그램의 최종 사용자는 누구입니까?

  • 먼거리(인터넷 지연 면에서)에 있는 지역에서 (기본 사이트)와 지역이 가까운 (인터넷 지연 면에서) 보조 사이트를 사용하려는 모든 사용자를 위해 생성됩니다. 매우 시각적이어서 경고와 필시 행동에 따라 맞추거나 제어될 수 있다.☆
  • 최종 사용자들은 주로 보조 사이트에서 주 사이트보다 더 가까운 위치를 통해 Git 리포지토리 복제하는 것이 기본적인 사용 사례로 예상되지만 최종 사용자들은 프로젝트, 이슈, 병합 요청 및 스니펫과 같은 정보를 보기 위해 GitLab 웹 인터페이스를 사용할 수 있습니다.

최종 사용자가 응용 프로그램에 대해 어떤 보안 기대를 갖고 있습니까?

  • 복제 프로세스는 안전해야 합니다. 예를 들어, 공개 인터넷을 통해 전체 데이터베이스 내용이나 모든 파일 및 리포지토리를 평문으로 전송하는 것은 일반적으로 허용되지 않을 것입니다.
  • 보조 사이트는 주 사이트의 보조 정보에 대해 동일한 액세스 제어 권한을 가져야 합니다. 따라서 인증되지 않은 사용자가 주 사이트에서 보조 사이트를 쿼리함으로써 특권 정보에 액세스하는 것을 방지해야 합니다.
  • 공격자는 보조 사이트를 통해 주 사이트로 위장할 수 없으며, 이로써 특권 정보에 액세스할 수 없도록 해야 합니다.

관리자

응용 프로그램에서 어떤 관리 기능을 제공합니까?

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

네트워크

경로 설정, 스위칭, 방화벽 및 로드 밸런싱에 관한 어떤 세부 정보가 정의되었습니까?

  • 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에도 적용됩니다. 클라우드에서의 배포는 일반적이고 지원되는 시나리오입니다.

적용 가능한 경우, 어떤 클라우드 컴퓨팅 접근 방식(Managed Hosting 대 “순수” 클라우드, AWS-EC2와 같은 “전체 머신” 방식 대 AWS-RDS 및 Azure와 같은 “호스팅된 데이터베이스” 방식 등)이 취해지나요?

  • 운영적인 요구에 따라 결정됩니다.

환경

이 응용프로그램을 만드는 데 사용된 프레임워크 및 프로그래밍 언어는 무엇입니까?

  • Ruby on Rails, Ruby.

응용프로그램을 위해 정의된 어떤 프로세스, 코드 또는 인프라 종속성이 있습니까?

  • Geo에 특정 요구 사항은 없습니다.

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

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

데이터베이스 연결 문자열, 암호화 키 및 기타 민감한 구성 요소는 어떻게 저장, 액세스되며 무단으로 탐지로부터 보호됩니까?

  • 일부 Geo별값이 있습니다. 일부는 설정 시 주 서 사이트에서 2차 서 사이트로 안전하게 전송되어야 하는 공유 비밀입니다. SSH를 통해 주 서 사이트에서 시스템 관리자로 전송하고, 마찬가지 방식으로 2차 서 사이트로 다시 보내도록 문서에서 권장합니다. 특히 이에는 PostgreSQL 복제 자격 증명과 데이터베이스의 특정 열을 복호화하는 데 사용되는 시크릿 키 (db_key_base)가 포함됩니다. db_key_base 시크릿은 다른 몇몇 시크릿과 함께 암호화되지 않은 채로 파일 시스템의 /etc/gitlab/gitlab-secrets.json에 저장됩니다. 그러한 값들에 대해 정지 상태에서의 보호는 없습니다.

데이터 처리

응용프로그램은 어떤 데이터 입력 경로를 지원합니까?

  • 데이터는 주로 GitLab 자체에서 노출된 웹 응용프로그램을 통해 입력되며, 시스템 관리 명령을 사용하여 데이터가 입력되기도 합니다(예: gitlab-ctl set-primary-node).
  • 2차 서 사이트는 또한 주 서 사이트로부터 PostgreSQL 스트리밍 복제를 통해 입력을 받습니다.

응용프로그램은 어떤 데이터 출력 경로를 지원합니까?

  • 주 서 사이트는 주로 2차 서 사이트로 PostgreSQL 스트리밍 복제를 통해 출력합니다. 이외에도 주로 GitLab 자체에서 노출된 웹 응용프로그램 및 최종 사용자에 의한 SSH ‘git clone’ 작업을 통해 출력합니다.

응용프로그램의 내부 구성 요소 간에 데이터가 어떻게 흐르나요?

  • 2차 서 사이트와 주 서 사이트는 HTTP/HTTPS( JSON 웹 토큰으로 보안됨) 및 PostgreSQL 스트리밍 복제를 통해 상호 작용합니다.
  • 주 서 사이트나 2차 서 사이트 내에서 SSOT는 파일 시스템과 데이터베이스(2차 사이트의 Geo 추적 데이터베이스 포함)입니다. 다양한 내부 구성 요소는 이러한 스토어를 변경하기 위해 조율됩니다.

데이터 입력 유효성 검사 요구 사항이 어떻게 정의되었습니까?

  • 2차 서 사이트는 주 서 사이트의 데이터를 충실하게 복제해야 합니다.

어플리케이션은 어떤 데이터를 저장하며 어떻게 저장하나요?

  • Git 저장소와 파일, 그와 관련된 추적 정보, 그리고 GitLab 데이터베이스 내용을 저장합니다.

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

  • 기본(primary) 사이트나 보조(secondary) 사이트는 정지 상태에서 Git 저장소나 파일 시스템 데이터를 암호화하지 않습니다. 일부 데이터베이스 열은 ‘db_otp_key’를 사용하여 정지 상태에서 암호화됩니다.
  • GitLab 배포 내의 모든 호스트간에 공유되는 정적 비밀번호는 데이터베이스 열의 서브셋을 정지 상태에서 암호화하는 데 사용됩니다.
  • 이동 중인 데이터는 암호화되어야 하지만, 애플리케이션은 통신이 암호화되지 않고도 계속될 수 있게 합니다. 두 주요 이동은 보조(secondary) 사이트의 PostgreSQL 복제 프로세스와 Git 저장소/파일의 이동입니다. 둘 다 기존의 Linux 패키지에 의해 관리되는 TLS를 사용하여 보호되어야 합니다.

민감한 데이터 유출을 감지하기 위해 어떤 능력이 존재하나요?

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

데이터 이동 중에 대한 암호화 요구 사항은 무엇인가요 - WAN, LAN, SecureFTP 또는 http:, https:와 같은 공개 접근 프로토콜을 통한 전송을 포함하여?

  • 데이터는 이동 중에 암호화될 수 있는 옵션을 가지고 있어야 하며, 수동 및 능동 공격에 대해 안전해야 합니다 (예: MITM 공격이 불가능해야 함).

접근

어떤 사용자 권한 레벨을 어플리케이션은 지원하나요?

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

사용자 식별 및 인증 요구 사항은 어떻게 정의되었나요?

  • 보조(secondary) 사이트는 공유 데이터베이스(HTTP 액세스)에 기반하여 Geo 기본(primary) 사이트에 OAuth 또는 JWT 인증을 합니다. 또한 데이터베이스 복제는 IP 기반 액세스 제어가 정의되어야 합니다.

사용자 승인 요구 사항은 어떻게 정의되었나요?

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

세션 관리 요구 사항은 어떻게 정의되었나요?

  • Geo JWT는 2분만 유효하며, 그 후에 새로 생성해야 합니다.
  • Geo JWT는 다음 중 하나의 특정 스코프에 대해 생성됩니다:
    • Geo API 접근.
    • Git 접근.
    • LFS 및 파일 ID.
    • 업로드 및 파일 ID.
    • 작업 아티팩트 및 파일 ID.

URI 및 서비스 호출에 대한 액세스 요구 사항은 어떻게 정의되었나요?

  • 보조(secondary) 사이트는 기본(primary) 사이트의 API에 많은 호출을 합니다. 예를 들어, 파일 복제가 진행됩니다. 이 엔드포인트는 JWT 토큰으로만 접근할 수 있습니다.
  • 기본(primary) 사이트도 상태 정보를 가져오기 위해 보조(secondary) 사이트에 호출을 합니다.

어플리케이션 모니터링

어플리케이션 감사 요구 사항은 어떻게 정의되었나요? 감사 및 디버그 로그는 어떻게 접근되며 저장되고 안전하게 되나요?

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