۴۲ دسته‌بندی عملیاتی برای تسریع بازرسی‌های امنیتی در پلتفرم NEXUS AI

تصور کنید ساعت ۲:۴۷ بامداد یک حادثه در محیط عملیاتی رخ می‌دهد؛ حالا به‌جای جست‌وجوی کورکورانه برای یافتن «چه چیزی خراب شد»، می‌توانید دقیقاً بپرسید «چه کسی چه چیزی را تغییر داد». این سطح از شفافیت محصول جدید NEXUS AI است که با پیاده‌سازی یک سامانه پاسخگویی و ثبت ۴۲ نوع رویداد مجزا در ۷ دسته‌بندی، گزارش‌های بازرسی (Audit Logs) را از ابزارهای سادهٔ عیب‌یابی به یک موتور سخت‌گیر برای انطباق با قوانین (Compliance Engine) تبدیل کرده است.

در فضای فعلی DevOps، تیم‌ها اغلب در زمینه گزارش‌های بازرسی سرمایه‌گذاری کمی می‌کنند و به‌جای آن، برای بازسازی حوادث امنیتی به گزارش‌های اپلیکیشن یا تاریخچه گیت (git history) تکیه می‌کنند. این فرآیند دستی معمولاً ساعت‌ها تلاش و زمان می‌برد. NEXUS AI با تغییر دیدگاه به گزارش‌های بازرسی — یعنی نگاه به آن‌ها به‌عنوان یک سامانه پاسخگویی به‌جای یک ابزار برنامه‌نویسی برای توسعه‌دهندگان — به تیم‌ها اجازه می‌دهد به سؤالات حیاتی امنیتی در عرض چند ثانیه پاسخ دهند. طبق راهنمای فنی منتشر شده در ۲۱ آوریل ۲۰۲۶، این پلتفرم تضمین می‌کند که هر تلاش برای احراز هویت، هر عملیات مربوط به اسرار (Secret operation) و هر تغییر در مجوزها، به‌صورت غیرقابل تغییر و ماندگار ثبت شود. این رویکرد یادآور معماری ثبت سوابق غیرقابل‌تغییر در سامانه‌های ایمیلی است که برای تضمین صحت داده‌ها در عامل‌های هوش مصنوعی به کار می‌رود.

همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن اشاره کردیم، شفافیت در سطح دسترسی، اولین سد دفاعی در برابر نفوذ است.

پاسخگویی در برابر عیب‌یابی

گزارش‌های بازرسی برای عیب‌یابی نرم‌افزار (Debugging) طراحی نشده‌اند. در عوض، آن‌ها به‌عنوان یک سامانه پاسخگویی عمل می‌کنند که برای پاسخ به چهار سؤال مشخص طراحی شده است:

• آیا فرد مجاز این اقدام را انجام داده است؟
• آیا این اقدام از یک مکان شناخته‌شده صورت گرفته است؟
• آیا این عملیات در زمانی رخ داده که منطقی باشد؟
• آیا این اقدام روی منبعی انجام شده که کاربر مجاز به لمس آن بوده است؟

هر دقیقه‌ای که صرف بازسازی بستر حادثه از طریق تاریخچه گیت شود، در واقع دقیقه‌ای است که سامانه پاسخگویی نتوانسته است ارزش خود را ثابت کند. NEXUS AI به‌گونه‌ای طراحی شده است که این سؤالات را در عرض ثانیه‌ها حل کند، نه ساعت‌ها. در واقع، جایگزینی رویکرد امیدوارانه با مدیریت مستندمحور، راهکاری کلیدی برای کنترل رفتارهای غیرمنتظره عامل‌های هوش مصنوعی محسوب می‌شود.

کاتالوگ رویدادها و ماتریس شدت

این سامانه رویدادها را در ۷ دسته عملکردی سازماندهی کرده است تا نظارت بر آن‌ها تسهیل شود. این ساختار شامل ۴۲ نوع رویداد مجزا است:

• احراز هویت (Authentication): شامل LOGIN_SUCCESS (گذرواژه/OAuth)، LOGIN_FAILED (گذرواژه غلط/توکن نامعتبر)، LOGOUT (خروج)، REGISTER (حساب جدید)، TOKEN_REFRESH (به‌روزرسانی توکن) و TOKEN_EXPIRED (انقضای توکن). در اینجا، یک مورد LOGIN_FAILED نویز محسوب می‌شود؛ اما ۱۵ مورد از یک IP در ۹۰ ثانیه، یک سیگنال حمله Brute-force برای یکپارچگی با SIEM است.
• استقرار (Deployment): ردیابی کامل چرخه عمر شامل DEPLOYMENT_CREATED (ایجاد)، DEPLOYMENT_UPDATED (به‌روزرسانی)، DEPLOYMENT_STARTED (شروع)، DEPLOYMENT_STOPPED (توقف)، DEPLOYMENT_DELETED (حذف)، DEPLOYMENT_FAILED (شکست در Build یا شروع کانتینر) و DEPLOYMENT_SCALED (تغییر مقیاس). تمام این اقدامات به ایمیل کاربر، شناسه توکن یا هر دو متصل هستند.
• امنیت (Security): شامل رویدادهای پرریسک مانند DOCKERFILE_VALIDATION_FAILED (شکست در اعتبارسنجی داکر فایل)، RATE_LIMIT_EXCEEDED (عبور از حد مجاز درخواست)، UNAUTHORIZED_ACCESS (دسترسی غیرمجاز)، SUSPICIOUS_ACTIVITY (فعالیت مشکوک) و CONTAINER_ESCAPE_ATTEMPT (تلاش برای خروج از کانتینر). دو مورد آخر به عنوان CRITICAL (بحرانی) علامت‌گذاری شده و هشدار فوری می‌فرستند و هرگز به سطوح پایین‌تر تنزل نمی‌یابند.
• منابع (Resource): نظارت بر مسائل مربوط به ظرفیت مانند RESOURCE_LIMIT_EXCEEDED (CPU، حافظه یا فضای ذخیره‌سازی)، HIGH_CPU_USAGE (مصرف بالای سی‌پی‌یو) و HIGH_MEMORY_USAGE (مصرف بالای رم). این‌ها یک ردپای مستند برای حوادثی فراهم می‌کنند که در آن‌ها یک استقرار، مثلاً در یک بعدازظهر سه‌شنبه، به‌طور بی‌صدا توسط OOM-kill بسته شده است.
• مدیریتی (Administrative): ثبت USER_CREATED (ایجاد کاربر)، USER_DELETED (حذف کاربر)، PERMISSION_CHANGED (تغییر نقش‌ها/دامنه دسترسی) و CONFIG_CHANGED (تغییرات در سطح سازمان). رویدادهای PERMISSION_CHANGED به‌طور خاص حالت «قبل» و «بعد» را در فیلد JSON جزئیات ثبت می‌کنند.
• پروژه (Project): ردیابی تغییرات متاداتا و چرخه عمر از طریق PROJECT_CREATED (ایجاد)، PROJECT_UPDATED (به‌روزرسانی) و PROJECT_DELETED (که باعث حذف پروژه و تمام استقرارها می‌شود).
• اسرار و خزانه (Secret and Vault): نظارت بر SECRET_CREATED (ایجاد)، SECRET_UPDATED (به‌روزرسانی)، SECRET_ROTATED (چرخش)، SECRET_DELETED (حذف)، SECRET_REVEALED (نمایش مقدار - علامت‌گذاری شده به عنوان WARNING)، SECRET_LISTED (لیست کردن) و SECRET_RUNTIME_ACCESSED (رمزگشایی برای تزریق به کانتینر).

رویدادهای هوشمندی پایگاه‌داده به‌طور خاص موارد DATABASE_ACCESSED (دسترسی به دیتابیس)، DATABASE_QUERY_EXECUTED (اجرای کوئری) و DATABASE_MODIFIED (تغییر دیتابیس) را ردیابی می‌کنند. رویداد DATABASE_MODIFIED به سطح WARNING ارتقاء می‌یابد، زیرا تغییرات Schema و دستورات DDL تأثیر بالایی دارند و بازگرداندن آن‌ها دشوار است.

کالبدشناسی لاگ و ساختار داده‌ها

هر رکورد در جدول audit_logs یک ورودی واحد است که شامل فیلدهای مشخصی برای دقت جنایی (Forensic Precision) است. یک رکورد معمولی شامل موارد زیر است:

• شناسه و متاداتا: یک id یکتا برای ارجاع پایدار در تیکت‌های حادثه و یک timestamp (برچسب زمانی) بر اساس UTC با دقت میلی‌ثانیه.
• بسترe Actor (عامل): شامل userId (عامل انسانی)، organizationId (مرز مستاجر/Tenant)، ipAddress (حیاتی برای شناسایی ناهنجاری‌های جغرافیایی) و userAgent (برای تمایز بین نسخه‌های CLI، مرورگرها یا SDKها).
• داده‌های منبع: resourceId (استقرار، Secret یا کاربر خاص) و resourceType (دسته‌بندی منبع).
• جزئیات اقدام: eventType (خوانده شده توسط ماشین)، action (خوانده شده توسط انسان) و یک فیلد JSON به نام details برای بسترهای آزاد (مانند تگ‌های ایمیج، مناطق یا نقش‌های قدیمی/جدید).
• نتیجه: success (مقدار بولی) و errorMessage (در صورتی که success برابر با false باشد).

سطوح شدت و هشداردهی

NEXUS AI از چهار سطح شدت برای هدایت خط لوله ذخیره‌سازی، نمایش و هشداردهی استفاده می‌کند:

۱. INFO (اطلاعاتی): عملیات عادی. استقرار‌های موفق، ورودها و لیست کردن اسرار در این سطح قرار می‌گیرند. این‌ها در دیتابیس نوشته می‌شوند اما هشدار ایجاد نمی‌کنند و خط مبنای «وضعیت عادی» را تعیین می‌کنند.
۲. WARNING (هشدار): شرایطی که نیاز به بررسی دارند. این مورد شامل SECRET_REVEALED (درخواست ادمین برای نمایش مقدار)، شکست در ورودها، برخورد با Limitهای نرخ درخواست (Rate Limit) و شکست‌های اعتبارسنجی Dockerfile است. الگوهای حجمی (مثلاً ۵۰ شکست در ورود طی ۱۰ دقیقه) باید توسط SIEM شناسایی شوند.
۳. ERROR (خطا): شکست‌هایی که نیاز به توجه دارند، مانند DEPLOYMENT_FAILED. این موارد در جریان خطاهای اپلیکیشن و دیتابیس ثبت می‌شوند تا فوراً در خط لوله‌های مشاهده‌پذیری (Observability) ظاهر شوند.
۴. CRITICAL (بحرانی): اقدام فوری لازم است. تنها SUSPICIOUS_ACTIVITY و CONTAINER_ESCAPE_ATTEMPT به‌طور پیش‌فرض در این سطح هستند. این‌ها خط لوله هشداردهی (ایمیل، Slack و یکپارچگی با PagerDuty در نقشه راه) را فعال می‌کنند.

سیاست نگهداری (Retention Policy)

مدت نگهداری داده‌ها بر اساس طرح کاربر متفاوت است و توسط یک Job روزانه که ساعت ۳:۳۰ بامداد به وقت UTC اجرا می‌شود، مدیریت می‌گردد:

• Starter و Pro: بازه نگهداری ۹۰ روزه.
• Enterprise: قابل تنظیم از طریق متغیر محیطی AUDIT_LOG_RETENTION_DAYS. صنایع تحت نظارت اغلب این مقدار را روی ۳۶۵ (حداقل HIPAA) یا ۲۵۵۵ (الزام ۷ ساله سوابق مالی) تنظیم می‌کنند.
• Enterprise On-Prem: مشتری مالک دیتابیس است و سیاست‌های نگهداری و پشتیبان‌گیری خود را تعریف می‌کند.

نکته بسیار حیاتی این است که رویدادهای CRITICAL از تمام عملیات‌های پاک‌سازی مستثنی هستند و صرف‌نظر از نوع طرح، به‌طور نامحدود نگهداری می‌شوند.

امتیازدهی امنیتی و نظارت

پلتفرم یک امتیاز امنیتی ۱۰۰-نمره‌ای متحرک را برای هر سازمان محاسبه می‌کند که در یک بازه پیش‌فرض ۷ روزه بازنگری می‌شود. امتیاز از ۱۰۰ شروع شده و بر اساس ریسک کسر می‌شود:

• شکست در ورود (LOGIN_FAILED): ۲- نمره
• عبور از حد مجاز (RATE_LIMIT_EXCEEDED): ۱- نمره
• شکست در اعتبارسنجی داکر فایل (DOCKERFILE_VALIDATION_FAILED): ۵- نمره
• رویداد امنیتی بحرانی: ۱۰- نمره

امتیاز ۱۰۰ نشان‌دهنده نبود هیچ رویداد نامطلوب است. امتیاز ۶۰ نشان می‌دهد که بررسی لازم است و امتیاز زیر ۴۰ باید باعث شروع یک بازبینی امنیتی فعال شود. این امتیاز را می‌توان در داشبورد در مسیر Settings → Security یا از طریق GET /api/audit/security-summary مشاهده کرد. برای بهینه‌سازی این فرآیند، می‌توان از عامل‌های خودکار برای بازرسی ۱۰۰ درصدی لاگ‌ها استفاده کرد تا خطاهای انسانی در تحلیل داده‌ها به حداقل برسد.

یکپارچگی و دسترسی

یکپارچگی با ابزارهای SIEM مانند Datadog، Grafana Loki و Splunk از طریق یک Endpoint کوئری JSON یا API خروجی CSV مدیریت می‌شود. خروجی CSV تا ۱۰,۰۰۰ رکورد را پشتیبانی کرده و شامل تمام فیلدها استken، به طوری که فیلد JSON جزئیات به صورت رشته (String) سریالایز شده است.

کاربران می‌توانند از طریق مسیرهای زیر به لاگ‌ها دسترسی داشته باشند:

• داشبورد: Settings → Audit Logs (با قابلیت صفحه‌بندی، جست‌وجو و فیلتر).
• API: نقاط دسترسی مانند /api/audit/logs (با فیلترهای startDate ،endDate ،eventType و severity)، /api/audit/export و /api/audit/user-activity/:userId برای خلاصه‌های ۳۰ روزه فعالیت.

برای کاربران Enterprise On-Prem، لاگ‌ها در یک کلاستر PostgreSQL متعلق به مشتری قرار دارند که در حالت استراحت (At Rest) با AES-256 رمزنگاری شده است تا تضمین شود هیچ داده‌ای از زیرساخت داخلی خارج نمی‌شود.

نقشه‌برداری انطباق (Compliance Mapping)

این سامانه مستقیماً با شناسه‌های کنترل نظارتی خاص نقشه‌برداری شده است تا دقیقاً شواهدی را که بازرسان نیاز دارند، فراهم کند:

نقشه‌برداری HIPAA:

• شناسایی یکتای کاربر (§164.312(a)(2)(i)): توسط userId در هر رکورد و tokenId در جزئیات فراهم شده است.
• کنترل‌های بازرسی (§164.312(b)): با ۴۲ نوع رویداد و لاگ‌های Append-only با نگهداری ۹۰ تا ۳۶۵ روزه برآورده شده است.
  L* خروج خودکار (§164.312(a)(2)(iii)): از طریق رویدادهای TOKEN_EXPIRED ثبت می‌شود.
• رمزگذاری/رمزگشایی (§164.312(a)(2)(iv)): هر رمزگشایی از اسرار از طریق SECRET_RUNTIME_ACCESSED ردیابی می‌شود.
• احراز هویت شخص (§164.312(d)): از طریق رویدادهای LOGIN_FAILED قابل استخراج است.

نقشه‌برداری SOC 2 Type II:

• کنترل‌های دسترسی منطقی (CC6.1): رویدادهای PERMISSION_CHANGED ،USER_CREATED و USER_DELETED.
• مجوز دسترسی به سیستم (CC6.2): رویدادهای LOGIN_SUCCESS ،LOGIN_FAILED و UNAUTHORIZED_ACCESS.
• ثبت‌نام/لغو دسترسی کاربر (CC6.3): رویدادهای USER_CREATED ،USER_DELETED و PERMISSION_CHANGED.
• محدودیت داده‌ها در حال انتقال (CC6.7): رویدادهای SECRET_RUNTIME_ACCESSED و DATABASE_ACCESSED.
• نظارت بر اجزای سیستم (CC7.2): رویدادهای HIGH_CPU_USAGE ،HIGH_MEMORY_USAGE و RESOURCE_LIMIT_EXCEEDED.
• تشخیص و گزارش حادثه (CC7.3): رویدادهای SUSPICIOUS_ACTIVITY و CONTAINER_ESCAPE_ATTEMPT (هشدارهای CRITICAL).

نقشه‌برداری GDPR:

• سوابق فعالیت‌های پردازشی (Art. 30): لاگ‌های کامل رویداد با Brs زمان، عامل و نتیجه.
• پاسخگویی (Art. 5(2)): لاگ Append-only بدون قابلیت تغییر.
• درخواست‌های دسترسی به داده‌ها (Art. 15): توسط Endpoint مسیر /api/audit/user-activity/:userId پشتیبانی می‌شود.
• اعلام نقض داده‌ها (Art. 33): رویدادهای CRITICAL فوراً هشدار می‌دهند تا پنجره ۷۲ ساعته رعایت شود.

نقشه‌برداری PCI DSS v4.0:

• ردیابی دسترسی به داده‌های دارنده کارت (Req. 10.2): رویدادهای DATABASE_ACCESSED و DATABASE_QUERY_EXECUTED برای دیتابیس‌های پرداخت.
• ثبت دسترسی کاربر به مسیرهای بازرسی (Req. 10.2.1): تمام ۴۲ نوع رویداد، userId یا tokenId را ثبت می‌کنند.
• ثبت دسترسی‌های دارای امتیاز بالا (Req. 10.2.1.b): رویداد PERMISSION_CHANGED تمام ارتقاهای نقش را ثبت می‌کند.
• نگهداری تاریخچه ۱۲ ماهه (Req. 10.7): از طریق تنظیم AUDIT_LOG_RETENTION_DAYS=365 در طرح Enterprise قابل دستیابی است.
• بازبینی روزانه لاگ‌ها (Req. 10.6): از طریق /api/audit/logs و خروجی‌های SIEM تسهیل شده است.

مرزهای جنایی (Forensic Boundaries)

برای حفظ امنیت و جلوگیری از تورم لاگ‌ها، NEXUS AI مرزهای سخت‌گیرانه‌ای درباره آنچه ثبت نمی‌شود تعریف کرده است:

• مقادیر اسرار هرگز لاگ نمی‌شوند: رویداد SECRET_RUNTIME_ACCESSED ثبت می‌کند که سکرتی به نام DATABASE_URL دسترسی یافته است، اما مقدار Plaintext هرگز وارد لاگ بازرسی نمی‌شود.
• داده‌های سطح اپلیکیشن استثنا شده‌اند: NEXUS AI اقدامات پلتفرم را بازرسی می‌کند. اگر یک اپلیکیشن متغیرهای محیطی خود را هنگام شروع لاگ کند، این یک موضوع جداگانه است.
• عملیات‌های خواندنی روتین نادیده گرفته می‌شوند: مشاهده وضعیت یک استقرار در داشبورد رویدادی ایجاد نمی‌کند، زیرا این کار باعث تولید میلیون‌ها رویداد INFO کم‌ارزش می‌شود.
• لاگ‌های زمان اجرا جدا هستند: خروجی‌های stdout/stderr کانتینرها از طریق GET /api/deployments/:id/logs در دسترس هستند و در لایه مشاهده‌پذیری ذخیره می‌شوند، نه در لاگ بازرسی.

پاسخ به حادثه در عمل

سناریویی را تصور کنید که در آن یک استقرار عملیاتی در ساعت ۲۳:۴۲ به‌طور غیرمنتظره متوقف می‌شود. یک مهندس می‌تواند این موضوع را در عرض چند دقیقه حل کند:

۱. فیلتر کردن: کوئری رویدادهای DEPLOYMENT_STOPPED را می‌گیرد. نتیجه نشان می‌دهد userId: null است اما شامل یک tokenId (tok_01HX9...) و یک IP (198.51.100.22) است.
۲. تطبیق متقاطع: توکن به عنوان github-actions-prod شناسایی می‌شود. اگرچه این توکن محدوده deploy:write را دارد، اما Workflow مربوطه فقط بازاستقرارها را تحریک می‌کند، نه توقف‌ها را.
۳. تحلیل: بررسی فعالیت‌های اخیر آن توکن نشان می‌دهد IP 198.51.100.22 خارج از محدوده IPهای خط لوله CI/CD (140.82.114.0/24) است.

نتیجه: توکن لو رفته بود. مهندس توکن را باطل کرده و اسرار را در ۱۱ دقیقه می‌چرخاند. بدون لاگ‌های بازرسی، این کار نیاز به بازسازی دستی از لاگ‌های گیت‌هاب و ارائه‌دهنده کلاود داشت که بیش از ۹۰ دقیقه زمان می‌برد.

چک‌لیست بهداشت بازرسی (Audit Hygiene)

برای حفظ وضعیت امنیتی، تیم‌ها باید اقدامات بهداشتی زیر را اجرا کنند:

• بررسی هفتگی GET /api/audit/security-summary؛ در صورت افت امتیاز به زیر ۸۰، بررسی کنید.
• تنظیم AUDIT_LOG_RETENTION_DAYS=365 برای بارهای کاری HIPAA، مالی یا PCI.
• استخراج CSVهای ماهانه برای بایگانی انطباق قبل از بسته‌های سه ماهه.
• استخراج /api/audit/user-activity/:userId برای هر عضو تیم در هنگام خروج (Offboarding).
• فیلتر کردن PERMISSION_CHANGED در بازبینی‌های سه ماهه برای تأیید تغییرات نقش.
• تأیید اینکه هیچ رویداد SECRET_REVEALED در ۳۰ روز گذشته رخ نداده باشد، مگر با مجوز.
• راه‌اندازی خط لوله SIEM برای رویدادهای severity=WARNING اگر تیم بیش از ۱۰ مهندس دارد.
• در حالت On-Prem: تأیید اینکه برنامه‌های پشتیبان‌گیری PostgreSQL شامل جدول audit_logs باشد.

پرسش‌های متداول (FAQ)

آیا می‌توانم یک ورودی لاگ را حذف کنم؟ خیر. رکوردها فقط قابل افزودن (Append-only) هستند تا تغییرناپذیری تضمین شود. لاگ بازرسی‌ای که بتوان آن را ویرایش کرد، دیگر لاگ بازرسی نیست.

چه کسی به این لاگ‌ها دسترسی دارد؟ دسترسی نیاز به مجوز audit.read دارد که فقط به نقش‌های OWNER و ADMIN داده می‌شود. توسعه‌دهندگان به‌طور پیش‌فرض نمی‌توانند اقدامات سایر کاربران را بررسی کنند.

آیا عوامل هوش مصنوعی (AI Agents) ردیابی می‌شوند؟ بله. فراخوانی ابزارهای MCP (مانند عوامل Claude) رویدادهای بازرسی با شناسه توکن در details.tokenId و یک userAgent خاص که کلاینت MCP را شناسایی می‌کند، تولید می‌کنند.

در هنگام کاهش طرح (Downgrade) چه اتفاقی می‌افتد؟ لاگ‌ها فوراً حذف نمی‌شوند. اما اگر از Enterprise (۳۶۵ روزه) به Pro (۹۰ روزه) بروید، Job نگهداری در اجرای بعدی، رکوردهای قدیمی‌تر از ۹۰ روز را پاک خواهد کرد. کاربران باید قبل از کاهش طرح، رکوردها را استخراج کنند.

این تغییر به سمت بازرسی‌های دقیق و نقشه‌برداری شده با استانداردهای انطباق، شیوه مدیریت زیرساخت‌های هوش مصنوعی را تغییر می‌دهد. با گذشتن از لاگ‌های عمومی و حرکت به سمت یک سامانه پاسخگویی، سازمان‌ها «شکاف جنایی» (Forensic Gap) را در هنگام نفوذ کاهش داده و به‌طرز چشمگیری میانگین زمان رفع مشکل (MTTR) را پایین می‌آورند.