«و چنین خواهد شد»: که ارائه‌دهندگان ابر درباره داده‌های شخصی مذاکره نمی‌کنند

یک روز درخواستی برای خدمات ابری دریافت کردیم. ما به طور کلی مواردی را که از ما خواسته می شود را بیان کردیم و لیستی از سوالات را برای روشن شدن جزئیات ارسال کردیم. سپس پاسخ ها را تجزیه و تحلیل کردیم و متوجه شدیم: مشتری می خواهد داده های شخصی سطح دوم امنیت را در فضای ابری قرار دهد. ما به او پاسخ می دهیم: "شما سطح دومی از داده های شخصی دارید، متاسفم، ما فقط می توانیم یک ابر خصوصی ایجاد کنیم." و او: "می دانید، اما در شرکت X آنها می توانند همه چیز را به صورت عمومی برای من پست کنند."

عکس از استیو کریسپ، رویترز

چیزهای عجیب! ما به وب سایت شرکت X رفتیم، مدارک گواهینامه آنها را مطالعه کردیم، سرمان را تکان دادیم و متوجه شدیم: سؤالات باز زیادی در قرار دادن داده های شخصی وجود دارد و باید به طور کامل به آنها رسیدگی شود. این کاری است که ما در این پست انجام خواهیم داد.

چگونه همه چیز باید کار کند

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

انواع تهدیدات فعلی در تعریف شده است فرمان شماره 1119 دولت فدراسیون روسیه مورخ 1 نوامبر 2012 "در مورد تصویب الزامات حفاظت از داده های شخصی در هنگام پردازش آنها در سیستم های اطلاعات داده های شخصی":

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

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

تهدیدهای نوع 3 برای یک سیستم اطلاعاتی مرتبط هستند تهدیدهایی که مرتبط نیستند با وجود قابلیت های غیرمستند (اعلام نشده). در نرم افزارهای سیستمی و کاربردیدر سیستم اطلاعاتی استفاده می شود."

نکته اصلی در این تعاریف وجود قابلیت های غیرمستند (اعلام نشده) است. برای تأیید عدم وجود قابلیت های نرم افزاری غیرمستند (در مورد ابر، این یک هایپروایزر است)، صدور گواهینامه توسط FSTEC روسیه انجام می شود. اگر اپراتور PD بپذیرد که چنین قابلیت هایی در نرم افزار وجود ندارد، تهدیدهای مربوطه بی ربط هستند. تهدیدهای نوع 1 و 2 به ندرت توسط اپراتورهای PD مرتبط در نظر گرفته می شوند.

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

FSTEC به وضوح تمام تهدیدات اصلی را فهرست می کند NOS (پایگاه داده تهدید). ارائه دهندگان زیرساخت ابری و ارزیابان از این پایگاه داده در کار خود استفاده می کنند. در اینجا نمونه هایی از تهدیدات وجود دارد:

UBI.44: "تهدید احتمال نقض امنیت داده های کاربر برنامه های فعال در داخل ماشین مجازی توسط نرم افزارهای مخرب خارج از ماشین مجازی است." این تهدید به دلیل وجود آسیب‌پذیری‌ها در نرم‌افزار Hypervisor است که تضمین می‌کند فضای آدرس مورد استفاده برای ذخیره داده‌های کاربر برای برنامه‌های فعال در داخل ماشین مجازی از دسترسی غیرمجاز توسط نرم‌افزارهای مخرب خارج از ماشین مجازی جدا شده است.

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

UBI.101: "تهدید در امکان دسترسی غیرمجاز به اطلاعات محافظت شده یک مصرف کننده سرویس ابری از دیگری است. این تهدید به این دلیل است که به دلیل ماهیت فناوری های ابری، مصرف کنندگان خدمات ابری باید زیرساخت ابری یکسانی را به اشتراک بگذارند. اگر هنگام جداسازی عناصر زیرساخت ابری بین مصرف کنندگان سرویس ابری و همچنین هنگام جداسازی منابع آنها و جداسازی داده ها از یکدیگر، خطاهایی رخ دهد، این تهدید قابل تحقق است.

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

و مطابق با به دستور FSTEC شماره 21 مورخ 18 فوریه 2013، هایپروایزر باید به عنوان غیر NDV در سطح 4 گواهی شود، در غیر این صورت استفاده از داده های شخصی سطح 1 و 2 با آن غیرقانونی خواهد بود («بند 12. ... برای اطمینان از سطوح 1 و 2 امنیت داده های شخصی و همچنین برای اطمینان از سطح 3 امنیت داده های شخصی در سیستم های اطلاعاتی که تهدیدات نوع 2 برای آنها به عنوان فعلی طبقه بندی می شود، از ابزارهای امنیت اطلاعات استفاده می شود که نرم افزار آن حداقل بر اساس 4 سطح کنترل بر عدم وجود قابلیت های اعلام نشده آزمایش شده است.).

فقط یک هایپروایزر که در روسیه توسعه یافته است دارای سطح مورد نیاز گواهینامه است، NDV-4. افق خورشید. به بیان ملایم، محبوب ترین راه حل نیست. ابرهای تجاری، به عنوان یک قاعده، بر اساس VMware vSphere، KVM، Microsoft Hyper-V ساخته می شوند. هیچ یک از این محصولات دارای گواهینامه NDV-4 نیستند. چرا؟ این احتمال وجود دارد که اخذ چنین گواهی برای تولیدکنندگان هنوز توجیه اقتصادی نداشته باشد.

و تنها چیزی که برای داده های شخصی سطح 1 و 2 در ابر عمومی برای ما باقی می ماند Horizon BC است. غم انگیز اما واقعی

چگونه همه چیز (از نظر ما) واقعاً کار می کند

در نگاه اول، همه چیز کاملاً سختگیرانه است: این تهدیدها باید با پیکربندی صحیح مکانیسم های حفاظتی استاندارد یک Hypervisor تأیید شده بر اساس NDV-4 از بین بروند. اما یک خلاء وجود دارد. مطابق با دستور FSTEC شماره 21 (بند 2 امنیت داده های شخصی هنگام پردازش در سیستم اطلاعات داده های شخصی (از این پس سیستم اطلاعاتی نامیده می شود) توسط اپراتور یا شخصی که داده های شخصی را از طرف اپراتور پردازش می کند تضمین می شود. قانون فدراسیون روسیه"، ارائه دهندگان به طور مستقل ارتباط تهدیدات احتمالی را ارزیابی کرده و اقدامات حفاظتی را بر اساس آن انتخاب می کنند. بنابراین، اگر تهدیدات UBI.44 و UBI.101 را به عنوان فعلی نپذیرفتید، دیگر نیازی به استفاده از هایپروایزر تأیید شده بر اساس NDV-4 نیست، که دقیقاً همان چیزی است که باید در برابر آنها محافظت کند. و این برای دریافت گواهی انطباق ابر عمومی با سطوح 1 و 2 امنیت داده های شخصی کافی خواهد بود که Roskomnadzor کاملاً از آن راضی خواهد بود.

البته، علاوه بر Roskomnadzor، FSTEC ممکن است با بازرسی همراه شود - و این سازمان در مسائل فنی بسیار دقیق تر است. او احتمالاً علاقه مند خواهد بود که چرا دقیقاً تهدیدات UBI.44 و UBI.101 نامربوط در نظر گرفته شده اند؟ اما معمولاً FSTEC فقط زمانی بازرسی را انجام می دهد که اطلاعاتی در مورد یک حادثه مهم دریافت کند. در این مورد، خدمات فدرال ابتدا به اپراتور داده های شخصی - یعنی مشتری خدمات ابری می رسد. در بدترین حالت، اپراتور جریمه کوچکی دریافت می کند - به عنوان مثال، برای توییتر در ابتدای سال جریمه در یک مورد مشابه 5000 روبل بود. سپس FSTEC بیشتر به سمت ارائه دهنده خدمات ابری می رود. که ممکن است به دلیل عدم رعایت الزامات نظارتی از مجوز محروم شود - و این خطرات کاملاً متفاوتی هستند، هم برای ارائه دهنده ابر و هم برای مشتریانش. اما، تکرار می کنم، برای بررسی FSTEC، معمولاً به یک دلیل واضح نیاز دارید. بنابراین ارائه دهندگان ابر مایل به ریسک هستند. تا اولین حادثه جدی.

همچنین گروهی از ارائه‌دهندگان «مسئول‌تر» هستند که معتقدند می‌توان با افزودن افزونه‌ای مانند vGate به هایپروایزر، تمام تهدیدات را بسته کرد. اما در یک محیط مجازی توزیع شده بین مشتریان برای برخی از تهدیدات (به عنوان مثال، UBI.101 فوق)، یک مکانیسم حفاظتی موثر فقط در سطح یک هایپروایزر دارای گواهی NDV-4 قابل اجرا است، زیرا هر سیستم الحاقی به عملکردهای استاندارد هایپروایزر برای مدیریت منابع (به ویژه RAM) تأثیری ندارد.

چگونه کار می کنیم

ما یک بخش ابری داریم که روی یک هایپروایزر تایید شده توسط FSTEC (اما بدون گواهی NDV-4) پیاده سازی شده است. این بخش دارای گواهی است، بنابراین داده های شخصی را می توان بر اساس آن در فضای ابری ذخیره کرد 3 و 4 سطح امنیت - الزامات حفاظت در برابر قابلیت های اعلام نشده لازم نیست در اینجا رعایت شود. در اینجا، به هر حال، معماری بخش ابر ایمن ما است:

سیستم های اطلاعات شخصی 1 و 2 سطح امنیت ما فقط بر روی تجهیزات اختصاصی اجرا می کنیم. فقط در این مورد، به عنوان مثال، تهدید UBI.101 واقعاً مرتبط نیست، زیرا رک های سرور که توسط یک محیط مجازی متحد نشده اند، حتی زمانی که در یک مرکز داده قرار دارند، نمی توانند بر یکدیگر تأثیر بگذارند. برای چنین مواردی، ما خدمات اجاره تجهیزات اختصاصی را ارائه می دهیم (به آن Hardware as a service نیز گفته می شود).

اگر مطمئن نیستید که چه سطحی از امنیت برای سیستم داده های شخصی شما مورد نیاز است، ما نیز به طبقه بندی آن کمک می کنیم.

نتیجه

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

منبع: www.habr.com