Serverless Security چیست؟ مهم‌ترین تهدیدهای امنیتی معماری Serverless

Serverless Security یا امنیت معماری بدون سرور مجموعه‌ای از اصول، فناوری‌ها و کنترل‌های امنیتی است که برای محافظت از توابع، APIها، داده‌ها، هویت‌ها و سرویس‌های ابری در معماری Serverless استفاده می‌شود. مهم‌ترین تهدیدهای این معماری شامل دسترسی‌های بیش‌ازحد، تزریق کد، افشای اطلاعات حساس، ضعف احراز هویت، آسیب‌پذیری کتابخانه‌ها، سوءاستفاده از رویدادها و حملات اختلال سرویس است. برای کاهش این خطرات باید اصل حداقل دسترسی، اعتبارسنجی ورودی‌ها، مدیریت امن اسرار، نظارت مداوم و امنیت زنجیره تأمین نرم‌افزار رعایت شود.

مقدمه: آیا حذف سرور به معنای حذف تهدیدهای امنیتی است؟

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

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

اما یک پرسش مهم وجود دارد: اگر سرورها توسط ارائه‌دهنده سرویس مدیریت می‌شوند، آیا برنامه‌های Serverless همچنان در معرض حملات سایبری هستند؟

پاسخ مثبت است.

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

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

در چنین شرایطی، حتی اگر زیرساخت اجرایی کاملاً به‌روز و ایزوله باشد، طراحی نادرست برنامه می‌تواند امنیت کل کسب‌وکار را تهدید کند.

بنابراین، Serverless Security تنها به امنیت کد محدود نمی‌شود؛ بلکه امنیت هویت، مجوزها، رویدادها، داده‌ها، شبکه، وابستگی‌های نرم‌افزاری و فرایند استقرار را نیز شامل می‌شود.

در این مقاله، معماری Serverless، مهم‌ترین تهدیدهای امنیتی آن و روش‌های کاربردی محافظت از برنامه‌های بدون سرور را بررسی می‌کنیم.

معماری Serverless چیست و چگونه کار می‌کند؟

Serverless Computing یک مدل رایانش ابری است که در آن ارائه‌دهنده خدمات ابری مسئول مدیریت بخش مهمی از زیرساخت اجرای برنامه است.

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

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

نقش Function as a Service در معماری Serverless

یکی از شناخته‌شده‌ترین الگوهای Serverless، مدل Function as a Service یا FaaS است.

در این مدل، برنامه به توابع مستقلی تقسیم می‌شود که معمولاً در پاسخ به یک رویداد مشخص اجرا می‌شوند.

این رویداد ممکن است شامل موارد زیر باشد:

• دریافت درخواست HTTP از طریق API
• بارگذاری فایل در فضای ذخیره‌سازی ابری
• ثبت رکورد جدید در پایگاه داده
• دریافت پیام از صف پردازش
• اجرای یک وظیفه زمان‌بندی‌شده
• انتشار پیام توسط سرویس‌های دیگر
• وقوع رویداد در سامانه احراز هویت

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

پس از پایان پردازش نیز محیط اجرا می‌تواند برای استفاده‌های بعدی نگهداری یا جمع‌آوری شود.

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

مهم‌ترین پلتفرم‌های Serverless

چند نمونه شناخته‌شده از سرویس‌های اجرای توابع عبارت‌اند از:

AWS Lambda: سرویس اجرای توابع در زیرساخت Amazon Web Services که با سرویس‌هایی مانند API Gateway، S3، SQS و DynamoDB یکپارچه می‌شود.

Azure Functions: سرویس اجرای کد مبتنی بر رویداد در Microsoft Azure که با خدمات هویت، ذخیره‌سازی، پیام‌رسانی و نظارت این پلتفرم ارتباط دارد.

Google Cloud Run Functions: محیط اجرای توابع در Google Cloud که از رویدادها و درخواست‌های HTTP پشتیبانی می‌کند و با سرویس‌های دیگر این اکوسیستم یکپارچه می‌شود.

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

تفاوت Serverless با میزبانی سنتی

در میزبانی سنتی، سازمان معمولاً مسئول مدیریت مستقیم بخش بیشتری از زیرساخت است؛ از نصب نرم‌افزار و به‌روزرسانی سیستم‌عامل گرفته تا پیکربندی شبکه و کنترل سرویس‌های فعال.

در معماری Serverless، بخش مهمی از این مسئولیت‌ها به ارائه‌دهنده ابری منتقل می‌شود.

بااین‌حال، مسئولیت امنیت برنامه و اطلاعات از بین نمی‌رود.

برای مقایسه:

در معماری سنتی:

• مدیریت سرور و سیستم‌عامل اهمیت زیادی دارد.
• تنظیمات مستقیم سرویس‌ها در اختیار مدیر زیرساخت است.
• بخش مهمی از امنیت به سخت‌سازی سیستم‌عامل و شبکه وابسته است.
• برنامه‌ها ممکن است برای مدت طولانی در یک محیط ثابت اجرا شوند.

در معماری Serverless:

• مدیریت زیرساخت اجرایی عمدتاً بر عهده ارائه‌دهنده است.
• کنترل مجوزهای ابری اهمیت ویژه‌ای پیدا می‌کند.
• ورودی رویدادها و ارتباط توابع به نقاط حساس امنیتی تبدیل می‌شوند.
• اجرای توابع ممکن است کوتاه‌مدت، مقیاس‌پذیر و توزیع‌شده باشد.
• کنترل هزینه و تعداد فراخوانی‌ها بخشی از راهبرد محافظتی است.

در نتیجه، امنیت Serverless به رویکردی متناسب با ویژگی‌های همین معماری نیاز دارد.

چرا امنیت Serverless با امنیت برنامه‌های سنتی متفاوت است؟

برنامه‌های Serverless همچنان در معرض بسیاری از آسیب‌پذیری‌های متداول وب قرار دارند؛ اما نحوه ظهور، گسترش و شناسایی این آسیب‌پذیری‌ها ممکن است متفاوت باشد.

افزایش تعداد نقاط ورود

یک برنامه سنتی ممکن است از چند سرویس اصلی تشکیل شده باشد، درحالی‌که یک سامانه Serverless می‌تواند ده‌ها یا صدها تابع مستقل داشته باشد.

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

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

پیچیدگی ارتباط میان سرویس‌ها

در یک معماری مبتنی بر رویداد، داده ممکن است از چند سرویس عبور کند.

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

تابع دیگری پیام را پردازش و اطلاعات را در پایگاه داده ثبت می‌کند.

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

محدودیت دید مستقیم به زیرساخت

در Serverless معمولاً امکان نصب آزادانه ابزارهای سنتی پایش میزبان یا دسترسی مستقیم به سیستم‌عامل زیرساخت وجود ندارد.

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

تغییر مداوم محیط اجرا

محیط‌های اجرایی ممکن است ایجاد، استفاده مجدد و سپس حذف شوند.

در چنین شرایطی، تکیه بر بررسی دستی یک سرور ثابت برای شناسایی رخدادهای امنیتی کافی نیست.

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

مدل مسئولیت مشترک در Serverless Security

یکی از مهم‌ترین مفاهیم در امنیت معماری Serverless، مدل Shared Responsibility یا مسئولیت مشترک است.

بر اساس این مدل، ارائه‌دهنده خدمات ابری و مالک برنامه هرکدام مسئول بخش مشخصی از امنیت هستند.

مسئولیت ارائه‌دهنده خدمات ابری

در سرویس‌های FaaS مدیریت‌شده، ارائه‌دهنده معمولاً مسئول محافظت از زیرساخت فیزیکی، بخش‌های زیرین پلتفرم، جداسازی محیط‌های اجرایی و مدیریت بسیاری از به‌روزرسانی‌های زیرساختی است.

این مسئولیت‌ها ممکن است شامل موارد زیر باشند:

• حفاظت از مراکز داده و سخت‌افزار
• ایمن‌سازی زیرساخت مجازی‌سازی
• مدیریت امنیت بخش‌های تحت کنترل ارائه‌دهنده
• نگهداری زیرساخت اجرای توابع
• ارائه قابلیت‌های ثبت رویداد و کنترل دسترسی
• فراهم‌کردن ابزارهای رمزنگاری و نظارت

دامنه دقیق این مسئولیت‌ها به نوع سرویس و قرارداد ارائه‌دهنده بستگی دارد.

مسئولیت مالک برنامه

مالک برنامه همچنان باید امنیت کد، داده‌ها، حساب‌ها و تنظیمات خود را تأمین کند.

مهم‌ترین مسئولیت‌های او عبارت‌اند از:

1. تعریف مجوزهای مناسب برای هر تابع
2. پیاده‌سازی احراز هویت و کنترل دسترسی
3. اعتبارسنجی داده‌های ورودی
4. محافظت از اطلاعات محرمانه
5. مدیریت کتابخانه‌های وابسته
6. پیکربندی امن سرویس‌ها و منابع ابری
7. نظارت بر رفتار توابع
8. مدیریت آسیب‌پذیری‌ها و رخدادهای امنیتی

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

نکته مهم: استفاده از Serverless ممکن است بخشی از بار عملیاتی امنیت را کاهش دهد، اما مسئولیت حفاظت از منطق برنامه و داده‌های کاربران همچنان باقی می‌ماند.

مهم‌ترین تهدیدهای امنیتی معماری Serverless

برای شناخت تهدیدهای Serverless Security باید مسیر ورود داده، نحوه اجرای توابع، سطح مجوزها و ارتباط آن‌ها با منابع دیگر بررسی شود.

خطرات زیر از مهم‌ترین مواردی هستند که در طراحی، توسعه و ارزیابی امنیتی سامانه‌های Serverless باید مورد توجه قرار گیرند.

۱. تزریق کد و داده‌های مخرب در توابع Serverless

Injection یکی از شناخته‌شده‌ترین دسته‌های آسیب‌پذیری نرم‌افزاری است.

این خطر زمانی ایجاد می‌شود که برنامه داده‌های ورودی را بدون جداسازی مناسب از دستورات اجرایی، پرس‌وجوها یا سایر بخش‌های حساس پردازش کند.

در معماری Serverless، ورودی لزوماً از یک فرم وب دریافت نمی‌شود.

داده ممکن است از API Gateway، پیام صف، محتوای فایل، رویداد پایگاه داده یا سرویس دیگری وارد تابع شود.

اگر برنامه از این داده‌ها برای ساخت دستورهای حساس استفاده کند، امکان ایجاد آسیب‌پذیری‌هایی مانند موارد زیر وجود دارد:

• SQL Injection در ارتباط با پایگاه داده
• Command Injection در اجرای فرایندهای سیستمی
• NoSQL Injection در پرس‌وجوهای ساختاریافته
• Template Injection در سامانه‌های قالب‌سازی
• تزریق داده به سرویس‌های پایین‌دستی

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

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

راهکارهای پیشگیری:

ابتدا باید ساختار داده‌های ورودی با استفاده از Schema Validation کنترل شود.

سپس نوع، طول، قالب و محدوده مقادیر بررسی شوند.

برای ارتباط با پایگاه داده باید از پرس‌وجوهای پارامتری استفاده شود.

همچنین بهتر است از ساخت مستقیم دستورهای اجرایی بر اساس اطلاعات غیرقابل‌اعتماد پرهیز شود.

اعتبارسنجی ورودی باید در مرزهای مختلف اعتماد انجام شود؛ نه صرفاً در اولین سرویس دریافت‌کننده درخواست.

۲. اعطای مجوزهای بیش‌ازحد به توابع

یکی از مهم‌ترین تهدیدهای Serverless Security، پیکربندی نامناسب Identity and Access Management یا IAM است.

IAM سامانه‌ای برای مدیریت هویت‌ها و تعیین سطح دسترسی آن‌ها به منابع ابری است.

در یک معماری امن، هر تابع باید فقط به منابعی دسترسی داشته باشد که برای انجام وظیفه خود به آن‌ها نیاز دارد.

این مفهوم با عنوان Principle of Least Privilege یا اصل حداقل دسترسی شناخته می‌شود.

فرض کنید یک تابع تنها مسئول خواندن تصویر از فضای ذخیره‌سازی و تولید نسخه بهینه‌شده آن است.

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

در صورت بروز آسیب‌پذیری در تابع، این مجوزهای اضافی می‌توانند دامنه خسارت را افزایش دهند.

مشکل زمانی جدی‌تر می‌شود که چندین تابع از یک نقش دسترسی مشترک و گسترده استفاده کنند.

در چنین شرایطی، ضعف امنیتی یک تابع ممکن است راه دسترسی به منابع موردنیاز سایر بخش‌ها را فراهم کند.

راهکارهای پیشگیری:

برای هر تابع یا مجموعه محدودی از وظایف مشابه، نقش‌های دسترسی متناسب تعریف کنید.

مجوزهای عمومی و گسترده را تا حد امکان حذف کنید.

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

مجوزها باید به‌صورت دوره‌ای بازبینی شوند؛ زیرا سطح دسترسی موردنیاز یک تابع ممکن است پس از تغییر منطق برنامه کاهش پیدا کند.

۳. ضعف احراز هویت و کنترل دسترسی

Broken Authentication و Broken Access Control از تهدیدهایی هستند که می‌توانند اطلاعات و عملیات حساس برنامه‌های Serverless را در معرض خطر قرار دهند.

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

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

این دو مفهوم تفاوت مهمی دارند.

Authentication یا احراز هویت مشخص می‌کند درخواست‌دهنده چه کسی است.

Authorization یا مجوزدهی تعیین می‌کند درخواست‌دهنده چه عملیاتی را می‌تواند انجام دهد.

برای مثال، کاربری که وارد حساب خود شده است نباید صرفاً به دلیل داشتن نشست معتبر بتواند اطلاعات سفارش کاربر دیگری را مشاهده کند.

در معماری Serverless، این کنترل باید در API Gateway، لایه احراز هویت و منطق برنامه متناسب با طراحی سامانه انجام شود.

استفاده از JWT نیز به‌تنهایی امنیت ایجاد نمی‌کند.

برنامه باید اعتبار امضای توکن، صادرکننده، مخاطب مجاز، زمان انقضا و سایر ادعاهای امنیتی مرتبط را بررسی کند.

راهکارهای پیشگیری:

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

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

۴. افشای رمزهای عبور و کلیدهای محرمانه

Secrets Management یکی از بخش‌های حیاتی امنیت Serverless است.

توابع ابری معمولاً برای ارتباط با پایگاه داده، سرویس پرداخت، سامانه پیام‌رسانی یا سایر APIها به اطلاعات محرمانه نیاز دارند.

این اطلاعات ممکن است شامل رمز عبور، کلید دسترسی، توکن احراز هویت و کلید رمزنگاری باشد.

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

برای مثال، ممکن است یک کلید API در مخزن کد، فایل پیکربندی، خروجی خطا یا بسته استقرار باقی بماند.

حتی ذخیره‌سازی اطلاعات حساس در متغیرهای محیطی نیز نیازمند بررسی سطح دسترسی، نحوه رمزنگاری و سیاست مدیریت اسرار است.

متغیرهای محیطی برای تنظیمات عملیاتی مناسب‌اند، اما برای اسرار حساس، استفاده از سرویس اختصاصی مدیریت اسرار معمولاً کنترل‌های بهتری فراهم می‌کند.

نمونه‌هایی از این سرویس‌ها عبارت‌اند از AWS Secrets Manager، Azure Key Vault و Google Secret Manager.

راهکارهای پیشگیری:

اطلاعات محرمانه را از کد جدا کنید.

برای هر سرویس، دسترسی محدود به اسرار موردنیاز تعریف کنید.

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

فرایند چرخش کلیدها یا Secret Rotation را در طراحی لحاظ کنید.

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

در صورت افشای یک کلید، صرفاً حذف آن از کد کافی نیست؛ کلید باید باطل یا جایگزین شود و میزان استفاده احتمالی از آن بررسی گردد.

۵. آسیب‌پذیری کتابخانه‌ها و زنجیره تأمین نرم‌افزار

بسیاری از توابع Serverless از نظر حجم کد اختصاصی کوچک هستند، اما برای اجرای وظایف خود به کتابخانه‌های متعددی وابسته‌اند.

برای مثال، یک تابع پردازش تصویر ممکن است از کتابخانه‌های دریافت فایل، تبدیل تصویر، ارتباط با فضای ذخیره‌سازی و مدیریت داده استفاده کند.

هرکدام از این وابستگی‌ها می‌توانند آسیب‌پذیری شناخته‌شده یا ضعف امنیتی دیگری داشته باشند.

علاوه بر وابستگی‌های مستقیم، کتابخانه‌ها ممکن است بسته‌های دیگری را نیز نصب کنند که با عنوان Transitive Dependencies شناخته می‌شوند.

در نتیجه، بررسی کد اختصاصی تابع به‌تنهایی برای تأمین امنیت کافی نیست.

تهدیدهای Software Supply Chain یا زنجیره تأمین نرم‌افزار می‌توانند از طریق بسته‌های آلوده، مخازن غیرقابل‌اعتماد، فرایندهای ساخت آسیب‌پذیر یا تغییر غیرمجاز فایل‌های استقرار ایجاد شوند.

راهکارهای پیشگیری:

نسخه وابستگی‌ها را کنترل و به‌صورت منظم بررسی کنید.

برای شناسایی آسیب‌پذیری‌های شناخته‌شده از ابزارهای Software Composition Analysis یا SCA استفاده کنید.

فقط بسته‌های ضروری را در خروجی استقرار قرار دهید.

از مخازن معتبر استفاده کنید و منشأ وابستگی‌های حساس را ارزیابی کنید.

ایجاد Software Bill of Materials یا SBOM نیز کمک می‌کند فهرستی از اجزای نرم‌افزاری و نسخه‌های استفاده‌شده در اختیار تیم امنیت قرار گیرد.

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

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

۶. سوءاستفاده از رویدادها و محرک‌های اجرای تابع

یکی از ویژگی‌های اصلی معماری Serverless، اجرای توابع در پاسخ به رویدادها است.

این رویدادها با عنوان Event شناخته می‌شوند و عامل شروع اجرای بسیاری از پردازش‌ها هستند.

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

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

همچنین وجود پیام در یک صف به این معنا نیست که تمام فیلدهای آن صحیح هستند یا پردازش موردنظر مجاز است.

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

اگر مرزهای اعتماد مشخص نباشند، داده‌های نامعتبر می‌توانند در چندین مرحله پردازش شوند.

راهکارهای پیشگیری:

برای هر منبع رویداد، فهرستی از محرک‌های مجاز تعریف کنید.

قالب و محتوای پیام‌ها را اعتبارسنجی کنید.

مجوز سرویس‌های منتشرکننده و مصرف‌کننده رویداد را محدود نگه دارید.

برای رویدادهای حساس، اصالت و یکپارچگی پیام را با سازوکار متناسب با منبع آن بررسی کنید.

اطلاعات امنیتی مانند هویت کاربر نباید صرفاً بر اساس یک فیلد قابل‌تغییر در پیام پذیرفته شوند.

همچنین بهتر است مسیر پردازش رویدادها مستند باشد تا تیم امنیت بداند هر رویداد کدام توابع و منابع را تحت تأثیر قرار می‌دهد.

۷. حملات SSRF و ارتباطات خروجی ناامن

Server-Side Request Forgery یا SSRF زمانی رخ می‌دهد که برنامه امکان هدایت درخواست‌های سمت سرور به مقصدهای غیرمجاز را فراهم کند.

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

برای مثال، یک تابع Serverless ممکن است برای دریافت تصویر از یک نشانی اینترنتی طراحی شده باشد.

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

پیامد SSRF به سطح دسترسی شبکه، هویت اجرایی، پلتفرم و کنترل‌های موجود بستگی دارد.

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

راهکارهای پیشگیری:

مقصدهای مجاز ارتباطات خروجی را محدود کنید.

در صورت امکان از Allowlist برای سرویس‌های مورداعتماد استفاده کنید.

نشانی‌ها و تغییرمسیرهای HTTP را به‌شکل امن اعتبارسنجی کنید.

کنترل‌های شبکه مانند محدودسازی Egress را متناسب با معماری فعال کنید.

همچنین مجوزهای هویت اجرایی تابع را به حداقل برسانید.

استفاده از شبکه خصوصی یا VPC به‌تنهایی SSRF را برطرف نمی‌کند؛ زیرا مشکل اصلی می‌تواند ناشی از تصمیم برنامه برای برقراری ارتباط با مقصد نامعتبر باشد.

۸. افشای اطلاعات حساس در محیط اجرای توابع

محیط اجرای Serverless ممکن است پس از پایان یک فراخوانی، برای فراخوانی بعدی همان تابع مجدداً استفاده شود.

این ویژگی می‌تواند عملکرد برنامه را بهبود دهد، اما در طراحی امنیتی باید مورد توجه قرار گیرد.

برای مثال، اگر تابع اطلاعات حساس کاربر را در متغیرهای عمومی، کش درون‌حافظه‌ای یا فایل‌های موقت نگهداری کند، احتمال باقی‌ماندن داده در محیط اجرای قابل‌استفاده مجدد وجود دارد.

این موضوع به معنای دسترسی آزاد سایر کاربران یا مستأجران ابری به حافظه یکدیگر نیست.

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

همچنین ذخیره‌سازی اطلاعات در مسیرهای موقت مانند /tmp باید با آگاهی از چرخه عمر محیط اجرا انجام شود.

راهکارهای پیشگیری:

اطلاعات حساس مربوط به یک درخواست را بدون ضرورت در وضعیت مشترک محیط اجرا نگهداری نکنید.

فایل‌های موقت را مدیریت و پس از پایان نیاز حذف کنید.

از جداسازی منطقی داده‌های کاربران اطمینان حاصل کنید.

داده‌های حساس را در خروجی خطا و لاگ ذخیره نکنید.

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

نکته مهم این است که طراحی Stateless به معنای حذف کامل وضعیت از سیستم نیست؛ بلکه وضعیت پایدار باید در محل مشخص و کنترل‌شده مدیریت شود.

۹. حملات اختلال سرویس و افزایش غیرعادی هزینه‌ها

یکی از مزیت‌های Serverless، امکان افزایش ظرفیت پردازش متناسب با تقاضا است.

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

فرض کنید یک API عمومی برای هر درخواست، تابعی را اجرا می‌کند که عملیات نسبتاً سنگینی انجام می‌دهد.

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

این وضعیت گاهی با عنوان Denial of Wallet شناخته می‌شود؛ زیرا هدف یا نتیجه آن می‌تواند تحمیل هزینه مالی قابل‌توجه باشد.

در کنار آن، حملات Denial of Service یا DoS ممکن است ظرفیت‌های اجرایی، سهمیه‌های سرویس یا وابستگی‌های برنامه را تحت فشار قرار دهند.

مقیاس‌پذیری خودکار به معنای مقاومت نامحدود در برابر حملات نیست.

راهکارهای پیشگیری:

برای APIها محدودیت نرخ درخواست یا Rate Limiting تعریف کنید.

در نقاط ورود HTTP، از WAF و کنترل‌های ضدسوءاستفاده متناسب استفاده کنید.

محدودیت هم‌زمانی اجرای توابع را بر اساس نیاز واقعی تنظیم کنید.

برای درخواست‌های پرهزینه، محدودیت مصرف و احراز هویت در نظر بگیرید.

هشدارهای هزینه، تعداد فراخوانی، مدت اجرا و نرخ خطا را فعال کنید.

همچنین باید توجه داشت که محدودکردن هم‌زمانی ممکن است ظرفیت پاسخ‌گویی به کاربران واقعی را نیز کاهش دهد؛ بنابراین، تنظیم آن باید بر اساس آزمایش بار و نیاز کسب‌وکار انجام شود.

۱۰. حملات زنجیره‌ای و گسترش دسترسی میان توابع

Function Chaining به ارتباط و فعال‌سازی چند تابع در یک جریان پردازشی اشاره دارد.

این الگو در معماری‌های Serverless رایج است و برای تقسیم وظایف و ساده‌سازی توسعه استفاده می‌شود.

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

برای مثال، تابع دریافت فایل ممکن است تنها نیازمند دسترسی به فضای ذخیره‌سازی باشد.

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

این وضعیت می‌تواند احتمال Lateral Movement یا حرکت جانبی در محیط ابری را بیشتر کند.

منظور از حرکت جانبی، گسترش دسترسی از یک بخش آسیب‌دیده به منابع و سرویس‌های دیگر است.

راهکارهای پیشگیری:

توابع را بر اساس مسئولیت‌های مشخص طراحی کنید.

نقش‌های دسترسی را تا حد امکان از یکدیگر جدا نگه دارید.

ارتباط میان سرویس‌ها را به مسیرهای ضروری محدود کنید.

برای عملیات حساس، مجوزهای مستقل و کنترل‌های اضافی تعریف کنید.

همچنین مسیرهای ارتباطی و وابستگی توابع باید در بازبینی‌های معماری امنیتی بررسی شوند.

هدف این است که حتی در صورت بروز مشکل در یک تابع، دامنه آسیب به همان بخش محدود بماند.

۱۱. ضعف ثبت رویدادها و نظارت امنیتی

Logging و Monitoring از مهم‌ترین اجزای امنیت برنامه‌های Serverless هستند.

در سامانه‌های سنتی، تیم امنیت ممکن است به فایل‌های سیستم، فرایندهای فعال و اطلاعات میزبان دسترسی داشته باشد.

اما در محیط Serverless، توابع می‌توانند برای مدت کوتاهی اجرا شوند و سپس محیط اجرایی آن‌ها تغییر کند.

به همین دلیل، ثبت اطلاعات امنیتی باید مستقل از عمر محیط اجرا طراحی شود.

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

از سوی دیگر، ثبت تمام اطلاعات ورودی نیز راهکار مناسبی نیست؛ زیرا ممکن است داده‌های حساس کاربران در لاگ‌ها ذخیره شوند.

راهکارهای پیشگیری:

ثبت رویدادهای ساختاریافته را فعال کنید.

برای هر درخواست، شناسه پیگیری یا Correlation ID در نظر بگیرید.

رویدادهایی مانند خطای احراز هویت، تغییر مجوزها، دسترسی غیرعادی به اسرار و افزایش فراخوانی‌ها را زیر نظر بگیرید.

از سامانه‌های متمرکز مانند Amazon CloudWatch، Azure Monitor و Google Cloud Logging متناسب با زیرساخت استفاده کنید.

برای تشخیص الگوهای مشکوک، ارسال داده‌های امنیتی به SIEM نیز می‌تواند مفید باشد.

دسترسی به لاگ‌ها باید محدود باشد و مدت نگهداری اطلاعات مطابق الزامات امنیتی و قانونی تنظیم شود.

۱۲. پیکربندی اشتباه سرویس‌های ابری

Security Misconfiguration یکی از خطرات مهم در بیشتر معماری‌های ابری است.

در Serverless، تنظیمات نادرست ممکن است باعث عمومی‌شدن یک API، اعطای مجوزهای غیرضروری یا دسترسی ناخواسته به منابع ذخیره‌سازی شود.

برای مثال، ممکن است یک تابع آزمایشی با دسترسی عمومی ایجاد شده باشد و پس از انتقال پروژه به محیط عملیاتی، همان تنظیمات باقی بماند.

همچنین امکان دارد سیاست‌های دسترسی منابع، تنظیمات شبکه یا مجوزهای سرویس‌های مدیریت‌شده به‌درستی بررسی نشده باشند.

وجود سرویس مدیریت‌شده به معنای امن‌بودن خودکار تمام تنظیمات آن نیست.

راهکارهای پیشگیری:

تنظیمات امنیتی را با Infrastructure as Code یا IaC مدیریت کنید.

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

قبل از استقرار، تنظیمات از نظر مجوزهای گسترده، منابع عمومی و سیاست‌های ناامن بررسی شوند.

برای محیط توسعه و تولید از تنظیمات و هویت‌های جداگانه استفاده کنید.

ابزارهای Cloud Security Posture Management یا CSPM نیز می‌توانند در شناسایی برخی خطاهای پیکربندی کمک کنند.

بازبینی تنظیمات باید پس از هر تغییر مهم در معماری تکرار شود.

۱۳. پردازش ناامن داده و Serialization

بسیاری از توابع Serverless اطلاعات را در قالب JSON، XML یا سایر ساختارهای داده دریافت و پردازش می‌کنند.

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

یکی از نمونه‌ها Insecure Deserialization است که در برخی فناوری‌ها می‌تواند آثار امنیتی جدی داشته باشد.

میزان خطر به زبان برنامه‌نویسی، کتابخانه مورد استفاده و نوع داده‌های پذیرفته‌شده بستگی دارد.

همچنین پردازش XML با تنظیمات نامناسب ممکن است در شرایط مشخص، مشکلاتی مانند XML External Entity یا XXE ایجاد کند.

راهکارهای پیشگیری:

برای تبادل داده از قالب‌های استاندارد و ساختارهای مشخص استفاده کنید.

نوع داده‌های ورودی را محدود نگه دارید.

از قابلیت‌های ناامن تبدیل داده‌های غیرقابل‌اعتماد به اشیای اجرایی استفاده نکنید.

کتابخانه‌های پردازش داده را به‌روز نگه دارید.

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

بهتر است داده‌های ورودی قبل از ورود به منطق اصلی برنامه، اعتبارسنجی و به ساختار داخلی مشخص تبدیل شوند.

۱۴. بازپخش رویدادها و پردازش تکراری عملیات

در بسیاری از سامانه‌های رویدادمحور، تحویل یک پیام ممکن است بیش از یک بار اتفاق بیفتد.

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

اگر برنامه برای این شرایط طراحی نشده باشد، یک عملیات ممکن است چند بار اجرا شود.

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

اگر همان رویداد دوباره پردازش شود و سامانه کنترل مناسبی نداشته باشد، احتمال ثبت تکراری اعتبار وجود دارد.

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

راهکارهای پیشگیری:

برای عملیات حساس از Idempotency یا طراحی تکرارپذیرِ بدون اثر اضافی استفاده کنید.

در این رویکرد، اجرای مجدد یک رویداد یکسان نباید نتیجه تجاری اضافی ایجاد کند.

برای هر عملیات، شناسه یکتا ثبت کنید.

وضعیت پردازش را در یک ذخیره‌سازی پایدار نگه دارید.

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

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

تهدیدهای امنیتی HTTP و API در معماری Serverless

بسیاری از برنامه‌های Serverless از طریق API در اختیار کاربران قرار می‌گیرند.

در این معماری، API Gateway یا سرویس مشابه معمولاً یکی از مهم‌ترین نقاط ورود است.

بااین‌حال، قرارگرفتن تابع پشت API Gateway به معنای رفع خودکار آسیب‌پذیری‌های برنامه نیست.

خطر Cross-Site Scripting یا XSS

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

در معماری Serverless، تابع ممکن است داده‌ای تولید کند که در صفحه وب نمایش داده می‌شود.

اگر برنامه در مرحله تولید یا نمایش خروجی، رمزگذاری متناسب با زمینه را رعایت نکند، امکان بروز XSS وجود دارد.

راهکار اصلی شامل Output Encoding، مدیریت امن محتوای پویا و استفاده از سیاست‌هایی مانند Content Security Policy به‌عنوان لایه دفاعی مکمل است.

خطر Cross-Site Request Forgery یا CSRF

CSRF به سوءاستفاده از وضعیت احراز هویت مرورگر برای ارسال درخواست ناخواسته اشاره دارد.

این آسیب‌پذیری به استفاده از Serverless وابسته نیست، اما APIهای مبتنی بر کوکی و نشست مرورگر همچنان می‌توانند در معرض آن باشند.

برای کاهش خطر، باید از کنترل‌هایی مانند CSRF Token، تنظیم مناسب ویژگی SameSite کوکی‌ها و بررسی Origin در سناریوهای مرتبط استفاده شود.

انتخاب کنترل مناسب به شیوه احراز هویت و نحوه فراخوانی API بستگی دارد.

نقش WAF در محافظت از توابع Serverless

Web Application Firewall یا WAF یکی از ابزارهای دفاعی برای بررسی و کنترل بخشی از ترافیک HTTP و HTTPS است.

WAF می‌تواند در شناسایی یا محدودسازی برخی درخواست‌های مشکوک، الگوهای شناخته‌شده حمله و سوءاستفاده‌های پرتکرار مفید باشد.

بااین‌حال، WAF جایگزین اعتبارسنجی ورودی، کنترل دسترسی یا منطق امن برنامه نیست.

همچنین این ابزار به‌صورت مستقیم تمام رویدادهای غیرHTTP، مانند پیام‌های صف یا رویدادهای ذخیره‌سازی را محافظت نمی‌کند.

بنابراین، استفاده از WAF باید بخشی از راهبرد دفاع چندلایه باشد.

چگونه یک معماری Serverless امن طراحی کنیم؟

طراحی امن باید قبل از نوشتن کد آغاز شود.

اگر مرزهای اعتماد، مجوزها و جریان داده از ابتدا مشخص نباشند، اصلاح آن‌ها پس از گسترش پروژه دشوارتر خواهد شد.

مرحله اول: شناسایی دارایی‌های حساس

در ابتدا باید مشخص شود کدام منابع بیشترین اهمیت امنیتی را دارند.

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

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

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

مرحله دوم: ترسیم جریان داده و مرزهای اعتماد

یکی از اقدامات ضروری، تهیه نمودار Data Flow است.

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

برای نمونه، مسیر ثبت سفارش می‌تواند شامل مراحل زیر باشد:

1. کاربر درخواست ثبت سفارش را ارسال می‌کند.
2. API Gateway درخواست را دریافت می‌کند.
3. سامانه احراز هویت، هویت درخواست‌دهنده را بررسی می‌کند.
4. تابع سفارش، داده‌ها و مجوزهای کاربر را اعتبارسنجی می‌کند.
5. اطلاعات سفارش در پایگاه داده ثبت می‌شود.
6. پیام مناسب در صف قرار می‌گیرد.
7. تابع پردازش، عملیات بعدی را انجام می‌دهد.
8. نتیجه در سامانه نظارت ثبت می‌شود.

در هر مرحله باید مشخص شود داده از یک مرز اعتماد عبور می‌کند یا خیر.

این بررسی برای Threat Modeling یا مدل‌سازی تهدید اهمیت زیادی دارد.

مرحله سوم: جداسازی وظایف و مجوزها

بهتر است هر تابع مسئولیت محدود و مشخصی داشته باشد.

تابعی که تنها تصاویر را پردازش می‌کند، معمولاً نباید به اطلاعات پرداخت یا مدیریت کاربران دسترسی داشته باشد.

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

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

بنابراین، هدف ایجاد تعادل میان استقلال وظایف، سادگی مدیریت و محدودسازی سطح دسترسی است.

مرحله چهارم: محافظت از داده‌های حساس

داده‌ها باید در زمان انتقال و ذخیره‌سازی متناسب با حساسیت آن‌ها محافظت شوند.

استفاده از TLS برای ارتباطات شبکه، رمزنگاری داده‌های ذخیره‌شده و مدیریت مناسب کلیدها اهمیت دارد.

همچنین باید مشخص شود چه کسانی اجازه مشاهده، تغییر و حذف داده‌ها را دارند.

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

مرحله پنجم: ایجاد کنترل‌های امنیتی در مسیر استقرار

کد و پیکربندی نباید بدون بررسی امنیتی وارد محیط عملیاتی شوند.

فرایند CI/CD باید شامل بررسی کد، تحلیل وابستگی‌ها، کنترل فایل‌های زیرساخت و ارزیابی تنظیمات حساس باشد.

همچنین حساب یا هویت مورد استفاده برای استقرار باید فقط مجوزهای ضروری را در اختیار داشته باشد.

جداسازی مجوزهای توسعه، آزمون و تولید نیز خطر تغییر غیرمجاز محیط عملیاتی را کاهش می‌دهد.

امنیت Serverless در AWS، Azure و Google Cloud

اگرچه اصول اصلی Serverless Security در پلتفرم‌های مختلف مشابه هستند، ابزارها و تنظیمات اجرای این اصول تفاوت دارند.

امنیت AWS Lambda

در AWS Lambda، IAM یکی از مهم‌ترین ابزارهای تعیین مجوز اجرای توابع و دسترسی آن‌ها به سایر منابع است.

برای محافظت مناسب باید نقش اجرایی هر تابع بررسی شود.

همچنین استفاده از AWS Secrets Manager برای مدیریت اسرار حساس، Amazon CloudWatch برای نظارت و ابزارهای ارزیابی تنظیمات امنیتی می‌تواند مفید باشد.

در معماری‌های HTTP، استفاده از کنترل‌های API Gateway و در صورت نیاز AWS WAF اهمیت دارد.

قابلیت Code Signing نیز در سناریوهای پشتیبانی‌شده می‌تواند برای بررسی امضای بسته‌های استقرار استفاده شود.

در صورت استفاده از این قابلیت باید سیاست مربوط به پذیرش یا رد بسته‌های فاقد اعتبار به‌درستی تنظیم شود.

امنیت Azure Functions

در Azure Functions، استفاده از Managed Identity امکان دسترسی به سرویس‌های سازگار را بدون مدیریت مستقیم اعتبارنامه‌های ثابت فراهم می‌کند.

برای مدیریت اسرار می‌توان از Azure Key Vault استفاده کرد.

Microsoft Entra ID نیز در سناریوهای مناسب برای احراز هویت و کنترل دسترسی کاربرد دارد.

ابزارهایی مانند Azure Monitor و Application Insights به نظارت بر عملکرد و رفتار برنامه کمک می‌کنند.

در صورت نیاز به محافظت از APIها، Azure API Management و کنترل‌های شبکه متناسب با طرح میزبانی قابل استفاده هستند.

باید توجه داشت که کلید دسترسی یک تابع به‌تنهایی جایگزین احراز هویت کامل کاربران و کنترل مجوزهای آن‌ها نیست.

امنیت Google Cloud Run Functions

در Google Cloud، IAM و Service Accountها نقش اصلی را در تعیین هویت و مجوز سرویس‌ها دارند.

برای ارتباط امن میان سرویس‌ها، می‌توان از هویت سرویس و توکن‌های معتبر متناسب با مدل احراز هویت استفاده کرد.

Google Secret Manager برای نگهداری اسرار و Cloud Logging برای ثبت رویدادها کاربرد دارند.

دسترسی عمومی یا خصوصی به سرویس باید آگاهانه و متناسب با نیاز برنامه تنظیم شود.

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

آیا یکی از این پلتفرم‌ها ذاتاً امن‌تر است؟

نمی‌توان صرفاً بر اساس نام ارائه‌دهنده نتیجه گرفت که یک برنامه Serverless امن‌تر خواهد بود.

هر سه اکوسیستم امکانات امنیتی مختلفی دارند، اما نحوه استفاده از این امکانات اهمیت تعیین‌کننده‌ای دارد.

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

بنابراین، هنگام انتخاب ارائه‌دهنده باید امکانات موردنیاز، الزامات قانونی، قابلیت‌های نظارت، هزینه کنترل‌های امنیتی و توان تیم فنی بررسی شود.

امنیت زنجیره توسعه و استقرار در Serverless

Serverless Security تنها به زمان اجرای تابع محدود نمی‌شود.

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

بررسی امنیت کد با SAST

Static Application Security Testing یا SAST روشی برای بررسی کد بدون اجرای برنامه است.

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

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

آزمون امنیت پویا با DAST

Dynamic Application Security Testing یا DAST بر بررسی رفتار برنامه در زمان اجرا تمرکز دارد.

این روش برای ارزیابی APIها و نقاط ورود HTTP کاربرد دارد.

در معماری Serverless باید توجه داشت که بخشی از منطق برنامه ممکن است از طریق رویدادهای غیرHTTP اجرا شود.

بنابراین، DAST به‌تنهایی پوشش کاملی از سطح حمله فراهم نمی‌کند.

بررسی وابستگی‌ها با SCA

SCA برای شناسایی اجزای نرم‌افزاری و آسیب‌پذیری‌های شناخته‌شده آن‌ها استفاده می‌شود.

این موضوع به‌ویژه در توابع Serverless که وابستگی‌های شخص ثالث فراوان دارند اهمیت دارد.

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

ارزیابی امنیت Infrastructure as Code

در معماری Serverless بسیاری از تنظیمات زیرساخت از طریق فایل‌های پیکربندی مدیریت می‌شوند.

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

بررسی امنیت این فایل‌ها می‌تواند خطاهای پیکربندی را پیش از استقرار شناسایی کند.

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

کنترل امنیت Pipeline

فرایند CI/CD خود نیز یکی از دارایی‌های حساس سازمان است.

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

بهتر است از اعتبارنامه‌های کوتاه‌مدت، هویت‌های محدود و کنترل تأیید تغییرات استفاده شود.

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

نقش مدل Zero Trust در امنیت Serverless

Zero Trust یک رویکرد امنیتی است که بر اعتمادنکردن پیش‌فرض به کاربران، دستگاه‌ها و سرویس‌ها تأکید دارد.

در این مدل، دسترسی باید بر اساس هویت، مجوز و شرایط درخواست ارزیابی شود.

این رویکرد با معماری Serverless سازگاری مفهومی خوبی دارد؛ زیرا برنامه‌ها معمولاً از سرویس‌های متعدد و ارتباطات توزیع‌شده تشکیل می‌شوند.

اعتماد نکردن خودکار به سرویس‌های داخلی

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

این فرض در معماری‌های ابری می‌تواند خطرناک باشد.

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

استفاده از هویت اختصاصی برای هر سرویس

هر تابع یا سرویس باید از هویت مشخص استفاده کند.

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

هویت اختصاصی کمک می‌کند هر سرویس تنها به منابع موردنیاز خود دسترسی داشته باشد.

کنترل مستمر مجوزها

اصل Zero Trust به معنای تأیید مجدد همه‌چیز در هر خط کد نیست.

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

برای مثال، یک تابع پردازش سفارش باید علاوه بر دریافت پیام معتبر، مجوز انجام عملیات حساس و سازگاری وضعیت سفارش را نیز بررسی کند.

تست امنیت Serverless چگونه انجام می‌شود؟

آزمون امنیت معماری Serverless باید ترکیبی از بررسی کد، پیکربندی، ارتباط سرویس‌ها و رفتار اجرایی باشد.

تمرکز صرف بر تست نفوذ یک API ممکن است بخش مهمی از خطرات مربوط به IAM و رویدادهای داخلی را نادیده بگیرد.

بررسی معماری و مدل‌سازی تهدید

اولین مرحله، شناسایی اجزای سیستم است.

باید مشخص شود هر تابع چه وظیفه‌ای دارد، چگونه اجرا می‌شود، چه داده‌هایی دریافت می‌کند و به کدام منابع دسترسی دارد.

سپس سناریوهای تهدید بر اساس مرزهای اعتماد و ارزش دارایی‌ها تحلیل می‌شوند.

چارچوب‌هایی مانند STRIDE می‌توانند برای دسته‌بندی تهدیدهای جعل هویت، تغییر داده، انکار عملیات، افشای اطلاعات، اختلال سرویس و افزایش سطح دسترسی مفید باشند.

بررسی مجوزهای IAM

در این مرحله، نقش‌های اجرایی و سیاست‌های دسترسی بررسی می‌شوند.

هدف شناسایی مجوزهای اضافی و مسیرهای دسترسی غیرضروری است.

برای هر تابع باید مشخص شود کدام عملیات واقعاً ضروری است.

مجوزهایی که دیگر استفاده نمی‌شوند یا بیش از دامنه نیاز هستند، باید اصلاح شوند.

آزمون ورودی‌ها و منطق کسب‌وکار

ورودی‌های HTTP، پیام‌های صف، رویدادهای ذخیره‌سازی و داده‌های دریافتی از سرویس‌های دیگر باید بررسی شوند.

در آزمون‌های مجاز می‌توان اعتبارسنجی ساختار داده، رفتار خطا، کنترل دسترسی و مدیریت رویدادهای تکراری را ارزیابی کرد.

همچنین باید بررسی شود که یک عملیات حساس بدون احراز هویت یا مجوز مناسب انجام نمی‌شود.

ارزیابی مدیریت اسرار

در این مرحله باید مشخص شود اطلاعات محرمانه کجا نگهداری می‌شوند و چه هویت‌هایی به آن‌ها دسترسی دارند.

بررسی مخازن کد، تنظیمات استقرار و سیاست‌های سرویس مدیریت اسرار اهمیت دارد.

همچنین باید فرایند چرخش و ابطال کلیدها قابل اجرا باشد.

آزمون محدودیت منابع

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

این آزمون‌ها باید در محیط کنترل‌شده و با مجوز انجام شوند.

هدف، اندازه‌گیری ظرفیت و اطمینان از عملکرد کنترل‌های حفاظتی است؛ نه ایجاد اختلال در سرویس عملیاتی.

بررسی قابلیت شناسایی رخداد

یک سامانه امن باید بتواند رفتارهای غیرعادی را ثبت و تحلیل کند.

برای مثال، تیم امنیت باید بداند آیا افزایش ناگهانی فراخوانی‌ها، تغییر غیرمجاز مجوزها یا تلاش‌های مکرر ناموفق برای دسترسی شناسایی می‌شوند یا خیر.

نتایج آزمون باید به اصلاح قوانین هشدار و بهبود فرایند پاسخ‌گویی منجر شوند.

چگونه حملات به معماری Serverless را شناسایی کنیم؟

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

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

شاخص‌های مهم برای نظارت

برخی شاخص‌های مهم عبارت‌اند از:

• تعداد فراخوانی‌های هر تابع
• میزان خطاهای اجرایی
• مدت‌زمان اجرای توابع
• تعداد اجراهای هم‌زمان
• تعداد درخواست‌های ناموفق احراز هویت
• تغییرات سیاست‌های IAM
• الگوهای دسترسی به اسرار
• ارتباطات خروجی غیرعادی
• افزایش غیرمنتظره هزینه‌ها
• رویدادهای حذف یا تغییر منابع حساس

هر شاخص باید با رفتار معمول برنامه مقایسه شود.

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

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

اهمیت Distributed Tracing

Distributed Tracing روشی برای ردیابی یک درخواست در میان چند سرویس است.

در معماری Serverless، یک عملیات ممکن است از API Gateway به چند تابع، صف و پایگاه داده منتقل شود.

بدون شناسه پیگیری مشترک، تشخیص منشأ خطا یا رفتار غیرعادی دشوار می‌شود.

ابزارهای ردیابی توزیع‌شده می‌توانند ارتباط میان اجزای برنامه را واضح‌تر کنند.

البته اطلاعات ثبت‌شده در Trace نیز باید از نظر محرمانگی کنترل شوند.

ارتباط مانیتورینگ با SIEM

Security Information and Event Management یا SIEM برای گردآوری و تحلیل رویدادهای امنیتی استفاده می‌شود.

در سازمان‌هایی که چندین سرویس ابری دارند، SIEM می‌تواند امکان تحلیل یکپارچه رویدادها را فراهم کند.

برای مثال، تغییر مجوز یک هویت و افزایش دسترسی به یک منبع حساس ممکن است در دو سرویس مختلف ثبت شوند.

تحلیل ارتباط میان این رویدادها می‌تواند در تشخیص یک رخداد امنیتی کمک کند.

پاسخ‌گویی به رخدادهای امنیتی Serverless

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

Incident Response در محیط Serverless باید با ویژگی‌های زیرساخت مدیریت‌شده سازگار باشد.

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

در صورت مشاهده رفتار مشکوک، ابتدا باید دامنه رخداد مشخص شود.

تیم امنیت باید بررسی کند کدام توابع، هویت‌ها، داده‌ها و منابع تحت تأثیر قرار گرفته‌اند.

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

محدودسازی دسترسی‌های مشکوک

اگر نشانه‌ای از سوءاستفاده وجود دارد، باید مسیرهای مرتبط به‌شکل کنترل‌شده محدود شوند.

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

اقدامات محدودسازی باید با توجه به وابستگی‌های سامانه انجام شوند تا اختلال غیرضروری ایجاد نشود.

حفظ شواهد

به دلیل ماهیت موقت محیط‌های اجرایی، جمع‌آوری شواهد باید بر اطلاعات ثبت‌شده در سرویس‌های ابری متکی باشد.

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

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

اصلاح و بازیابی

پس از شناسایی علت، باید نقص امنیتی در کد یا پیکربندی اصلاح شود.

همچنین اعتبارنامه‌های در معرض خطر باید جایگزین شوند.

نسخه سالم برنامه باید از مسیر استقرار مورداعتماد منتشر شود.

پس از بازیابی نیز نظارت تقویت می‌شود تا اطمینان حاصل شود رفتار مشکوک تکرار نشده است.

بررسی درس‌آموخته‌ها

پس از پایان حادثه، لازم است فرایند Post-Incident Review انجام شود.

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

هدف، اصلاح فرایندها و کاهش ریسک آینده است.

اشتباهات رایج در پیاده‌سازی Serverless Security

بخش مهمی از مشکلات امنیتی معماری Serverless ناشی از فرضیات نادرست و تصمیم‌های شتاب‌زده در طراحی است.

اعتماد کامل به امنیت ارائه‌دهنده ابری

یکی از اشتباهات رایج این است که تیم توسعه تصور کند تمام مسئولیت‌های امنیتی به ارائه‌دهنده منتقل شده‌اند.

درحالی‌که امنیت کد، هویت‌ها، مجوزها و داده‌ها همچنان نیازمند کنترل مستقل است.

استفاده از یک نقش IAM برای تمام توابع

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

بهتر است نقش‌ها بر اساس نیاز واقعی وظایف تعریف شوند.

ذخیره کلیدهای حساس در کد

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

اطلاعات حساس باید از طریق سازوکارهای مدیریت اسرار و هویت‌های محدود در اختیار برنامه قرار گیرند.

اعتماد به داده‌های سرویس‌های داخلی

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

اما داده اولیه ممکن است از کاربر یا منبع دیگری وارد سیستم شده باشد.

بنابراین، کنترل ورودی در مرزهای اعتماد ضروری است.

نادیده گرفتن رویدادهای تکراری

در معماری رویدادمحور، اجرای تکراری یک پیام باید در طراحی پیش‌بینی شود.

اگر عملیات مالی یا تغییر وضعیت بدون کنترل تکرار انجام شود، ممکن است پیامدهای تجاری مهمی ایجاد شود.

اتکای کامل به WAF

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

ثبت اطلاعات حساس در لاگ‌ها

ذخیره کامل درخواست‌ها ممکن است باعث افشای توکن‌ها، اطلاعات کاربران یا داده‌های محرمانه شود.

ثبت رویدادها باید متناسب با نیاز امنیتی و با حذف یا پوشاندن اطلاعات حساس انجام شود.

بی‌توجهی به هزینه اجرای توابع

نبود هشدار و محدودیت مناسب می‌تواند باعث افزایش هزینه در شرایط سوءاستفاده یا خطای برنامه شود.

هزینه مصرف منابع باید بخشی از نظارت عملیاتی و امنیتی باشد.

چک‌لیست امنیت معماری Serverless

برای ارزیابی وضعیت امنیتی یک برنامه Serverless، می‌توان کنترل‌های زیر را به‌صورت دوره‌ای بررسی کرد.

امنیت هویت و مجوزها

1. برای هر تابع، سطح دسترسی موردنیاز مشخص شده باشد.
2. مجوزهای اضافی و گسترده حذف شده باشند.
3. نقاط ورود حساس به احراز هویت معتبر نیاز داشته باشند.
4. مجوز کاربران برای هر عملیات حساس بررسی شود.
5. هویت‌های سرویس‌ها تا حد امکان مستقل باشند.
6. اعتبارنامه‌های ثابت غیرضروری حذف شده باشند.

امنیت کد و ورودی‌ها

1. تمام ورودی‌های غیرقابل‌اعتماد اعتبارسنجی شوند.
2. ارتباط با پایگاه داده از روش‌های امن پرس‌وجو استفاده کند.
3. داده‌های خروجی متناسب با محل نمایش رمزگذاری شوند.
4. قابلیت‌های پردازش داده ناامن غیرفعال باشند.
5. رویدادهای تکراری باعث اجرای چندباره عملیات حساس نشوند.
6. خطاها اطلاعات داخلی و محرمانه را آشکار نکنند.

امنیت داده‌ها و اسرار

1. کلیدها و رمزهای حساس داخل کد قرار نداشته باشند.
2. اسرار از طریق سرویس مدیریت مناسب نگهداری شوند.
3. دسترسی به هر Secret محدود باشد.
4. فرایند چرخش و ابطال اعتبارنامه‌ها تعریف شده باشد.
5. داده‌های حساس در انتقال و ذخیره‌سازی محافظت شوند.
6. اطلاعات محرمانه در لاگ‌ها و فایل‌های موقت باقی نمانند.

امنیت زیرساخت و استقرار

1. پیکربندی زیرساخت نسخه‌بندی شده باشد.
2. سیاست‌های IAM و منابع عمومی قبل از استقرار بررسی شوند.
3. وابستگی‌های نرم‌افزاری اسکن شوند.
4. هویت‌های CI/CD مجوزهای محدود داشته باشند.
5. بسته‌های استقرار از نظر منشأ و یکپارچگی بررسی شوند.
6. محیط‌های توسعه و تولید به‌درستی تفکیک شده باشند.

نظارت و پاسخ‌گویی

1. لاگ‌های امنیتی به‌صورت متمرکز جمع‌آوری شوند.
2. هشدارهای مربوط به مجوزها و دسترسی‌ها فعال باشند.
3. تعداد فراخوانی‌ها و هزینه‌ها نظارت شوند.
4. مسیر درخواست‌ها در سرویس‌های مرتبط قابل پیگیری باشد.
5. برنامه پاسخ‌گویی به رخداد تدوین شده باشد.
6. فرایند بازیابی و ابطال اعتبارنامه‌ها آزمایش شده باشد.

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

اولویت‌بندی خطرات امنیتی Serverless

تمام تهدیدهای امنیتی اهمیت یکسانی ندارند.

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

برای مثال، یک تابع عمومی که به اطلاعات مالی دسترسی دارد، معمولاً به کنترل‌های سخت‌گیرانه‌تری نسبت به یک تابع داخلی با داده‌های غیرحساس نیاز دارد.

خطرات با اولویت بالا

• دسترسی عمومی غیرضروری به عملیات حساس
• مجوزهای IAM گسترده
• افشای اعتبارنامه‌های مهم
• ضعف کنترل دسترسی به داده‌های کاربران
• آسیب‌پذیری‌های جدی در مسیر پردازش ورودی
• امکان انجام تکراری عملیات مالی یا حساس

خطرات با اولویت وابسته به شرایط

• نبود محدودیت نرخ درخواست
• استفاده از وابستگی‌های قدیمی
• مدیریت نامناسب فایل‌های موقت
• ضعف ثبت رویدادهای امنیتی
• نبود محدودیت مناسب در ارتباطات خروجی

این دسته‌بندی مطلق نیست.

برای مثال، نبود محدودیت درخواست در یک API عمومی پرهزینه ممکن است به یک خطر فوری تبدیل شود.

بنابراین، تیم امنیت باید اولویت‌ها را بر اساس معماری واقعی و اهمیت منابع تعیین کند.

آینده امنیت Serverless و چالش‌های جدید

با گسترش رایانش ابری، استفاده از معماری‌های رویدادمحور و توابع مدیریت‌شده در برنامه‌های مختلف افزایش یافته است.

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

افزایش اهمیت هویت‌های ماشینی

در یک سامانه Serverless ممکن است تعداد سرویس‌ها و هویت‌های اجرایی بسیار بیشتر از تعداد کاربران انسانی باشد.

مدیریت مجوز این هویت‌ها، جلوگیری از استفاده از اعتبارنامه‌های ثابت و بررسی دسترسی‌های غیرضروری از چالش‌های مهم امنیتی است.

استفاده گسترده‌تر از DevSecOps

DevSecOps رویکردی است که کنترل‌های امنیتی را با فرایند توسعه و عملیات نرم‌افزار یکپارچه می‌کند.

در معماری Serverless، خودکارسازی بررسی کد، وابستگی‌ها و پیکربندی زیرساخت می‌تواند به کاهش خطاهای تکراری کمک کند.

تحلیل رفتار برای شناسایی ناهنجاری‌ها

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

برای مثال، افزایش غیرمعمول دسترسی یک تابع به منابع حساس می‌تواند نیازمند بررسی باشد.

بااین‌حال، تشخیص ناهنجاری به معنای اثبات حمله نیست و نتایج آن باید با سایر شواهد ترکیب شود.

اهمیت امنیت چندابری

سازمان‌هایی که از چند ارائه‌دهنده خدمات ابری استفاده می‌کنند، با چالش یکپارچه‌سازی سیاست‌های دسترسی و نظارت روبه‌رو هستند.

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

سؤالات متداول درباره Serverless Security

Serverless Security چیست؟

Serverless Security مجموعه‌ای از راهکارها برای حفاظت از توابع، APIها، داده‌ها، مجوزها و سایر اجزای معماری بدون سرور است. این رویکرد بر کنترل دسترسی، امنیت کد، مدیریت اسرار، محافظت از رویدادها و نظارت امنیتی تمرکز دارد.

آیا معماری Serverless از سرورهای سنتی امن‌تر است؟

معماری Serverless می‌تواند بخشی از مسئولیت مدیریت و سخت‌سازی زیرساخت را کاهش دهد، اما امنیت نهایی به طراحی و تنظیمات برنامه بستگی دارد. یک برنامه Serverless با مجوزهای گسترده یا کد آسیب‌پذیر همچنان می‌تواند ناامن باشد.

مهم‌ترین تهدید امنیتی Serverless چیست؟

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

آیا AWS Lambda در برابر حملات سایبری آسیب‌پذیر است؟

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

آیا برای امنیت Serverless به فایروال نیاز داریم؟

برای نقاط ورود HTTP، استفاده از WAF و کنترل‌های شبکه می‌تواند مفید باشد. بااین‌حال، تمام تهدیدهای Serverless از مسیر HTTP رخ نمی‌دهند و فایروال به‌تنهایی از رویدادهای داخلی، مجوزهای نادرست یا آسیب‌پذیری کتابخانه‌ها محافظت نمی‌کند.

آیا امکان حملات DDoS در Serverless وجود دارد؟

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

آیا متغیرهای محیطی محل مناسبی برای نگهداری رمزها هستند؟

متغیرهای محیطی برای تنظیمات عملیاتی مفید هستند، اما نگهداری اسرار حساس به سطح دسترسی و سیاست‌های امنیتی وابسته است. برای اطلاعات مهم، استفاده از سرویس مدیریت اسرار و هویت‌های محدود معمولاً انتخاب مناسب‌تری است.

تفاوت امنیت Serverless با امنیت کانتینر چیست؟

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

چگونه امنیت APIهای Serverless را افزایش دهیم؟

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

آیا Serverless برای پردازش اطلاعات مالی مناسب است؟

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

آیا امنیت Serverless فقط به توسعه‌دهندگان مربوط است؟

خیر. تأمین امنیت نیازمند همکاری توسعه‌دهندگان، تیم DevOps، متخصصان امنیت، مدیران زیرساخت و مسئولان کسب‌وکار است. هر گروه در مدیریت بخشی از ریسک‌های فنی و عملیاتی نقش دارد.

هر چند وقت یک‌بار باید امنیت توابع Serverless بررسی شود؟

بررسی امنیتی بهتر است در مراحل توسعه و پیش از هر استقرار مهم انجام شود. همچنین بازبینی دوره‌ای مجوزها، وابستگی‌ها، تنظیمات و لاگ‌ها ضروری است. تناوب دقیق باید بر اساس حساسیت داده‌ها، سرعت تغییر برنامه و سطح ریسک تعیین شود.

جمع‌بندی: چگونه امنیت معماری Serverless را تضمین کنیم؟

معماری Serverless روشی انعطاف‌پذیر برای توسعه و اجرای برنامه‌های ابری است که می‌تواند بخشی از پیچیدگی مدیریت زیرساخت را کاهش دهد.

بااین‌حال، حذف مدیریت مستقیم سرور به معنای حذف تهدیدهای امنیتی نیست.

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

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

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

1. طراحی معماری بر اساس اصل حداقل دسترسی
2. احراز هویت و کنترل مجوزهای مناسب
3. اعتبارسنجی داده‌ها و رویدادهای ورودی
4. مدیریت امن کلیدها و اطلاعات محرمانه
5. بررسی امنیت کتابخانه‌ها و زنجیره تأمین
6. محدودسازی ارتباطات و مصرف منابع
7. نظارت مستمر بر رویدادها و رفتار توابع
8. پیاده‌سازی آزمون‌های امنیتی در فرایند توسعه
9. آماده‌سازی برنامه پاسخ‌گویی به رخدادها
10. بازبینی دوره‌ای تنظیمات و سیاست‌های دسترسی

امنیت Serverless یک قابلیت منفرد یا محصول مشخص نیست؛ بلکه نتیجه طراحی صحیح، توسعه امن، مدیریت دسترسی و نظارت پیوسته است.

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

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