Ẩn thông tin nhạy cảm/bí mật trong các tệp nhật ký

Question

Bạn sẽ ẩn thông tin nhạy cảm như thế nào khi truy cập tệp nhật ký? Có, bạn có thể chọn không đăng nhập các thông tin nhạy cảm ở nơi đầu tiên, nhưng có thể có trường hợp chung mà bạn đăng nhập một cách mù quáng thông báo lỗi khi thất bại hoặc theo dõi tin nhắn trong khi điều tra sự cố, v.v. tệp nhật ký.

Ví dụ: bạn có thể đang cố gắng chèn bản ghi đơn hàng chứa số thẻ tín dụng của khách hàng vào cơ sở dữ liệu. Khi một lỗi cơ sở dữ liệu, bạn có thể muốn đăng nhập câu lệnh SQL vừa được thực thi. Sau đó bạn sẽ kết thúc với số thẻ tín dụng của khách hàng trong một tệp nhật ký.

Có một mô hình thiết kế có thể được sử dụng để "gắn thẻ" một số thông tin nhất định như nhạy cảm để một đường ống ghi nhật ký chung có thể lọc chúng ra không?

Answer 1

Thực tiễn hiện tại của tôi đối với trường hợp được đề cập là ghi nhật ký băm của thông tin nhạy cảm đó. Điều này cho phép chúng tôi xác định các bản ghi nhật ký thuộc về một yêu cầu cụ thể (ví dụ một số thẻ tín dụng cụ thể) nhưng không cung cấp cho bất kỳ ai sức mạnh để chỉ lấy nhật ký và sử dụng thông tin nhạy cảm cho mục đích xấu xa của họ.

Tất nhiên, thực hiện điều này liên tục liên quan đến thực hành mã hóa tốt. Tôi thường chọn để đăng nhập tất cả các đối tượng sử dụng quá tải toString của họ (trong Java hoặc .NET) mà serializes băm của các giá trị cho các lĩnh vực được đánh dấu bằng một thuộc tính Sensitive áp dụng cho họ. Tất nhiên, chuỗi SQL có nhiều vấn đề hơn, nhưng chúng tôi dựa nhiều hơn vào ORM của chúng tôi để lưu giữ dữ liệu và ghi lại trạng thái của hệ thống ở các giai đoạn khác nhau, sau đó ghi lại truy vấn SQL, do đó nó trở thành không vấn đề.

Answer 2

Cá nhân tôi sẽ coi các tệp nhật ký là thông tin nhạy cảm và đảm bảo hạn chế quyền truy cập vào chúng.

Answer 3

Trong ví dụ của bạn, bạn nên mã hóa số thẻ tín dụng hoặc, tốt hơn, thậm chí không lưu trữ nó ở địa điểm đầu tiên.

Nếu, giả sử bạn đang đăng nhập một thứ khác, chẳng hạn như thông tin đăng nhập, bạn có thể muốn thay thế mật khẩu bằng *****.

Tuy nhiên, điều này quản lý gọn gàng tránh trả lời câu hỏi bạn đã đặt ra ngay từ đầu. Nói chung, khi xử lý thông tin nhạy cảm, nó phải được mã hóa trên đường đến bất kỳ hình thức lưu trữ vĩnh viễn nào, có thể là tệp cơ sở dữ liệu hoặc tệp nhật ký. Giả sử rằng một Bad Guy sẽ có thể có được bàn tay của họ trên một trong hai, và bảo vệ thông tin cho phù hợp.

Answer 4

Nếu bạn biết những gì bạn đang cố gắng lọc, bạn có thể chạy bạn đăng xuất thông qua biểu thức làm sạch Regex trước khi bạn đăng nhập.

Answer 5

Ghi nhật ký số thẻ tín dụng có thể là vi phạm PCI. Và nếu bạn không tuân thủ PCI, bạn sẽ bị tính phí xử lý thẻ cao hơn. Không đăng nhập thông tin nhạy cảm hoặc mã hóa toàn bộ tệp nhật ký của bạn.

Ý tưởng của bạn về thông tin nhạy cảm "gắn thẻ" là hấp dẫn. Bạn có thể có loại dữ liệu đặc biệt cho thông tin Sensitive, bao gồm loại dữ liệu cơ bản, thực. Bất cứ khi nào đối tượng này được hiển thị dưới dạng một chuỗi ký tự, nó chỉ trả lại "***" hoặc bất kỳ thứ gì.

Tuy nhiên, điều này có thể yêu cầu thay đổi mã rộng rãi và yêu cầu mức cảnh giác đồng nhất tương tự như cần thiết để tránh ghi nhật ký thông tin nhạy cảm ngay từ đầu.

Answer 6

Về các câu lệnh SQL cụ thể, nếu ngôn ngữ của bạn hỗ trợ nó, bạn nên sử dụng các tham số thay vì đặt các giá trị trong chính câu lệnh. Nói cách khác:

select * from customers where credit_card = ? 

Sau đó đặt tham số thành số thẻ tín dụng.

Tất nhiên, nếu bạn định ghi nhật ký câu lệnh SQL với các tham số được điền vào, bạn cần một số cách khác để lọc ra dữ liệu nhạy cảm.

Answer 7

Tham khảo công cụ này, được tạo chính xác cho trường hợp sử dụng này.

Nếu bạn muốn chỉ mặt nạ trường đã chọn, trong khi ghi nhật ký và giữ các giá trị trường khác như cũ. bạn có thể thử điều này.

https://github.com/senthilaru/sp-util

<dependency> 
    <groupId>com.immibytes</groupId> 
    <artifactId>sp-utils</artifactId> 
    <version>1.0.0-RELEASE</version> 
</dependency>