Áp dụng nguyên tắc Zero Trust trong quản lý quyền truy cập doanh nghiệp.

Đặt tài nguyên cần bảo vệ vào trung tâm

Theo NIST SP 800-207, không nên mặc nhiên tin cậy chỉ vì vị trí mạng hoặc quyền sở hữu thiết bị. Việc truy cập cần được xác thực và cho phép theo chính sách phù hợp với tài nguyên, danh tính và các điều kiện liên quan. Được vào một tài nguyên không tự động đồng nghĩa được vào tài nguyên khác.

Với doanh nghiệp, câu hỏi đầu tiên nên là công việc nào đang phụ thuộc dữ liệu hoặc dịch vụ cần bảo vệ. Hồ sơ nhân sự, hệ thống đặt hàng và công cụ hỗ trợ khách hàng có mức nhạy cảm cùng yêu cầu sẵn sàng khác nhau. Nếu chỉ bắt đầu từ sơ đồ mạng, nhóm có thể kiểm soát được đường đi nhưng chưa hiểu quyền thao tác cần giới hạn.

Chủ nghiệp vụ cần giúp xác định ai được đọc, thay đổi, xuất hoặc phê duyệt thông tin. IT chuyển các nhu cầu đó thành cơ chế kỹ thuật và vận hành; bảo mật đánh giá điều kiện bảo vệ. Khi chưa rõ chủ dữ liệu hoặc vai trò công việc, chính sách truy cập khó chính xác dù công cụ có khả năng đánh giá nhiều tín hiệu.

Zero Trust không làm các lớp bảo vệ mạng trở nên vô ích. Doanh nghiệp vẫn cần cấu hình, giám sát và bảo vệ luồng kết nối phù hợp. Điểm thay đổi là không dùng việc đã vượt qua một ranh giới làm căn cứ đủ cho mọi quyền phía sau. Mỗi lớp phải đóng góp vào việc bảo vệ tài nguyên cụ thể.

Đội ngũ có thể bắt đầu từ năng lực quản lý bảo mật thông tin để thống nhất mục tiêu, phạm vi và trách nhiệm. Như vậy, kiến trúc truy cập sẽ phục vụ nhu cầu bảo vệ đã được hiểu chung, thay vì trở thành một dự án riêng của nhóm triển khai công cụ.

Tách xác thực danh tính khỏi quyền thực hiện công việc

Xác thực giúp kiểm tra danh tính được trình bày. Phân quyền quyết định danh tính đó được làm gì với tài nguyên. Một người đăng nhập thành công, kể cả sử dụng xác thực đa yếu tố, vẫn có thể không cần quyền xem toàn bộ hồ sơ. Nếu doanh nghiệp gộp hai câu hỏi, việc tăng độ chắc chắn khi đăng nhập có thể che đi quyền quá rộng.

Cấp quyền tối thiểu cần thiết bắt đầu từ nhiệm vụ thực tế. Nhân viên đối soát có thể cần xem một phần giao dịch nhưng không cần xuất mọi dữ liệu khách hàng. Kỹ sư bảo trì có thể cần quyền quản trị trong một khoảng thời gian xác định. Mỗi lựa chọn cần chủ phê duyệt, phạm vi hành động và điều kiện kết thúc rõ.

Danh tính không chỉ thuộc về con người. Ứng dụng và tác vụ tự động cũng gọi dịch vụ, đọc dữ liệu hoặc thực hiện thay đổi. Với những trường hợp này, doanh nghiệp cần biết chủ chịu trách nhiệm và quyền phục vụ luồng nào. Không nên áp cách xác thực của nhân viên một cách máy móc cho mọi tác vụ, nhưng cũng không để quyền tự động nằm ngoài quản lý.

Thiết bị là một nguồn tín hiệu khác. Tài khoản đúng chưa đủ nếu trạng thái thiết bị không đáp ứng yêu cầu cho loại dữ liệu đang truy cập. Ngược lại, thiết bị được doanh nghiệp cấp không bảo đảm người dùng có mọi quyền. Chính sách cần kết hợp thông tin thay vì chọn một dấu hiệu rồi coi đó là bằng chứng đầy đủ.

Để thực hiện nhất quán, nhóm quản trị vận hành IT cần kiểm tra cấu hình và các đường truy cập thực tế. Nếu chính sách chỉ áp trên cổng chính nhưng ứng dụng vẫn có một cách đăng nhập khác không được quản lý, phạm vi bảo vệ có thể hẹp hơn báo cáo triển khai.

Chọn tín hiệu có ý nghĩa và quyết định có thể giải thích

Chính sách động cần dữ liệu đủ đáng tin cậy. Vai trò đang có hiệu lực, trạng thái thiết bị và độ nhạy cảm của tài nguyên thường hữu ích hơn việc thu thập nhiều tín hiệu nhưng không biết chất lượng. Mỗi tín hiệu nên có nguồn, độ cập nhật và cách xử lý khi thiếu thông tin. Dữ liệu cũ có thể làm cả quyết định cho phép lẫn từ chối sai.

Bảng dưới đây là gợi ý thảo luận cho một ứng dụng nội bộ, không phải bộ quy tắc cố định của NIST. Người thiết kế cần điều chỉnh theo rủi ro và điều kiện thực tế. Trước khi thực thi rộng, tổ chức nên kiểm tra cả trường hợp được phép lẫn tình huống cần hạn chế để tránh làm gián đoạn công việc hợp lệ.

Một thông báo từ chối cần đủ rõ để người dùng biết bước hợp lệ tiếp theo, nhưng không công bố thông tin nhạy cảm về cơ chế bảo vệ. Bộ phận hỗ trợ cần nhận được dữ liệu phù hợp để xác định lỗi vai trò, thiếu điều kiện hay sai cấu hình. Nếu mọi lỗi đều hiện “không được phép”, người dùng dễ tìm đường vòng và đội hỗ trợ khó điều tra.

Nhật ký giúp kiểm tra quyết định nhưng cần được quản lý. Tổ chức phải xác định thông tin cần thu thập, mục đích sử dụng, quyền xem và yêu cầu lưu giữ áp dụng. Theo dõi hoạt động để bảo vệ dịch vụ không đồng nghĩa mọi nhân viên đều được xem toàn bộ dữ liệu hành vi của người khác.

Thử trên một luồng công việc trước khi mở rộng

Zero Trust khó thành công nếu phạm vi khởi đầu là thay toàn bộ cơ chế truy cập. Một lựa chọn thực hành là chọn luồng có tài nguyên rõ, chủ nghiệp vụ sẵn sàng phối hợp và nguồn thông tin danh tính đủ tốt. Phạm vi này cần có ý nghĩa bảo vệ, đồng thời đủ nhỏ để kiểm tra cách cấp quyền và hỗ trợ người dùng.

Nhóm bắt đầu bằng bản đồ người dùng, tài nguyên, thao tác và cách truy cập hiện hành. Những quyền đang tồn tại phải được chủ nghiệp vụ xác nhận; không nên chuyển nguyên một danh sách quyền rộng sang chính sách mới rồi coi là đã thực hiện quyền tối thiểu. Các ngoại lệ cần được nhận diện trước khi triển khai, tránh phát hiện sát lúc sử dụng.

Kiểm thử phải có tình huống tích cực và tiêu cực. Người có nhiệm vụ, thiết bị đáp ứng yêu cầu và thao tác đúng cần tiếp tục làm việc được. Người không còn quyền hoặc yêu cầu vượt phạm vi phải bị xử lý đúng. Đồng thời, nhóm cần xem điều gì xảy ra khi nguồn danh tính hoặc thành phần quyết định gặp gián đoạn.

Các quyết định về nguồn lực, phụ thuộc và cách mở rộng cần năng lực quản lý IT. Nếu dữ liệu nhân sự chưa cập nhật hoặc ứng dụng không hỗ trợ cơ chế cần thiết, đó là điều kiện phải xử lý trong lộ trình. Một nhãn kiến trúc không thể bù cho các nền tảng còn thiếu.

Một tình huống: cùng một nhân viên, khác điều kiện truy cập

Trong tình huống giả định, một doanh nghiệp cho nhân viên tài chính truy cập hồ sơ thanh toán qua kết nối từ xa. Cách cũ dựa nhiều vào việc tài khoản đã đăng nhập vào mạng nội bộ. Sau khi rà quyền, nhóm thấy nhân viên có thể mở cả thư mục không liên quan nhiệm vụ, và dữ liệu xuất chưa có điều kiện phù hợp với thiết bị sử dụng.

Doanh nghiệp thử chính sách cho một nhóm hồ sơ cụ thể. Người dùng cần danh tính và vai trò được xác nhận, nhưng quyền đọc và xuất được xem riêng. Thiết bị đáp ứng điều kiện có thể phục vụ hành động được phép; khi điều kiện khác, chính sách yêu cầu bước bổ sung hoặc giới hạn thao tác theo thiết kế đã phê duyệt.

Trong đợt thử, một nhân viên hợp lệ bị từ chối vì thông tin vai trò chưa cập nhật. Nhóm xử lý nguồn dữ liệu và kiểm thử lại, thay vì mở toàn bộ quyền để giải quyết nhanh. Một trường hợp khác truy cập từ mạng văn phòng nhưng không có nhiệm vụ với hồ sơ này cũng không được tự động cho phép. Căn cứ quyết định bám tài nguyên và vai trò.

Kết quả giả định không chứng minh mọi rủi ro đã hết. Tổ chức vẫn cần quản lý tài khoản, thiết bị, ứng dụng và phản hồi hỗ trợ. Điều luồng thử làm rõ là việc kết nối thành công không còn được dùng để suy ra mọi quyền, còn sai lệch chính sách có người tiếp nhận và cách kiểm tra.

Duy trì việc đánh giá phù hợp với rủi ro

Căn cứ cấp quyền có thể thay đổi trong quá trình sử dụng: vai trò bị thu hồi, thiết bị có tín hiệu mới hoặc người dùng yêu cầu tài nguyên khác. Kiến trúc cần hỗ trợ việc đánh giá lại theo chính sách. Điều này không đồng nghĩa buộc người dùng nhập mật khẩu ở mọi lần nhấp; cách thực hiện phải cân bằng bảo vệ, sẵn sàng và khả năng sử dụng.

Các trường hợp hỗ trợ khẩn cấp hoặc hệ thống cũ cũng cần cơ chế riêng. Quyền ngoại lệ phải có giới hạn, người phê duyệt, theo dõi và bước xem xét sau sử dụng. Nếu ngoại lệ cứ tự gia hạn vì tiện, nó có thể trở thành đường truy cập rộng hơn chính sách mà doanh nghiệp đang cố xây dựng.

Qua cách nhìn quản lý rủi ro IT, tổ chức có thể ưu tiên mở rộng theo tác động và khoảng trống đã được kiểm chứng. Tín hiệu nên theo dõi gồm quyền không phù hợp, lỗi quyết định, ngoại lệ kéo dài và thời gian hỗ trợ; không chỉ là số người đã được chuyển sang công cụ mới.

Áp dụng Zero Trust có giá trị khi mỗi quyền được gắn với nhu cầu, điều kiện và trách nhiệm rõ. Doanh nghiệp không cần chờ một cuộc thay thế toàn bộ mới bắt đầu, nhưng mỗi bước phải làm căn cứ cấp quyền chính xác hơn và có thể kiểm tra trong công việc thực tế.

Bài viết liên quan

• Mua thêm công cụ bảo mật hay xây dựng hệ thống quản lý: Doanh nghiệp cần gì?
• Kiểm kê và phân loại tài sản thông tin: Nền tảng để xác định yêu cầu bảo vệ.
• Lập kế hoạch xử lý rủi ro: Khi nào cần giảm thiểu, tránh, chia sẻ hoặc chấp nhận rủi ro?
• Quản lý danh tính và quyền truy cập: Kiểm soát vòng đời tài khoản nhân viên.

Nguồn tham khảo

1. NIST — SP 800-207: Zero Trust Architecture
2. NIST — SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications
3. CIS — Critical Security Control 6: Access Control Management