‏وقتی شبکه بسته‌ست ولی اجرا باز می‌مونه

نویسنده که یه مهندس امنیته، چند سال پیش می‌خواسته داده‌های تست رو بین دو اکانت AWS که هیچ مسیر شبکه‌ای مستقیم بینشون نبوده رد و بدل کنه. به‌جای باز کردن مسیر شبکه، از IAM استفاده کرده: یه پیام رو صف SQS اکانت Dev فرستاده، این پیام یه تابع Lambda تو اکانت Staging رو صدا زده، و جواب هم از یه صف دیگه برگشته. نتیجه یه ورک‌فلو دوطرفه بین دو محیط بوده که هیچ فایروالی نمی‌دیدتش؛ دقیقاً همون چیزی که تو یه حمله واقعی command-and-control (کانال کنترل از راه دور بدافزار) نامیده می‌شه.

نکته اینه که این الگو مخصوص AWS نیست: تو AWS ترکیب EventBridge، صف SQS و Lambda، تو Google Cloud ترکیب Pub/Sub یا Eventarc با Cloud Run، و تو Azure ترکیب Event Grid یا Service Bus با Functions همین کارو می‌کنن. همه‌ی این‌ها معماری‌های کاملاً عادی و رایج هستن؛ مشکل از وقتی شروع می‌شه که هر کدوم از این اتصال‌ها جدا جدا بررسی می‌شن، در حالی که کنار هم یه مسیر از یه منبع کم‌اعتماد به یه اکشن حساس داخلی می‌سازن.

نویسنده این ایده رو یه قدم جلوتر برده: با یه پالیسی cross-account روی EventBridge، از یه اکانت بیرونی یه event ساختگی فرستاده که یه Lambda داخلی رو صدا می‌زده و اون Lambda هم یه اپلیکیشن تو EKS رو صدا می‌زده. اون اپلیکیشن پشت security group، NetworkPolicy کوبرنتیز و مجوزهای service mesh بوده، ولی چون هر قدم به‌تنهایی مجاز بوده، درخواست از همه‌ی لایه‌ها رد شده و اپلیکیشن با هویت ابری خودش یه اکشن حساس (حذف یه security group تو یه اکانت دیگه) رو اجرا کرده، بدون این‌که هیچ کنترلی دور زده بشه.

وقتی نویسنده دنبال یه سیگنال هشدار برای این ماجرا گشته، چیزی پیدا نکرده. CloudTrail (لاگ فعالیت‌های AWS) فقط نشون می‌داده کدوم هویت این اکشن رو انجام داده، نه این‌که چرا. برای بازسازی مسیر واقعی مجبور شده لاگ اپلیکیشن، مش سرویس، فلوی شبکه، Lambda و قانون EventBridge رو دستی دنبال کنه که تقریباً یه بعدازظهر کامل طول کشیده؛ اونم درحالی که از قبل می‌دونسته دنبال چی می‌گرده.

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

نکات کلیدی:

• مسیر شبکه (network path) و مسیر اجرا (execution path) دو چیز جدان؛ ایزوله بودن یکی به معنی ایزوله بودن اون یکی نیست.
• تو AWS از SQS/EventBridge/Lambda، تو GCP از Pub/Sub یا Eventarc، و تو Azure از Event Grid یا Service Bus می‌شه بدون مسیر شبکه یه اکانت دیگه رو صدا زد.
• تو آزمایش نویسنده، یه event از یه اکانت بیرونی از طریق EventBridge و Lambda به یه اپلیکیشن تو EKS رسیده و باعث حذف یه security group شده.
• CloudTrail هویت مسئول اکشن رو نشون می‌ده ولی دلیل و مسیر رسیدن بهش رو نه؛ بازسازی این مسیر دستی و زمان‌بره.
• پیشنهاد نویسنده: مسیرهای اجرا رو از مرحله‌ی طراحی به‌عنوان بخشی از مرز امنیتی نگاشت و پایش کنیم، نه فقط شبکه و هویت رو.