Attack Surface Management چیست؟ چگونه سطح حمله سایت و زیرساخت را کاهش دهیم؟
Attack Surface Management یا مدیریت سطح حمله، فرایندی مستمر برای شناسایی، ارزیابی و کاهش نقاط دسترسی احتمالی مهاجمان به سایت، سرور و زیرساخت سازمان است. زیردامنه‌های فراموش‌شده، پورت‌های غیرضروری، سرویس‌های قدیمی، APIهای ناامن و دسترسی‌های مدیریتی گسترده از مهم‌ترین عوامل افزایش سطح حمله هستند. شناسایی کامل دارایی‌ها، محدودسازی دسترسی، حذف سرویس‌های بلااستفاده، مدیریت آسیب‌پذیری‌ها و پایش مداوم تغییرات می‌تواند احتمال نفوذ و گسترش حملات را کاهش دهد.
Attack Surface Management یا مدیریت سطح حمله فرایندی مستمر برای شناسایی، ارزیابی، اولویت‌بندی و کاهش نقاطی است که مهاجمان می‌توانند از طریق آن‌ها به سایت، سرور، شبکه یا زیرساخت سازمان دسترسی پیدا کنند. این نقاط شامل دامنه‌ها، زیردامنه‌ها، پورت‌های باز، سرویس‌های اینترنتی، APIها، پنل‌های مدیریتی و دارایی‌های ابری هستند. هدف اصلی مدیریت سطح حمله، حذف دسترسی‌های غیرضروری و کاهش احتمال نفوذ و خسارت امنیتی است.
مقدمه: چرا حتی زیرساخت‌های امن هم ممکن است در معرض حمله باشند؟
تصور کنید یک فروشگاه اینترنتی از فایروال قدرتمند، گواهی SSL معتبر، احراز هویت دومرحله‌ای و سیستم مانیتورینگ پیشرفته استفاده می‌کند. تمام سرورهای اصلی به‌روزرسانی شده‌اند و تیم فنی نیز به‌صورت منظم وضعیت امنیت وب‌سایت را بررسی می‌کند.
بااین‌حال، یک زیردامنه آزمایشی متعلق به چند سال قبل همچنان فعال است.
این زیردامنه به نسخه‌ای قدیمی از نرم‌افزار متصل شده که دیگر پشتیبانی نمی‌شود. هیچ‌کس مسئول نگهداری آن نیست و حتی تیم امنیت سازمان نیز از وجود آن اطلاع ندارد.
در چنین شرایطی، سرمایه‌گذاری روی امنیت سایت اصلی نمی‌تواند به‌تنهایی خطر ناشی از آن دارایی فراموش‌شده را برطرف کند.
این مسئله یکی از مهم‌ترین چالش‌های امنیت سایبری مدرن است: سازمان‌ها همیشه تصویر کاملی از تمام نقاط قابل‌دسترسی زیرساخت خود ندارند.
هر پروژه جدید، محیط آزمایشی، سرویس ابری، API، اتصال شخص ثالث یا تغییر زیرساخت می‌تواند سطح حمله را افزایش دهد.
مشکل زمانی جدی‌تر می‌شود که دارایی‌های جدید بدون ثبت رسمی ایجاد شوند یا پس از پایان پروژه همچنان فعال باقی بمانند.
در گذشته، بسیاری از سازمان‌ها با چند سرور و تعداد محدودی دامنه فعالیت می‌کردند. اما امروزه حتی یک وب‌سایت متوسط ممکن است از CDN، سرویس پرداخت، فضای ذخیره‌سازی ابری، چندین API، محیط توسعه و سامانه‌های مدیریت مستقل استفاده کند.
این پیچیدگی باعث می‌شود مدیریت امنیت صرفاً با نصب فایروال یا اجرای اسکن آسیب‌پذیری امکان‌پذیر نباشد.
در چنین محیطی، Attack Surface Management یا ASM به یکی از اجزای مهم برنامه امنیت سازمان تبدیل می‌شود.
مدیریت سطح حمله کمک می‌کند مشخص شود چه دارایی‌هایی وجود دارند، کدام‌یک از بیرون قابل‌دسترسی هستند، چه خطراتی دارند و کدام اقدامات بیشترین تأثیر را در کاهش احتمال نفوذ خواهند داشت.
در این مقاله، مفهوم Attack Surface Management را به‌صورت تخصصی بررسی می‌کنیم و روش‌های عملی کاهش سطح حمله سایت، وردپرس، APIها، سرورها، زیرساخت ابری و شبکه سازمانی را توضیح می‌دهیم.
Attack Surface Management چیست؟
Attack Surface Management به معنای مدیریت سطح حمله، مجموعه‌ای از فرایندها و کنترل‌های امنیتی است که برای شناسایی و کاهش مسیرهای احتمالی نفوذ به دارایی‌های دیجیتال استفاده می‌شود.
این مفهوم بر یک اصل ساده استوار است:
نمی‌توان از دارایی یا مسیری که وجود آن ناشناخته است، به‌درستی محافظت کرد.
در مدیریت سطح حمله، ابتدا دارایی‌های مرتبط با سازمان شناسایی می‌شوند. سپس میزان دسترسی، اهمیت و وضعیت امنیتی آن‌ها بررسی می‌شود.
در مرحله بعد، خطرات شناسایی‌شده بر اساس احتمال سوءاستفاده و میزان خسارت احتمالی اولویت‌بندی می‌شوند.
در نهایت، سازمان تلاش می‌کند با حذف سرویس‌های اضافی، محدودسازی دسترسی، اصلاح پیکربندی‌ها و به‌روزرسانی نرم‌افزارها سطح حمله را کاهش دهد.
این فرایند برخلاف یک بررسی امنیتی مقطعی، باید به‌صورت مداوم تکرار شود.
منظور از Attack Surface یا سطح حمله چیست؟
Attack Surface به مجموع نقاط، مسیرها و رابط‌هایی گفته می‌شود که امکان تعامل با یک سیستم، ورود داده یا دسترسی به منابع آن را فراهم می‌کنند و ممکن است مورد سوءاستفاده قرار گیرند.
سطح حمله می‌تواند شامل موارد زیر باشد:
- صفحات ورود و پنل‌های مدیریتی
- دامنه‌ها و زیردامنه‌های سازمان
- پورت‌های شبکه و سرویس‌های فعال
- APIها و رابط‌های ارتباطی
- نرم‌افزارها و افزونه‌های نصب‌شده
- حساب‌های کاربری و مجوزهای دسترسی
- سرویس‌های ابری و منابع ذخیره‌سازی
- ابزارهای مدیریت و مانیتورینگ
- ارتباطات بین سرورها و برنامه‌ها
- تجهیزات شبکه و سیستم‌های متصل
برای مثال، اگر یک سرور وب علاوه بر HTTPS، رابط مدیریت پایگاه داده و سرویس SSH را مستقیماً در اینترنت منتشر کند، چندین مسیر بالقوه برای دسترسی به زیرساخت وجود دارد.
وجود این سرویس‌ها الزاماً به معنای آسیب‌پذیربودن آن‌ها نیست؛ اما هر سرویس قابل‌دسترسی باید به‌عنوان بخشی از سطح حمله بررسی شود.
مدیریت سطح حمله چه هدفی دارد؟
هدف Attack Surface Management حذف تمام ارتباطات و امکانات سیستم نیست.
یک وب‌سایت برای خدمت‌رسانی به کاربران باید از اینترنت قابل‌دسترسی باشد. API نیز ممکن است برای اتصال اپلیکیشن موبایل یا سرویس‌های تجاری ضروری باشد.
هدف اصلی این است که فقط مسیرهای موردنیاز باقی بمانند و همان مسیرها نیز با کنترل‌های مناسب محافظت شوند.
به بیان دیگر، مدیریت سطح حمله تلاش می‌کند بین نیازهای عملیاتی و حداقل دسترسی ضروری تعادل برقرار کند.
چرا مدیریت سطح حمله برای امنیت سایت اهمیت دارد؟
یکی از ویژگی‌های مهم زیرساخت‌های دیجیتال این است که دائماً تغییر می‌کنند.
تیم توسعه ممکن است یک زیردامنه جدید ایجاد کند. مدیر سرور یک سرویس مانیتورینگ راه‌اندازی کند. بخش فروش نیز یک ابزار CRM به وب‌سایت متصل کند.
هرکدام از این تغییرات می‌توانند نقاط دسترسی جدیدی ایجاد کنند.
دارایی‌های ناشناخته و فراموش‌شده
یکی از خطرات مهم، دارایی‌هایی هستند که مالک یا وضعیت نگهداری مشخصی ندارند.
ممکن است یک سرور قدیمی همچنان در شبکه فعال باشد، اما دیگر هیچ تیمی مسئول به‌روزرسانی آن نباشد.
یا یک محیط آزمایشی پس از پایان پروژه غیرفعال نشده باشد.
این دارایی‌ها ممکن است برای مدت طولانی از فرایندهای امنیتی سازمان خارج بمانند.
افزایش پیچیدگی معماری زیرساخت
استفاده از Microservices، Kubernetes، سرویس‌های ابری و زیرساخت‌های توزیع‌شده، مدیریت امنیت را پیچیده‌تر می‌کند.
در این معماری‌ها، منابع می‌توانند به‌صورت پویا ایجاد یا حذف شوند.
بنابراین، فهرست دارایی‌هایی که یک ماه قبل تهیه شده است، ممکن است دیگر وضعیت واقعی زیرساخت را نشان ندهد.
کاهش احتمال حرکت جانبی مهاجم
اگر یکی از سرویس‌ها به خطر بیفتد، مهاجم ممکن است تلاش کند به سایر بخش‌های زیرساخت دسترسی پیدا کند.
این رفتار Lateral Movement یا حرکت جانبی نام دارد.
تفکیک شبکه، محدودسازی مجوزها و حذف ارتباطات غیرضروری می‌تواند گسترش نفوذ را دشوارتر کند.
بهبود اولویت‌بندی اقدامات امنیتی
همه مشکلات امنیتی شدت یکسانی ندارند.
برای مثال، یک رابط مدیریتی حساس که مستقیماً در اینترنت قرار دارد، معمولاً نیازمند بررسی متفاوتی نسبت به یک سرویس آزمایشی کاملاً جداشده است.
ASM کمک می‌کند منابع امنیتی بر خطراتی متمرکز شوند که پیامد واقعی بیشتری دارند. 
انواع سطح حمله در سایت و زیرساخت
برای مدیریت مؤثر Attack Surface باید انواع مختلف سطح حمله را شناخت.
هر دسته به کنترل‌ها و روش‌های ارزیابی مخصوص خود نیاز دارد.
سطح حمله خارجی یا External Attack Surface
سطح حمله خارجی شامل دارایی‌ها و سرویس‌هایی است که از اینترنت یا شبکه‌های خارج از محدوده اعتماد سازمان قابل‌دسترسی هستند.
نمونه‌های آن عبارت‌اند از:
- وب‌سایت عمومی
- زیردامنه‌های اینترنتی
- IPهای عمومی
- سرویس‌های VPN
- پنل‌های مدیریت قابل‌دسترسی از اینترنت
- APIهای عمومی
- سرویس‌های ایمیل
- برنامه‌های تحت وب میزبانی‌شده در فضای ابری
مدیریت این دسته اهمیت زیادی دارد، زیرا بعضی از این دارایی‌ها بدون نیاز به حضور در شبکه داخلی سازمان قابل‌شناسایی هستند.
سطح حمله داخلی یا Internal Attack Surface
سطح حمله داخلی به مسیرهای دسترسی در شبکه سازمان، سرورهای خصوصی و ارتباطات بین سرویس‌ها اشاره دارد.
برای مثال، دسترسی آزاد تمام سرورها به یک پایگاه داده داخلی می‌تواند سطح حمله داخلی را افزایش دهد.
اگر یک سیستم به خطر بیفتد، چنین ارتباطاتی ممکن است گسترش حادثه را آسان‌تر کنند.
بنابراین، خصوصی‌بودن شبکه به معنای بی‌نیازی از کنترل دسترسی نیست.
سطح حمله برنامه‌های وب
برنامه‌های وب دارای مسیرهای مختلف دریافت و پردازش داده هستند.
فرم ورود، بخش آپلود فایل، جست‌وجو، مدیریت سفارش و صفحات حساب کاربری نمونه‌هایی از این نقاط هستند.
در این بخش، آسیب‌پذیری‌هایی مانند XSS، SQL Injection، CSRF و ضعف کنترل دسترسی اهمیت پیدا می‌کنند.
هر قابلیت جدید می‌تواند مسیرهای تعامل تازه‌ای ایجاد کند که باید از نظر امنیتی بررسی شوند.
سطح حمله هویت و دسترسی
حساب‌های کاربری، توکن‌ها، کلیدهای API، نشست‌ها و مجوزهای مدیریتی نیز بخشی از سطح حمله هستند.
برای مثال، وجود حساب مدیریتی قدیمی با رمز عبور ضعیف می‌تواند حتی در صورت ایمن‌بودن سرویس‌های شبکه خطر ایجاد کند.
این بخش با مفاهیمی مانند Identity and Access Management یا IAM ارتباط مستقیم دارد.
سطح حمله زنجیره تأمین نرم‌افزار
نرم‌افزارها معمولاً از کتابخانه‌ها، افزونه‌ها و سرویس‌های شخص ثالث استفاده می‌کنند.
آسیب‌پذیری در یکی از این وابستگی‌ها ممکن است امنیت کل برنامه را تحت‌تأثیر قرار دهد.
بنابراین، مدیریت سطح حمله فقط به سرورها و پورت‌ها محدود نمی‌شود.
سطح حمله فیزیکی
در محیط‌هایی که سازمان مالک تجهیزات زیرساختی است، دسترسی فیزیکی به سرورها، تجهیزات شبکه و رسانه‌های ذخیره‌سازی نیز اهمیت دارد.
این حوزه معمولاً با کنترل تردد، حفاظت از تجهیزات و سیاست‌های امنیت فیزیکی مدیریت می‌شود.
تمرکز اصلی ASM برای سایت‌ها اغلب روی سطح حمله دیجیتال است، اما در ارزیابی جامع سازمانی نباید مسیرهای فیزیکی را نادیده گرفت. 
تفاوت Attack Surface Management با EASM و سایر روش‌های امنیتی
چند مفهوم نزدیک به مدیریت سطح حمله وجود دارند که گاهی به‌اشتباه یکسان در نظر گرفته می‌شوند.
| مفهوم | هدف اصلی | محدوده تمرکز |
|---|---|---|
| ASM | شناسایی و کاهش مسیرهای احتمالی حمله | کل سطح حمله سازمان |
| EASM | مدیریت دارایی‌های در معرض اینترنت | سطح حمله خارجی |
| CAASM | تجمیع و تحلیل موجودی دارایی‌های سایبری | دارایی‌ها و داده‌های چند سامانه |
| Vulnerability Management | شناسایی و اصلاح آسیب‌پذیری‌ها | ضعف‌های شناخته‌شده و قابل‌بررسی |
| Penetration Testing | ارزیابی عملی امنیت در محدوده مجاز | سیستم‌ها و سناریوهای مشخص |
| CTEM | مدیریت مستمر مواجهه با تهدید | اولویت‌بندی و اعتبارسنجی مواجهه‌های امنیتی |
External Attack Surface Management چیست؟
EASM مخفف External Attack Surface Management است.
این رویکرد بر شناسایی، پایش و کاهش خطرات دارایی‌هایی تمرکز دارد که از خارج سازمان، به‌ویژه اینترنت، قابل‌دسترسی هستند.
برای مثال، شناسایی زیردامنه‌های فراموش‌شده، سرویس‌های عمومی ناخواسته و منابع ابری اشتباه پیکربندی‌شده می‌تواند بخشی از فعالیت EASM باشد.
EASM زیرمجموعه‌ای از مدیریت سطح حمله محسوب می‌شود.
تفاوت ASM با اسکن آسیب‌پذیری
Vulnerability Scanning معمولاً به بررسی ضعف‌های امنیتی در دارایی‌های مشخص می‌پردازد.
اما ASM باید پیش از آن مشخص کند چه دارایی‌هایی وجود دارند و کدام‌یک نیازمند بررسی هستند.
ممکن است اسکنر روی تمام سرورهای ثبت‌شده اجرا شود، اما یک سرور قدیمی که در فهرست وجود ندارد، بررسی نشود.
مدیریت سطح حمله تلاش می‌کند چنین شکاف‌هایی را شناسایی کند.
تفاوت ASM با تست نفوذ
تست نفوذ یا Penetration Testing با مجوز و محدوده مشخص، مقاومت سیستم در برابر سناریوهای حمله را ارزیابی می‌کند.
در مقابل، ASM بیشتر بر شناخت مستمر دارایی‌ها، تغییرات و سطح مواجهه تمرکز دارد.
این دو روش مکمل یکدیگر هستند.
نتایج ASM می‌توانند برای تعیین محدوده تست نفوذ استفاده شوند و یافته‌های تست نفوذ نیز به اصلاح اولویت‌های مدیریت سطح حمله کمک کنند. 
مرحله اول: شناسایی تمام دارایی‌های دیجیتال سازمان
نخستین مرحله مدیریت سطح حمله، Asset Discovery یا کشف دارایی‌ها است.
در این مرحله باید تصویری قابل‌اعتماد از سیستم‌هایی که تحت مالکیت یا مسئولیت سازمان هستند تهیه شود.
تهیه فهرست دامنه‌ها و زیردامنه‌ها
دامنه اصلی معمولاً شناخته‌شده است؛ اما زیردامنه‌های قدیمی ممکن است فراموش شده باشند.
برای مثال، یک سازمان ممکن است زیردامنه‌های جداگانه‌ای برای موارد زیر داشته باشد:
- پنل مدیریت
- محیط توسعه
- نسخه آزمایشی سایت
- مستندات API
- سامانه پشتیبانی
- داشبورد مانیتورینگ
- سرویس‌های مربوط به مشتریان
- پروژه‌های قدیمی
تمام این موارد باید در فهرست دارایی‌ها ثبت شوند.
وجود یک رکورد DNS به‌تنهایی ثابت نمی‌کند که سرویس فعال یا متعلق به سازمان است؛ بنابراین، یافته‌ها باید با اطلاعات مالکیت و زیرساخت تطبیق داده شوند.
استفاده از منابع اطلاعاتی مجاز
برای شناخت سطح حمله خارجی می‌توان از اطلاعات مدیریتی DNS، رکوردهای موجود در سامانه‌های سازمان، اطلاعات گواهی‌های دیجیتال و فهرست منابع ابری استفاده کرد.
Certificate Transparency Logs می‌توانند به شناسایی نام‌هایی کمک کنند که برای آن‌ها گواهی دیجیتال صادر شده است.
بااین‌حال، این اطلاعات ممکن است قدیمی یا مربوط به دارایی‌های غیرفعال باشند.
به همین دلیل، اعتبارسنجی یافته‌ها ضروری است.
تمام بررسی‌های فعال شبکه باید فقط روی دارایی‌هایی انجام شوند که مالکیت یا مجوز ارزیابی آن‌ها مشخص است.
شناسایی سرورها و IPهای عمومی
سازمان باید بداند چه آدرس‌های عمومی در اختیار دارد و هر آدرس به کدام سرویس اختصاص یافته است.
گاهی یک IP عمومی به ماشین مجازی یا Load Balancer قدیمی متصل مانده است.
در زیرساخت‌های ابری، بررسی فهرست رسمی منابع و تنظیمات شبکه می‌تواند به شناسایی این موارد کمک کند.
شناسایی منابع ابری
منابع ابری ممکن است شامل ماشین‌های مجازی، فضای Object Storage، پایگاه داده مدیریت‌شده، Load Balancer و سرویس‌های Serverless باشند.
در این بخش باید مشخص شود کدام منابع از اینترنت قابل‌دسترسی هستند و آیا این دسترسی واقعاً ضروری است یا خیر.
برای نمونه، یک فضای ذخیره‌سازی خصوصی نباید به دلیل تنظیمات اشتباه به‌صورت عمومی منتشر شود.
شناسایی دارایی‌های بدون مالک مشخص
برای هر دارایی باید مسئول فنی و مالک کسب‌وکاری مشخص شود.
دارایی بدون مالک، حتی اگر در حال حاضر آسیب‌پذیری شناخته‌شده‌ای نداشته باشد، از نظر مدیریت و نگهداری ریسک بیشتری دارد.
وجود مالک مشخص باعث می‌شود مسئولیت به‌روزرسانی، بررسی هشدارها و تصمیم‌گیری درباره حذف یا نگهداری سرویس روشن باشد.
مرحله دوم: تهیه نقشه سطح حمله یا Attack Surface Mapping
پس از شناسایی دارایی‌ها، باید ارتباط بین آن‌ها مشخص شود.
فهرستی از نام سرورها به‌تنهایی نمی‌تواند ساختار واقعی سطح حمله را نشان دهد.
ترسیم مسیر ورود درخواست‌ها
برای یک فروشگاه اینترنتی، مسیر درخواست ممکن است به شکل زیر باشد:
کاربر اینترنت ← CDN یا WAF ← Load Balancer ← سرور وب ← Backend ← پایگاه داده
هر بخش در این مسیر باید از نظر دسترسی و مسئولیت امنیتی بررسی شود.
برای مثال، ممکن است سایت از CDN محافظت شود اما سرور اصلی همچنان به‌صورت مستقیم از اینترنت قابل‌دسترسی باشد.
در چنین حالتی، برخی کنترل‌های مستقر در لایه CDN ممکن است با ارتباط مستقیم به Origin اعمال نشوند.
شناسایی مسیرهای ورود و خروج داده
سطح حمله فقط شامل مسیرهای ورود به سیستم نیست.
مسیرهایی که داده از طریق آن‌ها خارج می‌شود نیز اهمیت دارند.
برای مثال، یک سرویس Backend ممکن است به چندین سرویس خارجی متصل باشد.
این ارتباطات باید بررسی شوند تا مشخص شود چه داده‌هایی منتقل می‌شوند و آیا محدودسازی مقصدها امکان‌پذیر است یا خیر.
شناسایی مرزهای اعتماد
Trust Boundary یا مرز اعتماد، محدوده‌ای است که در آن سطح اعتماد یا سیاست امنیتی تغییر می‌کند.
ارتباط اینترنت با Frontend یک مرز اعتماد است.
ارتباط Frontend با Backend یا برنامه با پایگاه داده نیز می‌تواند مرز اعتماد دیگری باشد.
در هر مرز باید احراز هویت، مجوز دسترسی، اعتبارسنجی داده و کنترل ارتباط متناسب با ریسک وجود داشته باشد.
طبقه‌بندی دارایی‌ها بر اساس اهمیت
تمام دارایی‌ها ارزش و حساسیت یکسانی ندارند.
برای مثال، پایگاه داده کاربران، سیستم پرداخت و سامانه مدیریت اعتبارنامه‌ها اهمیت بیشتری نسبت به یک صفحه اطلاع‌رسانی عمومی دارند.
شناخت حساسیت دارایی‌ها کمک می‌کند تصمیم‌های امنیتی صرفاً بر اساس تعداد درگاه‌ها یا سرویس‌ها گرفته نشوند. 
مرحله سوم: شناسایی نقاط پرخطر در سطح حمله
پس از ترسیم نقشه دارایی‌ها، باید نقاطی شناسایی شوند که احتمال سوءاستفاده یا شدت پیامدهای آن‌ها بیشتر است.
پنل‌های مدیریتی قابل‌دسترسی از اینترنت
رابط‌های مدیریتی یکی از نقاط حساس زیرساخت هستند.
نمونه‌هایی از آن‌ها شامل کنترل‌پنل سرور، داشبورد مجازی‌سازی، مدیریت پایگاه داده و رابط مدیریت سرویس‌های ابری است.
بهتر است چنین رابط‌هایی فقط از مسیرهای مدیریتی محافظت‌شده قابل‌دسترسی باشند.
سرویس‌های قدیمی و بدون پشتیبانی
نرم‌افزاری که دیگر وصله امنیتی دریافت نمی‌کند، ممکن است با گذشت زمان در معرض خطر بیشتری قرار گیرد.
در این شرایط، ادامه استفاده از سرویس باید با ارزیابی ریسک و برنامه جایگزینی همراه باشد.
حساب‌های کاربری با مجوزهای گسترده
حساب‌های مدیریتی مشترک یا حساب‌هایی که بیش از نیاز واقعی دسترسی دارند، می‌توانند پیامد یک حادثه را تشدید کنند.
اصل Least Privilege یا حداقل دسترسی باید در سطح کاربران، سرویس‌ها و برنامه‌ها اعمال شود.
فایل‌ها و مسیرهای حساس
نسخه‌های پشتیبان، فایل‌های تنظیمات، گزارش‌های برنامه و اطلاعات محرمانه نباید بدون ضرورت از طریق وب قابل‌دسترسی باشند.
برای کاهش خطر، بهتر است این فایل‌ها خارج از مسیر عمومی وب نگهداری شوند و دسترسی به آن‌ها محدود باشد.
ارتباطات غیرضروری بین سیستم‌ها
اگر همه سرورها بتوانند آزادانه با یکدیگر ارتباط برقرار کنند، آسیب‌دیدن یکی از آن‌ها ممکن است دامنه حادثه را افزایش دهد.
تقسیم‌بندی شبکه و محدودسازی ارتباطات می‌تواند این خطر را کاهش دهد.
چگونه ریسک نقاط سطح حمله را اولویت‌بندی کنیم؟
یکی از اشتباهات رایج در مدیریت سطح حمله، یکسان دانستن تمام یافته‌ها است.
درحالی‌که ممکن است دو سرویس هر دو از اینترنت قابل‌دسترسی باشند، اما میزان خطر آن‌ها کاملاً متفاوت باشد.
معیارهای اصلی ارزیابی ریسک
برای اولویت‌بندی می‌توان پنج عامل مهم را بررسی کرد:
- قابلیت دسترسی: آیا دارایی از اینترنت عمومی یا شبکه غیرقابل‌اعتماد قابل‌دسترسی است؟
- وجود ضعف امنیتی: آیا آسیب‌پذیری شناخته‌شده یا پیکربندی خطرناک وجود دارد؟
- شواهد سوءاستفاده: آیا درباره بهره‌برداری واقعی از ضعف موردنظر شواهد معتبری وجود دارد؟
- اهمیت دارایی: آیا سیستم اطلاعات حساس نگهداری می‌کند یا برای کسب‌وکار حیاتی است؟
- کنترل‌های محافظتی: آیا دسترسی محدود، پایش فعال و کنترل‌های جبرانی مؤثر وجود دارند؟
این عوامل باید در کنار یکدیگر بررسی شوند.
چرا امتیاز CVSS به‌تنهایی کافی نیست؟
CVSS روشی برای بیان شدت فنی آسیب‌پذیری است.
اما امتیاز آن به‌تنهایی تمام شرایط محیطی سازمان را نشان نمی‌دهد.
برای مثال، یک آسیب‌پذیری در سامانه عمومی و حیاتی ممکن است نسبت به همان ضعف در یک محیط آزمایشی جداشده، اولویت اصلاح بیشتری داشته باشد.
همچنین وجود شواهد بهره‌برداری فعال می‌تواند در تصمیم‌گیری اهمیت زیادی داشته باشد.
استفاده از اطلاعاتی مانند CISA Known Exploited Vulnerabilities یا KEV در کنار وضعیت واقعی دارایی می‌تواند به اولویت‌بندی کمک کند.
نمونه جدول اولویت‌بندی
| دارایی | وضعیت مواجهه | اهمیت | اولویت پیشنهادی |
|---|---|---|---|
| پنل مدیریت عمومی با ضعف احراز هویت | بسیار بالا | حیاتی | فوری |
| سرور وب با آسیب‌پذیری قابل‌سوءاستفاده | بالا | بالا | فوری |
| زیردامنه آزمایشی بلااستفاده | بسته به وضعیت | متوسط | بررسی و حذف در صورت عدم نیاز |
| سرویس داخلی دارای دسترسی محدود | پایین‌تر | متوسط | برنامه اصلاح |
| ابزار توسعه غیرفعال و جداشده | پایین | پایین | پاک‌سازی برنامه‌ریزی‌شده |
این جدول صرفاً یک نمونه مفهومی است و رتبه واقعی باید بر اساس شواهد و معماری زیرساخت تعیین شود. 
کاهش سطح حمله شبکه و سرورها
بخش مهمی از Attack Surface Management به محدودسازی سرویس‌های قابل‌دسترسی در شبکه مربوط می‌شود.
بستن پورت‌های غیرضروری
هر پورت باز باید با نیاز عملیاتی مشخصی مرتبط باشد.
اگر یک سرویس دیگر استفاده نمی‌شود، بهتر است پس از بررسی وابستگی‌ها غیرفعال شود.
همچنین باید بین بازبودن یک پورت در سیستم‌عامل و قابلیت دسترسی واقعی از شبکه تفاوت قائل شد.
ممکن است سرویس در حال اجرا باشد، اما توسط فایروال محدود شده باشد.
برای کاهش سطح حمله، هر دو وضعیت باید بررسی شوند.
استفاده از فایروال با سیاست حداقل دسترسی
در طراحی فایروال بهتر است ارتباطات موردنیاز به‌صورت مشخص تعریف شوند.
رویکرد Default Deny به این معنا است که ارتباطات غیرمجاز به‌صورت پیش‌فرض مسدود باشند.
سپس فقط مسیرهای ضروری فعال شوند.
در سرورهای لینوکسی می‌توان از ابزارهای مدیریت فایروال متناسب با سیستم‌عامل و زیرساخت استفاده کرد.
در محیط‌های ابری نیز Security Groupها و سیاست‌های شبکه باید بررسی شوند.
محدودسازی دسترسی SSH
سرویس SSH برای مدیریت سرورها کاربرد زیادی دارد.
اما لازم نیست در همه زیرساخت‌ها از تمام آدرس‌های اینترنتی قابل‌دسترسی باشد.
استفاده از کلیدهای امن، محدودسازی دسترسی مدیریتی، احراز هویت مناسب و در صورت نیاز VPN یا Bastion Host می‌تواند خطر را کاهش دهد.
همچنین باید دسترسی حساب‌های مدیریتی و کلیدهای قدیمی به‌صورت دوره‌ای بررسی شود.
حذف سرویس‌های آزمایشی
بعضی نرم‌افزارها هنگام نصب، سرویس‌های نمونه یا داشبوردهای مدیریتی ایجاد می‌کنند.
اگر این اجزا در محیط عملیاتی ضروری نیستند، بهتر است حذف یا غیرفعال شوند.
بررسی IPv6
در بعضی زیرساخت‌ها، تیم امنیت فقط قوانین IPv4 را بررسی می‌کند.
اما ممکن است سرویس از طریق IPv6 نیز قابل‌دسترسی باشد.
اگر IPv6 فعال است، باید سیاست‌های امنیتی و فایروال مربوط به آن نیز بررسی شوند.
غیرفعال‌کردن IPv6 بدون شناخت نیازهای شبکه راهکار عمومی مناسبی نیست؛ مسئله اصلی مدیریت صحیح آن است.
کاهش سطح حمله برنامه‌های وب
برنامه وب معمولاً اصلی‌ترین بخش قابل‌دسترسی برای کاربران اینترنت است.
در نتیجه، کاهش سطح حمله آن اهمیت زیادی دارد.
حذف قابلیت‌های بلااستفاده
هر قابلیت جدید شامل منطق پردازش، مسیرهای دریافت داده و مجوزهای مخصوص خود است.
اگر بخشی از برنامه دیگر استفاده نمی‌شود، بهتر است پس از بررسی وابستگی‌ها حذف شود.
برای مثال، یک ماژول ثبت‌نام قدیمی یا مسیر مدیریتی منسوخ ممکن است همچنان در برنامه وجود داشته باشد.
اعتبارسنجی داده‌های ورودی
Input Validation به بررسی ساختار و محدوده داده‌های دریافتی اشاره دارد.
برنامه باید مشخص کند چه داده‌هایی قابل‌قبول هستند و درخواست‌های نامعتبر را به‌درستی مدیریت کند.
در کنار آن، استفاده از روش‌های امن دسترسی به پایگاه داده، خروجی‌سازی مناسب محتوا و کنترل دسترسی برای کاهش خطر آسیب‌پذیری‌هایی مانند SQL Injection و XSS ضروری است.
محافظت در برابر CSRF
Cross-Site Request Forgery یا CSRF زمانی مطرح می‌شود که مرورگر کاربر احراز هویت‌شده برای انجام یک عملیات ناخواسته مورد سوءاستفاده قرار گیرد.
استفاده از توکن‌های ضد CSRF، تنظیمات مناسب Cookie و کنترل درخواست‌های حساس می‌تواند خطر را کاهش دهد.
کاهش خطر XSS
Cross-Site Scripting یا XSS به اجرای محتوای اسکریپتی ناخواسته در زمینه امنیتی یک وب‌سایت مربوط می‌شود.
برای مقابله با آن باید از خروجی‌سازی متناسب با زمینه، پردازش امن داده‌های غیرقابل‌اعتماد و سیاست‌های دفاعی مناسب استفاده شود.
Content Security Policy یا CSP نیز می‌تواند یک لایه محافظتی تکمیلی باشد.
مدیریت صحیح خطاها
پیام‌های خطای عمومی نباید اطلاعات حساس درباره مسیرهای داخلی، ساختار پایگاه داده یا تنظیمات سرور را آشکار کنند.
در محیط عملیاتی، جزئیات فنی خطا بهتر است در سامانه لاگ محافظت‌شده ثبت شوند.
کاربر نهایی باید پیام مناسب و محدود دریافت کند.
استفاده از WAF
Web Application Firewall یا WAF می‌تواند بخشی از درخواست‌های مخرب یا غیرعادی را شناسایی و محدود کند.
اما WAF جایگزین اصلاح آسیب‌پذیری برنامه نیست.
برای مثال، ضعف کنترل دسترسی در منطق تجاری ممکن است صرفاً با یک قانون عمومی WAF برطرف نشود.
کاهش سطح حمله سایت‌های وردپرسی
وردپرس به دلیل ساختار افزونه‌محور و گستردگی امکانات، نیازمند مدیریت دقیق اجزای نصب‌شده است.
هر افزونه یا قالب اضافی می‌تواند کد، قابلیت یا مسیر دسترسی جدیدی به سایت اضافه کند.
حذف افزونه‌ها و قالب‌های غیرضروری
غیرفعال‌کردن یک افزونه لزوماً معادل حذف تمام فایل‌های آن نیست.
اگر افزونه یا قالبی دیگر موردنیاز نیست، بهتر است پس از تهیه نسخه پشتیبان و بررسی وابستگی‌ها به‌صورت کامل حذف شود.
به‌روزرسانی هسته، افزونه‌ها و قالب‌ها
استفاده از نسخه‌های پشتیبانی‌شده یکی از مهم‌ترین اقدامات کاهش ریسک است.
به‌روزرسانی‌ها باید با توجه به سازگاری و اهمیت امنیتی آن‌ها برنامه‌ریزی شوند.
در سایت‌های حساس، بهتر است تغییرات ابتدا در محیط آزمایشی بررسی شوند.
محافظت از حساب‌های مدیریتی
حساب‌های مدیر وردپرس باید از رمزهای عبور منحصربه‌فرد و احراز هویت دومرحله‌ای استفاده کنند.
همچنین باید مجوز کاربران بررسی شود تا افراد بیش از نیاز واقعی دسترسی نداشته باشند.
بررسی XML-RPC
XML-RPC یکی از رابط‌های ارتباطی وردپرس است.
اگر یک سایت یا سرویس متصل واقعاً به آن نیاز ندارد، می‌توان محدودسازی یا غیرفعال‌سازی آن را بررسی کرد.
اما نباید بدون شناخت وابستگی‌ها این قابلیت را حذف کرد، زیرا ممکن است برخی ابزارها به آن نیاز داشته باشند.
امنیت REST API
WordPress REST API بخشی از معماری وردپرس است و استفاده از آن به‌خودی‌خود ناامن نیست.
مسئله اصلی، کنترل صحیح مجوزها و محافظت از داده‌ها در Endpointهای مربوط است.
غیرفعال‌کردن کامل REST API معمولاً راهکار مناسبی برای تمام سایت‌ها نیست.
محافظت از فایل‌های پشتیبان
فایل‌های Backup و خروجی پایگاه داده نباید داخل مسیرهای عمومی وب بدون کنترل مناسب ذخیره شوند.
همچنین دسترسی به فایل‌های پیکربندی حساس باید محدود باشد.
محدودسازی ویرایش فایل از داشبورد
در محیط‌هایی که ویرایش مستقیم کد از پنل مدیریت ضرورتی ندارد، می‌توان قابلیت ویرایش فایل‌های افزونه و قالب را محدود کرد.
این اقدام به‌تنهایی مانع تمام تغییرات مخرب نمی‌شود، اما یکی از مسیرهای غیرضروری تغییر کد را کاهش می‌دهد.
کاهش سطح حمله APIها و سرویس‌های ارتباطی
APIها بخش مهمی از معماری وب‌سایت‌ها و اپلیکیشن‌های مدرن هستند.
هر Endpoint می‌تواند داده دریافت کند، عملیات اجرا کند یا اطلاعاتی را برگرداند.
بنابراین، APIها باید به‌عنوان دارایی‌های مهم در برنامه ASM ثبت شوند.
تهیه موجودی APIها
سازمان باید بداند چه APIهایی فعال هستند و هرکدام چه کاربردی دارند.
در این فهرست بهتر است مواردی مانند مالک، نسخه، روش احراز هویت، سطح دسترسی و نوع داده پردازش‌شده مشخص باشد.
وجود APIهای قدیمی و بدون مالک می‌تواند مدیریت امنیت را دشوار کند.
حذف نسخه‌های منسوخ
گاهی نسخه جدید API منتشر می‌شود، اما نسخه قدیمی همچنان فعال باقی می‌ماند.
این وضعیت ممکن است باعث شود منطق امنیتی و پشتیبانی چند نسخه به‌صورت هم‌زمان ادامه پیدا کند.
نسخه‌های قدیمی باید بر اساس برنامه مهاجرت مشخص کنار گذاشته شوند.
کنترل دسترسی به منابع
Broken Object Level Authorization یا BOLA یکی از مشکلات مهم امنیت API است.
این ضعف زمانی رخ می‌دهد که برنامه به‌درستی بررسی نکند آیا کاربر مجاز به دسترسی به یک منبع مشخص است یا خیر.
برای جلوگیری از آن، کنترل مجوز باید در سمت سرور و برای هر عملیات حساس اعمال شود.
محدودسازی مصرف منابع
Rate Limiting و کنترل مصرف منابع می‌توانند به کاهش خطر استفاده بیش‌ازحد از بعضی قابلیت‌های API کمک کنند.
البته محدودسازی نرخ درخواست جایگزین کنترل دسترسی و امنیت منطق تجاری نیست.
مدیریت کلیدهای API
کلیدهای API باید دارای حداقل مجوز، دوره اعتبار مناسب و امکان ابطال باشند.
همچنین نباید در کدهای عمومی یا فایل‌های قابل‌دسترسی کاربران قرار گیرند.
امنیت Webhookها
Webhookها برای ارتباط میان سرویس‌ها کاربرد دارند.
در این بخش باید اصالت پیام‌های دریافتی، مجوز عملیات و محدودیت‌های لازم بررسی شود.
برای نمونه، استفاده از امضای معتبر درخواست و کنترل شناسه‌های رویداد می‌تواند در طراحی ارتباط امن نقش داشته باشد.
کاهش سطح حمله زیرساخت ابری و Kubernetes
زیرساخت ابری به سازمان امکان می‌دهد منابع را سریع ایجاد کند.
اما همین سرعت ممکن است باعث افزایش دارایی‌های ثبت‌نشده شود.
مدیریت منابع عمومی در Cloud
ماشین‌های مجازی، Load Balancerها و پایگاه‌های داده باید از نظر دسترسی عمومی بررسی شوند.
بهتر است فقط منابعی در اینترنت منتشر شوند که واقعاً به دسترسی عمومی نیاز دارند.
محافظت از Object Storage
فضاهای ذخیره‌سازی ابری ممکن است شامل فایل‌های کاربران، نسخه‌های پشتیبان یا داده‌های حساس باشند.
مجوزهای عمومی باید فقط در صورت ضرورت و با بررسی دقیق فعال شوند.
همچنین سیاست‌های دسترسی سرویس‌ها باید بر اساس حداقل مجوز طراحی شوند.
مدیریت سطح حمله Kubernetes
در Kubernetes اجزایی مانند API Server، Ingress، Service، Pod و Worker Node بخشی از معماری امنیتی هستند.
برای کاهش سطح حمله باید کنترل دسترسی با RBAC، امنیت Pod، محافظت از Secrets و محدودسازی شبکه بررسی شود.
استفاده از NetworkPolicy
NetworkPolicy در Kubernetes برای محدودسازی ارتباطات Podها استفاده می‌شود.
این قابلیت می‌تواند به کاهش ارتباطات غیرضروری و محدودسازی حرکت جانبی کمک کند.
اجرای مؤثر آن به پشتیبانی افزونه شبکه کلاستر وابسته است.
امنیت Container Image
تصاویر کانتینری باید از منابع مورداعتماد دریافت شوند.
حذف ابزارهای غیرضروری از Image، اسکن آسیب‌پذیری و استفاده از نسخه‌های مشخص می‌تواند به کاهش سطح حمله کمک کند.
کنترل سرویس‌های مدیریتی
داشبوردهای Kubernetes، ابزارهای مدیریت Container و سرویس‌های مانیتورینگ نباید بدون ضرورت در اینترنت عمومی منتشر شوند.
دسترسی به آن‌ها باید از مسیرهای مدیریتی محافظت‌شده انجام شود.
مدیریت سطح حمله هویت و حساب‌های کاربری
حتی اگر تمام سرویس‌های شبکه ایمن باشند، اعتبارنامه‌های ضعیف یا افشاشده می‌توانند مسیر دسترسی غیرمجاز ایجاد کنند.
اجرای اصل Least Privilege
هر کاربر و سرویس باید فقط به منابع موردنیاز دسترسی داشته باشد.
مجوزهای مدیریتی گسترده نباید به‌صورت پیش‌فرض اختصاص داده شوند.
استفاده از احراز هویت چندعاملی
Multi-Factor Authentication یا MFA به استفاده از بیش از یک عامل برای احراز هویت اشاره دارد.
برای حساب‌های مدیریتی و سرویس‌های حساس، استفاده از MFA مقاوم در برابر فیشینگ در صورت امکان می‌تواند سطح حفاظت را افزایش دهد.
حذف حساب‌های بلااستفاده
حساب‌های کارکنان سابق، دسترسی‌های موقت و کاربران آزمایشی باید به‌صورت دوره‌ای بررسی شوند.
هر حساب فعال و غیرضروری، بخشی از سطح حمله هویتی سازمان محسوب می‌شود.
مدیریت Service Accountها
حساب‌های سرویس نیز باید دارای مجوز مشخص باشند.
استفاده از یک حساب مشترک با دسترسی گسترده برای چند برنامه می‌تواند دامنه خسارت را افزایش دهد.
کنترل نشست‌ها و توکن‌ها
مدیریت زمان اعتبار نشست‌ها، امکان ابطال توکن و محافظت از اطلاعات احراز هویت اهمیت زیادی دارد.
در برنامه‌های حساس، تغییر رمز عبور یا رخدادهای امنیتی مهم باید مطابق سیاست سازمان بر اعتبار نشست‌های فعال تأثیر بگذارند.
نقش امنیت زنجیره تأمین در Attack Surface Management
سطح حمله سازمان فقط شامل کدی نیست که تیم توسعه نوشته است.
وابستگی‌های نرم‌افزاری، ابزارهای ساخت و سرویس‌های خارجی نیز می‌توانند بخشی از مسیرهای خطر باشند.
شناسایی وابستگی‌های نرم‌افزاری
فهرست کتابخانه‌ها و بسته‌های مورد استفاده باید مشخص باشد.
Software Bill of Materials یا SBOM یکی از روش‌های ثبت اجزای نرم‌افزاری است.
وجود SBOM به‌تنهایی امنیت ایجاد نمی‌کند، اما می‌تواند شناسایی وابستگی‌های آسیب‌پذیر را آسان‌تر کند.
حذف کتابخانه‌های بدون استفاده
وابستگی‌های غیرضروری ممکن است حجم کد و هزینه نگهداری امنیتی را افزایش دهند.
حذف آن‌ها، در صورت سازگاری با برنامه، می‌تواند به کاهش سطح حمله کمک کند.
امنیت مخازن کد
مخازن Git باید از نظر مجوزهای دسترسی، اطلاعات محرمانه و حساب‌های متصل بررسی شوند.
قرارگرفتن کلیدهای API یا اعتبارنامه‌های واقعی در تاریخچه مخزن می‌تواند خطرناک باشد.
امنیت CI/CD
Pipelineهای ساخت و انتشار نرم‌افزار معمولاً به مخازن، سرورها و سرویس‌های ابری دسترسی دارند.
این دسترسی‌ها باید محدود و قابل‌ممیزی باشند.
بهتر است اعتبارنامه‌های موقت و سازوکارهای امن مدیریت Secret جایگزین کلیدهای ثابت و گسترده شوند.
مدیریت سطح حمله سرویس‌های شخص ثالث
بسیاری از سایت‌ها از خدمات خارجی استفاده می‌کنند.
درگاه پرداخت، سامانه ارسال پیامک، ابزار تحلیل رفتار کاربر، سرویس ایمیل و پلتفرم پشتیبانی نمونه‌هایی از این وابستگی‌ها هستند.
بررسی مجوزهای اتصال
هنگام اتصال یک سرویس خارجی باید مشخص شود به چه داده‌ها و عملیاتی دسترسی دارد.
برای مثال، ابزاری که فقط نیازمند خواندن آمار عمومی است، نباید مجوز مدیریت کاربران یا تغییر تنظیمات حساس را دریافت کند.
حذف اتصال‌های قدیمی
ممکن است یک ابزار تجاری دیگر استفاده نشود، اما توکن یا دسترسی آن همچنان فعال باشد.
قطع اتصال‌های بلااستفاده می‌تواند سطح حمله را کاهش دهد.
ارزیابی ریسک تأمین‌کنندگان
در سرویس‌های حساس، بهتر است وضعیت امنیتی تأمین‌کننده و مسئولیت‌های قراردادی بررسی شود.
همچنین باید مشخص باشد در صورت وقوع حادثه، چه کسی مسئول اطلاع‌رسانی و واکنش است.
محدودسازی اسکریپت‌های شخص ثالث
اسکریپت‌های خارجی که در صفحات وب بارگذاری می‌شوند، می‌توانند بر امنیت و حریم خصوصی کاربران تأثیر بگذارند.
استفاده از اسکریپت‌های ضروری، بررسی منشأ آن‌ها و تنظیم سیاست‌های امنیت محتوا از جمله کنترل‌های قابل‌بررسی هستند.
نقش DNS، CDN و WAF در کاهش سطح حمله
سه فناوری DNS، CDN و WAF در معماری بسیاری از سایت‌ها حضور دارند.
هرکدام می‌توانند در مدیریت سطح حمله نقش داشته باشند، اما کاربرد یکسانی ندارند.
مدیریت امن DNS
رکوردهای DNS باید به‌صورت منظم بررسی شوند.
رکوردهای قدیمی یا اشاره‌کننده به سرویس‌های حذف‌شده ممکن است باعث سردرگمی یا در بعضی شرایط ایجاد خطرات امنیتی شوند.
همچنین دسترسی به پنل مدیریت DNS باید محدود و محافظت شود.
بررسی خطر Subdomain Takeover
در بعضی شرایط، رکورد DNS به یک سرویس خارجی اشاره می‌کند که دیگر به‌درستی به سازمان اختصاص ندارد.
این نوع پیکربندی ممکن است در صورت وجود شرایط فنی خاص، خطر تصاحب زیردامنه یا Subdomain Takeover ایجاد کند.
راهکار دفاعی، بررسی مالکیت منابع، حذف رکوردهای بلااستفاده و مدیریت صحیح چرخه عمر سرویس‌ها است.
استفاده از CDN
Content Delivery Network یا CDN می‌تواند توزیع محتوا و مدیریت ترافیک را بهبود دهد.
برخی ارائه‌دهندگان CDN قابلیت‌های محافظتی مانند کنترل ترافیک و مقابله با بعضی حملات را نیز ارائه می‌کنند.
اما استفاده از CDN به‌تنهایی به معنای محافظت کامل از سرور اصلی نیست.
جلوگیری از دسترسی مستقیم ناخواسته به Origin
اگر معماری به‌گونه‌ای طراحی شده که ترافیک عمومی باید از CDN یا Reverse Proxy عبور کند، دسترسی مستقیم به سرور Origin باید متناسب با این طراحی محدود شود.
در غیر این صورت ممکن است بعضی کنترل‌های مستقر در لایه واسط دور زده شوند.
نقش WAF
WAF در کاهش خطر برخی حملات لایه کاربرد مؤثر است.
اما نمی‌تواند تمام خطاهای منطقی، مجوزهای نامناسب یا آسیب‌پذیری‌های زیرساختی را برطرف کند.
بهترین نتیجه زمانی حاصل می‌شود که WAF با ایمن‌سازی برنامه و سرور ترکیب شود.
نقش مدیریت آسیب‌پذیری در کاهش سطح حمله
Attack Surface Management و Vulnerability Management دو فرایند مرتبط اما متفاوت هستند.
ASM مشخص می‌کند چه دارایی‌ها و مسیرهایی وجود دارند.
مدیریت آسیب‌پذیری بررسی می‌کند کدام ضعف‌های امنیتی باید اصلاح شوند.
اسکن دوره‌ای دارایی‌های مجاز
اسکن امنیتی می‌تواند به شناسایی نرم‌افزارهای قدیمی، پیکربندی‌های ناامن و آسیب‌پذیری‌های شناخته‌شده کمک کند.
این فعالیت باید فقط در محدوده دارای مجوز انجام شود.
همچنین لازم است روش بررسی متناسب با حساسیت سرویس انتخاب شود تا اختلال غیرضروری ایجاد نشود.
اولویت‌بندی اصلاحات
بهتر است اصلاح آسیب‌پذیری‌ها بر اساس اهمیت دارایی، قابلیت سوءاستفاده و شواهد تهدید انجام شود.
صرفاً تعداد زیاد یافته‌ها نباید معیار اصلی موفقیت یا شکست برنامه امنیتی باشد.
استفاده از کنترل‌های جبرانی
گاهی نصب وصله فوری امکان‌پذیر نیست.
در چنین شرایطی، محدودسازی دسترسی، جداسازی شبکه یا غیرفعال‌سازی موقت قابلیت آسیب‌پذیر می‌تواند به کاهش ریسک کمک کند.
این اقدامات معمولاً جایگزین دائمی اصلاح علت اصلی نیستند.
بررسی مجدد پس از اصلاح
بسته‌شدن یک تیکت امنیتی لزوماً به معنای برطرف‌شدن واقعی مشکل نیست.
باید بررسی شود که تغییر موردنظر اجرا شده و مسیر خطرناک دیگر وجود ندارد یا به‌شکل مؤثر کنترل شده است.
مانیتورینگ مداوم سطح حمله
یکی از تفاوت‌های اصلی ASM با ارزیابی امنیتی مقطعی، توجه به تغییرات مستمر است.
ممکن است امروز یک زیرساخت وضعیت مناسبی داشته باشد، اما فردا با انتشار سرویس جدید در معرض خطر قرار گیرد.
پایش ایجاد زیردامنه‌های جدید
اضافه‌شدن زیردامنه جدید باید در فرایند مدیریت دارایی ثبت شود.
این تغییر ممکن است کاملاً مجاز باشد، اما لازم است مالک و هدف آن مشخص شود.
شناسایی تغییرات دسترسی عمومی
انتشار ناخواسته یک سرویس داخلی یا تغییر قوانین فایروال می‌تواند سطح حمله را افزایش دهد.
پایش تنظیمات شبکه و منابع ابری برای شناسایی این تغییرات اهمیت دارد.
پایش اعتبار گواهی‌های TLS
گواهی‌های دیجیتال باید از نظر اعتبار، انقضا و ارتباط با سرویس‌های سازمان بررسی شوند.
وجود گواهی قدیمی الزاماً به معنای فعال‌بودن سرویس نیست، اما می‌تواند سرنخی برای بررسی دارایی‌های فراموش‌شده باشد.
مانیتورینگ تغییرات مجوز
ایجاد حساب مدیریتی جدید یا افزایش مجوز یک سرویس باید قابل‌ردیابی باشد.
در محیط‌های حساس، چنین تغییراتی می‌توانند نیازمند هشدار و بررسی باشند.
ثبت رویدادهای امنیتی
Log Management و SIEM می‌توانند به تجمیع رویدادها و تحلیل فعالیت‌های مشکوک کمک کنند.
بااین‌حال، ثبت حجم زیاد گزارش بدون سیاست نگهداری، اولویت‌بندی و بررسی هشدارها ارزش عملی محدودی دارد.
خودکارسازی Attack Surface Management در DevSecOps
در سازمان‌هایی که سرویس‌ها دائماً تغییر می‌کنند، مدیریت کاملاً دستی سطح حمله ممکن است کافی نباشد.
DevSecOps تلاش می‌کند کنترل‌های امنیتی را در چرخه توسعه و عملیات نرم‌افزار ادغام کند.
بررسی امنیت پیش از انتشار
پیش از انتشار یک قابلیت جدید بهتر است مشخص شود آیا Endpoint عمومی، مجوز جدید یا ارتباط شبکه‌ای تازه ایجاد می‌شود.
در صورت افزایش سطح حمله، کنترل‌های امنیتی متناسب باید پیش از انتشار بررسی شوند.
استفاده از Infrastructure as Code
Infrastructure as Code یا IaC به مدیریت تنظیمات زیرساخت با فایل‌های نسخه‌بندی‌شده اشاره دارد.
این رویکرد می‌تواند تغییرات را قابل‌بررسی و تکرارپذیر کند.
همچنین ابزارهای بررسی پیکربندی می‌توانند بعضی تنظیمات ناامن را پیش از استقرار شناسایی کنند.
سیاست‌های خودکار امنیتی
در بعضی زیرساخت‌ها می‌توان سیاست‌هایی تعریف کرد که ایجاد منابع عمومی غیرمجاز یا دسترسی‌های بیش‌ازحد را محدود کنند.
چنین کنترل‌هایی باید بر اساس نیاز سازمان طراحی شوند و از نظر سازگاری عملیاتی آزمایش شوند.
پیوند ASM با مدیریت تغییر
هر تغییر مهم در معماری زیرساخت باید از منظر سطح حمله بررسی شود.
برای مثال، اضافه‌کردن یک Load Balancer جدید ممکن است مسیرهای ارتباطی تازه‌ای ایجاد کند.
در نتیجه، مدیریت تغییر و ASM باید اطلاعات یکدیگر را تکمیل کنند.
نمونه عملی: کاهش سطح حمله یک فروشگاه اینترنتی
فرض کنیم یک فروشگاه اینترنتی از وردپرس و ووکامرس استفاده می‌کند.
زیرساخت شامل سرور اصلی، پایگاه داده، CDN، پنل هاست، سامانه پیامک و یک API اختصاصی است.
وضعیت اولیه
بررسی دارایی‌های متعلق به فروشگاه نشان می‌دهد:
- یک زیردامنه آزمایشی قدیمی همچنان فعال است.
- پنل مدیریت سرور از اینترنت عمومی قابل‌دسترسی است.
- چند حساب مدیریتی بلااستفاده وجود دارد.
- یک افزونه قدیمی دیگر موردنیاز نیست.
- کلید API سرویس قدیمی پیامک همچنان معتبر است.
- نسخه پشتیبان سایت در محل مناسبی نگهداری نمی‌شود.
- دسترسی مستقیم به Origin برخلاف طراحی CDN امکان‌پذیر است.
هیچ‌کدام از این یافته‌ها به‌تنهایی وقوع نفوذ را اثبات نمی‌کنند.
اما مجموع آن‌ها نشان می‌دهد سطح حمله فروشگاه بیش از نیاز واقعی است.
مرحله اول: شناسایی و ثبت
ابتدا تمام دارایی‌ها ثبت می‌شوند.
برای هر دامنه، سرور و سرویس خارجی، مالک و کاربرد مشخص می‌شود.
مرحله دوم: حذف دارایی‌های غیرضروری
پس از بررسی وابستگی‌ها، زیردامنه آزمایشی بلااستفاده حذف می‌شود.
افزونه قدیمی نیز پس از اطمینان از عدم نیاز عملیاتی کنار گذاشته می‌شود.
مرحله سوم: محدودسازی دسترسی
دسترسی به پنل مدیریتی از مسیر محافظت‌شده انجام می‌شود.
همچنین ارتباط مستقیم با Origin بر اساس معماری شبکه محدود می‌شود.
مرحله چهارم: اصلاح دسترسی‌های هویتی
حساب‌های بلااستفاده حذف یا غیرفعال می‌شوند.
کلیدهای API قدیمی باطل می‌شوند و مجوز سرویس‌های فعال مورد بازبینی قرار می‌گیرد.
مرحله پنجم: حفاظت از داده‌ها
نسخه‌های پشتیبان به فضای محافظت‌شده منتقل می‌شوند.
همچنین سیاست نگهداری و آزمایش بازیابی اطلاعات مشخص می‌شود.
نتیجه امنیتی
پس از این اصلاحات، مسیرهای دسترسی غیرضروری کاهش پیدا می‌کنند.
اما امنیت فروشگاه همچنان به به‌روزرسانی نرم‌افزارها، پایش مداوم و بررسی ضعف‌های منطقی برنامه وابسته است.
این مثال نشان می‌دهد هدف ASM فقط کشف مشکلات نیست؛ بلکه باید به کاهش قابل‌اندازه‌گیری مواجهه امنیتی منجر شود.
نمونه مقایسه‌ای: زیرساخت بدون ASM و زیرساخت دارای ASM
| معیار | بدون مدیریت سطح حمله | با مدیریت سطح حمله |
|---|---|---|
| فهرست دارایی‌ها | پراکنده و احتمالاً ناقص | مستمر و دارای مسئول مشخص |
| زیردامنه‌های قدیمی | ممکن است فراموش شوند | شناسایی و تعیین تکلیف می‌شوند |
| سرویس‌های عمومی | بررسی موردی | پایش و ارزیابی مستمر |
| مجوزهای کاربران | احتمال انباشت دسترسی | بازبینی دوره‌ای |
| مدیریت آسیب‌پذیری | متکی به دارایی‌های شناخته‌شده | مرتبط با کشف و اهمیت دارایی |
| تغییرات زیرساخت | ممکن است بدون ارزیابی امنیتی انجام شوند | در فرایند مدیریت تغییر بررسی می‌شوند |
| اولویت‌بندی اصلاحات | اغلب مبتنی بر شدت فنی | مبتنی بر ریسک و شرایط محیطی |
| گزارش مدیریتی | محدود به ابزارهای جداگانه | متمرکز بر وضعیت مواجهه امنیتی |
این مقایسه یک الگوی مطلوب مدیریتی را نشان می‌دهد و به معنای تضمین امنیت در صورت استفاده از ASM نیست. 
چگونه یک برنامه ۳۰، ۶۰ و ۹۰ روزه برای کاهش سطح حمله طراحی کنیم؟
برای سازمان‌هایی که هنوز برنامه رسمی ASM ندارند، اجرای مرحله‌ای می‌تواند انتخاب مناسبی باشد.
۳۰ روز اول: شناخت وضعیت موجود
در ماه اول تمرکز باید بر شناسایی دارایی‌ها و تعیین مالکیت باشد.
اقدامات پیشنهادی:
- تعیین دامنه مسئولیت برنامه ASM
- تهیه فهرست دامنه‌ها، زیردامنه‌ها و IPهای متعلق به سازمان
- استخراج فهرست منابع ابری و سرورها
- شناسایی سرویس‌های مدیریتی و عمومی
- تعیین مالک فنی هر دارایی
- شناسایی دارایی‌های فراموش‌شده یا بدون مالک
- تهیه نقشه اولیه ارتباطات
- ثبت ریسک‌های مهم و فوری
در پایان این مرحله، سازمان باید تصویر اولیه‌ای از سطح حمله داشته باشد.
روزهای ۳۱ تا ۶۰: کاهش ریسک‌های مهم
در مرحله دوم، تمرکز بر اصلاح موارد اولویت‌دار قرار می‌گیرد.
اقدامات مهم عبارت‌اند از:
- حذف یا غیرفعال‌سازی سرویس‌های بلااستفاده
- محدودسازی دسترسی به پنل‌های مدیریتی
- اصلاح قوانین فایروال
- حذف حساب‌ها و اعتبارنامه‌های غیرضروری
- رفع آسیب‌پذیری‌های مهم و قابل‌سوءاستفاده
- بررسی دسترسی عمومی منابع ابری
- محافظت از نسخه‌های پشتیبان
- بازبینی امنیت APIهای حساس
این اصلاحات باید با مدیریت تغییر و برنامه بازگشت در صورت اختلال همراه باشند.
روزهای ۶۱ تا ۹۰: خودکارسازی و پایش
در مرحله سوم، برنامه ASM از یک پروژه مقطعی به فرایندی مستمر تبدیل می‌شود.
اقدامات پیشنهادی:
- تعیین چرخه بازبینی موجودی دارایی‌ها
- اتصال یافته‌های امنیتی به سامانه ثبت وظایف
- تعریف هشدار برای تغییرات حساس
- ایجاد فرایند ثبت دارایی جدید
- تعریف شاخص‌های ارزیابی عملکرد
- تعیین زمان‌بندی بازبینی دسترسی‌ها
- مستندسازی مراحل پاسخ به یافته‌های مهم
- ارائه گزارش مدیریتی از روند کاهش ریسک
برنامه ۹۰ روزه یک الگوی اجرایی است و زمان واقعی آن به اندازه و پیچیدگی زیرساخت بستگی دارد.
مهم‌ترین شاخص‌های اندازه‌گیری موفقیت ASM
مدیریت سطح حمله باید با شاخص‌های قابل‌اندازه‌گیری همراه باشد.
اما صرفاً کاهش تعداد دارایی‌ها همیشه نشانه بهبود امنیت نیست.
ممکن است سازمان به دلیل نیاز تجاری، سرویس‌های جدید و ضروری اضافه کند.
موضوع اصلی، مدیریت صحیح ریسک آن‌ها است.
درصد دارایی‌های دارای مالک مشخص
این شاخص نشان می‌دهد چه سهمی از دارایی‌ها مسئول فنی یا کسب‌وکاری مشخص دارند.
افزایش پوشش مالکیت می‌تواند به بهبود پاسخ‌گویی کمک کند.
زمان شناسایی دارایی جدید
هرچه فاصله ایجاد یک دارایی تا ثبت آن در موجودی کمتر باشد، احتمال باقی‌ماندن طولانی‌مدت دارایی ناشناخته کاهش می‌یابد.
زمان اصلاح مواجهه‌های پرخطر
Mean Time to Remediate یا MTTR در این زمینه می‌تواند مدت متوسط اصلاح مشکلات مشخص را نشان دهد.
برای تحلیل درست باید نوع و شدت مشکلات نیز در نظر گرفته شود.
تعداد دارایی‌های اینترنتی بدون تأیید
این شاخص به شناسایی دارایی‌هایی کمک می‌کند که مالکیت، ضرورت یا وضعیت امنیتی آن‌ها مشخص نیست.
درصد پوشش ارزیابی امنیتی
سازمان باید بداند چه سهمی از دارایی‌های مهم با روش مناسب ارزیابی شده‌اند.
تعداد دسترسی‌های غیرضروری اصلاح‌شده
کاهش حساب‌های بلااستفاده، مجوزهای اضافی و ارتباطات شبکه‌ای غیرضروری می‌تواند بخشی از روند کاهش سطح حمله را نشان دهد.
روند ریسک باقی‌مانده
مهم‌ترین شاخص نهایی، تغییر میزان مواجهه با خطر در طول زمان است.
بهتر است این روند بر اساس اهمیت دارایی‌ها و کیفیت کنترل‌های دفاعی تحلیل شود، نه فقط تعداد هشدارها.
مهم‌ترین اشتباهات رایج در Attack Surface Management
تمرکز فقط بر سایت اصلی
بعضی سازمان‌ها تمام توجه خود را به دامنه اصلی معطوف می‌کنند.
درحالی‌که زیردامنه‌ها، APIها و سرویس‌های جانبی نیز می‌توانند بخشی از سطح حمله باشند.
فرض اینکه هر دارایی کشف‌شده آسیب‌پذیر است
وجود یک سرویس عمومی به معنای ناامن‌بودن آن نیست.
باید بین قابلیت دسترسی، ضعف امنیتی و خطر واقعی تفاوت قائل شد.
استفاده از ابزار بدون فرایند اصلاح
تهیه فهرست بزرگی از مشکلات بدون تعیین مسئول و زمان اصلاح، ارزش عملی محدودی دارد.
مدیریت سطح حمله باید به اقدام قابل‌پیگیری منجر شود.
حذف عجولانه سرویس‌ها
غیرفعال‌کردن یک سرویس بدون بررسی وابستگی‌ها ممکن است باعث اختلال در بخش‌های دیگر شود.
پیش از حذف دارایی باید کاربرد، مالک و اثرات احتمالی آن مشخص شود.
نادیده‌گرفتن سرویس‌های ابری
ممکن است تیم امنیت فقط سرورهای سنتی را بررسی کند، درحالی‌که منابع ابری خارج از همان فهرست مدیریت می‌شوند.
برنامه ASM باید تمام محیط‌های مرتبط را پوشش دهد.
اعتماد بیش‌ازحد به فایروال
فایروال نمی‌تواند تمام آسیب‌پذیری‌های برنامه یا مشکلات مجوز دسترسی را برطرف کند.
امنیت نیازمند کنترل‌های چندلایه است.
انجام ASM فقط یک‌بار
سطح حمله با تغییر نرم‌افزار، زیرساخت و فعالیت سازمان تغییر می‌کند.
بنابراین، بررسی یک‌باره به‌تنهایی کافی نیست.
نبود معیار برای اولویت‌بندی
اگر تمام یافته‌ها با اولویت یکسان ثبت شوند، تیم امنیت ممکن است زمان زیادی را صرف مشکلات کم‌اهمیت کند.
نداشتن مالک برای یافته‌ها
هر یافته باید به تیم یا شخص مسئول ارجاع داده شود.
بدون مسئولیت مشخص، احتمال باقی‌ماندن مشکلات برای مدت طولانی افزایش می‌یابد.
فراموش‌کردن اعتبارسنجی اصلاحات
پس از اعمال تغییر، باید بررسی شود که مشکل واقعاً برطرف شده است.
برای مثال، حذف یک رکورد DNS بدون بررسی سرویس مرتبط ممکن است تمام جنبه‌های خطر را حل نکند.
چک‌لیست جامع کاهش سطح حمله سایت و زیرساخت
برای بررسی اولیه وضعیت امنیت، می‌توان این چک‌لیست را استفاده کرد.
شناسایی دارایی‌ها
- تمام دامنه‌ها و زیردامنه‌های سازمان ثبت شده باشند.
- IPهای عمومی و منابع ابری شناسایی شده باشند.
- هر دارایی مالک مشخص داشته باشد.
- محیط‌های آزمایشی و قدیمی بررسی شده باشند.
- فهرست دارایی‌ها به‌صورت دوره‌ای به‌روزرسانی شود.
امنیت شبکه و سرور
- پورت‌ها و سرویس‌های غیرضروری محدود شده باشند.
- قوانین فایروال بر اساس نیاز واقعی تعریف شده باشند.
- دسترسی مدیریتی از مسیرهای امن انجام شود.
- سرویس‌های قدیمی و بدون پشتیبانی تعیین تکلیف شده باشند.
- ارتباطات داخلی حساس محدود شده باشند.
امنیت برنامه و API
- مسیرهای مدیریتی محافظت شده باشند.
- کنترل دسترسی در سمت سرور اعمال شود.
- ورودی‌های غیرقابل‌اعتماد اعتبارسنجی شوند.
- APIهای قدیمی و بلااستفاده حذف یا محدود شوند.
- وابستگی‌های نرم‌افزاری بررسی شوند.
- پیام‌های خطا اطلاعات حساس افشا نکنند.
امنیت هویت
- حساب‌های مدیریتی از MFA استفاده کنند.
- حساب‌های بلااستفاده حذف شوند.
- مجوزها بر اساس اصل حداقل دسترسی باشند.
- کلیدهای API به‌صورت امن مدیریت شوند.
- دسترسی سرویس‌های شخص ثالث بررسی شود.
امنیت داده و زیرساخت
- نسخه‌های پشتیبان محافظت شوند.
- منابع ذخیره‌سازی حساس به‌صورت ناخواسته عمومی نباشند.
- دسترسی به پایگاه داده محدود باشد.
- Secrets در مخازن کد ذخیره نشوند.
- ارتباطات حساس از رمزنگاری مناسب استفاده کنند.
پایش و مدیریت
- تغییرات سطح حمله پایش شوند.
- یافته‌های مهم دارای اولویت مشخص باشند.
- مسئول اصلاح هر یافته تعیین شود.
- اثربخشی اصلاحات بررسی شود.
- گزارش مدیریتی از روند کاهش ریسک تهیه شود.
این چک‌لیست باید متناسب با ساختار واقعی سازمان تکمیل شود.
سؤالات متداول درباره Attack Surface Management
Attack Surface Management چیست؟
Attack Surface Management یا مدیریت سطح حمله فرایندی مستمر برای شناسایی، ارزیابی و کاهش نقاطی است که امکان دسترسی یا سوءاستفاده از سیستم‌های سازمان را فراهم می‌کنند. این فرایند شامل مدیریت دارایی‌ها، شناسایی مواجهه‌های امنیتی، اولویت‌بندی ریسک و اصلاح مسیرهای غیرضروری است.
تفاوت Attack Surface و Vulnerability چیست؟
Attack Surface مجموعه مسیرها و نقاط تعامل با سیستم است، درحالی‌که Vulnerability به یک ضعف امنیتی مشخص اشاره دارد. هر نقطه سطح حمله الزاماً آسیب‌پذیر نیست، اما می‌تواند نیازمند کنترل و بررسی امنیتی باشد.
آیا ASM فقط برای شرکت‌های بزرگ ضروری است؟
خیر. حتی یک سایت کوچک ممکن است چندین زیردامنه، افزونه، API و سرویس جانبی داشته باشد. در چنین شرایطی، تهیه موجودی دارایی‌ها و حذف دسترسی‌های غیرضروری می‌تواند به کاهش ریسک کمک کند.
آیا با نصب فایروال می‌توان سطح حمله را کاهش داد؟
فایروال می‌تواند دسترسی شبکه‌ای غیرضروری را محدود کند، اما تمام مشکلات امنیتی را برطرف نمی‌کند. کاهش سطح حمله به مدیریت سرویس‌ها، مجوزها، برنامه‌ها و داده‌ها نیز نیاز دارد.
EASM چیست؟
External Attack Surface Management زیرمجموعه‌ای از ASM است که بر شناسایی و کاهش خطرات دارایی‌های قابل‌دسترسی از اینترنت تمرکز دارد. دامنه‌ها، سرویس‌های عمومی و منابع ابری اینترنتی از جمله موضوعات مهم آن هستند.
آیا مدیریت سطح حمله جایگزین تست نفوذ است؟
خیر. ASM برای شناخت و مدیریت مستمر سطح حمله استفاده می‌شود، درحالی‌که تست نفوذ مقاومت سیستم را در سناریوهای مشخص و مجاز ارزیابی می‌کند. این دو روش مکمل یکدیگر هستند.
مهم‌ترین راه کاهش سطح حمله سایت چیست؟
شناسایی تمام دارایی‌ها، حذف سرویس‌های غیرضروری، محدودسازی دسترسی مدیریتی، به‌روزرسانی نرم‌افزارها و اجرای اصل حداقل دسترسی از مهم‌ترین اقدامات هستند. اولویت دقیق به معماری و ریسک سایت بستگی دارد.
آیا استفاده از CDN سطح حمله را حذف می‌کند؟
خیر. CDN ممکن است بعضی کنترل‌های حفاظتی و مدیریت ترافیک را فراهم کند، اما سایر اجزای زیرساخت همچنان نیازمند محافظت هستند. دسترسی مستقیم ناخواسته به Origin نیز باید بررسی شود.
Shadow IT چه ارتباطی با ASM دارد؟
Shadow IT به استفاده از فناوری‌ها یا سرویس‌هایی گفته می‌شود که خارج از فرایندهای رسمی مدیریت فناوری اطلاعات سازمان ایجاد یا استفاده شده‌اند. این دارایی‌ها ممکن است در فهرست امنیتی وجود نداشته باشند و ASM می‌تواند به شناسایی و تعیین تکلیف آن‌ها کمک کند.
آیا تعداد کمتر پورت باز همیشه به معنای امنیت بیشتر است؟
خیر. کاهش سرویس‌های غیرضروری معمولاً مفید است، اما تعداد پورت‌ها به‌تنهایی معیار کاملی برای امنیت نیست. نوع سرویس، سطح دسترسی، پیکربندی و اهمیت داده‌ها نیز باید بررسی شوند.
هر چند وقت یک‌بار باید سطح حمله بررسی شود؟
بهتر است شناسایی تغییرات مهم تا حد امکان به‌صورت مستمر انجام شود. بازبینی‌های دوره‌ای نیز باید بر اساس حساسیت زیرساخت و سرعت تغییرات سازمان برنامه‌ریزی شوند.
آیا ASM از حملات Zero-Day جلوگیری می‌کند؟
ASM نمی‌تواند تمام حملات Zero-Day را متوقف کند. بااین‌حال، کاهش سرویس‌های غیرضروری، محدودسازی دسترسی‌ها و جداسازی شبکه می‌تواند بعضی مسیرهای حمله را حذف کند یا دامنه خسارت احتمالی را کاهش دهد.
آیا مدیریت سطح حمله روی عملکرد سایت تأثیر دارد؟
بعضی تغییرات مانند محدودسازی ارتباطات یا اعمال کنترل‌های جدید ممکن است بر رفتار برنامه اثر بگذارند. بنابراین، اصلاحات باید با آزمایش، پایش و برنامه بازگشت انجام شوند. هدف، افزایش امنیت بدون ایجاد اختلال غیرضروری است.
چه کسی مسئول مدیریت سطح حمله در سازمان است؟
معمولاً مسئولیت میان تیم امنیت، زیرساخت، عملیات و توسعه تقسیم می‌شود. بااین‌حال، بهتر است مالک اصلی برنامه ASM و مسئول اصلاح هر یافته به‌صورت مشخص تعیین شوند.
جمع‌بندی: چگونه سطح حمله سایت و زیرساخت را به حداقل برسانیم؟
Attack Surface Management یکی از رویکردهای مهم برای مدیریت امنیت زیرساخت‌های مدرن است.
در شرایطی که سازمان‌ها از وب‌سایت‌ها، سرورها، سرویس‌های ابری، APIها و نرم‌افزارهای متعدد استفاده می‌کنند، شناخت تمام نقاط دسترسی به یک ضرورت عملیاتی تبدیل شده است.
مهم‌ترین اصل در مدیریت سطح حمله این است که امنیت فقط با محافظت از دارایی‌های شناخته‌شده تأمین نمی‌شود.
دارایی‌های فراموش‌شده، سرویس‌های قدیمی، حساب‌های بلااستفاده و ارتباطات غیرضروری نیز باید شناسایی و تعیین تکلیف شوند.
برای کاهش سطح حمله، ابتدا باید فهرست جامعی از دارایی‌های دیجیتال تهیه شود.
سپس نقاط دسترسی، ارتباطات بین سرویس‌ها و اهمیت هر دارایی بررسی شود.
در مرحله بعد، خطرات بر اساس احتمال سوءاستفاده و میزان خسارت احتمالی اولویت‌بندی شوند.
حذف سرویس‌های بلااستفاده، محدودسازی پورت‌ها، محافظت از پنل‌های مدیریتی، به‌روزرسانی نرم‌افزارها، مدیریت امن APIها و اجرای اصل حداقل دسترسی از مهم‌ترین اقدامات اصلاحی هستند.
همچنین استفاده از WAF، کنترل‌های امنیت شبکه، مدیریت Secrets و پایش رویدادها می‌تواند لایه‌های دفاعی بیشتری ایجاد کند.
اما هیچ‌کدام از این اقدامات نباید به‌صورت جداگانه و بدون شناخت معماری انجام شوند.
هدف نهایی Attack Surface Management این نیست که تمام نقاط دسترسی حذف شوند؛ بلکه باید تعداد و خطر مسیرهای غیرضروری کاهش یابد و مسیرهای ضروری نیز به‌درستی محافظت شوند.
در نهایت، مدیریت سطح حمله یک پروژه یک‌باره نیست.
هر تغییر در سایت، انتشار نرم‌افزار جدید، اضافه‌شدن سرویس ابری یا ایجاد حساب مدیریتی می‌تواند وضعیت مواجهه امنیتی را تغییر دهد.
بنابراین، یک برنامه موفق ASM باید شامل شناسایی مستمر، ارزیابی ریسک، اصلاح مشکلات، اعتبارسنجی اقدامات و پایش تغییرات باشد.
سازمانی که سطح حمله خود را به‌درستی می‌شناسد، می‌تواند منابع امنیتی را هدفمندتر تخصیص دهد، احتمال نفوذ از مسیرهای فراموش‌شده را کاهش دهد و در برابر تغییرات و تهدیدهای جدید آمادگی بیشتری داشته باشد.
