보안 사고가 발생하면 우선 조직에서 정의한 프로세스를 따릅니다. GitLab Security Operations 팀은 이 가이드를 다음과 같은 목적으로 작성했습니다.

• GitLab Self-Managed 인스턴스와 GitLab.com 그룹의 관리자 및 Maintainer를 위한 가이드입니다.
• GitLab 서비스와 관련된 다양한 보안 사고에 대응하는 방법에 대한 추가 정보와 모범 사례를 제공합니다.
• 보안 사고를 처리하기 위해 조직에서 정의한 프로세스를 보완하는 자료이며, 이를 대체하지 않습니다.

이 가이드를 활용하면 GitLab 관련 보안 사고를 자신 있게 처리할 수 있습니다. 필요한 경우 이 가이드는 GitLab 문서의 다른 부분으로 연결되는 링크를 제공합니다.

사고가 발생하기 전과 발생하는 동안 이를 탐지하려면 보안 사고 탐지를 참고합니다.

일반적인 보안 사고 시나리오#

퍼블릭 인터넷에 자격 증명 노출#

이 시나리오는 잘못된 설정이나 사람의 실수로 인해 민감한 인증 또는 권한 부여 정보가 인터넷에 노출된 보안 이벤트를 가리킵니다. 이러한 정보에는 다음이 포함될 수 있습니다.

• 비밀번호.
• 개인 액세스 토큰.
• 그룹/프로젝트 액세스 토큰.
• 러너 토큰.
• 파이프라인 트리거 토큰.
• SSH 키.

이 시나리오에는 GitLab 서비스를 통해 서드파티 자격 증명에 대한 민감한 정보가 노출되는 경우도 포함될 수 있습니다. 이러한 노출은 예를 들어 퍼블릭 GitLab 프로젝트에 대한 실수로 인한 커밋이나 CI/CD 설정의 잘못된 구성을 통해 발생할 수 있습니다. 자세한 내용은 다음을 참고합니다.

• GitLab 토큰 개요
• GitLab CI/CD 변수 보안

대응#

자격 증명 노출과 관련된 보안 사고는 토큰 유형과 연관된 권한에 따라 심각도가 낮음부터 심각까지 다양합니다. 이러한 사고에 대응할 때는 다음을 수행합니다.

• 토큰의 유형과 범위를 파악합니다.
• 토큰 정보를 기반으로 토큰 소유자와 관련 팀을 식별합니다.
  • 개인 액세스 토큰의 경우 개인 액세스 토큰 API를 사용해 토큰 세부 정보를 빠르게 조회할 수 있습니다.
• 토큰의 범위와 잠재적 영향을 평가한 후 토큰을 취소하거나 순환합니다. 프로덕션 토큰을 취소하는 것은 노출된 토큰이 초래하는 보안 위험과 토큰 취소가 초래할 수 있는 가용성 위험 사이의 균형을 고려해야 하는 일입니다. 다음 조건을 모두 만족하는 경우에만 토큰을 취소합니다.
  • 토큰 취소가 미치는 잠재적 영향을 확실히 이해하고 있는 경우.
  • 회사의 보안 사고 대응 가이드라인을 따르는 경우.
• 자격 증명이 노출된 시점과 자격 증명을 취소한 시점을 기록합니다.
• GitLab 감사 로그를 검토해 노출된 토큰과 관련된 무단 활동이 있는지 확인합니다. 토큰의 범위와 유형에 따라 다음과 관련된 감사 이벤트를 검색합니다.
  • 새로 생성된 사용자.
  • 토큰.
  • 악의적인 파이프라인.
  • 코드 변경 사항.
  • 프로젝트 설정 변경 사항.

이벤트 유형#

• 그룹 또는 네임스페이스에서 사용할 수 있는 감사 이벤트를 검토합니다.
• 공격자는 지속성을 유지하기 위해 토큰, SSH 키, 사용자 계정을 생성하려 시도할 수 있습니다. 이러한 활동과 관련된 감사 이벤트를 확인합니다.
• CI/CD 변수에 대한 수정 사항을 식별하려면 CI 관련 감사 이벤트를 중점적으로 확인합니다.
• 공격자가 실행한 파이프라인에 대한 job 로그를 검토합니다.

이 시나리오에 대한 자세한 내용은 자격 증명 노출 및 토큰 남용을 참고합니다.

사용자 계정 침해 의심#

대응#

사용자 계정이나 봇 계정이 침해되었다고 의심되는 경우 다음을 수행합니다.

• 현재의 위험을 완화하려면 사용자를 차단합니다.
• 해당 사용자가 접근했을 가능성이 있는 자격 증명을 재설정합니다. 예를 들어 Maintainer 또는 Owner 권한을 가진 사용자는 보호된 CI/CD 변수와 러너 등록 토큰을 볼 수 있습니다.
• 사용자 비밀번호를 재설정합니다.
• 사용자에게 2단계 인증(2FA)을 활성화하도록 요청하고, 인스턴스 또는 그룹에 대해 2FA를 강제 적용하는 것을 고려합니다.
• 조사를 완료하고 영향을 완화한 후 사용자를 차단 해제합니다.

이벤트 유형#

사용 가능한 감사 이벤트를 검토해 의심스러운 계정 행동이 있는지 확인합니다. 예를 들면 다음과 같습니다.

• 의심스러운 로그인 이벤트.
• 개인, 프로젝트, 그룹 액세스 토큰의 생성 또는 삭제.
• SSH 또는 GPG 키의 생성 또는 삭제.
• 2단계 인증의 생성, 수정 또는 삭제.
• 리포지터리 변경 사항.
• 그룹 또는 프로젝트 구성 변경 사항.
• 러너 추가 또는 수정.
• 웹훅 또는 Git 훅 추가 또는 수정.
• 승인된 OAuth 애플리케이션 추가 또는 수정.
• 연결된 SAML ID 공급자 변경 사항.
• 이메일 주소 또는 알림 변경 사항.

이 시나리오에 대한 자세한 내용은 침해된 사용자 계정을 참고합니다.

CI/CD 관련 보안 사고#

CI/CD 워크플로는 현대 소프트웨어 개발의 필수적인 부분이며, 주로 개발자와 SRE가 코드를 빌드, 테스트, 프로덕션에 배포하는 데 사용합니다. 이러한 워크플로는 프로덕션 환경에 연결되어 있으므로 CI/CD 파이프라인 내의 민감한 시크릿에 접근해야 하는 경우가 많습니다. CI/CD 관련 보안 사고는 설정에 따라 다양하지만 크게 다음과 같이 분류할 수 있습니다.

• 노출된 GitLab CI/CD job 토큰과 관련된 보안 사고.
• 잘못 구성된 GitLab CI/CD를 통해 노출된 시크릿.

대응#

노출된 GitLab CI/CD job 토큰#

파이프라인 job 이 실행되기 직전에 GitLab은 고유한 토큰을 생성해 CI_JOB_TOKEN 사전 정의된 변수로 주입합니다. GitLab CI/CD job 토큰을 사용하면 특정 API 엔드포인트로 인증할 수 있습니다. 이 토큰은 job을 실행시킨 사용자와 동일한 API 접근 권한을 가집니다. 이 토큰은 파이프라인 job 이 실행되는 동안에만 유효하며, job 이 완료되면 만료되어 더 이상 사용할 수 없습니다.

일반적인 상황에서는 CI_JOB_TOKEN 이 job 로그에 표시되지 않습니다. 하지만 다음과 같은 방식으로 이 데이터가 의도치 않게 노출될 수 있습니다.

• 파이프라인에서 상세 로깅(verbose logging)을 활성화하는 경우.
• 셸 환경 변수를 콘솔에 출력(echo)하는 명령을 실행하는 경우.
• 러너 인프라를 제대로 보호하지 못한 경우.

이러한 경우 다음을 수행합니다.

• 리포지터리의 소스 코드에 최근 수정 사항이 있는지 확인합니다. 수정된 파일의 커밋 기록을 확인하면 변경을 수행한 행위자를 파악할 수 있습니다. 의심스러운 수정이 있다고 판단되면 사용자 계정 침해 의심 가이드를 사용해 사용자 활동을 조사합니다.
• 해당 파일에서 호출하는 코드에 대한 의심스러운 수정도 문제를 일으킬 수 있으므로 조사해야 하며, 시크릿 노출로 이어질 수 있습니다.
• 취소가 프로덕션에 미치는 영향을 파악한 후 노출된 시크릿을 순환하는 것을 고려합니다.
• 사용자 및 프로젝트 설정에 대한 의심스러운 수정 사항이 있는지 사용 가능한 감사 로그를 검토합니다.

잘못 구성된 GitLab CI/CD를 통해 노출된 시크릿#

CI 변수로 저장된 시크릿이 마스킹되지 않으면 job 로그에 노출될 수 있습니다. 예를 들어 환경 변수를 출력(echo)하거나 상세한 오류 메시지가 발생하는 경우입니다. 프로젝트 공개 범위에 따라 job 로그는 회사 내부에서 접근할 수 있거나, 프로젝트가 퍼블릭인 경우 인터넷을 통해 접근할 수 있습니다. 이러한 유형의 보안 사고를 완화하려면 다음을 수행합니다.

• 노출된 시크릿 가이드를 따라 노출된 시크릿을 취소합니다.
• 변수를 마스킹하는 것을 고려합니다. 마스킹하면 job 로그에 변수가 직접 표시되는 것을 방지할 수 있습니다. 하지만 마스킹이 완벽한 것은 아닙니다. 예를 들어 마스킹된 변수라도 아티팩트 파일에 기록되거나 원격 시스템으로 전송될 수 있습니다.
• 변수를 보호하는 것을 고려합니다. 보호하면 보호된 브랜치에서만 변수를 사용할 수 있습니다.
• job 로그와 아티팩트에 대한 공개 접근을 막으려면 퍼블릭 파이프라인을 비활성화하는 것을 고려합니다.
• 아티팩트 보존 및 만료 정책을 검토합니다.
• 모범 사례에 대한 자세한 내용은 CI/CD job 토큰 보안 가이드를 참고합니다.
• 노출 시점에 의심스러운 변경이 있었는지 확인하려면 AWS의 CloudTrail 로그나 GCP의 CloudAudit 로그와 같이 노출된 시크릿이 속한 시스템의 감사 로그를 검토합니다.
• 사용자 및 프로젝트 설정에 대한 의심스러운 수정 사항이 있는지 사용 가능한 감사 로그를 검토합니다.

이 시나리오에 대한 자세한 내용은 CI/CD 남용을 참고합니다.

인스턴스 침해 의심#

GitLab Self-Managed 고객과 관리자는 다음에 대한 책임이 있습니다.

• 기반 인프라의 보안.
• GitLab 설치본을 최신 상태로 유지하는 것.

GitLab을 정기적으로 업데이트하고, 운영체제와 그 소프트웨어를 업데이트하며, 공급업체 가이드에 따라 호스트를 강화하는 것이 중요합니다.

대응#

GitLab 인스턴스가 침해되었다고 의심되는 경우 다음을 수행합니다.

• 의심스러운 계정 행동이 있는지 사용 가능한 감사 이벤트를 검토합니다.
• (관리자 root 사용자를 포함한) 모든 사용자를 검토하고, 필요한 경우 사용자 계정 침해 의심 가이드의 단계를 따릅니다.
• 사용 가능한 경우 자격 증명 인벤토리(Credentials Inventory)를 검토합니다.
• 민감한 자격 증명, 변수, 토큰, 시크릿을 변경합니다. 예를 들어 인스턴스 구성, 데이터베이스, CI/CD 파이프라인 등에 위치한 항목입니다.
• GitLab을 최신 버전으로 업데이트하고, 보안 패치가 릴리스될 때마다 업데이트하는 계획을 수립합니다.
• 또한 다음은 악의적인 공격자에 의해 서버가 침해되었을 때 사고 대응 계획에서 일반적으로 수행하는 단계입니다.
  1. 이후 조사를 위해 서버 상태와 로그를 1회 쓰기(write-once) 위치에 저장합니다.
  2. 인식되지 않은 백그라운드 프로세스를 확인합니다.
  3. 시스템에서 열려 있는 포트를 확인합니다. 기본 포트 가이드를 출발점으로 활용할 수 있습니다.
  4. 정상 상태로 확인된 백업에서 또는 처음부터 호스트를 다시 빌드하고, 최신 보안 패치를 모두 적용합니다.
  5. 비정상적인 트래픽이 있는지 네트워크 로그를 검토합니다.
  6. 네트워크 모니터링과 네트워크 수준의 제어를 수립합니다.
  7. 인바운드 및 아웃바운드 네트워크 접근을 승인된 사용자와 서버로만 제한합니다.
  8. 모든 로그가 독립된 쓰기 전용(write-only) 데이터스토어로 라우팅되도록 합니다.

이벤트 유형#

시스템 설정, 사용자 권한, 사용자 로그인 이벤트와 관련된 변경 사항을 파악하려면 시스템 접근 감사 이벤트를 검토합니다.

이 시나리오에 대한 자세한 내용은 침해된 인스턴스를 참고합니다.

잘못 구성된 프로젝트 또는 그룹 설정#

프로젝트 또는 그룹 설정이 잘못 구성되어 보안 사고가 발생할 수 있으며, 이는 민감한 데이터나 독점 데이터에 대한 무단 접근으로 이어질 수 있습니다. 이러한 사고에는 다음이 포함될 수 있으나 이에 국한되지 않습니다.

• 프로젝트 공개 범위 변경.
• 머지 리퀘스트 승인 설정 수정.
• 프로젝트 삭제.
• 프로젝트에 의심스러운 웹훅 추가.
• 보호된 브랜치 설정 변경.

대응#

프로젝트 설정에 대한 무단 수정이 의심되는 경우 다음 단계를 고려합니다.

• 먼저 사용 가능한 감사 이벤트를 검토해 해당 작업을 수행한 사용자를 식별합니다.
• 사용자 계정이 의심스러워 보이면 사용자 계정 침해 의심 가이드에 설명된 단계를 따릅니다.
• 감사 이벤트를 참고하고 프로젝트 Owner 및 Maintainer에게 자문을 구해 설정을 원래 상태로 되돌리는 것을 고려합니다.

이벤트 유형#

• 감사 로그는 target_type 필드를 기준으로 필터링할 수 있습니다. 보안 사고의 맥락에 따라 이 필드에 필터를 적용해 범위를 좁힙니다.
• 컴플라이언스 관리의 감사 이벤트와 그룹 및 프로젝트의 감사 이벤트를 구체적으로 확인합니다.

이 시나리오에 대한 자세한 내용은 잘못 구성된 프로젝트 또는 그룹 설정을 참고합니다.

보안 사고 지원을 위해 GitLab에 문의하기#

GitLab에 도움을 요청하기 전에 GitLab 문서를 먼저 검색합니다. 자체적으로 예비 조사를 수행한 후 추가 질문이 있거나 지원이 필요한 경우에 지원팀에 문의합니다. GitLab Support의 지원 대상 여부는 보유한 라이선스에 따라 결정됩니다.

보안 모범 사례#

환경 관리에 대한 제안을 확인하려면 GitLab 보안 문서를 참고합니다.

강화 권장 사항#

GitLab 환경의 보안 태세를 개선하는 방법에 대한 자세한 내용은 강화 권장 사항을 참고합니다.

Git 남용 사용량 제한에서 자세히 설명하는 것처럼 남용 사용량 제한을 도입하는 것도 고려할 수 있습니다. 남용 사용량 제한을 설정하면 특정 유형의 보안 사고를 자동으로 완화하는 데 도움이 될 수 있습니다.