보안 사고 대응

보안 사고가 발생하면 조직에서 정의한 프로세스를 따르어야 합니다. GitLab SIRT 팀이 이 가이드를 작성했습니다.

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

이 가이드를 사용하면 GitLab과 관련된 보안 사고를 자신감 있게 처리할 수 있습니다. 필요한 경우 해당 가이드에서는 다른 GitLab 설명서로의 링크가 제공됩니다.

caution
이 가이드에서 언급된 제안/권고사항은 본인 책임으로 사용해야 합니다.

일반적인 침해 시나리오

공개 인터넷에 자격 증명 노출

이 시나리오는 설정 오류 또는 실수로 민감한 인증 또는 권한 부여 정보가 인터넷에 노출된 보안 사건을 참조합니다. 해당 정보에는 다음과 같은 항목이 포함될 수 있습니다:

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

이 시나리오에는 또한 GitLab 서비스를 통해 제3자 자격 증명에 대한 민감한 정보가 노출될 수 있습니다. 해당 노출은 공개 GitLab 프로젝트에 대한 우연한 커밋이나 CI/CD 설정의 잘못된 구성을 통해 발생할 수 있습니다. 자세한 내용은 아래를 참조하십시오:

대응

자격 증명 노출과 관련된 보안 사고는 토큰의 유형 및 관련 권한에 따라 낮은 것부터 심각한 것까지 다양할 수 있습니다. 이러한 사고에 대응할 때는 다음을 수행해야 합니다:

  • 토큰의 유형 및 범위를 결정합니다.
  • 토큰 소유자 및 토큰 정보에 근거한 관련 팀을 식별합니다.
  • 토큰의 범위와 잠재적인 영향을 평가한 후 토큰을 폐기합니다. 프로덕션 토큰을 폐기하는 것은 서비스 중단을 초래할 수 있으며, 관리자 토큰을 폐기하지 않으면 피해를 입을 수 있습니다. 따라서 다음의 경우에만 토큰을 폐기해야 합니다:
    • 잠재적인 영향에 대해 확신이 있는 경우.
    • 회사의 보안 사고 대응 가이드를 따르고 있는 경우.
  • 자격 증명 노출 시간 및 자격 증명 폐기 시간을 문서화합니다.
  • 노출된 토큰과 관련된 무단 활동을 식별하기 위해 GitLab 감사 로그를 확인합니다. 토큰의 범위 및 유형에 따라 새로 생성된 사용자, 토큰, 악성 파이프라인 실행, 코드 변경 및 프로젝트 설정 변경과 관련된 감사 이벤트를 검색하세요.

이벤트 유형

  • 귀하의 그룹 또는 네임스페이스에 대한 사용 가능한 감사 이벤트를 검토합니다.
  • 이기종자가 지속성을 유지하기 위해 토큰, SSH 키 또는 사용자 계정을 생성하려고 할 수 있습니다. 이러한 활동과 관련된 감사 이벤트를 찾아보세요.
  • CI 관련 감사 이벤트에 중점을 두어 CI/CD 변수에 대한 수정 사항을 식별합니다.
  • 악의적인 사용자가 실행한 파이프라인에 대한 작업 로그를 검토합니다.

의심스러운 유저 계정 침해

대응

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

  • 현재 위험을 완화하기 위해 사용자를 차단합니다.
  • 사용자가 액세스할 수 있었던 모든 자격 증명을 재설정합니다. 예를 들어 최소한 Maintainer 역할을 가진 사용자는 보호된 CI/CD 변수 및 러너 등록 토큰을 볼 수 있습니다.
  • 사용자의 암호를 재설정합니다.
  • 사용자가 이중 인증(2FA)을 활성화하도록 요청하고 인스턴스 또는 그룹 수준에서 2FA 적용을 고려합니다.
  • 조사를 완료하고 영향을 완화한 후에 사용자의 차단을 해제합니다.

이벤트 유형

가용한 감사 이벤트를 확인하여 의심스러운 계정 동작을 식별합니다. 예를 들어:

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

CI/CD 관련 보안 사고

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

  • 노출된 GitLab CI/CD 작업 토큰과 관련된 보안 사고.
  • GitLab CI/CD를 통해 노출된 시크릿.

대응

노출된 GitLab CI/CD 작업 토큰

파이프라인 작업이 실행될 때, GitLab은 고유한 토큰을 생성하고 CI_JOB_TOKEN 미리 정의된 변수로 주입합니다. GitLab CI/CD 작업 토큰은 특정 API 엔드포인트와 인증하기 위해 사용할 수 있습니다. 이 토큰은 작업이 실행되는 동안에만 유효합니다. 작업이 완료되면 토큰이 만료되어 더 이상 사용할 수 없습니다.

일반적으로 CI_JOB_TOKEN은 작업 로그에 표시되지 않습니다. 그러나 파이프라인에서 상세 로깅을 활성화하거나 셸 환경 변수를 콘솔에 출력하는 명령을 실행하거나 러너 인프라를 제대로 보호하지 않는 경우 이러한 데이터가 암시적으로 노출 될 수 있습니다. 이러한 경우에는 다음을 수행해야 합니다:

  • 최근에 리포지터리의 소스 코드에 어떤 수정 사항이 있는지 확인합니다. 수정된 파일의 커밋 기록을 확인하여 해당 변경을 한 사용자를 결정할 수 있습니다. 의심스러운 편집이 있다고 의심되면 사용자 활동을 조사하여 의심스러운 유저 계정 침해 가이드를 참조하세요.
  • 작업을 통해 호출된 코드에 의심스러운 수정 사항이 있으면 문제가 발생할 수 있으므로 조사해야 하며, 노출된 시크릿으로 이어질 수 있습니다.
  • 노출된 시크릿의 프로덕션적인 영향을 결정한 후 노출된 시크릿을 회전하는 것을 고려하세요.
  • 사용자 및 프로젝트 설정에 의심스러운 수정 사항이 있을 경우에 대비하여 사용자 및 프로젝트 설정에 대한 감사 로그를 검토합니다.
GitLab CI/CD를 통해 노출된 시크릿

CI 변수로 저장된 시크릿이 마스킹되지 않을 경우, 작업 로그에서 노출될 수 있습니다. 예를 들어 환경 변수를 에코하는 명령 또는 상세한 오류 메시지를 만나는 경우입니다. 프로젝트 가시성에 따라 작업 로그는 회사 내에서 또는 프로젝트가 공개되어 있으면 인터넷 상에서 액세스할 수 있습니다. 이러한 유형의 보안 사고를 완화하기 위해 다음을 수행해야 합니다:

  • 공개 인터넷에 자격증명 노출을 따라 노출된 시크릿을 폐기합니다.
  • 변수를 마스킹함으로써 직접적으로 작업 로그에 표시되지 않도록 처리합니다. 그러나 마스킹은 100% 확실한 보안 방법은 아닙니다. 예를 들어, 마스킹된 변수가 여전히 아티팩트 파일에 기록되거나 원격 시스템으로 전송될 수 있습니다.
  • 변수를 보호함으로써 보호된 브랜치에서만 사용 가능하게 합니다.
  • 공개 파이프라인을 비활성화하여 공개 액세스를 방지합니다.
  • 아티팩트 보관 및 만료 정책을 검토합니다.
  • CI/CD 작업 토큰 보안 가이드에서 자세한 내용을 확인합니다.
  • 노출된 시크릿 시스템에 대한 감사 로그를 확인하려면 AWS의 CloudTrail 로그 또는 GCP의 CloudAudit Logs와 같은 감사 로그를 검토하여 노출 당시에 의심스러운 변경이 있었는지 확인합니다.
  • 사용자 및 프로젝트 설정에 대한 의심스러운 수정 사항이 있는지 확인할 수 있도록 사용 가능한 감사 로그를 검토합니다.

의심스러운 침해된 인스턴스

Self-Managed형 GitLab 고객 및 관리자는 다음과 같은 책임이 있습니다.

  • 기본 인프라의 보안.
  • GitLab 자체를 최신 상태로 유지하는 것.

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

대응

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

  • 의심스러운 계정 활동에 대한 사용 가능한 감사 이벤트를 확인합니다.
  • 모든 사용자(관리자 루트 사용자 포함)를 검토하고 필요한 경우 의심스러운 침해된 사용자 계정 가이드의 단계를 따릅니다.
  • 가능한 경우 자격증명 디렉터리을 검토합니다.
  • 민감한 자격 증명, 변수, 토큰 및 비밀을 변경합니다. 예를 들어, 인스턴스 구성, 데이터베이스, CI/CD 파이프라인 또는 기타 위치에 있는 것들입니다.
  • GitLab의 최신 버전으로 업데이트하고 모든 보안 패치 릴리스 후에 업데이트하는 계획을 채택합니다.
  • 또한 악의적인 행위자에 의해 서버가 침해된 경우 사건 대응 계획에서 취해지는 일반적인 단계를 수행합니다.
  • 나중에 조사하기 위해 서버 상태와 로그를 쓰기 전용 위치에 저장합니다.
  • 인식되지 않는 백그라운드 프로세스를 찾습니다.
  • 시스템에서 열린 포트를 확인합니다.
  • 호스트를 잘 알려진 좋은 백업 또는 처음부터 다시 구축하고 최신 보안 패치를 적용합니다.
  • 일반적이지 않은 트래픽을 위해 네트워크 로그를 검토합니다.
  • 네트워크 모니터링 및 네트워크 수준 제어를 설정합니다.
  • 인가된 사용자 및 서버에 대한 수신 및 발신 네트워크 액세스를 제한합니다.
  • 모든 로그가 독립적인 쓰기 전용 데이터 리포지터리로 라우팅되도록 보장합니다.

이벤트 유형

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

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

보안 사고는 부적절하게 구성된 프로젝트 또는 그룹 설정으로 인해 발생할 수 있으며, 그로 인해 민감하거나 독점적인 데이터에 대한 무단 액세스가 가능해질 수 있습니다. 이러한 사건에는 다음과 같은 것들이 포함될 수 있지만 이에 국한되지는 않습니다.

  • 프로젝트 가시성 변경.
  • MR(Merge Request) 승인 설정 수정.
  • 프로젝트 삭제.
  • 프로젝트에 의심스러운 웹훅 추가.
  • 보호된 브랜치 설정 변경.

대응

프로젝트 설정에 무단 수정이 의심된다면 다음 단계를 고려하십시오.

  • 사용 가능한 감사 이벤트를 검토하여 해당 작업을 수행한 사용자를 식별합니다.
  • 사용자 계정이 의심스러운 경우 의심스러운 침해된 사용자 계정 가이드에 기술된 단계를 따릅니다.
  • 감사 이벤트를 참조하고 프로젝트 소유자 및 유지 관리자에게 지침을 얻기 위해 설정을 원래 상태로 되돌릴 수 있도록 고려해 보십시오.

이벤트 유형

보안 사건에 대한 GitLab 지원 요청

GitLab의 도움을 청하기 전에 GitLab 문서를 검색합니다. 귀하의 엔드에서 기초 조사를 수행하고 추가 질문 또는 지원이 필요한 경우 지원을 요청해야 합니다. GitLab 지원 서비스의 자격은 라이선스에 따라 결정됩니다.

보안 최상의 실천 방법

환경 및 요구 사항에 맞는 건의사항에 대해 GitLab 보안 문서를 검토하십시오.

탐지

GitLab SIRT는 GitLab SIRT 공개 프로젝트(https://gitlab.com/gitlab-com/gl-security/security-operations/gitlab-sirt-public/automated-incident-response/-/tree/main/detections?ref_type=heads)에 유용한 탐지 항목을 유지합니다.

이 리포지터리에 있는 탐지 항목은 감사 이벤트를 기반으로 하며 일반적인 Sigma 규칙 형식입니다. 원하는 형식으로 규칙을 얻기 위해 Sigma 규칙 변환기를 사용할 수 있습니다. Sigma 형식 및 관련 도구에 대한 자세한 내용은 리포지터리를 참조하십시오. 귀하의 SIEM에 GitLab 감사 로그가 적재되어 있는지 확인하십시오. GitLab 감사 이벤트를 원하는 대상지로 스트리밍하려면 감사 이벤트 스트리밍 가이드를 따르십시오.