وفقًا للقوانين الروسية ، فإن أي شركة تتعامل مع البيانات الشخصية لمستخدميها في روسيا تصبح مشغل PD ، سواء أرادت ذلك أم لا. هذا يفرض عليه عددًا من الالتزامات الرسمية والإجرائية التي لا تستطيع أو ترغب كل شركات في تحملها بشكل مستقل.
كما تبين الممارسة ، فهي لا تريد ذلك حقًا ، لأن مجال المعرفة هذا لا يزال جديدًا ولا يتم اختباره في الممارسة العملية حتى أن المحترفين يواجهون صعوبات وأسئلة. اليوم سوف نتحدث عن كيفية تطبيقنا للمشروع لتخزين البيانات الشخصية لعملائنا والصعوبات غير الواضحة التي واجهناها.
كيف ساعدنا في حماية البيانات على 152-FZ
في بداية عام 2019 ، اتصل بنا Smart Service LLC ، مطور نظام إدارة خدمة
HubEx وتطبيق تبادل تبادل بيانات
myQRcards .
يتيح لك الحل الأول أتمتة عملية صيانة المعدات في مجموعة متنوعة من المجالات - بدءًا من إعداد آلات القهوة ومكيفات الهواء في غرف المكاتب وحتى إصلاح توربينات الغاز. والثاني مصمم عبر الإنترنت لإنشاء بطاقات عمل إلكترونية تعتمد على رموز QR.
MyQRcards بطاقة العمل عبر الإنترنت.يقوم كلا النظامين بتخزين ومعالجة بيانات المستخدم التي تندرج تحت تصنيف "الشخصية" وفقًا لـ 152-FZ. في هذه الحالة ، يفرض القانون عددًا من القيود على أنظمة تخزين هذه البيانات الشخصية من أجل ضمان المستوى المطلوب من أمانها والقضاء على خطر الوصول غير المصرح به للسرقة أو سوء الاستخدام.
يجب احترام القانون ، لكن Smart Service لم تخطط لتطوير اختصاصها في حماية البيانات الشخصية. لذلك ، الخدمات والبيانات المشتركة من قبل المستخدمين "نقل" إلى Linxdatacenter. قامت Smart Service بنقل قدرات الخادم الخاصة ببيئة العمل إلى منطقة شبكة محمية محمية بمركز البيانات الخاص بنا ، معتمدة وفقًا للمتطلبات المنصوص عليها في 152-FZ - ما يسمى "السحاب المحمي".
كيف يتم استخدام السحب المحمية
يجب أن يفي أي نظام معلومات يعالج البيانات الشخصية بثلاثة متطلبات أساسية:
- يجب أن يكون الوصول إلى خوادم تخزين ومعالجة البيانات عبر قناة VPN مع تشفير وفقًا لـ GOST ؛
- يجب مراقبة خوادم التخزين والمعالجة باستمرار عن طريق الحماية من الفيروسات بحثًا عن الثغرات الأمنية ؛
- يجب أن يكون التخزين في شبكات معزولة.
نضع قدرات خادم العميل في مناطق منفصلة تفي بمتطلبات 152- وتساعد في الحصول على استنتاج بشأن الامتثال.
بنية تحتية افتراضية محمية لـ Smart Service LLC.سير العمل
تمت الموافقة المبدئية على العمل في يونيو 2019 ، والذي يمكن اعتباره تاريخ بدء المشروع. يجب أن يتم كل العمل في بيئة "حية" مع الآلاف من الطلبات في اليوم الواحد. وبطبيعة الحال ، كان مطلوبًا إكمال المشروع دون مقاطعة التشغيل العادي لكلا النظامين.
لذلك ، تم وضع خطة عمل واضحة والاتفاق عليها ، مقسمة إلى 4 مراحل:
- تدريب
- هجرة
- الاختبار والتحقق في الظروف الحقيقية ،
- إدراج أنظمة المراقبة والقيود المفروضة على الوصول.
فقط في حالة ، قمنا بتوفير إجراء استرداد الطوارئ (DRP). وفقًا لخطة العمل الأولية ، لم يستغرق الكثير من الوقت والموارد وكان من المفترض أن يتم الانتهاء منها في يوليو 2019. تم توفير كل مرحلة من المراحل لإجراء اختبار كامل لتوافر الشبكة ووظائف النظام في النهاية.
أصعب مرحلة فيها "شيء ما يمكن أن يحدث خطأ" كانت الهجرة. في البداية ، خططنا للهجرة عن طريق تحريك الأجهزة الافتراضية بالكامل. كان هذا هو الخيار الأكثر منطقية ، لأنه لا يتطلب مشاركة موارد إضافية لإعادة التكوين. يبدو أن vMotion يمكن أن يكون أكثر بساطة.
فجأة
ومع ذلك ، كما هو الحال عادة في المشاريع في مجال جديد نسبيًا ، حدث شيء غير متوقع.
نظرًا لأن كل جهاز ظاهري يشغل 500 - 1000 غيغابايت ، فإن نسخ هذه الكميات حتى في إطار مركز بيانات واحد يستغرق حوالي 3-4 ساعات لكل جهاز. نتيجة لذلك ، لم نلتق نافذة الوقت المخصص. كان هذا بسبب القيود الفعلية للنظام الفرعي للقرص عند نقل البيانات إلى vCloud.
لم يسمح خطأ إصدار vCloud المستخدم بتنظيم التخزين vMotion بالنسبة لجهاز ظاهري به أنواع مختلفة من الأقراص ، لذلك كان لا بد من تغيير الأقراص. ونتيجة لذلك ، اتضح أن نقل الأجهزة الافتراضية ، لكنه استغرق وقتًا أطول من المخطط.
النقطة الثانية التي لم نتوقعها هي القيود المفروضة على نقل كتلة قاعدة البيانات (مجموعة تجاوز الفشل MS SQLServer). نتيجة لذلك ، كان علينا نقل الكتلة للعمل مع عقدة واحدة وتركها خارج المنطقة المحمية.
تجدر الإشارة إلى أنه: لسبب ما ، ونتيجة لترحيل الأجهزة الافتراضية ، انهارت مجموعة التطبيقات وكان لا بد من إعادة تجميعها.
كنتيجة للمحاولة الأولى ، حصلنا على الحالة غير المرضية للأنظمة واضطررنا إلى إعادة النظر في تخطيط الخيارات وتطويرها.
محاولة رقم 2
بعد العمل على الأخطاء ، أدرك الفريق أنه سيكون من الأصح تكرار البنية التحتية في المنطقة المحمية ونسخ ملفات البيانات فقط. تقرر عدم المطالبة برسوم إضافية من العميل لسعات خادم إضافية كان لا بد من نشرها لإكمال عملية الترحيل.
نتيجة لذلك ، عندما تم تكرار المجموعات في المنطقة المحمية تمامًا ، مرت الهجرة دون مشاكل.
علاوة على ذلك ، كان من الضروري فقط فصل شبكات المناطق المحمية وغير المحمية. كانت هناك بعض الانقطاعات الطفيفة في العمل. تمكنت مرحلة الاختبار للنظام بأكمله في المنطقة المحمية دون أي حماية من البدء في الوضع العادي. بعد جمع إحصائيات إيجابية حول النظام في هذا الوضع ، انتقلنا إلى المرحلة الأخيرة: تشغيل أنظمة الأمان وتقييد الوصول.
نتائج فعالة ودرس مفيد
ونتيجة لذلك ، كان من الممكن ، مع العميل ، إجراء تغييرات كبيرة على البنية التحتية للخادم الحالية ، والتي سمحت بزيادة موثوقية وأمن تخزين PD ، مما يقلل بشكل كبير من مخاطر الوصول غير المصرح به إليهم ، للحصول على شهادة الوفاء بمتطلبات التخزين - وهو إنجاز لم يتحقق بعد من قبل الجميع مطورو برامج مماثلة.
في الخلاصة ، بدت حزمة عمل المشروع كما يلي:
- يتم تنظيم شبكة فرعية مخصصة ؛
- في المجموع ، تم ترحيل مجموعتين تتكونان من خمسة أجهزة افتراضية: مجموعة قاعدة بيانات تجاوز الفشل (جهازان ظاهريان) ، مجموعة تطبيقات Service Fabric (ثلاثة أجهزة افتراضية)
- تم إعداد إعدادات لحماية البيانات وأنظمة التشفير.
يبدو أن كل شيء واضح ومنطقي. في الممارسة العملية ، تبين أن كل شيء أكثر تعقيدًا. مرة أخرى ، كنا مقتنعين أنه عند العمل مع كل مهمة فردية من مثل هذه الخطة ، يلزم أعلى مستوى من الاهتمام بـ "تفاهات" ، والتي تتحول في الواقع إلى عدم تفاهات ، ولكن العوامل المحددة لنجاح المشروع بأكمله.