GitHub Proof of Presence: 민감 작업 재인증의 범위와 2시간 예외

기업 계정에서 로그인한 사용자가 토큰을 만들거나 조직 보안 설정을 바꿀 때, 현재 브라우저 세션이 살아 있다는 사실만으로 충분할까요? GitHub는 2026년 9월 24일 Enterprise Cloud용 Proof of Presence(PoP)를 공개 프리뷰로 발표했습니다. 보호되는 고영향 작업 앞에서 사용자를 기업의 ID 제공자(IdP)로 돌려보내 인증 정책을 만족했는지 확인하는, 기업용 sudo mode 확장입니다. 하지만 이 기능을 ‘모든 작업마다 반드시 MFA’라고 설명하면 범위와 보증 수준을 모두 잘못 전달합니다.

관리자에게 필요한 질문은 네 가지입니다. 우리 기업이 이번 프리뷰에 포함되는가, 어떤 작업을 보호하는가, IdP에서 무엇을 요구하는가, 성공한 인증을 얼마 동안 재사용하는가. 아래 내용은 GitHub의 날짜가 명시된 출시 공지와 설정 문서를 대조한 운영 판단입니다. 이 글은 GitHub의 발표·설정 문서에 근거한 적용 판단이며, 실제 기업 테넌트의 인증 흐름이나 침해 방지 효과를 독립 시험하지 않았습니다.

로그인 상태와 민감 작업의 확인을 분리하기

기본 로그인은 현재 세션으로 GitHub를 사용하는 조건이고, PoP는 보호되는 sudo mode 작업을 진행하기 직전에 IdP 정책을 다시 확인하는 조건입니다. GitHub 공지는 토큰 생성, 웹훅 수정, 조직 보안 설정 변경, 복구 코드 열람을 예로 듭니다. 설정 문서는 기존 sudo mode가 보호하는 작업이 PoP 도전을 유발한다고 설명합니다. 따라서 모든 페이지 열람이나 모든 API 호출에 별도 도전이 걸린다고 확장하면 안 됩니다.

작업을 시도하면 GitHub가 기업의 IdP로 리디렉션하고, 사용자가 해당 정책을 만족한 증명을 가지고 돌아왔을 때 작업을 이어가도록 허용합니다. 도전을 마치지 못한 사용자는 기업/IdP 관리자에게 문의하도록 공식 문서가 안내합니다. 아래 도식은 공식 설명을 경계별로 다시 그린 것이지 실제 로그인 화면이나 공격 차단 시험이 아닙니다.

GitHub가 보호되는 sudo-mode 작업에서 IdP로 보내는 흐름을 재구성했다. 실제 로그인 화면이나 차단 성공률이 아니다. 출처: github.blog/changelog/2026-09-24-require-proof-of-presence-for-high-impact-actions.

이 경계는 유효한 세션만 가진 행위자가 민감 설정에 도달하는 위험을 줄이려는 통제입니다. 공식 발표가 보안 자세 개선을 설명하지만, 이 글에는 공격 성공률이나 침해 감소율을 측정한 자료가 없습니다. ‘탈취 세션이면 언제나 차단된다’는 식의 절대적 보장 대신, 보호 작업·IdP 정책·세션 재사용 조건을 함께 살펴야 합니다.

누가 지금 쓸 수 있나: 출시 공지와 설정 문서의 온도 차

2026년 9월 24일 출시 공지는 이 공개 프리뷰를 github.com과 GHEC-DR의 Enterprise Managed Users(EMU) 기업 가운데 Microsoft Entra ID를 SAML 또는 OIDC SSO IdP로 쓰는 경우로 한정합니다. 공식 설정 문서는 ‘GitHub Enterprise Cloud의 enterprise accounts’라고 넓게 시작하고, 지원 IdP로 Entra ID를 적으며, 선행 조건에는 개인 계정 기업의 SAML SSO 설정 안내도 포함합니다. 두 문장의 범위가 완전히 같다고 취급할 근거는 아닙니다.

실무적으로는 날짜가 명시된 출시 공지의 좁은 프리뷰 조건을 기본으로 판단하세요. 개인 계정 기반 기업이나 다른 배포 형태라면 문서의 일반적 선행 조건만 보고 이번 출시 대상이라고 결론 내리지 말고 실제 테넌트의 옵션·자격을 GitHub에 확인해야 합니다. ‘지원 IdP가 Entra ID’라는 설명도 다른 모든 IdP에서 바로 사용할 수 있다는 뜻이 아닙니다. 프리뷰는 변경될 수 있으므로 향후 문서가 바뀌면 적용 시점과 조건을 다시 확인해야 합니다.

출시 공지는 프리뷰 대상을 좁게 정한다. 설정 문서의 넓은 표현만으로 개인 계정 기업의 출시 자격을 단정하지 않는다. 출처: docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/configuring-proof-of-presence.

암호 재확인과 MFA는 동의어가 아니다

GitHub는 기업 관리자가 고를 수 있는 두 인증 요구를 나눕니다. Re-authentication은 IdP에 다시 인증하는 방식으로, IdP 정책에 따라 암호만으로 충족할 수 있습니다. MFA는 재인증에 더해 IdP가 구성한 인증 앱이나 생체 인증 같은 추가 다중 요소 도전을 요구합니다. 두 선택 모두 GitHub 내부에 별도의 암호 입력란을 만드는 설명이 아니라 IdP 도전으로 이어진다는 점이 중요합니다.

예를 들어 규제 요구가 ‘민감 설정 전 추가 요소 확인’이라면 GitHub 메뉴를 켰다는 사실만으로 충족했다고 기록하지 말고 MFA 선택과 Entra ID 정책의 실제 보증 수준을 함께 검토해야 합니다. 반면 재인증만 고른 조직은 조건에 따라 암호 재입력으로 통과할 수 있으므로 ‘반드시 MFA’라고 안내해서는 안 됩니다. 장치 준수 확인 같은 정책도 GitHub가 도전을 위해 IdP로 보낸다는 공지의 예시이지, 모든 조직에서 자동 적용되는 값은 아닙니다.

두 방식 모두 IdP로 이동하지만 재인증만으로 MFA가 보장되지는 않는다. 실제 설정 화면은 아니다. 출처: github.blog/changelog/2026-09-24-require-proof-of-presence-for-high-impact-actions.

관리자를 위한 네 칸 판단표

아래 표는 출시 공지와 설정 문서를 관리자 의사결정으로 바꾼 편집상 도구입니다. GitHub가 이 표의 순서를 인증하거나 특정 테넌트에 적합하다고 승인한 것은 아닙니다.

확인할 질문	공식 자료에서 확인한 범위	관리자의 결정
우리 테넌트가 이번 프리뷰 대상인가?	9월 24일 출시 공지는 github.com·GHEC-DR의 EMU 기업과 Entra ID SAML/OIDC SSO로 한정	계정·배포·SSO 조건을 대조하고, 문서 표현과 다른 경우 GitHub에 자격 확인
어느 작업에서 확인하나?	보호되는 sudo mode 작업에서 IdP로 리디렉션	토큰 생성·웹훅 수정·조직 보안 설정·복구 코드 열람 등 민감 작업을 점검하고 모든 클릭에 적용된다고 가정하지 않기
어떤 보증을 요구하나?	재인증은 IdP 정책에 따라 암호만으로도 통과할 수 있고, MFA 선택은 추가 요소를 요구	필요한 보증 수준에 맞춰 IdP 정책과 GitHub 선택지를 함께 설정
언제 다시 확인하나?	성공 뒤 같은 브라우저의 sudo-mode 세션에서 2시간 동안 보호 작업을 이어갈 수 있음	매 작업 MFA라고 설명하지 말고 재사용 창을 위협 모델에 반영

기업이 적용 가능하고 IdP 정책을 정했다면 공식 설정 문서는 enterprise의 Settings → Authentication security → Proof of presence 드롭다운에서 요구 사항을 고르도록 안내합니다. 정책은 기업 전체에 적용된다고 문서는 말합니다. 따라서 작은 팀만의 독립된 버튼처럼 가정하지 말고 적용 범위와 지원 절차를 먼저 알리는 편이 낫습니다. 여기서 설명한 경로는 문서상의 설정 안내일 뿐, 이 글이 실제 테넌트에 로그인해 값을 바꾼 결과가 아닙니다.

공식 범위를 관리자의 네 질문으로 재구성한 편집상 판단 도구다. PR 병합 보호는 현재 제공 기능이 아니다. 출처: github.blog/changelog/2026-09-24-require-proof-of-presence-for-high-impact-actions.

2시간 창과 아직 제공되지 않은 보호

GitHub 공지는 도전에 성공하면 같은 브라우저 sudo-mode 세션에서 2시간 동안 추가 PoP 확인 없이 보호 작업을 계속할 수 있다고 명시합니다. 이 숫자는 기업 전체의 토큰 만료 시간이나 다른 기기의 인증 유효기간이 아니라, 공지가 설명하는 동일 브라우저 세션의 재사용 창입니다. 첫 보호 작업의 도전과 그 뒤의 보호 작업을 구분하지 않으면 관리자 교육자료에 ‘설정 변경 하나마다 새 MFA’라는 오해가 들어갑니다.

또한 공지는 pull request 병합 전 PoP 지원을 ‘곧 제공’할 예정이라고 표현합니다. 따라서 현재 프리뷰의 배포된 보호 항목으로 PR 병합을 넣어서는 안 됩니다. 병합 승인 통제가 당장 필요하다면 별도 현재 정책을 검토해야 하며, 예정 기능을 현재의 보안 장벽으로 계산하지 마세요. 이것은 병합 기능의 위험성을 실험으로 측정한 결론이 아니라 발표의 제공 시점 표현에 따른 경계입니다.

결국 적용 전 확인할 것은 단일 스위치가 아닙니다. 좁은 출시 자격을 확인하고, 실제 보호 작업을 목록화한 뒤, IdP의 재인증/MFA 정책을 원하는 보증 수준에 맞추고, 같은 세션의 2시간 예외를 운영 문서에 적어야 합니다. 도입 후에는 기업의 실제 정책과 도전 동작을 자체 환경에서 검증해야 합니다. 이 글 자체는 설정 변경이나 인증 실험을 수행하지 않았습니다.

공식 자료

• GitHub Changelog, 「Require proof of presence for high-impact actions」(2026-09-24) - https://github.blog/changelog/2026-09-24-require-proof-of-presence-for-high-impact-actions/
• GitHub Docs, 「Configuring Proof of Presence」(확인 시점의 public preview 안내) - https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/configuring-proof-of-presence

자료의 출시 범위 표현 차이는 해소된 사실처럼 취급하지 않았습니다. 위 판단표와 도식은 공식 내용을 편집해 재구성한 것이며, 공격 시나리오 재현·실제 테넌트 정책 검사·법규 적합성 판정은 포함하지 않습니다.