زیرساخت‌های فراموش‌شده IT: تهدید خاموشی که از Shadow IT هم خطرناک‌تر است

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

این‌ها بخش‌هایی از زیرساخت IT سازمانی هستند که گاهی از رادار تیم‌های IT و امنیت خارج می‌شوند. در واقع، این دارایی‌ها تبدیل به موجوداتی مدیریت‌نشده، بی‌فایده و صرفاً فراموش‌شده می‌شوند. این زامبی‌های IT ریسک‌هایی برای امنیت اطلاعات و انطباق با مقررات ایجاد می‌کنند و هزینه‌های عملیاتی غیرضروری به بار می‌آورند. این موضوع معمولاً زیرمجموعه‌ای از Shadow IT محسوب می‌شود، با یک تفاوت کلیدی: هیچ‌کس این دارایی‌ها را نمی‌خواهد، از وجودشان خبر ندارد و سودی از آن‌ها نمی‌برد. در این مقاله تلاش می‌کنیم مشخص کنیم کدام دارایی‌ها نیاز به توجه فوری دارند، چگونه باید آن‌ها را شناسایی کرد و واکنش مناسب چه شکلی است.

سرورهای فیزیکی و مجازی: دروازه‌های ورود مهاجمان

اولویت: بالا. سرورهای آسیب‌پذیر نقاط ورود حملات سایبری هستند و همچنان منابع را مصرف می‌کنند در حالی که ریسک‌های انطباق با مقررات ایجاد می‌کنند.

شیوع: بالا. سرورهای فیزیکی و مجازی معمولاً در زیرساخت‌های بزرگ پس از پروژه‌های مهاجرت یا ادغام و تملک شرکت‌ها رها می‌شوند. سرورهای تست که پس از اجرای پروژه‌های IT دیگر استفاده نمی‌شوند، و همچنین وب‌سرورهای پروژه‌های منسوخ که بدون دامنه فعال هستند، اغلب به فراموشی سپرده می‌شوند.

مقیاس این مشکل را آمار Let’s Encrypt نشان می‌دهد: در سال ۲۰۲۴، نیمی از درخواست‌های تمدید دامنه از دستگاه‌هایی آمده که دیگر با دامنه درخواست‌شده مرتبط نیستند. تقریباً یک میلیون از این دستگاه‌ها در سراسر جهان وجود دارند.

چگونه این سرورها را شناسایی کنیم؟

بخش IT باید فرایند Automated Discovery and Reconciliation یا AD&R را پیاده‌سازی کند. این فرایند نتایج اسکن شبکه و فهرست‌برداری ابری را با داده‌های پایگاه داده مدیریت پیکربندی (CMDB) ترکیب می‌کند و امکان شناسایی به‌موقع اطلاعات قدیمی یا متناقض درباره دارایی‌های IT را فراهم می‌سازد و به یافتن خود دارایی‌های فراموش‌شده کمک می‌کند.

این داده‌ها باید با اسکن‌های آسیب‌پذیری خارجی که تمام IPهای عمومی سازمان را پوشش می‌دهند، تکمیل شوند.

واکنش صحیح چیست؟

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

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

 

اکانت‌های فراموش‌شده: هدف اصلی مهاجمان برای ماندگاری در شبکه

اولویت: بحرانی. اکانت‌های غیرفعال و دارای دسترسی بالا اهداف اصلی مهاجمانی هستند که به دنبال ایجاد پایداری در شبکه یا گسترش دسترسی خود در زیرساخت هستند.

شیوع: بسیار بالا. اکانت‌های سرویس فنی، اکانت‌های پیمانکاران و اکانت‌های غیرشخصی از رایج‌ترین اکانت‌های فراموش‌شده هستند.

روش‌های شناسایی

تحلیل منظم دایرکتوری کاربران (Active Directory در اکثر سازمان‌ها) انجام دهید تا انواع اکانت‌هایی که در دوره مشخصی (یک ماه، سه‌ماهه یا یک‌ساله) فعالیتی نداشته‌اند شناسایی شوند. همزمان، توصیه می‌شود مجوزهای اختصاص‌داده‌شده به هر اکانت بررسی شوند و هر مجوز اضافی یا غیرضروری حذف شود.

واکنش مناسب

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

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

 

محل‌های ذخیره‌سازی داده فراموش‌شده: منبع اصلی نقض‌های بزرگ ۲۰۲۴-۲۰۲۵

اولویت: بحرانی. داده‌های کنترل‌نشده در پایگاه‌های داده قابل‌دسترسی از خارج، فضاهای ذخیره‌سازی ابری و سطل‌های بازیافت، و سرویس‌های اشتراک‌گذاری فایل سازمانی—حتی سرویس‌های «امن»—منبع کلیدی نقض‌های بزرگ در سال‌های ۲۰۲۴-۲۰۲۵ بوده‌اند. داده‌های افشاشده در این نشت‌ها اغلب شامل اسکن اسناد، پرونده‌های پزشکی و اطلاعات شخصی هستند. در نتیجه، این رخدادهای امنیتی به جریمه‌هایی برای عدم انطباق با مقرراتی مانند HIPAA، GDPR و سایر چارچوب‌های حفاظت از داده منجر می‌شوند.

شیوع: بالا. داده‌های آرشیوی، کپی‌های داده نزد پیمانکاران، نسخه‌های قدیمی پایگاه‌های داده از مهاجرت‌های سیستمی قبلی—همه این‌ها اغلب سال‌ها (حتی دهه‌ها) در بسیاری از سازمان‌ها بدون ثبت و قابل‌دسترسی باقی می‌مانند.

ابزارهای شناسایی

با توجه به تنوع گسترده انواع داده و روش‌های ذخیره‌سازی، ترکیبی از ابزارها برای کشف ضروری است:

  • زیرسیستم‌های ممیزی بومی در پلتفرم‌های فروشندگان اصلی، مانند AWS Macie و Microsoft Purview
  • راه‌حل‌های تخصصی Data Discovery و Data Security Posture Management
  • تحلیل خودکار لاگ‌های فهرست‌برداری، مانند S3 Inventory

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

واکنش

لاگ‌های دسترسی را تحلیل کنید و فضای ذخیره‌سازی کشف‌شده را در ابزارهای DLP و CASB خود ادغام کنید تا استفاده از آن را نظارت کنید—یا تأیید کنید که واقعاً رها شده است. از ابزارهای موجود برای ایزوله‌سازی امن دسترسی به فضای ذخیره‌سازی استفاده کنید. در صورت لزوم، یک پشتیبان امن ایجاد کنید، سپس داده‌ها را حذف کنید.

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

 

اپلیکیشن‌ها و سرویس‌های بلااستفاده روی سرورها: آسیب‌پذیری‌های پنهان

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

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

شناسایی

از طریق ممیزی منظم پیکربندی‌های نرم‌افزاری. برای ممیزی مؤثر، سرورها باید از مدل دسترسی مبتنی بر نقش پیروی کنند، به‌طوری که هر نقش سرور فهرست متناظری از نرم‌افزارهای مورد نیاز داشته باشد. علاوه بر CMDB، طیف گسترده‌ای از ابزارها به این ممیزی کمک می‌کنند:

  • ابزارهایی مانند OpenSCAP و Lynis—متمرکز بر انطباق با سیاست و سخت‌سازی سیستم
  • ابزارهای چندمنظوره مانند OSQuery
  • اسکنرهای آسیب‌پذیری مانند OpenVAS
  • تحلیلگران ترافیک شبکه

واکنش

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

 

APIهای منسوخ: چرا ۴۱ درصد حملات بیشتر شده‌اند؟

اولویت: بالا. مهاجمان اغلب از APIها برای استخراج حجم زیادی از داده‌های حساس و کسب دسترسی اولیه به سازمان سوءاستفاده می‌کنند. در سال ۲۰۲۴، تعداد حملات مرتبط با API به میزان ۴۱ درصد افزایش یافت، و مهاجمان به‌طور خاص APIهای منسوخ را هدف قرار می‌دهند، زیرا این APIها اغلب داده‌ها را با بررسی‌ها و محدودیت‌های کمتری ارائه می‌دهند. نشت ۲۰۰ میلیون رکورد از X/Twitter نمونه‌ای از این موضوع است.

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

شناسایی

در سطح WAF یا NGFW، نظارت بر ترافیک به APIهای خاص ضروری است. این کار به شناسایی ناهنجاری‌هایی که ممکن است نشان‌دهنده سوءاستفاده یا استخراج داده باشند کمک می‌کند، و همچنین APIهایی را که ترافیک حداقلی دریافت می‌کنند شناسایی می‌کند.

واکنش

برای APIهای کم‌فعالیت شناسایی‌شده، با ذی‌نفعان کسب‌وکار همکاری کنید تا برنامه‌ای برای خارج‌کردن از سرویس توسعه دهید و کاربران باقیمانده را به نسخه‌های جدیدتر منتقل کنید.

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

 

نرم‌افزار با وابستگی‌ها و کتابخانه‌های منسوخ: جایی که Log4Shell‌ها پنهان می‌شوند

اولویت: بالا. اینجاست که آسیب‌پذیری‌های بزرگ و بحرانی مانند Log4Shell پنهان می‌شوند که به سازش سازمانی و مشکلات انطباق با مقررات منجر می‌شوند.

شیوع: بسیار بالا، به‌ویژه در سیستم‌های مدیریت سازمانی در مقیاس بزرگ، سیستم‌های اتوماسیون صنعتی و نرم‌افزارهای سفارشی.

شناسایی

از ترکیب سیستم‌های مدیریت آسیب‌پذیری (VM/CTEM) و ابزارهای تحلیل ترکیب نرم‌افزار (SCA) استفاده کنید. برای توسعه داخلی، استفاده از اسکنرها و سیستم‌های امنیتی جامع یکپارچه با خط لوله CI/CD الزامی است تا از ساخت نرم‌افزار با کامپوننت‌های منسوخ جلوگیری شود.

واکنش

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

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

 

وب‌سایت‌های فراموش‌شده: از فیشینگ تا آسیب به اعتبار برند

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

شیوع: بالا—به‌ویژه برای سایت‌هایی که برای کمپین‌های کوتاه‌مدت یا فعالیت‌های داخلی یک‌باره راه‌اندازی شده‌اند.

شناسایی

بخش IT باید ثبت مرکزی از همه وب‌سایت‌ها و دامنه‌های عمومی نگهداری کند و وضعیت هر یک را به‌صورت ماهانه یا فصلی با مالکان آن‌ها تأیید کند. علاوه بر این، می‌توان از اسکنرها یا نظارت DNS برای ردیابی دامنه‌های مرتبط با زیرساخت IT شرکت استفاده کرد. لایه دیگری از حفاظت توسط سرویس‌های Threat Intelligence ارائه می‌شود که می‌توانند به‌طور مستقل هر وب‌سایت مرتبط با برند سازمان را شناسایی کنند.

واکنش

سیاستی برای خاموش‌کردن زمان‌بندی‌شده وب‌سایت پس از دوره ثابتی از پایان استفاده فعال آن ایجاد کنید. سیستم خودکار ثبت و تمدید DNS پیاده‌سازی کنید تا از از‌دست‌دادن کنترل بر دامنه‌های شرکت جلوگیری شود.

 

دستگاه‌های شبکه بلااستفاده: دروازه‌ای آسان برای هکرها

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

شیوع: متوسط. دستگاه‌ها در هنگام نقل مکان دفتر، ارتقای زیرساخت شبکه یا راه‌اندازی فضاهای کاری موقت جا می‌مانند.

شناسایی

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

واکنش

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

 

جمع‌بندی: از زامبی‌های IT خود آگاه شوید

زیرساخت‌های فراموش‌شده IT—از سرورهای یتیم و اکانت‌های غیرفعال گرفته تا APIهای منسوخ و دستگاه‌های شبکه رها‌شده—تهدیدی خاموش اما جدی هستند که از Shadow IT سنتی هم خطرناک‌تر است، زیرا هیچ‌کس از وجودشان خبر ندارد و هیچ‌کس مسئولیتشان را بر عهده نمی‌گیرد.

نکات کلیدی:

  • فرایندهای AD&R و فهرست‌برداری منظم پیاده‌سازی کنید
  • سیاست‌های رسمی برای خارج‌کردن دارایی‌ها از سرویس تدوین کنید
  • سیستم‌های IAM و مدیریت چرخه عمر API مستقر کنید
  • SBOM به‌روز نگهداری کنید
  • ممیزی‌های منظم فیزیکی و منطقی انجام دهید

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

دیدگاهتان را بنویسید

آخرین مقالات

چرا احراز هویت دومرحله‌ای دیگر شما را در برابر فیشینگ محافظت نمی‌کند؟

11 ساعت پیش

زیرساخت‌های فراموش‌شده IT: تهدید خاموشی که از Shadow IT هم خطرناک‌تر است

11 ساعت پیش

سرنوشت تلخ ویندوز ۷ در انتظار کاربران ویندوز ۱۰ است.

1 روز پیش

EDR یا XDR؟ راهنمای انتخاب سپر دفاعی مناسب برای سازمان شما

4 روز پیش

تفاوت EDR با آنتی‌ویروس چیست؟

5 روز پیش

طراحی یک نقشه راه تاب‌آور برای امنیت سایبری

1 ماه پیش

آخرین اطلاعیه‌ها

هشدار
Alert Level 3
حمله فیشینگ با فایل‌های ISO به بخش مالی روسیه برای توزیع Phantom Stealer
1 روز پیش
هشدار
Alert Level 2
CERT-FR توصیه می‌کند Wi-Fi را هنگام عدم استفاده کاملاً غیرفعال کنید
1 روز پیش
امنیت
Alert Level 1
KnowBe4 آموزش سفارشی دیپ‌فیک برای مقابله با تهدیدات هوش مصنوعی رونمایی کرد
1 روز پیش
خبر
Alert Level 1
راه‌اندازی چارچوب جهانی آموزش امنیت سایبری در سومالی
1 روز پیش
هشدار
Alert Level 3
پنج گروه چینی از آسیب‌پذیری React2Shell برای توزیع بدافزار سوءاستفاده می‌کنند
1 روز پیش
گزارش
Alert Level 3
گزارش سرف‌شارک ۲۰۲۵: ایران در رتبه ۱۱۹ امنیت دیجیتال جهان
1 روز پیش
حمله سایبری
Alert Level 3
تروجان بانکی Frogblight کاربران ترکیه را هدف قرار می‌دهد
1 روز پیش
باج افزار
Alert Level 2
ضعف رمزنگاری باج‌افزار CyberVolk امکان رمزگشایی رایگان را فراهم کرد
1 روز پیش
خبر
Alert Level 2
استارلینک: ماهواره چینی تا ۲۰۰ متری ماهواره ما رسید
1 روز پیش
وصله امنیتی
Alert Level 3
آسیب‌پذیری بحرانی در Plesk امکان دسترسی root به مهاجمان می‌دهد
3 روز پیش