This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
ongoing @theoretick @vbhat161 @ahmed.hemdan @theoretick @connorgilbert @amarpatel devops secure 2022-11-25

플랫폼 전반적인 경험으로서의 Secret Detection

요약

오늘날의 Secret Detection 기능은 파이프라인 컨텍스트 내에서 저장소의 컨테이너화된 스캔을 중심으로 구축되었습니다. 이 기능은 유출이나 침해된 토큰이 나타날 수 있는 범위에 비해 상당히 제한적이며, 더 넓은 범위로 확장되어야 합니다.

플랫폼 전반적인 Secret Detection은 저장소 콘텐츠, 작업 로그, 이슈, 에픽, MR 등과 같은 프로젝트 관리 기능을 포함한, 비밀 유출 위험이 높은 플랫폼 기능 전반에서의 감지를 포함합니다.

동기

목표

  • 비밀 토큰에 대한 플랫폼 전반적인 감지 지원
  • 감지된 비밀을 거부하여 노출 방지
  • 최종 사용자 경험에 영향을 미치지 않으면서 확장 가능한 감지 수단 제공
  • 토큰 패턴과 마스킹의 통합된 목록 제공

대상 유형에서 스캔 대상 우선 순위를 확인하세요.

비목표

Phase1은 감지 및 알림이 플랫폼 전체에만 제한되어 있으며, 미리받는 Git 상호작용 및 브라우저 기반 감지 중에만 거부가 이루어집니다.

비밀 폐기 및 회전 또한이 새로운 기능의 범위를 벗어납니다.

이 MVC의 초기 범위를 벗어난 스캔된 객체 유형은 대상 유형에 포함되어 있습니다.

관리 UI

비밀 관리에 대한 독립적인 인터페이스 개발은 이 설계안의 범위를 벗어납니다. 감지 사항은 기존 취약점 관리 UI를 사용하여 관리됩니다.

감지된 비밀의 관리는 비밀 관리 기능 능력에서 분명히 다르므로, 감지된 비밀을 식별하면 이미 해당 대상 개체 (즉, 저장소)에있기 때문에 이미 침해를 당하게 되었습니다. 반면 관리되는 비밀은 안전한 저장을 위해 보다 엄격한 기준에 따라 저장되어야 하며, (예 : 작업 로그 또는 UI에 나타날 때) 마스킹 및 암호화도 포함됩니다.

장기적인 우선 순위로는 두 유형의 비밀 관리를 통합하는 것을 고려해야 하지만, 현재 설계안의 목표에서는 여전히 활성 감지에 초점을 맞추고 있으므로 이러한 작업은 범위를 벗어납니다.

대상 유형

대상 객체 유형은 유출된 비밀을 감지하기 위해 우선 순위가 매겨진 스캔 대상을 의미합니다.

우선 순위별로 다음을 포함합니다:

  1. 1MB 미만의 이진이 아닌 Git 블롭
  2. 작업 로그
  3. 이슈 생성 (이슈, MR, 에픽)
  4. 이슈 업데이트 (이슈, MR, 에픽)
  5. 이슈 코멘트 (이슈, MR, 에픽)

초기 단계의 범위를 벗어난 대상에는 다음이 포함됩니다:

  • 1MB 이상의 이진이 아닌 Git 블롭
  • 이진 Git 블롭
  • 미디어 유형 (JPEG, PDF 등)
  • 스니펫
  • 위키
  • 컨테이너 이미지
  • 외부 미디어 (YouTube 플랫폼 비디오)

토큰 유형

기존의 Secret Detection 구성은 여러 플랫폼에 걸친 100가지 이상의 규칙을 커버합니다. 총 실행 비용과 잘못된 감지 가능성을 줄이기 위해 전용 서비스는 정의가 잘 된, 낮은 FP(fales-positive) 토큰에만 초점을 맞춥니다.

중요도별로 식별해야 하는 토큰 유형:

  1. 명확하게 정의된 GitLab 토큰 (개인 액세스 토큰 및 파이프라인 트리거 토큰 포함)
  2. 검증된 파트너 토큰 (AWS 등)
  3. 명확하게 정의된 낮은 FP의 타사 토큰
  4. 현재 Secret Detection 분석기 구성에 포함된 나머지 토큰

명확하게 정의된 토큰은 대부분은 고정된 부분 문자열 접두사 (또는 접미사)와 고정된 길이를 갖는 토큰입니다.

GitLab 및 파트너 토큰의 경우 자체 토큰의 도메인에 대한 이해를 가지고 있으며 파트너와 협력하여 제공된 패턴의 정확성을 검증했습니다.

낮은 FP 토큰은 사용자 보고서와 기각 보고서에 의존합니다. 이 데이터 이슈를 전달함으로써 FP 비율에 대한 집계를 얻을 수 있지만, 이는 주로 사용자가 보고한 데이터입니다.

잘못된 감지 가능성을 최소화하기 위해 고엔트로피(arbitrary) 및 임의의 문자열을 도입하거나 경고할 계획은 없습니다. 즉 3lsjkw3a22와 같은 패턴을 포함하지 않을 것입니다.

규칙 구성의 균일성

규칙 패턴 구성은 ‘비밀’ 분석기의 패키지 된 gitleaks.toml 구성에 중앙에 유지되어야 하며, Phase 1의 경우 거래를 위해 패키지를 할 gitleaks.toml 구성을 플랫폼에 체크섬을 확인하여 특정 릴리스 버전과 일치하도록 해야 합니다. 각 토큰은 tags별로 필터링되어 고신뢰도 및 블로킹 그룹을 형성할 수 있습니다. 예를 들어:

prereceive_blocking_rules = toml.load_file('gitleaks.toml')['rules'].select do |r|
  r.tags.include?('gitlab_blocking_p1') &&
    r.tags.include?('gitlab_blocking')
end

감사 기능

비밀 감지 및 억제의 중요한 측면은 행정적 가시성이어야 합니다. 각 단계에서 이벤트 또는 로깅을 활성화하여 이벤트 검색을 가능하게해야 합니다.

제안

실험적 능력의 첫 번째 반복은 레일즈 애플리케이션에 구현된 블로킹 미리받는 후크를 특징으로 하는 것입니다. 이 반복은 실험적 상태로 선택된 사용자에게 배포되어 팀이 기능의 프로파일링을 고려하기 전에 전용 서비스로 추출을 고려하는 기회를 제공합니다.

미래 상태에서 여러 도메인 객체에 대한 확장 가능한 비밀 감지를 달성하기 위해 전용 스캔 서비스를 만들고 GitLab 배포와 함께 배포해야 합니다. 이것을 SecretScanningService라고합니다.

이 서비스는 다음과 같아야 합니다:

  • 높은 성능
  • 수평 확장 가능
  • 도메인 객체 스캔 기능이 일반적입니다

플랫폼 전체적인 비밀 감지는 GitLab SaaS 및 셀프매니지드 인스턴스에서 기본적으로 활성화되어야 합니다.

결정

도전과제

  • GitLab.com 인프라에 대한 안전한 인증
  • 대용량 blob에 대한 스캔 성능
  • 도메인 객체(예: 푸시 빈도와 같은)의 대량 스캔 성능
  • 스캔 요청의 대기열

대용량 Git 데이터 블롭에 대한 전송 최적화

Gitaly의 업로드 팩 트래픽 청사진에서 설명한 대로, gRPC를 통한 대용량 데이터 전송 처리에 대한 문제가 발생했습니다. 이는 우리가 비밀 탐지를 대규모 블롭 크기에 확장하여 누출된 비밀들의 범위를 확대함에 따라 고려사항일 수 있습니다. 우리는 1MB 블롭 크기 제한으로 사전 수신 스캔을 롤아웃할 것으로 예상되며, 이는 충분히 적절한 범위 안에 있어야 합니다. 프로토버퍼 문서에서:

일반적으로, 각 메시지 크기가 1MB를 초과하는 경우 대안 전략을 고려할 시간일 수 있습니다.

확장 단계에서는 Gitaly가 사용하는 최적화된 사이드채널 접근 방식과 같은 청킹 또는 대체 전략을 탐구해야 할 것입니다.

설계 및 구현 세부 정보

탐지 능력은 실험 구성 요소에서부터 통합된 모노리스로 직접 구현된 독립형 서비스로의 다단계 롤아웃에 의존합니다.

비밀 탐지 서비스의 구현은 GitLab.com 및 참조 아키텍처에서의 벤치마킹 및 용량 계획에 강하게 의존합니다. 스캔 기능은 우리의 SaaS 및 셀프 관리형 인스턴스의 기본적으로 켜져 있어야 하므로, 각 반복의 배포 특성은 서비스가 독립형 구성 요소로 작동할지, 또는 우리의 Elasticsearch 색인 서비스의 구현과 동일하게 subproccess로 실행될지를 정의합니다.

추가적인 백그라운드 탐구에 대해서는 기술적 발견을 확인하세요.

과거 스케일링 접근에 대한 토론은 이 쓰레드에서 확인하세요.

탐지 엔진

현재의 시크릿 탐지 오퍼링은 모든 시크릿 스캔에 Gitleaks를 사용합니다. --no-git 구성을 사용하여 리포지토리 컨텍스트 외의 임의의 텍스트 블롭을 스캔할 수 있으며 파이프라인 스캔 이외에도 계속 사용할 수 있습니다.

성능 우려사항이 드러날 때까지는 탐지 엔진의 변경 사항은 범위에서 제외됩니다.

GitLab 시크릿 탐지의 장기적인 방향은 Gitleaks 도구의 것보다 더 큰 범위입니다. 따라서 우리는 Gitleaks 도메인을 해당 빌드 컨텍스트로 제한하는 기능 캡슐화를 고려해야 합니다.

사전 수신 탐지의 경우, 사전 필터링 및 re2를 사용한 정규식 탐지의 조합에 의존합니다. 초기 벤치마크에 대해서는 스파이크 이슈를 확인하세요.

주목할만한 대체품으로 Hyperscan과 그의 이식 가능 포크인 Vectorscan과 같은 고성능 정규식 엔진이 있습니다. 이러한 시스템은 기존 스택을 넘어 성장할 필요성이 우리에게 보여질 경우 미래에 탐색할 가치가 있을 수 있으나, 독립적으로 확장 가능하고 일반적인 스캔 엔진을 구축하는 팀의 가속화가 우선되었습니다. 더 많은 정보는 구현 언어 고려 사항에 대한 ADR 001을 참조하세요.

조직 수준의 제어

구성 및 워크플로우는 조직을 중심으로 구성되어야 합니다. 탐지 제어 및 거버넌스 패턴은 여러 프로젝트와 그룹에서의 구성을 지원하고, 공유할록을 강조하며(push 옵션 바이패스 비활성화 등), 감사가 가능하도록해야 합니다.

각 단계는 인스턴스 수준에서부터 조직 수준의 제어로 반복함에 따라 사용하는 패러다임을 문서화합니다.

단계 1 - 루비 푸시체크 사전 수신 통합

위의 목표에 설명된 중요 경로는 두 가지 주요 객체 유형을 다룹니다: Git 텍스트 블롭(푸시 이벤트에 해당) 및 임의의 텍스트 블롭. 단계 1에서는 Git 텍스트 블롭에 완전히 초점을 맞춥니다.

푸시 이벤트의 탐지 플로우는 커밋 데이터를 스캔하기 위해 PreReceive 훅에 구독하고, PushCheck 인터페이스를 사용합니다. 해당 SecretScanningService 서비스는 지정된 블롭 콘텐츠를 Gitaly에서 가져와 커밋 콘텐츠를 스캔하며, 비밀이 감지되면 푸시를 거부합니다. 시퀀스는 푸시 이벤트 탐지 플로우를 확인하세요.

푸시 탐지의 경우, 커밋이 인라인으로 거부되고 오류가 최종 사용자에게 반환됩니다.

구성

이 단계는 고객이 인스턴스 수준 응용 프로그램 설정을 통해 “실험적”으로 제한된 가용성으로 간주될 것입니다.

고수준 아키텍처

1단계 아키텍처는 추가 구성 요소가 없으며 완전히 Rails 응용 프로그램 서버에 캡슐화됩니다. 이는 인증 경계 내에서의 밀접한 통합을 제공하며 배포를 신속하게 할 수 있지만, 기존 응용 프로그램 노드에 추가 CPU, 메모리, 전송 용량 및 요청 지연을 추가하는 리소스 이용이라는 주요 단점이 있습니다.

Push 이벤트 검출 플로우

sequenceDiagram autonumber actor User User->>+Workhorse: git push with-secret Workhorse->>+Gitaly: tcp Gitaly->>+Rails: PreReceive Rails->>-Gitaly: ListAllBlobs Gitaly->>-Rails: ListAllBlobsResponse Rails->>+GitLabSecretDetection: Scan(blob) GitLabSecretDetection->>-Rails: found Rails->>User: rejected: secret found User->>+Workhorse: git push without-secret Workhorse->>+Gitaly: tcp Gitaly->>+Rails: PreReceive Rails->>-Gitaly: ListAllBlobs Gitaly->>-Rails: ListAllBlobsResponse Rails->>+GitLabSecretDetection: Scan(blob) GitLabSecretDetection->>-Rails: not_found Rails->>User: accepted

Gem 스캐닝 인터페이스

1단계에서는 GitLab Rails 플랫폼에서 Secret Detection Ruby Gem을 사용합니다.

개인용 SD 젬은 여러 블롭에서 스캔을 실행하는 것 외에도 다음을 지원합니다.

  • 전체 스캔 수준 및 각 블롭 수준에서 구성 가능한 시간 제한.

  • 주 프로세스 대신 서브프로세스에서 스캔을 실행하는 기능. 요청당 생성되는 프로세스 수는 5로 제한됩니다.

Pre-receive Secret Detection 스캔 중에 참조된 Ruleset 파일은 여기에 있습니다.

젬에 대한 더 자세한 내용은 README 파일에서 찾을 수 있습니다. 또한 젬 코드가 저장되고 배포되는 방법에 대한 자세한 내용은 ADR 002를 참조하십시오.

Phase 2 - 독립형 사전 수신 서비스

위의 목표에 설명된 중요 경로는 두 가지 주요 객체 유형을 다룹니다: Git 텍스트 블롭(푸시 이벤트에 해당) 및 임의의 텍스트 블롭. 2단계에서는 계속하여 Git 텍스트 블롭에 중점을 둡니다.

이 단계에서는 일반적인 가용성을 위해 몬리스 밖에서 서비스의 확장을 강조하고 기본적으로 활성화된 동작을 허용합니다. 아키텍처는 독립적 및 독립적으로 확장 가능한 서비스를 제공하도록 조정되었습니다.

푸시 검출의 경우, 커밋이 거부되고 오류가 최종 사용자에게 반환됩니다.

구성

이 단계에서는 “일반적으로 사용 가능(GA)”으로 간주되며 기관 수준 설정을 통해 비활성화 구성이 가능합니다.

고수준 아키텍처

2단계 아키텍처는 비밀 감지 로직을 독립적인 서비스로 추출하여 레일즈 애플리케이션과 Gitaly와 직접 통신하는 것을 포함합니다. 이는 비밀 감지 노드를 독립적으로 확장하고 레일즈 애플리케이션의 리소스 사용량을 줄이는 수단을 제공합니다.

스캔은 여전히 (가능성이 있음에도 불구하고) 동기적으로 실행되며, (잠재적으로) 블로킹되는 사전 수신 트랜잭션으로 실행됩니다. 블롭 크기는 여전히 1MB로 제한됩니다.

노드 수는 순수하게 설명적인 것이지만, 스캔 서비스의 독립적인 확장 요구 사항을 강조하는 데 도움이 됩니다.

Push 이벤트 감지 흐름

sequenceDiagram autonumber actor 사용자 사용자->>+Workhorse: 비밀 포함하여 git push Workhorse->>+Gitaly: tcp Gitaly->>+GitLabSecretDetection: PreReceive GitLabSecretDetection->>-Gitaly: ListAllBlobs Gitaly->>-GitLabSecretDetection: ListAllBlobsResponse Gitaly->>+GitLabSecretDetection: PreReceive GitLabSecretDetection->>GitLabSecretDetection: 스캔(블록) GitLabSecretDetection->>-Gitaly: 발견 Gitaly->>+Rails: PreReceive Rails->>사용자: 거절됨: 비밀 발견 사용자->>+Workhorse: 비밀을 포함하지 않는 git push Workhorse->>+Gitaly: tcp Gitaly->>+GitLabSecretDetection: PreReceive GitLabSecretDetection->>-Gitaly: ListAllBlobs Gitaly->>-GitLabSecretDetection: ListAllBlobsResponse Gitaly->>+GitLabSecretDetection: PreReceive GitLabSecretDetection->>GitLabSecretDetection: 스캔(블록) GitLabSecretDetection->>-Gitaly: 발견 안 됨 Gitaly->>+Rails: PreReceive Rails->>사용자: 허용됨

3단계 - 사전 수신 서비스를 넘어서는 확장

이때 임의의 텍스트 블롭에 대한 감지 흐름은 Notes::PostProcessService (또는 동등한 서비스)에 구독하여 SecretScanningServiceSidekiq 요청을 인큐해서 도메인 객체의 객체 유형과 기본 키별로 텍스트 블롭을 처리합니다. SecretScanningService 서비스는 관련 텍스트 블롭을 가져와 내용을 스캔하고, 비밀이 감지되면 레일즈 애플리케이션에 알립니다.

작업 로그에 대한 감지 흐름은 오브젝트 스토리지로 아카이브하는 중에 로그를 처리해야 합니다. 임의의 추적 청크에 대해 스트리밍 중인 스캔 및 임의 추적 청크에 대한 되감기 버퍼링에 대한 추가 복잡성에 대한 이 문제에서 논의하세요.

푸시 감지의 경우, 커밋이 거부되고 오류가 최종 사용자에게 반환됩니다. 감지의 다른 경우에는 레일즈 애플리케이션이 기존 취약점 관리 UI에 결과를 노출하기 위해 Vulnerabilities::ManuallyCreateService를 사용하여 수동으로 취약점을 생성합니다.

구성

본 단계는 “일반적으로 사용 가능”하며 기본 설정을 통해 조직 수준 설정을 통해 비활성화 구성을 고려할 것입니다.

고수준 아키텍처

2단계에서 정의된 아키텍처에 변경사항은 없지만, 개별 로드 요구 사항은 탐지 서비스의 노드 수를 확장해야 할 수 있습니다.

Push Event Detection Flow

2단계에서 정의된 푸시 이벤트 감지 흐름에 변경 사항은 없지만, 추가 기능으로 레일스에서 임의의 텍스트 덩어리를 직접 스캔할 수 있게 함으로써 생성될 수 있는 처리 전 행동을 흉내 내는 능력이 추가되었습니다. (대상 유형에서 우선 순위 객체 유형을 확인하십시오).

sequenceDiagram autonumber actor 사용자 사용자->>+Workhorse: git push with-secret Workhorse->>+Gitaly: tcp Gitaly->>+GitLabSecretDetection: PreReceive GitLabSecretDetection->>-Gitaly: ListAllBlobs Gitaly->>-GitLabSecretDetection: ListAllBlobsResponse Gitaly->>+GitLabSecretDetection: PreReceive GitLabSecretDetection->>GitLabSecretDetection: Scan(blob) GitLabSecretDetection->>-Gitaly: found Gitaly->>+Rails: PreReceive Rails->>사용자: rejected: secret found 사용자->>+Workhorse: POST issuable with-secret Workhorse->>+Rails: tcp Rails->>+GitLabSecretDetection: PreReceive GitLabSecretDetection->>GitLabSecretDetection: Scan(blob) GitLabSecretDetection->>-Rails: found Rails->>사용자: rejected: secret found

향후 단계

이들은 기능 완전한 항상 켜진 경험을 제공하기 위한 주요 사항이지만 아직 단계에 우선순위가 정해지지 않았습니다.

대형 덩어리 크기 (1MB 이상)

현재 단계에는 1MB를 넘는 덩어리 크기의 확장이 포함되지 않습니다. 주된 제한 사항은 미래의 반복을 위한 RPC 전송 한도에 맞추기로 선택되었으며, 추가 덩어리 크기를 지원할 수 있어야 합니다. 이는 다음 두 가지 방법으로 구현할 수 있습니다:

  1. 포스트-리시브 처리

    비차단 방식으로 덩어리를 수신하고, 스캔을 백그라운드 작업으로 처리하고, 특정 시크릿을 감지하면 수동으로 경고를 실행합니다.

  2. 스캔 로직 배치의 개선

    1MB의 제약을 유지하면서도 주로 미래를 대비하여 예상되는 전송 프로토콜과 일치시키는 겁니다. 이는 별도의 전송(http, 디스크로부터 읽기, …)을 사용하거나 덩어리 크기를 분할하여 완화시킬 수 있습니다.

감지 억제

유출된 시크릿에 대한 감지와 조치를 여러 수준에서 지원할 것입니다.

  1. 전역 억제 - 시크릿이 거짓 토큰일 가능성이 높다면(즉, EXAMPLE), 사용자가 심각하게 불편할 수 있는 워크플로우 컨텍스트에서 억제돼야 합니다.

    여전히 감사 이벤트자동 취약점 해결으로 이러한 결과를 선별하는 수단을 제공해야 합니다.

  2. 조직 억제 - 시크릿이 조직의 허용 목록과 일치하면(또는 이전에 플래그 지정되어 관련성이 없다고 해결된 경우), 재발 방지되어야 합니다. 조직 수준 제어를 참조하십시오.

  3. 인라인 억제 - 인라인 주석은 나중 단계에서 조직 수준 구성과 함께 지원되어야 합니다.

외부 토큰 검증

감지의 사후 처리로 검증된 시크릿을 탐구해야 합니다. 이것은 지원되는 토큰 유형별로 프로세서를 필요로 하며, 우리가 경고에 대해 높은 신뢰도를 제공하기 위해 유효한 유출된 토큰과 거짓 양성을 구별할 수 있어야 합니다. 우리의 유출된 시크릿에 대한 자동 응답과 유사합니다.

내부 토큰과 외부 토큰 두 가지 유형이 있습니다:

  • 내부 토큰은 ScanSecurityReportSecretsWorker 워커의 일부로 검증 및 폐기할 수 있습니다.
  • 외부 토큰은 외부 검증이 필요하며, 아키텍처시크릿 폐기 서비스와 밀접하게 일치합니다.

반복