InfoGrab Docs

Geo 보안 검토(Q&A)

요약

다음 Geo 기능 세트의 보안 검토는 자체 GitLab 인스턴스를 운영하는 고객에게 적용되는 기능의 보안 측면에 중점을 둡니다. 이를 사용할지 여부는 운영 요구 사항에 따라 고객이 결정합니다:

다음 Geo 기능 세트의 보안 검토는 자체 GitLab 인스턴스를 운영하는 고객에게 적용되는 기능의 보안 측면에 중점을 둡니다. 검토 질문은 부분적으로 owasp.org의 OWASP 애플리케이션 보안 검증 표준 프로젝트를 기반으로 합니다.

비즈니스 모델#

애플리케이션이 서비스를 제공하는 지리적 영역은 무엇인가요?#

  • 고객에 따라 다릅니다. Geo는 고객이 여러 영역에 배포할 수 있도록 하며 고객이 위치를 선택합니다.
  • 지역 및 노드 선택은 완전히 수동입니다.

데이터 필수 요소#

애플리케이션은 어떤 데이터를 수신, 생성 및 처리하나요?#

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

데이터를 민감도에 따라 어떻게 분류할 수 있나요?#

  • GitLab의 민감도 모델은 공개 vs. 내부 vs. 비공개 프로젝트를 중심으로 합니다. Geo는 이를 모두 무분별하게 복제합니다. 파일 및 리포지토리(데이터베이스 콘텐츠는 아님)에 대한 "선택적 동기화"가 있어 원한다면 덜 민감한 프로젝트만 보조 사이트로 복제할 수 있습니다.

애플리케이션에 대해 어떤 데이터 백업 및 보존 요구 사항이 정의되어 있나요?#

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

최종 사용자#

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

  • 보조 사이트는 주요 GitLab 설치(기본 사이트)에서 멀리 떨어진(인터넷 지연 면에서) 지역에 만들어집니다. 보조 사이트가 더 가깝다고 느끼는(인터넷 지연 면에서) 기본 사이트를 보통 사용하는 누구나가 사용하도록 의도됩니다.

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

  • 보조 사이트는 기본 사이트가 제공하는 모든 인터페이스(특히 HTTP/HTTPS 웹 애플리케이션 및 HTTP/HTTPS 또는 SSH Git 리포지토리 액세스)를 제공하지만 읽기 전용 활동으로 제한됩니다. 주요 사용 사례는 기본 사이트 대신 보조 사이트에서 Git 리포지토리를 clone하는 것으로 예상되지만 최종 사용자는 GitLab 웹 인터페이스를 사용하여 프로젝트, 이슈, 머지 리퀘스트, 스니펫과 같은 정보를 볼 수 있습니다.

최종 사용자는 어떤 보안 기대치를 가지고 있나요?#

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

관리자#

애플리케이션에서 관리 권한을 가진 사람은 누구인가요?#

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

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

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

네트워크#

라우팅, 스위칭, 방화벽 및 로드 밸런싱에 관해 어떤 세부 사항이 정의되어 있나요?#

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

애플리케이션을 지원하는 핵심 네트워크 장치는 무엇인가요?#

  • 고객마다 다릅니다.

어떤 네트워크 성능 요구 사항이 있나요?#

  • 기본 사이트와 보조 사이트 간의 최대 복제 속도는 사이트 간의 사용 가능한 대역폭에 의해 제한됩니다. 엄격한 요구 사항은 없습니다. 복제 완료 시간(및 기본 사이트의 변경 사항을 따라잡는 능력)은 데이터 세트의 크기, 지연 허용 범위 및 사용 가능한 네트워크 용량의 함수입니다.

애플리케이션을 지원하는 사설 및 공개 네트워크 링크는 무엇인가요?#

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

시스템#

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

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

필요한 OS 구성 요소 및 잠금 요구 사항에 관해 어떤 세부 사항이 정의되어 있나요?#

  • 지원되는 Linux 패키지 설치 방법은 대부분의 구성 요소를 스스로 패키징합니다.
  • 시스템 설치된 OpenSSH 데몬(Geo는 사용자가 사용자 정의 인증 방법을 설정하도록 요구함) 및 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에 특화된 몇 가지 값이 있습니다. 일부는 설정 시 기본 사이트에서 보조 사이트로 안전하게 전송해야 하는 공유 비밀입니다. 우리의 문서는 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 리포지토리/파일에 대한 것입니다. 두 가지 모두 기존 구성에 따라 Linux 패키지가 관리하는 키와 함께 TLS를 사용하여 보호해야 합니다.

민감한 데이터의 유출을 감지하는 기능은 무엇인가요?#

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

전송 중 데이터에 대해 어떤 암호화 요구 사항이 정의되어 있나요?#

  • (여기에는 WAN, LAN, SecureFTP 또는 http:와 https:와 같은 공개적으로 액세스 가능한 프로토콜을 통한 전송이 포함됩니다.)
  • 데이터는 전송 중에 암호화할 수 있는 옵션이 있어야 하며 수동 및 능동 공격(예: MITM 공격이 불가능해야 함)에 대해 안전해야 합니다.

액세스#

애플리케이션이 지원하는 사용자 권한 수준은 무엇인가요?#

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

어떤 사용자 식별 및 인증 요구 사항이 정의되어 있나요?#

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

어떤 사용자 권한 부여 요구 사항이 정의되어 있나요?#

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

어떤 세션 관리 요구 사항이 정의되어 있나요?#

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

URI 및 서비스 호출에 대해 어떤 액세스 요구 사항이 정의되어 있나요?#

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

애플리케이션 모니터링#

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

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

Geo 보안 검토(Q&A)

Tier: Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

다음 Geo 기능 세트의 보안 검토는 자체 GitLab 인스턴스를 운영하는 고객에게 적용되는 기능의 보안 측면에 중점을 둡니다. 이를 사용할지 여부는 운영 요구 사항에 따라 고객이 결정합니다:

다음 Geo 기능 세트의 보안 검토는 자체 GitLab 인스턴스를 운영하는 고객에게 적용되는 기능의 보안 측면에 중점을 둡니다. 검토 질문은 부분적으로 owasp.org의 OWASP 애플리케이션 보안 검증 표준 프로젝트를 기반으로 합니다.

비즈니스 모델#

애플리케이션이 서비스를 제공하는 지리적 영역은 무엇인가요?#

  • 고객에 따라 다릅니다. Geo는 고객이 여러 영역에 배포할 수 있도록 하며 고객이 위치를 선택합니다.
  • 지역 및 노드 선택은 완전히 수동입니다.

데이터 필수 요소#

애플리케이션은 어떤 데이터를 수신, 생성 및 처리하나요?#

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

데이터를 민감도에 따라 어떻게 분류할 수 있나요?#

  • GitLab의 민감도 모델은 공개 vs. 내부 vs. 비공개 프로젝트를 중심으로 합니다. Geo는 이를 모두 무분별하게 복제합니다. 파일 및 리포지토리(데이터베이스 콘텐츠는 아님)에 대한 "선택적 동기화"가 있어 원한다면 덜 민감한 프로젝트만 보조 사이트로 복제할 수 있습니다.

애플리케이션에 대해 어떤 데이터 백업 및 보존 요구 사항이 정의되어 있나요?#

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

최종 사용자#

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

  • 보조 사이트는 주요 GitLab 설치(기본 사이트)에서 멀리 떨어진(인터넷 지연 면에서) 지역에 만들어집니다. 보조 사이트가 더 가깝다고 느끼는(인터넷 지연 면에서) 기본 사이트를 보통 사용하는 누구나가 사용하도록 의도됩니다.

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

  • 보조 사이트는 기본 사이트가 제공하는 모든 인터페이스(특히 HTTP/HTTPS 웹 애플리케이션 및 HTTP/HTTPS 또는 SSH Git 리포지토리 액세스)를 제공하지만 읽기 전용 활동으로 제한됩니다. 주요 사용 사례는 기본 사이트 대신 보조 사이트에서 Git 리포지토리를 clone하는 것으로 예상되지만 최종 사용자는 GitLab 웹 인터페이스를 사용하여 프로젝트, 이슈, 머지 리퀘스트, 스니펫과 같은 정보를 볼 수 있습니다.

최종 사용자는 어떤 보안 기대치를 가지고 있나요?#

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

관리자#

애플리케이션에서 관리 권한을 가진 사람은 누구인가요?#

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

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

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

네트워크#

라우팅, 스위칭, 방화벽 및 로드 밸런싱에 관해 어떤 세부 사항이 정의되어 있나요?#

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

애플리케이션을 지원하는 핵심 네트워크 장치는 무엇인가요?#

  • 고객마다 다릅니다.

어떤 네트워크 성능 요구 사항이 있나요?#

  • 기본 사이트와 보조 사이트 간의 최대 복제 속도는 사이트 간의 사용 가능한 대역폭에 의해 제한됩니다. 엄격한 요구 사항은 없습니다. 복제 완료 시간(및 기본 사이트의 변경 사항을 따라잡는 능력)은 데이터 세트의 크기, 지연 허용 범위 및 사용 가능한 네트워크 용량의 함수입니다.

애플리케이션을 지원하는 사설 및 공개 네트워크 링크는 무엇인가요?#

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

시스템#

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

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

필요한 OS 구성 요소 및 잠금 요구 사항에 관해 어떤 세부 사항이 정의되어 있나요?#

  • 지원되는 Linux 패키지 설치 방법은 대부분의 구성 요소를 스스로 패키징합니다.
  • 시스템 설치된 OpenSSH 데몬(Geo는 사용자가 사용자 정의 인증 방법을 설정하도록 요구함) 및 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에 특화된 몇 가지 값이 있습니다. 일부는 설정 시 기본 사이트에서 보조 사이트로 안전하게 전송해야 하는 공유 비밀입니다. 우리의 문서는 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 리포지토리/파일에 대한 것입니다. 두 가지 모두 기존 구성에 따라 Linux 패키지가 관리하는 키와 함께 TLS를 사용하여 보호해야 합니다.

민감한 데이터의 유출을 감지하는 기능은 무엇인가요?#

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

전송 중 데이터에 대해 어떤 암호화 요구 사항이 정의되어 있나요?#

  • (여기에는 WAN, LAN, SecureFTP 또는 http:와 https:와 같은 공개적으로 액세스 가능한 프로토콜을 통한 전송이 포함됩니다.)
  • 데이터는 전송 중에 암호화할 수 있는 옵션이 있어야 하며 수동 및 능동 공격(예: MITM 공격이 불가능해야 함)에 대해 안전해야 합니다.

액세스#

애플리케이션이 지원하는 사용자 권한 수준은 무엇인가요?#

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

어떤 사용자 식별 및 인증 요구 사항이 정의되어 있나요?#

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

어떤 사용자 권한 부여 요구 사항이 정의되어 있나요?#

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

어떤 세션 관리 요구 사항이 정의되어 있나요?#

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

URI 및 서비스 호출에 대해 어떤 액세스 요구 사항이 정의되어 있나요?#

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

애플리케이션 모니터링#

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

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