GitHubのProof of Presenceで再認証を強化――Entra IDと2時間のセッションを理解する

GitHubが、Entra IDを使うEMU企業向けにProof of Presenceの公開プレビューを発表しました。重要操作前の再認証をIdPへ委ねる仕組みと、MFA設定・2時間のセッションを踏まえた導入判断を整理します。

こはるの読みどころ

「ログイン済み」と「重要操作を任せられる」は分けて考えたいね。認証の強さと、確認結果が有効な時間を一緒に見てみよう！

GitHubで重要な設定を変更するとき、「ログインできているから、そのまま進めてよい」とは限りません。セッションが有効であることと、その操作を本人が今行っていることの間には、確認したい隔たりがあります。

2026年9月24日に発表されたProof of Presenceは、この隔たりに対して、企業の認証基盤へ再確認を求める機能です。ただし、名前から「重要操作のたびに必ずMFAを行う」と受け取ると、実際の動作とはずれてしまいます。

GitHub Enterprise Cloudの認証を管理するなら、どこで再認証が入り、何を満たせば操作を続けられるのかを押さえたいところです。既存のsudo modeとのつながりから、導入時に決めるべき認証要件まで見ていきましょう。

sudo modeの再確認を企業のIdPへつなぐ

GitHubには以前から、ログイン済みでも機密性の高い操作の前に認証を求めるsudo modeがあります。たとえばSSH鍵の追加や個人アクセストークン（PAT）の作成は、アカウントへアクセスする新しい経路を作れるため、この確認の対象です。GitHubのsudo modeの説明で、通常のログインとは別の確認段階であることが分かります。

Proof of Presenceは、その確認に企業のIdentity Provider（IdP、認証基盤）を組み込みます。保護対象の操作で再認証が必要になると、GitHubからIdPへ移動し、要求された認証ポリシーを満たして戻った場合に操作を続けられます。設定ドキュメントは、sudo modeの対象操作とセッションモデルを引き継ぐ仕組みとして説明しています。

ここで増えるのは、重要操作へ進む前の本人確認です。運用上は「誰に操作権限を与えるか」に加え、「その権限を使う前に、どの認証条件を満たしてもらうか」を設計する機能として捉えると分かりやすいですね。

公開プレビューはEntra IDを使うEMU企業が対象

2026年9月24日の公開プレビューは、github.comとデータ所在地を選べるGitHub Enterprise Cloud（GHEC-DR）上のEnterprise Managed Users（EMU）企業が対象です。SSOのIdPにMicrosoft Entra IDを使用し、SAMLまたはOIDCで接続している構成に限定されています。

EMUは、外部IdPからGitHubのユーザーアカウントのライフサイクルと認証を管理する仕組みです。既存の個人アカウントで企業へ参加する構成とは区別されます。EMUの公式説明を踏まえ、まず自社のアカウント方式とSSO接続先を照合すると、導入候補かどうかを判断できます。

設定資料には個人アカウント型企業向けのSSO案内もありますが、今回の公開範囲はリリース告知のEMU限定を基準に捉えるのが妥当です。また、プルリクエストのマージ前にProof of Presenceを要求する対応は、発表時点では今後の予定です。マージ直前の確認を目的に検討する場合は、提供済みの機能と分けて考える必要があります。

再認証とMFAは、求める保証の強さが異なる

対象条件を満たしたら、次は認証要件を選びます。企業の「Settings」から「Authentication security」へ進み、「Proof of presence」で選択します。有効にしたポリシーは企業全体へ適用されます。公式の設定手順では、次の2つが示されています。

選択肢	メンバーに求める認証
Re-authentication	IdPで再認証する。ポリシーによってはパスワードで満たせる
MFA	IdPで再認証し、設定された追加の多要素認証も満たす

つまり、Proof of Presenceを有効にするだけで、必ず追加要素を求める設定になるわけではありません。「再度サインインしてもらう」のか、「追加の要素まで求める」のかを、GitHub側の選択とEntra ID側のポリシーを合わせて決めます。

導入検証では、画面が一度表示されたかだけでなく、意図した認証を満たさなければ保護対象の操作へ進めないかを見たいところです。これは検証時の着眼点であり、実環境での動作確認結果ではありません。認証を完了できないメンバーの問い合わせ先も、GitHubの企業管理者とIdP管理者の間で整理しておくと運用につなげやすくなります。

2時間のセッションを含めて保護の範囲を判断する

認証に成功すると、同じブラウザーセッションでは2時間、追加のProof of Presence確認なしに重要操作を続けられます。毎回その場で認証し直す仕組みとは異なります。

さらに、sudo modeのタイムアウト仕様では、その間に機密性の高い操作を行うとタイマーがリセットされます。Proof of Presenceも同じセッションとタイムアウトモデルを使うため、「最初の認証から必ず2時間後に再確認される」という固定期限としては扱えません。

たとえば、認証後30分で次の保護対象操作を行う場面を考えてみましょう。同じ有効なセッションなら再確認を挟まずに進められ、操作によってタイマーも更新されます。これは仕様を当てはめた説明例です。認証要求を繰り返す負担を抑えられる一方、各操作に対して新しい認証記録が必要な運用とは、要件を突き合わせる必要があります。

Proof of Presenceを導入する意味は、有効なログインだけに頼らず、重要操作の前に企業の認証ポリシーを通すことにあります。自社が求める認証の強さと、その確認結果を再利用できる時間の両方が合っているか。この2点を判断できれば、機能名への期待ではなく、具体的な運用要件に基づいて採用を決められます。