Kiểm tra trạng thái thiết bị VPN không chặn? Hãy lần theo báo cáo trước
Đại lý điểm cuối của bạn báo cáo trạng thái khỏe mạnh, nhưng ứng dụng nội bộ vẫn mở. Đi qua bộ thu thập, phán quyết và chặn, rồi chứng minh việc từ chối bằng một yêu cầu.
Nếu một laptop có chữ ký diệt virus ngừng cập nhật từ nhiều tuần trước vẫn mở được ứng dụng nội bộ của bạn, thì hiếm khi tài liệu chính sách là thứ sai. Ba hệ thống riêng biệt phải đồng ý trước khi quyền truy cập bị từ chối: một thứ đo điểm cuối, một thứ chuyển phép đo đó thành phán quyết cho phép hoặc từ chối, và một thứ thực sự bỏ gói lưu lượng. Khi thiết bị không tuân thủ vẫn lọt vào, đúng một trong những mắt xích đó thiếu hoặc đang tin bằng chứng không nên tin. Các bước kiểm tra dưới đây đi theo thứ tự đó, và mỗi bước có một điểm dừng.
Chặn là bước cuối cùng, không phải bước đầu tiên
Xác thực và trạng thái trả lời hai câu hỏi khác nhau. Đăng nhập thành công chứng minh đã trình một thông tin xác thực; nó không nói gì về phần mềm đang chạy trên máy đã trình thông tin đó. Chính khoảng trống này khiến một hồ sơ khách hàng bị sao chép có thể mang một phiên trông khỏe mạnh sang một máy chủ không khỏe mạnh.
Công việc tuân thủ điểm cuối đã có từ vựng cho chuỗi này. Mô hình tham chiếu NEA trong RFC 5209 chia công việc thành bộ thu thập, bước đánh giá và điểm thực thi, và nói rõ rằng một khách hàng nói dối về trạng thái của chính mình nằm ngoài mô hình. Lưu ý đó quan trọng hơn sơ đồ: một mô-đun nền tảng đáng tin không biến phép đo tự báo cáo thành sự thật.
Giữ bộ thu thập trung thực về phạm vi. Nó chỉ nên báo cáo các thuộc tính mà chính sách của bạn nêu tên, trên thiết bị đang yêu cầu truy cập, và ít gì khác. Một đại lý kiểm kê liệt kê mọi gói đã cài là công cụ khác với bộ thu thập trạng thái, và khác biệt đó vừa là vấn đề lưu giữ vừa là vấn đề độ chính xác. Nếu báo cáo không gắn được với một danh tính thiết bị, người đánh giá đang đoán xem mình vừa cho máy nào qua.
Một bảng điều khiển hiển thị trạng thái đỏ không phải là kiểm soát. Hãy hỏi người dùng bị từ chối còn với tới được gì: wiki, chia sẻ tệp, cổng cơ sở dữ liệu? Việc khắc phục cần một bề mặt hẹp duy nhất, và mọi thứ khác nằm sau chặn.
Đọc báo cáo trước khi đọc quy tắc
Hãy bắt đầu từ nguồn thay vì dấu tích xanh của khách hàng. Trên Windows, phép đo cục bộ đến từ Defender hoặc từ sản phẩm tự đăng ký với Security Center, và cả hai đều đọc được mà không cần bảng điều khiển của nhà cung cấp:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateLệnh thứ hai trả về một số nguyên tên là productState. Các bit của nó được ghi tài liệu lỏng lẻo và nhà cung cấp đóng gói cờ bật và cờ mới khác nhau, nên hãy xác minh thay vì phân tích. Các gói bên thứ ba cũng để lại mục trong Security Center sau khi gỡ cài đặt, và mục đó báo cáo về phần mềm không còn trên đĩa.
Tuổi là trường mà người ta bỏ qua. Dấu thời gian chữ ký chỉ có nghĩa so với đồng hồ của máy đang đánh giá, nên hãy chuyển nó thành khoảng thời gian thay vì ước lượng bằng mắt:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursGiờ đây chính sách có một con số để đọc. Nếu quy tắc của bạn nói 72 giờ, đó là con số nó dùng, và một laptop ngủ một tuần sẽ trượt mà không ai phải diễn giải nhãn. Ghi ngưỡng bên cạnh lệnh, vì hai thứ đó lệch nhau khi công cụ điểm cuối được thay.
Chuyển mỗi trạng thái thiết bị thành phán quyết bằng văn bản
Phần lớn tranh cãi về trạng thái thực ra là tranh cãi về hàng không xác định. Hãy quyết định trước sự cố đầu tiên, trong một bảng nêu bằng chứng, phán quyết và người sở hữu, để không ai ứng biến tại bảng điều khiển cổng.
| Evidence the assessor has | Verdict | What it protects against |
|---|---|---|
| Timestamp inside the policy window, protective service running | Admit to normal applications | Nothing yet; the other checks still apply |
| Timestamp older than the window | Deny, admit remediation page only | Signature rollback and dormant laptops |
| Service disabled or reporting off | Deny, escalate to the endpoint owner | An agent reporting stale success |
| No report at all for this session | Treat as deny, never as healthy | Agents that fail open under load |
Hàng dưới cùng là nơi các sản phẩm khác nhau. Một số cổng từ chối kết nối và giải thích tại sao; số khác để đường hầm dựng lên và áp một chính sách hạn chế; vài cái quay về báo cáo tốt gần nhất đã biết. Chỉ hai kiểu đầu là biện hộ được, và đáng để thử xem bản của bạn làm kiểu nào.
Giữ danh tính và quyền riêng ở làn của chúng. Một laptop qua mọi bài kiểm tra trạng thái vẫn cần sự uỷ quyền con người đúng cho ứng dụng, và chứng chỉ thiết bị chứng minh việc nắm giữ khoá chứ không phải trạng thái hệ thống tệp. Ép cả ba thành một boolean là cách một tài khoản trợ giúp có được quyền truy cập thường trực vào môi trường sản xuất.
Kiểm tra đường thực thi bằng một yêu cầu, không phải bảng điều khiển
Thực thi là thuộc tính của một yêu cầu, nên hãy đo nó bằng một yêu cầu. Đặt một máy không tuân thủ vào đường hầm và thực hiện lời gọi mà người dùng thật sẽ làm:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthMột 200 từ thiết bị đáng lẽ phải bị chặn nghĩa là phán quyết chưa bao giờ tới được đường dữ liệu. Hai nguyên nhân thường gặp: chính sách gắn với một nhóm mà tài khoản thử chưa từng tham gia, hoặc ứng dụng tới được qua một tuyến mà VPN không sở hữu.
Trước hết hãy kiểm tra giả định định tuyến. Nếu tên nội bộ phân giải thành một địa chỉ mà khách hàng đã tới được qua LAN cục bộ, đường hầm là không liên quan và sẽ không chính sách nào áp dụng. So địa chỉ đó với tuyến mà cổng đẩy ra. Trên OpenVPN, chính sách theo từng khách hàng nằm trong các tệp được khoá bằng tên chung, nên dễ kiểm tra:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17Một tệp chứa disable ngắt kết nối khách hàng đó hoàn toàn, trong khi dòng push "route ..." thu hẹp nơi nó tới được. Cả hai đều là thực thi, và cả hai đều hiện ra với người đang gỡ lỗi báo cáo.
Thử bốn trường hợp trên một tài khoản thử
Bước kiểm tra cuối là một ma trận nhỏ, không phải con đường suôn sẻ. Cho một tài khoản thử đi qua bốn trạng thái: hiện hành, chữ ký hết hạn, bảo vệ bị tắt, đại lý chưa cài. Với mỗi trạng thái, ghi phán quyết vào nhật ký đánh giá, trạng thái HTTP mà ứng dụng trả về, và liệu trang khắc phục có tải được không.
foreach ($case in 'current', 'stale', 'disabled', 'absent') {
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}Hai chi tiết dễ bị bỏ sót. Đầu tiên là phát lại: một báo cáo được ghi khi máy còn khỏe không được chấp nhận cho phiên sau trên cùng thiết bị, nên hãy tìm một dấu thời gian gắn với kết nối hiện tại. Tiếp theo là gỡ bỏ: gỡ đại lý phải tạo ra cùng một lần từ chối như báo cáo cũ, không phải một lần qua sạch, và đây là trường hợp thường không bao giờ được thử.
Khi ma trận khớp với bảng, hãy bàn giao ba thứ cho người sẽ vận hành cổng tiếp theo: các lệnh, ngưỡng và bốn kết quả mong đợi. Chính việc bàn giao đó là sản phẩm thực sự, vì một thiết kế trạng thái chỉ sống trong tài liệu chính sách sẽ lệch ngay lần đầu công cụ điểm cuối đổi trường báo cáo của nó.