"وهكذا ستفعل": لا يوافق مقدمو الخدمات السحابية على البيانات الشخصية

بطريقة ما جاء إلينا تطبيق للخدمات السحابية. لقد توصلنا بشكل عام إلى ما هو مطلوب منا ، وأرسلنا قائمة من الأسئلة لتوضيح التفاصيل. ثم حللنا الإجابات وأدركنا: يريد العميل وضع البيانات الشخصية للمستوى الثاني من الأمان في السحابة. نجيبه: "لديك المستوى الثاني من البيانات الشخصية ، آسف ، يمكننا فقط إنشاء سحابة خاصة." وهو: "كما تعلم ، لكن في الشركة X يمكنهم وضع كل شيء في العلن من أجلي."

الصورة ستيف كريسب ، رويترز

أشياء غريبة! ذهبنا إلى موقع الشركة X ، ودرسنا وثائق تصديقهم ، وهزنا رؤوسنا وأدركنا أن هناك الكثير من الأسئلة المفتوحة في وضع البيانات الشخصية ويجب أن تكون جيدة التهوية. ماذا سنفعل في هذا المنشور.

كيف يجب أن تعمل الأشياء

بادئ ذي بدء ، دعنا نتعرف على الأسس التي تُنسب إليها البيانات الشخصية بشكل عام إلى مستوى أو آخر من مستويات الأمان. يعتمد ذلك على فئة البيانات ، وعلى عدد مواضيع هذه البيانات التي يخزنها المشغل ويعالجها ، وكذلك على نوع التهديدات الحالية.

لتعريف أنواع التهديدات الحالية ، انظر مرسوم حكومة الاتحاد الروسي رقم 1119 بتاريخ 1 نوفمبر 2012 "بشأن الموافقة على متطلبات حماية البيانات الشخصية أثناء معالجتها في أنظمة معلومات البيانات الشخصية":

"التهديدات من النوع الأول ذات صلة بنظام المعلومات ، إذا كانت ، من بين أمور أخرى ، التهديدات الحالية المرتبطة مع وجود ميزات غير موثقة (غير معلن عنها) في برنامج النظامالمستخدمة في نظام المعلومات.

التهديدات من النوع الثاني ذات صلة بنظام المعلومات ، إذا كانت ، من بين أمور أخرى ، التهديدات الحالية المرتبطة مع وجود ميزات غير موثقة (غير معلن عنها) في البرامج التطبيقيةالمستخدمة في نظام المعلومات.

التهديدات من النوع الثالث ذات صلة بنظام المعلومات إذا كانت كذلك التهديدات ذات الصلة غير ذات الصلة مع وجود ميزات غير موثقة (غير معلن عنها) في برامج النظام والتطبيقالمستخدمة في نظام المعلومات ".

الشيء الرئيسي في هذه التعريفات هو وجود ميزات غير موثقة (غير معلن عنها). لتأكيد عدم وجود ميزات البرامج غير الموثقة (في حالة السحابة ، هذا برنامج مراقبة فائقة) ، تم اعتماد FSTEC of Russia. إذا وافق مشغل PD على عدم وجود مثل هذه الفرص في البرنامج ، فإن التهديدات المقابلة تكون غير ذات صلة. نادرًا ما يتم قبول التهديدات من النوعين الأول والثاني من قبل مشغلي PD حسب الاقتضاء.

بالإضافة إلى تحديد مستوى أمان PD ، يجب على المشغل أيضًا تحديد التهديدات الحالية المحددة للسحابة العامة ، وبناءً على المستوى المحدد لأمان PD والتهديدات الحالية ، تحديد التدابير اللازمة ووسائل الحماية ضدها.

يحتوي FSTEC على جميع التهديدات الرئيسية المدرجة بوضوح في رقم (قاعدة بيانات التهديد). يستخدم مقدمو البنى التحتية السحابية ومعتمدوها هذه القاعدة في عملهم. فيما يلي أمثلة على التهديدات:

UBI 44: "التهديد يكمن في إمكانية تعريض أمن بيانات المستخدم للبرامج التي تعمل داخل الجهاز الظاهري للخطر من خلال برامج ضارة تعمل خارج الجهاز الظاهري". يرجع هذا التهديد إلى وجود ثغرات أمنية في برنامج Hypervisor ، مما يضمن عزل مساحة العنوان المستخدمة لتخزين بيانات المستخدم الخاصة بالبرامج التي تعمل داخل الجهاز الظاهري من الوصول غير المصرح به بواسطة البرامج الضارة التي تعمل خارج الجهاز الظاهري.

يكون تنفيذ هذا التهديد ممكنًا إذا تغلب رمز البرنامج الضار بنجاح على حدود الجهاز الظاهري ، ليس فقط من خلال استغلال نقاط الضعف في برنامج Hypervisor ، ولكن أيضًا من خلال تنفيذ مثل هذا التأثير من مستويات أقل (فيما يتعلق بـ Hypervisor) من يعمل النظام.

UBI 101: "يكمن التهديد في إمكانية الوصول غير المصرح به إلى المعلومات المحمية لأحد مستهلكين الخدمة السحابية من قبل مستهلك آخر. يرجع هذا التهديد إلى حقيقة أنه ، نظرًا لطبيعة التقنيات السحابية ، يتعين على مستهلكي الخدمات السحابية مشاركة نفس البنية التحتية السحابية. يكون تنفيذ هذا التهديد ممكنًا في حالة حدوث أخطاء عند فصل عناصر البنية التحتية السحابية بين مستهلكي الخدمات السحابية ، وكذلك عند عزل مواردهم وعزل البيانات عن بعضهم البعض.

لا يمكنك الحماية من هذه التهديدات إلا بمساعدة برنامج Hypervisor ، لأنه هو الذي يدير الموارد الافتراضية. وبالتالي ، يجب اعتبار برنامج Hypervisor كوسيلة للحماية.

ووفقًا لـ طلب FSTEC رقم 21 بتاريخ 18 فبراير 2013 ، يجب اعتماد برنامج Hypervisor لعدم وجود NDV في المستوى 4 ، وإلا فإن استخدام البيانات الشخصية من المستويين 1 و 2 سيكون غير قانوني ("البند 12. ... لضمان المستويين الأول والثاني من أمان البيانات الشخصية ، وكذلك لضمان المستوى الثالث من أمان البيانات الشخصية في أنظمة المعلومات التي يتم تصنيف التهديدات من النوع 1 لها على أنها ذات صلة ، يتم استخدام أدوات أمان المعلومات ، والتي تم استخدام برمجياتها اختبرت ما لا يقل عن 2 مستوى التحكم في غياب القدرات غير المعلنة ").

المستوى المطلوب من الشهادة ، NDV-4 ، لديه جهاز مراقبة واحد فقط ، تطوير روسي - أفق الشمس. بعبارة ملطفة ، ليس الحل الأكثر شيوعًا. عادةً ما يتم إنشاء السحب التجارية على أساس VMware vSphere و KVM و Microsoft Hyper-V. لم يتم اعتماد أي من هذه المنتجات NDV-4. لماذا؟ من المحتمل أن الحصول على هذه الشهادة للمصنعين ليس له ما يبرره اقتصاديًا بعد.

ويبقى بالنسبة لنا البيانات الشخصية للمستويين الأول والثاني في السحابة العامة فقط Horizon VS. محزن لكن حقيقي.

كيف يعمل كل شيء (في رأينا) في الواقع

للوهلة الأولى ، كل شيء صارم تمامًا: يجب القضاء على هذه التهديدات من خلال التهيئة الصحيحة لآليات الحماية القياسية لبرنامج Hypervisor المعتمد وفقًا لـ NDV-4. لكن هناك ثغرة واحدة. وفقًا لأمر FSTEC رقم 21 ("البند 2 يتم ضمان أمان البيانات الشخصية أثناء معالجتها في نظام معلومات البيانات الشخصية (المشار إليه فيما يلي باسم نظام المعلومات) من قبل المشغل أو الشخص الذي يعالج البيانات الشخصية نيابة عن المشغل وفقًا لـ تشريع الاتحاد الروسي ") ، يقوم مقدمو الخدمة بتقييم مدى صلة التهديدات المحتملة بشكل مستقل ، ووفقًا لذلك ، يختارون تدابير الحماية. لذلك ، إذا لم يتم قبول تهديدات UBI.44 و UBI.101 على أنها ذات صلة ، فلن تكون هناك حاجة لاستخدام برنامج Hypervisor المعتمد وفقًا لـ NDV-4 ، والذي يجب أن يوفر الحماية ضدها. وسيكون هذا كافيًا للحصول على شهادة امتثال السحابة العامة بمستويين 1 و 2 من أمان PD ، والتي ستكون Roskomnadzor راضية تمامًا عنها.

بالطبع ، بالإضافة إلى Roskomnadzor ، يمكن أن تأتي FSTEC مع تدقيق - وهذه المنظمة أكثر دقة في الأمور الفنية. من المؤكد أنها ستكون مهتمة بالسبب في اعتبار التهديدات UBI.44 و UBI.101 غير ذات صلة؟ لكن عادة ما تقوم FSTEC بإجراء تفتيش فقط عندما تتلقى معلومات حول بعض الحوادث الساطعة. في هذه الحالة ، تأتي الخدمة الفيدرالية أولاً إلى مشغل البيانات الشخصية - أي عميل الخدمات السحابية. في أسوأ الحالات ، يتلقى المشغل غرامة صغيرة - على سبيل المثال ، على Twitter في بداية العام غرامة في حالة مماثلة بلغت 5000 روبل. ثم يذهب FSTEC إلى أبعد من ذلك إلى مزود الخدمة السحابية. والتي قد يتم حرمانها من التراخيص بسبب عدم الامتثال للمتطلبات التنظيمية - وهذه مخاطر مختلفة تمامًا ، لكل من موفر السحابة وعملائه. لكني أكرر عادة ما تكون هناك حاجة لسبب واضح للتحقق من FSTEC. لذا فإن مقدمي الخدمات السحابية على استعداد لتحمل المخاطر. حتى أول حادث كبير.

هناك أيضًا مجموعة من مقدمي الخدمات "الأكثر مسؤولية" الذين يعتقدون أنه من الممكن إغلاق جميع التهديدات عن طريق إضافة وظيفة إضافية مثل vGate إلى برنامج Hypervisor. ولكن في بيئة افتراضية موزعة بين العملاء لبعض التهديدات (على سبيل المثال ، UBI.101 أعلاه) ، لا يمكن تنفيذ آلية حماية فعالة إلا على مستوى المشرف المعتمد وفقًا لـ NDV-4 ، نظرًا لأن أي أنظمة إضافية لـ لا تؤثر الوظائف القياسية لبرنامج Hypervisor لإدارة الموارد (على وجه الخصوص ، RAM).

كيف نعمل

لدينا شريحة سحابية مطبقة على برنامج Hypervisor المعتمد من FSTEC (ولكن بدون شهادة NDV-4). تم اعتماد هذا المقطع ، بحيث يمكن وضع البيانات الشخصية في السحابة بناءً عليها 3 و 4 مستويات أمان - لا يلزم هنا مراعاة متطلبات الحماية من القدرات غير المعلنة. بالمناسبة ، إليك بنية الجزء السحابي الآمن لدينا:

أنظمة البيانات الشخصية 1 و 2 مستويات أمان نحن ننفذ فقط على معدات مخصصة. فقط في هذه الحالة ، على سبيل المثال ، لا يكون تهديد UBI.101 مناسبًا حقًا ، نظرًا لأن رفوف الخوادم التي لا توحدها بيئة افتراضية واحدة لا يمكن أن تؤثر على بعضها البعض حتى عند وضعها في نفس مركز البيانات. في مثل هذه الحالات ، نقدم خدمة تأجير معدات مخصصة (تسمى أيضًا الأجهزة كخدمة ، والمعدات كخدمة).

إذا لم تكن متأكدًا من مستوى الأمان المطلوب لنظام بياناتك الشخصية ، فإننا نساعد أيضًا في تصنيفها.

إنتاج

أظهرت أبحاث السوق الصغيرة التي أجريناها أن بعض مشغلي السحابة على استعداد تام للمخاطرة بأمن بيانات العملاء ومستقبلهم لتلقي طلب. لكننا نتمسك بسياسة مختلفة في هذه الأمور ، والتي وصفناها بإيجاز أعلى قليلاً. سنكون سعداء للإجابة على أسئلتك في التعليقات.

المصدر: www.habr.com