보안 사고 대응

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

  • GitLab 인스턴스와 GitLab.com의 그룹의 관리자 및 유지보수 담당자를 위한 것입니다.
  • GitLab 서비스와 관련된 다양한 보안 사고에 대응하는 추가 정보와 모범 사례를 제공합니다.
  • 조직에서 정의한 프로세스를 대체하는 것이 아닙니다.

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

경고: 이 가이드에서 언급된 제안/권장 사항은 본인 책임으로 사용하십시오.

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

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

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

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

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

대응

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

  • 토큰의 유형과 범위를 결정합니다.
  • 토큰 소유자 및 토큰 정보를 기반으로 관련 팀을 식별합니다.
    • 개인 액세스 토큰의 경우 개인 액세스 토큰 API를 사용하여 토큰 세부 정보를 빨리 검색할 수도 있습니다.
  • 평가한 후 토큰을 철회하거나 회전합니다. 제품용 토큰을 철회하는 것은 노출된 토큰에 의한 보안 위험과 토큰 철회로 인한 가용성 위험의 균형을 맞추는 것입니다. 토큰을 철회해야 하는 경우:
    • 토큰 철회의 잠재적인 영향을 이해하는 데 자신 있을 때.
    • 회사의 보안 사고 대응 지침을 준수할 때.
  • 자격 증명 노출 시간 및 자격 증명 철회 시간을 문서화합니다.
  • 노출된 토큰과 관련된 무단 활동을 식별하기 위해 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 엔드포인트와 인증하기 위해 사용할 수 있습니다. 이 토큰은 작업이 실행된 사용자와 동일한 API 액세스 권한을 갖습니다. 이 토큰은 작업이 완료된 후에 만료되어 더 이상 사용할 수 없습니다.

일반적으로 CI_JOB_TOKEN은 작업 로그에 표시되지 않습니다. 그러나 다음과 같은 경우 실수로 이 데이터를 노출할 수 있습니다.

  • 파이프라인에서 상세 로깅을 활성화함.
  • 셸 환경 변수를 콘솔에 에코하는 명령 실행.
  • 러너 인프라를 제대로 보호하지 못하는 것으로 인해 데이터를 실수로 노출할 수 있음.

이러한 경우 다음을 해야 합니다.

  • 최근에 저장소의 소스 코드에 어떤 수정 사항이 있는지 확인하십시오. 수정된 파일의 커밋 내역을 확인하여 수정을 한 사용자를 모니터링할 수 있습니다. 의심스러운 편집이 의심된다면 의심스러운 유저 계정 침해 가이드를 사용하여 사용자 활동을 조사하세요.
  • 해당 파일에 의심스러운 수정이 있을 경우, 해당 파일을 호출하는 모든 코드의 의심스러운 수정이 발생할 수 있으며 노출된 비밀로 이어질 수 있으므로 조사해야 합니다.
  • 노출된 비밀을 철회하기 전에 생산 환경 영향을 결정한 후 노출된 토큰을 회전하는 것을 고려하십시오.
  • 사용 가능한 감사 로그를 검토하여 사용자 및 프로젝트 설정에 대한 의심스러운 수정을 확인하십시오. ``` …
GitLab CI/CD를 잘못 구성하여 노출된 비밀

CI 변수로 저장된 비밀이 마스킹되지 않으면, 작업 로그에서 노출될 수 있습니다. 예를 들어, 환경 변수를 echo하는 경우나 자세한 오류 메시지를 만나는 경우 등입니다. 프로젝트 가시성에 따라 작업 로그에 접근할 수 있으며 프로젝트가 공개 상태인 경우 인터넷을 통해서도 접근할 수 있습니다. 이러한 유형의 보안 사고를 완화하기 위해 다음을 고려해야 합니다:

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

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

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

  • 기본 인프라의 보안.
  • GitLab 설치를 최신 상태로 유지.

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

대응

GitLab 인스턴스가 침해되었다고 의심될 경우 다음을 해야 합니다:

  • 의심스러운 계정 활동을 위해 사용할 수 있는 감사 이벤트를 검토하십시오.
  • 모든 사용자(관리자 root 사용자 포함)를 검토하고 필요한 경우 의심스러운 침해된 사용자 계정 가이드에 따르세요.
  • 사용 가능한 경우 자격 증명 인벤토리를 검토하세요.
  • 인스턴스 구성, 데이터베이스, CI/CD 파이프라인 또는 기타 위치에 위치한 민감한 자격 증명, 변수, 토큰 및 비밀을 변경하세요.
  • GitLab의 최신 버전으로 업데이트하고 모든 보안 패치 발표 후에 업데이트하기 위한 계획 채택하기.
  • 또한, 서버가 악의적인 사용자에 의해 침해된 경우 사고 대응 계획에서 수행되는 공통 단계를 다음과 같이 생각해볼 수도 있습니다:
    1. 나중에 조사할 수 있도록 서버 상태 및 로그를 쓰기 전용 위치에 저장합니다.
    2. 인식되지 않는 백그라운드 프로세스를 찾습니다.
    3. 시스템의 열린 포트를 확인합니다. 시작점으로 기본 포트 가이드를 사용할 수 있습니다.
    4. 알려진 좋은 백업 또는 처음부터 호스트를 다시 빌드하고 모든 최신 보안 패치를 적용합니다.
    5. 일반적이지 않은 트래픽을 위한 네트워크 로그를 검토합니다.
    6. 네트워크 모니터링과 네트워크 수준의 제어를 수립합니다.
    7. 인증된 사용자 및 서버에 대한 입출력 네트워크 액세스를 제한합니다.
    8. 모든 로그가 독립적인 쓰기 전용 데이터 저장소로 라우팅되도록 합니다.

이벤트 유형

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

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

보안 사고는 올바로 구성되지 않은 프로젝트 또는 그룹 설정으로 인해 발생할 수 있으며 민감한 또는 자산 소유 데이터에 무단 액세스로 이어질 수 있습니다. 이러한 사고에는 다음과 같은 것들이 포함될 수 있습니다:

  • 프로젝트 가시성 변경.
  • MR 승인 설정 수정.
  • 프로젝트 삭제.
  • 프로젝트에 수상한 웹훅 추가.
  • 보호된 브랜치 설정 변경.

대응

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

  • 사용할 수 있는 감사 이벤트를 검토하여 해당 작업을 수행한 사용자를 확인합니다.
  • 사용자 계정이 의심스러운 경우 의심스러운 침해된 사용자 계정 가이드에 나와 있는 단계를 따르세요.
  • 프로젝트 소유자 및 유지 관리자에게 상담하여 감사 이벤트를 참고하여 설정을 원래 상태로 복원하는 것을 고려해보세요.

이벤트 유형

보안 사고 시 GitLab의 지원 요청

GitLab의 도움이 필요한 경우, 먼저 GitLab 설명서를 검색하세요. 사용자 측의 예비 조사를 수행한 후 추가적인 질문이나 지원이 필요한 경우 지원을 요청해야 합니다. GitLab 지원 서비스의 자격은 라이선스에 따라 결정됩니다.

보안 최적 사례

환경 및 요구에 가장 잘 맞는 제안에 대해 GitLab 보안 설명서를 검토하세요. 자체 관리 GitLab 인스턴스를 실행 중이라면 GitLab 구성 요소 다이어그램을 확인하여 GitLab 설치의 여러 부분을 숙지하세요.

강화 권고사항

GitLab 강화 권고사항을 검토하여 GitLab 환경의 보안 자세를 개선하는 권고사항을 확인하세요.

Git 공격 속도 제한을 상세히 설명한 내용을 통해 남용 공격 속도 제한을 적용하는 것도 고려해보십시오. 남용 공격 속도 제한을 설정함으로써 특정 유형의 보안 사고를 자동으로 완화할 수 있습니다.

탐지

GitLab SIRT는 GitLab SIRT 공개 프로젝트에서 활발히 탐지된 내용의 저장소를 유지합니다.

이 저장소의 탐지 내용은 감사 이벤트를 기반으로 하며 일반적인 시그마 규칙 형식으로 되어 있습니다. 시그마 규칙 변환기를 사용하여 규칙을 원하는 형식으로 가져올 수 있습니다. 시그마 형식 및 관련 도구에 대한 자세한 내용은 해당 저장소를 참조하세요. 귀하의 SIEM에 GitLab 감사 로그를 소화했는지 확인하세요. 감사 이벤트를 원하는 대상지로 소화하기 위해 감사 이벤트 스트리밍 가이드를 따르세요.