Сокрытие чувствительной / конфиденциальной информации в файлах журнала
Насколько я знаю не точно, но Вы добираетесь где-нибудь с
object.methods.sort
6 ответов
Моя текущая практика для рассматриваемого случая - регистрировать хэш такой конфиденциальной информации. Это позволяет нам идентифицировать записи журналов, которые относятся к определенному требованию (например, конкретному номеру кредитной карты), но не дает никому возможности просто захватить журналы и использовать конфиденциальную информацию в своих злых целях.
Конечно, для этого постоянно требуются хорошие методы кодирования. Обычно я предпочитаю регистрировать все объекты, используя их перегрузки toString (в Java или .NET), которые сериализуют хэш значений для полей, отмеченных атрибутом Sensitive , примененным к ним.
Конечно, строки SQL более проблематичны, но мы больше полагаемся на нашу ORM для сохранения данных и регистрируем состояние системы на различных этапах, а затем регистрируем запросы SQL, поэтому это не проблема.
Я лично считаю файлы журнала конфиденциальной информацией и обязательно ограничиваю доступ к ним.
Регистрация номера кредитной карты может быть нарушением PCI. А если вы не соответствуете требованиям PCI, с вас будет взиматься более высокая комиссия за обработку карты. Либо не регистрируйте конфиденциальную информацию, либо зашифруйте все файлы журнала.
Ваша идея «пометить» конфиденциальную информацию интригует. У вас может быть специальный тип данных для конфиденциальной информации, который содержит реальный базовый тип данных. Всякий раз, когда этот объект отображается как строка символов, он просто возвращает "***" или что-то еще.
Однако это может потребовать повсеместных изменений кодирования и уровня осознанной бдительности, аналогичной той, которая необходима для того, чтобы в первую очередь не регистрировать конфиденциальную информацию.
В вашем примере вы должны зашифровать номер кредитной карты или, что еще лучше, вообще не сохранять его.
Если, скажем, вы регистрировали что-то еще, например логина, вы можете явно заменить пароль на *****.
Тем не менее, это позволяет аккуратно избежать ответа на вопрос, который вы изначально задали. В общем, при работе с конфиденциальной информацией она должна быть зашифрована на пути к любой форме постоянного хранилища, будь то файл базы данных или файл журнала. Предположим, что плохой парень сможет достать и то, и другое, и соответственно защитить информацию.
Если вы знаете, что пытаетесь отфильтровать, вы можете запустить вывод журнала через выражение очистки Regex, прежде чем регистрировать его.
В частности, что касается операторов SQL, если ваш язык поддерживает их, вам следует использовать параметры вместо того, чтобы помещать значения в сам оператор. Другими словами:
select * from customers where credit_card = ?
Затем установите параметр на номер кредитной карты.
Конечно, если вы планируете регистрировать операторы SQL с заполненными параметрами, вам потребуется другой способ отфильтровать конфиденциальные данные.