در محیط‌های SAP، مدیریت دستورات خارجی سیستم‌عامل (External OS Commands) از طریق تراکنش‌های SM49 و SM69 یکی از حیاتی‌ترین نقاط امنیتی است. با این حال، یک شکاف جدی بین «قابلیت حسابرسی» (Auditability) و «دید عملیاتی» (Visibility) وجود دارد که می‌تواند منجر به اجرای دستورات مخرب بدون ثبت هیچ ردی در لاگ‌های امنیتی شود.
مکانیسم اجرای دستورات در SAP
وقتی یک دستور خارجی اجرا می‌شود، فرآیند SAP درخواست را به یک Helper به نام sapxpg می‌سپارد و این ابزار، دستور را با دسترسی کاربر sidadm (کاربری که مالک نصب SAP است) اجرا می‌کند. زنجیره اجرای فرآیند در سطح سیستم‌عامل همواره به صورت زیر است:
SAP work process → sapxpg → Binary
چالش اصلی: تفاوت تعریف دستور و پارامترهای زمان اجرا
بسیاری از تیم‌های امنیتی تنها به بازبینی لیست دستورات در SM69 اکتفا می‌کنند. اما خطر اصلی در Runtime Parameters نهفته است. یک مهاجم می‌تواند دستوری کاملاً عادی (مانند find) را تعریف کند، اما در زمان اجرا از قابلیت‌هایی مثل -exec برای اجرای دستورات دیگر (مانند /usr/bin/id) استفاده کند. در این حالت، دستور واقعی اجرا شده هرگز در تعریف SM69 ثبت نمی‌شود و تنها در رشته پارامترهای زمان اجرا قرار دارد.
تحلیل مسیرهای مختلف اجرا و وضعیت لاگ‌ها
- مسیر تعاملی (Dialog Path): در این حالت، Security Audit Log (SAL) هیچ ردی از دستور، باینری یا پارامترها ثبت نمی‌کند و تنها یک پیام کلی مبنی بر «شروع تراکنش SM49» ثبت می‌شود.
- مسیر RFC: هنگام فراخوانی دستورات از طریق RFC، لاگ‌ها تنها عملیات Logon یا نام تابع (مانند
SXPG_COMMAND_EXECUTE) را ثبت می‌کنند، اما جزئیات دستور اجرا شده کاملاً حذف شده است. - مسیر پس‌زمینه (Background Path): تنها در این مسیر، دستورات و پارامترها در Job Log (جداول TBTC*) به صورت متن آزاد ثبت می‌شوند، اما باز هم این اطلاعات در Security Audit Log قرار نمی‌گیرند.
راهکار نهایی: تکیه بر OS-level Auditing
تنها منبعی که در تمامی مسیرها (Dialog, RFC, Background) قادر به ثبت کامل دستورات و آرگومان‌ها است، auditd در سطح سیستم‌عامل است. با این حال، سه مانع رایج وجود دارد:
۱. غیرفعال بودن: در برخی توزیع‌های SUSE، سیاست task,never باعث سرکوب رکوردهای execve می‌شود.
۲. عدم پایداری: تغییرات زمان اجرا با auditctl پس از ریبوت پاک می‌شوند و باید در rules.d ثبت گردند.
۳. نویز زیاد: ثبت تمامی فرآیندها باعث ایجاد حجم زیادی از لاگ می‌شود. راهکار بهینه، فیلتر کردن بر اساس Parent Process یعنی sapxpg است.
توصیه‌های عملیاتی برای مدیران SOC و مهندسین امنیت
- اصلاح سیاست‌های Audit: حذف
task,neverو تعریف قوانین پایدار برایexecveدر سطح OS. - استفاده از ابزارهای مدرن: به جای درگیری با لاگ‌های خام auditd، از Sysmon for Linux، EDR یا ابزارهای eBPF (مانند Falco) برای شناسایی فرآیندهای فرزند sapxpg استفاده کنید.
- کنترل دسترسی‌های سخت‌گیرانه: محدود کردن دسترسی به اشیاء
S_LOG_COM،S_RZL_ADMو همچنینS_RFCبرای مسیرهای RFC. - همبسته‌سازی (Correlation): برای شناسایی کاربر SAP که دستور را اجرا کرده، باید Timestamp لاگ SAL را با رکورد
execveدر auditd تطبیق دهید.
