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. The development, release, and timing of any products, features, or functionality may be subject to change or delay and 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

요약

오늘날의 비밀 감지 기능은 파이프라인 컨텍스트 내의 리포지터리를 스캔하는 컨테이너화된 스캔을 중심으로 구축되었습니다. 이 기능은 누수나 위험한 토큰이 나타날 수 있는 범위에 비해 상당히 제한적이며, 훨씬 더 넓은 범위로 확장하여 리포지터리 콘텐츠, 작업 로그 및 이슈, 에픽, MR 등과 같은 프로젝트 관리 기능을 포함한 플랫폼 기능 전반에 걸쳐 감지되어야 합니다.

동기

목표

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

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

비목표

Phase1의 경우 감지 및 플랫폼 전반에 걸친 알림만으로 제한되며, prereceive Git interactions 및 브라우저 기반 감지 중에만 거부됩니다.

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

이 MVC의 범위를 벗어나는 스캔 대상 유형에 대한 추가 정보는 대상 유형에 포함됩니다.

관리 UI

보안성을 제공하기 위해 감지된 비밀은 보다 엄격한 표준으로 안전한 저장을 위해 관리되어야 하며, 보이는 경우 암호화 및 마스킹도 포함됩니다.

장기적인 우선 순위로 두 가지 비밀 유형의 관리를 통합하는 것을 고려해야 하지만, 현재 블루프린트의 목표에서는 여전히 비활성 감지에 중점을 두고 있습니다.

대상 유형

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

우선 순위순으로 포함되는 것은 다음과 같습니다.

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

초기 단계의 대상에 포함되지 않은 타겟은 다음과 같습니다.

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

토큰 유형

기존의 Secret Detection 구성은 다양한 플랫폼에서 100가지 이상의 규칙을 다룹니다. 총 실행 비용과 잘못된 양성 결과의 가능성을 줄이기 위해 전용 서비스는 잘 정의된 낮은 FP 토큰만을 대상으로 합니다.

중요도 순으로 식별해야 할 토큰 유형은 다음과 같습니다.

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

잘 정의된 토큰은 보통 고정 부분 문자열 접두사(또는 접미사) 및 고정 길이를 가진 토큰입니다.

GitLab 및 파트너 토큰의 경우, 자체 토큰에 대한 우리의 도메인 이해와 파트너와의 협업을 통해 제공된 패턴의 정확성을 검증했습니다.

낮은 FP 토큰은 사용자 보고 및 기각 보고를 의존합니다. 이 데이터 이슈의 제공을 통해 FP 급료에 대한 집계값을 갖게 될 것이지만, 현재 이는 사용자 보고 데이터에 주로 의존합니다.

오인자 양성을 최소화하기 위해 고엔트로피, 임의 문자열과 같은 패턴(예: 3lsjkw3a22)을 도입하거나 경고할 계획은 없습니다.

규칙 구성의 균일성

규칙 패턴 구성은 secrets 분석기의 패키지 된 gitleaks.toml 구성에서 중앙에 유지되어야 하며, Phase 1을 위해 모노리스에 벤더링되고 드리프트를 피하기 위해 특정 릴리스 버전과 일치하는지 확인하기 위해 체크섬이 확인되어야 합니다. 각 토큰은 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

감사 기능성

비밀 감지 및 억제의 중요한 측면은 관리 가능성의 가능성을 포함합니다. 각 단계마다이 기능을 통해 이벤트를 검색할 수 있는 감사 기능(이벤트 또는 로깅)을 포함해야 합니다.

제안

실험적 기능의 첫 번째 반복에는 Rails 애플리케이션에서 구현된 차단 프리리시브 후크를 특징으로 할 것입니다. 이 반복은 실험 상태로 선택된 사용자 및 팀이 추출을 고려하기 전에 기능을 프로파일링 할 기회를 제공할 것입니다.

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

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

  • 매우 성능이 좋아야 함
  • 수평 확장 가능
  • 도메인 개체 스캔 기능이 일반적

GitLab SaaS와 Self-Managed 인스턴스의 기본적으로 플랫폼 전체적인 비밀 감지 기능이 활성화되어야 합니다.

결정

도전과제

  • GitLab.com 인프라에 대한 안전한 인증
  • 대형 블롭에 대한 스캔 성능
  • 도메인 객체(예: 푸시 주기)의 스캔 성능
  • 스캔 요청의 큐 진행

대용량 Git 데이터 블러를 위한 전송 최적화

과거 Gitaly의 upload-pack 트래픽 블루프린트에 설명 된 바와 같이, 우리는 외부 미디어(YouTube 플랫폼 비디오)와 같이 큰 데이터 전송을 처리하는 데 문제가 있었습니다. 유출된 비밀을 보다 폭넓게 커버하기 위한 대형 블러 크기로 Secret Detection을 확장하는 것이 우려됩니다. 우리는 미래에 1MB 범위 내의 블러 크기 한도로 사전 수신 스캔을 롤아웃할 것입니다. 이는 엄격한 범위 내에 있을 것으로 예상됩니다. Protobuffers의 문서에서 다음과 같이 설명되어 있습니다.

일반적인 경험으로, 각 메시지가 1MB를 초과하는 크기로 확장을 고려할 때, 다른 전략을 고려해야 할 것입니다.

확장 단계에서는 Gitaly에서 사용되는 최적화 된 측면채널 접근 방식과 같은 래도 페친들링 또는 대안 전략을 탐색해야 합니다.

디자인 및 구현 세부 정보

감지 기능은 실험적 구성요소에서 시작하여 텍스트 블롭을 일반적으로 스캔할 수 있는 독립적 서비스로의 전환에하여 멀티 페이즈 롤아웃에 의존합니다.

비밀 스캔 서비스의 구현은 우리의 벤치마킹 및 용량 계획에 강하게 의존합니다. 스캔 기능은 두 가지 모두에 있어서 기본적으로 활성화된 컴포넌트여야 하므로 각 반복의 배포 특성은 서비스가 독립적 컴포넌트로 동작할지, 또는 Rails 아키텍처의 자식 프로세스로 실행될지 정의합니다 (Elasticsearch 인덱싱 서비스의 구현과 유사).

자세한 내용은 추가적인 백그라운드 탐색을 위해 기술적 탐사를 확인하세요.

전달된 논의 주제에 대해서는 이 스레드를 참조하세요.

감지 엔진

현재의 Secret Detection 제공은 파이프라인 컨텍스트에서 모든 비밀 스캔을 위해 Gitleaks를 사용하고 있습니다. --no-git 구성을 사용함으로써 리포지터리 컨텍스트 외의 임의 텍스트 블롭을 스캔할 수 있으며, 비-파이프라인 스캔에 대해서도 계속 사용할 수 있습니다.

임플리먼테이션 엔진의 변경은 벤치마킹이 성능 우려 사항을 드러낼 때까지 범위를 벗어납니다.

GitLab Secret Detection의 장기적인 방향은 Gitleaks 도구보다 더 큰 범위를 가지고 있기 때문에 Gitleaks 도메인을 관련된 빌드 컨텍스트로 제한하는 기능 캡슐화를 고려해야 합니다.

전송승제 감지의 경우, 사전 필터링을 위한 키워드/부분 문자열 일치와 re2에 대한 정규식 감지의 결합에 의존합니다. 초기 벤치마크에 대한 초기 벤치마크를 위해 spike issue를 참조하십시오.

주목할만한 대체품에는 Hyperscan과 (이의 휴대용 포크인) Vectorscan과 같은 고성능 정규식 엔진이 포함됩니다. 이러한 시스템은 현재 스텍을 벗어나 성장의 필요성을 보여주는 경우에 미래에 탐구할 가치가 있습니다. 그러나 독립적으로 확장 가능하고 일반적인 스캔 엔진을 만드는 팀의 빨리 완성하는 속도가 우선시 되었습니다. 구현 언어 고려 사항에 대해 자세히 알아 보려면 ADR 001을 참조하십시오.

조직 수준의 통제

구성 및 워크플로는 조직을 중심으로 구성되어야 합니다. 감지 통제 및 거버넌스 패턴은 여러 프로젝트 및 그룹에 걸쳐 구성을 지원하고 공유 허용 디렉터리, 조직 전체 정책(예: 푸시 옵션 우회 비활성화) 및 감사 기능을 강조하는 통일된 방식으로 지원해야 합니다.

각 단계는 인스턴스 수준에서 조직 수준의 통제로 반복하는 과정을 문서화합니다.

단계 1 - Ruby pushcheck pre-receive 통합

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

푸시 이벤트의 감지 흐름은 PreReceive 후크에 구독하여 PushCheck 인터페이스를 사용하여 커밋 데이터를 스캔합니다. 이 SecretScanningService 서비스는 Gitaly에서 지정된 덩어리 내용을 가져와 커밋 내용을 스캔하고 비밀번호가 감지되면 푸시를 거부합니다. 연속에 대해서는 푸시 이벤트 감지 흐름을 참조하세요.

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

구성

이 단계는 “실험적”으로 간주되며 인스턴스 수준의 애플리케이션 설정을 통해 고객 선택 사항으로 제한된 가용성을 가집니다.

고수준 아키텍처

1단계 아키텍처에는 추가 컴포넌트가 없으며 완전히 Rails 응용 프로그램 서버에 캡슐화됩니다. 이는 권한 경계 내에서 밀접한 통합을 제공하고 배포를 신속하게 할 수 있습니다. 기존 응용 프로그램 노드에 CPU, 메모리, 전송 용량 및 요청 대기 시간을 추가하는 자원 이용의 주요 단점이 있습니다.

푸시 이벤트 감지 흐름

sequenceDiagram autonumber actor 사용자 사용자->>+Workhorse: 비밀번호가 있는 git 푸시 Workhorse->>+Gitaly: tcp Gitaly->>+Rails: PreReceive Rails->>-Gitaly: ListAllBlobs Gitaly->>-Rails: ListAllBlobsResponse Rails->>+GitLabSecretDetection: 스캔(블롭) GitLabSecretDetection->>-Rails: 발견 Rails->>사용자: 거부됨: 비밀번호 발견 사용자->>+Workhorse: 비밀번호가 없는 git 푸시 Workhorse->>+Gitaly: tcp Gitaly->>+Rails: PreReceive Rails->>-Gitaly: ListAllBlobs Gitaly->>-Rails: ListAllBlobsResponse Rails->>+GitLabSecretDetection: 스캔(블롭) GitLabSecretDetection->>-Rails: 발견되지 않음 Rails->>사용자: 허용됨

젬 스캐닝 인터페이스

단계 1에서는 GitLab Rails 플랫폼의 Secrets Push Check에서 호출되는 비공개 Secret Detection Ruby Gem을 사용합니다.

비공개 SD 젬은 여러 블롭에서 스캔을 실행하는 기능 외에도 다음을 지원합니다.

  • 스캔 전체 수준 및 각 블롭 수준의 구성 가능한 시간 초과.

  • 중요한 프로세스 내에서 스캔을 실행하는 능력. 요청 당 생성되는 프로세스 수는 5로 제한됩니다.

Pre-receive Secret Detection 스캔 중에 참조되는 Ruleset 파일은 여기에서 찾을 수 있습니다.

젬에 대한 자세한 내용은 README 파일을 참조하세요. 또한 젬 코드의 저장 및 배포 방식에 대한 자세한 내용은 ADR 002를 참조하세요.

단계 2 - 독립형 사전 수령 서비스

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

이 단계에서는 일반적인 가용성을 위해 모놀리스 외부로 서비스를 확장하고 on-by-default 동작을 허용하기 위해 강조됩니다. 아키텍처는 독립적 및 독자적으로 확장 가능한 서비스를 제공하기 위해 적응됩니다.

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

구성

이 단계는 조직 수준의 설정을 통해 “일반적으로 사용 가능”하며 on-by-default로 간주되며 비활성화 구성이 가능합니다.

고수준 아키텍처

2단계 아키텍처에는 비밀 감지 로직을 독립적으로 확장하여 레일스 응용 프로그램 및 Gitaly와 직접 통신하는 것이 포함됩니다. 이를 통해 비밀 감지 노드를 독립적으로 확장하고 레일스 응용 프로그램에 대한 자원 사용 오버헤드를 줄일 수 있습니다.

스캔은 여전히 (잠재적으로) 블록될 수 있는 사전 수령 트랜잭션으로 동기적으로 실행됩니다. 덩어리 크기는 1MB로 제한됩니다.

노드 수는 순전히 예시적인 것이며, 스캔 서비스의 독립적인 스케일링 요구 사항을 강조하기 위한 것입니다.

Push Event Detection Flow

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: git push without-secret Workhorse->>+Gitaly: tcp Gitaly->>+GitLabSecretDetection: PreReceive GitLabSecretDetection->>-Gitaly: ListAllBlobs Gitaly->>-GitLabSecretDetection: ListAllBlobsResponse Gitaly->>+GitLabSecretDetection: PreReceive GitLabSecretDetection->>GitLabSecretDetection: Scan(blob) GitLabSecretDetection->>-Gitaly: not_found Gitaly->>+Rails: PreReceive Rails->>사용자: accepted

Phase 3 - Pre-receive 서비스 이상의 확장

이슈 코멘트와 같은 임의의 텍스트 덩어리에 대한 감지 흐름은 Notes::PostProcessService (또는 해당 서비스)를 구독하여 도메인 오브젝트의 객체 유형 및 기본 키에 따라 SecretScanningService에 Sidekiq 요청을 큐잉한 후 처리하는 것에 의존합니다. SecretScanningService 서비스는 관련 텍스트 덩어리를 가져와 내용을 검사하고 비밀이 감지될 때 Rails 애플리케이션에 알립니다.

작업 로그의 감지 흐름은 로그를 오브젝트 리포지터리로 아카이브하는 동안 로그를 처리해야 합니다. 임의의 추적 청크를 버퍼링하여 스트리밍 중에 스캔하고 추가된 복잡성에 대한 토론은 이 이슈를 참조하세요.

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

설정

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

고수준 아키텍처

제2 단계에서 정의된 아키텍처에 변경 사항은 없지만 감지 서비스의 개별 부하 요구 사항이 확장되어야 할 수 있습니다.

Push Event Detection Flow

제2 단계에서 정의된 푸시 이벤트 감지 흐름에 변경 사항은 없지만 임의의 텍스트 덩어리를 Rails에서 직접 스캔할 수 있는 기능이 추가되어 문제 생성을 위한 사전 수신 동작을 흉내 내는 것을 가능하게 합니다(우선 순위 객체 유형에 대한 자세한 내용은 대상 유형을 참조).

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 작업의 일부로 검증 가능하고 취소할 수 있습니다. 외부 토큰은 외부 검증이 필요하며, 아키텍처는 비밀 허가 서비스에 밀접하게 일치할 것입니다.

반복

  • ✓ 감지 범위 및 조치 요구 사항 정의
  • ✓ 이슈 및 코멘트에서의 GitLab 토큰에 대한 브라우저 기반 감지 구현
  • ✓ 비밀 스캔 서비스 PoC 구현
  • ✓ 비밀 스캔 젬 PoC 구현
  • 사전 수신 PoC의 사전 프로덕션 성능 프로파일링
    • 서비스 능력의 프로파일링
      • ✓ 루비와 Go 접근법 간의 정규식 성능 평가
      • 전송 대기 시간, CPU 및 메모리 풋프린트
  • ✓ 비밀 스캔 젬 통합 MVC 구현 (개별 커밋을 대상으로 함)
  • 제1 단계 - 배포 및 모니터링
  • 레퍼런스 아키텍처에 서비스 컴포넌트 추가를 위한 용량 계획
  • 보안 및 준비 검토
  • 제2 단계 - 배포 및 모니터링
  • 비밀 스캔 서비스 구현 (임의의 텍스트 덩어리를 대상으로 함)
  • 제3 단계 - 배포 및 모니터링
  • 고우선순위 도메인 객체 롤아웃 (우선 순위 미정)
    • 이슈 코멘트
    • 이슈 바디
    • 작업 로그