Một nhân viên ngồi ở quán cà phê cần mở đúng ứng dụng nội bộ để làm việc. Doanh nghiệp muốn hỗ trợ kết nối từ xa, đồng thời tránh cấp quyền rộng hơn nhu cầu. ZTNA (Zero Trust Network Access) là một hướng tiếp cận giúp đặt quyết định truy cập gần với từng ứng dụng và từng phiên làm việc, thay vì chỉ dựa vào việc người dùng đã kết nối vào một mạng.
1. Từ kết nối vào mạng đến quyền theo ứng dụng
VPN vẫn phù hợp với nhiều tình huống. Tuy nhiên, tùy kiến trúc và chính sách, kết nối VPN có thể đưa người dùng tới một vùng mạng rộng hơn phạm vi của ứng dụng họ cần. Khi số nhân sự từ xa, thiết bị và ứng dụng tăng lên, doanh nghiệp cần xem lại quyền nào thực sự cần thiết cho từng vai trò.
Với ZTNA, chính sách có thể giới hạn quyền tới ứng dụng cụ thể. Người dùng không được mặc định tin cậy chỉ vì đang ở văn phòng hay đã thiết lập kết nối; quyền được xem xét dựa trên chính sách của doanh nghiệp và thông tin có sẵn trong phiên truy cập.
2. Quyết định truy cập cần xét những gì?
Một chính sách ZTNA thường kết hợp danh tính người dùng với thông tin về thiết bị và tài nguyên đích. Tùy sản phẩm, cấu hình và gói sử dụng, doanh nghiệp có thể xét nhóm người dùng, trạng thái bảo mật của endpoint, chứng thư thiết bị và điều kiện của ứng dụng.
Nếu thiết bị thay đổi trạng thái hoặc không còn đáp ứng chính sách, quyền truy cập có thể được đánh giá lại theo khả năng của giải pháp đã triển khai. Mức kiểm soát thực tế phụ thuộc vào cách tích hợp danh tính, quản trị endpoint, cổng ứng dụng và các chính sách liên quan.
3. Một luồng truy cập ZTNA điển hình
Người dùng mở ứng dụng đã được cấu hình. Thành phần trên thiết bị cung cấp thông tin cần thiết; hệ thống đối chiếu danh tính và điều kiện thiết bị với chính sách; sau đó cổng truy cập áp dụng quyền cho ứng dụng tương ứng. Nhật ký truy cập giúp đội IT theo dõi các phiên và xử lý vấn đề khi cần.
Trong phương án Fortinet, FortiClient, FortiClient EMS và FortiGate có thể phối hợp cho các vai trò agent, quản trị tập trung và cổng ứng dụng. Phiên bản, mô hình triển khai, điều kiện tương thích và quyền sử dụng cần được xác nhận theo cấu hình cụ thể trước khi đặt hàng.
4. Bắt đầu bằng một phạm vi thử nghiệm nhỏ
Doanh nghiệp có thể chọn một ứng dụng nội bộ, một nhóm người dùng đại diện và một số thiết bị mẫu để kiểm tra trước. Phạm vi thử nghiệm nên làm rõ ai được truy cập, từ thiết bị nào, trong điều kiện nào và nhóm hỗ trợ sẽ xử lý ra sao khi người dùng bị từ chối.
Trong pilot, hãy kiểm tra trải nghiệm đăng nhập, khả năng tương thích ứng dụng, việc ghi nhận nhật ký, các trường hợp thiết bị không đạt yêu cầu và ảnh hưởng tới công việc hằng ngày. Sau đó mới quyết định mở rộng phạm vi hoặc điều chỉnh chính sách.
- Liệt kê ứng dụng cần truy cập và nhóm người dùng liên quan
- Xác định nguồn danh tính, cách quản lý thiết bị và điều kiện truy cập
- Thử các tình huống được phép, bị từ chối và cần hỗ trợ
- Đối chiếu phiên bản, license, mô hình triển khai và yêu cầu vận hành
5. ZTNA không phải nút bật thay thế mọi kết nối
Không phải ứng dụng nào cũng phù hợp với cùng một phương án truy cập, và ZTNA không đồng nghĩa doanh nghiệp phải loại bỏ VPN ngay lập tức. Một số tổ chức có thể duy trì VPN cho một số hệ thống trong khi thử ZTNA với nhóm ứng dụng phù hợp, tùy kiến trúc và kế hoạch chuyển đổi.
Trước khi triển khai rộng, doanh nghiệp cần khảo sát ứng dụng, luồng phụ thuộc, danh tính, thiết bị đầu cuối, năng lực hỗ trợ và điều kiện cấp phép. Đánh giá theo từng bước giúp kiểm soát tác động tới người dùng và tránh chọn cấu hình vượt quá khả năng vận hành.
Đi sâu hơn theo
đúng bài toán.
Gợi ý từ Arbolume: Hãy bắt đầu bằng khảo sát hiện trạng và mức độ ưu tiên. Một cấu hình vừa vặn thường hiệu quả hơn một giải pháp lớn nhưng khó vận hành.
