--- title: '盗まれたセッションだけで設定変更させない｜GitHubのProof of Presenceを解説' url: 'https://automationse.net/github-enterprise-proof-of-presence-high-impact-actions-guide' markdown: 'https://automationse.net/github-enterprise-proof-of-presence-high-impact-actions-guide.md' date: '2026-09-26' description: ' **SECURITY / 2026年9月24日発表** ## 「ログイン済み」だけで、高リスク操作を許さない GitHub EnterpriseのProof of Presenceは、トークン作成やWebhook変更などの直前に、企業のIdPへ戻して本人確認を要求します。盗まれたセッションの悪用を抑える追加層です。 **高リスク操作**トークン・Webhook・セキュリティ設定など **IdPで確認**再認証またはMFAを要求 **公開プレビュー**発表時点の対象構成は限定的 ## 3行要約 - GitHubは2026年9月24日、Enterpriseの高リスク操作に追加の再認証を要求できる「Proof of Presence（PoP）」を公開プレビューで発表しました。 - 発表時点の対象は、Microsoft Entra IDをSAMLまたはOIDCのSSOに使うEnterprise Managed Users（EMU）のEnterpriseです。 - 認証に成功すると、そのブラウザーセッションでは2時間、高リスク操作を続けられます。MFA設定を選んでも、IdP側のポリシー確認が重要です。 ## 背景：有効なセッションが本人とは限らないブラウザーのセッションCookieや長期トークンが盗まれると、通常のログイン済み状態だけでは本人と攻撃者を見分けにくくなります。とりわけ新しいトークンの作成、Webhookの編集、組織のセキュリティ設定変更は影響が大きい操作です。GitHubのPoPは、その瞬間に企業のIDプロバイダー（IdP）で再認証を求め、既存セッションだけでは先へ進めないようにします。 ## 何が新しいのか PoPはGitHubの既存の「sudo mode」を企業向けに拡張します。対象操作を試みるとGitHubがIdPにリダイレクトし、指定した認証要件を満たした後に操作へ戻ります。選択肢は、IdPでの再認証と追加のMFA（多要素認証）です。GitHubの発表は、後者では認証アプリや生体認証など、IdP側で設定した追加要素を要求できるとしています。 **1 操作**トークン作成などを開始 **2 転送**GitHubからEntra IDへ **3 確認**再認証・MFAを実施 **4 継続**要件を満たせば操作可能 | 対象例 | なぜ重要か | 確認ポイント | |---|---|---| | 個人アクセストークン作成 | 新しい持続的なアクセス手段を作る | 権限と有効期限 | | Webhookの作成・編集 | イベント情報の送信先を変えられる | 送信先と秘密情報 | | 組織のセキュリティ設定変更 | 保護の水準を変えられる | 変更者と監査ログ | | 回復コードの表示 | アカウント復旧に使われる | 表示・保管手順 | 対象例はGitHubの発表とsudo modeのドキュメントに基づきます。プルリクエストのマージ前にもPoPを要求する機能は「今後対応予定」で、現時点の対象として数えてはいけません。 ## 管理者向け導入手順 1. Enterpriseが今回の公開プレビュー対象か確認します。9月24日の発表ではEMUとEntra IDの組み合わせに限定されています。GitHubの一般ドキュメントはより広い構成の説明も含むため、実際の管理画面で提供状況を確かめてください。 2. Enterpriseの設定から「Authentication security」を開き、「Proof of presence」で再認証かMFAを選びます。 3. Entra ID側で、求める認証強度、デバイス条件、失敗時の復旧経路を確認します。「再認証」だけではIdPの設定によってパスワードで満たせる場合があります。 4. テスト用アカウントで対象操作を行い、リダイレクト、成功、失敗、期限切れ後の再チャレンジを確認します。これらはGitHubの設定手順に、導入前の運用検証を加えた編集部案です。IdPの障害時に管理者が作業できなくなる可能性も考え、変更手順と復旧担当を決めておくべきです。 ## 企業・開発者への影響 PoPにより、ブラウザーセッションを持つだけの第三者やエージェントが高リスク設定へ進むことを難しくできます。ただし、正当なユーザーがフィッシングで認証を通してしまうリスクまではなくなりません。またPoPはパスワード・MFA、トークン管理、最小権限、監査ログを置き換えるものではありません。 ## リスクと限界 **「毎回MFA」ではありません。**GitHubは既存sudo modeと同じセッションモデルを用い、チャレンジ成功後はブラウザーセッションで2時間、高リスク操作を続けられると説明しています。操作ごとの追加確認を期待するなら、この時間窓を理解してください。 - 公開プレビューのため、対象構成や挙動は変更される可能性があります。 - 2026年9月24日の発表はEMU＋Entra IDへ限定しています。すべてのGitHub Enterpriseアカウントで直ちに使えるわけではありません。 - IdP側の条件付きアクセスポリシーが弱ければ、求める本人確認強度にならない場合があります。 ## 今後注目すべき点対象IdPやアカウント形態の拡大、プルリクエストのマージへの対応、監査イベントと運用上の例外管理が注目点です。正式提供までは管理画面と最新ドキュメントを確認しながら試験導入するのが妥当です。 **最終確認日：2026年9月26日** ### 参照元（一次情報） - [GitHub Changelog：Require proof of presence for high-impact actions（2026年9月24日）](https://github.blog/changelog/2026-09-24-require-proof-of-presence-for-high-impact-actions/) - [GitHub Docs：Configuring Proof of Presence](https://docs.github.com/en/enterprise-cloud@latest/admin/configuring-settings/hardening-security-for-your-enterprise/configuring-proof-of-presence) - [GitHub Docs：Sudo mode](https://docs.github.com/en/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/sudo-mode) Previous Post Next Post --- ## Navigation - Previous: [AIがファジングの準備からクラッシュ解析まで担当｜GitHub Security LabのTaskflowを安全に試す](https://automationse.net/github-security-lab-ai-fuzzing-taskflow-agent-guide.md)