Comments 3
Используйте серверное время с регулярной синхронизацией с сервером NTP.
Мне кажется не совсем корректное предложение. Тут два нюанса:
Система может быть распределённой по разным регионам, находящимся в различных часовых поясах. Или даже если это не так - то разные приложения могут функционировать в разных часовых поясах (и это будет важно - когда логи будут сводиться в единую базу). Поэтому, правильнее приводить время к Гринвичу (UTC+00).
Пользователи могут работать из разны часовых поясов, и чтобы точнее определять момент события с точки зрения пользователя - нужно сохранять ещё и время клиента из сеанса пользователя. Ну, скажите - что не дело обсуждать с пользователем на камчатке, события приведённые к нулевому меридиану, а если таких пользователей в процессе было задействовано несколько и все в разных часовых поясах? Но тут сложности, когда пользователи с других часовых поясов работают через RDP - тут время клиента будет временем терминального сервера для всех. И вот тут уже вопрос как правильно поступать в таких случаях. Особенно всё усложняется, когда клиент одного и того же пользователя по факту может быть запущен на разных компьютерах, в разных часовых поясах (а такое вполне возможно, хотя навряд ли одновременно, но лично встречал когда то так, то эдак работал клиент; да хоть взять ещё и коммандировщиков - которые в разъездах по стране и клиент запущен у них на ноутбуках - хотя тут уже свои нюансы - часовой пояс в этом случае не все переведу, хотя он может и автоматически переводится, тем более если это смартфон/планшет с включённой синхронизацией по сети).
Работать с другого часового пояса пользователь может ещё и через Интернет или через VPN канал.
Спасибо за комментарий который улучшает статью, и добавляет идей для читателей.
Временные метки, учет часовых поясов и различных форматов дат в журналах аудита - это важная тема особенно для приложений с распределенной инфраструктурой. В статье я не пытался описать настолько детальную реализацию функций журнала, а нюансы о которых Вы пишете точно важны и могут быть даже сложнее и здесь, на мой взгляд, для ответственных за разработку продукта применим итерационный подход - на первом этапе использовать простое добавление меток времени к событиям серверной части приложения, и дальнейшее улучшение о которых Вы пишете если это требуется клиентам (например, сотрудникам SOC при расследовании инцидентов).
Что касается сценария одновременного использования приложения одним пользователем о котором пишете - так это довольно частый сценарий когда пользователь одновременно подключается к SaaS приложению, например, с рабочего ноутбука и мобильного телефона.
Не очень удачный российский пример приведен:
ПОЧЕМУ МЕГАПЛАН НЕЛЬЗЯ ВЗЛОМАТЬ?
После такого вопроса-утверждения доверия к компании в части ИБ становится только меньше.
5 шагов до крупного заказчика: что сделать SaaS-приложению, чтобы начать работать с enterprise