Ngày 24/9/2026, GitHub công bố tính năng proof of presence cho GitHub Enterprise Cloud. Quản trị viên có thể yêu cầu thành viên xác thực lại tương tác hoặc vượt qua một thử thách đa yếu tố trước khi thực hiện những hành động có tác động lớn, ví dụ tạo token, sửa webhook, đổi cài đặt bảo mật của tổ chức hay xem mã khôi phục.
Đây không phải trò đùa về giao diện. Trong vài năm gần đây, các vụ tấn công chuỗi cung ứng phần mềm thường bắt đầu bằng cookie phiên bị đánh cắp hoặc token dài hạn bị lộ. Một phiên hợp lệ bị chiếm có thể ra lệnh như chính chủ tài khoản. Với các nhóm phát triển ở Việt Nam làm việc cho khách hàng nước ngoài hoặc tự vận hành hệ thống production, đây là rủi ro trực tiếp chứ không còn là chuyện của doanh nghiệp lớn.
Có gì mới
Proof of presence là bước mở rộng của sudo mode, cơ chế GitHub vốn dùng để bắt xác thực lại trước một số thao tác nhạy cảm. Thay vì chỉ kiểm tra ở cấp tài khoản, tính năng mới đẩy câu hỏi về cho nhà cung cấp định danh (IdP) của doanh nghiệp. GitHub chuyển người dùng sang IdP, IdP kiểm tra theo chính sách mà doanh nghiệp tự đặt, rồi trả kết quả về. Hành động chỉ được tiếp tục nếu người dùng quay lại kèm bằng chứng đã đáp ứng chính sách.
Điểm khác biệt so với chỉ dùng mật khẩu là mục tiêu kiểm tra. Proof of presence xác nhận có một người thật, được cấp quyền, đang thao tác ngay tại thời điểm hành động xảy ra, chứ không chỉ xác nhận rằng có một phiên hoặc token hợp lệ được dùng. Đó chính là chỗ vá được lỗ hổng của kịch bản đánh cắp phiên.
Theo GitHub, tính năng này cũng giúp khách hàng thuộc nhóm bị quản lý chặt đáp ứng yêu cầu tuân thủ về xác thực mới trước các thao tác nhạy cảm, ví dụ các khuôn khổ như FDA Part 11. Với đơn vị làm phần mềm y tế hoặc tài chính có đối tác Mỹ, đây là điểm đáng lưu ý khi đàm phán hợp đồng.
Ai được dùng, ai còn phải chờ
Bản public preview lần này được giới hạn khá hẹp. GitHub nêu rõ phạm vi chỉ gồm các doanh nghiệp dùng managed user (EMU) trên github.com và GHEC-DR, và phải dùng Microsoft Entra ID làm nhà cung cấp định danh SSO, thông qua SAML hoặc OIDC.
Nghĩa là rất nhiều tổ chức dùng GitHub Enterprise Cloud vẫn chưa chạm được tính năng này, dù đã trả tiền cho gói cao. Doanh nghiệp dùng IdP khác, hoặc dùng tài khoản GitHub thường thay vì EMU, cần chờ các đợt mở rộng sau. Nhóm làm việc cá nhân, tài khoản Free hay Team cũng chưa có lựa chọn này.
GitHub cũng cho biết sẽ sớm hỗ trợ proof of presence trước thao tác merge pull request. Đây là điểm đáng theo dõi với các nhóm áp quy trình review nghiêm ngặt, vì merge là bước đưa mã vào nhánh chính, thường là mục tiêu cuối của kẻ tấn công.
Cách bật và hai kiểu xác thực
Nếu doanh nghiệp của bạn dùng Entra ID cho SSO, quản trị viên có thể cấu hình proof of presence với một trong hai mức yêu cầu. Thứ nhất là xác thực lại: thành viên đăng nhập lại với IdP, và tùy chính sách của IdP thì một lần nhập mật khẩu có thể đã đủ. Thứ hai là MFA: thành viên xác thực lại và phải vượt thêm một thử thách đa yếu tố, ví dụ ứng dụng xác thực hoặc sinh trắc học, theo cấu hình trong IdP.
Về hành vi sau khi vượt thử thách, GitHub dùng chung mô hình phiên với sudo mode. Sau khi xác thực thành công, người dùng có thể tiếp tục thực hiện các hành động có tác động lớn trong chính phiên trình duyệt đó trong vòng hai giờ mà không phải kiểm tra lại. Cách này giữ được sự cân bằng giữa an toàn và việc không làm gián đoạn công việc quá nhiều lần trong ngày.
Danh sách hành động bị áp chính sách khá rộng: tạo token, sửa webhook, thay đổi cài đặt bảo mật của tổ chức, xem mã khôi phục. Đây đều là những thao tác mà nếu bị kẻ xấu thực hiện, hậu quả có thể lan ra toàn bộ hệ thống chứ không dừng ở một kho mã.
Vì sao cần lớp chặn này
Cookie phiên và token dài hạn là thứ dễ bị đánh cắp trong các cuộc tấn công chuỗi cung ứng. Một khi kẻ tấn công có được chúng, hệ thống vẫn thấy một phiên hợp lệ và không có lý do gì để nghi ngờ. Bắt người dùng xác thực lại với IdP phá vỡ đúng giả định đó: kẻ đánh cắp phiên không có cách hoàn thành thử thách MFA trên thiết bị của nạn nhân.
Ngoài kịch bản tấn công, lớp chặn còn có ích trước các tác nhân tự động. Khi tổ chức cho agent hoặc công cụ tự động chạy trong CI/CD, một bước xác thực tương tác sẽ buộc con người phải có mặt đúng lúc, tránh việc một tiến trình lạ lặng lẽ leo thêm một bước ngoài kế hoạch.
Nên làm gì bây giờ
Nếu bạn là quản trị viên của một doanh nghiệp GitHub dùng EMU và Entra ID, việc nên làm là đọc tài liệu cấu hình proof of presence, đối chiếu với chính sách bảo mật nội bộ, rồi chọn giữa mức xác thực lại và mức MFA tùy độ nhạy cảm của hệ thống. Đừng bật đại cho toàn bộ tổ chức ngay ngày đầu, vì có thể gây gián đoạn cho các nhóm chưa chuẩn bị thiết bị MFA.
Nếu tổ chức chưa thuộc phạm vi preview, bạn vẫn nên xem lại vệ sinh token và cookie phiên: thu hồi token cũ, rút ngắn thời hạn, kiểm tra thiết bị lạ. Đây là những việc làm được ngay và giảm rủi ro trong lúc chờ tính năng mở rộng.
Thông tin về phạm vi và điều kiện có thể thay đổi sau thời điểm công bố, nên bạn nên kiểm tra lại tại bài changelog chính thức của GitHub. Nếu đang tìm hiểu thêm công cụ cho nhóm phát triển, xem bài về GitHub và GitHub Copilot trên TopỨngDụng.
