کاربران برای پیکربندی و نگهداری سرویس‌های فناوری اطلاعات خود، از جمله ذخیره‌سازی داده‌ها، به ارائه‌دهندگان سرویس‌های ابری (Cloud Providers) اعتماد می‌کنند. در مقابل، ارائه‌دهنده تضمین می‌کند که سرویس‌های میزبانی‌شده همیشه در دسترس باشند و داده‌ها کاملاً محرمانه باقی بمانند. برای اثبات امنیت پلتفرم‌ها، ارائه‌دهندگان استراتژی‌های مختلفی را اتخاذ می‌کنند؛ برخی از برنامه‌های Bug Bounty استفاده می‌کنند، برخی بر حسابرسی‌های داخلی (Internal Audits) تکیه دارند و برخی دیگر تیم‌های تحقیقاتی خارجی را به خدمت می‌گیرند. با این حال، متدولوژی تست نفوذ (Pentest) در فضای ابری همچنان دارای نقاط کور بسیاری است؛ چرا که استاندارد واحدی وجود ندارد و نتیجه کار به تجربه و مهارت تیم انجام‌دهنده بستگی دارد.
مدل سه لایه زیرساخت ابری
برای سیستماتیک کردن فرآیند تست نفوذ، می‌توان زیرساخت ابری را به سه لایه اصلی تقسیم کرد که هر کدام مرزهای اعتماد (Trust Boundaries) متفاوتی دارند:
- لایه خارجی (External Layer): این لایه مشابه بخش عمومی یک هتل (مانند وب‌سایت رزرو یا میز پذیرش) است. در اینجا، تست‌کننده از طریق کنسول مدیریت (Management Console)، رابط‌های کاربری مشتری و APIهای عمومی با سیستم تعامل دارد. هدف اصلی در این لایه، دستیابی به دسترسی اولیه (Initial Access) به محیط یک مشتری دیگر یا حرکت به سمت لایه Overlay است.
- لایه سرویس ارائه‌دهنده (Overlay Layer): این لایه مشابه بخش‌های «فقط کارکنان» در یک هتل (مانند آشپزخانه یا اتاق کنترل) است. این لایه شامل محیط‌های اجرای سرویس‌ها (Service Runtime)، سیستم‌های مدیریت سرویس، برنامه‌های زمان‌بندی (Schedulers)، سیستم‌های مانیتورینگ و APIهای داخلی است. در این سطح، هدف نفوذ، دسترسی به مدیریت سرویس‌های مدیریت‌شده یا زیرساخت‌های داخلی ارائه‌دهنده است.
- لایه زیرساخت (Underlay Layer): این لایه مشابه تأسیسات فنی و سیستم‌های برق یک ساختمان است. این لایه شامل سخت‌افزار، سرورهای فیزیکی، سیستم‌عامل‌های میزبان (Host OS)، هایپروایزرها (Hypervisors) و شبکه‌های انتقال است. تست‌های careless در این لایه می‌تواند آسیب‌های جدی به زیرساخت وارد کند.
مرزهای اعتماد و سناریوهای حمله
جوهر اصلی تست نفوذ ابری، فراتر رفتن از اسکن ساده زیرشبکه‌ها و تمرکز بر تست مرزهای اعتماد است. یک مرز واقعی توسط کنترل‌هایی مانند احراز هویت و تعیین سطح دسترسی (IAM, RBAC)، جداسازی (Isolation) از طریق مجازی‌سازی یا کانتینرسازی، و رمزنگاری (مانity mTLS) محافظت می‌شود. تحلیل‌ها نشان می‌دهند که مهاجمان معمولاً از سه مسیر اصلی اقدام می‌کنند:
- اجرای کد از راه دور (RCE): تلاش برای اجرای کد در محیط‌های مدیریت‌شده مانند پایگاه‌های داده مدیریت‌شده (Managed Databases)، توابع بدون سرور (Serverless Functions) یا کانتینرها. اگر مهاجم بتواند از یک کانتینر به سیستم‌عامل میزبان (Host OS) فرار کند، می‌تواند به منابع دیگر دسترسی یابد.
- سرقت اعتبارنامه‌ها (Credential Theft): استخراج توکن‌های سرویس (Service Account Tokens)، اعتبارنامه‌های دسترسی به Metadata یا گواهی‌های mTLS برای استفاده از قابلیت‌های قانونی پلتفرم جهت دسترسی به منابع حساس‌تر.
- دور زدن محدودیت‌های فنی: استفاده از کانال‌های مدیریتی یا دسترسی‌های کارکنان (مانند VPN اپراتور یا پورتال پشتیبانی) برای ورود به محیط‌های داخلی ارائه‌دهنده.
چالش‌های معماری در محیط‌های ابری
برخلاف سیستم‌های سنادی که الگوهای معماری ثابتی دارند، پلتفرم‌های ابری بسیار متغیر هستند. یک پایگاه داده مدیریت‌شده ممکن است در یک ارائه‌دهنده در یک ماشین مجازی ایزوله اجرا شود و در ارائه‌دهنده دیگر، در یک Namespace از یک کلاستر مشترک Kubernetes باشد. این عدم قطعیت باعث می‌شود که پس از شکستن اولین مرز اعتماد، کار تست‌کننده به جای جستجوی پورت‌های باز، به بازسازی معماری از طریق نشانه‌های غیرمستقیم (مانند مسیرهای شبکه، نام سرویس‌ها و پیکربندی‌های Agentها) تبدیل شود.
