Яка інформація ніколи не повинна відображатися в журналах? [зачинено]

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

Наприклад, працюючи з файлами, деякі розробники спокушаються відстежувати назви файлів . Наприклад, перед тим, як додати ім'я файлу до каталогу, якщо ми простежимо все на помилці, буде легко помітити, наприклад, що додане ім'я занадто довге, і що помилка в коді повинна була забути перевірити на наявність довжини з'єднаний рядок. Це корисно, але це конфіденційні дані і ніколи не повинні з’являтися в журналах .

Таким же чином:

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

ніколи не повинні з'являтися в слід.

То які ще типи інформації потрібно виганяти з журналів? Чи є вже написані вказівки, які я можу використовувати?

^{¹ Очевидно, я не говорю про речі, як журнали IIS або Apache. Те, про що я говорю, - це така інформація, яка збирається з єдиною метою налагодити саме додаток, а не простежити за діяльністю недовірених осіб.}

Редагувати: Дякую за відповіді та ваші коментарі. Оскільки моє запитання не надто точне, я спробую відповісти на питання, задані в коментарях:

• Що я роблю з колодами?

Журнали програми можуть зберігатися в пам'яті, що означає або на простому диску на жорсткому диску в localhost, в базі даних, знову в простому або в Windows Events. У кожному випадку, проблема полягає в тому, що ці джерела можуть бути недостатньо безпечними. Наприклад, коли клієнт запускає програму і ця програма зберігає журнали у текстовому файлі у текстовому каталозі, будь-хто, хто має фізичний доступ до ПК, може прочитати ці журнали.

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

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

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

• Чи не простіше шифрувати дані?

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

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

Подумайте, як би ви захистили ту саму інформацію, якби вона відображалася в звичайному інтерфейсі користувача. Вам слід було б визначити, хто такий користувач, а потім викласти лише ту інформацію, яку цей користувач мав право бачити.

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

Передача погано розроблених файлів журналів є величезним ризиком для безпеки. Я не вірю, що ви отримаєте хороше рішення для цього, переклавши якісь дані. Кращою стратегією є створення білого списку того, що може входити у кожен файл журналу, та проектування файлів журналу знизу вгору.

Інформація про кредитні картки ніколи не повинна реєструватися.

Ідентифікаційні номери (наприклад, SSN в США або Teudat Zehut # в Ізраїлі).

Мережеві імена комп’ютера, мережеві спільні шляхи.

Персональна ідентифікаційна медична інформація, на яку поширюється Закон про переносність та підзвітність медичного страхування 1996 року (HIPAA). У цій статті перелічені наступні приклади:

• Заяви на охорону здоров'я або зустрічі з інформацією про охорону здоров'я, наприклад, документацією відвідувань лікаря та записками, зробленими лікарями та іншим персоналом лікаря;
• Консультації щодо оплати та переказу медичних послуг;
• Координація переваг в галузі охорони здоров'я;
• Статус претензій на охорону здоров'я;
• Зарахування та зарахування до плану здоров’я;
• Придатність до плану охорони здоров'я;
• Виплати за медичний план;
• Сертифікати та авторизація направлення;
• Перший звіт про травму;
• Медичні претензії вкладення.

якщо безпека турбує, зашифруйте файл журналу

Зверху моєї голови ...

Інформація про кредитні картки не повинна міститись у журналах. Дані SSN (або SIN) не повинні знаходитись у журналах.

... звичайно, є винятки, якщо вам трапляється працювати в якомусь центральному сховищі даних для компанії з кредитними картками або урядовим агентством, яке управляє даними SIN, то, можливо, вам доведеться записати їх, оскільки це головне м'ясо того, що ви переробляємо / керуємо.

Так, але.

Для налагодження деяких проблем потрібні реальні дані.

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

Я працював у сфері контролю за повітряним рухом, фінансах та банківській справі. У кожній ситуації є конфіденційні дані. Є завдання, з якими неминуче обробляти конфіденційні дані, у тих випадках вам потрібно переконатися в тому, що ви працюєте з надійними людьми. Цей ризик може бути дещо пом’якшений юридичними застереженнями, про які слід домовитись перед тим, як отримати доступ до таких даних (угоди про нерозголошення, використання даних лише з поважних ділових причин, обмежений доступ до даних, кримінальне переслідування за невиконання або примусове виконання угод ...) - і відповідні процеси, які дозволяють відстежувати ці речі.

Якщо дані є критичними, то вам доведеться заплатити ціну за налаштування систем, що захищають цілісність, узгодженість та безпеку цих даних.

Це сказало, що ви праві ставити питання "які дані". Справді ви самі на це відповідаєте: більша частина стосується бізнесу. Тож попросіть своїх клієнтів, якщо ви самі не можете відповісти, маючи на увазі все вищезазначене та дотримуючись певного способу виявлення та вирішення проблем, які можуть виникнути.

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

Зберігайте повідомлення журналу тьмяними :)