کامپلاینس چیست؟ راهنمای جامع انطباق امنیتی با استانداردها

کامپلاینس (Compliance) یا انطباق امنیتی یعنی سازمان بتواند نشان دهد سیستم‌ها، فرایندها و کنترل‌های امنیتی‌اش با الزامات یک استاندارد، قانون یا مقررات بخشی مطابقت دارد؛ مثلاً ISO 27001 برای مدیریت امنیت اطلاعات، PCI DSS برای داده کارت‌های پرداخت یا الزامات افتا برای زیرساخت‌های حیاتی. کلمه کلیدی در این تعریف «نشان دادن» است: انطباق با استانداردهای امنیتی فقط اجرای کنترل نیست، بلکه اثبات مستند و قابل ممیزی آن هم هست.

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

کامپلاینس چیست و چه تفاوتی با امنیت دارد؟

امنیت (Security) یعنی کاهش واقعی ریسک: بستن سرویس‌های غیرضروری، نصب وصله‌ها، محدود کردن دسترسی‌ها و تشخیص به‌موقع حمله. کامپلاینس یعنی تطبیق همین اقدامات با یک مجموعه الزام مشخص و ارائه شواهد آن به ممیز. این دو هم‌پوشانی زیادی دارند، اما یکی نیستند:

• سازمان منطبق اما ناامن: همه سیاست‌ها و مستندات کامل است، اما سروری که بعد از ممیزی به شبکه اضافه شده، بدون هاردنینگ و با یک آسیب‌پذیری بحرانی در حال کار است.
• سازمان امن اما نامنطبق: تیم فنی کار درستی انجام می‌دهد، اما هیچ گزارش، سابقه یا مستندی برای اثبات آن وجود ندارد و در ممیزی یافته (Finding) ثبت می‌شود.
• حالت مطلوب: کنترل‌های فنی واقعاً اجرا می‌شوند و ابزارها به‌صورت خودکار شواهد قابل ارائه تولید می‌کنند.

معیار	امنیت	کامپلاینس
هدف	کاهش ریسک واقعی	اثبات تطابق با الزامات
محرک	تهدیدها و ارزش دارایی‌ها	استاندارد، قانون یا قرارداد
معیار سنجش	آسیب‌پذیری‌های باز، رخدادها	یافته‌های ممیزی، کامل بودن شواهد
بازه زمانی	پیوسته	معمولاً دوره‌ای

قاعده ساده این است: امنیت را برای کاهش ریسک بسازید و کامپلاینس را محصول جانبی آن کنید، نه برعکس.

چارچوب‌ها و استانداردهای اصلی انطباق امنیتی

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

ISO/IEC 27001

استاندارد بین‌المللی سیستم مدیریت امنیت اطلاعات (ISMS) و رایج‌ترین گواهی امنیتی در دنیا. نسخه ۲۰۲۲ آن در پیوست A (Annex A) ۹۳ کنترل در چهار دسته سازمانی، انسانی، فیزیکی و فناورانه دارد. کنترل‌هایی مثل 8.8 (مدیریت آسیب‌پذیری‌های فنی) و 8.9 (مدیریت پیکربندی) مستقیماً به کار تیم زیرساخت مربوط می‌شوند. جزئیات کامل را در راهنمای استاندارد ISO 27001 بخوانید.

PCI DSS

استاندارد امنیت داده صنعت کارت پرداخت که نسخه 4.0 آن در مارس ۲۰۲۲ و نسخه 4.0.1 در ژوئن ۲۰۲۴ منتشر شد. برخلاف بسیاری از استانداردها، الزامات فنی بسیار صریحی دارد؛ از پیکربندی امن همه اجزا (الزام ۲) تا اسکن آسیب‌پذیری داخلی و خارجی هر سه ماه و تست نفوذ سالانه. برای جزئیات، راهنمای PCI DSS 4.0 را ببینید.

NIST CSF 2.0

چارچوب امنیت سایبری مؤسسه NIST که نسخه 2.0 آن در فوریه ۲۰۲۴ با شش کارکرد Govern، Identify، Protect، Detect، Respond و Recover منتشر شد. گواهی ندارد و الزام‌آور نیست، اما زبان مشترک خوبی برای سنجش بلوغ امنیتی و گزارش به مدیران ارشد است.

CIS Controls

مجموعه‌ای از ۱۸ کنترل اولویت‌بندی‌شده (نسخه 8.1) با سه گروه پیاده‌سازی IG1 تا IG3. برای سازمانی که نقطه شروع عملی می‌خواهد بسیار مناسب است و در کنار آن، CIS Benchmarks جزئیات پیکربندی امن هر سیستم‌عامل و سرویس را مشخص می‌کنند.

الزامات افتا و مقررات بخشی در ایران

مرکز مدیریت راهبردی افتا مسئول امنیت فضای تولید و تبادل اطلاعات در زیرساخت‌های حیاتی کشور است و برای این دستگاه‌ها الزامات و راهنماهای امنیتی صادر می‌کند. محورهای کلی این الزامات شامل شناسایی دارایی‌ها، امن‌سازی سیستم‌ها، ارزیابی آسیب‌پذیری، مدیریت وصله، ثبت و نگهداری لاگ، کنترل دسترسی، پاسخ به حادثه و ممیزی دوره‌ای است (جزئیات در الزامات افتا). علاوه بر این، نهادهای ناظر بخشی مثل بانک مرکزی برای بانک‌ها و شرکت‌های پرداخت الزامات اختصاصی دارند. چون این مقررات به‌روزرسانی می‌شوند، همیشه آخرین نسخه اسناد رسمی را مبنا قرار دهید.

انطباق مستمر در برابر ممیزی سالانه

مدل سنتی کامپلاینس این‌طور است: چند هفته قبل از ممیزی، تیم‌ها با عجله اسکرین‌شات جمع می‌کنند، چند سرور را وصله می‌کنند و گزارشی تهیه می‌کنند که فقط وضعیت همان روز را نشان می‌دهد. مشکل این است که محیط فناوری اطلاعات هر روز تغییر می‌کند؛ سرور جدید اضافه می‌شود، یک تغییر اضطراری پیکربندی را عوض می‌کند و هر هفته صدها CVE جدید منتشر می‌شود.

انطباق مستمر (Continuous Compliance) یعنی کنترل‌ها به‌صورت خودکار و دائمی سنجیده شوند، انحراف‌ها همان موقع کشف شوند و شواهد به‌تدریج در طول سال انباشته شوند. نتیجه این است که روز ممیزی فقط یک روز کاری عادی است. مراحل این چرخه:

1. تعیین دامنه (Scope): مشخص کنید کدام سیستم‌ها، داده‌ها و واحدها مشمول کدام الزام هستند. دامنه دقیق، هزینه انطباق را به‌شدت کاهش می‌دهد.
2. نگاشت کنترل‌ها: هر بند استاندارد را به یک الزام فنی قابل سنجش تبدیل کنید؛ مثلاً «مدیریت آسیب‌پذیری» یعنی اسکن احرازهویت‌شده ماهانه و رفع موارد بحرانی در مهلت مشخص.
3. ارزیابی: وضعیت فعلی را با اسکن آسیب‌پذیری و ممیزی پیکربندی در برابر خط مبنا (Baseline) بسنجید.
4. اصلاح: شکاف‌ها را بر اساس ریسک اولویت‌بندی و رفع کنید و با اسکن مجدد، رفع آن‌ها را تأیید کنید.
5. جمع‌آوری شواهد: گزارش‌ها، تیکت‌ها و سوابق را با تاریخ و به‌صورت قابل ردیابی نگه دارید.
6. پایش مستمر: انحراف پیکربندی (Configuration Drift) و آسیب‌پذیری‌های تازه را بین دو ممیزی رصد کنید.

شواهد ممیزی (Audit Evidence): ممیز دقیقاً چه می‌خواهد؟

ممیز دو چیز را بررسی می‌کند: اینکه کنترل درست طراحی شده باشد و اینکه در طول دوره ممیزی واقعاً اجرا شده باشد. برای همین معمولاً سه نوع شواهد درخواست می‌شود:

• مستندات طراحی: سیاست‌ها، رویه‌ها، استاندارد پیکربندی امن، روش ارزیابی ریسک و بیانیه کاربست‌پذیری (SoA) در ISO 27001.
• سوابق اجرا: گزارش‌های اسکن دوره‌ای، تیکت‌های رفع آسیب‌پذیری، سوابق تغییرات، صورت‌جلسه بازبینی دسترسی‌ها و لاگ‌ها.
• خروجی‌های فنی: نمونه پیکربندی واقعی سیستم‌ها، گزارش تطابق با Benchmark و نتیجه اسکن مجدد بعد از اصلاح.

شواهد خوب تاریخ دارد، کل دامنه را پوشش می‌دهد، قابل ردیابی است و چرخه کامل «کشف، رفع، تأیید» را نشان می‌دهد. ممیزها معمولاً به‌صورت نمونه‌ای چند سرور یا چند ماه را انتخاب می‌کنند؛ پس شواهد باید برای کل دوره در دسترس باشد، نه فقط ماه آخر. هر استثنا یا پذیرش ریسک هم باید مستند و توسط مالک ریسک تأیید شده باشد.

چگونه هاردنینگ و مدیریت آسیب‌پذیری شواهد ممیزی می‌سازند

دو فعالیت فنی بیشترین سهم را در شواهد کامپلاینس دارند. هاردنینگ (مقاوم‌سازی) خط مبنای پیکربندی امن را تعریف می‌کند و گزارش تطابق با آن، شواهد مستقیم کنترل‌های پیکربندی است. مدیریت آسیب‌پذیری با اسکن منظم، اولویت‌بندی، رفع و اسکن مجدد، سوابقی تولید می‌کند که تقریباً همه استانداردها آن را می‌خواهند. اگر این دو فرایند با ابزار مناسب و زمان‌بندی ثابت اجرا شوند، بخش بزرگی از شواهد خودبه‌خود تولید می‌شود. برای جزئیات فرایند، چرخه مدیریت آسیب‌پذیری را بخوانید.

جدول زیر نمونه‌ای از نگاشت چارچوب به الزام فنی و شواهد است:

چارچوب و بند	الزام فنی	شواهد قابل ارائه
ISO 27001 – کنترل 8.8	شناسایی و رفع به‌موقع آسیب‌پذیری‌های فنی	گزارش‌های اسکن دوره‌ای، تیکت‌های رفع، اسکن مجدد
ISO 27001 – کنترل 8.9	تعریف و نگهداری پیکربندی امن	خط مبنای مستند، گزارش تطابق، گزارش انحراف
PCI DSS – الزام ۲	پیکربندی امن همه اجزای سیستم	استاندارد پیکربندی، گزارش ممیزی پیکربندی
PCI DSS – الزام 6.3.3	نصب وصله‌های بحرانی ظرف یک ماه	سوابق وصله با تاریخ انتشار و نصب
PCI DSS – 11.3.1 و 11.3.2	اسکن داخلی و خارجی (ASV) هر سه ماه	گزارش‌های فصلی اسکن و اسکن مجدد
NIST CSF 2.0 – Identify	شناسایی دارایی‌ها و آسیب‌پذیری‌ها	فهرست دارایی‌ها، گزارش ریسک اولویت‌بندی‌شده
CIS Controls – کنترل ۴ و ۷	پیکربندی امن و مدیریت مستمر آسیب‌پذیری	امتیاز Benchmark، روند آسیب‌پذیری‌ها در زمان
الزامات افتا (کلی)	امن‌سازی، ارزیابی آسیب‌پذیری، ثبت رخداد	گزارش ارزیابی، سوابق اصلاح، لاگ‌ها

همان‌طور که می‌بینید، یک اسکن احرازهویت‌شده و یک ممیزی پیکربندی می‌تواند هم‌زمان چند الزام از چند استاندارد را پوشش دهد. به همین دلیل بهتر است به‌جای پروژه جداگانه برای هر استاندارد، یک مجموعه کنترل یکپارچه بسازید و آن را به همه چارچوب‌ها نگاشت کنید.

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

• هدف قرار دادن گواهی به‌جای امنیت: گواهی تأیید وضعیت در یک بازه است، نه تضمین امنیت در آینده.
• دامنه نامشخص: دامنه خیلی بزرگ هزینه را بالا می‌برد و دامنه خیلی کوچک ممیز را قانع نمی‌کند.
• شواهد دستی و پراکنده: اسکرین‌شات‌هایی که تاریخ و منبع ندارند، در ممیزی ارزش کمی دارند.
• استثناهای مستندنشده: سیستم قدیمی که قابل وصله نیست باید کنترل جبرانی و پذیرش ریسک مکتوب داشته باشد.
• جدا کردن تیم فنی از پروژه: وقتی کامپلاینس فقط کار واحد حاکمیت باشد، الزامات هیچ‌وقت به تنظیمات واقعی سیستم‌ها نمی‌رسد.

نت‌گارد چگونه به انطباق امنیتی کمک می‌کند

نت‌گارد بخش فنی کامپلاینس را خودکار می‌کند: اسکن آسیب‌پذیری احرازهویت‌شده و بدون عامل روی سرورها، تجهیزات شبکه، پایگاه‌های داده و برنامه‌های وب، ممیزی هاردنینگ در برابر CIS Benchmarks و خط مبنای اختصاصی سازمان، کشف انحراف پیکربندی و اولویت‌بندی ریسک بر اساس آسیب‌پذیری‌های دارای اکسپلویت و اهمیت دارایی. یافته‌ها به کنترل‌های ISO 27001، PCI DSS و NIST نگاشت می‌شوند، اسکن مجدد رفع آن‌ها را تأیید می‌کند و گزارش‌های مدیریتی و فنی به فارسی و انگلیسی آماده ارائه به ممیز هستند. امکان استقرار داخلی و حتی در شبکه ایزوله نیز وجود دارد. برای آشنایی بیشتر به صفحه انطباق امنیتی نت‌گارد سر بزنید.

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

کامپلاینس چیست؟

کامپلاینس یا انطباق امنیتی به معنای تطابق سیستم‌ها و فرایندهای سازمان با الزامات یک استاندارد، قانون یا مقررات بخشی و توانایی اثبات این تطابق با شواهد مستند است. نمونه‌های رایج آن ISO 27001، PCI DSS، NIST CSF و الزامات افتا هستند. کامپلاینس هم شامل اجرای کنترل‌های فنی و سازمانی است و هم شامل نگهداری سوابقی که ممیز بتواند اجرای آن‌ها را بررسی کند.

تفاوت کامپلاینس و امنیت چیست؟

امنیت یعنی کاهش واقعی ریسک در برابر تهدیدها، در حالی که کامپلاینس یعنی تطابق با یک مجموعه الزام مشخص و اثبات آن به ممیز. سازمان می‌تواند گواهی داشته باشد اما به دلیل سیستم‌های وصله‌نشده آسیب‌پذیر باشد، یا امنیت خوبی داشته باشد اما به دلیل نبود مستندات در ممیزی رد شود. بهترین رویکرد این است که کنترل‌های امنیتی واقعی اجرا شوند و شواهد کامپلاینس به‌صورت خودکار از همان فرایندها تولید شود.

آیا داشتن گواهی ISO 27001 یعنی سازمان امن است؟

نه لزوماً. گواهی ISO 27001 نشان می‌دهد سیستم مدیریت امنیت اطلاعات سازمان در زمان ممیزی با الزامات استاندارد مطابقت داشته و ممیزی‌های مراقبتی سالانه آن را ادامه می‌دهند. اما امنیت واقعی به اجرای روزانه کنترل‌ها بستگی دارد؛ مثلاً اینکه آسیب‌پذیری‌ها چقدر سریع وصله می‌شوند و پیکربندی سرورهای جدید چقدر با خط مبنا فاصله دارد. پایش مستمر این فاصله را کم می‌کند.

کدام استاندارد امنیتی برای سازمان من مناسب است؟

انتخاب استاندارد به صنعت، مشتریان و نهاد ناظر بستگی دارد. سازمان‌هایی که داده کارت پرداخت را پردازش می‌کنند با PCI DSS، دستگاه‌های زیرساخت حیاتی با الزامات افتا و شرکت‌هایی که به مشتریان سازمانی خدمات می‌دهند معمولاً با ISO 27001 سروکار دارند. NIST CSF و CIS Controls برای سنجش بلوغ و شروع عملی مناسب‌اند. بیشتر سازمان‌ها چند چارچوب را هم‌زمان با یک مجموعه کنترل مشترک پوشش می‌دهند.

شواهد ممیزی (Audit Evidence) چیست؟

شواهد ممیزی هر سند، گزارش یا سابقه‌ای است که نشان می‌دهد یک کنترل امنیتی طراحی و در طول دوره ممیزی اجرا شده است. نمونه‌ها شامل سیاست‌ها و رویه‌ها، گزارش‌های اسکن آسیب‌پذیری، تیکت‌های رفع، سوابق تغییرات، گزارش تطابق پیکربندی و لاگ‌ها هستند. شواهد معتبر تاریخ‌دار، قابل ردیابی و پوشش‌دهنده کل دامنه است و چرخه کشف، رفع و تأیید را نشان می‌دهد.