اعتبار لاگ سرور در دادگاه به این بستگی دارد که اطلاعات ثبت‌شده تا چه اندازه قابل اعتماد، قابل انتساب و قابل بررسی باشند. لاگ‌های سرور می‌توانند به‌عنوان بخشی از ادله الکترونیکی در اختلافات حقوقی و پرونده‌های جرایم رایانه‌ای مطرح شوند؛ اما صرف ارائه یک فایل متنی یا تصویر از پنل هاست، وقوع جرم یا هویت شخص مسئول را ثابت نمی‌کند. برای ارزیابی ارزش اثباتی این اطلاعات، منشأ ثبت رویداد، صحت زمان‌ها، احتمال دستکاری، روش استخراج و زنجیره حفاظت از شواهد اهمیت دارد.
در اختلاف میان مالک سایت و شرکت هاستینگ، ادعای نفوذ غیرمجاز، حذف اطلاعات، سوءاستفاده از حساب مدیریتی یا نقض تعهدات پشتیبانی، لاگها ممکن است مسیر بررسی فنی را روشن کنند. بااین‌حال، تحلیل نادرست یک آدرس IP یا اختلاف ساعت میان دو سرور میتواند تصویری گمراه‌کننده از حادثه بسازد. آشنایی با ساختار لاگ، روش حفظ اصالت فایل و حدود اعتبار گزارش کارشناسی به مدیران سرور، صاحبان کسب‌وکارهای اینترنتی و طرفین اختلاف کمک می‌کند شواهد را به‌شکلی دقیق‌تر و قابل دفاع ارائه کنند.
لاگ سرور چه اطلاعاتی را ثبت می‌کند؟
لاگ سرور مجموعه‌ای از رویدادهایی است که سیستم‌عامل، وب‌سرور، نرم‌افزار یا تجهیزات شبکه در جریان فعالیت خود ثبت می‌کنند. بسته به تنظیمات سرویس، این اطلاعات میتواند شامل زمان درخواست، آدرس IP مبدأ، مسیر درخواست‌شده، کد پاسخ HTTP، شناسه کاربر، خطاهای نرم‌افزاری یا تلاش برای ورود به سیستم باشد. بعضی رویدادها به‌صورت خودکار ثبت می‌شوند و بعضی دیگر تنها در صورت فعال‌بودن قابلیت ثبت وقایع در دسترس هستند. بنابراین نبودن یک رخداد در لاگ همیشه به معنای رخ‌ندادن آن نیست.
برای نمونه، هنگام بررسی ادعای دسترسی غیرمجاز به مدیریت وردپرس، ممکن است لاگ وب‌سرور درخواست‌های مربوط به صفحه ورود را نشان دهد. در مقابل، تشخیص اینکه ورود واقعاً موفق بوده یا چه تغییری در سایت ایجاد شده است، احتمالاً به سوابق احراز هویت، افزونه ثبت فعالیت یا لاگ پایگاه داده نیاز دارد. متخصص بررسی حادثه باید مشخص کند هر رویداد در کدام لایه ثبت شده و چه محدودیت‌هایی دارد. این تفکیک از تبدیل یک نشانه فنی به نتیجه‌گیری حقوقی شتاب‌زده جلوگیری می‌کند.
اطلاعاتی که بهتر است در زمان بررسی حفظ شوند
- فایل اصلی لاگ همراه با مسیر ذخیره‌سازی و مشخصات سرور تولیدکننده
- زمان شروع و پایان بازه مورد بررسی و منطقه زمانی ثبت رویدادها
- نسخه نرم‌افزار، تنظیمات ثبت وقایع و سیاست چرخش لاگها
- سوابق ورود مدیران، تغییر سطح دسترسی و فعالیت حساب‌های دارای امتیاز بالا
- لاگ فایروال، پراکسی معکوس، CDN و سامانه‌های امنیتی مرتبط
- نسخه حفاظت‌شده فایل، مقدار هش و صورت‌جلسه استخراج شواهد
چه تفاوتی میان لاگ وب‌سرور و لاگ سیستم‌عامل وجود دارد؟
لاگ وب‌سرور عمدتاً فعالیت درخواست‌های HTTP و HTTPS، پاسخ‌های سرویس و خطاهای مربوط به ارائه محتوای وب را ثبت می‌کند. در محیط‌هایی مانند Apache و Nginx، فایل‌های دسترسی و خطا از مهم‌ترین منابع تحلیل هستند. در مقابل، لاگ سیستم‌عامل رویدادهایی مانند ورود کاربران، فعالیت سرویس‌ها، خطاهای سیستمی و بعضی تغییرات امنیتی را نمایش می‌دهد. این دو دسته اطلاعات مکمل یکدیگرند، اما هیچ‌کدام بهتنهایی تصویر کاملی از همه فعالیت‌های سرور ارائه نمی‌کنند.
فرض کنید مدیر سایت ادعا می‌کند شخصی از طریق اینترنت فایلی را حذف کرده است. مشاهده یک درخواست مشکوک در لاگ وب‌سرور ممکن است نقطه شروع بررسی باشد، ولی برای اثبات ارتباط آن درخواست با حذف فایل باید سوابق برنامه، مجوزهای کاربر و رویدادهای سیستم‌عامل نیز بررسی شوند. حتی ممکن است حذف توسط یک فرایند زمان‌بندی‌شده یا ابزار مدیریتی انجام شده باشد. تطبیق چند منبع مستقل، امکان ارزیابی فرضیه‌های جایگزین را فراهم می‌کند.
| نوع لاگ | اطلاعات اصلی | کاربرد در اختلاف حقوقی | محدودیت مهم |
|---|---|---|---|
| لاگ وب‌سرور | درخواست، IP، زمان و پاسخ HTTP | بررسی درخواست‌های مشکوک به سایت | هویت واقعی درخواست‌کننده را مشخص نمی‌کند |
| لاگ سیستم‌عامل | ورود کاربران و فعالیت سرویس‌ها | بررسی دسترسی مدیریتی و تغییرات سیستم | به سطح ثبت وقایع و تنظیمات وابسته است |
| لاگ فایروال | اتصالات مجاز یا مسدودشده | بازسازی الگوی ارتباطات شبکه | ممکن است محتوای فعالیت را نشان ندهد |
| لاگ برنامه | تراکنش‌ها و فعالیت حساب‌های کاربری | بررسی عملیات انجام‌شده در نرم‌افزار | ممکن است قابل تغییر توسط برنامه یا مدیر باشد |
| لاگ پایگاه داده | بخشی از تغییرات و عملیات داده‌ای | بررسی تغییر یا حذف اطلاعات | ثبت جزئیات وابسته به پیکربندی است |
آیا آدرس IP بهتنهایی هویت شخص را ثابت می‌کند؟
خیر؛ آدرس IP بهتنهایی برای شناسایی قطعی شخصی که پشت یک فعالیت اینترنتی قرار داشته کافی نیست. یک IP عمومی ممکن است میان چند کاربر شبکه سازمانی، مشترکان دارای NAT یا اعضای یک خانواده مشترک باشد. استفاده از VPN، پراکسی یا زیرساخت ابری نیز میتواند ارتباط میان IP مشاهده‌شده و موقعیت واقعی کاربر را پیچیده کند. حتی در مواردی که IP به یک اشتراک اینترنتی مشخص مربوط است، انتساب فعالیت به یک فرد نیازمند بررسی‌های تکمیلی خواهد بود.
در تحلیل فنی باید IP، زمان دقیق، پورت مبدأ در موارد لازم، اطلاعات تخصیص آدرس و سوابق احراز هویت کنار یکدیگر قرار بگیرند. در سامانه‌هایی که پشت CDN یا پراکسی معکوس هستند، IP ثبت‌شده ممکن است متعلق به واسطه باشد، نه کاربر نهایی. هدرهایی مانند X-Forwarded-For نیز بدون شناخت زنجیره پراکسی‌های مورد اعتماد، دلیل قطعی محسوب نمی‌شوند. نتیجه کارشناسی باید تفاوت میان شناسایی اتصال شبکه و شناسایی شخص حقیقی را آشکارا بیان کند.
چرا یکسان‌سازی ساعت سرورها در تحلیل حقوقی مهم است؟
زمان وقوع رویداد یکی از عناصر اساسی بازسازی حوادث امنیتی است و اختلاف ساعت میتواند ترتیب ظاهری وقایع را تغییر دهد. برای مثال، یک سرور ممکن است زمان را بر اساس UTC ثبت کند و سرور دیگری از منطقه زمانی محلی استفاده کند. اگر کارشناس بدون توجه به این تفاوت لاگها را کنار هم قرار دهد، ممکن است تصور کند یک عملیات قبل از ورود کاربر انجام شده است. چنین برداشتی میتواند بر تشخیص رابطه میان رویدادها تأثیر بگذارد.
استفاده صحیح از سرویس‌های همگامسازی زمان مانند NTP یا Chrony و ثبت وضعیت آن‌ها به کاهش این خطر کمک می‌کند. بااین‌حال، صرف فعال‌بودن همگامسازی تضمین نمی‌کند که ساعت در تمام لحظات گذشته دقیق بوده است. هنگام بررسی حادثه باید تغییر دستی ساعت، وضعیت همگامسازی، تأخیر ثبت وقایع و اختلاف ساعت احتمالی میان ماشین‌های مجازی نیز ارزیابی شود. بهتر است زمان‌ها برای مقایسه به یک مبنای مشترک مانند UTC تبدیل شوند و زمان اولیه ثبت‌شده بدون تغییر محفوظ بماند.
چگونه یکپارچگی فایل لاگ را با هش بررسی کنیم؟
هش رمزنگاری‌شده، خروجی محاسباتی مشخصی است که از محتوای یک فایل به دست می‌آید و میتواند برای تشخیص تغییر آن استفاده شود. الگوریتم SHA-256 یکی از گزینه‌های متداول برای بررسی یکپارچگی فایل‌های شواهد دیجیتال است. اگر هش یک فایل هنگام استخراج ثبت شود و مقدار محاسبه‌شده از همان فایل در بررسی بعدی یکسان باشد، این نتیجه از تغییرنکردن محتوای فایل میان دو مرحله پشتیبانی می‌کند. البته یکسان‌بودن هش بهخودیخود ثابت نمی‌کند که اطلاعات پیش از نخستین محاسبه صحیح بوده‌اند.
روش مناسب آن است که فایل اصلی با کمترین تغییر ممکن استخراج و بلافاصله هش آن در یک گزارش ثبت شود. سپس نسخه‌ای حفاظت‌شده ایجاد شود و تحلیل‌ها روی نسخه کاری انجام بگیرند. نام فایل، اندازه، زمان برداشت، ابزار مورد استفاده، شناسه سیستم و هویت شخص استخراج‌کننده نیز باید مستند شوند. اگر فایل بعداً منتقل شود، مقایسه هش در مبدأ و مقصد به تشخیص تغییرات احتمالی هنگام انتقال کمک می‌کند.
زنجیره حفاظت از شواهد الکترونیکی
زنجیره حفاظت یا Chain of Custody به مستندسازی مسیر در اختیار گرفتن، انتقال، نگهداری و بررسی شواهد اشاره دارد. در این فرایند باید مشخص باشد چه کسی در چه زمانی به فایل دسترسی داشته و چه عملیاتی انجام داده است. ثبت هش یکی از کنترل‌های فنی این زنجیره است، اما جایگزین ثبت تحویل‌گیرندگان، کنترل دسترسی یا حفاظت فیزیکی و منطقی نمیشود. در محیط‌های حساس، نگهداری نسخه اصلی به‌صورت فقط‌خواندنی و ثبت رویدادهای دسترسی اهمیت ویژه دارد.
چه عواملی ممکن است باعث حذف یا تغییر لاگها شوند؟
تغییر لاگ همیشه نتیجه اقدام عمدی یا مخرب نیست. سیاست چرخش لاگ یا Log Rotation ممکن است فایل‌های قدیمی را فشرده، جابه‌جا یا طبق برنامه حذف کند. محدودیت فضای دیسک، خطای سرویس ثبت وقایع، تغییر پیکربندی، بازسازی کانتینر یا پایان دوره نگهداری نیز ممکن است باعث از دست رفتن داده‌ها شود. در نتیجه، مشاهده یک فاصله زمانی بدون رویداد باید همراه با وضعیت سرویس‌ها و سیاست‌های نگهداری تفسیر شود.
در سوی دیگر، کاربری که دسترسی مدیریتی کافی دارد ممکن است بتواند فایل لاگ را ویرایش یا حذف کند. مهاجم دارای دسترسی سطح بالا نیز ممکن است آثار فعالیت خود را تغییر دهد، هرچند وقوع چنین اقدامی باید با شواهد مستقل بررسی شود. ارسال رویدادها به سامانه ثبت مرکزی با کنترل دسترسی مجزا و ذخیره‌سازی مقاوم در برابر تغییر میتواند خطر دستکاری را کاهش دهد. نگهداری رویدادها فقط روی همان سیستمی که موضوع نفوذ احتمالی است، معمولاً اتکاپذیری کمتری دارد.
اشتباهات رایج هنگام حفظ لاگ
- بازکردن و ذخیره دوباره فایل اصلی با ویرایشگر متن، بدون حفظ نسخه اولیه
- اتکا به اسکرین‌شات به‌جای فایل کامل و اطلاعات زمینه‌ای آن
- نادیده‌گرفتن منطقه زمانی و اختلاف ساعت میان سرویس‌ها
- حذف دوره‌ای لاگها پس از اطلاع از اختلاف، بدون بررسی ضرورت حفاظت
- محاسبه هش فقط پس از چند مرحله انتقال و ویرایش فایل
- ثبت‌نکردن نام افراد دارای دسترسی مدیریتی به شواهد
نسخه پشتیبان لاگ چه زمانی ارزش اثباتی دارد؟
نسخه پشتیبان زمانی برای بررسی حقوقی مفیدتر است که زمان تهیه، منشأ اطلاعات و روش حفاظت از آن روشن باشد. بکاپی که پیش از شروع اختلاف و به‌صورت منظم ایجاد شده، ممکن است امکان مقایسه اطلاعات گذشته و وضعیت فعلی را فراهم کند. اگر نسخه پشتیبان در محیطی مستقل و با دسترسی محدود نگهداری شده باشد، احتمال تغییر هم‌زمان آن با فایل اصلی کمتر خواهد بود. بااین‌حال، هیچ بکاپی صرفاً به دلیل قدیمی‌بودن یا خودکاربودن، معتبر و غیرقابل خدشه محسوب نمیشود.
در فرایند بازیابی باید مشخص شود بکاپ از چه منبعی تهیه شده، آیا کامل است و چه روشی برای کنترل یکپارچگی آن وجود دارد. گاهی نسخه پشتیبان در نتیجه پیکربندی اشتباه، تمام رویدادهای مورد نیاز را در بر نمی‌گیرد. همچنین ممکن است اطلاعات پیش از تهیه بکاپ دچار تغییر شده باشند. بنابراین مقایسه نسخه‌های مختلف، بررسی گزارش اجرای عملیات پشتیبان‌گیری و ثبت هش فایل بازیابی‌شده به ارزیابی دقیق‌تر کمک می‌کند.
آیا گزارش استخراج لاگ توسط مدیر سرور کافی است؟
گزارش مدیر سرور میتواند یک سند فنی مهم برای آغاز رسیدگی باشد، اما لزوماً برای اثبات نهایی ادعا کفایت نمی‌کند. مدیر سرور معمولاً با ساختار سامانه، محل ذخیره لاگها و نحوه استخراج اطلاعات آشناست. بااین‌حال، اگر خود او یا شرکت متبوعش یکی از طرفین اختلاف باشد، استقلال گزارش ممکن است محل پرسش قرار گیرد. دادگاه میتواند با توجه به موضوع پرونده، ضرورت بررسی مستقل یا ارجاع موضوع به کارشناس را ارزیابی کند.
گزارش مناسب باید روش استخراج، بازه زمانی، فایل‌های بررسی‌شده، ابزارهای استفاده‌شده و محدودیت‌های اطلاعات را توضیح دهد. بهتر است میان داده خام، مشاهدات فنی و برداشت کارشناسی تفکیک روشنی وجود داشته باشد. برای مثال، عبارت «درخواست از یک IP ثبت شده است» با ادعای «مالک این IP مرتکب نفوذ شده است» از نظر میزان قطعیت یکسان نیست. ضمیمه‌کردن شواهد قابل بازبینی و حفظ نسخه اصلی، امکان ارزیابی مستقل گزارش را افزایش می‌دهد.
مبنای قانونی اعتبار داده‌های الکترونیکی
قانون تجارت الکترونیکی ایران، مصوب ۱۳۸۲، مبنای مهمی برای بررسی ارزش اثباتی داده‌پیام‌ها فراهم می‌کند. در ماده ۱۲ این قانون آمده است: «ارزش اثباتی «داده پيام» را صرفاً به دليل شكل و قالب آن رد كرد». این عبارت بخشی از حکم ماده ۱۲ است که رد ارزش اثباتی داده‌پیام را صرفاً به دلیل قالب الکترونیکی آن منع می‌کند. متن کامل ماده در سامانه ملی قوانین و مقررات؛ قانون تجارت الکترونیکی قابل بررسی است.
ماده ۱۳ همین قانون نیز مقرر می‌کند: «ارزش اثباتي «داده پيام» ها با توجه به عوامل مطمئنه». این عبارت بخشی از ماده‌ای است که تناسب روش‌های ایمنی به‌کاررفته را از عوامل ارزیابی ارزش اثباتی می‌داند. در نتیجه، نباید از پذیرش اصولی ادله الکترونیکی نتیجه گرفت که هر فایل لاگ بدون بررسی اصالت، کامل‌بودن و شرایط تولید، ارزش اثباتی یکسانی دارد. همچنین احراز شرایط سابقه الکترونیکی مطمئن موضوع مواد ۱۱ و ۱۴ نیازمند بررسی مستقل است و صرف محاسبه هش چنین عنوانی ایجاد نمی‌کند.
کارشناس رسمی فناوری اطلاعات چگونه داده‌های ثبت‌شده را ارزیابی می‌کند؟
کارشناس رسمی دارای صلاحیت مرتبط، معمولاً بررسی را از تعیین پرسش کارشناسی و شناسایی منابع داده آغاز می‌کند. او باید مشخص کند لاگها از چه سامانه‌هایی استخراج شده‌اند، آیا نسخه اصلی در دسترس است و چه اشخاصی به آن‌ها دسترسی داشته‌اند. سپس ساختار رویدادها، زمان‌بندی، ارتباط میان رکوردها و احتمال نقص یا تغییر اطلاعات بررسی می‌شود. دامنه این فعالیتها به موضوع ارجاع، داده‌های موجود و حدود مأموریت کارشناسی وابسته است.
برای مثال، در اختلاف میان مشتری و شرکت هاستینگ درباره حذف پایگاه داده، کارشناس ممکن است سوابق پنل مدیریت، ورود SSH، زمان اجرای وظایف خودکار و رویدادهای بکاپ را تطبیق دهد. اگر چند فرضیه فنی با شواهد سازگار باشند، گزارش باید این عدم قطعیت را توضیح دهد. کارشناس نباید صرف مشاهده یک رویداد مشکوک، مسئولیت حقوقی یا وقوع جرم را قطعی فرض کند. تشخیص نهایی آثار حقوقی شواهد و تصمیم قضایی در صلاحیت مرجع رسیدگی‌کننده است.
تفاوت نظر فنی و نتیجه حقوقی
گزارش فنی ممکن است وقوع یک اتصال، تغییر فایل یا استفاده از حساب کاربری را با درجات مختلف اطمینان تأیید کند. اما اینکه فعالیت مزبور مجاز بوده، تعهد قراردادی نقض شده یا رفتار واجد وصف کیفری است، به بررسی سایر ادله و قواعد حقوقی وابسته خواهد بود. بنابراین گزارش کارشناسی باید از نظر قابلیت تکرار روش، شفافیت فرضیات و امکان بررسی مستقل ارزیابی شود. نظر کارشناس یکی از عناصر رسیدگی است و بهخودیخود جایگزین تصمیم دادگاه نمیشود.
در صورت برداشت اشتباه کارشناس از لاگ سرور چگونه می‌توان اعتراض کرد؟
اگر کارشناس زمان رویدادها را اشتباه تبدیل کرده، IP پراکسی را به کاربر نهایی نسبت داده یا میان درخواست ناموفق و ورود موفق تفاوتی نگذاشته باشد، این موارد می‌توانند مبنای ایراد فنی به نظریه باشند. اعتراض مؤثر باید دقیقاً نشان دهد کدام بخش گزارش با داده خام، تنظیمات ثبت وقایع یا اصول فنی ناسازگار است. بیان کلی اینکه نظریه اشتباه است معمولاً به‌اندازه ارائه مستندات قابل بررسی سودمند نیست. در صورت لزوم می‌توان درخواست توضیح، تکمیل بررسی یا ارجاع موضوع به کارشناسی دیگر را با توجه به مقررات و تصمیم مرجع رسیدگی مطرح کرد.
مسیر اعتراض و مهلت‌های قانونی به نوع پرونده و مرحله رسیدگی بستگی دارد. برای آشنایی با مراحل حقوقی و نقش وکیل در این فرایند، مطالعه راهنمای وکیل اعتراض به نظریه کارشناسی در مشهد میتواند مفید باشد. در پرونده مشخص بهتر است پیش از پایان مهلت قانونی، مستندات فنی و نظریه موجود با یک وکیل پایه یک دادگستری بررسی شوند. همکاری وکیل با متخصص مستقل امنیت و زیرساخت میتواند به تنظیم ایرادهای روشن و قابل ارزیابی کمک کند.
مدارک مناسب برای اعتراض فنی
- نسخه کامل نظریه کارشناسی و بخش‌هایی که محل اختلاف هستند.
- فایل‌های لاگ اولیه و نسخه‌های حفاظت‌شده همراه با هش ثبت‌شده.
- تنظیمات ساعت، منطقه زمانی و سوابق همگامسازی سرورها.
- مستندات معماری شبکه، CDN، پراکسی و نحوه ثبت IP واقعی.
- گزارش‌های مستقل فنی درباره خطاهای احتمالی تحلیل.
- مدارک مربوط به زمان استخراج، انتقال و دسترسی به شواهد.
جمع‌بندی
اعتبار لاگ سرور در دادگاه نه به حجم اطلاعات ثبت‌شده، بلکه به کیفیت تولید، حفاظت و تفسیر آن وابسته است. لاگ معتبرتر از نظر فنی، لاگی است که منشأ مشخص، زمان‌بندی قابل بررسی، زنجیره حفاظت مستند و امکان کنترل یکپارچگی داشته باشد. استفاده از هش SHA-256، نگهداری مستقل نسخه اصلی، همگامسازی زمان و مقایسه چند منبع رویداد میتواند اتکاپذیری شواهد را تقویت کند. بااین‌حال، هیچ‌یک از این اقدامات بهتنهایی تضمین‌کننده پذیرش یا نتیجه قضایی خاص نیست.
برای مدیران هاستینگ و صاحبان سایت، بهترین رویکرد آن است که پیش از بروز اختلاف، سیاست ثبت و نگهداری امن لاگها طراحی شود. پس از وقوع حادثه نیز باید از اقدامات غیرضروری روی داده اصلی خودداری کرد و فرایند استخراج را مستند ساخت. در اختلافات جدی، ترکیب بررسی فنی مستقل و مشاوره حقوقی متناسب با پرونده، احتمال ارائه تصویری دقیق‌تر از رویدادها را افزایش می‌دهد. این مطلب جنبه آموزشی دارد و جایگزین مشاوره تخصصی حقوقی یا کارشناسی رسمی برای پرونده معین نیست.
پرسش‌های متداول
آیا لاگ سرور بهتنهایی برای اثبات هک کافی است؟
معمولاً خیر؛ لاگ ممکن است نشانههایی از تلاش برای نفوذ یا فعالیت غیرعادی نشان دهد، اما اثبات دسترسی غیرمجاز و انتساب آن به شخص مشخص به شواهد تکمیلی نیاز دارد. سوابق احراز هویت، تغییر فایلها، تنظیمات امنیتی و سایر قرائن باید متناسب با موضوع پرونده بررسی شوند.
آیا لاگها پس از انتقال به سرور دیگر همچنان قابل استناد هستند؟
انتقال فایل بهخودیخود باعث از بین رفتن قابلیت استناد نمیشود، مشروط بر اینکه منشأ، یکپارچگی و فرایند انتقال قابل بررسی باشند. ثبت هش پیش و پس از انتقال، نگهداری نسخه اصلی و مستندسازی افراد دارای دسترسی میتواند به ارزیابی اصالت کمک کند. تصمیم نهایی درباره ارزش اثباتی با مرجع رسیدگی است.
آیا مدیر سایت میتواند فایل لاگ را بدون محدودیت نگهداری کند؟
خیر؛ نگهداری لاگ باید با تعهدات قراردادی، مقررات مرتبط، ضرورت امنیتی و حقوق اشخاص سازگار باشد. برخی لاگها حاوی آدرس IP، شناسه کاربری یا اطلاعات حساس هستند و نگهداری نامحدود یا دسترسی غیرضروری به آن‌ها میتواند خطرات حقوقی و امنیتی ایجاد کند. مدت نگهداری باید با توجه به الزامات قانونی قابل اعمال و هدف مشخص تعیین شود.
آیا اختلاف ساعت سرور ممکن است نتیجه کارشناسی را تغییر دهد؟
بله؛ اختلاف ساعت میتواند ترتیب ظاهری فعالیتها و ارتباط زمانی میان رویدادها را تغییر دهد. کارشناس باید منطقه زمانی، اختلاف احتمالی ساعت و وضعیت همگامسازی سیستمها را بررسی کند. اصلاح ترتیب زمانی بدون حفظ داده اولیه نیز میتواند قابلیت بازبینی نتیجه را کاهش دهد.
