روابط عمومی شرکت ایدکو (توزیع‌کننده‌ی محصولات کسپرسکی در ایران)؛ ترکیب زیرساخت کلود خصوصی و عمومی که بیشترِ سازمان‌ها الان نیز از آن استفاده می‌کنند چالش‌های امنیتی منحصر به فردی را نیز با خود به همراه داشته است. دلایل زیادی وجود دارد که چرا سازمان‌ها کلود عمومی را انتخاب می‌کنند؛ از ایجاد امکان رشد سریع بدون برنامه‌ریزی برای ظرفیت گرفته تا اِعمال انعطاف‌پذیری و چابکی در تحویل خدمات مشتری‌محور. با این حال این کاربرد می‌تواند شرکتها را همچنین در معرض خطر قرار دهد. از آنجایی که الزامات نظارتی و سایر اولویت‌ها ایجاب می‌کند که برخی کاربردهای خاص روی زیرساخت عمومی باقی بماند، بسیاری از سازمان‌ها ترجیح می‌دهند ترکیبی از زیرساخت خصوصی و عمومی را داشته باشند.
افزون بر این، سازمان‌ها به طور معمول برای حرکت بین ارائه‌دهندگان از چندین ارائه‌دهنده کلود به طور همزمان استفاده می‌کنند (و یا این گزینه را نگه می‌دارند). با این وجود، رویکرد ترکیبی یا هیبریدی نیز چالش‌های امنیتی خاص خود را دارد که در ادامه بدان‌ها خواهیم پرداخت. با ما همراه بمانید. ارائه‌دهندگان مختلف کلود و پلت‌فرم‌های خصوصی کلود ممکن است قابلیت‌های مشابهی را ارائه دهند اما روش پیاده‌سازی کنترل‌های امنیتی و نیز ابزارهای مدیریتی‌شان با هم فرق دارد.
حال این سوال پیش می‌آید که: چطور یک سازمان در سراسر کلودهای مختلف می‌تواند نظارتی دائم داشته باشد و در اجرای سیاست و کنترل‌ها یکپارچه عمل کند؟ همینطور چطور می‌تواند تضمین دهد که موضع امنیتی موقع حرکت بین هر یک از آنها حفظ می‌شود؟ خوشبختانه، گام‌هایی هست که افراد حرفه‌ای می‌توانند برای تضمین امنیت دائم برنامه‌ها –از فازهای اولیه توسعه گرفته تا کل چرخه عمر- بردارند.
ابزارهای امنیتی قدیمی دیگر در کلود، کارا نیستند
ابزارهای امنیتی که خاستگاهشان از اول کلود نبوده برای محافظت اپ‌هایی که به دلایلی در کلود اجرا می‌شوند تجهیزات خوبی محسوب نمی‌شوند. ابتدا اینکه آنها نمی‌توانند به نسبت متودهای سنتی آبشار[1] چرخه‌های توسعه کلود را که به طور قابل‌ملاحظه‌ای در حال تسریع هستند مدیریت کنند. به جای انتشار نسخه‌‌ها هر چند ماه یکبار، سازمان‌هایی که CI/CD بومی کلود را پیاده‌سازی می‌کنند همواره در حال یکپارچه‌سازی و بکارگیری اپ‌ها و آپدیت‌ها هستند (برخی‌اوقات چند بار در روز). این رویکردی اتومات را می‌طلبد تا بدین‌ترتیب امنیت تضمین داده شود- رویکردی که بتوان آن را در فازهای اولیه توسعه به کار برد تا بدین‌ترتیب پروسه توسعه و روند کلی عملیات‌ها کُند نشود. علاوه بر این، در چنین محیط پویا و متنوع کلودی، راهکارهای امنیتی دیگر نمی‌توانند انتظار زیرساخت و لوکیشن دائمی را داشته باشند یا بدان‌ها وابسته باشند. اگر –در گذشته- می‌دانستیم سروری خاصی اپی خاص را اجرا می‌کند (برای مثال سرور مایکروسافت اکسچنج یا پایگاه داده) دیگر نمی‌توان همان سناریو سابق را برای امروز نیز اجرایی کرد. راهکارهای اپ کلودِ مدرن یکجورهایی به خود اپ گره خورده‌اند و نه رشته اتصالی با آدرس آی‌پی یا لوکیشن سرور خاصی ندارند. هماهنگ‌سازی خودکار ورک‌لودها بدین معناست که یک پایگاه داده ممکن است اکنون روی کانتینری اجرا شوند و ده دقیقه بعد با یک آدرس آی‌پی مختلف روی کانیتنر دیگری باشد. یا شاید فردا کلود شاخه تماماً به ارائه دهنده‌ی کلود مختلفی منتقل شود. برای همین است که سازمان‌ها باید از راهکارهای کلود محور مدرن‌تری استفاده کنند و راهکارهای قدیمی‌تر که مخصوص کلود نیستند را کنار بگذارند.
ابزارهای امنیتی مخصوص ارائه‌دهندگان کلود: پاسخی محدود
ارائه‌دهندگان اصلی کلود همه از آنچه «مدل مسئولیت مشترک[2]» نامیده می‌شود، استفاده می‌کنند، که در سطحی بسیار ساده، بین امنیت «کلود» (مسئولیت ارائه‌دهنده) و امنیت «در فضای کلود» (مسئولیت مشتری) تمایز قائل می‌شود. "مسئولیت مشترک" به معنای مسئولیت‌پذیری مشترک نیست. وقتی صحبت از امنیت فیزیکی مراکز داده کلود عمومی می‌شود، سازمان‌ها نباید نگران باشند. ارائه‌دهندگان کلود چنین امنیتی را با بالاترین استانداردها، مشابه استانداردهایی که توسط بانک‌های بزرگ و سازمان‌های دولتی استفاده می‌شود، اجرا می‌کنند. اما برای هر چیز دیگری، مسئولیت مستقیماً بر عهده سازمان‌های مشتری است - در واقع، گارتنر پیش‌بینی می‌کند که تا سال 2025، 99٪ از خرابی‌های امنیت کلود از سمت مشتری خواهد بود.
ابزارهای ارائه‌شده توسط ارائه‌دهندگان امنیت ابری (CSP) معمولاً پوشش جزئی برای نیازهای مشتری را فراهم کرده و وابستگی مشتریان را به ارائه‌دهنده کلود افزایش می‌دهند، اما در حفاظت از محیط‌های چندگانه کلود، به ویژه کلودهای خصوصی به همان اندازه مؤثر نیستند.
خبرهای خوب در بخش امنیتی
خبر خوب این است که فناوری‌ها دارند به اجرای راهکارهای جدید عادت می‌کنند؛ برای مثال کانتینرها و کوبرنتیزها[3] امنیت را از قبل بیشتر می‌کنند و بدین‌ترتیب اتوماسیون و قابلیت‌دید نیز افزایش داده خواهد شد. همچنین چنین راهکارهایی باعث می‌شود امنیت در کل محیط‌های کلود عمومی و خصوصی راحت‌تر انتقال داده شود البته به شرطی که نظارت‌های امنیتی هم به درستی پیاده‌سازی شوند. از آنجایی که کانتینرها طوری ساخته شده‌اند که پورتابل باشند و نیز کوبرنتیز طوری طراحی شده که با هر محیط کلودی کار می‌کند اگر ابزار امنیتی را که مشخصاً برای محافظت از کانتینرها طراحی شده وصل کنید، می‌توانید آنها را به طور یکپارچه هر جایی اجرا نمایید (صرف‌نظر از اینکه اپ‌ها در واقع کجا قرار دارند).
به دلیل پیچیدگی محیط‌های کلود و دخیل بودن قطعات متحرک، برنامه‌ریزی یک پشته‌ی فناوری[4] نیازمند رویکردی است جامع تا بشود از اپ‌ها در کل چرخه عمر دفاع کرد (منظور از چرخه عمر از زمان توسعه است تا تولید). چنین رویکردی باید بتواند چندین شکاف امنیتی را هم در کل اجزای زیرساخت و هم کد اپ مدیریت کند –خواه مدیریت آسیب‌پذیری باشد، خواه تنظیمات نادرست، بدافزار یا ناهنجاری‌های رفتاری.
رویکرد تولد در کلود
شرکتها اکنون نه تنها در کلود زاده شدند بلکه مشخصاً هدفشان امنیت‌دهی به پشته کلود بومی و جدید است –از کانتینرها گرفته تا VM. CNAPP (پلتفرم محافظت از اپ بومی کلود[5]) دسته‌بندی جدیدی است که گارتنر نامگذاری‌اش کرده و کار آن محافظت از اپ‌های سازمانی در برابر حملات است؛ حملاتی که با رشد کلود بیشتر نیز خواهند شد. گرچه آینده امنیت کلود روشن است اما در حال حاضر تصویر روشنی از آن آینده در دست نداریم. دلیلش هم افزایش حجم و پیچیدگی حملاتی است که به طور خاص هدفشان زیرساخت کلود و زنجیره‌های تأمین است.
یک نود Kubernetes آسیب پذیر یا نودی که بدرستی پیکربندی نشده باشد در کمتر از 20 دقیقه هدف قرار می‌گیرد. این حملات پیچیده ممکن است به پیامدهای مخرب مختلفی منجر شود، از استخراج ارزهای دیجیتال تا سرقت اطلاعات اعتبار، و از نصب روت کیت تا پیمایش شبکه. فاصله بین رقابت برای انتقال ورک‌لودها بیشتر به فضای کلود و توانایی ایمن‌سازی آن حجم کاری ریشه در کمبود دانش و مهارت دارد، اما پلتفرم‌هایی برای پر کردن این شکاف‌ها وجود دارد. مهمتر از آن، شرکتها می‌توانند به سطح بی‌سابقه‌ای از امنیت در نتیجه سطح بالای اتوماسیون سیاست‌محور، کاهش سطح حمله، و توانایی تشخیص کوچک‌ترین رانش یا ناهنجاری‌های رفتاری اجزای برنامه دست یابند. روش‌های امنیتی که بخشی جدایی ناپذیر از توسعه، استقرار و اجرای برنامه‌های کاربردی کلود هستند، در فهرست راهکارهای آتی قرار دارند.
[1]Waterfall methods یک مدل ترتیبی توسعه و تولید نرم‌افزار است و در آن مراحل تولید به شکل یک جریان مداوم متمایل به سمت پایین است (همانند یک آبشار) که شامل فازهای تحلیل خواسته‌ها، طراحی، پیاده‌سازی یا implementation، ٓازمودن و تست کردن، یکپارچه سازی یا integration، و دادن محصول به بازار می‌شود.
[2] the shared responsibility model
[3] پلتفرم متن‌باز، قابل حمل و منعطف است که برای توسعهٔ خودکار (automating deployment)، مقیاس‌گذاری (scaling) و مدیریت اپلیکیشن‌های کانتینرسازی‌شده (containerized applications) استفاده می‌شود.
[4] tech stack
[5] Cloud Native Application Protection Platform
منبع: کسپرسکی آنلاین (ایدکو)
کسپرسکی اسم یکی از بزرگترین شرکتهای امنیتی و سازنده آنتی ویروس است که برخی از کاربران اشتباهاً این شرکت و محصولات آنتی ویروس آن را با عناوینی نظیر کسپرسکای،کاسپرسکی، کسپراسکای، کسپراسکای، و یا کاسپراسکای نیز می‌شناسد. همچنین لازم به ذکر است مدیرعامل این شرکت نیز یوجین کسپرسکی نام دارد.
