Mặt nạ dữ liệu nhạy cảm có thể định cấu hình qua log4net

Question

Tôi đang xem xét việc sử dụng log4net làm khung đăng nhập được lựa chọn cho một dự án mới bắt đầu ngay. Một vấn đề mà tôi đã chạy vào trong quá trình tạo mẫu mà tôi không thể tìm thấy câu trả lời chính xác là cách bạn có thể làm sạch hoặc che giấu nội dung thư theo cách có thể định cấu hình và ngăn nắp.

Giả sử giả sử tôi muốn một số chất tẩy rửa được đưa vào hoạt động nhưng tôi cũng muốn tuân theo nguyên tắc trách nhiệm duy nhất. Một số ví dụ sạch:

• Cardnumber/PAN sạch
• Mật khẩu sạch
• dữ liệu cá nhân sạch

Tôi biết rằng bạn không bao giờ nên đăng nhập loại thông tin này trong văn bản đơn giản và mã thực thi các bản ghi sẽ không bao giờ cố tình làm điều này. Tôi muốn có một mức độ bảo vệ cuối cùng tuy nhiên trong trường hợp dữ liệu trở nên không đúng định dạng và dữ liệu nhạy cảm bằng cách nào đó trượt vào một nơi nào đó nó không nên; nhật ký là trường hợp xấu nhất.

Lựa chọn 1:

tôi đã tìm thấy bài viết này StackOverflow định chi tiết một giải pháp khả thi tuy nhiên nó liên quan đến việc sử dụng phản ánh. Điều này là không mong muốn cho hiệu suất nhưng nó cũng có vẻ hacky để thao tác cơ chế lưu trữ nội bộ. Editing-log4net-messages-before-they-reach-the-appenders

Phương án 2:

Câu trả lời gợi ý trên cùng một câu hỏi gợi ý việc sử dụng một PatternLayoutConverter. Điều này là tốt cho một hoạt động làm sạch duy nhất nhưng bạn không thể sử dụng nhiều các hoạt động như dưới đây:

public class CardNumberCleanerLayoutConverter : PatternLayoutConverter 
{ 
    protected override void Convert(TextWriter writer, LoggingEvent loggingEvent) 
    { 
     string message = loggingEvent.RenderedMessage; 

     // TODO: Replace with real card number detection and masking. 
     writer.Write(message.Replace("9", "*")); 
    } 
} 

<layout type="log4net.Layout.PatternLayout"> 
    <converter> 
     <name value="cleanedMessage" /> 
     <type value="Log4NetPrototype.CardNumberCleanerLayoutConverter, Log4NetPrototype" /> 
    </converter> 
    <converter> 
     <name value="cleanedMessage" /> 
     <type value="Log4NetPrototype.PasswordCleanerLayoutConverter, Log4NetPrototype" /> 
    </converter> 
    <conversionPattern value="%cleanedMessage" /> 
</layout> 

Trong trường hợp của một vụ va chạm đặt tên như trình bày ở trên, bộ chuyển đổi nạp cuối cùng sẽ là một trong những đó là hành động. Sử dụng ví dụ trên, điều này có nghĩa là mật khẩu sẽ được làm sạch chứ không phải số thẻ.

Lựa chọn 3:

Một lựa chọn thứ ba mà tôi đã cố gắng là việc sử dụng các trường hợp ForwarderAppender xích nhưng điều này nhanh chóng làm phức tạp cấu hình và tôi sẽ không xem xét nó một giải pháp lý tưởng. Bởi vì lớp LoggingEvent có một tài sản RenderedMessage bất biến chúng tôi không thể thay đổi nó mà không cần tạo một thể hiện mới của lớp LoggingEvent và đi qua nó qua như chứng minh dưới đây:

public class CardNumberCleanerForwarder : ForwardingAppender 
{ 
    protected override void Append(LoggingEvent loggingEvent) 
    { 
     // TODO: Replace this with real card number detection and masking. 
     string newMessage = loggingEvent.RenderedMessage.Replace("9", "*"); 

     // What context data are we losing by doing this? 
     LoggingEventData eventData = new LoggingEventData() 
     { 
     Domain = loggingEvent.Domain, 
     Identity = loggingEvent.Identity, 
     Level = loggingEvent.Level, 
     LocationInfo = loggingEvent.LocationInformation, 
     LoggerName = loggingEvent.LoggerName, 
     ExceptionString = loggingEvent.GetExceptionString(), 
     TimeStamp = loggingEvent.TimeStamp, 
     Message = newMessage, 
     Properties = loggingEvent.Properties, 
     ThreadName = loggingEvent.ThreadName, 
     UserName = loggingEvent.UserName 
     }; 

     base.Append(new LoggingEvent(eventData)); 
    } 
} 

public class PasswordCleanerForwarder : ForwardingAppender 
{ 
    protected override void Append(LoggingEvent loggingEvent) 
    { 
     // TODO: Replace this with real password detection and masking. 
     string newMessage = loggingEvent.RenderedMessage.Replace("4", "*"); 

     // What context data are we losing by doing this? 
     LoggingEventData eventData = new LoggingEventData() 
     { 
     Domain = loggingEvent.Domain, 
     Identity = loggingEvent.Identity, 
     Level = loggingEvent.Level, 
     LocationInfo = loggingEvent.LocationInformation, 
     LoggerName = loggingEvent.LoggerName, 
     ExceptionString = loggingEvent.GetExceptionString(), 
     TimeStamp = loggingEvent.TimeStamp, 
     Message = newMessage, 
     Properties = loggingEvent.Properties, 
     ThreadName = loggingEvent.ThreadName, 
     UserName = loggingEvent.UserName 
     }; 

     base.Append(new LoggingEvent(eventData)); 
    } 
} 

cấu hình Matching (rất khó để làm theo):

<log4net> 
    <appender name="LocatedAsyncForwardingAppender" type="Log4NetPrototype.LocatedAsyncForwardingAppender, Log4NetPrototype"> 
     <appender-ref ref="CardNumberCleanerForwarder" /> 
    </appender> 
    <appender name="CardNumberCleanerForwarder" type="Log4NetPrototype.CardNumberCleanerForwarder, Log4NetPrototype"> 
     <appender-ref ref="PasswordCleanerForwarder" /> 
    </appender> 
    <appender name="PasswordCleanerForwarder" type="Log4NetPrototype.PasswordCleanerForwarder, Log4NetPrototype"> 
     <appender-ref ref="LogFileAppender" /> 
    </appender> 
    <appender name="LogFileAppender" type="Log4NetPrototype.LogFileAppender, Log4NetPrototype"> 
     <layout type="log4net.Layout.PatternLayout"> 
     <conversionPattern value="%m" /> 
     </layout> 
    </appender> 
    <root> 
     <level value="DEBUG" /> 
     <appender-ref ref="LocatedAsyncForwardingAppender" /> 
    </root> 
</log4net> 

Có ai có đề xuất khác về cách thức này có thể được triển khai khi số lượng chất tẩy rửa có thể được định cấu hình theo chi phí hiệu suất không?

Answer 1

Trong câu hỏi của bạn, bạn đã nói rằng bạn nên đi đến nguyên nhân và không ghi lại bất kỳ dữ liệu nhạy cảm nào. Điều này có thể được thực thi bằng tùy chọn thứ tư sử dụng các đánh giá mã và xem dữ liệu đang được ghi lại. Các câu lệnh đăng nhập của bạn sẽ không bao giờ ghi lại bất kỳ dữ liệu nhạy cảm nào, bởi vì nguyên nhân gây ra một nguy cơ bảo mật.Tin tưởng vào bất kỳ mã nào có bộ lọc, dữ liệu nhạy cảm có thể sẽ thất bại nếu bạn thực hiện các thay đổi đối với dự án của mình. Quá trình QA của bạn phải thực sự tốt để nắm bắt loại lỗi này (tôi chưa bao giờ thấy một người kiểm tra đi qua tất cả các nhật ký). Vì vậy, tôi sẽ đi cho tùy chọn 4 mà là đảm bảo rằng bạn không đăng nhập loại thông tin này ở nơi đầu tiên.