Сокрытие конфиденциальных данных при логировании

[gleb_l]

«..скрываем данные о фактических зарплатах руководителей путем деления исходных значений на 10..»

Если серьезно - забыли аннотацию - данные ушли в лог в небезопасном виде. Уж лучше тогда сделать интерфейс ILoggable, в нем декларировать метод toLogString(), и разрешать логировать только классы, имплементирующие этот интерфейс

[riccio]

Идея ограничить возможность логировать объекты выглядит неплохо, но не везде применима: вспомним хотя бы protobuf или avro. И реализация интерфейса ILoggable все равно приводит нас к методу, который будет возвращать строковое представление объекта.

[aleksandy]

Да, приводит. Но не просто приводит, а явно заставляет реализовать метод для строкового представления логируемой информации, что уже является частью бизнес-логики приложения, а, следовательно, должно быть протестировано.

[tuxi]

Как по мне, первый способ со своей реализацией toString() наиболее правильный по двум причинам

1. он быстрый, если у вас хайлоад, это на мой взгляд важно.

2. существует не так много мест где надо скрывать номер телефона, фио, пароль и тд. По пальцам обычно можно пересчитать варианты этих User.

   Пароль кстати мне не понятно зачем выводить скрытым, так как настоящий все равно хэширован, а то что ввел пользователь, наоборот надо выводить, это будет одной из зацепок при разборе инцидентов в случае бутфорса например

[Batalmv]

Как по мне, первый способ со своей реализацией toString() наиболее правильный по двум причинам

А если toString() еще где-то используется, и там, в другом месте надо отдавать незамаскированнеы данные

Я вот думаю, может проще реализовать отдельный метод, который конвертит объект в строку для логирования. По умолчанию пусть под капотом будет toString, а в классах с "чуствительными" данными маскировать эти поля

Конечно в каждой строчек с логами надо будет его явно указывать, но скорость будет та же, зато нет риска словить сайд эффект

--------

Но я уже давно не программирую, поэтому возможно фигню сморозил

[breninsul]

ну обычно очень полезно логгировать jsonчики нам приходящие, что-бы анализировать что где пошло не так.

Но это не так важно. Важно что везде, кроме как маскирования в логгере, у вас пароль, к что хуже пан карты будет логгировать на любой чих.

Включили дебаг уровень, и не знали что ваш вреймворк начал логгировать аргументы метода? Привет PCI DSS.

Ненене, проходили. Все конфиденциальное имеет спец. структуру(или префикс/постфикс) и логгируется на уровне логгера.

[riccio]

Еще один подход к обработке логируемой строки, в том числе входящего JSON, в использовании PatternLayout.

[OlegZH]

Было бы любопытно потом разобраться во всех тонкостях приведённого кода. Можно будет задать вопросы в личку?

И ещё один вопрос. А могут ли поля класса сами быть экземплярами других классов? В этом случае, необходимость ведения лога включило бы на этапе конструктора объекта объемлющего класса некую разделяемую различными полями сущность, ответственную за формирование лога.

[riccio]

Давайте попробуем разобраться, что именно происходит. Напишите ваши вопросы личным сообщением, постараюсь вам помочь.

Если использовать в виде поля класса объект другого класса: например:

public class User {
//...
@Confidentially
private Address address;
}


то в консоли будет выведено null

[dopusteam]

Предположим, мы таким приемом скрыли номер телефона — в логе отобразился ноль

Вы храните номер телефона числом?)

[saymon_says]

Я на проекте расширил класс логгера, переопределил методы beforeRequest, afterRequest и createMessage. Внутри добавил логику что скрывать , что нет. Плюс добавил MDC чтоб весь процесс был явно виден и фильтрует в логах. Logback.xml свой паттерн тоже и все