Какая информация никогда не должна появляться в журналах? [закрыто]

Я собираюсь написать руководство компании о том, что никогда не должно появляться в журналах (след приложения). На самом деле, некоторые разработчики пытаются включить в трассировку как можно больше информации, делая хранение этих журналов рискованным и крайне опасным для отправки , особенно когда клиент не знает, хранится ли эта информация, потому что он никогда не заботился об этом. и никогда не читайте документацию и / или предупреждающие сообщения.

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

Точно так же:

• Пароли ,
• IP-адреса и информация о сети (MAC-адрес, имя хоста и т. Д.) ¹,
• Доступ к базе данных,
• Прямой ввод от пользователя и сохраненных бизнес-данных

никогда не должен появляться в след.

Так какие еще виды информации должны быть исключены из журналов? Есть ли уже написанные инструкции, которые я могу использовать?

^{¹ Очевидно, я не говорю о таких вещах, как журналы IIS или Apache. Я говорю о том, какая информация собирается только с целью отладки самого приложения, а не для отслеживания действий ненадежных объектов.}

Изменить: Спасибо за ваши ответы и ваши комментарии. Поскольку мой вопрос не слишком точен, я постараюсь ответить на вопросы, заданные в комментариях:

• Что я делаю с журналами?

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

Журналы заявки также могут быть отправлены через Интернет. Например, если у клиента возникла проблема с приложением, мы можем попросить его запустить это приложение в режиме полной трассировки и отправить нам файл журнала. Кроме того, некоторые приложения могут автоматически отправлять нам отчеты о сбоях (и даже если есть предупреждения о конфиденциальных данных, в большинстве случаев клиенты их не читают).

• Я говорю о конкретных полях?

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

• Не проще ли зашифровать данные?

Нет. Это усложнит каждое приложение, особенно если мы хотим использовать диагностику C # и TraceSource. Это также потребовало бы управления авторизациями, что не так просто. Наконец, если мы говорим о журналах, представленных нам от клиента, мы должны иметь возможность читать журналы, но без доступа к конфиденциальным данным. Технически легче вообще никогда не включать конфиденциальную информацию в журналы и никогда не заботиться о том, как и где хранятся эти журналы.

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

Подумайте, как бы вы защитили ту же информацию, если бы она отображалась в обычном пользовательском интерфейсе. Вам нужно будет определить, кем был пользователь, а затем предоставить только ту информацию, которую этот пользователь имел право видеть.

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

Передача плохо спроектированных файлов журналов - огромный риск для безопасности. Я не верю, что вы получите хорошее решение для этого, занеся в черный список какие-то данные. Лучшей стратегией является внесение в белый список того, что может быть в каждом файле журнала, и создание файлов журнала снизу вверх от этого.

Информация о кредитной карте никогда не должна регистрироваться.

Идентификационные номера (например, SSN в США или Teudat Zehut # в Израиле).

Сетевые имена компьютеров, общие сетевые пути.

Идентифицируемая личность информация о состоянии здоровья подпадает под действие Закона о мобильности и подотчетности медицинского страхования 1996 года (HIPAA). В этой статье перечислены следующие примеры:

• Претензии в отношении медицинского обслуживания или сведения о медицинском обслуживании, такие как документация посещений врача и записи, сделанные врачами и другим персоналом поставщика;
• Оплата медицинских услуг и консультации по денежным переводам;
• Координация льгот по здравоохранению;
• Статус заявки на медицинское обслуживание;
• Регистрация и исключение из плана медицинского обслуживания;
• Право на получение плана медицинского обслуживания;
• Страховые взносы по плану медицинского страхования;
• Реферальные сертификаты и авторизация;
• Первый отчет о травме;
• Здоровье требует вложений.

если проблема безопасности, зашифруйте файл журнала

С верхней части моей головы....

Информация о кредитной карте не должна быть в журналах. Данные SSN (или SIN) не должны быть в журналах.

... конечно, есть исключения: если вам приходится работать в каком-то центральном хранилище данных для компании-эмитента кредитных карт или государственного учреждения, которое управляет данными SIN, то вам, возможно, придется регистрировать их, потому что это основная часть того, что вы Перерабатываю / управляю.

Да, но.

Для устранения некоторых проблем вам нужны реальные данные.

Таким образом, вы должны играть в балансную игру: вы должны обсудить и согласовать со своими основными клиентами, что они считают конфиденциальными или конфиденциальными данными, а что нет. Если несколько клиентов не согласны, примите во внимание наихудший сценарий для каждого аспекта, если только вы не можете оправдать его для тех клиентов, которые могут зацикливаться на маркировке всего чувствительного.

Я работал в авиадиспетчерской, финансовой и банковской сферах. В каждой ситуации есть конфиденциальные данные. Существуют задачи, для которых неизбежно работать с конфиденциальными данными, в таких случаях вам нужно как можно больше убедиться, что вы работаете с заслуживающими доверия людьми. Этот риск может быть несколько смягчен юридическими положениями, которые должны быть согласованы до получения доступа к таким данным (соглашения о неразглашении, использование данных только по уважительным деловым причинам, ограниченный доступ к данным, штрафы за судебное преследование за несоблюдение или обеспечение соблюдения соглашений ...) - и соответствующие процессы, которые позволяют отслеживать эти вещи.

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

Тем не менее, вы правы, чтобы задать вопрос «какие данные». Воистину, вы отвечаете сами: в основном это связано с бизнесом. Поэтому спросите своих клиентов, не можете ли вы ответить самостоятельно - с учетом всего вышесказанного и оставьте некоторый способ выявления и устранения проблем, которые могут возникнуть.

Я бы сказал, регистрировать сообщения, которые кажутся смешными, пока вы пишете код. Вы не найдете их забавными в будущем, и они будут там навсегда - как этот опрометчивый пост в блоге / фейсбуке / твиттере!

Вести журнал сообщений скучно :)