اختلال چندساعتهی اخیر در Cloudflare فقط یک مشکل در دسترسپذیری نبود؛ در عمل برای بسیاری از سازمانها تبدیل شد به یک آزمایش ناخواستهی امنیتی. برای نخستین بار، خیلیها دیدند اگر لایهی دفاعی Cloudflare را کنار بگذارند، زیرساخت واقعی اپلیکیشن و وبسایتشان تا چه حد تابآور است.
ماجرا چه بود و چرا مهم است؟
در یک بازهی زمانی چندساعته، بخشی از سرویسهای Cloudflare دچار اختلال شد. نتیجه روشن بود: تعدادی از وبسایتهای معروف و سرویسهایی که پشت این پلتفرم قرار داشتند، یا از دسترس خارج شدند یا ناپایدار شدند.
بعضی سازمانها برای حفظ در دسترسبودن، تصمیم گرفتند موقتاً Cloudflare را دور بزنند؛ یعنی DNS را طوری تنظیم کردند که کاربران به جای رفتن به لبهی شبکهی Cloudflare، مستقیماً به سرورهای اصلی (origin) متصل شوند. این تصمیم از نظر availability منطقی بود، اما از منظر امنیتی اتفاق مهمی رخ داد: ترافیک اینترنت بدون فیلترهای Cloudflare به سمت زیرساخت واقعی آنها سرازیر شد.
در بسیاری از محیطها، DNS، WAF، محافظت در برابر DDoS، کنترل رباتها و حتی بخشی از سیاستهای جغرافیایی همه روی Cloudflare متمرکز است. وقتی این لایه را موقتاً حذف میکنید، عملاً برای چند ساعت با «چهرهی واقعی» اپلیکیشن خود در برابر اینترنت روبهرو میشوید.
وابستگی پنهان به WAF و فیلترهای Cloudflare
سالها استفاده از Cloudflare باعث شده در بسیاری از سازمانها طراحی امنیتی بهطور ضمنی بر یک فرض استوار شود: «Edge همه چیز را میگیرد». سیستم WAF و Bot Management این پلتفرم معمولاً طیف وسیعی از حملات لایهی کاربرد را قبل از رسیدن به اپلیکیشن متوقف میکند؛ حملاتی از جنس تزریق SQL، XSS، credential stuffing، اسکنهای خودکار، سوءاستفاده از API و…
وقتی چنین لایهای همیشه جلوی چشم است، تیمهای توسعه و امنیت ناخواسته تنبل میشوند. تست نفوذ و QA امنیتی گاهی سطحیتر میشود، چون در ذهن همه این است که: اگر هم چیزی از قلم بیفتد، WAF جلویش را میگیرد. در نتیجه، کد اپلیکیشن ممکن است به اندازهی لازم در برابر OWASP Top Ten سختسازی نشده باشد.
اختلال اخیر دقیقاً این توهم را از بین برد. در ساعاتی که Cloudflare دور زده شد، هر آنچه تا دیروز در Edge فیلتر میشد، حالا مستقیماً روی سرورهای واقعی نشست. لاگهای وبسرور و اپلیکیشن در آن بازه برای هر سازمانی حکم یک تست نفوذ زنده را دارد؛ تستی که نه در محیط آزمایش، بلکه در دل محیط عملیاتی انجام شده است.
نگاه از زاویهی مهاجم
برای درک بهتر ریسک، کافی است چند دقیقه از زاویهی یک مهاجم حرفهای به موضوع نگاه کنیم. فرض کنید مدتی است یک فروشگاه آنلاین یا سرویس مالی خاص را هدف گرفتهاید. میدانید که Cloudflare جلوی بسیاری از تلاشهای شما را گرفته و نمیگذارد بهراحتی اسکن عمیق انجام دهید، brute-force اجرا کنید یا payloadهای تزریقی را بدون محدودیت بفرستید.
حالا در یک لحظه، با رصد تغییرات DNS متوجه میشوید که این هدف، موقتاً Cloudflare را از مسیر خارج کرده است. از دید مهاجم، این یعنی پنجرهای طلایی باز شده است. طبیعی است که در چنین وضعیتی موج جدیدی از حملات شروع میشود:
اسکن سرویسها روی origin واقعی، تست احراز هویت ضعیف، تلاش برای تزریق SQL و XSS روی فرمها و APIها، بررسی endpointهای مدیریتی که قبلاً پشت فیلترها پنهان بودند، و حتی تلاش برای ایجاد دسترسی ماندگار در صورت موفقیت.
نکتهی مهم اینجاست: اگر در آن بازه، مهاجمی موفق شده باشد وارد سیستم شود، احتمالاً بعد از بازگشت Cloudflare هم در داخل باقی میماند. یعنی بازگشت به تنظیمات قبلی بهمعنای از بین رفتن ریسک نیست؛ فقط دوباره روی مشکل، یک لایهی محافظتی قرار دادهاید.
علت فنی اختلال و یک نکته مهم معماری
بر اساس توضیح فنی منتشر شده، منشأ این اختلال حملهی سایبری نبود، بلکه یک تغییر اشتباه در سطح مجوزهای یکی از سیستمهای پایگاه داده بود. همین تغییر باعث شد دیتابیس، دادههای بیشتری از حد معمول را در فایلی که برای سیستم مدیریت رباتها استفاده میشود قرار دهد؛ فایلی که اندازهاش بهطور غیرمنتظرهای افزایش یافت و سپس روی تعداد زیادی از ماشینهای شبکه توزیع شد. همین رشد غیرقابل پیشبینی، بخشی از زیرساخت را تحت فشار قرار داد و اختلال ایجاد کرد.
از نگاه معماری امنیت و پایداری، این داستان یک پیام روشن دارد: در سیستمهای توزیعشدهی بزرگ، اگر برای اجزای مشترک مثل فایلهای پیکربندی و feature file محدودیت، اعتبارسنجی و rollout مرحلهای نگذارید، یک تغییر کوچک میتواند کل شبکه را تحت تأثیر قرار دهد. این نکته فقط برای Cloudflare نیست؛ هر سازمانی که زیرساخت توزیعشده دارد باید روی مکانیزمهای حفاظت در برابر خطای داخلی هم به همان اندازهی حفاظت در برابر حملهی خارجی سرمایهگذاری کند.
ریسک «نقطهی شکست واحد» در معماریهای مدرن
Cloudflare ادعا میکند بخش چشمگیری از وبسایتهای اینترنت به نوعی به سرویسهای آن متکی هستند. وقتی این وابستگی را کنار استفادهی گسترده از AWS، Azure و سایر ارائهدهندگان ابری قرار دهیم، تصویر واضحتر میشود: اکوسیستم وب امروز حول چند هاب بزرگ میچرخد. هر اختلال کوتاه در یکی از آنها میتواند عملاً برای صدها یا هزاران سازمان به نقطه شکست واحد تبدیل شود.
مشکل زمانی جدیتر است که همهچیز روی یک Vendor متمرکز شده باشد: DNS، WAF، CDN، محافظت در برابر DDoS، مدیریت رباتها، و حتی دسترسی Zero Trust. در چنین حالتی، اگر آن Vendor دچار اختلال شود، همزمان هم availability و هم security شما تحت تأثیر قرار میگیرد.
چه درسهایی میتوان گرفت؟
از نگاه یک کارشناس امنیت، این حادثه چند پیام عملی مهم دارد:
اول اینکه نباید تمام دفاع امنیتی را روی لبهی شبکه و روی یک ارائهدهنده متمرکز کرد. اپلیکیشن باید بهتنهایی در برابر حملات رایج مقاوم باشد؛ یعنی حتی اگر هیچ WAF خارجی در کار نباشد، باز هم در برابر حملات مبتنی بر OWASP Top Ten تاب بیاورد. این یعنی سرمایهگذاری جدی روی کدنویسی امن، بازبینی امنیتی کد، تستهای خودکار و دستی، و استفاده از ابزارهای SAST و DAST.
دوم، زیرساخت باید طوری طراحی شود که قطع شدن یک سرویسدهندهی واحد، کل سازمان را فلج نکند. میتوان لایههای مختلف دفاعی و خدمات حیاتی را بین چند zone، چند حساب کاربری و در صورت لزوم چند Vendor توزیع کرد. استفاده از DNS چندتأمینکنندهای، داشتن مسیرهای جایگزین برای WAF و CDN، و تعریف سناریوهای failover میتواند زمان بازیابی را بهطور چشمگیری کم کند.
سوم، سازمانها باید رفتار خود در زمان بحران را بشناسند. در چند ساعت اختلال، چه تغییراتی روی DNS انجام شد؟ چه کسی آنها را تأیید کرد؟ چه سرویسهای «موقت» جدیدی راهاندازی شد؟ آیا از دستگاههای شخصی، شبکههای ناایمن یا سرویسهای SaaS بدون مجوز استفاده شد؟ اگر پاسخ این پرسشها روشن نباشد، یعنی در حادثهی بعدی دوباره همان اشتباهات تکرار خواهد شد.
یک رویکرد عملی پیشنهادی
اگر در این اختلال مجبور شدهاید Cloudflare را دور بزنید، حالا بهترین زمان است که سه کار مشخص انجام دهید:
نخست، لاگهای مربوط به همان بازهی زمانی را بهصورت هدفمند تحلیل کنید. بهدنبال الگوهای حمله، افزایش غیرعادی حجم درخواستها، تلاشهای ناموفق ورود، payloadهای مشکوک در پارامترها و هر رفتار غیرمعمول دیگر باشید. اگر تیم داخلی فرصت یا تخصص کافی ندارد، از یک تیم خارج از سازمان کمک بگیرید.
دوم، بعد از بازگشت به وضعیت عادی، یک ارزیابی امنیتی مجدد انجام دهید. به این بازه به چشم یک تست نفوذ زنده نگاه کنید و فرض را بر این بگذارید که ممکن است کسی در آن زمان وارد شده باشد. بررسی برای شواهد حضور ماندگار، حسابهای غیرمجاز، تغییرات غیرمنتظره در تنظیمات، و اضافه شدن سرویسها یا تونلهای ناشناخته ضروری است.
سوم، معماری و فرآیندهای خود را بازطراحی کنید. برای قطع شدن Cloudflare یا هر Vendor دیگر مثل آروان کلود که در ایران رایج است، سناریوی مشخص و مستند داشته باشید. از پیش بدانید اگر مجبور شدید سرویس را دور بزنید، دقیقاً چه تنظیماتی را تغییر میدهید، چه محدودیتهای جایگزینی را در لایهی اپلیکیشن فعال میکنید و چطور پس از پایان بحران همهچیز را به حالت امن بازمیگردانید.
جمعبندی
اختلال Cloudflare یک یادآوری جدی بود که نشان داد اتکا به یک لایهی دفاعی واحد، هرچقدر هم قدرتمند، از نظر امنیتی خطرناک است. امنیت واقعی زمانی به دست میآید که اپلیکیشن، زیرساخت و فرآیندها هر سه بهدرستی طراحی شده باشند. اگر این حادثه باعث شود سازمانها وابستگی خود به یک Vendor را بهتر ببینند، دفاع خود را چندلایه کنند و کدنویسی امن را جدیتر بگیرند، میتوان گفت از یک مشکل عملیاتی کوتاه، یک فرصت بلندمدت یادگیری ساختهاند.
