보안 사고 대응

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

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

이 가이드를 사용하면 GitLab과 관련된 보안 사고를 자신있게 처리할 수 있어야 합니다. 필요한 경우, 해당 가이드는 GitLab 문서의 다른 부분으로 연결됩니다.

caution
이 가이드에서 언급된 제안/권고사항은 본인 책임으로 사용하세요.

일반적인 침해 시나리오

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

이 시나리오는 잘못된 구성 또는 실수로 민감한 인증 또는 권한 부여 정보가 인터넷에 노출된 보안 사건을 가리킵니다. 해당 정보에는 다음과 같은 것이 포함될 수 있습니다:

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

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

대응

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

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

이벤트 유형

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

의심스러운 유저 계정 침해

대응

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

이벤트 유형

귀하에게 수행 가능한 감사 이벤트를 검토하여 의심스러운 계정 동작을 식별하세요. 예를 들어:

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

CI/CD 관련 보안 사고

CI/CD 워크플로우는 현대적인 소프트웨어 개발의 핵심 부분이며, 주로 개발자 및 SRE가 프로덕션 환경으로 코드를 빌드, 테스트 및 배포하는 데 사용됩니다. 이러한 워크플로우는 보통 CI/CD 파이프라인 내에서 민감한 시크릿에 액세스해야하므로 설정에 따라 CI/CD와 관련된 보안 사고가 발생할 수 있습니다.

대응

노출된 GitLab CI/CD job 토큰

파이프라인 작업이 실행되기 전에 GitLab은 특정 API 엔드포인트와 인증하기 위해 CI_JOB_TOKEN 사전 정의된 변수로 고유한 토큰을 생성하고 주입합니다. 이 토큰을 사용하여 파이프라인 작업을 실행한 사용자와 동일한 권한으로 API에 액세스할 수 있습니다. 이 토큰은 파이프라인 작업이 실행되는 동안에만 유효합니다. 작업이 완료되면 토큰이 만료되어 더 이상 사용할 수 없게 됩니다.

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

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

CI 변수로 저장된 비밀이 마스킹되지 않았을 때, 작업 로그에서 노출될 수 있습니다. 예를 들어, 환경 변수를 출력하거나 상세한 오류 메시지를 만나는 경우입니다. 프로젝트 가시성에 따라 작업 로그가 회사 내에서 액세스 가능하거나 프로젝트가 공개 상태인 경우 인터넷 상에서 액세스 가능할 수 있습니다. 이러한 유형의 보안 사건을 완화하기 위해 다음과 같은 조치를 취해야합니다:

  • 노출된 비밀 안내를 따라 노출된 비밀 취소하기
  • 변수 마스킹을 고려해야합니다. 이렇게 하면 작업 로그에 직접 표시되지 않습니다. 그러나 마스킹은 완벽하지 않습니다. 예를 들어, 마스킹된 변수가 여전히 artifact 파일에 기록되거나 원격 시스템으로 보내질 수 있습니다.
  • 변수 보호도 고려해야합니다. 이렇게 하면 보호된 브랜치에서만 사용할 수 있습니다.
  • 공개 파이프라인 비활성화를 고려하여 공개 상태에서의 작업 로그 및 artifact 액세스를 방지합니다.
  • artifact 보존 및 만료 정책을 검토합니다.
  • 더 많은 정보를 위해 CI/CD 작업 토큰 보안 안내을 따릅니다.
  • 시스템 액세스 사건에 대해 CloudTrail 로그(AWS) 또는 CloudAudit Logs(GCP)와 같은 노출된 비밀 시스템에 대한 감사 로그를 검토하여 의심스러운 변경 사항이 있는지 확인합니다.
  • 사용자 및 프로젝트 설정에 대한 의심스러운 수정을 위해 사용 가능한 감사 로그를 검토합니다.

의심되는 침해당한 인스턴스

Self-managed GitLab 고객 및 관리자는 다음에 대한 책임이 있습니다:

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

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

대응

GitLab 인스턴스가 침해당했다고 의심되면 다음을 해야합니다:

  • 의심스러운 계정 동작에 대한 사용 가능한 감사 이벤트를 검토합니다.
  • 모든 사용자 (관리 루트 사용자 포함)에 대해 검토하고 필요한 경우 의심스러운 계정 가이드의 단계를 따릅니다.
  • 사용 가능한 경우 자격 증명 인벤토리를 검토합니다.
  • 인스턴스 구성, 데이터베이스, CI/CD 파이프라인 또는 기타 위치에 있는 민감한 자격 증명, 변수, 토큰 및 비밀을 변경합니다.
  • GitLab의 최신 버전으로 업데이트하고 보안 패치 릴리스 후 계획을 채택합니다.
  • 알려진 좋지 않은 백업 또는 내부적으로 모든 최신 보안 패치를 적용하고 호스트를 다시 설정합니다.
  • 인식되지 않는 백그라운드 프로세스를 확인합니다.
  • 시스템에서 개방된 포트를 확인합니다.
  • 네트워크 로그를 확인하여 일반적이지 않은 트래픽을 찾습니다.
  • 네트워크 모니터링 및 네트워크 수준의 제어 설정을 설정합니다.
  • 인바운드 및 아웃바운드 네트워크 액세스를 권한이 있는 사용자 및 서버에만 허용되도록 제한합니다.
  • 모든 로그가 독립적인 읽기 전용 데이터 리포지터리로 전송되도록합니다.

이벤트 유형

시스템 설정, 사용자 권한 및 사용자 로그인 이벤트 관련 변경 사항을 결정하기 위해 시스템 액세스 감사 이벤트를 검토합니다.

프로젝트 또는 그룹 설정 오용

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

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

대응

프로젝트 설정에 무단 수정이 의심된다면, 다음 단계를 고려해야합니다:

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

이벤트 유형

  • 검증을 위해 시스템 액세스 감사 이벤트를 target_type 필드에 대한 필터로 필터링할 수 있습니다. 보안 사건 컨텍스트에 따라 이 필드에 대한 필터를 적용하여 범위를 좁힐 수 있습니다.
  • 컴플라이언스 관리 및 그룹 및 프로젝트에 대한 감사 이벤트에 대한 특정 감사 이벤트를 찾아보세요.

GitLab 보안 사고 지원

GitLab에 도움을 요청하기 전에 GitLab 문서를 검색하십시오. 당사의 기초 조사를 수행하고 추가 질문이나 지원이 필요한 경우에 한해 GitLab 지원으로 문의하세요. GitLab 지원부서의 지원 자격은 라이선스에 따라 결정됩니다.

보안 Best Practices

환경 및 요구 사항에 가장 적합한 제안 사항을 확인하려면 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 감사 이벤트가 수신될 수 있도록 해야합니다. 원하는 대상으로 감사 이벤트를 전송하기 위해 감사 이벤트 스트리밍 가이드를 따르십시오.