GitHub Proof of Presence — 토큰 생성·웹훅 수정 전 Entra ID 재인증 강제(9월 24일 공개 프리뷰)
GitHub Proof of Presence(PoP)는 엔터프라이즈 구성원이 토큰 생성, 웹훅 수정, 조직 보안 설정 변경 같은 고위험 작업을 하기 직전에 회사 IdP(신원 공급자)로 다시 인증하게 만드는 엔터프라이즈 정책이다. GitHub은 9월 24일 이 기능을 공개 프리뷰로 내놨다. 대상은 좁다. github.com과 GHEC-DR의 관리형 사용자(EMU) 엔터프라이즈 가운데, SAML이나 OIDC로 Microsoft Entra ID를 SSO에 연결한 곳만 쓸 수 있다.
이름이 낯설 수 있는데, 뜻은 단순하다. "유효한 세션이나 토큰이 있다"가 아니라 "지금 이 순간 권한 있는 사람이 실제로 화면 앞에 있다"를 증명하라는 것이다. 체인지로그는 배경을 이렇게 설명한다. "Stolen session cookies and long-lived authentication tokens have shown up in several recent supply chain attacks."(탈취된 세션 쿠키와 오래 사는 인증 토큰이 최근 여러 공급망 공격에서 등장했다.) 로그인된 브라우저 쿠키 하나만 손에 넣으면 그 사람 행세를 할 수 있는 구조를 막겠다는 얘기다.
sudo 모드와 무엇이 다른가
GitHub에는 원래 sudo 모드가 있다. 이미 로그인한 상태여도 SSH 키 추가나 토큰 생성 같은 작업 앞에서 한 번 더 인증을 요구하고, 통과하면 2시간 동안은 다시 묻지 않는 장치다. 이때 쓸 수 있는 수단은 비밀번호, 패스키, 보안 키, GitHub Mobile, TOTP 앱 코드, 소셜 로그인 이메일로 받은 코드다. 문자 메시지(SMS)는 sudo 확인에 쓸 수 없어서, SMS만 등록한 사람은 비밀번호를 입력하게 된다.
문제는 EMU였다. 문서에 이런 문장이 있다. "If your enterprise uses Enterprise Managed Users, only the setup user will receive prompts to enter sudo mode, as managed user accounts don't have credentials stored on GitHub."(EMU 엔터프라이즈에서는 설정 사용자만 sudo 프롬프트를 받는다. 관리형 계정은 GitHub에 자격증명이 저장돼 있지 않기 때문이다.) 다시 말해 EMU 구성원은 그동안 이 재확인 단계를 사실상 건너뛰고 있었다. 확인해 줄 비밀번호가 GitHub 쪽에 없으니까. 이번 기능이 EMU부터 열린 것도 이 공백을 생각하면 납득이 간다.
PoP는 그 확인을 IdP로 넘긴다. 차이를 표로 정리하면 이렇다.
| 구분 | sudo 모드 | Proof of Presence |
|---|---|---|
| 누가 확인하나 | GitHub 자체 | 엔터프라이즈 IdP(현재 Entra ID만) |
| 인증 수단 | 비밀번호·패스키·보안 키·GitHub Mobile·TOTP | IdP 정책이 정함(재인증 또는 MFA) |
| 켜는 주체 | 기본 동작(개인 설정 없음) | 엔터프라이즈 관리자가 정책으로 |
| 적용 범위 | 개인 계정 | 엔터프라이즈 전체 |
| 유지 시간 | 2시간, 보호 작업을 할 때마다 타이머 초기화 | sudo 모드와 같은 세션 모델 |
보호 대상 작업 목록은 둘이 같다. 문서는 "the same protected actions that trigger sudo mode will trigger a PoP challenge"(sudo 모드를 띄우는 보호 작업이 그대로 PoP 확인을 띄운다)라고 적었다. sudo 모드 문서 기준으로 보면 이렇다.
- 계정: 계정 삭제, 이메일 변경, 새 SSH 키 추가, 서드파티 앱 승인
- 개발자 설정: 클라이언트 시크릿 생성·삭제, 개인 액세스 토큰 생성, 전체 토큰 폐기, OAuth 앱 이전
- 웹훅: 저장소·조직·엔터프라이즈 웹훅의 생성·조회·수정·삭제, 전송 기록 조회와 재전송
- 조직 멤버십: 초대 발송·수정, 멤버 직접 추가, 팀 역할 변경
- 조직 보안: 2FA 강제 여부 등 보안 설정 변경
- 엔터프라이즈 설정: 조직 생성, IdP IP 허용 목록의 앱 접근 설정 변경
- 룰셋: 조직·저장소 룰셋 생성과 수정
- 복구 코드: 인증·SSO 복구 코드 조회, 다운로드, 재생성
문서는 이 목록에 "including but not limited to"(이에 한정되지 않음)를 붙여 두었다. 전부라고 단정할 수는 없다는 뜻이다.
켜는 방법과 Entra ID 쪽 준비
설정 자체는 짧다. 엔터프라이즈 소유자 기준으로 순서는 이렇다.
- 엔터프라이즈 페이지에서 Settings로 들어간다.
- Authentication security를 연다.
- Proof of presence 드롭다운에서 요구 수준을 고른다.
선택지는 두 개다. Re-authentication은 IdP에 다시 로그인만 하면 되고, 회사 정책에 따라 비밀번호만으로 통과될 수도 있다. MFA는 다시 로그인한 뒤 인증 앱이나 생체 인식 같은 추가 인증까지 요구한다. 정책은 엔터프라이즈 전체에 한 번에 걸린다.
여기서 놓치기 쉬운 부분이 있다. 어떤 수단으로 통과하느냐는 GitHub이 아니라 Entra ID가 정한다. 문서도 켜기 전에 IdP 인증 정책이 원하는 보증 수준을 주는지 먼저 확인하라고 적어 두었다. 패스키나 보안 키만 인정하고 싶다면 그건 Entra 쪽 숙제다.
Entra에는 이를 위한 '인증 강도(authentication strength)'라는 조건부 액세스 제어가 있다. 기본 제공 강도 중 '피싱 방지 MFA'는 FIDO2 보안 키, Windows Hello for Business(또는 플랫폼 자격증명), 다단계 인증서 기반 인증만 인정한다. 피싱 방지 MFA란 인증 수단이 로그인 화면과 직접 상호작용해, 가짜 사이트에 코드를 입력하게 만드는 수법이 통하지 않는 방식을 말한다. 푸시 알림이나 문자 코드는 여기에 들지 않는다. 조건부 액세스를 쓰려면 테넌트에 Entra ID P1 라이선스가 있어야 한다. 다만 GitHub의 PoP 요청이 Entra 조건부 액세스 정책과 정확히 어떻게 연결되는지는 GitHub 문서에 구체적으로 나와 있지 않다. 그 매핑은 도입 전에 테스트 테넌트에서 직접 확인해야 할 부분이다.
범위 표기도 하나 짚어 둘 필요가 있다. 체인지로그와 커뮤니티 공지는 EMU 엔터프라이즈 한정이라고 썼다. 반면 설정 문서의 사전 준비 항목에는 개인 계정을 쓰는 엔터프라이즈의 SAML 설정 안내도 함께 링크돼 있다. 일반 SAML 엔터프라이즈라면 메뉴가 보이는지 직접 보는 수밖에 없다.
명세에서 먼저 보인 'PR 머지 전 재인증'
체인지로그 끝에는 "Support for proof of presence before pull request merges is coming soon."(PR 머지 전 PoP 지원이 곧 나온다)이라는 문장이 있다. 이 기능이 어디서 왔는지 보면 흥미롭다. 체인지로그가 링크한 커뮤니티 토론(#64212)은 2023년 8월 18일 올라온 요청으로, FDA Part 11 같은 규제 때문에 PR 승인에 전자서명 수준의 재인증을 넣어 달라는 내용이다. 이번 공지 댓글이 그 토론에 달렸으니 3년 묵은 요청에 대한 첫 답인 셈이다.
이 PR 머지 기능의 흔적이 공개 REST API 명세에 이미 있다. 2026년 10월 2일 이 컴퓨터(macOS, gh 2.101.0)에서 github/rest-api-description 저장소(MIT 라이선스)의 GHEC 명세를 받아 읽기 전용으로 검색해 본 결과다.
gh api -H 'Accept: application/vnd.github.raw' \
repos/github/rest-api-description/contents/descriptions/ghec/ghec.yaml > ghec.yaml
grep -n -A 14 'repository-rule-params-proof-of-presence:' ghec.yaml
grep -c 'rule-params-proof-of-presence' ghec.yaml # 결과: 1 (정의 한 줄뿐)
나온 내용을 줄이면 이렇다.
repository-rule-params-proof-of-presence:
title: ProofOfPresence
description: Require a fresh authentication before a pull request can be merged.
properties:
required_authentication_level:
enum: [reauth, mfa]
"PR을 머지하기 전에 새 인증을 요구한다"는 룰셋 파라미터이고, 값은 설정 화면과 같은 reauth, mfa 두 가지다. 명세 커밋 기록을 거슬러 확인하니 8월 28일 커밋(92dc700)에서 처음 들어왔다. 체인지로그보다 4주 먼저다. 다만 같은 파일 어디에서도 이 스키마를 참조하는 규칙 유형은 아직 없다. 정의만 있고 실제 룰셋 API에 연결되지는 않았다는 뜻이라, 지금 이 값으로 룰셋을 만들 수 있다고 보면 안 된다. 엔터프라이즈 PoP 정책을 조회·변경하는 REST 엔드포인트도 명세에 없다. 지금은 웹 설정 화면이 유일한 경로다.
토큰·앱 자동화엔 무슨 일이 생기나
공지와 문서 어디에도 API 호출이나 토큰 기반 자동화에 대한 언급은 없다. 근거가 되는 건 세션 모델뿐이다. 체인지로그는 확인 후 2시간 유지가 "in that browser session"(그 브라우저 세션 안에서)이라고 적었고, 확인 방식도 사용자를 IdP 화면으로 돌려보내는 흐름이다. 브라우저 리다이렉트를 따라갈 수 없는 PAT나 GitHub App 호출에 이 확인이 걸린다는 설명은 없다. 여기서부터는 공식 설명이 아니라 그 구조에서 읽어 낸 해석이다.
그렇게 보면 PoP가 막는 건 주로 '훔친 브라우저 세션으로 새 권한을 만드는 일'이다. 쿠키를 탈취한 공격자가 새 토큰을 발급하거나 웹훅을 자기 서버로 돌리려 하면 IdP 재인증에서 멈춘다. 체인지로그가 "agents going an extra step without your knowledge"(모르는 사이에 한 단계 더 나아가는 에이전트)를 함께 언급한 것도 같은 맥락이다. 브라우저를 조작하는 AI 에이전트가 사람 세션을 빌려 토큰을 만들려는 상황도 같은 관문에 걸린다고 볼 수 있다.
반대로 이미 밖으로 샌 토큰은 이 기능이 다루지 않는다. 그쪽은 어떤 토큰이 살아 있는지 보는 자격증명 인벤토리 내보내기와 회수 절차가 맡는 영역이다. 서비스 계정 토큰을 앱으로 SSO 승인하는 자동화를 쓰고 있다면, 그 승인 API는 앱 자격증명으로 돈다. 사람 세션 기반인 PoP와는 별개 경로라고 보는 게 맞다.
개인적으로는 켜기 전에 이 순서로 점검하겠다.
- Entra ID 쪽에 GitHub 앱용 조건부 액세스 정책이 있는지, 그 정책이 어떤 인증 수단을 통과시키는지 본다. Re-authentication을 고르면 비밀번호만으로 끝날 수 있다.
- 설정 사용자(EMU setup user)의 복구 경로를 확인한다. IdP 장애 시 SSO 복구 코드가 필요한데, 복구 코드 조회 자체가 보호 작업이다.
- 엔터프라이즈 웹훅이나 룰셋을 자주 만지는 운영자에게 2시간마다 재인증 화면이 뜬다는 걸 미리 알린다.
- 테스트 계정으로 토큰 생성과 웹훅 수정을 한 번씩 해 보고, Entra 로그인 로그에 GitHub 재인증이 어떻게 찍히는지 남겨 둔다.
규제 산업에서 오래 기다린 기능이고, 진짜 무게는 아직 나오지 않은 PR 머지 쪽에 실릴 가능성이 크다. 지금 공개된 엔터프라이즈 설정은 그 전 단계, 계정과 설정을 지키는 첫 칸이다.
인용한 GitHub 문서(docs.github.com)는 CC BY 4.0, REST API 명세와 Microsoft Entra 문서 저장소는 MIT 라이선스이며, GitHub 체인지로그는 원문을 짧게 인용했다.