GitHub Proof of Presence: Re-authentication과 MFA 선택 기준

GitHub Proof of Presence에서는 개인 액세스 토큰·복구 코드·조직 보안처럼 탈취 뒤 피해가 큰 작업을 우선한다면 MFA, 기존 Microsoft Entra ID 정책이 이미 충분히 강하고 운영 마찰을 낮추는 편이 더 중요하다면 Re-authentication을 검토하는 것이 맞습니다. 다만 GitHub에서 고른 이름만으로 통제 강도가 완성되지는 않습니다. 실제 인증 방법은 연결된 IdP 정책에 좌우되고, 어느 쪽이든 성공 뒤에는 2시간의 grace period가 남으므로 Entra 인증 강도와 세션 정책, 실제 프롬프트를 함께 검증해야 합니다.

확인된 사실: GitHub는 2026년 9월 24일 Enterprise Managed Users와 Microsoft Entra ID를 사용하는 Enterprise Cloud 조직을 대상으로 Proof of Presence public preview를 발표했습니다. 기업 소유자는 Enterprise settings의 Authentication security에서 민감 작업 전 fresh authentication을 요구하고, 방식으로 Re-authentication 또는 MFA를 선택할 수 있습니다. 사용자는 연결된 IdP로 이동하며 인증에 실패하면 작업이 차단됩니다.

직접 대조: GitHub 설정 문서와 sudo mode 문서를 함께 보면 보호 범위에는 personal access token과 client secret 생성, webhook 변경, 조직 보안 설정, enterprise IdP IP allow list, ruleset, 복구 코드처럼 계정·자동화·복구 경계를 바꾸는 작업이 포함됩니다. 성공한 인증 뒤에는 2시간 동안 다시 묻지 않는 grace period가 적용됩니다.

POEMORA의 해석: 이 기능은 “MFA를 켰다”는 체크박스보다, 오래된 SSO 세션으로 고위험 작업까지 이어지는 경로를 어디서 끊을지 정하는 운영 통제에 가깝습니다. 따라서 두 옵션은 같은 작업 범위, 같은 사용자 집단, 같은 2시간 창을 놓고 비교해야 합니다.

비교 기준: 같은 네 가지 질문으로 본다

Re-authentication과 MFA를 비교할 때는 인증 단계 수만 세지 말고 아래 네 기준을 같은 순서로 적용합니다.

1. 피해 규모: 자격 증명 생성, 외부 전송 경로 변경, 보안 정책 완화, 복구 수단 열람처럼 한 번의 작업이 장기 접근권이나 데이터 흐름을 바꾸는가?
2. 인증 보증: IdP가 실제로 어떤 인증 방법을 허용하는가? Microsoft Entra authentication strength는 Conditional Access에서 허용할 방법 조합을 정의하며, 기본 제공 정책에는 Multifactor authentication, Passwordless MFA, Phishing-resistant MFA가 있습니다.
3. 운영 마찰: 당직 대응, 자동화 장애 복구, 대규모 조직 관리처럼 짧은 시간에 여러 민감 작업을 수행하는 흐름에서 추가 인증이 어느 정도 지연을 만드는가?
4. 잔여 세션 위험: 인증 직후 2시간 동안 추가 프롬프트 없이 민감 작업을 수행할 수 있다는 사실을 감당할 수 있는가?

Authentication strength와 sign-in frequency는 같은 설정이 아닙니다. 전자는 허용할 인증 방법을 정하고, 후자는 사용자가 다시 인증해야 하는 간격을 정합니다. GitHub Proof of Presence의 선택과 Entra의 두 통제를 별도 항목으로 기록해야 “MFA를 선택했지만 약한 방법이 허용된 경우”와 “강한 방법은 정했지만 너무 오래된 세션을 그대로 둔 경우”를 구분할 수 있습니다.

장단점: Re-authentication과 MFA

Re-authentication

Re-authentication은 사용자를 IdP로 돌려보내 최근 사용자 확인을 다시 받는 방식입니다. GitHub 발표는 이 옵션이 자격 증명을 다시 요구할 수 있지만 반드시 추가 인증 요소를 요구하는 것은 아니라고 설명합니다.

• 장점: 기존 IdP 세션·Conditional Access 설계와 조합하기 쉬우며, 모든 민감 작업에 별도의 MFA 경험을 추가하는 것보다 운영 마찰을 낮출 수 있습니다.
• 단점: 이름만 보고 강한 사용자 확인이라고 판단할 수 없습니다. 실제 프롬프트가 비밀번호 재입력인지, 패스키·보안 키 같은 강한 방법인지 IdP 정책과 테스트 계정으로 확인해야 합니다.
• 맞는 조건: 대상 사용자가 제한적이고, Entra에서 허용 방법과 재인증 조건을 이미 관리하며, 긴급 운영 흐름의 지연 비용이 큰 조직입니다.

MFA

MFA는 Proof of Presence 단계에서 IdP의 다중 요소 인증을 요구하는 선택입니다. 단순한 세션 재확인보다 탈취된 단일 자격 증명만으로 통과할 가능성을 낮추는 방향입니다.

• 장점: PAT·복구 코드·보안 설정처럼 장기 권한과 복구 경계를 바꾸는 작업에 더 명확한 사용자 확인 기준을 세울 수 있습니다.
• 단점: 등록된 방법과 복구 절차가 부실하면 정상 관리자도 차단될 수 있습니다. 너무 잦은 재인증은 사용자가 프롬프트를 기계적으로 승인하거나 악성 요청에도 자격 증명을 입력하는 습관을 만들 수 있습니다.
• 맞는 조건: privileged role, 외부 전송 경로, 장기 자격 증명, 복구 수단을 다루며 phishing-resistant authentication까지 요구할 이유가 분명한 조직입니다.

두 옵션 모두 GitHub가 지정한 민감 작업 집합 앞에서 동작합니다. 현재 설정은 작업별로 서로 다른 방식을 지정하는 표가 아니라 기업 수준에서 Re-authentication 또는 MFA 중 하나를 고르는 구조이므로, 아래 선택표는 제품 설정표가 아니라 조직이 어느 옵션을 채택할지 판단하는 위험 분류표입니다.

적합 대상: 보호 작업별 선택표

이 표의 결론은 조건에 따라 바뀝니다. 예를 들어 Re-authentication을 선택하더라도 Entra Conditional Access가 phishing-resistant authentication strength를 요구하고 실제 재인증을 강제한다면 보증 수준은 높아질 수 있습니다. 반대로 MFA라는 이름을 선택해도 허용 방법, 세션 수명, 예외 계정이 느슨하면 기대한 통제가 나오지 않을 수 있습니다. 그래서 설정 이름보다 실제 IdP 응답과 감사 기록을 기준으로 승인해야 합니다.

선택: 기본값은 MFA, 예외는 검증된 Re-authentication

POEMORA의 권고는 고위험 작업의 피해가 계정 하나를 넘어 조직·자동화·데이터 흐름으로 번질 수 있다면 MFA를 기본값으로 두는 것입니다. Re-authentication은 더 약한 옵션이라는 이유만으로 배제할 것이 아니라, Entra 정책이 실제로 강한 인증 방법과 적절한 재인증을 보장하고 운영 마찰을 줄여야 할 명확한 이유가 있을 때 예외로 검토합니다.

결정 전에 다음 순서로 한 개의 테스트 enterprise에서 확인합니다.

1. 대상이 Enterprise Managed Users와 Microsoft Entra ID 조합인지 확인합니다.
2. 민감 작업 목록을 자격 증명, 외부 전송, 보안 정책, 복구 수단으로 분류합니다.
3. Re-authentication과 MFA 각각에서 실제 IdP 프롬프트와 허용된 인증 방법을 기록합니다.
4. 인증 실패 시 작업이 차단되는지, 성공 뒤 2시간 grace period 안에서 어떤 작업이 이어지는지 확인합니다.
5. 관리자 분실·MFA 장애·IdP 장애를 가정해 break-glass와 복구 절차를 연습합니다.
6. 감사 로그에서 사용자, 작업, 인증 시각, 정책 결과를 함께 추적할 수 있는지 확인합니다.

실패 조건과 한계

다음 중 하나라도 남으면 전사 적용을 미룹니다.

• Enterprise Managed Users·Microsoft Entra ID라는 적용 조건을 충족하지 않습니다.
• MFA를 선택했지만 허용 인증 방법과 예외 계정이 문서화되지 않았습니다.
• Re-authentication의 실제 challenge가 무엇인지 테스트하지 않았습니다.
• 2시간 grace period를 작업마다 다시 인증하는 통제로 오해했습니다.
• 복구 코드와 break-glass 계정이 같은 사람·같은 단말·같은 IdP 장애에 묶여 있습니다.
• 반복 프롬프트의 업무 영향과 피싱 피로를 측정하지 않았습니다.

이 글은 public preview와 현재 공식 문서를 바탕으로 한 정책 비교입니다. 특정 조직의 Entra tenant, Conditional Access 결과, GitHub 감사 로그를 직접 검증한 사례 보고가 아닙니다. 실제 보증 수준은 등록된 인증 방법, 예외 정책, 단말 상태, 역할 배정과 장애 복구 설계에 따라 달라집니다.

도입 결정 뒤에는 GitHub 설정만 켜지 말고, Entra 정책·테스트 계정·감사 로그·복구 절차를 한 묶음으로 남기세요. 자동화와 계정 보안 경계를 함께 점검해야 한다면 POEMORA 자동화 서비스에서 현재 흐름을 기준으로 검증 범위를 정리할 수 있습니다.