Chính sách nhóm NPS không phải là thực thi tài nguyên VPN

Hai nhóm, hai hồ sơ truy cập, một cổng VPN, và rốt cuộc cả hai nhóm đều chạm tới cùng những máy chủ. Nguyên nhân thường gặp không phải chính sách bị hỏng mà là nửa sau còn thiếu của thiết kế: NPS quyết định ai được lập phiên, còn một thứ khác phải quyết định phiên đó được chạm tới đâu. Khi chỉ có nửa đầu, việc cấp quyền thành công cho tất cả những ai xác thực được. Chính sách đang làm đúng việc của nó, còn thiết kế thì vẫn chưa hoàn chỉnh.

Một chính sách mạng khớp theo nhóm là bằng chứng về việc được chấp nhận. Nó không phải bằng chứng về các gói tin, và phần lớn công việc này nằm ở khoảng trống giữa hai câu nói đó.

Tìm chính sách thực sự đã chấp nhận phiên

NPS đánh giá các chính sách mạng theo thứ tự, và quy tắc đầu tiên được bật có điều kiện khớp sẽ thắng. Điều kiện có thể gồm thành viên nhóm người dùng hoặc máy tính, loại kết nối, thời gian và trạng thái thiết bị. Vì vậy một chính sách rộng đặt sớm trong danh sách sẽ chấp nhận kết nối trước khi quy tắc hẹp hơn ở bên dưới được xét tới. Thứ tự không phải là chi tiết của giao diện; nó chính là chính sách.

Đọc danh sách theo thứ tự và xác định mục đã khớp, rồi ghi lại những thiết lập mà nó trả về. Tên nhóm trong trình soạn thảo không phải kết quả; kết quả là quyết định cấp quyền mà máy chủ nhận được. Hãy tách riêng cấp quyền cho người dùng và cấp quyền cho thiết bị ở nơi triển khai dùng cả hai, vì một tài khoản có thể mở đường hầm không đương nhiên là tài khoản phải chạm tới mọi dịch vụ nội bộ.

Phản hồi RADIUS là một chỉ dẫn, không phải bộ lọc

Thuộc tính Filter-Id mang tên của một danh sách bộ lọc. Nó không gửi kèm một tập quy tắc lọc gói tin di động mà mọi bên nhận đều hiểu, và việc gửi một cái tên mà cổng VPN chưa từng định nghĩa thì không thực thi được gì cả. Lời cảnh báo tương tự cũng đúng với các thuộc tính VLAN: gán một phiên đường hầm vào một VLAN tự nó không phải là quy tắc truy cập được định tuyến cho người dùng đó.

Đây là chỗ một thiết kế trông có vẻ hoàn chỉnh phía NPS lại lặng lẽ không làm gì. Thay vì giả định rằng tên thuộc tính chuẩn hàm ý hành vi chuẩn, hãy xác nhận với tài liệu của nhà cung cấp cổng VPN xem những thuộc tính cấp quyền nào được hỗ trợ và bên nhận làm gì với từng thuộc tính.

Đặt việc thực thi ở nơi lưu lượng đi qua

Một cổng VPN xử lý các gói tin của người dùng có thể áp bộ lọc theo phiên, ánh xạ một nhóm vào một chính sách cổng VPN, hoặc cấp cho phiên một địa chỉ từ một nhóm địa chỉ riêng mà tường lửa đối xử khác đi. Bất kỳ cách nào trong số đó đều có thể hiệu quả, và chúng hỏng theo những cách khác nhau. Hãy xác định cổng VPN của bạn hỗ trợ cơ chế nào trước khi viết chính sách nêu tên cơ chế đó. Sau đó viết ra điều gì xảy ra với một phiên khi cơ chế đó vắng mặt, vì mặc định chính là sự im lặng.

Mô tả quyền dự kiến thành bốn phần: danh tính hoặc nhóm nguồn, đích, giao thức và cổng. Hãy thêm những phụ thuộc mà người dùng thực sự cần, chẳng hạn DNS hoặc một dịch vụ xác thực, nếu không hạn chế sẽ làm hỏng các luồng đăng nhập mà không ai nghĩ tới việc kiểm thử. Viết quy tắc cho giao diện thực sự lọc, không phải cho giao diện tình cờ đang mở trong trình soạn thảo.

Cũng phải tính đến việc dịch địa chỉ. Nếu một tường lửa phía sau chỉ thấy một địa chỉ nguồn đã dịch cho mọi người dùng đường hầm, nó không thể phân biệt từng cá nhân chỉ từ địa chỉ đó, và một quy tắc viết như thể nó làm được sẽ hoặc vô dụng hoặc quá rộng.

Hồ sơ máy khách nằm ở phía không tin cậy

Một hồ sơ VPN được quản lý có thể đẩy các tuyến, quy tắc chia đường hầm hoặc bộ lọc ứng dụng, và những thứ đó định hình cách một thiết bị ngoan ngoãn hành xử. Chúng không phải là biện pháp bảo vệ cho dịch vụ, vì máy khách chính là bên bạn đang muốn ràng buộc. Xóa một tuyến trong hồ sơ cũng không phải là cấp quyền, vì máy khách có thể có đường đi khác tới cùng đích.

Coi thiết lập phía máy khách là tiện lợi và thiết lập phía cổng VPN là kiểm soát. Khi hai bên mâu thuẫn, cổng VPN đúng, vì nó là thứ nhìn thấy các gói tin.

Nghiệm thu bằng hai tài khoản, rồi lần theo đúng thứ tự

Tạo hai tài khoản kiểm thử thông thường với quyền dự kiến khác nhau, lập phiên mới và kiểm tra chính sách cổng VPN hiệu lực cho từng tài khoản. Sau đó thử một thao tác được phép vô hại và một tài nguyên bị từ chối cụ thể. Một lần ping thất bại tự nó chứng minh rất ít, vì ICMP có thể bị lọc trong khi dịch vụ TCP phía sau vẫn trả lời ngon lành.

Khi cả hai tài khoản vẫn có quyền truy cập rộng, hãy lần theo một thứ tự cố định: chính sách nào đã khớp, phản hồi mang quyết định cấp quyền nào, và cổng VPN đã làm gì với nó. Thêm nhiều thuộc tính NPS hơn trước khi xác nhận bên nhận thực thi chúng là cách một trục trặc cấp quyền nhỏ biến thành một cửa sổ thay đổi không có kết quả.