잠재적인 보안 사고를 일찍 탐지할수록 영향을 더 많이 제한할 수 있습니다.

GitLab Security Operations 팀은 GitLab Self-Managed 인스턴스의 관리자와 Maintainer, 그리고 GitLab.com 그룹의 관리자와 Maintainer를 위해 이 권장 사항을 작성했습니다. GitLab에서 보안과 관련된 활동에 대한 탐지 범위를 구축하고, 잠재적인 보안 사고를 나타내는 신호를 파악하는 데 활용합니다. 이 권장 사항은 조직이 정의한 탐지 및 모니터링 프로세스를 보완하지만 대체하지는 않습니다.

사고를 확인하면 보안 사고 대응에 따라 사고를 차단하고 해결합니다.

탐지 체계 구축#

효과적인 탐지는 신뢰할 수 있는 데이터 소스, 이를 분석하는 중앙 위치, 원시 활동을 조치 가능한 알림으로 바꾸는 조정된 규칙을 결합합니다.

탐지 데이터 소스#

GitLab은 의심스러운 활동을 탐지하는 데 사용할 수 있는, 보안과 관련된 여러 데이터 소스를 생성합니다.

각 소스에 담긴 내용과 각 제공 형태 및 구독 티어에서 수집하는 방법은 보안 텔레메트리를 참고합니다.

예상치 못한 위치에서의 로그인이나 2단계 인증 변경 같은 의심스러운 인증을 탐지하려면 시스템 액세스 감사 이벤트를 검토합니다.

이벤트를 중앙화하고 SIEM으로 스트리밍#

사고를 거의 실시간으로 탐지하고 조사를 위해 이벤트를 보관하려면 보안 정보 및 이벤트 관리(SIEM) 시스템이나 다른 로그 분석 플랫폼에 데이터를 중앙화합니다.

• 감사 이벤트를 외부 대상으로 스트리밍합니다.
  • GitLab Self-Managed 및 GitLab Dedicated: 인스턴스용 감사 이벤트 스트리밍
  • GitLab.com: 최상위 그룹용 감사 이벤트 스트리밍
• 이벤트를 스트리밍하지 않는다면 감사 이벤트 API로 일정에 따라 수집할 수 있습니다.
• 공격자가 로그와 이벤트를 변경하거나 삭제할 수 없도록 독립적인 쓰기 한 번(write-once, 변경 불가) 데이터 저장소로 라우팅합니다.
• 데이터가 필요해지기 전에 조사 및 규정 준수 요구 사항을 충족하는 보존 기간을 정의합니다.

GitLab 탐지 규칙 사용#

GitLab Security Operations 팀은 GitLab 환경을 위한 오픈 소스 탐지 프레임워크인 TLDR(Threat, Logs, Detection, Respond)을 유지 관리합니다.

각 TLDR 탐지에는 다양한 정보가 포함됩니다.

• Threat 세부 정보: 위협에 대한 설명과 기술적·비즈니스적 영향.
• Logs: 탐지에 필요한 로그 소스와 샘플 이벤트.
• Detection: 일반적인 Sigma 형식의 규칙과, SIEM이 없는 환경을 위한 원시 로그 쿼리.
• Atomic test: 탐지가 동작하는지 확인할 수 있도록 활동을 재현하는 단계.
• Response: 진양성(true positive)을 처리하는 방법에 대한 안내.

탐지는 두 가지 유형으로 나뉩니다.

• 위협 탐지: 2단계 인증 비활성화, 새 관리자 계정, 새 배포 키 또는 프로젝트 액세스 토큰, 머지 리퀘스트 승인 또는 보호된 브랜치 설정 변경처럼 감사 이벤트에 기록되는 의심스럽거나 악의적인 활동.

• 취약점 탐지: 애플리케이션 로그에 기록되는, GitLab Self-Managed의 알려진 취약점을 악용하려는 시도.

이 탐지를 사용하려면 다음과 같이 합니다.

1. 각 탐지에 나열된 로그 소스를 SIEM으로 수집합니다.
2. Sigma 규칙을 SIEM의 쿼리 언어로 변환합니다. 공식 Sigma CLI나 웹 기반 sigconverter.io를 사용합니다.
3. 변환한 규칙을 먼저 모니터링 전용 모드로 배포하고 알림 발생량을 검토합니다.
4. 대기 중인 대응 담당자에게 알림을 라우팅하기 전에 환경에 맞게 규칙을 조정합니다.

탐지 범위 매핑 및 탐지 조정#

탐지를 배포한 후에는 정확성을 유지하고 조직에 중요한 위협을 다루도록 정기적으로 검토합니다.

• 탐지를 MITRE ATT&CK 같은 프레임워크에 매핑하여 어떤 공격자 기법을 탐지할 수 있고 어디에 공백이 있는지 파악합니다.
• 환경의 정상 활동을 기준선으로 설정해 알림이 의미 있는 이탈에 집중하도록 합니다.
• 노이즈가 많은 규칙을 조정하여 심각도가 높은 알림의 신뢰성을 유지합니다.
• 각 탐지가 예상대로 동작하는지 테스트하고 각 규칙의 예상 동작을 문서화합니다. 각 TLDR 탐지에는 이를 위해 사용할 수 있는 atomic test가 포함되어 있습니다.

시나리오별 탐지 대상#

다음 시나리오 대부분은 사고 대응의 일반적인 보안 사고 시나리오와 일치합니다. 각 시나리오에서 나열된 신호를 모니터링합니다. 탐지가 발생해 사고를 확인하면 연결된 대응 단계를 따릅니다.

다음 표는 각 시나리오를 MITRE ATT&CK 기법 예시에 매핑합니다. 이 매핑은 출발점으로 사용하고 조직의 위협 모델에 맞게 조정합니다.

자격 증명 노출 및 토큰 악용#

토큰, 키 또는 다른 자격 증명이 노출되었거나 오용되었음을 시사하는 활동을 주시합니다.

• 개인, 프로젝트 또는 그룹 액세스 토큰의 생성. 특히 예상하지 못한 사용자가 만든 경우.
• SSH 또는 GPG 키의 생성.
• 공격자가 지속성을 유지하는 데 사용할 수 있는 새 사용자 계정의 생성.
• CI/CD 변수나 시크릿을 저장하는 다른 구성의 변경. 지속적 통합 감사 이벤트에 집중합니다.
• 예상하지 못한 사용자가 실행한 파이프라인. 자세한 내용은 job 로그를 검토합니다.

대응 방법은 공용 인터넷에 대한 자격 증명 노출을 참고합니다.

침해된 사용자 계정#

계정을 소유자가 아닌 다른 사람이 사용하고 있다는 신호를 주시합니다.

• 예상하지 못한 IP 주소, 위치, 기기에서의 로그인처럼 의심스러운 로그인 이벤트.
• 개인, 프로젝트 또는 그룹 액세스 토큰의 생성 또는 삭제.
• SSH 또는 GPG 키의 생성 또는 삭제.
• 2단계 인증 설정의 변경.
• 이메일 주소나 알림 설정의 변경.
• 승인된 OAuth 애플리케이션의 추가 또는 수정.
• 연결된 SAML ID 공급자의 변경.

대응 방법은 침해가 의심되는 사용자 계정을 참고합니다.

CI/CD 악용#

시크릿을 노출하거나 공격자가 파이프라인에서 코드를 실행할 수 있게 하는 변경을 주시합니다.

• CI/CD 구성 파일이나 파이프라인 정의의 수정.
• 마스킹과 보호 설정을 포함한 CI/CD 변수의 변경.
• 파이프라인이나 job 아티팩트를 공개적으로 접근할 수 있게 만드는 변경.
• 새 러너의 등록 또는 기존 러너의 변경.
• CI/CD job 토큰의 예기치 않은 사용.

대응 방법은 CI/CD 관련 보안 사고를 참고합니다.

침해된 인스턴스#

GitLab Self-Managed에서는 인스턴스 수준과 호스트 수준의 신호를 주시합니다.

• 시스템 설정, 사용자 권한 또는 로그인 이벤트의 변경을 보여 주는 시스템 액세스 감사 이벤트.
• 새 관리자 계정의 생성, 또는 관리자 root 사용자의 활동.
• 인식할 수 없는 백그라운드 프로세스, 예상하지 못한 열린 포트, 비정상적인 네트워크 트래픽 같은 호스트 수준 지표.

대응 방법은 침해가 의심되는 인스턴스를 참고합니다.

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

데이터를 노출하거나 액세스 제어를 약화시킬 수 있는 변경을 주시합니다.

• 프로젝트 또는 그룹 공개 범위의 변경.
• 머지 리퀘스트 승인 설정의 수정.
• 프로젝트 삭제.
• 의심스러운 웹훅이나 서버 훅의 추가.
• 보호된 브랜치 설정의 변경.

target_type 필드로 감사 이벤트를 필터링해 검색 범위를 좁히고, 컴플라이언스 관리 및 그룹과 프로젝트 감사 이벤트를 검토합니다.

대응 방법은 잘못 구성된 프로젝트 또는 그룹 설정을 참고합니다.

데이터 유출#

소스 코드나 다른 데이터가 GitLab 밖으로 복사되고 있다는 징후를 주시합니다. 이는 침해된 계정이나 토큰으로 공격자가 접근 권한을 얻은 뒤에 발생하는 경우가 많습니다.

• 한 사용자나 토큰이 짧은 기간에 수행한 많은 리포지터리 다운로드 또는 클론.
• 프로젝트 또는 그룹 내보내기와 내보내기 파일 다운로드. 특히 평소 이를 수행하지 않는 사용자가 수행한 경우.
• 리포지터리에 대한 장기 액세스를 제공하는 새 배포 키 또는 배포 토큰.
• 예상하지 못한 사용자의 job 아티팩트 다운로드.
• 비공개 프로젝트나 그룹을 공개로 바꾸는 변경.
• 이전에 확인되지 않은 IP 주소에서 사용된 개인 액세스 토큰.

대응하려면 공용 인터넷에 대한 자격 증명 노출에 따라 관련 자격 증명을 폐기하고, 조직이 정의한 사고 대응 프로세스를 따릅니다.

악용 및 리소스 오용#

CI/CD에서의 암호화폐 채굴처럼 자동화된 악용과 예상치 못한 리소스 소비를 주시합니다.

• 파이프라인 활동, 컴퓨트 분(minutes), 새 러너 등록의 급증.
• 새 계정 생성의 급증.
• 과도한 Git 작업. Ultimate에서는 Git 악용 속도 제한을 구성하여 이러한 패턴 중 일부를 자동으로 완화할 수 있습니다.

대응하려면 조직이 정의한 사고 대응 프로세스를 따르고 보안 강화 권장 사항을 검토합니다.

탐지가 발생했을 때#

탐지가 알림을 발생시키면 이를 분류하여 보안 사고가 진행 중인지 확인합니다.

1. 증거를 보존합니다. 이후 조사를 위해 관련 로그와 감사 이벤트를 쓰기 한 번 저장 위치에 저장합니다.
2. 영향을 받은 사용자, 프로젝트, 그룹, 토큰, 호스트 같은 범위를 확인합니다.
3. 일치하는 시나리오에서 연결된 대응 단계를 따라 사고를 차단하고 해결합니다.
4. 조직이 정의한 사고 대응 프로세스를 따릅니다.

GitLab에 지원 요청#

GitLab에 도움을 요청하기 전에 GitLab 문서를 검색합니다. 예비 조사를 마친 뒤에도 질문이 있거나 지원이 필요하면 GitLab Support에 문의합니다. GitLab Support의 지원 대상 여부는 라이선스에 따라 결정됩니다.

관련 주제#

• 보안 사고
• 보안 텔레메트리
• GitLab 보안
• 감사 이벤트 유형