Я собираюсь написать руководство компании о том, что никогда не должно появляться в журналах (след приложения). На самом деле, некоторые разработчики пытаются включить в трассировку как можно больше информации, делая хранение этих журналов рискованным и крайне опасным для отправки , особенно когда клиент не знает, хранится ли эта информация, потому что он никогда не заботился об этом. и никогда не читайте документацию и / или предупреждающие сообщения.
Например, при работе с файлами некоторые разработчики испытывают желание отследить имена файлов . Например, перед добавлением имени файла в каталог, если мы отследим все по ошибке, будет легко заметить, например, что добавленное имя слишком длинное и что ошибка в коде заключалась в том, чтобы забыть проверить длину каскадная строка. Это полезно, но это конфиденциальные данные, которые никогда не должны появляться в журналах .
Точно так же:
- Пароли ,
- IP-адреса и информация о сети (MAC-адрес, имя хоста и т. Д.) ¹,
- Доступ к базе данных,
- Прямой ввод от пользователя и сохраненных бизнес-данных
никогда не должен появляться в след.
Так какие еще виды информации должны быть исключены из журналов? Есть ли уже написанные инструкции, которые я могу использовать?
¹ Очевидно, я не говорю о таких вещах, как журналы IIS или Apache. Я говорю о том, какая информация собирается только с целью отладки самого приложения, а не для отслеживания действий ненадежных объектов.
Изменить: Спасибо за ваши ответы и ваши комментарии. Поскольку мой вопрос не слишком точен, я постараюсь ответить на вопросы, заданные в комментариях:
- Что я делаю с журналами?
Журналы приложения могут храниться в памяти, что означает либо в виде простого на жестком диске на локальном хосте, в базе данных, снова в виде простого или в событиях Windows. В любом случае проблема заключается в том, что эти источники могут быть недостаточно безопасными. Например, когда клиент запускает приложение, и это приложение сохраняет журналы в виде простого текстового файла во временном каталоге, любой, кто имеет физический доступ к ПК, может прочитать эти журналы.
Журналы заявки также могут быть отправлены через Интернет. Например, если у клиента возникла проблема с приложением, мы можем попросить его запустить это приложение в режиме полной трассировки и отправить нам файл журнала. Кроме того, некоторые приложения могут автоматически отправлять нам отчеты о сбоях (и даже если есть предупреждения о конфиденциальных данных, в большинстве случаев клиенты их не читают).
- Я говорю о конкретных полях?
Я работаю только с обычными бизнес-приложениями, поэтому единственными конфиденциальными данными являются бизнес-данные. Нет ничего, связанного со здоровьем или другими областями, подпадающими под определенные правила Но спасибо, что поговорили об этом, я, вероятно, должен взглянуть на эти поля, чтобы найти некоторые подсказки о том, что я могу включить в рекомендации.
- Не проще ли зашифровать данные?
Нет. Это усложнит каждое приложение, особенно если мы хотим использовать диагностику C # и TraceSource
. Это также потребовало бы управления авторизациями, что не так просто. Наконец, если мы говорим о журналах, представленных нам от клиента, мы должны иметь возможность читать журналы, но без доступа к конфиденциальным данным. Технически легче вообще никогда не включать конфиденциальную информацию в журналы и никогда не заботиться о том, как и где хранятся эти журналы.
debug
имени файла, но не дляinfo
имени файла.