Geo 보안 검토 (Q&A)

Tier: Premium, Ultimate Offering: Self-managed

Geo 기능 세트의 보안 검토는 고객이 자체 GitLab 인스턴스를 실행하는 경우 해당 기능의 보안 측면에 중점을 둡니다. 검토 질문은 일부가 OWASP 애플리케이션 보안 검증 표준 프로젝트의 owasp.org에서 기반을 두고 있습니다.

비즈니스 모델

응용 프로그램 서비스가 대상인 지리적 영역은 무엇입니까?

  • 고객별로 다릅니다. Geo를 사용하면 여러 영역으로 배포할 수 있으며 고객이 지정할 수 있습니다.
  • 지역 및 노드 선택은 완전 매뉴얼적입니다.

데이터 핵심 기능

응용 프로그램이 수신, 생성 및 처리하는 데이터는 무엇입니까?

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

데이터를 민감도에 따라 분류하는 데 어떻게 할 수 있습니까?

  • GitLab의 민감도 모델은 공개 프로젝트 대 내부 프로젝트 대 비공개 프로젝트 중심입니다. Geo는 모든 데이터를 구분 없이 복제합니다. “선택적 동기화”는 파일 및 리포지터리(데이터베이스 내용 제외)에 대해 존재하여 덜 민감한 프로젝트만 보조 사이트로 복제하도록 허용합니다.
  • 또한 확인: GitLab 데이터 분류 정책.

응용 프로그램에 대한 데이터 백업 및 보존 요구 사항은 무엇입니까?

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

최종 사용자

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

  • 먼 거리(인터넷 대기 시간 측면에서)에 있는 지역에 보조 사이트가 생성되며, 일반적으로 주 사이트를 사용하는 사람이 해당 보조 사이트가 그들에게 가까운 경우 사용할 수 있도록 의도되었습니다.

최종 사용자는 어떻게 응용 프로그램과 상호 작용합니까?

  • 보조 사이트는 주요 사이트와 동일한 모든 인터페이스를 제공합니다(주로 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 문서의 운영 체제에서 지원되는 운영 체제를 참조하십시오.

필요한 OS 컴포넌트 및 잠금 필요 사항에 대한 세부 정보는 무엇입니까?

  • 지원되는 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.

데이터베이스 연결 문자열, 암호화 키 및 기타 민감한 컴포넌트는 어떻게 저장, 액세스 및 무단 감지로부터 보호되나요?

  • 일부 Geo에 특정한 값이 있습니다. 일부는 설정 시 프라이머리 사이트에서 세컨더리 사이트로 안전하게 전송되어야 하는 공유 비밀입니다. 문서에서는 이를 프라이머리 사이트에서 시스템 관리자를 통해 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는 파일 시스템 및 데이터베이스( 세컨더리 사이트의 Geo 추적 데이터베이스 포함)입니다. 다양한 내부 컴포넌트는 이러한 리포지터리를 변경하기 위해 조정됩니다.

데이터 입력 유효성 검사 요구 사항은 무엇으로 정의되었나요?

  • 세컨더리 사이트는 프라이머리 사이트의 데이터를 정확하게 복제해야 합니다.

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

  • Git 리포지터리 및 파일, 관련 정보를 추적하며, GitLab 데이터베이스의 내용을 저장합니다.

어떤 데이터가 암호화되어야 하거나 암호화되어야 할 필요가 있는지, 그리고 어떤 키 관리 요구 사항이 정의되어 있나요?

  • 프라이머리 사이트나 세컨더리 사이트는 휴식 중에 Git 리포지터리나 파일 시스템 데이터를 암호화하지 않습니다. 데이터베이스 열의 하위 집합은 db_otp_key를 사용하여 휴식 중에 암호화됩니다.
  • GitLab 배포의 모든 호스트에서 공유되는 정적 비밀입니다.
  • 이동 중에 데이터는 암호화되어야 하지만, 응용 프로그램은 통신이 암호화되도록 허용합니다. 두 주요 이동 경로는 세컨더리 사이트의 PostgreSQL 복제 프로세스 및 Git 리포지터리/파일입니다. 둘 다 TLS를 사용하여 보호되어야 하며, 그 키는 GitLab에 대한 최종 사용자 액세스를 위한 기존 구성대로 Linux 패키지에 의해 관리됩니다.

민감한 데이터 유출을 감지하기 위한 기능이 무엇이 있나요?

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

데이터의 이동에 대한 암호화 요구 사항은 무엇으로 정의되었나요(광대역, LAN, SecureFTP 또는 http: 및 https:와 같은 공개 액세스 프로토콜을 통한 전송 포함)?

  • 데이터는 이동 중에 선택적으로 암호화되어야 하며, 매뉴얼 및 능동 공격에 대해 안전해야 합니다(예: MITM 공격이 불가능해야 합니다).