Tên người dùng VPN biến mất khỏi đường ống nhật ký ở đâu?

Các phiên xuất hiện trên bảng điều khiển trong khi cột tên người dùng vẫn trống, và phản xạ đầu tiên là đổ lỗi cho bộ phân tích. Phản xạ đó bỏ qua ba giai đoạn trước đó nơi giá trị có thể đã bị mất. Cổng có thể che giấu danh tính theo chính sách, một quy tắc nhập có thể xóa nó trước khi lập chỉ mục, và một lần trích xuất tại thời điểm tìm kiếm có thể đơn giản là không đặt tên cho nó. Cách sửa phụ thuộc vào ranh giới nào bạn chứng minh được là bên chịu trách nhiệm, nên công việc hữu ích là so sánh chứ không phải cấu hình.

Bắt đầu từ một sự kiện, không phải bảng điều khiển

Chọn một sự kiện xác thực duy nhất và ghi lại điều gì nhận dạng nó: kiểu và phiên bản cổng, phương thức xác thực, mã định danh sự kiện, dấu thời gian và địa chỉ nguồn. Thêm tên người dùng đúng như người đó đã nhập, kể cả chữ hoa và chữ thường, vì tìm kiếm phân biệt chữ hoa có thể ẩn một trường đang tồn tại. Hãy coi sự kiện đó là tham chiếu cho mọi so sánh về sau.

Các loại sự kiện không dùng chung một lược đồ. Một lần thử thất bại, một lần đăng nhập thành công không có ứng dụng khách và một lần kết nối lại đường hầm có thể tạo ra các trường khác nhau, và một số cổng bỏ qua danh tính khi lần thử chưa bao giờ tới bước xác thực người dùng. Vì vậy một cột trống ở một loại sự kiện là bằng chứng yếu về sự cố đường ống.

Làm việc với một danh tính kiểm thử đã được phê duyệt thay vì tài khoản nhân viên thật, và giữ việc so sánh trong các quy tắc truy cập vốn đã điều chỉnh dữ liệu nhật ký. Bật rộng rãi ghi nhật ký xác thực chi tiết chỉ để lấy một mẫu sẽ thay đổi chính hệ thống bạn đang cố đo.

So sánh bốn ranh giới theo thứ tự

Giá trị có thể biến mất tại một trong bốn điểm. Mỗi điểm có chủ sở hữu khác nhau và cách sửa khác nhau.

Dừng lại ở ranh giới đầu tiên nơi giá trị biến mất. Sự khác biệt giữa giao diện thiết bị và bản sao thô chỉ ra việc vận chuyển hoặc cấu hình bộ thu thập; khớp ở đó nhưng thiếu giá trị trong sự kiện đã lập chỉ mục chỉ ra một phép biến đổi; giá trị có trong sự kiện đã lập chỉ mục nhưng không có trên bảng điều khiển chỉ ra việc trích xuất hoặc truy vấn.

Thứ tự này quan trọng vì mỗi giai đoạn sau chỉ có thể mất thông tin, không bao giờ khôi phục lại. Một biểu thức chính quy không thể lấy lại chuỗi mà giai đoạn trước đã thay bằng ký tự giữ chỗ, và một thiết lập quyền riêng tư không thể giải thích giá trị chưa bao giờ được gửi đi.

Che giấu tại nguồn là chính sách, không phải lỗi bộ phân tích

Tài liệu ghi nhật ký ASA của Cisco mô tả việc ẩn tên người dùng như một hành vi có thể cấu hình, bao gồm cách biểu diễn các tên người dùng không hợp lệ hoặc không xác định. Vì vậy một danh tính bị che trong sự kiện nguồn có thể chính là điều chính sách quyền riêng tư yêu cầu, và việc coi đó là lỗi phân tích dẫn tới một yêu cầu làm suy yếu kiểm soát.

Cách biểu diễn chính xác phụ thuộc vào phiên bản và loại thông điệp. Một sự kiện có thể mang ký tự giữ chỗ, sự kiện khác có thể bỏ hẳn trường đó, và một lần xác thực thất bại có thể không bao giờ có tên. Hãy kiểm tra hành vi được ghi trong tài liệu cho sự kiện cụ thể thay vì áp dụng một báo cáo lỗi cũ cho mọi danh tính bị thiếu.

Khi việc che giấu là có chủ đích, câu hỏi chuyển từ cách khôi phục trường sang liệu yêu cầu kiểm toán có thể được đáp ứng theo cách khác hay không. Mã định danh phiên, một ánh xạ danh tính được kiểm soát do nhóm nhỏ hơn nắm giữ, hoặc một nguồn sự kiện được ủy quyền hẹp hơn thường đáp ứng nhu cầu mà không đặt mọi tên người dùng từng thử trước mắt mọi người đọc nhật ký.

Ẩn danh trước khi lập chỉ mục không thể hoàn tác

Tài liệu của Splunk về xử lý sự kiện mô tả việc ẩn danh bằng các biểu thức sed và các phép biến đổi ghi lại hoặc loại bỏ dữ liệu trước khi lập chỉ mục. Chính vị trí đó là điểm mấu chốt: sự kiện thô bị thay đổi ngay khi đi vào, nên việc trích xuất tại thời điểm tìm kiếm không còn gì để tìm.

Việc biên tập tại thời điểm lập chỉ mục và việc trích xuất trường tại thời điểm tìm kiếm giải quyết các vấn đề khác nhau. Biên tập giới hạn ai có thể thấy giá trị; trích xuất chỉ quyết định truy vấn dùng tên nào. Băm là lựa chọn trung gian giữ được tương quan, nhưng một hàm băm ổn định trên không gian tên người dùng nhỏ vẫn mang tính nhận dạng khi ai đó có thể thử các tên ứng viên với nó.

Nếu sự kiện được lưu vẫn chứa danh tính, vấn đề nằm ở phía sau: loại nguồn, việc ngắt dòng, xử lý dấu phân cách, bí danh trường hoặc chính truy vấn. Đó là những sửa chữa phân tích thông thường và chúng không chạm tới ranh giới quyền riêng tư.

Chọn cách sửa khớp với ranh giới

Ba điều kiện quyết định phản ứng. Thứ nhất, chính sách quyền riêng tư có chủ đích loại trừ danh tính không? Thứ hai, quy trình kiểm toán hoặc điều tra cần danh tính, một bí danh, hay chỉ cần phiên? Thứ ba, cần giá trị ở ranh giới nào — thu thập, lưu trữ hay trình bày?

Nếu chính sách có chủ đích loại trừ, hãy thay đổi yêu cầu hoặc cách trình bày, không phải kiểm soát. Nếu chính sách cho phép danh tính nhưng việc thu thập làm mất nó, hãy sửa bộ thu thập và xác nhận sự kiện thô. Nếu lưu trữ còn nguyên vẹn, hãy sửa việc trích xuất và kiểm thử nó với sự kiện đã được phê duyệt mà bạn đã ghi lại lúc đầu.

Kết thúc điều tra bằng cách nêu ranh giới trong bản ghi thay đổi: bị che tại nguồn, bị xóa trong lúc nhập, hoặc bị trích xuất bỏ sót. Một câu đó nói cho kỹ sư tiếp theo biết nên xem ở đâu trước, và nó ngăn một khiếu nại về bảng điều khiển biến thành một tính năng quyền riêng tư bị tắt âm thầm.