ами сбоев.
В качестве набора принципов запишите три вещи: входные данные, действия и решения. Регистрируйте контекст, который их информирует. Регистрируйте, кто, что, почему, когда и где. Регистрируйте как успехи, так и отказы, и подумайте о том, как ваши журналы будут использоваться дознавателями, спрашивающими, кто, что, как и когда. Они также будут спрашивать, почему, и ваши журналы могут помочь им ответить, почему ваше программное обеспечение что-то сделало.
Когда я говорю: «Регистрируйте „Кто“», я имею в виду коллекцию идентификаторов (то, что вы сделали для аутентификации каждого из них, описано в разделе «Почему?»). Это включает в себя следующие пункты:
• удаленную машину и все имена, которые она имеет в настоящее время (компьютеры имеют по крайней мере IP-адрес и DNS-имя; часто они имеют другие имена, такие как имена WINS, имена Zigbee, имена Bluetooth, MAC-адреса и т. п.);
• учетную запись, которая может состоять из одного или нескольких имен учетной записи и имен, ориентированных на приложение, а также номеров банковских или кредитных карт (например, я вхожу в систему как shostack и запускаю mysql-user wordpress);
• создателя журнала (это означает, какая машина и какое приложение создали журнал, потому что агрегирование журналов означает, что localhost может быть не очень информативным для пользователя или системы, читающих сообщение журнала).
Записывать «Что» означает записывать все то, что другая сторона отправляла или делала. Для человека это будут вводимые данные, включая текст, действия мыши, голос, жесты и мозговые волны. Записывайте команды и аргументы в журнал, а если ответы приходят откуда-то еще, возможно, зарегистрируйте и их. Для удаленного компьютера захват полного обмена данными полезен для отладки, но слишком подробен для длительного хранения.
Записывать «Что» также означает, какие внешние входные данные принимает ваш код и откуда. Это могут быть файлы, URL-адреса или IP-адреса. Регистрация полных путей к файлам и, возможно, даже хэшей может быть очень полезна для расследователей.
Записывать «Почему» означает регистрацию ваших решений: где и почему произошла развилка в коде? Какие решения по проверке подлинности или авторизации принимает ваш код и почему? Если вы проверили пароль, зарегистрируйте «password success», а не «password1 был использован для успешной проверки подлинности». Если вы испустите дух, запишите это.
Регистрировать «Когда» означает регистрировать события, которые происходят. Как мы обсуждаем в главе 7 «Предсказуемость и случайность», храните свои журналы в формате UTC.
Существует подход к протоколированию, называемый канонический журнал, который включает в себя дополнение «текущих» сообщений сводным сообщением журнала, содержащим всю полезную информацию в одном сообщении, чтобы избавить операторов от работы по ее реконструкции и корреляции. Это не должно помешать вам создавать журналы по ходу работы, особенно если ваш код подвергается атаке и так и не достигает функции, которая генерирует канонический журнал.
«Кто» и «Почему» будут активно использоваться в ответ на отказ. Если потребитель говорит: «Я не совершал эту транзакцию», – то мы можем вернуться назад и проверить, были ли какие-то факторы, которые выделялись как необычные. Если их было много (другой IP или геолокация, другой браузер), мы поверим ему с большей вероятностью. «Кто» и «Почему» также активно используются при реагировании на более сложные атаки. Если злоумышленник может пройти аутентификацию под именем Хан с помощью правильного пароля, мы, вероятно, захотим просмотреть каждое место, где Хан использует этот пароль.
Все это может привести к слишком многословным журналам. Применяйте суждения о том, что регистрируется и на каких уровнях отладки, но устанавливайте продуманные значения по умолчанию.
Для записи конфиденциальной информации (паролей, криптографических ключей, номеров социального страхования) может потребоваться специальная опция отладки.
Журналирование операций
Необходимо учитывать, где создаются журналы, куда они попадают и кто имеет к ним доступ. Возможно, ваше программное обеспечение является локальным приложением, и журналы остаются в этой системе. Возможно, журналы отправляются в облако или в службу агрегирования журналов.
Доступ к необработанным журналам или возможность выполнять произвольный код над данными журналов – это мощные средства (и рискованные, если в этих журналах содержится конфиденциальная информация). Когда журналы содержат личную информацию, важно иметь возможность отследить, кто получил к ним доступ. Поэтому, скорее всего, вы захотите создавать инструменты, поддерживающие распространенные сценарии. Отказ будет наиболее распространенным сценарием, когда у вас есть клиенты-люди, а автоматический сбор и анализ соответствующей информации ускоряет ответы и делает их более последовательными. Эти инструменты никогда полностью не заменят доступ к необработанному журналу для борьбы с новыми или необычными шаблонами атак. (Подробнее об этом – в разделе «Совместное использование журналов».)
Хранение журналов в течение длительного времени разумно, но может быть дорогостоящим. Вам нужно будет подумать о том, как долго вы храните ту или иную информацию. Существуют нормативные и эксплуатационные потребности. Операционные потребности могут быть разными, но нередко можно услышать о взломе, обнаруженном спустя годы после того, как это произошло, и возможность узнать, что сделал злоумышленник, может избавить вас от необходимости говорить своим клиентам: «Мы не знаем, получил ли злоумышленник доступ к личной информации, которую вы нам доверили, потому что у нас нет журналов».
В то время как отказ потребителя обычно происходит немедленно, атаки часто обнаруживаются спустя годы. К сожалению, современные операционные системы имеют политики ротации журналов, которые были разработаны, когда диски стоили доллары за мегабайт, и эти политики с тех пор не обновлялись. Ваши операционные системы выбрасывают журналы до того, как обнаружат вторжение и поймают злоумышленника. Как правило, ротация и регулирование приводят к перемещению журналов в какое-либо центральное хранилище.
Наконец, Национальный центр компьютерной безопасности Великобритании (National Computer Security Centre) опубликовал несколько убедительных рекомендаций на странице «Введение в ведение журналов в целях безопасности» [Introduction to logging for security purposes, NCSC, 2018].
Персональные данные в журналах
Журналы будут содержать личную информацию, и поэтому с ними нужно обращаться осторожно. Тщательное обращение включает в себя управление разрешениями на чтение журналов, возможное разделение данных на несколько журналов, токенизацию данных или написание инструментов для извлечения данных из журналов на различных уровнях детализации.
Как правило, рекомендуется токенизировать всю личную информацию. Это означает замену конфиденциальных данных случайной строкой и сохранение сопоставления между токенами и защищенными значениями. Иногда токенизацию отождествляют с криптографическими методами, такими как хэширование или шифрование. Хэширование подвержено словарным атакам. Злоумышленник создает, скажем, словарь всех возможных телефонных номеров или номеров социального страхования, а затем хэширует каждый из них. Теперь у него есть словарь всех открытых текстовых и хэшированных значений, и для небольших списков, таких как миллиарды телефонных номеров, это делается довольно быстро. Кроме того, если вы токенизируете, может случиться так, что удаление ссылки из токена на идентифицируемую информацию может помочь выполнить обязательства по правилам «права на забвение».
Реагируя на отказы потребителей от транзакций, можно проверить токенизированную информацию, а не необработанную информацию. Точно так же осуществление права на забвение похоже на отказ от отношений клиента с вами. (Реализация может быть даже идентичной, но в этой книге нет юридических советов.)
Кроме того, вам может потребоваться зарегистрировать тот факт, что вы удалили всю информацию о человеке. (Не смотрите на меня, посмотрите на европейское право!) По иронии судьбы, для этого может потребоваться записать то, что вы когда-то знали. Хранение имен полей, а не значений, вероятно, является хорошим началом. Вы также можете сохранить хэш ключа индекса, например адрес электронной почты или номер телефона, в тех случаях, когда вы не можете сохранить отображение.
Журналы сторонних участников
Существует множество причин для того, чтобы журналы вели третьи лица. Совсем не просто быстро обслуживать множество прозрачных однопиксельных GIF-файлов, чтобы отслеживать, когда люди просматривают электронные письма, открывают документы или отображают веб-страницы. Почему бы не позволить кому-то другому делать это и владеть процессом выявления и масштабирования атаки?
Также полезно то, что независимая третья сторона, создающая журналы, может выступать в качестве оплота против ложных отказов. Записи, хранящиеся в ходе обычной коммерческой деятельности, считаются надежными, по крайней мере в Соединенных Штатах. (Есть пределы. Я не превратился волшебным образом в юриста с тех пор, как вы начали читать эту книгу, и даже если бы я им стал, это не было бы юридическим советом.) Таким образом, такие компании, как DocuSign, могут не только помочь управлять процессом подписания, но и вести журналы или криптографически подписывать документы. (Я не знаю, что на самом деле делает DocuSign, это просто гипотетический пример.)
Журналирование vs Аудит
Microsoft называет систему ведения журналов Windows системой аудита [Microsoft, 2017]. Это может привести к путанице в понимании того, что такое аудит, о чем свидетельствуют такие утверждения, как «У нас есть аудит». Аудит – это инспекция или проверка, чтобы убедиться, что вы ведете надлежащий учет и соответствуют ли предпринимаемые вами действия вашим обязательствам. Аудит может быть проведен по журналам или оказаться невозможен из-за их отсутствия или недостаточности.