보안 사고 대응

보안 사고가 발생했을 때, 주로 조직에서 정의한 프로세스를 따라야 합니다. GitLab 보안 운영 팀이 이 가이드를 만들었습니다:

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

이 가이드를 사용하여 GitLab과 관련된 보안 사고를 처리하는 데 자신감을 느낄 수 있어야 합니다. 필요한 경우, 가이드는 GitLab 문서의 다른 부분에 대한 링크를 제공합니다.

경고: 이 가이드에서 언급된 제안/권장 사항은 귀하의 위험으로 사용하십시오.

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

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

이 시나리오는 잘못된 구성 또는 인적 오류로 인해 민감한 인증 또는 권한 정보가 인터넷에 노출된 보안 이벤트를 나타냅니다. 이러한 정보에는 다음이 포함될 수 있습니다:

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

이 시나리오는 GitLab 서비스의 타사 자격 증명에 대한 민감한 정보 노출도 포함될 수 있습니다. 노출은 예를 들어, 공개 GitLab 프로젝트에 대한 우발적인 커밋 또는 CI/CD 설정의 잘못된 구성 등을 통해 발생할 수 있습니다. 더 많은 정보는 다음을 참조하세요:

대응

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

  • 토큰의 유형 및 범위를 결정합니다.
  • 토큰 정보에 따라 토큰 소유자 및 관련 팀을 식별합니다.
    • 개인 액세스 토큰의 경우, 개인 액세스 토큰 API를 사용하여 신속하게 토큰 세부정보를 검색할 수 있습니다.
  • 토큰의 범위와 잠재적인 영향을 평가한 후, 무효화하거나 회전합니다. 프로덕션 토큰을 무효화하는 것은 노출된 토큰이 초래하는 보안 위험과 토큰 무효화로 인해 발생할 수 있는 가용성 위험 간의 균형입니다. 다음 조건을 충족하는 경우에만 토큰을 무효화하십시오:
    • 토큰 무효화의 잠재적 영향을 이해하고 있다고 확신합니다.
    • 회사의 보안 사고 대응 지침을 따릅니다.
  • 자격 증명 노출 시간과 자격 증명을 무효화한 시간을 문서화합니다.
  • 노출된 토큰과 관련된 무단 활동을 식별하기 위해 GitLab 감사 로그를 검토합니다. 토큰의 범위 및 유형에 따라 다음과 관련된 감사 이벤트를 검색합니다:
    • 새로 생성된 사용자.
    • 토큰.
    • 악성 파이프라인.
    • 코드 변경.
    • 프로젝트 설정 변경.

이벤트 유형

  • 그룹 또는 네임스페이스에 대한 감사 이벤트를 검토합니다.
  • 적은 수의 잠입자가 토큰, SSH 키 또는 사용자 계정을 생성할 수 있으므로 이러한 활동과 관련된 감사 이벤트를 확인합니다.
  • CI/CD 변수에 대한 변경 사항을 식별하기 위해 CI 관련 감사 이벤트에 집중합니다.
  • 적대자가 실행한 파이프라인에 대한 작업 로그를 검토합니다.

의심되는 침해된 사용자 계정

대응

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

이벤트 유형

의심스러운 계정 행동을 식별하기 위해 사용할 수 있는 감사 이벤트를 검토하세요. 예를 들어:

  • 의심스러운 로그인 이벤트.
  • 개인, 프로젝트 및 그룹 접근 토큰의 생성 또는 삭제.
  • SSH 또는 GPG 키의 생성 또는 삭제.
  • 2단계 인증의 생성, 수정 또는 삭제.
  • 저장소 변경.
  • 그룹 또는 프로젝트 설정 변경.
  • 러너의 추가 또는 수정.
  • 웹후크 또는 Git 훅의 추가 또는 수정.
  • 권한이 부여된 OAuth 애플리케이션의 추가 또는 수정.
  • 연결된 SAML ID 제공자 변경.
  • 이메일 주소 또는 알림 변경.

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 엔드포인트에 인증할 수 있습니다. 이 토큰은 작업을 실행한 사용자가 API에 접근할 수 있는 동일한 권한을 가집니다. 토큰은 파이프라인 작업이 실행되는 동안만 유효합니다. 작업이 완료된 후, 토큰은 만료되어 더 이상 사용할 수 없습니다.

일반적인 상황에서 CI_JOB_TOKEN은 작업 로그에 표시되지 않습니다. 그러나 다음과 같은 방법으로 의도치 않게 이 데이터를 노출할 수 있습니다:

  • 파이프라인에서 자세히 로그를 활성화하기.
  • 셸 환경 변수를 콘솔에 에코하는 명령을 실행하기.
  • 러너 인프라를 적절하게 보호하지 않으면 의도치 않게 이 데이터가 노출될 수 있습니다.

이런 경우에는:

  • 저장소에서 소스 코드에 대한 최근 수정 사항이 있는지 확인하세요. 수정된 파일의 커밋 기록을 확인하여 변경을 한 행위를 식별할 수 있습니다. 의심스러운 편집이 의심되는 경우, 의심되는 침해된 사용자 계정 가이드를 사용하여 사용자 활동을 조사하세요.
  • 해당 파일에서 호출되는 코드에 대한 의심스러운 수정 사항은 문제를 일으킬 수 있으며, 조사해야 하고 비밀 노출로 이어질 수 있습니다.
  • 복구의 프로덕션 영향을 판단한 후 노출된 비밀을 교체하는 것을 고려하세요.
  • 사용자 및 프로젝트 설정에 대한 의심스러운 수정이 있는지 감사 로그를 검토하세요.
잘못 구성된 GitLab CI/CD를 통한 비밀 노출

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

  • 노출된 비밀 가이드를 따라 노출된 비밀을 철회합니다.
  • 변수를 마스킹하는 것을 고려하세요. 이렇게 하면 작업 로그에 직접적으로 반영되는 것을 방지할 수 있습니다. 그러나 마스킹은 완벽하지 않습니다. 예를 들어, 마스킹된 변수는 여전히 아티팩트 파일에 기록되거나 원격 시스템으로 전송될 수 있습니다.
  • 변수를 보호하는 것을 고려하세요. 이렇게 하면 보호된 브랜치에서만 사용 가능하게 됩니다.
  • 공개적인 파이프라인을 비활성화하여 작업 로그 및 아티팩트에 대한 공개 액세스를 방지하는 것을 고려하세요.
  • 아티팩트 보존 및 만료 정책을 검토하세요.
  • 모범 사례에 대한 자세한 정보를 얻으려면 CI/CD 작업 토큰 보안 가이드를 따르세요.
  • 노출된 비밀 시스템에 대한 감사 로그를 검토하여 (AWS의 CloudTrail 로그 또는 GCP의 CloudAudit 로그 등) 노출 시기에 의심스러운 변경이 있었는지 확인하세요.
  • 사용자 및 프로젝트 설정에 대한 의심스러운 수정 사항을 확인하기 위해 사용 가능한 감사 로그를 검토하세요.

해킹 당했을 가능성이 있는 인스턴스

자체 관리하는 GitLab 고객 및 관리자에게는 다음 책임이 있습니다:

  • 기초 기반 시설의 보안.
  • GitLab 설치를 최신 상태로 유지합니다.

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

대응

GitLab 인스턴스가 해킹당한 것으로 의심되면 다음을 수행해야 합니다:

  • 의심스러운 계정 행동에 대한 감사 이벤트를 검토하세요.
  • 모든 사용자 (관리자 루트 사용자 포함)를 검토하고, 필요시 해킹 의심 사용자 계정 가이드의 단계를 따르세요.
  • 사용 가능한 경우 자격 증명 인벤토리를 검토하세요.
  • 모든 민감한 자격 증명, 변수, 토큰 및 비밀을 변경하세요. 예를 들어, 인스턴스 구성, 데이터베이스, CI/CD 파이프라인 또는 다른 곳에 위치한 것들입니다.
  • GitLab의 최신 버전으로 업데이트하고, 모든 보안 패치 릴리스 후 업데이트할 계획을 채택하세요.
  • 또한, 다음 제안 사항은 악의적인 공격자가 서버를 손상시켰을 때 사고 대응 계획에서 일반적으로 취해지는 단계입니다:
    1. 나중 조사를 위해 서버 상태 및 로그를 한 번만 쓸 수 있는 위치에 저장합니다.
    2. 인식할 수 없는 백그라운드 프로세스가 있는지 확인합니다.
    3. 시스템에서 열린 포트를 확인합니다. 기본 포트 가이드를 시작점으로 사용할 수 있습니다.
    4. 알려진 좋은 백업에서 호스트를 재구성하거나 처음부터 시작하여 최신 보안 패치를 모두 적용합니다.
    5. 비정상적인 트래픽에 대한 네트워크 로그를 검토합니다.
    6. 네트워크 모니터링 및 네트워크 수준의 제어를 설정합니다.
    7. 승인된 사용자 및 서버에만 인바운드 및 아웃바운드 네트워크 액세스를 제한합니다.
    8. 모든 로그가 독립적이고 쓰기 전용 데이터 저장소로 라우팅되도록 합니다.

이벤트 유형

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

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

보안 사건은 잘못 구성된 프로젝트 또는 그룹 설정으로 인해 발생할 수 있으며, 이는 민감하거나 독점적인 데이터에 대한 무단 접근으로 이어질 수 있습니다. 이러한 사건은 다음과 같은 경우를 포함하되 이에 국한되지는 않습니다:

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

대응

프로젝트 설정에 대한 무단 수정이 의심되는 경우, 다음 단계를 고려하세요:

  • 사용자의 활동을 식별하기 위해 사용 가능한 감사 이벤트를 검토하는 것으로 시작하세요.
  • 사용자 계정이 의심스러운 경우, 의심되는 침해 사용자 계정 가이드에 설명된 단계를 따르세요.
  • 감사 이벤트를 참조하고 프로젝트 소유자 및 유지 보수자와 상담하여 설정을 원래 상태로 되돌리는 것을 고려하세요.

이벤트 유형

보안 사건에 대한 지원을 요청하기 위해 GitLab과 연결

GitLab에 도움을 요청하기 전에 GitLab 문서를 검색하세요. 초기 조사를 수행하고 추가 질문이나 지원이 필요한 경우 지원 팀과 연결해야 합니다. GitLab 지원의 지원 자격은 라이센스에 따라 결정됩니다.

보안 모범 사례

귀하의 환경과 요구에 가장 적합한 제안을 위해 GitLab 보안 문서를 검토하세요. self-managed GitLab 인스턴스를 운영하는 경우 GitLab 구성 요소 다이어그램을 검토하여 GitLab 설치의 다양한 부분에 대해 익숙해지는 것을 고려하세요.

강화 권장 사항

GitLab 환경의 보안 태세를 개선하기 위한 권장 사항을 위해 GitLab 강화 권장 사항을 검토하는 것을 고려하세요.

Git abuse rate limit에 명시된 대로 남용 비율 제한을 구현하는 것도 고려할 수 있습니다. 남용 비율 제한 설정은 특정 유형의 보안 사건을 자동으로 완화하는 데 도움이 될 수 있습니다.

탐지

GitLab SIRT는 GitLab SIRT 공개 프로젝트에서 활성 탐지 레포지토리를 유지하고 있습니다.

이 레포지토리의 탐지는 감사 이벤트를 기반으로 하며 일반 Sigma 규칙 형식입니다. 원하는 형식으로 규칙을 얻기 위해 sigma 규칙 변환기를 사용할 수 있습니다. Sigma 형식 및 관련 도구에 대한 자세한 내용은 레포지토리를 참조하세요. GitLab 감사 로그가 SIEM에 수집되어야 합니다. 감사 이벤트 스트리밍 가이드를 따라 원하는 대상으로 감사 이벤트를 스트리밍하세요.