GitHub thêm “bằng chứng hiện diện”: MFA vẫn có cửa sổ hai giờ

lúc 09:41 27 tháng 9, 2026|Tác giả: Ban biên tập QUASA|8 phút đọc

Ngày 24/9/2026, GitHub mở public preview Proof of Presence cho doanh nghiệp dùng Enterprise Managed Users (EMU) và Microsoft Entra ID. Tính năng yêu cầu xác thực lại trước một số thao tác nhạy cảm, nhưng sau khi vượt qua thử thách, phiên trình duyệt có thể tiếp tục thực hiện các thao tác được bảo vệ trong cửa sổ sudo hai giờ mà không gặp thử thách mới.

Đợt preview ngày 24/9 được NEXSIGHT AI WIRE ghi nhận với phạm vi EMU dùng Entra ID. Với quản trị viên, Proof of Presence là lớp kiểm tra qua nhà cung cấp danh tính đặt lên sudo mode: việc đã đăng nhập GitHub chưa đủ để thực hiện một thao tác được bảo vệ khi phiên chưa vượt qua yêu cầu xác thực đó. Chính sách có thể yêu cầu đăng nhập lại hoặc MFA; hai lựa chọn này không cho cùng mức bảo đảm.

Thao tác nào đưa người dùng trở lại Entra ID?

Proof of Presence áp dụng cho các thao tác vốn thuộc phạm vi bảo vệ của sudo mode. Những ví dụ được GitHub nêu gồm tạo token, chỉnh sửa webhook, thay đổi thiết lập bảo mật của tổ chức và xem mã khôi phục. Chúng có điểm chung là có thể ảnh hưởng đến quyền truy cập hoặc mở đường cho một phương thức truy cập khác; đây là lý do kiểm tra danh tính ngay trước thao tác có giá trị hơn việc chỉ dựa vào trạng thái đăng nhập.

Thử thách xuất hiện khi thành viên định thực hiện thao tác được bảo vệ và phiên của họ cần xác thực lại. GitHub chuyển thành viên tới Entra ID để đáp ứng chính sách danh tính của doanh nghiệp, rồi cho phép thao tác tiếp tục nếu họ quay lại với bằng chứng đã hoàn tất yêu cầu. Chỉ mở trang GitHub hay thực hiện một thao tác thông thường không đồng nghĩa với việc luôn bị yêu cầu MFA.

Phạm vi bảo vệ cũng không nên được hiểu là mọi hành động trong kho mã đều đã có bước kiểm tra mới. Chẳng hạn, kiểm tra Proof of Presence trước khi hợp nhất pull request mới được GitHub nêu là khả năng sẽ bổ sung, chưa phải phần đã có trong preview được công bố. Bản đồ thao tác hiện tại vì thế cần bám vào những hành động sudo mode thực sự bảo vệ, thay vì suy rộng từ mức độ quan trọng mà doanh nghiệp tự gán cho một hành động.

Cookie phiên bị đánh cắp bị chặn trong điều kiện nào?

Một cookie phiên bị chiếm có thể khiến yêu cầu gửi tới GitHub trông như đến từ tài khoản đã đăng nhập. Nếu phiên đó chưa có quyền sudo hợp lệ, người sử dụng cookie vẫn phải vượt qua thử thách tại Entra ID trước khi hoàn tất thao tác được bảo vệ. Khi họ không đáp ứng được chính sách xác thực, thao tác không được cho phép tiếp tục. Đây là cơ chế giảm rủi ro từ phiên bị chiếm, không phải cam kết rằng mọi cách dùng phiên bị đánh cắp đều bị chặn.

Mức cản trở thực tế phụ thuộc vào chính sách mà Entra ID áp dụng cho thử thách. Nếu doanh nghiệp chọn xác thực lại và chính sách cho phép hoàn tất bằng mật khẩu, kết quả khác với yêu cầu MFA có thêm yếu tố xác thực. Kiểm tra thiết bị tuân thủ chính sách cũng có thể là một yêu cầu của nhà cung cấp danh tính. Vì vậy, cùng một tên tính năng trên GitHub không tự xác định mức bảo đảm của bước kiểm tra.

Một giới hạn khác liên quan đến tác nhân tự động hoặc tác nhân AI dùng quyền của người đã đăng nhập. Nếu tác nhân chỉ có phiên chưa vượt thử thách, thao tác nhạy cảm phải dừng ở bước xác thực danh tính. Nếu nó có thể sử dụng chính phiên trình duyệt đã được người dùng xác thực và còn quyền sudo, cơ chế này không phê duyệt riêng ý định hay nội dung của từng thay đổi. Đó là suy luận từ mô hình phiên được công bố, không phải kết quả thử nghiệm tấn công mà GitHub đã công bố.

Vì sao MFA vẫn để lại cửa sổ hai giờ?

Proof of Presence kế thừa mô hình phiên của sudo mode. Sau một lần vượt thử thách, thành viên có thể thực hiện thêm thao tác được bảo vệ trong cùng phiên trình duyệt mà chưa phải quay lại Entra ID. Chọn mức MFA vì thế không có nghĩa một lời nhắc MFA mới sẽ xuất hiện trước từng lần tạo token hoặc sửa webhook.

Cửa sổ này cũng không phải hạn chót cố định tính từ lần xác thực đầu tiên. Quy tắc sudo mode của GitHub đặt thời gian chờ hai giờ và đặt lại bộ đếm khi có một thao tác nhạy cảm trong thời gian đó. Nếu các thao tác được bảo vệ tiếp tục diễn ra, quyền sudo có thể còn hiệu lực lâu hơn hai giờ tính từ lần vượt thử thách ban đầu. Điểm cần đưa vào mô hình đe dọa là khoảng thời gian kể từ thao tác nhạy cảm gần nhất, cùng khả năng người khác sử dụng phiên đang có quyền sudo.

Điều này giải thích vì sao thời điểm cookie bị chiếm rất quan trọng. Cookie của một phiên chưa vượt kiểm tra dẫn đến thử thách danh tính trước thao tác được bảo vệ; cookie gắn với phiên đang có quyền sudo tạo ra tình huống rủi ro khác. Proof of Presence không thu hồi token đã tồn tại và cũng không biến mỗi hành động tiếp theo thành một lần phê duyệt độc lập.

Ai thuộc preview và quản trị viên cấu hình ở đâu?

Thông báo ra mắt giới hạn public preview ở doanh nghiệp EMU trên github.com hoặc GitHub Enterprise Cloud with data residency, dùng Microsoft Entra ID làm nhà cung cấp SSO qua SAML hoặc OIDC. Chỉ có giấy phép GitHub Enterprise Cloud và sử dụng Entra ID chưa đủ để kết luận một doanh nghiệp thuộc phạm vi được công bố. Mô hình tài khoản và cách nối SSO đều là điều kiện cần đối chiếu.

Tài liệu cấu hình của GitHub hướng dẫn quản trị viên vào enterprise, mở Settings, chọn Authentication security rồi chọn yêu cầu trong mục Proof of presence. Trang này cũng nêu đường dẫn chuẩn bị SSO cho cả doanh nghiệp dùng tài khoản cá nhân lẫn EMU. Đó là hướng dẫn cấu hình chung; nó không tự xác nhận rằng phạm vi public preview đã mở rộng khỏi EMU như giới hạn trong thông báo ra mắt.

Có hai mức yêu cầu. Re-authentication buộc thành viên xác thực lại với nhà cung cấp danh tính và, tùy chính sách doanh nghiệp, có thể được đáp ứng bằng mật khẩu. MFA buộc xác thực lại kèm một thử thách đa yếu tố bổ sung do doanh nghiệp cấu hình, chẳng hạn ứng dụng xác thực hoặc sinh trắc học. Ở cả hai mức, thành viên không hoàn tất được thử thách phải nhờ quản trị viên enterprise hoặc quản trị viên danh tính xử lý; thao tác được bảo vệ không có đường bỏ qua chỉ vì người đó đã đăng nhập GitHub.

Sau khi bật, chính sách áp dụng trên toàn enterprise. Doanh nghiệp vẫn có thể chọn một nhóm quản trị nhỏ để đánh giá luồng sử dụng, nhưng không thể coi đó là phạm vi giới hạn của chính sách. Một đợt đánh giá có ích nên ghi nhận thao tác tạo token hoặc sửa webhook khi chưa có quyền sudo, thao tác lặp lại sau khi vượt thử thách, trường hợp thử thách Entra ID thất bại và hành vi sau khi quyền sudo hết hiệu lực. Đây là checklist đánh giá do bài viết đề xuất, không phải kết quả thử nghiệm của GitHub.

Proof of Presence hiện là public preview với phạm vi công bố hẹp và yêu cầu xác thực do Entra ID quyết định. Điều đã rõ là bước kiểm tra mới bảo vệ những thao tác thuộc sudo mode khi phiên cần xác thực lại; điều chưa được công bố là thời điểm hỗ trợ kiểm tra trước khi hợp nhất pull request hoặc mở rộng preview sang các cấu hình danh tính khác. Khi đánh giá khả năng bảo vệ, doanh nghiệp cần tính cả chính sách xác thực lẫn thời gian quyền sudo tiếp tục được sử dụng.

Đọc thêm:

Chia sẻ: