هناك حاجة إلى شركة أجنبية كبيرة للسقوط
في سحابة لدينا بسبب قانون البيانات الشخصية. نظرًا لأنهم هم أنفسهم يشاركون في تدقيق الشركات الأخرى ، فقد تعاملوا مع السؤال كالمعتاد: لقد درسوا السوق ، وقاموا بتجميع قائمة بالمتطلبات الخاصة بالسحابة وبدأوا في التحقق من من وكيف تقابلها.
نقل جميع الأنظمة: بيئات الاختبار ، اختبار + prod ، preprod ، جميع الأجهزة الافتراضية ، الخوادم الافتراضية بالإضافة إلى جميع أنظمة البنية التحتية الافتراضية. حتى دعمهم ظهر في روسيا. منا - تأجير الموارد فقط.
قاموا بفحصنا بشكل ملحوظ ، من حيث الحجم: مراجعة كاملة تقريبًا لمركز البيانات. لكنهم لم ينظروا في الأجهزة والمواصفات الفنية بشكل عام ، ولكن حول كيفية بناء عمليات IB وكيف تتم ملاحظة اتفاقيات مستوى الخدمة المختلفة. من وجهة نظرهم ، فإن عمليات استقرار جيش تحرير السودان هي التي تشير إلى جودة الشركة. وقلنا لهم عن كل مكون بالتفصيل.
أريد مشاركة قائمة معايير التحقق. لأنه كان هناك على الأقل نوع من المنهجية ، لأنه قبل ذلك قليل من العملاء كان لديهم مثل هذا النهج المنهجي لهذه المشكلة.
الخيارات العامة
المتطلبات الرئيسية كانت حوالي عشرين. من بينها تلك الأساسية مثل وضع النظام الأساسي على مركزين للبيانات ، وجود وحدة تحكم لإدارة الموارد ، والقدرة على العمل من خلال واجهة برمجة التطبيقات ، ودفع تكاليف الخدمات عند استخدامها مع تفصيل لا يزيد عن ساعة واحدة ، وتوافر أدوات التشغيل الآلي ، على سبيل المثال ، Terraform. المتطلبات الأخرى لا تعني أننا فوجئنا كثيرًا ، فهي ببساطة لا تعرضها جميعًا دون استثناء. من بين هذه المتطلبات الحاجة إلى امتلاك مبنى يعمل فيه مركز بيانات السحابة.
ولكن هنا كل شيء واضح بشكل عام. يبدو أن هذا العميل يقرأ أيضًا تاريخ سوق التجميع الروسي. أو بعض من عملائها قد التقى بالفعل في مكان ما في الخارج. كل شيء آخر هو المعيار بشكل عام. متطلبات مركز البيانات موجود في موسكو (كان هذا أيضًا في القائمة) - هذه هي الفرصة للحضور إلى المسؤول وسرعة المكالمات أثناء النسخ المتماثل. النقطة الأكثر أهمية بعد مركزين للبيانات هي المقاييس التفصيلية في اتفاقية مستوى الخدمة. كما قلت ، هذا يقلقهم أكثر حول كل عنصر.
متطلبات الموظفين
كانت هذه واحدة من أصعب الكتل ، لأن العميل ، الذي يتمتع بخبرة واسعة في أنشطة المشروع (لديهم المئات من عملاء الإنتاج والتجزئة في جميع أنحاء العالم) ، نقله إلى حد ما على تكنولوجيا المعلومات. بشكل عام ، هذا هو النهج السليم ، ولكن تبين أن المتطلبات "ثقيلة".
إليك ما تم اختباره من أجل:
- وجود ثلاثة مستويات من الدعم الفني للمنصة: السطر الأول هو حل الحوادث على مستوى المنصة (HW ، والمحاكاة الافتراضية) ، والخط الثاني هو حل المشاكل في البنية التحتية للعميل الموجودة في النظام الأساسي السحابي (OS ، DBMS وغيرها من برامج التطبيق) ، السطر الثالث هو الاتصال البائع المطورين منصة سحابة و / أو البائعين لحل المشاكل.
- وضع التشغيل 24x7x365 من السطر الأول من الدعم الفني.
- معرفة إلزامية باللغتين الروسية والإنجليزية من قبل متخصصين من جميع مستويات الدعم.
- القدرة على تقديم طلبات للحادث عن طريق البريد الإلكتروني أو عن طريق الاتصال بخدمة الدعم الفني.
- إمكانية تقديم طلبات للحادث عن طريق الاتصال بخدمة الدعم الفني.
- تتراوح مدة رد فعل أخصائي الدعم الفني للحادث من 10 إلى 15 دقيقة حسب أولوية التطبيق (يجب على المورد تسجيل وصف تفصيلي لأولويات الحوادث في عقد الخدمة).
- يتراوح وقت حل الحادث من 90 إلى 240 دقيقة ، حسب أولوية التطبيق (يجب على المورد تسجيل وصف تفصيلي لأولويات الحوادث في عقد الخدمة).
- وجود إلزامي لفريق مشروع مخصص ، والذي يشمل: مدير الحساب ، مدير المشروع ، المهندس المعماري التقني ، المهندسين.
- القدرة على استخدام وسائل الاتصال المختلفة بين فريق المورد وفريق العميل لحل المشكلات بسرعة أكبر (على سبيل المثال ، استخدام Telegram و WhatsApp وغيرهم من الرسل).
- تحديد قائمة فريق المشروع في عقد موقع لتقديم خدمات النظام الأساسي السحابي. يجب أن تتضمن القائمة الاسم الكامل وأرقام الاتصال بالهواتف المحمولة وعناوين البريد الإلكتروني لجميع الأشخاص المشاركين في نشاط العميل والمورد.
هنا ، واحدة من أهم النقاط بالنسبة للعميل هي أنها قدمت ثلاثة خطوط دعم بالضبط. كل شخص لديه دائمًا السطر الأول ، وعادةً ما يكون السطر الثاني من الدعم موجودًا ، لكن متطلباته ضبابية بالفعل. ولكن هناك أيضا الثلث ، الذي شهد في الواقع رقائق مختلفة. ولا يتم الاستعانة بمصادر خارجية ، كما يحدث في بعض الأحيان. يتعامل المشروع فقط مع موظفيه. لا يتم تخصيص فريق خدمة لمشروع عميل كبير ، ولكن فريق مشروع منفصل ، ويتم تسجيل ذلك في المستندات.
فريق المشروع المخصص هو نقطة مهمة منفصلة. لمزود الخدمة السحابية العادي ، عادة ما يأتي كل هذا في شكل من أشكال الخدمة. لكن مرة أخرى ، لا يوجد شرط مباشر مباشر لهذا ، ولا توجد معايير. بشكل عام ، هناك أشخاص يشاركون بشكل مباشر في دعم العميل ، وهناك شخص يدير مشروعًا معينًا ، وهناك مهندسون. إنه مكلف للعميل تخصيص وقت لهؤلاء الأشخاص ، لكنه ضروري ، لأنه في معظم الحالات خارج "الاستضافة فقط" تحتاج إلى حل المشاكل المعقدة للغاية. أو بسيطة ، ولكن بسرعة وأول مرة. لذلك ، سيكون هؤلاء الأشخاص نشيطين على مدار الساعة طوال أيام الأسبوع ، دائمًا على اتصال وعلى استعداد للمساعدة. مع أي نوع من الاتصالات مريحة للعميل. هذه خدمة يتم تقديمها عادةً للعملاء "المحبوبين" ، ولكن معنا - للجميع. وهو موثق.
في التواصل: من المهم جدًا أن يكون لديك هواتف شخصية في جهات الاتصال في حالة الطوارئ المختلفة. في المشاريع الجادة ، يمر التواصل عبر الرسل لتسريع (قبل عامين ، لم يكن الأمر كذلك ، فقد تواصل الجميع عبر البريد). أعطى مدير المبيعات رقمًا شخصيًا لا ينطفئ ليلًا وفي إجازة - هذا هو المعيار. ولكن لا يمكن للجميع قول هذا.
الآن بالتفصيل أكثر قليلاً - حول متطلبات الأنظمة الفرعية الفردية والعمليات.
متطلبات الشهادة
عرض- يجب أن يتوافق نظام المحاسبة للموارد المستهلكة مع المتطلبات المعمول بها في "قواعد استخدام أنظمة الدفع الآلية ، المعتمدة. قرار من وزارة الإعلام والاتصالات في روسيا بتاريخ 02.07.2007 رقم 73. "
- يجب أن يكون لدى مزود شهادة محدثة من الامتثال لأنظمة إدارة أمن المعلومات في الشركة مع متطلبات معيار ISO / IEC 27001: 2013 فيما يتعلق بتوفير خدمات الاستعانة بمصادر خارجية لمراكز البيانات ومراكز البيانات الافتراضية.
- توفر الشهادة الحالية للنظام الأساسي السحابي PCI DSS v3.2.
- يجب أن تتضمن شهادة المطابقة PCI DSS 3.2 دعم تقنية المعلومات والأمن المادي وأمن خدمات النظام والمعدات المادية والشبكات والتخزين.
- شهادات مراكز بيانات التصميم من المستوى الثالث ، ومراكز بيانات مرافق المستوى الثالث ، ومراكز بيانات الاستدامة التشغيلية من المستوى الثالث.
لا مفاجآت هنا: PCI DSS للبيانات المالية و T-III لثلاث شهادات. هذا مهم لعمل العميل. لشركتك تحتاج إلى إنشاء قائمة الشهادات الخاصة بك. لكن النقطة الأولى تستحق اهتماما خاصا. كما اتضح فيما بعد ، كان من المهم بالنسبة للعميل توفير مستند يشير إلى العمل الكفء لنظام الفوترة لدينا. لحسن الحظ بالنسبة لنا ، قبل حوالي عام من ذلك ، اعتمدنا ذلك في وزارة الاتصالات.
فيما يلي قائمة بمتطلبات العناصر الرئيسية للنظام الأساسي السحابي. نظرًا لأننا عملنا سابقًا بإحكام شديد مع العملاء الأجانب ، توجد بالفعل قائمة مماثلة ، ولكن بشكل مخفض إلى حد كبير. إلى حد ما أو آخر ، تمت الإشارة إلى المعلومات في SLA والمستندات الأخرى. بناءً على طلب مستشار أعمال ، قمنا بتجميع كل ما لدينا ، ورتبنا وتحديثنا. ونتيجة لذلك ، تلقينا مستندًا قويًا إلى حد ما في المجلد ، يمكننا تقديمه للتعرف على العملاء الآخرين.
لذلك ، ما هو محدد على وجه التحديد في قوائم المراجعة فيما يتعلق بالمعايير الفنية للمنصة.
موارد الحوسبة
عرض- ينبغي ضمان تخصيص موارد الحوسبة (النوى الافتراضية ، RAM) ، باستثناء إمكانية التأثير المتبادل للخوادم الافتراضية للعميل الموجودة على عقدة مادية واحدة على بعضها البعض.
- يجب أن يوفر النظام الأساسي السحابي القدرة على تغيير مقدار موارد الحوسبة دون إعادة إنشاء VM.
- إمكانية النشر المضمون لـ VMs على العقد المادية المختلفة.
- يجب أن توفر المنصة السحابية اختيارًا للكتلة (DC) عند بدء تشغيل VM.
الأقراص
عرض- يجب أن توفر المنصة السحابية القدرة على إنشاء أقراص افتراضية ذات أداء مختلف (IOPS) من خلال واجهة الإدارة القائمة على الويب وواجهة برمجة التطبيقات.
- يجب أن توفر النظام الأساسي السحابي القدرة على تغيير أداء القرص أثناء التنقل.
- يجب أن تكون موارد القرص متوفرة مع ضمانات الأداء تقاس بعدد IOPS لكل قرص.
- يجب أن تغطي ضمانات أداء القرص ما يصل إلى 100،000 IOPS.
- يجب أن يوفر النظام الأساسي السحابي القدرة على ترحيل البيانات بين موارد القرص ذات الأداء المختلف "أثناء التنقل" دون إيقاف الخدمة.
الشبكات
عرض- يجب أن يتيح لك النظام الأساسي السحابي تنظيم بيئات شبكة معزولة غير متوفرة للعملاء الآخرين في النظام الأساسي السحابي.
- يجب أن تسمح لك بيئات الشبكات المنعزلة في النظام الأساسي السحابي بإدارة عنونة الشبكة وتوجيه البنية التحتية لتكنولوجيا المعلومات الخاصة بالعميل.
- يجب أن يكون النظام الأساسي السحابي وظيفة لربط قنوات الاتصال الخارجية المخصصة للعملاء.
- يجب ضمان تخصيص أو حذف عناوين IP الخارجية للخوادم الافتراضية باستخدام النظام الأساسي السحابي.
- يجب أن توفر المنصة السحابية اتصالًا آمنًا بالفشل الخارجي بسرعة لا تقل عن 40 جيجابت / ثانية.
- يجب أن يكون النظام الأساسي السحابي مضمنًا في خدمات DNS و DHCP.
- يجب أن توفر المنصة السحابية اتصالات VPN IPSec.
- يجب أن توفر المنصة السحابية إمكانية الوصول الآمن إلى الأعطال إلى الإنترنت ، بشكل مستقل عن الموفر ، وأن تجمع أربعة مزودين على الأقل.
- يجب أن يكون عرض النطاق الترددي بين أجهزة VM داخل نفس مركز البيانات 10 جيجابت / ثانية على الأقل.
- اتصال L2 بين البنى التحتية الافتراضية المنتشرة في مختلف مراكز البيانات.
تخزين الأشياء
عرض- يجب أن يكون للنظام الأساسي السحابي خدمة ملفات متوافقة مع واجهة برنامج Amazon S3.
- يجب أن يعمل تخزين الكائنات وفقًا لبروتوكول يوفر القدرة على تخزين واستقبال أي كمية من البيانات في أي وقت من أي مكان على الإنترنت.
- يجب توزيع نظام تخزين البيانات لتحمل الأخطاء بين موقعين على الأقل من المقاول.
- يجب أن يكون نظام التخزين قادرًا على التوسع عند إضافة الملفات.
- يجب أن يدعم تخزين الكائن تعيين الإصدار.
- يجب نسخ كل كائن في المستودع بين مواقع المقاول. في حالة حدوث فشل واحد لأي من مكونات تخزين الكائن ، يجب ألا يكون هناك أي تأثير على جودة الخدمة.
- القدرة على العمل مع التخزين عبر HTTPS.
- دعم قائمة التحكم بالوصول (ACL) والسياسة.
- دعم نُهج دورة حياة كائن دورة حياة.
- تشفير جانب الخادم.
- دعم لمواقع الويب الثابتة وأسماء المستخدمين لمواقع الويب مثل mysite.ru
- مستوى التسامح مع الخطأ لخدمة التخزين هو 99.99٪ على الأقل.
IB
عرض- يجب ضمان فصل بيئة معلومات العميل داخل النظام الأساسي السحابي إلى عدة شبكات افتراضية مستقلة.
- يجب تنفيذ إدارة الوصول إلى الشبكات الافتراضية على مختلف المنافذ والبروتوكولات باستخدام جدار حماية مدمج مجانًا.
- يجب التأكد من دمج خوادم النظام الأساسي الظاهري في شبكة افتراضية خاصة واحدة (VPN) مع خوادم العميل الفعلية أو الافتراضية الموجودة على موقع بعيد أو مركز بيانات.
- يجب توفير الوصول إلى وظائف إدارة برامج النظام الأساسي السحابي (APIs) بحيث لا يتم اختراق الأمان حتى عند استخدام بروتوكولات النقل غير الآمنة.
- يجب استخدام بروتوكول HTTPS للوصول إلى وظائف إدارة برامج النظام الأساسي السحابي (API). يجب أن تكون الشهادات موقعة من قبل هيئات الشهادات الموثوق بها.
- يجب الوصول إلى خوادم Linux / UNIX الافتراضية باستخدام بروتوكول SSH باستخدام مصادقة مفتاح كلمة المرور. يجب أن يوفر النظام الأساسي الظاهري القدرة على إدارة مفاتيح المصادقة (الإنشاء والحذف) ، بالإضافة إلى توفير آلية يمكن الوصول إليها من VM لتسليم المفاتيح العامة إلى VM أثناء التحميل.
- يجب إجراء تنظيم الوصول الآمن إلى خوادم نظام تكنولوجيا المعلومات باستخدام اتصال IPsec VPN.
- يجب أن يحتوي النظام الأساسي الافتراضي على جدار حماية متكامل ، يتم تكوينه بشكل منفصل لكل شبكة افتراضية ، وكذلك للشبكات الافتراضية للبيئات السحابية المعزولة.
- وجود نتائج اختبار الاختراق مع موعد نهائي لا يزيد عن سنة واحدة.
النسخ الاحتياطي
عرض- يجب أن يدير العميل خدمة النسخ الاحتياطي بشكل مستقل من خلال واجهة الإدارة القائمة على الويب.
- من خلال واجهة الويب ، يجب أن تكون الوظيفة متاحة لتعيين جدول النسخ الاحتياطي للخوادم الفردية ، وكذلك لعمل نسخة احتياطية منها واستعادتها يدويًا.
- يجب حساب خدمة النسخ الاحتياطي للبيانات ودفعها عند الاستخدام ، وهي غيغابايت من البيانات المحمية شهريًا.
- يجب أن توفر خدمة النسخ الاحتياطي للبيانات القدرة على عمل نسخة احتياطية من نظام الشركة المشترك وبرامج التطبيقات. يجب أن يكون وكلاء البرامج المثبتة على الخوادم المحمية مجانيين.
- إدارة النسخ الاحتياطي - من خلال واجهة الويب ومن خلال وكيل البرمجيات.
- استخدام التخزين المرن القائم على الملفات S3 لتخزين النسخ.
- استخدام إلغاء البيانات المكررة.
الفواتير
عرض- في النظام الأساسي السحابي ، يجب أن يكون التقسيم المنطقي لـ VMs إلى مجموعات مع خيار إعداد فواتير منفصل متاحًا.
- الدفع فقط لحجم المحتلة فعلا.
ما انتهى
كان الاختبار مرهقًا جدًا بالنسبة لنا ، ولكن بفضل ذلك تعلمنا نحن أنفسنا كثيرًا. على سبيل المثال ، بالتركيز على الزملاء الأجانب ، وضعوا عدة إجراءات ، وقاموا بإحضار جميع الوثائق بترتيب كامل. في الواقع ، لقد عملنا لبعض الوقت ، ثم اقترحنا شراكة استراتيجية. لأن هذه الشركة لديها أيضا العديد من العملاء في روسيا. الآن كل هذا قيد المناقشة ، ولكن ظهرت منهجية التحقق بالفعل. بالطبع ، لا تعطي قوائم المراجعة فكرة كاملة عما وكيف بدا مستشارو الأعمال ، لكنني حاولت تفريغ القائمة الرئيسية ، مما سيسمح لك ببناء منهجية تحقق بنفسك. هنا ، بالطبع ، هناك بعض الماكرة من جانبي ، لأننا نجحنا في هذا الاختبار وفزنا ، أي أن قوائم التحقق قابلة للتطبيق بالكامل تقريبًا على السحابة الخاصة بنا. لأن برنامجنا يتوافق مع مشروعهم الكبير. آمل أن تستخدم الفطرة السليمة وتفهم ما يحتاجه مشروعك من المنصة ، وتغيير المتطلبات وفقًا لذلك.
إذا فجأة هناك أسئلة ليست للتعليقات - بريدي هو NiVasilev@croc.ru