امنیت ابری همه چیز در مورد پیکربندی است. در اینجا نحوه اطمینان از صحیح و ایمن بودن پیکربندی منابع ابری و نحوه حفظ آنها به این صورت آمده است.
تیمهای مهندسی و امنیت ابر باید چند سؤال مهم در مورد امنیت محیطهای ابری خود بپرسند، و باید فراتر از اینکه آیا محیطها ممیزیهای انطباق را میگذرانند یا خیر، فراتر بروند.
در عرض چند دقیقه پس از افزودن نقطه پایانی جدید به اینترنت، یک مهاجم بالقوه آن را اسکن کرده و قابلیت بهره برداری آن را ارزیابی کرده است. یک پیکربندی نادرست ابر میتواند هدفی را در پشت سازمان شما قرار دهد – و دادههای شما را در معرض خطر قرار دهد.
برای لحظهای فرض کنید که مهاجم یکی از این آسیبپذیریها را پیدا کرده و جایگاه اولیهای در محیط شما به دست میآورد. شعاع انفجار این نفوذ چقدر است؟ چه نوع آسیبی می توانند وارد کنند؟
کشف دانش در مورد محیط شما و محل ذخیره داده های حساس برای مهاجم چقدر آسان است؟ آیا آنها می توانند از کلیدهای API منابع ابری و تنظیمات بیش از حد مجاز IAM (مدیریت هویت و دسترسی) برای به خطر انداختن صفحه کنترل ابری شما و دسترسی به منابع و داده های اضافی استفاده کنند؟ آیا میتوانند آن دادهها را بدون شناسایی، مثلاً با دستور همگامسازی سطل ذخیرهسازی، در حساب ابری خودشان استخراج کنند؟
عمیقتر نگاه کنید، احتمالاً چیزی را که پیدا میکنید دوست نخواهید داشت. قبل از اینکه هکرها بتوانند از آنها سوء استفاده کنند، سریع اقدام کنید تا این شکاف ها را در امنیت ابری خود ببندید. و همچنین بدانید که “رانش” پیکربندی ابری همیشه اتفاق می افتد، حتی زمانی که از خطوط لوله خودکار CI/CD استفاده می شود، بنابراین باید مراقب باشید. یک محیط ابری که امروز بدون پیکربندی نادرست است، احتمالاً برای مدت طولانی به همین شکل باقی نخواهد ماند.
امنیت ابری امنیت پیکربندی است
کلاد اساساً یک رایانه غولپیکر قابل برنامهریزی است و عملیات ابری بر پیکربندی منابع ابری، از جمله منابع حساس به امنیت مانند IAM، گروههای امنیتی و سیاستهای دسترسی به پایگاههای داده و ذخیرهسازی اشیا متمرکز است. باید مطمئن شوید که تنظیمات منابع ابری شما در روز اول صحیح و ایمن هستند و در روز دوم نیز به همین شکل باقی می مانند.
تحلیلگران صنعت این را مدیریت وضعیت امنیت ابری (CSPM) می نامند. و این همان چیزی است که مشتریان ابری همیشه به اشتباه می افتند، گاهی اوقات با عواقب ویرانگر. اگر نقض دادهای را مشاهده کردید که شامل خدمات وب آمازون، مایکروسافت آژور یا Google Cloud میشود، این یک فرض محکم است که این حمله به دلیل اشتباهات مشتری ابری ممکن شده است.
ما تمایل زیادی به جلوگیری از پیکربندی نادرست برای منابع ابری فردی مانند سرویسهای ذخیرهسازی شی (مانند Amazon S3، Azure Blob) و شبکههای مجازی (مانند AWS VPC، Azure VNet) داریم و انجام این کار کاملاً حیاتی است. .
اما این نیز مهم است که بدانیم امنیت ابری به هویت بستگی دارد. در فضای ابری، بسیاری از سرویسها از طریق تماسهای API به یکدیگر متصل میشوند و برای امنیت به خدمات IAM نیاز دارند تا قوانین شبکه مبتنی بر IP، فایروالها و غیره.
به عنوان مثال، اتصال از یک تابع AWS Lambda به یک سطل آمازون S3 با استفاده از یک خط مشی متصل به نقشی که تابع Lambda بر عهده می گیرد، یعنی هویت سرویس آن، انجام می شود. IAM و سرویسهای مشابه پیچیده و دارای ویژگیهای غنی هستند، و سادهتر بودن بیش از حد فقط برای به کار انداختن کارها آسان است، به این معنی که پیکربندیهای بیش از حد مجاز (و اغلب خطرناک) IAM معمول هستند.
Cloud IAM شبکه جدید است، اما از آنجایی که سرویسهای IAM ابری با پیکربندی ایجاد و مدیریت میشوند، امنیت ابر همچنان به پیکربندی و جلوگیری از پیکربندی نادرست مربوط میشود.
پیکربندی نادرست ابر و حوادث امنیتی
انواع زیرساختهای ابری بسیار بیشتر از آنچه در مرکز داده وجود داشت، وجود دارد، و همه آن منابع کاملاً قابل تنظیم و تنظیم نادرست هستند. همه انواع مختلف منابع ابری موجود را در نظر بگیرید، و روشهایی را که میتوان آنها را با هم برای پشتیبانی از برنامهها ترکیب کرد، و امکانات پیکربندی عملاً بینهایت است.
در نظرسنجی سال ۲۰۲۱ ما، ۳۶٪ از متخصصان ابر گفتند که سازمان آنها در سال گذشته با نشت یا نقض جدی امنیت ابری مواجه شده است. و تعدادی از راههای ممکن شدن این حوادث وجود دارد.
منبع: گزارش وضعیت امنیت ابری ۲۰۲۱< /p>
به خاطر داشته باشید که پیکربندی منابعی مانند ذخیرهسازی اشیا و سرویسهای IAM میتوانند در محیطهای کوچکتر بسیار پیچیده شوند و هر رخنه ابری که ما از آن آگاه هستیم شامل زنجیرهای از سوءپیکربندیهای نادرست است. بهجای تمرکز صرف بر پیکربندیهای نادرست یک منبع، ضروری است که مورد استفاده خود را کاملاً درک کنید و در مورد چگونگی ایمن کردن این سرویسها در زمینه کامل محیط خود به طور انتقادی فکر کنید.
به عنوان مثال، ممکن است فکر کنید که سطل Amazon S3 شما به صورت ایمن پیکربندی شده است زیرا “Block Access Public” فعال است، زمانی که یک عامل مخرب ممکن است بتواند با استفاده از منابع IAM دارای امتیاز بیش از حد در همان محیط به محتوای آن دسترسی داشته باشد. درک خطر شعاع انفجار میتواند مشکلی برای حل آن باشد، اما مشکلی است که نمیتوان آن را نادیده گرفت.
مقیاس پیکربندی نادرست ابر
آسیبپذیریهای پیکربندی نادرست ابر با آسیبپذیریهای برنامهها و سیستمعاملها متفاوت هستند، زیرا حتی پس از رفع آنها همچنان ظاهر میشوند. احتمالاً کنترلهایی در خط لوله توسعه خود دارید تا مطمئن شوید که توسعهدهندگان آسیبپذیریهای شناختهشده برنامه یا سیستم عامل را برای تولید مستقر نمیکنند. و هنگامی که این استقرارها ایمن شوند، به طور کلی یک مشکل حل شده است.
پیکربندی نادرست ابر متفاوت است. این امری عادی است که می بینیم همان آسیب پذیری پیکربندی نادرست بارها و بارها ظاهر می شود. یک قانون گروه امنیتی که اجازه دسترسی نامحدود به SSH را می دهد (مثلاً ۰.۰.۰.۰/۰ در پورت ۲۲) تنها نمونه ای از نوع پیکربندی های نادرست است که به صورت روزانه و اغلب خارج از خط لوله استقرار تأیید شده رخ می دهد. ما از این مثال استفاده می کنیم زیرا اکثر مهندسان با آن آشنا هستند (و احتمالاً در مقطعی از حرفه خود مرتکب این عمل فاحش شده اند).
از آنجایی که زیرساختهای ابری بسیار انعطافپذیر هستند و میتوانیم آن را به دلخواه با استفاده از API تغییر دهیم، تمایل زیادی به انجام این کار داریم. این چیز خوبی است، زیرا ما دائماً در حال نوآوری و بهبود برنامه های خود هستیم و باید زیرساخت خود را برای پشتیبانی از این نوآوری اصلاح کنیم. اما اگر در طول مسیر از پیکربندی نادرست محافظت نمیکنید، انتظار داشته باشید که پیکربندی نادرست زیادی به محیط شما وارد شود. نیمی از تیم های مهندسی ابر و امنیت روزانه با ۵۰ یا بیشتر رویدادهای پیکربندی نادرست سروکار دارند.
منبع: گزارش وضعیت امنیت ابری ۲۰۲۱< /p>
چرا پیکربندی نادرست ابر رخ می دهد
اگر ما با موفقیت از ابر استفاده می کنیم، تنها عامل ثابت در محیط های ابری ما تغییر است، زیرا این بدان معناست که ما به سرعت در حال نوآوری هستیم و به طور مداوم برنامه های خود را بهبود می بخشیم.
اما هر تغییری خطراتی را به همراه دارد.
طبق گفته گارتنر، تا سال ۲۰۲۳ حداقل ۹۹ درصد از خرابی های امنیت ابری تقصیر مشتری خواهد بود. به نظر میرسد این ۱% یک مانع با توجه به پیکربندی نادرست ابری است که باعث میشود خرابیهای امنیت ابری رخ دهد، و پیکربندی نادرست ۱۰۰% نتیجه خطای انسانی است.
اما چرا مهندسان ابر چنین اشتباهات مهمی را اغلب مرتکب می شوند؟
عدم آگاهی از امنیت و خطمشیهای ابری یکی از دلایل اصلی پیکربندی نادرست ابری بود که در سال گذشته گزارش شد. همه قوانین انطباق و سیاست های امنیت داخلی خود را با هم جمع کنید و احتمالاً حجمی به ضخامت جنگ و صلح دارید. هیچ انسانی نمی تواند همه اینها را به خاطر بسپارد، و ما نباید از آنها انتظار داشته باشیم.
بنابراین، برای محافظت در برابر پیکربندی نادرست به کنترلهایی نیاز داریم. اما ۳۱ درصد می گویند که سازمان آنها فاقد کنترل و نظارت کافی برای جلوگیری از اشتباهات پیکربندی نادرست ابر هستند.
بخشی از دلیل آن این است که APIها و واسط های ابری زیادی وجود دارد که تیم ها نمی توانند به طور مؤثر اداره کنند. استفاده از پلتفرمهای ابری متعدد (گزارششده توسط ۴۵ درصد از پاسخدهندگان) تنها مشکل را تشدید میکند، زیرا هر کدام انواع منابع، ویژگیهای پیکربندی، رابطهای حاکم، سیاستها و کنترلهای خاص خود را دارند. تیم شما به تخصص نیاز دارد که به طور موثر به همه پلتفرم های ابری در حال استفاده رسیدگی کند.
اگر تیمها ابزار امنیتی بومی ارائهدهنده خدمات ابری را که در محیطهای چند ابری کار نمیکند، استفاده کنند، چالش امنیتی چند ابری بیشتر میشود.
منبع: گزارش وضعیت امنیت ابری ۲۰۲۱< /p>
هفت توصیه استراتژیک
از آنجایی که امنیت ابر در درجه اول به پیشگیری، شناسایی و اصلاح اشتباهات پیکربندی نادرست قبل از اینکه توسط هکرها مورد سوء استفاده قرار گیرند، مربوط می شود، اتوماسیون موثر مبتنی بر سیاست در هر مرحله از چرخه عمر توسعه، از زیرساخت به عنوان کد، مورد نیاز است. IaC) از طریق CI/CD تا زمان اجرا.
در زیر هفت توصیه از متخصصان ابر برای انجام این کار فهرست کردهام.
۱. دید را در محیط خود ایجاد کنید.
امنیت ابری مربوط به آگاهی از ابر شما و ممانعت از دسترسی دشمنان شما به آن دانش است. اگر از وضعیت کامل محیط ابری خود، از جمله هر منبع، پیکربندی و رابطه آگاه نیستید، خطر جدی را به دنبال دارید. ایجاد و حفظ دید جامع در محیط ابری خود در سراسر پلتفرم های ابری و به طور مداوم تأثیر امنیتی هر تغییر، از جمله خطرات بالقوه شعاع انفجار را ارزیابی کنید.
شما نه تنها به وضعیت امنیتی بهتری دست خواهید یافت، بلکه توسعه دهندگان خود را قادر میسازید تا سریعتر حرکت کنند، و متخصصان تطابق از شما برای شواهد حسابرسی فعال تشکر خواهند کرد.
۲. از زیرساخت به عنوان کد در همه جا استفاده کنید.
به جز چند استثنا، هیچ دلیلی وجود ندارد که شما باید زیرساخت های ابری خارج از زیرساخت را به عنوان خطوط لوله CI/CD خودکار و خودکار بسازید و اصلاح کنید، به ویژه برای هر چیز جدید. استفاده از IaC نه تنها کارایی، مقیاس و قابلیت پیش بینی را برای عملیات ابری به ارمغان می آورد، بلکه مکانیزمی را برای بررسی امنیت زیرساخت ابری پیش از استقرار فراهم می کند. وقتی توسعهدهندگان از IaC استفاده میکنند، میتوانید ابزارهای مورد نیاز برای بررسی امنیت زیرساختهایشان را قبل از استقرار در اختیار آنها قرار دهید.
اگر از یک محیط چند ابری استفاده میکنید، یک ابزار منبع باز IaC مانند Terraform که بهطور گسترده مورد استفاده قرار میگیرد احتمالا بهترین گزینه شماست پیشنهادات IaC از ارائه دهندگان خدمات ابری (به عنوان مثال، AWS CloudFormation، مدیر منابع Azure و Google Deployment Cloud Manager) رایگان هستند و شایسته توجه هستند.
۳. در همه جا از اتوماسیون مبتنی بر سیاست استفاده کنید.
هرجا که خطمشیهای ابری به زبان انسانی بیان شده باشد، تفاوتهایی را در تفسیر و خطاهای پیادهسازی دعوت میکنید. هر خط مشی امنیت و انطباق ابری که در محیط ابری شما اعمال می شود باید به عنوان کد اجرایی بیان و اجرا شود. با سیاست به عنوان کد، امنیت ابری قطعی می شود. این امکان مدیریت و اجرای کارآمد امنیت را فراهم میکند – و به توسعهدهندگان کمک میکند تا امنیت را در اوایل فرآیند توسعه به دست آورند.
از خط مشی فروشنده اختصاصی به عنوان ابزار کد خودداری کنید و یک موتور خط مشی منبع باز مانند Open Policy Agent (OPA) را انتخاب کنید. OPA را می توان برای هر چیزی اعمال کرد که بتواند خروجی JSON یا YAML تولید کند که تقریباً هر مورد استفاده از ابر را پوشش می دهد.
راهحلهایی را که به ابزارها و سیاستهای متفاوتی برای IaC و زیرساختهای ابری در حال اجرا نیاز ندارند، اولویتبندی کنید.
۴. توسعه دهندگان را برای ساخت ایمن توانمند کنید.
در فضای ابری، امنیت بیش از آنکه یک مشکل تحلیل داده باشد، یک مشکل مهندسی نرم افزار است. متخصصان امنیت ابری به مهارت های مهندسی و درک چگونگی عملکرد کل چرخه عمر توسعه نرم افزار (SDLC) از توسعه تا CI/CD و زمان اجرا نیاز دارند. و توسعه دهندگان به ابزارهایی نیاز دارند که به آنها کمک کند امنیت را درست در اوایل SDLC بدست آورند. امنیت را یک فکر قبلی و همراه نزدیک توسعه قرار دهید، نه یک تفکر بعدی که فقط بر مسائل پس از استقرار متمرکز شود.
آموزش تیمهای امنیتی در مورد شیوههای مهندسی ابر نه تنها آنها را به مهارتهای لازم برای دفاع در برابر تهدیدات ابری مدرن مجهز میکند، بلکه مهارتها و تجربیات ارزشمندی را برای کمک به پیشرفت حرفهشان به دست خواهند آورد. شما حفظ تیم را بهبود می بخشید و سازمان خود را به عنوان مکانی مطلوب برای کار قرار می دهید.
مجموعه Cloud Security Masterclass برای کمک به مهندسین ابر و امنیت طراحی شده است خطرات ابر و نحوه تفکر انتقادی در مورد ایمن کردن موارد استفاده منحصر به فرد آنها.
۵. خطمشیهای دسترسی خود را قفل کنید.
اگر از قبل یک خطمشی رسمی برای دسترسی و مدیریت محیطهای ابری خود ندارید، اکنون زمان ایجاد آن است. از شبکههای خصوصی مجازی (VPN) برای اعمال ارتباطات ایمن در فضاهای شبکه حیاتی (به عنوان مثال، Amazon Virtual Private Cloud یا Azure Virtual Network) استفاده کنید. دسترسی VPN را در دسترس یا مورد نیاز قرار دهید تا تیم بتواند به منابع شرکت دسترسی داشته باشد، حتی اگر آنها در یک شبکه Wi-Fi کمتر قابل اعتماد هستند.
مهندسان مستعد ایجاد قوانین گروه امنیتی جدید یا لیست سفید IP هستند تا بتوانند به منابع تیم مشترک در ابر دسترسی داشته باشند. ممیزی های مکرر می تواند تأیید کند که ماشین های مجازی یا سایر زیرساخت های ابری در معرض خطر اضافی قرار نگرفته اند. بر میزبانهای سنگر ایجاد نظارت کنید، محدوده IP منبع را قفل کنید و برای دسترسی نامحدود SSH نظارت کنید.
در AWS، Azure، GCP و دیگر ابرهای عمومی، IAM به عنوان یک شبکه فراگیر عمل می کند. از اصل حداقل مجوز پیروی کنید و از ابزارهایی مانند Fugue Best Practices Framework برای شناسایی آسیبپذیریهایی که بررسیهای انطباق ممکن است از دست بروند. تغییرات IAM را بخشی از فرآیند مدیریت تغییر خود قرار دهید و از ابزارهای مدیریت هویت و جلسه ممتاز استفاده کنید.
ذهنیت «به طور پیشفرض انکار» را بپذیرید.
پست های مرتبط
۷ راه برای جلوگیری از حمله پیکربندی نادرست ابر
۷ راه برای جلوگیری از حمله پیکربندی نادرست ابر
۷ راه برای جلوگیری از حمله پیکربندی نادرست ابر