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

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

이 가이드를 사용하면 GitLab과 관련된 보안 인시던트를 자신 있게 처리할 수 있습니다. 필요한 경우 가이드는 GitLab 문서의 다른 부분으로 링크합니다.

일반적인 보안 인시던트 시나리오#

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

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

• 패스워드.
• 개인 액세스 토큰.
• 그룹/프로젝트 액세스 토큰.
• 러너 토큰.
• 파이프라인 트리거 토큰.
• SSH 키.

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

• GitLab 토큰 개요
• GitLab CI/CD 변수 보안

대응#

자격 증명 노출과 관련된 보안 인시던트는 토큰 유형과 관련 권한에 따라 낮음에서 중요까지 심각도가 다를 수 있습니다. 이러한 인시던트에 대응할 때:

• 토큰의 유형과 범위를 파악합니다.
• 토큰 정보를 기반으로 토큰 소유자와 관련 팀을 식별합니다.
  • 개인 액세스 토큰의 경우 개인 액세스 토큰 API를 사용하여 토큰 세부 정보를 빠르게 가져올 수 있습니다.
• 범위와 잠재적 영향을 평가한 후 토큰을 취소하거나 교체합니다. 프로덕션 토큰을 취소하는 것은 노출된 토큰이 제기하는 보안 위험과 토큰 취소가 유발할 수 있는 가용성 위험 사이의 균형입니다. 다음의 경우에만 토큰을 취소합니다:
  • 토큰 취소의 잠재적 영향을 확실히 이해한 경우.
  • 회사의 보안 인시던트 대응 가이드라인을 따르는 경우.
• 자격 증명 노출 시간과 자격 증명을 취소한 시간을 문서화합니다.
• GitLab 감사 로그를 검토하여 노출된 토큰과 관련된 무단 활동을 식별합니다. 토큰의 범위와 유형에 따라 다음과 관련된 감사 이벤트를 검색합니다:
  • 새로 만들어진 사용자.
  • 토큰.
  • 악의적인 파이프라인.
  • 코드 변경.
  • 프로젝트 설정 변경.

이벤트 유형#

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

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

대응#

사용자 계정이나 봇 계정이 침해된 것으로 의심되는 경우:

• 현재 위험을 완화하기 위해 사용자를 차단합니다.
• 사용자가 액세스했을 수 있는 모든 자격 증명을 재설정합니다. 예를 들어, Maintainer 또는 Owner 역할을 가진 사용자는 보호된 CI/CD 변수와 러너 등록 토큰을 볼 수 있습니다.
• 사용자 패스워드를 재설정합니다.
• 사용자에게 이중 인증(2FA)을 활성화하도록 하고, 인스턴스 또는 그룹에 2FA를 강제하는 것을 고려합니다.
• 조사를 완료하고 영향을 완화한 후 사용자를 차단 해제합니다.

이벤트 유형#

의심스러운 계정 동작을 식별하기 위해 사용 가능한 감사 이벤트를 검토합니다. 예:

• 의심스러운 로그인 이벤트.
• 개인, 프로젝트, 그룹 액세스 토큰의 생성 또는 삭제.
• SSH 또는 GPG 키의 생성 또는 삭제.
• 이중 인증의 생성, 수정 또는 삭제.
• 리포지터리 변경.
• 그룹 또는 프로젝트 구성 변경.
• 러너 추가 또는 수정.
• 웹훅 또는 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 Self-Managed 고객 및 관리자는 다음에 대한 책임이 있습니다:

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

GitLab을 정기적으로 업데이트하고, 운영 체제와 소프트웨어를 업데이트하고, 벤더 가이드라인에 따라 호스트를 강화하는 것이 중요합니다.

대응#

GitLab 인스턴스가 침해된 것으로 의심되는 경우:

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

이벤트 유형#

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

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

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

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

대응#

프로젝트 설정에 무단 수정이 있다고 의심되는 경우 다음 단계를 고려합니다:

• 사용 가능한 감사 이벤트를 검토하여 해당 작업을 한 사용자를 식별하는 것부터 시작합니다.
• 사용자 계정이 의심스러운 경우 의심되는 침해된 사용자 계정 가이드에 설명된 단계를 따릅니다.
• 감사 이벤트를 참조하고 프로젝트 소유자와 Maintainer의 안내를 받아 설정을 원래 상태로 되돌리는 것을 고려합니다.

이벤트 유형#

• 감사 로그는 target_type 필드를 기준으로 필터링할 수 있습니다. 보안 인시던트 컨텍스트에 따라 이 필드에 필터를 적용하여 범위를 좁힙니다.
• 컴플라이언스 관리 및 그룹과 프로젝트의 감사 이벤트에 대한 특정 감사 이벤트를 찾습니다.

보안 인시던트에 대한 GitLab 지원 요청#

GitLab에 도움을 요청하기 전에 GitLab 문서를 검색합니다. 예비 조사를 완료하고 추가 질문이 있거나 지원이 필요한 경우 지원팀에 연락해야 합니다. GitLab 지원에서 지원을 받을 자격은 라이선스에 따라 결정됩니다.

보안 모범 사례#

환경 관리에 대한 제안은 GitLab 보안 문서를 검토합니다.

강화 권장 사항#

GitLab 환경의 보안 태세 개선에 대한 자세한 내용은 강화 권장 사항을 참조하세요.

Git 남용 속도 제한에 자세히 설명된 남용 속도 제한 구현도 고려할 수 있습니다. 남용 속도 제한 설정은 특정 유형의 보안 인시던트를 자동으로 완화하는 데 도움이 될 수 있습니다.

탐지#

GitLab SIRT는 GitLab SIRT 공개 프로젝트에서 탐지의 활성 리포지터리를 유지 관리합니다.

이 리포지터리의 탐지는 감사 이벤트를 기반으로 하며 일반적인 Sigma 규칙 형식으로 되어 있습니다. Sigma 규칙 변환기를 사용하여 원하는 형식으로 규칙을 가져올 수 있습니다. Sigma 형식 및 관련 도구에 대한 자세한 내용은 리포지터리를 방문하세요. GitLab 감사 로그가 SIEM에 수집되어 있는지 확인합니다. 자체 관리 인스턴스 또는 GitLab.com 최상위 그룹에 대한 감사 이벤트 스트리밍 가이드를 따라 원하는 대상으로 감사 이벤트를 스트리밍해야 합니다.