Lưu bộ nhớ đệm phân loại VPN và giữ tuổi của nó hiển thị

Phân loại được lưu đệm tiết kiệm một lần tra cứu và đóng băng ý kiến hôm qua vào quyết định hôm nay. So sánh thật sự không phải là bộ nhớ đệm so với không có, mà là một quan sát, độ tươi của nó và phản hồi mà trang bạn đã chọn. Mất ranh giới giữa ba thứ đó và một bước tối ưu hóa bắt đầu tự đặt chính sách. Việc sửa chữa là ghi chép kế toán, không phải một nguồn dữ liệu tốt hơn.

Ba bản ghi với ba đồng hồ khác nhau

Quan sát là trường bạn nhận được, nguồn dữ liệu nó đến từ và phiên bản tập dữ liệu phía sau. Độ tươi là thuộc tính của mục bộ nhớ đệm: khi nào lần tra cứu chạy, khi nào mục không còn được tin cậy và liệu lần làm mới cuối cùng có trả về gì không. Phản hồi là điều trang bạn làm về nó cho yêu cầu này, tài khoản này hoặc hành động này. Chúng được tạo bởi các chủ sở hữu khác nhau và hư hỏng với tốc độ khác nhau, vì thế một hàng tên blocked phá hủy sự phân biệt đó.

Hai đồng hồ đáng được chăm sóc đặc biệt. Thời điểm lần tra cứu của bạn chạy không phải thời điểm nhà cung cấp công bố tập dữ liệu, và người vận hành đọc hàng sau đó cần biết mỗi giá trị đến từ cái nào trong hai. Đặt thời hạn và việc làm mới theo mô hình cập nhật được ghi chép của nguồn dữ liệu và theo chi phí của việc sai, không bao giờ theo một con số vay mượn từ trang khác.

Giữ trường, không giữ phán quyết

Tài liệu của MaxMind về IP ẩn danh là một ví dụ cụ thể về nguồn dữ liệu tách VPN ẩn danh, nhà cung cấp lưu trữ, proxy công khai và lối ra Tor thành các trường riêng. Nó cũng ghi lại rằng một mạng con VPN chưa đăng ký có thể thay vào đó xuất hiện dưới cờ lưu trữ. Việc làm phẳng điều đó thành một boolean duy nhất ném đi phần duy nhất mà người vận hành có thể kiểm toán sau này.

Không hướng suy luận nào là an toàn. Nhãn lưu trữ không chứng minh rằng một đường hầm đã được dùng, và việc không có cờ VPN không chứng minh rằng không có gì nằm giữa máy khách và dịch vụ của bạn. Đó là hai khẳng định khác nhau, và một boolean duy nhất không thể diễn đạt cả hai.

Gắn mục với địa chỉ bạn đã xác minh

Sau proxy ngược, ứng dụng phải dùng cách xử lý địa chỉ máy khách mà việc triển khai đã phê duyệt. Tiêu đề chuyển tiếp do bên gọi cung cấp không bao giờ được có thể chọn danh tiếng được lưu đệm của người khác.

Lỗi đó vừa là lỗi đúng đắn vừa là lỗi bảo mật, vì kẻ tấn công kiểm soát tiêu đề có thể thừa hưởng một mục tin cậy hoặc ghim nạn nhân vào một mục xấu. Xuất khóa từ kết nối mà hạ tầng của bạn đã kết thúc, và ghi lại việc xuất nào đã được dùng. Khi có nhiều proxy phía trước, hãy ghi chép chuỗi thay vì tin tiêu đề đầu tiên có vẻ hợp lý. Nếu chuỗi mơ hồ, ghi lại khóa đã xuất và tiêu đề bạn đã từ chối, vì cái sau là thứ một cuộc rà soát sự cố sẽ hỏi.

Không có bằng chứng không phải là kết quả sạch

Hết thời gian, một phản hồi sai định dạng và một cơ sở dữ liệu không khả dụng mỗi thứ có nghĩa khác với một lần tra cứu thành công mà không khớp gì. Trình bày chúng như các kết quả riêng, và quyết định trước việc hành động được bảo vệ làm gì khi hoàn toàn không có bằng chứng. Một trang chỉ đọc và một hành động trên tài khoản đã đăng nhập có thể theo những quy tắc khác nhau một cách hợp lý.

Giữ xác thực bình thường, hoặc yêu cầu một xác minh được hỗ trợ, thường là câu trả lời tốt hơn là coi sự cố là quyền cho tất cả hoặc là lệnh cấm toàn trang. Giới hạn thời gian một lần tra cứu có thể chạy và dừng các cơn bão làm mới bằng bất kỳ cơ chế nào mà tích hợp hỗ trợ. Khi dùng một giá trị cũ trong lúc sự cố, hãy gắn nhãn cũ tại điểm quyết định, và làm cho lần thất bại cuối cùng của việc làm mới hiển thị để một lỗi kéo dài không thể đi qua như một mục khỏe mạnh. Dù lựa chọn là gì, hãy viết nó ở nơi chính sách được thi hành, không phải trong một bình luận cạnh việc tra cứu.

Việc lưu giữ thuộc cùng một quyết định: giữ các trường mà chức năng này cần và dấu vết rà soát phía sau, không hơn. Một bộ nhớ đệm IP không phải trở thành lịch sử duyệt web.

Chấp nhận bốn trường hợp, gồm một chỉnh sửa

Kiểm thử một kết quả mới, một kết quả hết hạn, một lần tra cứu thất bại và một phân loại được chỉnh sau. Mỗi trường hợp luyện một nhánh khác nhau, và chỉ cái cuối cho thấy một hạn chế sai có thể được gỡ bỏ hay không.

Sau đó xác nhận rằng người dùng thường có đường để xin rà soát sau một lần chặn sai, vì nguồn dữ liệu đôi khi sẽ sai và hàng đợi là một phần của thiết kế. Viết bốn trường hợp vào runbook kèm tên chủ sở hữu chính sách. Thiết kế xứng đáng với chỗ của nó khi nó loại bỏ các tra cứu dư thừa mà vẫn giữ nguyên sự không chắc chắn và quyết định rõ ràng nằm trong tay một con người.