ایمن سازی داده های بدون سرور از بدافزارهای رمزنگاری مانند Denonia

AWS Lambda اخیراً اولین تهدید خاص خود را با بدافزار Denonia مشاهده کرد. اگرچه تأثیر این حمله کم بود، اما اکنون زمان آن رسیده است که شرکت ها از خود بپرسند که برنامه های بدون سرور آنها چقدر ایمن هستند و چگونه می توانند برای حمله آینده آماده شوند.

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

برنامه بدون سرور من چگونه آسیب پذیر است؟

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

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

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

کنترل های دسترسی خود را سخت کنید

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

کد را در مسیر خود نگه دارید

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

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

داستان کامل بدون سرور را دریافت کنید

استراتژی‌های نظارت سنتی – که فقط بر روی معیارهای ردیابی استفاده از منابع مانند CPU و حافظه تمرکز می‌کنند، یا در مورد خدمات مدیریت شده و شخص ثالث نقاط کوری دارند – در مورد ایمن کردن برنامه‌های بدون سرور، شکاف بزرگی ایجاد می‌کنند. همانطور که برنامه شما رشد می کند و سطح حمله شما بزرگتر می شود، تکیه بر معیارها و گزارش های خام برای نظارت بر محیط های بدون سرور فقط شما را به این نتیجه می رساند. به زودی، سرویس‌ها و منابع بسیار زیادی وجود خواهند داشت که داده‌ها را تولید می‌کنند تا بفهمند کد شما کجا اشتباه کرده است و سیستم شما می‌تواند قبل از اینکه متوجه شوید مورد سوء استفاده قرار گیرد.

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

امنیت بدون سرور در آینده

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

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