تفاوت لاگ سامانه با سیاههٔ ممیزی چیست؟
لاگ سامانه برای تشخیص خطا نوشته میشود و مخاطبش مهندس است. سیاههٔ ممیزی برای پاسخ به پرسش «چه کسی، چه زمانی، به چه چیزی دسترسی داشت و چه تغییری داد» نوشته میشود و مخاطبش بازرس است. این دو نه یک قالب دارند و نه یک دورهٔ نگهداشت.
تفاوت عملی مهم این است که لاگ میتواند ناقص باشد بدون آنکه بیارزش شود؛ سیاههٔ ممیزی نمیتواند. اگر نود درصد دسترسیها ثبت شده باشند، بازرس نمیتواند دربارهٔ آن ده درصد چیزی بگوید و بنابراین نمیتواند دربارهٔ کل هم چیزی بگوید. جامعیت، شرط استفاده است نه معیار کیفیت.
به همین دلیل سیاهه باید در همان مسیری تولید شود که خود عمل انجام میشود، نه در مسیری موازی که ممکن است دور زده شود. هر مسیر دسترسی که سیاهه تولید نکند، یک استثنا در گزارش نهایی است.
چرا افزودن بعدی سیاهه معمولاً شکست میخورد؟
به سه دلیل ساختاری. اول، رویدادهای گذشته وجود ندارند. سازمانی که پس از یک سال استفاده تصمیم میگیرد سیاهه داشته باشد، آن یک سال را برای همیشه از دست داده است — و اغلب دقیقاً همان دورهای است که موضوع ممیزی میشود.
دوم، مسیرهای دسترسی در طول زمان زیاد میشوند: رابط کاربری، رابط برنامهنویسی، خروجی گرفتن، اشتراکگذاری پیوند، همگامسازی با سامانهٔ دیگر. افزودن بعدی سیاهه یعنی پیدا کردن و ابزارگذاری همهٔ این مسیرها، و همیشه یکی از قلم میافتد.
سوم، هویت. سیاههای که بهجای فرد، حساب سرویس را ثبت میکند بیفایده است؛ و انتقال هویت کاربر تا لایههای پایین سامانه، تصمیمی معماری است که در طراحی اولیه یا گرفته شده یا نشده. اصلاحش بعداً بهمعنای بازنویسی مسیر داده است.
یک سیاههٔ قابل استفاده چه چیزهایی را ثبت میکند؟
پنج فیلد، در هر رویداد: هویت واقعی فرد، زمان با منطقهٔ زمانی صریح، عملی که انجام شد، شیئی که عمل روی آن انجام شد، و نتیجه — یعنی اینکه عمل موفق بود یا رد شد. رویدادهای رد شده اغلب از رویدادهای موفق مهمترند؛ الگوی تلاشهای ناموفق برای دسترسی، چیزی است که ممیزی به دنبال آن میگردد.
برای یک سامانهٔ دانش سازمانی، دو رویداد بیشتر از بقیه اهمیت دارند: مشاهدهٔ یک سند یا رونوشت، و پرسشی که از دستیار پرسیده شده همراه با اسنادی که در پاسخ استفاده شدهاند. دومی تازه است و در بیشتر سامانهها ثبت نمیشود، در حالی که دقیقاً همان جایی است که پاسخ نادرست باید پس از وقوع بررسی شود.
و یک رویداد که فراموش میشود: دسترسی به خود سیاهه. اگر دیدن سیاهه ثبت نشود، سیاهه یک نقطهٔ کور دارد که بزرگترین اختیار سامانه در آن قرار گرفته است.
یکپارچگی و نگهداشت سیاهه چه الزاماتی دارند؟
سیاهه باید فقطافزودنی باشد: کسی که میتواند رکورد را حذف یا ویرایش کند، میتواند اثر عمل خود را پاک کند و آنگاه سیاهه چیزی را اثبات نمیکند. جداسازی اختیارات — یعنی اینکه مدیر سامانه مالک سیاهه نباشد — کنترل مکملی است که در ممیزیهای جدی خواسته میشود.
دورهٔ نگهداشت باید بر مبنای الزام تعیین شود و نه بر مبنای هزینهٔ ذخیرهسازی، و باید صریح و مکتوب باشد. سیاههای که دورهٔ نگهداشتش تعریف نشده، در عمل تا اولین بحران فضای دیسک نگهداری میشود.
و باید قابل استخراج باشد. سیاههای که فقط در رابط کاربری قابل مشاهده است، در یک ممیزی سهماهه با چند هزار رویداد عملاً غیرقابل استفاده است؛ خروجی ساختیافته یک الزام است، نه یک تسهیل.
از تأمینکننده چه باید پرسید؟
شش پرسش مشخص: کدام رویدادها ثبت میشوند و کدام نمیشوند؛ آیا هر مسیر دسترسی سیاهه تولید میکند یا فقط رابط کاربری؛ هویت ثبتشده فرد است یا حساب سرویس؛ آیا سیاهه فقطافزودنی است و چه کسی میتواند آن را بخواند؛ دورهٔ نگهداشت چقدر است؛ و خروجی در چه قالبی گرفته میشود.
پاسخها را بهصورت نمونهٔ واقعی بخواهید، نه بهصورت توضیح. یک فایل خروجی از یک روز کاری واقعی، بیش از هر مستندی نشان میدهد که سیاهه در عمل چه چیزی را ثبت میکند.
در داناوی هر مشاهده، هر تغییر دسترسی و هر پرسش از دانا همراه با منابعی که در پاسخ استفاده شدهاند در سیاههٔ ممیزی ثبت میشود — اما این پرسشها را باید از هر تأمینکنندهای پرسید و پاسخ را در قرارداد نوشت، چون آنچه در مستند بازاریابی «ممیزیپذیر» خوانده میشود دامنهٔ بسیار متفاوتی دارد.
