2026년 7월 경찰청이 GitHub PAT 500개 이상 유출 권고문을 발행한 것을 계기로, GitLab 환경에서 크리덴셜을 점검하는 4단계 절차를 설명한다. 토큰은 발급 후 복사본이 몇 개 존재하는지 알 수 없는 자기완결형 인증 수단이라 MFA도 우회 가능하다는 점이 핵심 리스크다.
핵심 포인트- 토큰은 발급 후 복사본 수를 파악할 수 없고 MFA를 완전히 우회하므로, 플랫폼이 아닌 크리덴셜 자체를 관리해야 한다.
- 파악(Count) → 추적(Monitor) → 교체(Rotate) → 강제(Enforce) 4단계로 토큰 생명주기를 관리한다.
- 취소(Revoke)보다 교체(Rotate)를 권장한다 — v16.3부터 토큰 패밀리 추적으로 도난 토큰이 새 토큰을 생성하면 자동 취소된다.
- 커스텀 토큰 접두어 사용 시 빌트인 시크릿 탐지 메커니즘이 비활성화되는 치명적 맹점이 있다.
- Free·Premium·Ultimate 티어별로 강제 적용 가능한 정책 범위가 크게 다르다.
상세 정리- 리스크 본질: 토큰은 발행 시점에 자기완결형 인증 수단이 되어 이후 복사본 수를 발행자가 알 수 없다. MFA도 토큰 인증을 막지 못한다.
- 1단계 파악(Count): glpat-(PAT), gldt-(deploy), glrt-(runner), glppt-(trigger), glft-(feed), glimt-(inbound email), SSH/deploy key 등 모든 크리덴셜 유형 인벤토리. Free 티어부터 GET /api/v4/personal_access_tokens API로 last_used_before·state=active 필터 활용.
- 2단계 추적(Monitor): last_used_at과 last_used_ips로 회사 IP 외부 접근, 비활성 토큰의 최근 활동 등 의심 패턴 파악. 전체 감사 추적은 Premium+ 필요.
- 3단계 교체(Rotate): POST /api/v4/personal_access_tokens/:id/rotate?expires_at=DATE로 교체. 취소만 하면 공격자의 첫 인증 실패 후 교체 토큰이 활성 상태로 남는 위험이 있어 교체가 권장된다. v16.3부터 토큰 패밀리 추적으로 도난 토큰으로 새 토큰 생성 시 전체 자동 취소.
- 4단계 강제(Enforce): 신규 토큰에 강제 만료 설정(Free, v17.3+ 기본값), 최대 수명 제한(Ultimate only), SSH 키 최대 수명(Ultimate only) 등 조직 정책으로 개인 규율에 의존하지 않는다.
- 티어별 기능: API 조회·취소·교체(모든 티어), 강제 만료(Free+), 감사 이벤트(Premium+), 최대 수명 제한(Ultimate), 크리덴셜 인벤토리 대시보드(Ultimate).
- GitLab.com 차이: SaaS 사용자는 인스턴스 관리자가 될 수 없어 Ultimate 티어 그룹 Owner가 크리덴셜 인벤토리를 통해 PAT를 취소해야 한다.
- 치명적 맹점: 커스텀 토큰 접두어 사용 시 빌트인 시크릿 탐지가 비활성화되며, 자동 유출 시크릿 대응은 공개 프로젝트에만 작동한다.
왜 읽나GitLab 인스턴스를 관리하는 보안팀과 DevOps 엔지니어가 토큰 유출 사고 후 체계적인 크리덴셜 점검과 재발 방지 정책을 수립하는 데 실용적인 절차를 제공한다.
인포그랩·
GitLab Blog·
Twilio Engineering·
Cloudflare Blog·