نظارت بر امنیت ابری

انتقال داده‌ها و برنامه‌ها به ابر چالش جدیدی را برای SOCهای شرکتی ایجاد می‌کند که همیشه آماده نظارت بر زیرساخت‌های افراد دیگر نیستند. طبق گفته Netoskope، یک شرکت متوسط ​​(ظاهراً در ایالات متحده) از 1246 سرویس ابری مختلف استفاده می کند که 22 درصد بیشتر از یک سال قبل است. 1246 سرویس ابری!!! از این تعداد 175 مورد مربوط به خدمات منابع انسانی، 170 مورد مربوط به بازاریابی، 110 مورد در حوزه ارتباطات و 76 مورد مربوط به امور مالی و CRM است. سیسکو "فقط" از 700 سرویس ابری خارجی استفاده می کند. بنابراین من با این اعداد کمی گیج شده ام. اما در هر صورت، مشکل در آنها نیست، بلکه در این واقعیت است که ابر به طور کاملاً فعال توسط تعداد فزاینده ای از شرکت ها استفاده می شود که مایلند همان قابلیت هایی را برای نظارت بر زیرساخت های ابری داشته باشند که در شبکه خودشان وجود دارد. و این روند در حال رشد است - با توجه به طبق گزارش اتاق حساب های آمریکا تا سال 2023، 1200 مرکز داده در ایالات متحده بسته خواهد شد (6250 مرکز داده قبلا بسته شده اند). اما انتقال به فضای ابری فقط «بیایید سرورهایمان را به یک ارائه‌دهنده خارجی منتقل کنیم» نیست. معماری جدید فناوری اطلاعات، نرم افزارهای جدید، فرآیندهای جدید، محدودیت های جدید... همه اینها تغییرات قابل توجهی را در کار نه تنها فناوری اطلاعات، بلکه امنیت اطلاعات نیز به ارمغان می آورد. و اگر ارائه دهندگان یاد گرفته اند که به نحوی با اطمینان از امنیت خود ابر کنار بیایند (خوشبختانه توصیه های زیادی وجود دارد)، پس با نظارت بر امنیت اطلاعات ابری، به ویژه در سیستم عامل های SaaS، مشکلات قابل توجهی وجود دارد که در مورد آنها صحبت خواهیم کرد.

فرض کنید شرکت شما بخشی از زیرساخت خود را به ابر منتقل کرده است... توقف کنید. نه اینجوری اگر زیرساخت منتقل شده است، و شما فقط در حال حاضر به این فکر می کنید که چگونه آن را نظارت کنید، پس قبلاً ضرر کرده اید. اگر آمازون، گوگل یا مایکروسافت نباشد (و سپس با رزرو)، احتمالاً توانایی زیادی برای نظارت بر داده ها و برنامه های خود نخواهید داشت. خوب است اگر به شما فرصت کار با لاگ ها داده شود. گاهی اوقات داده های رویداد امنیتی در دسترس خواهد بود، اما شما به آن دسترسی نخواهید داشت. به عنوان مثال، آفیس 365. اگر ارزان ترین مجوز E1 را دارید، رویدادهای امنیتی اصلاً در دسترس شما نیستند. اگر مجوز E3 دارید، داده های شما فقط 90 روز ذخیره می شود، و تنها در صورت داشتن مجوز E5، مدت زمان لاگ ها برای یک سال در دسترس است (اما، این نیز تفاوت های ظریف خود را دارد که مربوط به نیاز به جداگانه است. از پشتیبانی مایکروسافت تعدادی عملکرد برای کار با گزارش‌ها درخواست کنید). به هر حال، مجوز E3 از نظر عملکردهای نظارتی بسیار ضعیف تر از Exchange شرکتی است. برای رسیدن به همان سطح، به یک مجوز E5 یا یک مجوز Advanced Compliance اضافی نیاز دارید، که ممکن است به پول اضافی نیاز داشته باشد که در مدل مالی شما برای انتقال به زیرساخت ابری لحاظ نشده است. و این تنها یک نمونه از دست کم گرفتن مسائل مربوط به نظارت بر امنیت اطلاعات ابری است. در این مقاله، بدون تظاهر به کامل بودن، می خواهم توجه خود را به نکات ظریفی جلب کنم که هنگام انتخاب ارائه دهنده ابر از نظر امنیتی باید در نظر گرفته شوند. و در پایان مقاله چک لیستی داده می شود که قبل از اینکه مسئله نظارت بر امنیت اطلاعات ابری حل شده است تکمیل شود.

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

• گزارش های امنیتی وجود ندارند. این یک وضعیت نسبتاً رایج است، به ویژه در میان بازیکنان تازه کار در بازار راه حل های ابری. اما شما نباید فوراً از آنها دست بکشید. بازیگران کوچک، به‌ویژه شرکت‌های داخلی، نسبت به نیازهای مشتریان حساس‌تر هستند و می‌توانند با تغییر نقشه راه تایید شده برای محصولات خود، برخی از عملکردهای مورد نیاز را به سرعت اجرا کنند. بله، این یک آنالوگ از GuardDuty از آمازون یا ماژول "Proactive Protection" از Bitrix نخواهد بود، اما حداقل چیزی است.
• امنیت اطلاعات نمی داند که لاگ ها در کجا ذخیره می شوند یا به آنها دسترسی ندارند. در اینجا لازم است با ارائه دهنده خدمات ابری وارد مذاکره شوید - شاید اگر مشتری را برای خود مهم بداند چنین اطلاعاتی را ارائه دهد. اما به طور کلی، زمانی که دسترسی به گزارش‌ها «با تصمیم خاصی» فراهم شود، خیلی خوب نیست.
• همچنین اتفاق می‌افتد که ارائه‌دهنده ابر گزارش‌هایی داشته باشد، اما آنها نظارت و ضبط رویداد محدودی را ارائه می‌کنند که برای شناسایی همه حوادث کافی نیست. برای مثال، شما ممکن است فقط گزارش‌های تغییرات در یک وب‌سایت یا گزارش‌های تلاش‌های احراز هویت کاربر را دریافت کنید، اما نه رویدادهای دیگر، مانند ترافیک شبکه، که یک لایه کامل از رویدادها را که مشخصه تلاش‌ها برای هک کردن زیرساخت ابری شما هستند، از شما پنهان می‌کند.
• سیاهههای مربوط وجود دارد، اما دسترسی به آنها به طور خودکار دشوار است، که آنها را مجبور می کند نه به طور مداوم، بلکه بر اساس یک برنامه نظارت شوند. و اگر نمی‌توانید گزارش‌ها را به‌طور خودکار دانلود کنید، دانلود گزارش‌ها، به عنوان مثال، در قالب اکسل (مانند تعدادی از ارائه‌دهندگان راه‌حل‌های ابری داخلی)، حتی ممکن است منجر به بی‌میلی سرویس امنیت اطلاعات شرکتی برای سرهم‌کردن آنها شود.
• بدون نظارت بر گزارش این شاید نامشخص ترین دلیل برای وقوع حوادث امنیت اطلاعات در محیط های ابری باشد. به نظر می رسد که لاگ وجود دارد و امکان دسترسی خودکار به آنها وجود دارد، اما هیچ کس این کار را انجام نمی دهد. چرا؟

مفهوم امنیت ابر مشترک

انتقال به ابر همیشه جستجوی تعادل بین تمایل به حفظ کنترل بر زیرساخت و انتقال آن به دستان حرفه‌ای‌تر ارائه‌دهنده ابری است که در نگهداری آن تخصص دارد. و در حوزه امنیت ابری نیز باید به دنبال این تعادل بود. علاوه بر این، بسته به مدل ارائه خدمات ابری مورد استفاده (IaaS، PaaS، SaaS)، این تعادل همیشه متفاوت خواهد بود. در هر صورت، باید به یاد داشته باشیم که امروزه همه ارائه دهندگان ابر از مدل به اصطلاح مسئولیت مشترک و امنیت اطلاعات مشترک پیروی می کنند. ابر مسئول برخی چیزها است و برای برخی دیگر مشتری مسئول قرار دادن داده ها، برنامه های کاربردی، ماشین های مجازی خود و سایر منابع در ابر است. بی‌احتیاطی است که انتظار داشته باشیم با رفتن به فضای ابری، همه مسئولیت‌ها را به عهده ارائه‌دهنده بگذاریم. اما این نیز عاقلانه نیست که هنگام انتقال به فضای ابری، تمام امنیت را خودتان ایجاد کنید. تعادل مورد نیاز است که به عوامل زیادی بستگی دارد: - استراتژی مدیریت ریسک، مدل تهدید، مکانیسم‌های امنیتی موجود برای ارائه‌دهنده ابر، قانون‌گذاری و غیره.

به عنوان مثال، طبقه بندی داده های میزبانی شده در فضای ابری همیشه بر عهده مشتری است. یک ارائه‌دهنده ابر یا یک ارائه‌دهنده خدمات خارجی فقط می‌تواند با ابزارهایی به او کمک کند که به علامت‌گذاری داده‌ها در فضای ابری، شناسایی تخلفات، حذف داده‌هایی که قانون را نقض می‌کنند، یا با استفاده از یک روش یا روش دیگر آن‌ها را پنهان می‌کنند. از سوی دیگر، امنیت فیزیکی همیشه بر عهده ارائه دهنده ابر است که نمی تواند آن را با مشتریان به اشتراک بگذارد. اما هر چیزی که بین داده و زیرساخت فیزیکی است دقیقاً موضوع بحث در این مقاله است. به عنوان مثال، در دسترس بودن ابر به عهده ارائه دهنده است و تنظیم قوانین فایروال یا فعال کردن رمزگذاری به عهده مشتری است. در این مقاله سعی خواهیم کرد ببینیم که امروزه چه مکانیسم های نظارت بر امنیت اطلاعات توسط ارائه دهندگان مختلف ابر محبوب در روسیه ارائه می شود، چه ویژگی هایی از آنها استفاده می شود و چه زمانی ارزش دارد که به دنبال راه حل های پوشش خارجی باشیم (به عنوان مثال، Cisco E- mail Security) که قابلیت های ابر شما را از نظر امنیت سایبری گسترش می دهد. در برخی موارد، به خصوص اگر از یک استراتژی چند ابری پیروی می کنید، چاره ای جز استفاده از راه حل های نظارت بر امنیت اطلاعات خارجی در چندین محیط ابری به طور همزمان نخواهید داشت (به عنوان مثال، Cisco CloudLock یا Cisco Stealthwatch Cloud). خب، در برخی موارد متوجه می‌شوید که ارائه‌دهنده ابری که انتخاب کرده‌اید (یا به شما تحمیل کرده‌اید) اصلاً قابلیت نظارت بر امنیت اطلاعات را ارائه نمی‌دهد. این ناخوشایند است، اما نه کمی، زیرا به شما امکان می دهد به اندازه کافی سطح خطر مرتبط با کار با این ابر را ارزیابی کنید.

چرخه حیات نظارت بر امنیت ابری

برای نظارت بر امنیت ابرهایی که استفاده می کنید، فقط سه گزینه دارید:

• به ابزارهای ارائه شده توسط ارائه دهنده ابر خود تکیه کنید،
• از راه‌حل‌های اشخاص ثالث استفاده کنید که بر پلتفرم‌های IaaS، PaaS یا SaaS که استفاده می‌کنید نظارت می‌کنند،
• زیرساخت نظارت ابری خود را بسازید (فقط برای پلتفرم های IaaS/PaaS).

بیایید ببینیم هر کدام از این گزینه ها چه ویژگی هایی دارند. اما ابتدا باید چارچوب کلی را که هنگام نظارت بر پلتفرم های ابری استفاده می شود، درک کنیم. من 6 جزء اصلی فرآیند نظارت بر امنیت اطلاعات در ابر را برجسته می کنم:

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

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

خدمات ابری داخلی

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

به طور کلی، با روشی که ارائه دهنده ابر مسائل مربوط به امنیت اطلاعات را در وب سایت خود و در مستندات خود توضیح می دهد، می توانید متوجه شوید که چقدر این موضوع را جدی می گیرد. به عنوان مثال، اگر دفترچه راهنمای محصولات "My Office" را بخوانید، اصلاً کلمه ای در مورد امنیت وجود ندارد، اما در مستندات محصول جداگانه "My Office. KS3، که برای محافظت در برابر دسترسی غیرمجاز طراحی شده است، یک لیست معمولی از نقاط هفدهمین دستور FSTEC وجود دارد که "My Office.KS17" آن را پیاده سازی می کند، اما توضیح داده نشده است که چگونه آن را پیاده سازی می کند و مهمتر از همه، نحوه اجرای آن این مکانیسم ها را با امنیت اطلاعات شرکت ادغام کنید. شاید چنین اسنادی وجود داشته باشد، اما من آن را در دامنه عمومی، در وب سایت "دفتر من" پیدا نکردم. اگرچه شاید من به این اطلاعات مخفی دسترسی نداشته باشم؟..

برای Bitrix، وضعیت بسیار بهتر است. این مستندات، فرمت‌های گزارش‌های رویداد و جالب‌تر، گزارش نفوذ را توصیف می‌کند که حاوی رویدادهای مرتبط با تهدیدات احتمالی برای پلتفرم ابری است. از آنجا می توانید IP، نام کاربر یا مهمان، منبع رویداد، زمان، عامل کاربر، نوع رویداد و غیره را بیرون بکشید. درست است، می توانید با این رویدادها یا از کنترل پنل خود ابر کار کنید یا داده ها را در قالب MS Excel بارگذاری کنید. در حال حاضر خودکار کردن کار با لاگ های Bitrix دشوار است و باید برخی از کارها را به صورت دستی انجام دهید (آپلود کردن گزارش و بارگذاری آن در SIEM). اما اگر به یاد داشته باشیم که تا همین اواخر چنین فرصتی وجود نداشت، پس این پیشرفت بزرگی است. در عین حال، می‌خواهم توجه داشته باشم که بسیاری از ارائه‌دهندگان ابری خارجی عملکرد مشابهی را «برای مبتدیان» ارائه می‌کنند - یا از طریق کنترل پنل به گزارش‌ها نگاه کنید، یا داده‌ها را برای خودتان آپلود کنید (با این حال، بیشتر داده‌های آپلود در . فرمت csv، نه اکسل).

بدون در نظر گرفتن گزینه no-log، ارائه دهندگان ابر معمولاً سه گزینه را برای نظارت بر رویدادهای امنیتی به شما ارائه می دهند - داشبورد، آپلود داده و دسترسی API. به نظر می رسد اولی بسیاری از مشکلات را برای شما حل می کند، اما این کاملاً درست نیست - اگر چندین مجله دارید، باید بین صفحه هایی که آنها را نشان می دهند جابجا شوید و تصویر کلی را از دست بدهید. علاوه بر این، بعید است که ارائه‌دهنده ابر توانایی مرتبط کردن رویدادهای امنیتی و تجزیه و تحلیل آنها را از نقطه نظر امنیتی در اختیار شما قرار دهد (معمولاً شما با داده‌های خام سروکار دارید که باید خودتان آن‌ها را درک کنید). استثناهایی وجود دارد و در ادامه در مورد آنها صحبت خواهیم کرد. در نهایت، ارزش این را دارد که بپرسید چه رویدادهایی توسط ارائه‌دهنده ابری شما ثبت می‌شوند، در چه قالبی، و چگونه با فرآیند نظارت بر امنیت اطلاعات شما مطابقت دارند؟ به عنوان مثال، شناسایی و احراز هویت کاربران و مهمانان. همان Bitrix به شما امکان می دهد بر اساس این رویدادها، تاریخ و زمان رویداد، نام کاربر یا مهمان (در صورت داشتن ماژول "Web Analytics")، شی مورد دسترسی و سایر عناصر معمول برای یک وب سایت را ثبت کنید. . اما سرویس‌های امنیت اطلاعات شرکتی ممکن است به اطلاعاتی در مورد اینکه آیا کاربر از یک دستگاه قابل اعتماد به ابر دسترسی داشته است نیاز داشته باشد (به عنوان مثال، در یک شبکه شرکتی این وظیفه توسط Cisco ISE اجرا می‌شود). در مورد یک کار ساده مانند عملکرد geo-IP، که به تعیین اینکه آیا حساب کاربری سرویس ابری به سرقت رفته است یا خیر، چطور؟ و حتی اگر ارائه دهنده ابر آن را در اختیار شما قرار دهد، این کافی نیست. همان سیسکو CloudLock فقط موقعیت جغرافیایی را تجزیه و تحلیل نمی‌کند، بلکه از یادگیری ماشین برای این کار استفاده می‌کند و داده‌های تاریخی هر کاربر را تجزیه و تحلیل می‌کند و ناهنجاری‌های مختلف را در تلاش‌های شناسایی و احراز هویت نظارت می‌کند. فقط MS Azure عملکرد مشابهی دارد (در صورت داشتن اشتراک مناسب).

مشکل دیگری وجود دارد - از آنجایی که برای بسیاری از ارائه دهندگان ابر نظارت بر امنیت اطلاعات موضوع جدیدی است که آنها تازه شروع به پرداختن به آن کرده اند، آنها دائماً چیزی را در راه حل های خود تغییر می دهند. امروز آنها یک نسخه از API دارند، فردا نسخه دیگر، پس فردا نسخه سوم. شما همچنین باید برای این کار آماده باشید. همین امر در مورد عملکرد نیز صادق است، که ممکن است تغییر کند، که باید در سیستم نظارت بر امنیت اطلاعات شما در نظر گرفته شود. به عنوان مثال، آمازون در ابتدا خدمات نظارت بر رویدادهای ابری جداگانه داشت - AWS CloudTrail و AWS CloudWatch. سپس یک سرویس جداگانه برای نظارت بر رویدادهای امنیت اطلاعات ظاهر شد - AWS GuardDuty. پس از مدتی، آمازون یک سیستم مدیریتی جدید به نام آمازون امنیت هاب را راه اندازی کرد که شامل تجزیه و تحلیل داده های دریافت شده از GuardDuty، Amazon Inspector، Amazon Macie و چندین مورد دیگر است. مثال دیگر ابزار ادغام لاگ Azure با SIEM - AzLog است. این به طور فعال توسط بسیاری از فروشندگان SIEM استفاده می شد، تا اینکه در سال 2018 مایکروسافت توقف توسعه و پشتیبانی آن را اعلام کرد، که بسیاری از مشتریانی که از این ابزار استفاده می کردند با مشکل مواجه شدند (در مورد نحوه حل آن بعدا صحبت خواهیم کرد).

بنابراین، تمام ویژگی‌های نظارتی را که ارائه‌دهنده ابری شما به شما ارائه می‌دهد، به دقت بررسی کنید. یا به ارائه دهندگان راه حل خارجی که به عنوان واسطه بین SOC و ابری که می خواهید نظارت کنید، تکیه کنید. بله، گران‌تر خواهد بود (اگرچه نه همیشه)، اما شما تمام مسئولیت را بر دوش شخص دیگری خواهید گذاشت. یا نه همه آن؟.. بیایید مفهوم امنیت مشترک را به خاطر بسپاریم و درک کنیم که ما نمی توانیم چیزی را تغییر دهیم - باید به طور مستقل درک کنیم که چگونه ارائه دهندگان ابری مختلف نظارت بر امنیت اطلاعات داده ها، برنامه ها، ماشین های مجازی و سایر منابع شما را فراهم می کنند. میزبانی در ابر و ما با آنچه آمازون در این بخش ارائه می دهد شروع می کنیم.

مثال: نظارت بر امنیت اطلاعات در IaaS بر اساس AWS

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

اولین چیزی که باید گفت این است که آمازون یک قلعه غیرقابل نفوذ نیست. حوادث مختلفی به طور مرتب برای مشتریانش اتفاق می افتد. به عنوان مثال، نام، آدرس، تاریخ تولد، و شماره تلفن 198 میلیون رای دهنده از Deep Root Analytics به سرقت رفته است. شرکت اسرائیلی Nice Systems 14 میلیون رکورد مشترکین Verizon را به سرقت برد. با این حال، قابلیت های داخلی AWS به شما امکان می دهد طیف گسترده ای از حوادث را شناسایی کنید. مثلا:

• تاثیر بر زیرساخت (DDoS)
• سازش گره (تزریق فرمان)
• به خطر افتادن حساب و دسترسی غیرمجاز
• پیکربندی نادرست و آسیب پذیری ها
• رابط ها و API های ناامن

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

برای شناسایی حوادث، می‌توانید از طیف گسترده‌ای از خدمات نظارتی مختلف که توسط آمازون توسعه داده شده‌اند استفاده کنید (اگرچه این خدمات اغلب با ابزارهای خارجی مانند osquery تکمیل می‌شوند). بنابراین، در AWS، تمام اقدامات کاربر بدون توجه به نحوه انجام آنها - از طریق کنسول مدیریت، خط فرمان، SDK یا سایر خدمات AWS نظارت می شود. تمام سوابق فعالیت هر حساب AWS (شامل نام کاربری، عملکرد، سرویس، پارامترهای فعالیت و نتیجه) و استفاده از API از طریق AWS CloudTrail در دسترس است. می‌توانید این رویدادها (مانند ورود به کنسول AWS IAM) را از کنسول CloudTrail مشاهده کنید، آنها را با استفاده از Amazon Athena تجزیه و تحلیل کنید، یا آنها را به راه‌حل‌های خارجی مانند Splunk، AlienVault و غیره «برون‌سپاری» کنید. خود لاگ های AWS CloudTrail در سطل AWS S3 شما قرار می گیرند.

دو سرویس دیگر AWS تعدادی دیگر از قابلیت های نظارتی مهم را ارائه می دهند. ابتدا، Amazon CloudWatch یک سرویس نظارتی برای منابع و برنامه های AWS است که از جمله موارد دیگر، به شما امکان می دهد ناهنجاری های مختلف را در ابر خود شناسایی کنید. همه سرویس‌های داخلی AWS، مانند Amazon Elastic Compute Cloud (سرورها)، Amazon Relational Database Service (پایگاه‌های داده)، Amazon Elastic MapReduce (تحلیل داده‌ها) و 30 سرویس دیگر آمازون، از Amazon CloudWatch برای ذخیره گزارش‌های خود استفاده می‌کنند. توسعه‌دهندگان می‌توانند از API باز Amazon CloudWatch برای افزودن عملکرد نظارت بر گزارش به برنامه‌ها و سرویس‌های سفارشی استفاده کنند و به آن‌ها اجازه می‌دهد دامنه تجزیه و تحلیل رویداد را در یک زمینه امنیتی گسترش دهند.

ثانیاً، سرویس VPC Flow Logs به شما امکان می دهد تا ترافیک شبکه ارسال یا دریافت شده توسط سرورهای AWS خود (به صورت خارجی یا داخلی)، و همچنین بین میکروسرویس ها را تجزیه و تحلیل کنید. هنگامی که هر یک از منابع AWS VPC شما با شبکه تعامل دارد، VPC Flow Logs جزئیات مربوط به ترافیک شبکه، از جمله رابط شبکه مبدا و مقصد، و همچنین آدرس های IP، پورت ها، پروتکل، تعداد بایت ها و تعداد بسته های شما را ثبت می کند. اره. کسانی که با امنیت شبکه محلی تجربه دارند، این موضوع را مشابه رشته ها تشخیص می دهند NetFlow، که می تواند توسط سوئیچ ها، روترها و فایروال های درجه یک سازمانی ایجاد شود. این گزارش‌ها برای اهداف نظارت بر امنیت اطلاعات مهم هستند، زیرا برخلاف رویدادهای مربوط به اقدامات کاربران و برنامه‌ها، به شما این امکان را می‌دهند که تعاملات شبکه را در محیط ابر خصوصی مجازی AWS از دست ندهید.

به طور خلاصه، این سه سرویس AWS - AWS CloudTrail، Amazon CloudWatch و VPC Flow Logs - با هم بینش نسبتاً قدرتمندی را در مورد استفاده از حساب، رفتار کاربر، مدیریت زیرساخت، فعالیت برنامه‌ها و خدمات، و فعالیت شبکه ارائه می‌دهند. به عنوان مثال، آنها می توانند برای تشخیص ناهنجاری های زیر استفاده شوند:

• تلاش برای اسکن سایت، جستجوی درهای پشتی، جستجوی آسیب پذیری ها از طریق انفجارهای "خطاهای 404".
• حملات تزریق (به عنوان مثال، تزریق SQL) از طریق انفجارهای "500 خطا".
• ابزارهای حمله شناخته شده sqlmap، nikto، w3af، nmap و غیره هستند. از طریق تجزیه و تحلیل قسمت User Agent.

خدمات وب آمازون همچنین خدمات دیگری را برای اهداف امنیت سایبری توسعه داده است که به شما امکان می دهد بسیاری از مشکلات دیگر را حل کنید. به عنوان مثال، AWS دارای یک سرویس داخلی برای حسابرسی سیاست ها و تنظیمات است - AWS Config. این سرویس ممیزی مستمر منابع AWS و تنظیمات آنها را فراهم می کند. بیایید یک مثال ساده در نظر بگیریم: فرض کنید می‌خواهید مطمئن شوید که رمزهای عبور کاربر در همه سرورهای شما غیرفعال هستند و دسترسی فقط بر اساس گواهی‌ها امکان‌پذیر است. AWS Config بررسی این مورد را برای همه سرورهای شما آسان می کند. خط‌مشی‌های دیگری نیز وجود دارند که می‌توانند برای سرورهای ابری شما اعمال شوند: «هیچ سروری نمی‌تواند از پورت ۲۲ استفاده کند»، «فقط مدیران می‌توانند قوانین دیوار آتش را تغییر دهند» یا «فقط کاربر Ivashko می‌تواند حساب‌های کاربری جدید ایجاد کند، و او می‌تواند این کار را فقط در روزهای سه‌شنبه انجام دهد. " در تابستان 22، سرویس AWS Config برای تشخیص خودکار نقض خط‌مشی‌های توسعه‌یافته گسترش یافت. قوانین پیکربندی AWS اساساً درخواست‌های پیکربندی پیوسته برای سرویس‌های آمازون مورد استفاده شما هستند که در صورت نقض خط‌مشی‌های مربوطه، رویدادهایی را ایجاد می‌کنند. برای مثال، به‌جای اجرای دوره‌ای کوئری‌های AWS Config برای تأیید اینکه همه دیسک‌های روی یک سرور مجازی رمزگذاری شده‌اند، می‌توان از قوانین پیکربندی AWS برای بررسی مداوم دیسک‌های سرور استفاده کرد تا اطمینان حاصل شود که این شرط برآورده شده است. و مهمتر از همه، در زمینه این نشریه، هرگونه تخلف، رویدادهایی را ایجاد می کند که توسط سرویس امنیت اطلاعات شما قابل تجزیه و تحلیل است.

AWS همچنین معادل خود را با راه حل های سنتی امنیت اطلاعات شرکتی دارد، که همچنین رویدادهای امنیتی را ایجاد می کند که می توانید و باید آنها را تجزیه و تحلیل کنید:

• تشخیص نفوذ - AWS GuardDuty
• کنترل نشت اطلاعات - AWS Macie
• EDR (اگرچه در مورد نقاط پایانی در ابر کمی عجیب صحبت می کند) - AWS Cloudwatch + osquery منبع باز یا راه حل های GRR
• تجزیه و تحلیل Netflow - AWS Cloudwatch + AWS VPC Flow
• تجزیه و تحلیل DNS - AWS Cloudwatch + AWS Route53
• AD - سرویس دایرکتوری AWS
• مدیریت حساب - AWS IAM
• SSO - AWS SSO
• تجزیه و تحلیل امنیتی - بازرس AWS
• مدیریت پیکربندی - AWS Config
• WAF - AWS WAF.

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

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

• CloudTrail - استفاده از API و اقدامات کاربر
• مشاور مورد اعتماد - بررسی امنیتی در برابر بهترین شیوه ها
• پیکربندی - موجودی و پیکربندی حساب ها و تنظیمات سرویس
• VPC Flow Logs - اتصال به رابط های مجازی
• IAM - خدمات شناسایی و احراز هویت
• ELB Access Logs - Load Balancer
• بازرس - آسیب پذیری های برنامه
• S3 - ذخیره سازی فایل
• CloudWatch - فعالیت برنامه
• SNS یک سرویس اطلاع رسانی است.

آمازون، در حالی که چنین طیفی از منابع و ابزار رویداد را برای نسل خود ارائه می دهد، توانایی خود در تجزیه و تحلیل داده های جمع آوری شده در زمینه امنیت اطلاعات بسیار محدود است. شما باید به طور مستقل لاگ های موجود را مطالعه کنید و به دنبال شاخص های مربوط به سازش در آنها باشید. AWS Security Hub که اخیراً آمازون راه‌اندازی کرده است، قصد دارد این مشکل را با تبدیل شدن به یک ابر SIEM برای AWS حل کند. اما تاکنون تنها در ابتدای راه است و هم به دلیل تعداد منابعی که با آن کار می کند و هم به دلیل محدودیت های دیگر ایجاد شده توسط معماری و اشتراک های خود آمازون محدود شده است.

مثال: نظارت بر امنیت اطلاعات در IaaS بر اساس Azure

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

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

AWS یک ویژگی مرتبط با این واقعیت دارد که وقتی منابع مجازی خود را رصد می کنید، اگر در مناطق مختلف قرار دارند، در ترکیب همه رویدادها و تجزیه و تحلیل یکپارچه آنها با مشکلاتی روبرو هستید، که برای از بین بردن آنها باید به ترفندهای مختلفی متوسل شوید، مانند کد خود را برای AWS Lambda ایجاد کنید که رویدادها را بین مناطق منتقل می کند. Azure این مشکل را ندارد - مکانیسم Activity Log آن تمام فعالیت ها را در کل سازمان بدون محدودیت ردیابی می کند. همین امر در مورد AWS Security Hub نیز صدق می‌کند، که اخیراً توسط آمازون توسعه داده شده است تا بسیاری از عملکردهای امنیتی را در یک مرکز امنیتی واحد تجمیع کند، اما فقط در منطقه خود، که با این حال، مربوط به روسیه نیست. Azure مرکز امنیتی خاص خود را دارد که محدود به محدودیت های منطقه ای نیست و دسترسی به تمام ویژگی های امنیتی پلت فرم ابری را فراهم می کند. علاوه بر این، برای تیم‌های محلی مختلف، می‌تواند مجموعه‌ای از قابلیت‌های حفاظتی خود را فراهم کند، از جمله رویدادهای امنیتی که توسط آنها مدیریت می‌شود. AWS Security Hub همچنان در راه شبیه شدن به Azure Security Center است. اما ارزش افزودن یک مگس به پماد را دارد - می توانید مقدار زیادی از آنچه قبلاً در AWS توضیح داده شده بود را از Azure فشار دهید، اما این کار به راحتی فقط برای Azure AD، Azure Monitor و Azure Security Center انجام می شود. تمام مکانیسم‌های امنیتی Azure، از جمله تجزیه و تحلیل رویدادهای امنیتی، هنوز به راحت‌ترین روش مدیریت نمی‌شوند. این مشکل تا حدی توسط API حل شده است، که در تمام سرویس‌های Microsoft Azure نفوذ می‌کند، اما این امر مستلزم تلاش بیشتر شما برای ادغام ابر خود با SOC و حضور متخصصان واجد شرایط است (در واقع، مانند هر SIEM دیگری که با ابر کار می‌کند. API ها). برخی از SIEM ها، که بعداً مورد بحث قرار خواهد گرفت، قبلاً از Azure پشتیبانی می کنند و می توانند وظیفه نظارت بر آن را خودکار کنند، اما مشکلات خاص خود را نیز دارد - همه آنها نمی توانند تمام گزارش هایی را که Azure دارد جمع آوری کنند.

جمع آوری و نظارت بر رویدادها در Azure با استفاده از سرویس Azure Monitor که ابزار اصلی جمع آوری، ذخیره و تجزیه و تحلیل داده ها در ابر مایکروسافت و منابع آن - مخازن Git، کانتینرها، ماشین های مجازی، برنامه ها و غیره است، ارائه می شود. تمام داده‌های جمع‌آوری‌شده توسط Azure Monitor به دو دسته تقسیم می‌شوند - معیارهایی که در زمان واقعی جمع‌آوری می‌شوند و شاخص‌های عملکرد کلیدی ابر Azure را توصیف می‌کنند، و گزارش‌هایی که حاوی داده‌های سازمان‌دهی‌شده در رکوردهایی هستند که جنبه‌های خاصی از فعالیت منابع و خدمات Azure را مشخص می‌کنند. علاوه بر این، با استفاده از Data Collector API، سرویس Azure Monitor می تواند داده ها را از هر منبع REST جمع آوری کند تا سناریوهای نظارتی خود را بسازد.

در اینجا چند منبع رویداد امنیتی وجود دارد که Azure به شما ارائه می دهد و می توانید از طریق Azure Portal، CLI، PowerShell یا REST API (و برخی فقط از طریق Azure Monitor/Insight API) به آنها دسترسی داشته باشید:

• گزارش‌های فعالیت - این گزارش به سؤالات کلاسیک «چه کسی»، «چه» و «وقتی» در مورد هر عملیات نوشتن (PUT، POST، DELETE) در منابع ابری پاسخ می‌دهد. رویدادهای مربوط به دسترسی خواندن (GET) مانند تعدادی دیگر در این گزارش گنجانده نشده است.
• گزارش‌های تشخیصی - حاوی داده‌هایی در مورد عملیات با یک منبع خاص موجود در اشتراک شما است.
• گزارش Azure AD - شامل فعالیت کاربر و فعالیت سیستم مربوط به گروه و مدیریت کاربر است.
• Windows Event Log و Linux Syslog - شامل رویدادهایی از ماشین‌های مجازی است که در فضای ابری میزبانی می‌شوند.
• معیارها - شامل تله متری در مورد عملکرد و وضعیت سلامت خدمات و منابع ابری شما است. هر دقیقه اندازه گیری و ذخیره می شود. طی 30 روز.
• گزارش‌های جریان گروه امنیت شبکه - حاوی داده‌هایی درباره رویدادهای امنیتی شبکه است که با استفاده از سرویس ناظر شبکه و نظارت بر منابع در سطح شبکه جمع‌آوری شده‌اند.
• گزارش های ذخیره سازی - شامل رویدادهای مربوط به دسترسی به امکانات ذخیره سازی است.

برای نظارت، می توانید از SIEM های خارجی یا مانیتور داخلی Azure و افزونه های آن استفاده کنید. بعداً در مورد سیستم‌های مدیریت رویداد امنیت اطلاعات صحبت خواهیم کرد، اما فعلاً بیایید ببینیم خود Azure برای تجزیه و تحلیل داده‌ها در زمینه امنیت چه چیزی به ما ارائه می‌دهد. صفحه اصلی برای هر چیزی که در مانیتور Azure مربوط به امنیت است، داشبورد امنیتی و حسابرسی Log Analytics است (نسخه رایگان از مقدار محدودی از فضای ذخیره‌سازی رویداد فقط برای یک هفته پشتیبانی می‌کند). این داشبورد به 5 ناحیه اصلی تقسیم می‌شود که آمار خلاصه‌ای از آنچه در محیط ابری که استفاده می‌کنید اتفاق می‌افتد را تجسم می‌کند:

• دامنه های امنیتی - شاخص های کمی کلیدی مرتبط با امنیت اطلاعات - تعداد حوادث، تعداد گره های در معرض خطر، گره های اصلاح نشده، رویدادهای امنیتی شبکه و غیره.
• موارد قابل توجه - تعداد و اهمیت مسائل امنیتی اطلاعات فعال را نشان می دهد
• Detections - الگوهای حملات مورد استفاده علیه شما را نمایش می دهد
• Threat Intelligence - اطلاعات جغرافیایی را روی گره های خارجی که به شما حمله می کنند نمایش می دهد
• پرس و جوهای امنیتی رایج - پرس و جوهای معمولی که به شما کمک می کند تا امنیت اطلاعات خود را بهتر نظارت کنید.

برنامه‌های افزودنی مانیتور Azure شامل Azure Key Vault (محافظت از کلیدهای رمزنگاری در فضای ابری)، ارزیابی بدافزار (تجزیه و تحلیل حفاظت در برابر کدهای مخرب در ماشین‌های مجازی)، تجزیه و تحلیل Azure Application Gateway Analytics (تجزیه و تحلیل، از جمله موارد دیگر، گزارش‌های فایروال ابری) و غیره است. . این ابزارها که با قوانین خاصی برای پردازش رویدادها غنی شده اند، به شما امکان می دهند جنبه های مختلف فعالیت سرویس های ابری از جمله امنیت را تجسم کنید و انحرافات خاصی را از عملکرد شناسایی کنید. اما، همانطور که اغلب اتفاق می افتد، هر عملکرد اضافی نیاز به اشتراک پولی مربوطه دارد، که به سرمایه گذاری های مالی مربوطه از شما نیاز دارد، که باید از قبل برنامه ریزی کنید.

Azure دارای تعدادی قابلیت داخلی نظارت بر تهدید است که در Azure AD، Azure Monitor و Azure Security Center یکپارچه شده است. از جمله، به عنوان مثال، تشخیص تعامل ماشین های مجازی با IP های مخرب شناخته شده (به دلیل وجود ادغام با سرویس های Threat Intelligence مایکروسافت)، تشخیص بدافزار در زیرساخت ابری با دریافت آلارم از ماشین های مجازی میزبانی شده در فضای ابری، رمز عبور. حدس زدن حملات ” به ماشین‌های مجازی، آسیب‌پذیری‌ها در پیکربندی سیستم شناسایی کاربر، ورود به سیستم از طریق ناشناس یا گره‌های آلوده، نشت حساب، ورود به سیستم از مکان‌های غیرمعمول و غیره. Azure امروز یکی از معدود ارائه دهندگان ابری است که به شما قابلیت های Threat Intelligence داخلی را برای غنی سازی رویدادهای امنیت اطلاعات جمع آوری شده ارائه می دهد.

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

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

اگر نه تنها به توانایی کار با لاگ‌ها، بلکه به یک مرکز امنیتی جامع برای پلتفرم ابری Azure خود، از جمله مدیریت خط‌مشی امنیت اطلاعات، نیاز دارید، می‌توانید در مورد نیاز به کار با مرکز امنیتی Azure صحبت کنید که اکثر عملکردهای مفید آن است. برای مقداری پول در دسترس هستند، به عنوان مثال، شناسایی تهدید، نظارت خارج از Azure، ارزیابی انطباق و غیره. (در نسخه رایگان فقط به ارزیابی امنیتی و توصیه هایی برای رفع مشکلات شناسایی شده دسترسی دارید). همه مسائل امنیتی را در یک مکان ادغام می کند. در واقع، ما می توانیم در مورد سطح بالاتری از امنیت اطلاعات نسبت به Azure Monitor که در اختیار شما قرار می دهد صحبت کنیم، زیرا در این حالت داده های جمع آوری شده در سراسر کارخانه ابری شما با استفاده از منابع بسیاری مانند Azure، Office 365، Microsoft CRM آنلاین، Microsoft Dynamics AX غنی می شوند. ، outlook.com، MSN.com، واحد جرایم دیجیتال مایکروسافت (DCU) و مرکز پاسخگویی امنیتی مایکروسافت (MSRC)، که بر روی آنها الگوریتم های مختلف یادگیری ماشینی و تحلیل رفتاری پیچیده قرار گرفته اند، که در نهایت باید کارایی شناسایی و پاسخ به تهدیدات را بهبود بخشد. .

Azure همچنین SIEM مخصوص به خود را دارد - در ابتدای سال 2019 ظاهر شد. این Azure Sentinel است که به داده های Azure Monitor متکی است و همچنین می تواند با آن ادغام شود. راه حل های امنیتی خارجی (به عنوان مثال، NGFW یا WAF)، که لیست آنها به طور مداوم در حال رشد است. علاوه بر این، از طریق ادغام Microsoft Graph Security API، شما می‌توانید فیدهای Threat Intelligence خود را به Sentinel متصل کنید، که این قابلیت‌ها را برای تجزیه و تحلیل حوادث در ابر Azure شما غنی می‌کند. می توان استدلال کرد که Azure Sentinel اولین SIEM "بومی" است که از ارائه دهندگان ابر ظاهر شد (همان Splunk یا ELK که می تواند در فضای ابری میزبانی شود، به عنوان مثال، AWS، هنوز توسط ارائه دهندگان خدمات ابری سنتی توسعه داده نشده است). Azure Sentinel و Security Center را می‌توان برای ابر Azure SOC نامید و در صورتی که دیگر زیرساختی ندارید و تمام منابع محاسباتی خود را به ابر منتقل می‌کردید و می‌توانست Azure ابری مایکروسافت باشد، به آن‌ها محدود شود (با رزروهای خاص).

اما از آنجایی که قابلیت‌های داخلی Azure (حتی اگر اشتراک Sentinel داشته باشید) اغلب برای اهداف نظارت بر امنیت اطلاعات و ادغام این فرآیند با سایر منابع رویدادهای امنیتی (هم ابری و هم داخلی) کافی نیست، نیاز به صادرات داده های جمع آوری شده به سیستم های خارجی، که ممکن است شامل SIEM باشد. این کار هم با استفاده از API و هم با استفاده از پسوندهای ویژه انجام می شود، که در حال حاضر به طور رسمی فقط برای SIEM های زیر در دسترس هستند - Splunk (افزونه مانیتور Azure برای Splunk)، IBM QRadar (Microsoft Azure DSM)، SumoLogic، ArcSight و ELK. تا همین اواخر، تعداد بیشتری از این SIEM ها وجود داشت، اما از اول ژوئن 1، مایکروسافت از Azure Log Integration Tool (AzLog) که در ابتدای وجود Azure و در غیاب استانداردسازی عادی کار با لاگ ها (Azure) متوقف شد. مانیتور حتی هنوز وجود نداشت) ادغام SIEM خارجی با ابر مایکروسافت را آسان کرد. اکنون وضعیت تغییر کرده است و مایکروسافت پلتفرم Azure Event Hub را به عنوان ابزار ادغام اصلی برای سایر SIEM ها توصیه می کند. بسیاری قبلاً چنین ادغامی را پیاده‌سازی کرده‌اند، اما مراقب باشید - آنها ممکن است همه لاگ‌های Azure را ضبط نکنند، بلکه فقط برخی از آنها را ثبت کنند (در اسناد SIEM خود نگاه کنید).

در پایان یک گشت و گذار کوتاه در Azure، می خواهم یک توصیه کلی در مورد این سرویس ابری ارائه دهم - قبل از اینکه چیزی در مورد عملکردهای نظارت بر امنیت اطلاعات در Azure بگویید، باید آنها را با دقت پیکربندی کنید و آزمایش کنید که آنها همانطور که در اسناد و مدارک نوشته شده است و کار می کنند. همانطور که مشاوران به مایکروسافت گفتند (و ممکن است نظرات متفاوتی در مورد عملکرد عملکردهای Azure داشته باشند). اگر منابع مالی دارید، می توانید اطلاعات مفید زیادی را از Azure در زمینه نظارت بر امنیت اطلاعات جمع آوری کنید. اگر منابع شما محدود است، مانند مورد AWS، باید فقط به قدرت خود و داده های خامی که Azure Monitor در اختیار شما قرار می دهد تکیه کنید. و به یاد داشته باشید که بسیاری از عملکردهای نظارت هزینه دارند و بهتر است از قبل با سیاست قیمت گذاری آشنا شوید. به عنوان مثال، به صورت رایگان می‌توانید 31 روز داده تا حداکثر 5 گیگابایت به ازای هر مشتری ذخیره کنید - برای تجاوز به این مقادیر، باید پول بیشتری بپردازید (تقریباً 2 دلار + برای ذخیره هر گیگابایت اضافی از مشتری و 0,1 دلار برای هر مشتری. ذخیره 1 گیگابایت در هر ماه اضافی). کار با برنامه های تله متری و متریک همچنین ممکن است به بودجه اضافی و همچنین کار با هشدارها و اعلان ها نیاز داشته باشد (محدودیت خاصی به صورت رایگان در دسترس است که ممکن است برای نیازهای شما کافی نباشد).

مثال: نظارت بر امنیت اطلاعات در IaaS بر اساس Google Cloud Platform

Google Cloud Platform در مقایسه با AWS و Azure مانند یک جوان به نظر می رسد، اما این تا حدی خوب است. برخلاف AWS که قابلیت های خود از جمله امنیتی را به تدریج افزایش داد و در تمرکز با مشکل مواجه شد. GCP، مانند Azure، بسیار بهتر به صورت متمرکز مدیریت می شود، که خطاها و زمان اجرا را در سراسر سازمان کاهش می دهد. از نقطه نظر امنیتی، GCP، به اندازه کافی عجیب، بین AWS و Azure است. او همچنین یک ثبت رویداد واحد برای کل سازمان دارد، اما ناقص است. برخی از توابع هنوز در حالت بتا هستند، اما به تدریج این کمبود باید برطرف شود و GCP به پلتفرم بالغ تری از نظر نظارت بر امنیت اطلاعات تبدیل خواهد شد.

ابزار اصلی برای ثبت رویدادها در GCP Stackdriver Logging (شبیه به Azure Monitor) است که به شما امکان می دهد رویدادها را در کل زیرساخت ابری خود (و همچنین از AWS) جمع آوری کنید. از منظر امنیتی در GCP، هر سازمان، پروژه یا پوشه دارای چهار گزارش است:

• Admin Activity - شامل تمام رویدادهای مربوط به دسترسی اداری، به عنوان مثال، ایجاد یک ماشین مجازی، تغییر حقوق دسترسی و غیره است. این لاگ همیشه بدون توجه به تمایل شما نوشته می شود و اطلاعات آن را به مدت 400 روز ذخیره می کند.
• دسترسی به داده - شامل تمام رویدادهای مربوط به کار با داده توسط کاربران ابری (ایجاد، اصلاح، خواندن و غیره) است. به طور پیش فرض، این گزارش نوشته نمی شود، زیرا حجم آن بسیار سریع افزایش می یابد. به همین دلیل ماندگاری آن تنها 30 روز است. علاوه بر این، همه چیز در این مجله نوشته نشده است. به عنوان مثال، رویدادهای مربوط به منابعی که به صورت عمومی برای همه کاربران در دسترس هستند یا بدون ورود به GCP قابل دسترسی هستند، روی آن نوشته نمی شوند.
• رویداد سیستم - شامل رویدادهای سیستمی است که به کاربران مربوط نمی شود یا اقدامات مدیری که پیکربندی منابع ابری را تغییر می دهد. همیشه به مدت 400 روز نوشته و ذخیره می شود.
• Access Transparency یک نمونه منحصر به فرد از گزارش است که همه اقدامات کارمندان Google (اما هنوز برای همه سرویس‌های GCP) که به زیرساخت شما به عنوان بخشی از وظایف شغلی خود دسترسی دارند، ثبت می‌کند. این گزارش به مدت 400 روز ذخیره می شود و برای هر مشتری GCP در دسترس نیست، اما فقط در صورت رعایت تعدادی از شرایط (پشتیبانی از سطح طلایی یا پلاتینیوم، یا وجود 4 نقش از یک نوع خاص به عنوان بخشی از پشتیبانی شرکتی). یک عملکرد مشابه نیز در دسترس است، به عنوان مثال، در Office 365 - Lockbox.

مثال گزارش: دسترسی به شفافیت

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

دسترسی به این گزارش‌ها به روش‌های مختلفی امکان‌پذیر است (به همان روشی که قبلاً در مورد Azure و AWS بحث شد) - از طریق رابط Log Viewer، از طریق API، از طریق Google Cloud SDK، یا از طریق صفحه فعالیت پروژه خود که برای آن به رویدادها علاقه مند هستند به همین ترتیب، آنها را می توان به راه حل های خارجی برای تجزیه و تحلیل اضافی صادر کرد. دومی با صادر کردن گزارش‌ها به ذخیره‌سازی BigQuery یا Cloud Pub/Sub انجام می‌شود.

علاوه بر Stackdriver Logging، پلتفرم GCP همچنین عملکرد Stackdriver Monitoring را ارائه می‌کند که به شما امکان می‌دهد معیارهای کلیدی (عملکرد، MTBF، سلامت کلی و غیره) سرویس‌ها و برنامه‌های ابری را نظارت کنید. داده‌های پردازش‌شده و تجسم‌شده می‌تواند یافتن مشکلات در زیرساخت ابری شما، از جمله در زمینه امنیت را آسان‌تر کند. اما لازم به ذکر است که این عملکرد در زمینه امنیت اطلاعات چندان غنی نخواهد بود، زیرا امروزه GCP آنالوگ همان AWS GuardDuty را ندارد و نمی تواند موارد بد را در بین همه رویدادهای ثبت شده شناسایی کند (گوگل تشخیص تهدید رویداد را توسعه داده است، اما هنوز در مرحله بتا در حال توسعه است و هنوز برای صحبت در مورد مفید بودن آن زود است). Stackdriver Monitoring می‌تواند به‌عنوان سیستمی برای تشخیص ناهنجاری‌ها مورد استفاده قرار گیرد، که سپس برای یافتن علل وقوع آن‌ها بررسی می‌شود. اما با توجه به کمبود پرسنل واجد شرایط در زمینه امنیت اطلاعات GCP در بازار، این کار در حال حاضر دشوار به نظر می رسد.

همچنین ارزش ارائه لیستی از برخی از ماژول های امنیت اطلاعاتی را دارد که می توانند در فضای ابری GCP شما استفاده شوند و مشابه آنچه AWS ارائه می دهد، می باشد:

• Cloud Security Command Center آنالوگ AWS Security Hub و Azure Security Center است.
• Cloud DLP - کشف و ویرایش خودکار داده‌های میزبانی شده در ابر با استفاده از بیش از 90 خط‌مشی طبقه‌بندی از پیش تعریف‌شده (به عنوان مثال پوشاندن).
• Cloud Scanner اسکنر آسیب‌پذیری‌های شناخته‌شده (XSS، Flash Injection، کتابخانه‌های بدون اصلاح و غیره) در App Engine، Compute Engine و Google Kubernetes است.
• Cloud IAM - کنترل دسترسی به تمام منابع GCP.
• Cloud Identity - حساب‌های کاربر، دستگاه و برنامه GCP را از یک کنسول مدیریت کنید.
• Cloud HSM - حفاظت از کلیدهای رمزنگاری.
• سرویس مدیریت کلید ابری - مدیریت کلیدهای رمزنگاری در GCP.
• کنترل سرویس VPC - یک محیط امن در اطراف منابع GCP خود ایجاد کنید تا از آنها در برابر نشت محافظت کنید.
• کلید امنیتی Titan - محافظت در برابر فیشینگ.

بسیاری از این ماژول ها رویدادهای امنیتی را ایجاد می کنند که می توانند برای تجزیه و تحلیل به ذخیره سازی BigQuery ارسال شوند یا به سیستم های دیگر از جمله SIEM صادر شوند. همانطور که در بالا ذکر شد، GCP یک پلتفرم فعال در حال توسعه است و گوگل اکنون در حال توسعه تعدادی ماژول جدید امنیت اطلاعات برای پلتفرم خود است. در میان آنها می‌توان به Event Threat Detection (اکنون در نسخه بتا موجود است)، که لاگ‌های Stackdriver را در جستجوی ردپایی از فعالیت‌های غیرمجاز (مشابه GuardDuty در AWS) اسکن می‌کند، یا Policy Intelligence (موجود در آلفا)، که به شما امکان می‌دهد خط‌مشی‌های هوشمندی را توسعه دهید. دسترسی به منابع GCP

من مروری کوتاه بر قابلیت‌های نظارت داخلی در پلتفرم‌های ابری محبوب کردم. اما آیا شما متخصصانی دارید که بتوانند با گزارش‌های ارائه‌دهنده IaaS «خام» کار کنند (همه آماده خرید قابلیت‌های پیشرفته AWS یا Azure یا Google نیستند)؟ علاوه بر این، بسیاری با ضرب المثل «اعتماد کن، اما تأیید کن» آشنا هستند، که بیش از هر زمان دیگری در زمینه امنیت صادق است. چقدر به قابلیت‌های داخلی ارائه‌دهنده ابری که رویدادهای امنیت اطلاعات را برای شما ارسال می‌کند اعتماد دارید؟ اصلاً چقدر روی امنیت اطلاعات تمرکز می کنند؟

گاهی اوقات ارزش آن را دارد که به راه‌حل‌های نظارت بر زیرساخت‌های ابری همپوشانی نگاه کنید که می‌توانند امنیت ابر داخلی را تکمیل کنند، و گاهی اوقات چنین راه‌حل‌هایی تنها گزینه برای به دست آوردن بینش در مورد امنیت داده‌ها و برنامه‌های میزبانی شده در ابر هستند. علاوه بر این، آنها به سادگی راحت تر هستند، زیرا آنها تمام وظایف تجزیه و تحلیل گزارش های لازم تولید شده توسط سرویس های ابری مختلف از ارائه دهندگان ابری مختلف را بر عهده می گیرند. نمونه ای از چنین راه حل های همپوشانی Cisco Stealthwatch Cloud است که بر روی یک کار متمرکز است - نظارت بر ناهنجاری های امنیت اطلاعات در محیط های ابری، از جمله نه تنها Amazon AWS، Microsoft Azure و Google Cloud Platform، بلکه ابرهای خصوصی.

مثال: نظارت بر امنیت اطلاعات با استفاده از Stealthwatch Cloud

AWS یک پلتفرم محاسباتی منعطف را ارائه می‌کند، اما این انعطاف‌پذیری، اشتباهاتی را برای شرکت‌ها آسان‌تر می‌کند که منجر به مشکلات امنیتی می‌شود. و مدل امنیت اطلاعات مشترک تنها به این امر کمک می کند. اجرای نرم‌افزار در فضای ابری با آسیب‌پذیری‌های ناشناخته (مثلاً با AWS Inspector یا GCP Cloud Scanner می‌توان با آسیب‌پذیری‌های شناخته شده مبارزه کرد)، رمزهای عبور ضعیف، پیکربندی‌های نادرست، اینسایدرها و غیره. و همه اینها در رفتار منابع ابری منعکس می شود که می تواند توسط Cisco Stealthwatch Cloud که یک سیستم نظارت بر امنیت اطلاعات و تشخیص حمله است، نظارت کند. ابرهای عمومی و خصوصی

یکی از ویژگی‌های کلیدی Cisco Stealthwatch Cloud، توانایی مدل‌سازی موجودیت‌ها است. با استفاده از آن، می‌توانید یک مدل نرم‌افزاری (یعنی شبیه‌سازی تقریباً واقعی) از هر یک از منابع ابری خود ایجاد کنید (مهم نیست AWS، Azure، GCP یا چیز دیگری باشد). اینها می‌توانند شامل سرورها و کاربران، و همچنین انواع منابع خاص محیط ابری شما، مانند گروه‌های امنیتی و گروه‌های مقیاس خودکار باشند. این مدل‌ها از جریان‌های داده ساختاریافته ارائه شده توسط سرویس‌های ابری به عنوان ورودی استفاده می‌کنند. به عنوان مثال، برای AWS این موارد VPC Flow Logs، AWS CloudTrail، AWS CloudWatch، AWS Config، AWS Inspector، AWS Lambda و AWS IAM هستند. مدل سازی موجودیت به طور خودکار نقش و رفتار هر یک از منابع شما را کشف می کند (شما می توانید در مورد نمایه سازی تمام فعالیت های ابری صحبت کنید). این نقش ها شامل دستگاه تلفن همراه اندروید یا اپل، سرور Citrix PVS، سرور RDP، دروازه ایمیل، سرویس گیرنده VoIP، سرور ترمینال، کنترل کننده دامنه و غیره است. سپس به طور مداوم بر رفتار آنها نظارت می کند تا مشخص کند که چه زمانی رفتار خطرناک یا تهدید کننده ایمنی رخ می دهد. شما می توانید حدس زدن رمز عبور، حملات DDoS، نشت داده ها، دسترسی غیرقانونی از راه دور، فعالیت کدهای مخرب، اسکن آسیب پذیری و سایر تهدیدها را شناسایی کنید. به عنوان مثال، تشخیص تلاش برای دسترسی از راه دور از یک کشور غیر معمول برای سازمان شما (کره جنوبی) به یک خوشه Kubernetes از طریق SSH به این صورت است:

و این چیزی است که ادعا می شود نشت اطلاعات از پایگاه داده Postgress به کشوری که قبلاً با آن تعامل نداشته ایم:

در نهایت، این چیزی است که بسیاری از تلاش های ناموفق SSH از چین و اندونزی از یک دستگاه راه دور خارجی به نظر می رسد:

یا، فرض کنید که نمونه سرور در VPC، طبق خط مشی، هرگز مقصد ورود از راه دور نیست. اجازه دهید فرض کنیم که این رایانه به دلیل تغییر اشتباه در خط مشی قوانین فایروال، ورود از راه دور را تجربه کرده است. ویژگی Entity Modeling این فعالیت ("دسترسی از راه دور غیرمعمول") را تقریباً در زمان واقعی شناسایی و گزارش می کند و به تماس خاص AWS CloudTrail، Azure Monitor یا GCP Stackdriver Logging API (شامل نام کاربری، تاریخ و زمان، در میان جزئیات دیگر) اشاره می کند. که باعث تغییر قانون ITU شد. و سپس این اطلاعات می تواند برای تجزیه و تحلیل به SIEM ارسال شود.

قابلیت‌های مشابهی برای هر محیط ابری که توسط Cisco Stealthwatch Cloud پشتیبانی می‌شود، اجرا می‌شود:

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

• آیا کسی در نرم افزاری که ما از آن استفاده می کنیم یک درب پشتی کشف کرده است؟
• آیا نرم افزار یا دستگاه شخص ثالثی در فضای ابری ما وجود دارد؟
• آیا کاربر مجاز از امتیازات سوء استفاده می کند؟
• آیا یک خطای پیکربندی وجود داشت که اجازه دسترسی از راه دور یا استفاده ناخواسته دیگر از منابع را می داد؟
• آیا نشت داده از سرورهای ما وجود دارد؟
• آیا کسی سعی داشت از یک موقعیت جغرافیایی غیر معمول به ما متصل شود؟
• آیا ابر ما به کدهای مخرب آلوده شده است؟

یک رویداد امنیت اطلاعات شناسایی شده را می توان در قالب یک بلیط مربوطه به Slack، Cisco Spark، سیستم مدیریت رویداد PagerDuty ارسال کرد و همچنین به SIEM های مختلف از جمله Splunk یا ELK ارسال کرد. به طور خلاصه، می‌توان گفت که اگر شرکت شما از استراتژی چند ابری استفاده می‌کند و محدود به یک ارائه‌دهنده ابر نیست، قابلیت‌های نظارت بر امنیت اطلاعات که در بالا توضیح داده شد، استفاده از Cisco Stealthwatch Cloud گزینه خوبی برای به دست آوردن مجموعه‌ای از نظارت است. قابلیت‌هایی برای بازیکنان پیشرو ابر - آمازون، مایکروسافت و گوگل. جالب ترین چیز این است که اگر قیمت های Stealthwatch Cloud را با مجوزهای پیشرفته برای نظارت بر امنیت اطلاعات در AWS، Azure یا GCP مقایسه کنید، ممکن است معلوم شود که راه حل Cisco حتی ارزان تر از قابلیت های داخلی آمازون، مایکروسافت خواهد بود. و راه حل های گوگل این متناقض است، اما واقعیت دارد. و هرچه از ابرها و قابلیت های آنها بیشتر استفاده کنید، مزیت راه حل تلفیقی آشکارتر خواهد بود.

علاوه بر این، Stealthwatch Cloud می‌تواند ابرهای خصوصی مستقر در سازمان شما را نظارت کند، به عنوان مثال، بر اساس کانتینرهای Kubernetes یا با نظارت بر جریان‌های Netflow یا ترافیک شبکه دریافتی از طریق انعکاس در تجهیزات شبکه (حتی تولید داخلی)، داده‌های AD یا سرورهای DNS و غیره. همه این داده ها با اطلاعات Threat Intelligence که توسط Cisco Talos، بزرگترین گروه غیردولتی محققان تهدیدات امنیت سایبری در جهان جمع آوری شده است، غنی می شود.

این به شما امکان می دهد یک سیستم نظارتی یکپارچه را برای ابرهای عمومی و ترکیبی که شرکت شما ممکن است از آن استفاده کند، پیاده سازی کنید. سپس اطلاعات جمع آوری شده را می توان با استفاده از قابلیت های داخلی Stealthwatch Cloud تجزیه و تحلیل کرد یا به SIEM شما ارسال کرد (Splunk، ELK، SumoLogic و چندین مورد دیگر به طور پیش فرض پشتیبانی می شوند).

با این کار، بخش اول مقاله را تکمیل می کنیم که در آن ابزارهای داخلی و خارجی برای نظارت بر امنیت اطلاعات پلتفرم های IaaS/PaaS را بررسی کردم که به ما امکان می دهد به سرعت حوادث رخ داده در محیط های ابری را شناسایی و به آنها پاسخ دهیم. شرکت ما انتخاب کرده است. در قسمت دوم به ادامه موضوع می پردازیم و گزینه های نظارت بر پلتفرم های SaaS را با استفاده از مثال Salesforce و Dropbox بررسی می کنیم و همچنین سعی می کنیم با ایجاد یک سیستم نظارت بر امنیت اطلاعات یکپارچه برای ارائه دهندگان ابری مختلف همه چیز را خلاصه و کنار هم قرار دهیم.

منبع: www.habr.com