سؤالی که جست‌وجوی اسلک نمی‌تواند جوابش را بدهد

نقش یک کاربر بی‌صدا از ADMIN به USER تغییر می‌کند. هیچ‌کس یادش نیست تأییدش کرده باشد. جاهای واضح برای نگاه‌کردن — اسلک، ایمیل، حافظه — همه به یک شکل شکست می‌خورند: نیت را ثبت می‌کنند، نه اقدام را، و فقط وقتی که کسی به فکرش رسیده باشد بنویسدش. آنچه واقعاً لازم دارید یک رکورد است که خودِ سیستم نگه می‌دارد، مستقل از اینکه کسی یادش بماند مستندش کند.

چه‌چیزی ثبت می‌شود، و چه‌چیزی نه

لاگ ممیزی وی‌کی‌اف‌گو فقط-افزایشی است — ردیف‌ها فقط اضافه می‌شوند، هرگز به‌روزرسانی یا حذف نمی‌شوند، پس یک حساب ادمین به‌خطرافتاده نمی‌تواند رد پایش را با ویرایش تاریخچه پاک کند. مشخصاً اقدام‌های مرتبط با حاکمیت را ردیابی می‌کند، نه هر کلیک در اپ:

const (
    ActionLoginSuccess   = "auth.login.success"
    ActionLoginFailure   = "auth.login.failure"
    ActionLogin2FAPrompt = "auth.login.2fa_required"
    Action2FAEnabled     = "auth.2fa.enabled"
    Action2FADisabled    = "auth.2fa.disabled"
    ActionUserCreated    = "user.created"
    ActionUserDeleted    = "user.deleted"
    ActionUserRoleChange = "user.role_changed"
    ActionPermissionSet  = "permission.changed"
    ActionProjectDeleted = "project.deleted"
    ActionTaskDeleted    = "task.deleted"
    ActionPlanChanged    = "plan.changed"
)

این یک مرز عمدی است. لاگی از هر ویرایش تسک و کامنت نویزی است که کسی نمی‌خواندش — رکوردهایی که برای حاکمیت اهمیت دارند آن‌هایی‌اند که پیامد امنیتی یا مالی دارند: کی از کجا وارد شد، کی 2FA را خاموش کرد، کی یک نقش را عوض کرد، کی یک پروژه را حذف کرد. هر رکورد شامل عامل، اقدام، هدف، یک بلوک متادیتای JSON برای جزئیات مخصوص اقدام، آی‌پی مبدأ و یک برچسب زمانی است — کافی برای بازسازیِ دقیقِ اتفاق بدون حدس‌زدن.

محدود به سازمان شما، نه کل پلتفرم

type AuditLog struct {
    OrganizationID *uint
    ActorID        *uint
    Action         string
    TargetType     string
    TargetID       string
    Metadata       datatypes.JSON
    IP             string
    CreatedAt      time.Time
}

یک ادمین سازمان که لاگ را کوئری می‌زند فقط ردیف‌های سازمان خودش را می‌بیند — همان مرز تننت که همه‌جای دیگر وی‌کی‌اف‌گو اجرا می‌شود، اینجا هم اجرا می‌شود. یک سوپرادمین پلتفرم می‌تواند برای بررسی بین‌تننتی یک نمای همه‌سازمان‌ها را فعال کند، اما این یک مسیر کوئریِ جدا و صریحاً بالابرده‌شده است، نه پیش‌فرض.

خواندن لاگ: فیلترهایی که اهمیت دارند

کوئری محدودکردن بر اساس عامل، اقدام، نوع هدف و یک بازه‌ی تاریخ را پشتیبانی می‌کند — همان شکلی که واقعاً هنگام بررسیِ یک چیز خاص لازم دارید، نه پیمایشِ یک آبشار. «هر تغییر مجوز در ۳۰ روز اخیر را نشانم بده» و «هر کاری کاربر ۴۲ در سوم مارس انجام داد را نشانم بده» هر دو یک کوئریِ فیلترشده‌اند، نه پیمایش دستی هزاران ردیف.

اشتباهات رایج

رفتار با لاگ ممیزی به‌عنوان جایگزین هشدار بلادرنگ. به «چه اتفاقی افتاد» با اطمینان و بعد از واقعه جواب می‌دهد. وقتی چیزی اتفاق می‌افتد کسی را پیجر نمی‌زند — آن یک دغدغه‌ی جداست (اعلان‌های درون‌برنامه‌ای وی‌کی‌اف‌گو حالت «همین الان» را می‌پوشانند؛ لاگ ممیزی حالت «بعداً ثابتش کن» را).

انتظار اینکه هر اقدامی آنجا باشد. لاگ عمداً باریک است — ویرایش تسک و کامنت در آن نیست. اگر تاریخچه‌ی کامل ویرایش یک تسک خاص را لازم دارید، آن تاریخچه‌ی تسک است، رکوردی متفاوت و پرسروصداتر که به‌ازای هر تسک نگه داشته می‌شود، نه به‌ازای هر سازمان.

فرض‌کردن اینکه حذف یک کاربر رد پایش را پاک می‌کند. نمی‌کند — ActorID روی رکوردهای گذشته حتی بعد از رفتن عامل دست‌نخورده می‌ماند، چون کل هدف لاگ ممیزی این است که از خودِ چیزی که ممیزی می‌کند جان سالم به‌در ببرد.

سؤالات متداول

آیا یک عضو معمولی تیم می‌تواند لاگ ممیزی را ببیند؟ نه — یک نمای محدود به ادمین است (ADMIN/SUPER_ADMIN در سازمان)، همان سطحی که از اول می‌تواند نقش‌ها و مجوزها را عوض کند.

آیا ردیابی ورود ناموفق به جلوگیری از حمله‌ی brute-force کمک می‌کند؟ یک رکورد است، نه یک مسدودکننده — محدودسازی نرخ چیزی است که واقعاً یک تلاش brute-force را کند می‌کند؛ لاگ ممیزی جایی است که بعدش می‌روید تا ببینید کدام حساب هدف بوده و کِی.

آیا خودِ لاگ هرگز پاک‌سازی می‌شود؟ هیچ وظیفه‌ی نگه‌داری روی آن اجرا نمی‌شود — برخلاف پاک‌سازی سطل بازیافت یا فایل‌های بکاپ قدیمی، ردیف‌های ممیزی قرار است انباشته شوند، نه منقضی.

قدم بعدی