보안 사고 대응

보안 사고가 발생한 경우 회사에서 정의한 프로세스를 따라야 합니다. GitLab SIRT 팀이 이 가이드를 만들었습니다:

  • 자체 관리 GitLab 인스턴스 및 GitLab.com 그룹의 관리자 및 유지 관리자를 위해.
  • GitLab 서비스와 관련된 다양한 보안 사고에 대한 응답에 대한 추가 정보 및 모베스트 프랙티스를 제공합니다.
  • 보안 사고를 처리하기 위해 회사에서 정의한 프로세스를 보완하는 것입니다. 이는 대체하지 않습니다.

이 가이드를 사용하면 GitLab과 관련된 보안 사고를 처리하는 데 자신감을 느낄 수 있어야 합니다. 필요한 경우 가이드에서 다른 GitLab 문서로 연결됩니다.

경고: 이 가이드에 나온 제안/권고 사항은 귀하의 책임으로 사용하십시오.

일반적인 침해 시나리오

공개 인터넷으로 자격 증명 노출

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

  • 암호.
  • 개인 액세스 토큰.
  • 프로젝트 액세스 토큰.
  • 러너 토큰.
  • 파이프라인 트리거 토큰.
  • SSH 키.

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

대응

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

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

이벤트 유형

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

의심스러운 유저 계정 침해

대응

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

이벤트 유형

귀하는 사용 가능한 감사 이벤트를 검토하여 의심스러운 계정 활동을 식별할 수 있습니다. 예를 들어:

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

CI/CD 관련 보안 사고

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

  • GitLab CI/CD 작업 토큰 노출과 관련된 보안 사고.
  • 구성되지 않은 GitLab CI/CD를 통해 노출된 비밀을 포함한 보안 사고.

위의 예제들에 있어의 방식으로 주어진 gitlab technical markdown를 한국어로 해석하시오.

노출된 GitLab CI/CD 작업 토큰

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

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

  • 리포지토리의 소스 코드에 최근 수정 내역이 있는지 확인합니다. 수정된 파일의 커밋 내역을 확인하여 변경을 일으킨 사용자를 확인할 수 있습니다. 의심스러운 수정 사항이 있다면 의심스러운 유출된 사용자 계정 가이드를 통해 사용자 활동을 조사합니다.
  • 해당 파일을 호출하는 어떠한 코드에도 의심스러운 수정 사항이 있는 경우 문제가 발생할 수 있으며, 조사되어 노출된 비밀을 야기시킬 수 있습니다.
  • 유효성 폐기의 생산 영향을 결정한 후 노출된 비밀을 교체하는 것을 고려합니다.
  • 사용 가능한 감사 로그에서 사용자 및 프로젝트 설정에 대한 의심스러운 수정 사항을 검토합니다.
GitLab CI/CD를 잘못 구성하여 노출된 비밀

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

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

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

자체 호스트형 GitLab 고객 및 관리자는 다음에 책임을 집니다:

  • 기본 인프라의 보안.
  • GitLab 자체의 최신 상태 유지.

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

응답

만약 GitLab 인스턴스에 침해되었다고 의심한다면, 다음을 수행해야 합니다:

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

이벤트 유형

시스템 액세스 감사 이벤트](../administration/audit_event_types.md#system-access)를 검토하여 시스템 설정, 사용자 권한 및 사용자 로그인 이벤트와 관련된 변경을 결정합니다.

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

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

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

응답

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

  • 먼저 감사 이벤트를 확인하여 해당 작업의 책임을 질 수 있는 사용자를 식별하세요.
  • 사용자 계정이 수상하다고 생각된다면, 의심스러운 침해된 사용자 계정 가이드에 설명된 단계를 따르세요.
  • 감사 이벤트를 참조하고 프로젝트 소유자 및 유지 관리자와 상의하여 설정을 원래 상태로 되돌릴지 고려해 보세요.

이벤트 유형

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

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

보안 Best Practices

환경 및 요구에 가장 적합한 제안을 얻으려면 GitLab 보안 문서를 검토하십시오.

탐지(s)

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 감사 로그가 통합되어 있는지 확인해야 합니다. 원하는 대상지에 감사 이벤트를 스트리밍하기 위해 감사 이벤트 스트리밍 가이드에 따라야 합니다.