في عملية التقييم ، قال العميل عرضًا أن قسم التطوير ، بالإضافة إلى الأجهزة الافتراضية ، يخطط لاستخدام الحاويات. ولكن مع هذا ، أضاف العميل ، هناك مشكلة واحدة: في GOST لا توجد كلمة واحدة عن Docker نفسه. كيف تكون؟ كيف تقيم سلامة العبوات؟
هذا صحيح ، كما يقول GOST فقط عن الأجهزة الافتراضية - حول كيفية حماية الأجهزة الافتراضية ، وبرنامج Hypervisor ، والخادم. لجأنا إلى البنك المركزي للحصول على تفسير. الجواب حيرنا.
GOST والافتراضية
بادئ ذي بدء ، دعونا نتذكر أن GOST R 57580 هو معيار جديد ، والذي يوضح "متطلبات ضمان أمن المعلومات للمؤسسات المالية" (FO). تشمل هذه المؤسسات المالية المشغلين والمشاركين في أنظمة الدفع والمؤسسات الائتمانية وغير الائتمانية ومراكز التشغيل والمقاصة.
اعتبارًا من 1 يناير 2021 ، يُطلب من FDs تقييم الامتثال لمتطلبات GOST الجديدة كل عامين . نحن ، ITGLOBAL.COM ، شركة تدقيق تقوم بإجراء مثل هذا التقييم.
لدى GOST قسم فرعي مخصص لحماية البيئات الافتراضية - رقم 7.8. لم يتم تحديد مصطلح "الظاهرية" هناك ، ولا يوجد تقسيم إلى افتراضية الأجهزة والحاويات. سيقول أي متخصص في تكنولوجيا المعلومات أنه من وجهة نظر فنية ، هذا غير صحيح: الجهاز الظاهري (VM) والحاوية بيئتان مختلفتان ، مع مبدأ عزل مختلف. من وجهة نظر ضعف المضيف الذي يتم نشر حاويات VM و Docker عليه ، يعد هذا أيضًا فرقًا كبيرًا.
اتضح أن تقييم أمن المعلومات للأجهزة الافتراضية والحاويات يجب أن يكون مختلفًا أيضًا.
أسئلتنا البنك المركزي
أرسلناهم إلى قسم أمن المعلومات في البنك المركزي (الأسئلة معطاة بشكل مختصر).
- كيف تنظر في الحاويات الافتراضية من نوع Docker عند إجراء تقييم الامتثال لـ GOST؟ هل من الصحيح تقييم التكنولوجيا وفقًا للقسم الفرعي 7.8 من GOST؟
- كيف أقوم بتقييم ضوابط الحاوية الافتراضية؟ هل يمكن معادلتها مع مكونات الخادم الافتراضية وتقييمها وفقًا لقسم GOST الفرعي؟
- هل أحتاج إلى إجراء تقييم منفصل لأمن المعلومات داخل حاويات Docker؟ إذا كان الأمر كذلك ، ما هي الضمانات التي يجب مراعاتها في عملية التقييم؟
- إذا كانت الحاوية تعادل البنية التحتية الافتراضية وتم تقييمها وفقًا للقسم الفرعي 7.8 - كيف يتم تنفيذ متطلبات GOST لتنفيذ أدوات أمن المعلومات الخاصة؟
استجابة البنك المركزي
فيما يلي المقتطفات الرئيسية.
يحدد GOST R 57580.1-2017 متطلبات التنفيذ من خلال تطبيق التدابير الفنية فيما يتعلق بالإجراءات التالية لـ ZI من القسم الفرعي 7.8 من GOST R 57580.1-2017 ، والتي ، وفقًا للإدارة ، يمكن توسيعها لتشمل حالات استخدام تقنيات المحاكاة الافتراضية للحاويات ، مع مراعاة ما يلي:
- .1 – .11 , , ( ) . (, .6 .7) , ;
- .13 – .22 , , . ( , );
- .26, .29 – .31 ;
- يجب أن يتم تنفيذ التدابير ZVS.32 - ZVS.43 لتسجيل أحداث أمن المعلومات المتعلقة بالوصول إلى الأجهزة الافتراضية ومكونات الخادم للمحاكاة الافتراضية عن طريق القياس أيضًا فيما يتعلق بعناصر بيئة المحاكاة الافتراضية التي تنفذ تقنية المحاكاة الافتراضية للحاويات ".
ماذا يعني
استنتاجان رئيسيان من إجابة إدارة أمن المعلومات بالبنك المركزي:
- تدابير حماية الحاويات هي نفس تدابير حماية الأجهزة الافتراضية ؛
- ويترتب على ذلك أنه في سياق أمن المعلومات ، فإن البنك المركزي يساوي بين نوعين من المحاكاة الافتراضية - حاويات Docker و VMs.
ورد في الرد أيضاً "تدابير تعويضية" يجب تطبيقها لتحييد التهديدات. ومع ذلك ، ليس من الواضح ما هي هذه "التدابير التعويضية" ، وكيفية قياس كفايتها واكتمالها وفعاليتها.
ما العيب في موقف البنك المركزي
إذا كنت تستخدم توصيات البنك المركزي في التقييم (والتقييم الذاتي) ، فأنت بحاجة إلى حل عدد من الصعوبات الفنية والمنطقية.
- تتطلب كل حاوية قابلة للتنفيذ تثبيت برنامج أمان المعلومات (SSS) عليها: مكافحة الفيروسات ، ومراقبة النزاهة ، والعمل مع السجلات ، وأنظمة DLP (منع تسرب البيانات) ، وما إلى ذلك. يمكن تثبيت كل هذا على جهاز افتراضي دون أي مشاكل ، ولكن في حالة الحاوية ، يعد تثبيت SZI خطوة سخيفة. تحمل الحاوية الحد الأدنى من "مجموعة أدوات الجسم" اللازمة لعمل الخدمة. تركيب نظام أمن معلومات فيه يخالف معناه.
- وفقًا للمبدأ نفسه ، يجب حماية صور الحاويات - كما أن كيفية تنفيذ ذلك غير واضحة.
- , . . . Docker? , ?
- , Docker- — .
من الناحية العملية ، من المحتمل أن يقوم كل مراجع بتقييم سلامة الحاويات بطريقته الخاصة ، بناءً على معرفته وخبرته. حسنًا ، أو لا على الإطلاق ، إذا لم يكن هناك أحد ولا الآخر.
فقط في هذه الحالة ، نضيف أنه اعتبارًا من 1 يناير 2021 ، يجب أن يكون الحد الأدنى للتقدير 0.7 على الأقل.
بالمناسبة ، ننشر بانتظام إجابات وتعليقات المنظمين المتعلقة بمتطلبات GOST 57580 ولوائح البنك المركزي في قناة Telegram الخاصة بنا .
ماذا أفعل
في رأينا ، لدى المؤسسات المالية خياران فقط لحل المشكلة.
1. رفض تنفيذ الحاويات
حل لأولئك الذين هم على استعداد لتحمل استخدام الأجهزة الافتراضية فقط وفي نفس الوقت يخشون من تصنيفات GOST المنخفضة وغرامات البنك المركزي.
بالإضافة إلى ذلك : من الأسهل تلبية متطلبات القسم الفرعي 7.8 من GOST.
السلبيات: سيتعين عليك التخلي عن أدوات التطوير الجديدة القائمة على افتراضية الحاوية ، على وجه الخصوص ، Docker و Kubernetes.
2. رفض تلبية متطلبات القسم الفرعي 7.8 من GOST
ولكن في نفس الوقت - لتطبيق أفضل الممارسات في ضمان أمن المعلومات عند العمل مع الحاويات. هذا حل لأولئك الذين يهتمون أكثر بالتقنيات الجديدة والفرص التي توفرها. نقصد بـ "أفضل الممارسات" هنا القواعد والمعايير المعتمدة في الصناعة لضمان سلامة حاويات Docker:
- أمن نظام التشغيل المضيف ، وتسجيل التكوين بشكل صحيح ، وحظر تبادل البيانات بين الحاويات ، وما إلى ذلك ؛
- استخدام ميزة Docker Trust للتحقق من سلامة الصور واستخدام ماسح الثغرات الأمنية المدمج ؛
- يجب ألا ننسى أمان الوصول عن بُعد ونموذج الشبكة بشكل عام: لم يقم أحد بإلغاء هجمات مثل ARP-spoofing و MAC-Fling.
بالإضافة إلى ذلك: لا توجد قيود فنية على استخدام المحاكاة الافتراضية للحاويات.
ناقص: هناك احتمال كبير أن يعاقب المنظم على عدم الامتثال لمتطلبات GOST.
خاتمة
قرر عميلنا عدم التخلي عن الحاويات. في الوقت نفسه ، كان عليه أن يراجع بشكل كبير نطاق العمل وتوقيت الانتقال إلى Docker (امتدت لمدة ستة أشهر). يدرك العميل جيدًا المخاطر. كما أنه يدرك أنه خلال تقييم المطابقة التالي مع GOST R 57580 ، سيعتمد الكثير على المدقق.
ماذا كنت تفعل في هذه الحالة؟