보안 텔레메트리
GitLab v19.5Offering: GitLab Self-Managed, GitLab Dedicated
요약
보안 텔레메트리는 보안 인시던트를 탐지하고 조사하기 위해 GitLab에서 수집하는 데이터입니다. GitLab Security Operations 팀은 GitLab Self-Managed 및 GitLab Dedicated 인스턴스의 관리자와 GitLab.com 네임스페이스의 소유자를 위해 이 권장 사항을 작성했습니다.
보안 텔레메트리는 보안 인시던트를 탐지하고 조사하기 위해 GitLab에서 수집하는 데이터입니다.
GitLab Security Operations 팀은 GitLab Self-Managed 및 GitLab Dedicated 인스턴스의 관리자와 GitLab.com 네임스페이스의 소유자를 위해 이 권장 사항을 작성했습니다. GitLab이 생성하는 보안 텔레메트리의 종류, 각 텔레메트리가 알려 주는 내용, 사용 중인 제품 형태와 구독 티어에서 수집할 수 있는 항목을 이해하는 데 활용합니다. 이 권장 사항은 조직에서 정의한 로깅 및 모니터링 프로세스를 보완하지만 대체하지는 않습니다.
탐지가 발생하면 보안 인시던트 대응을 따라 인시던트를 격리하고 해결합니다.
이러한 제안과 권장 사항은 사용자 책임하에 사용합니다. 사용 가능한 텔레메트리는 제품 형태, 구독 티어, 구성에 따라 다릅니다.
보안 텔레메트리의 종류#
GitLab은 두 가지 주요 보안 텔레메트리를 생성합니다. 이 둘은 서로 다른 질문에 답하고 수집 방식도 다르므로, 가능하면 둘 다 사용합니다.
감사 이벤트 : 사용자가 로그인하거나, 권한이 바뀌거나, 토큰이 만들어지거나, 설정이 변경되는 것처럼 보안과 관련된 작업이 발생할 때 GitLab이 내보내는 구조화된 이벤트입니다. 각 이벤트에는 작업을 수행한 사람, 영향을 받은 대상, 접속한 IP 주소, 시각이 기록됩니다. 감사 이벤트는 "사용자가 GitLab에서 무엇을 했는가?"라는 질문에 답합니다. GitLab은 수백 가지의 감사 이벤트 유형을 정의합니다.
애플리케이션 로그 : GitLab Rails 애플리케이션과 그 주변 구성 요소(Workhorse, Gitaly, GitLab Shell, Sidekiq)가 기록하는 로그 파일입니다. 모든 HTTP 요청, Git 작업, 백그라운드 job이 기록됩니다. 이러한 활동의 상당수는 감사 이벤트가 되지 않습니다. 실패하거나 차단된 요청, 감사 대상이 아닌 엔드포인트로 보낸 요청, 요청의 정확한 파라미터, 요청을 처리하기 위해 GitLab이 거친 내부 단계가 그렇습니다. 애플리케이션 로그는 "GitLab 내부에서 무슨 일이 있었는가?"라는 질문에 답하며, GitLab 자체를 노린 악용 시도를 탐지할 수 있는 유일한 출처입니다.
이 둘 외에도 CI/CD job 로그와 자격 증명 인벤토리처럼 보안과 관련된 데이터를 자체적으로 기록하는 GitLab 기능이 여러 가지 있습니다. 자세한 내용은 그 밖의 보안 데이터 출처를 참고합니다.
제품 형태와 티어별 수집 가능 항목#
다음 표는 제품 형태별로 각 보안 텔레메트리 수집 방법에 필요한 최소 티어를 보여 줍니다. GitLab Dedicated는 Ultimate에서만 제공되므로 이 표의 모든 항목을 GitLab Dedicated에서 사용할 수 있습니다.
| 수집 방법 | GitLab.com | GitLab Self-Managed | GitLab Dedicated |
|---|---|---|---|
| GitLab에서 감사 이벤트를 보거나 API로 가져오기 | Premium | Premium | 예 |
| 감사 이벤트를 보안 정보 및 이벤트 관리(SIEM) 시스템이나 다른 대상으로 스트리밍 | Ultimate | Ultimate | 예 |
| 애플리케이션 로그 수집 | 사용할 수 없습니다. GitLab이 이 로그를 운영하고 보관합니다. | 모든 티어 | 예 |
실제로는 다음과 같습니다:
- Free에서는 본인의 로그인 이벤트를 보고 CI/CD job 로그를 검토할 수 있지만, 그룹, 프로젝트, 인스턴스 감사 이벤트는 볼 수 없습니다. GitLab Self-Managed에서는
audit_json.log에 기록되는 소수의 감사 이벤트를 포함한 애플리케이션 로그를 수집할 수 있습니다. - Premium에서는 GitLab에서 감사 이벤트를 보고 검색하며 API로 가져올 수 있지만, 스트리밍할 수는 없습니다. GitLab에서 일어나는 일을 전혀 볼 수 없는 것은 아니지만, 탐지와 장기 보관은 사용자 몫입니다.
- Ultimate에서는 감사 이벤트를 거의 실시간으로 SIEM에 스트리밍하고, GitLab에는 표시되지 않는 스트리밍 전용 이벤트도 받을 수 있습니다.
감사 이벤트 보기#
Premium과 Ultimate에서는 별도 설정 없이 감사 이벤트를 볼 수 있습니다:
- GitLab UI의 그룹, 프로젝트, 인스턴스 수준에서 봅니다. 인스턴스 수준 감사 이벤트는 GitLab Self-Managed와 GitLab Dedicated에서 사용할 수 있습니다.
- UI와 같은 이벤트를 반환하는 감사 이벤트 API로 봅니다.
Free에서 볼 수 있는 감사 이벤트는 사용자 프로필의 Authentication log에 있는 본인의 로그인 이벤트뿐입니다.
감사 이벤트를 보는 것은 간단한 점검이나 특정 사용자 또는 프로젝트를 사후에 조사하기에는 충분합니다. 하지만 다음과 같은 이유로 탐지에는 충분하지 않습니다:
- 각 쿼리는 30일 범위로 제한되며, UI는 이벤트 세부 정보를 검색하지 않습니다.
- 일부 이벤트 유형은 스트리밍 전용이며 GitLab에 표시되지 않습니다.
- 이벤트에 대한 알림을 설정하거나, 다른 데이터와 상관 분석하거나, 보관 기간을 제어할 수 없습니다.
감사 이벤트를 스트리밍할 수 없다면 API에서 일정에 따라 가져와 로그 플랫폼에 적재할 수 있습니다. 지연이 있고 스트리밍 전용 이벤트는 빠지지만, 검색할 수 있는 사본과 탐지의 기반을 얻을 수 있습니다.
감사 이벤트 스트리밍#
감사 이벤트 스트리밍은 모든 감사 이벤트를 발생하는 즉시 사용자가 제어하는 대상으로 보내므로, SIEM이 거의 실시간으로 완전한 기록을 갖게 됩니다. 스트리밍은 모든 제품 형태에서 감사 이벤트를 수집하는 데 권장되는 방법이며, 스트리밍 전용 이벤트를 받을 수 있는 유일한 방법입니다.
스트리밍 전용 이벤트#
일부 감사 이벤트 유형은 스트리밍 전용입니다. GitLab에 저장되지 않으며 스트리밍 대상이 있어야만 받을 수 있습니다. 이 중 다수는 민감한 데이터에 대한 읽기 액세스를 기록하므로 탐지에 특히 유용합니다. 예를 들면 다음과 같습니다:
| 스트리밍 전용 이벤트 | 알 수 있는 내용 |
|---|---|
repository_git_operation |
리포지터리를 복제, 가져오기 또는 푸시한 사용자 |
repository_file_accessed_api 및 repository_file_accessed_web |
API 또는 웹 UI로 파일을 읽은 사용자 |
job_artifact_downloaded |
CI/CD job 아티팩트를 다운로드한 사용자 |
variable_viewed_api 및 variable_viewed_graphql |
CI/CD 변수를 읽은 사용자 |
personal_access_token_used_from_unseen_ip |
이전에 확인되지 않은 IP 주소에서 토큰이 사용됨 |
user_authenticated_using_job_token |
CI/CD job 토큰으로 인증함 |
전체 목록은 아닙니다. 스트리밍 전용 이벤트 전체는 사용 가능한 감사 이벤트 유형 목록의 Saved to database 열을 참고합니다.
스트리밍 설정#
스트리밍을 구성하는 위치는 제품 형태에 따라 다릅니다:
| 제품 형태 | 구성하는 사람 | 범위 | 자세한 정보 |
|---|---|---|---|
| GitLab.com | 최상위 그룹의 Owner | 최상위 그룹, 하위 그룹, 프로젝트 | 최상위 그룹의 감사 이벤트 스트리밍 |
| GitLab Self-Managed 및 GitLab Dedicated | 관리자 | 인스턴스 전체. 조직 전반에서 서로 다른 대상을 사용하도록 최상위 그룹별로 구성할 수도 있습니다. | 인스턴스의 감사 이벤트 스트리밍 |
스트리밍은 HTTP 엔드포인트, Google Cloud Logging, Amazon S3의 세 가지 대상 유형을 지원합니다. 대상을 여러 개 추가할 수 있으며 이벤트 유형별로 각 대상을 필터링할 수 있습니다.
수신 측을 설계할 때 다음을 고려합니다:
- 간헐적인 중복 전송을 예상하고 이벤트
id를 기준으로 중복을 제거합니다. - GitLab.com에서는 대상에서 GitLab.com IP 범위의 트래픽을 허용합니다.
- 대상을 민감한 자산으로 취급합니다. 스트리밍된 이벤트에는 전체 이벤트 세부 정보가 포함됩니다.
- 대상을 많이 추가할 계획이라면 대상 한도를 확인합니다.
애플리케이션 로그 수집#
감사 이벤트는 어떤 작업이 일어났는지 알려 줍니다. 애플리케이션 로그는 그 작업이 어떻게 일어났는지 알려 줍니다. 감사 이벤트가 요약하는 요청 수준의 세부 정보를 제공하며, 실패한 요청, 속도 제한에 걸린 요청, 감사 대상이 아닌 엔드포인트로 보낸 요청, 각 요청의 전체 파라미터처럼 감사 이벤트가 전혀 없는 보안 관련 활동도 대량으로 기록합니다. 애플리케이션 로그를 수집할 수 있다면 수집합니다.
보안 관련 로그#
다음 로그가 보안 모니터링에 가장 관련이 깊습니다. 경로는 Linux 패키지 설치에서 /var/log/gitlab/ 기준의 상대 경로입니다. Helm 차트 설치에서 같은 로그를 찾는 위치는 로그 시스템 문서에 설명되어 있습니다.
| 로그 | 기록 내용 | 탐지 용도 |
|---|---|---|
gitlab-rails/production_json.log |
웹 애플리케이션이 처리한 모든 요청: 사용자, IP, 경로, 상태, 파라미터. | 의심스러운 로그인 흐름, 설정 변경, 웹 엔드포인트에 대한 악용 시도. |
gitlab-rails/api_json.log |
모든 REST API 요청: 사용자, IP, 라우트, 상태, 파라미터. | 토큰 남용, API를 통한 대량 데이터 액세스, 탈취된 계정의 자동화. |
gitlab-rails/graphql_json.log |
GraphQL 쿼리와 복잡도. | GraphQL을 통한 열거와 대량 데이터 액세스. |
gitlab-rails/auth_json.log |
속도 제한과 보호된 경로 규칙에 의해 차단된 요청. | 무차별 대입 공격과 자격 증명 대입 공격. |
gitlab-rails/audit_json.log |
파일에 기록된 감사 이벤트. | 스트리밍할 수 없는 티어를 포함한 감사 이벤트의 로컬 사본. |
gitlab-rails/application_json.log |
사용자 생성과 프로젝트 삭제 같은 인스턴스 이벤트. | 계정과 프로젝트 수명 주기 변경. |
gitlab-shell/gitlab-shell.log |
SSH를 통한 Git 작업: 사용자, 프로젝트, 명령. | 배포 키를 포함하여 SSH로 이루어지는 리포지터리 복제와 푸시. |
gitlab-workhorse/current |
HTTPS 기반 Git과 파일 다운로드를 포함한 모든 트래픽의 HTTP 액세스 로그. | HTTPS를 통한 리포지터리 복제, 아티팩트와 내보내기 다운로드, 웹 스캔. |
gitaly/current |
리포지터리 작업과 Git 훅. | 비정상적인 리포지터리 액세스 패턴, 훅 실패. |
sidekiq/current |
백그라운드 job: 가져오기, 내보내기, 미러 업데이트, 알림. | 데이터 유출에 사용되는 프로젝트 내보내기와 미러 구성. |
로그 전반에서 요청 추적#
GitLab이 처리하는 모든 요청에는 상관 관계 ID가 부여되며, 같은 ID가 Workhorse에서 Rails, Gitaly, Sidekiq까지 요청이 거치는 모든 로그에 나타납니다. 한 로그에서 의심스러운 항목을 발견하면 모든 로그에서 해당 상관 관계 ID를 검색하여 전체 요청을 재구성합니다. 자세한 내용은 상관 관계 ID로 관련 로그 항목 찾기를 참고합니다.
애플리케이션 로그를 플랫폼으로 전송#
GitLab Self-Managed : 원하는 로그 전송 도구로 각 노드의 로그를 로그 플랫폼에 전송합니다. GitLab은 로그를 로컬에서 순환시키고 결국 오래된 파일을 삭제하므로, 순환으로 삭제되기 전에 전송합니다. 순환을 조정하려면 로깅 구성을 참고합니다. 다중 노드 배포에서는 플랫폼이 모든 노드의 로그를 집계하도록 하여 상관 관계 ID 검색이 전체 요청을 포괄하게 합니다.
GitLab Dedicated : GitLab은 애플리케이션 로그와 인프라 로그를 사용자 AWS 계정의 Amazon S3 버킷으로 전달하고 1년간 보관합니다. Switchboard에서 로그 수집기에 버킷 읽기 액세스 권한을 부여하고, 로그가 1년보다 오래 필요하면 자체 스토리지에 복사합니다. 설정 단계는 GitLab Dedicated의 애플리케이션 로그를 참고합니다.
그 밖의 보안 데이터 출처#
감사 이벤트와 애플리케이션 로그 외에도 보안과 관련된 데이터를 기록하는 GitLab 기능이 여러 가지 있으며, 이를 직접 검토하거나 탐지에 가져와 사용할 수 있습니다. 대부분은 별도의 수집 설정 없이 GitLab UI에서 사용할 수 있고, 여러 가지는 모든 티어에서 사용할 수 있습니다.
| 데이터 출처 | 사용 가능 여부 | 보여 주는 내용 |
|---|---|---|
| 로그인 감사 이벤트 | 모든 티어 | 사용자 프로필의 Authentication log에 표시되는 사용자의 성공한 로그인. Free에서 사용할 수 있는 유일한 감사 이벤트입니다. |
| CI/CD job 로그 | 모든 티어 | 실행된 명령, 노출된 시크릿, 예상하지 못한 사용자가 시작한 파이프라인. 저장 및 보관은 job 로그 관리를 참고합니다. |
| Job 토큰 인증 로그 | 모든 티어 | CI/CD job 토큰으로 프로젝트에 인증한 프로젝트. |
| 자격 증명 인벤토리 | Ultimate | 인스턴스 또는 최상위 그룹에 있는 개인, 그룹, 프로젝트 액세스 토큰, SSH 키, GPG 키와 범위 및 만료 정보. |
| 시크릿 푸시 보호 및 파이프라인 시크릿 탐지 | 시크릿 푸시 보호: Ultimate. 파이프라인 시크릿 탐지: 모든 티어. | 사용자가 푸시하려고 시도했거나 리포지터리에 커밋된 시크릿. |
다음 단계#
텔레메트리가 SIEM 또는 로그 플랫폼에 도달한 뒤에는 다음을 진행합니다:
- 모니터링할 신호를 정하고 TLDR 탐지 규칙을 배포하려면 탐지 역량 구축을 참고합니다.
- 탐지가 의존하는 이벤트 유형, 특히 스트리밍 전용 이벤트가 플랫폼에 도달하는지 확인합니다. 스트리밍 대신 API로 감사 이벤트를 수집한다면, 받지 못하는 이벤트에 의존하는 탐지가 무엇인지 확인합니다.
- 조사와 규정 준수 요구를 충족하는 보관 기간을 정의합니다. GitLab은 저장된 감사 이벤트를 무기한 보관하지만, 실제로 검색할 수 있는 범위는 스트리밍 대상과 로그 플랫폼이 정합니다.