لقد حان الخريف في الفناء ؛ تكنو يوتوبيا مستعرة. التكنولوجيا تسرع إلى الأمام. نحمل في جيبنا حاسوبًا تزيد قدرته الحاسوبية بمئات الملايين من المرات عن قوة أجهزة الكمبيوتر التي تتحكم في الرحلات الجوية إلى القمر. بمساعدة Youtube VR ، يمكننا السباحة في المحيطات باستخدام قناديل البحر والحيتان ، والروبوتات منذ فترة طويلة تستكشف آفاق الكواكب الباردة المهملة.
في الوقت نفسه ، ينقسم المهندسين والمتخصصين في خدمات تكنولوجيا المعلومات والمطورين وزملائهم الذين لا حصر لهم إلى معسكرين: أولئك الذين يقومون بإنشاء حلول جديدة (البرامج والاستراتيجيات وأنظمة المعلومات) وأولئك الذين يفهمونها.
اقتحم النظام الإيكولوجي لتطوير التطبيقات وطريقة استخدام الخدمات المجهرية. حتى وقت قريب ، كانت غير مفهومة ، مغلقة عن أعين المتطفلين ، وهي تقنية جديدة في الأساس. ولكن اليوم ، بعد بضع سنوات فقط ، تستخدم الشركات الكبيرة والمتوسطة الحجم بالفعل هذا النهج بثقة في بيئة التطوير الخاصة بها. ما هو مثل؟ لن نستخدم التعاريف "الكلاسيكية" ، لكننا سنخبرك بكلماتنا.
Microservice العمارة. حاويات
Microservices هي طريقة يتم فيها تقسيم وظائف نظام واحد إلى العديد من الخدمات الصغيرة ، ويقوم كل منها بمهمة واحدة من وظيفة معقدة. واحد يعمل كخادم ويب ، والآخر كقاعدة بيانات ، والثالث مشغول بشيء آخر ، إلخ. بين كل هذه الخدمات المصغرة ، يتم تأسيس تفاعل الشبكة ، ويتم تخصيص الموارد اللازمة. مثال مضحك وليس أقل وضوحا لمثل هذا المفهوم هو نظام طلب وإصدار الغداء في مطاعم الوجبات السريعة.
يقوم العميل (المستخدم) بإنشاء طلب جديد باستخدام الجهاز الطرفي أو الاستقبال (خادم الويب) ، ويقوم بنقل البيانات المتعلقة بعدد الجبن والبطاطا ونوع الصودا في غداءه (يملأ قاعدة البيانات) ، ويقوم بالدفع ، وبعد ذلك يتم نقل البيانات إلى المطبخ ، حيث يتم الموظفين البطاطس البطاطس (خدمة الطهي) ، والجزء الآخر ينشر المواد الغذائية ويسكب الصودا (خدمة جمع). ثم يتم نقل الأمر الذي تم جمعه إلى مكتب الإصدار (خدمة إصدار) ، حيث يُظهر العميل شيكًا برقم الطلب (هناك حتى التحقق!) ، ويقدمون له الغداء. كل وحدة من وحدات العملية في هذه الحالة مشغولة بمهمة واحدة ، وتعمل بسرعة وسلاسة ، وفقًا لخوارزمية محددة. يجب أن تعترف أنه سيكون من الغباء توقع أن يتم تفريغ الصودا في مكتب الاستقبال بشكل أسرع من المطبخ ، أو أن الموظف الذي يقلي الفطائر سيكون قادرًا على قبول الدفع لطلبك. ومع ذلك ، إذا تم تصحيح النظام بشكل صحيح واستمرت العمليات كما هو متوقع ، فسيعمل كل شيء بسرعة وكفاءة.
فيما يتعلق بهندسة الخدمات الصغيرة ، تجدر الإشارة إلى نقطة مهمة - بيئة التنفيذ الخاصة بها. اليوم ، هناك خيار واسع الانتشار وهو الحاويات (مرحبًا ، Docker). تتمثل ميزة الحاويات في فكرة تعبئة جميع البيئة اللازمة فيها ، بدءًا من صورة OS خفيفة الوزن ، والحزم المثبتة ، والأطر والمكتبات المحملة ، وتنتهي بالتطبيق نفسه. كيف هذا مفيد؟ على الأقل حقيقة أن المطور لن يكون قادرًا على استبعاد شرح "كل شيء يعمل على جهاز الكمبيوتر الخاص بي" عندما تأتي إليه برسالة تفيد بأن التطبيق لا يعمل.
تتيح لك العبوات إنشاء تطبيقات وتعبئتها مع البيئة بأكملها في صورة جاهزة لنظام خفيف الوزن ولم تعد تقلق بشأن المشكلات المرتبطة بالعمل في بيئات مختلفة. تحتاج إلى نشر التطبيق إلى خادم آخر؟ أطلقنا صورة عمل معها في الحاوية - ويعمل كل شيء.
في نظام المعلومات الذي تم إنشاؤه باستخدام الحاويات ، لم يعد لديك ما يدعو للقلق بشأن إصدارات البرامج في البيئة التي تعمل فيها التطبيقات ، ومع تنفيذ عمليات التسليم المستمرة ، فأنت بحاجة أيضًا إلى تقديم رمز ، وما إلى ذلك. تعني فكرة الحاوية أن التطوير نفسه يعمل التطبيق في نفس بيئة الحاوية ، وبما أن الخدمة الميكروية مغلقة ، فلا يهم أي نظام تشغيل أو مع الحزم المثبتة التي يعمل بها. يعمل التطبيق لأنه تم إنشاؤه لبيئة حاوية لا تتغير بغض النظر عن النظام المحيط بالحاوية. لم يعد من الضروري تثبيت جميع البرامج اللازمة لفترة طويلة ومملة ، لإقامة اتصالات ، تبعيات وحزم. لا تحتاج إلى ترحيل التطبيقات يدويًا عند الانتقال بين بيئات التطوير والنشر أو عند زيادة قدرات مركز الحوسبة. لقد ظهر مستوى جديد من التجريد ، يأخذ مكانه بين البرنامج النهائي مع مستخدميه والبيئة المضيفة (الافتراضية أو المعدنية المجردة) ، والتي يعمل عليها كل هذا. يكتسب هذا النهج ، نظرًا لراحته ، زخمًا ثابتًا ولن يتباطأ.
تسعى العديد من المؤسسات الكبيرة إلى تبني أفضل التقنيات لتحسين كفاءة الأعمال وتطويرها وقابلية تطويرها وتحولها ، بما في ذلك في سياق أنظمة المعلومات. بعد كل شيء ، فإنه على وجه التحديد للشركات الكبيرة ذات التوجه الرقمي التي تهتم في المقام الأول بالحلول التي تهدف إلى المرونة والقابلية للتوسعة والتنقل ، لأنه ، عند تغيير الصناعة ، يصبح عرضة للصعوبات المرتبطة بالتوسع والتكيف مع السوق المتغير ، إلخ. ليس بالضرورة عن شركات تكنولوجيا المعلومات. في سياق مشكلات CI / CD وأمنها ، تتجه شركات من القطاع العام وكبار اللاعبين في السوق المالية مثل البنوك وحتى المحتكرون في مجال الخدمات اللوجستية إلى مؤسستنا. في جميع الحالات ، هناك شيء واحد يوحدهم - استخدام الحاويات بشكل أو بآخر عند تطوير التطبيقات والخدمات ، إلخ.
غالبا ما تتم مقارنة الشركات الكبيرة بأسماك القرش. في هذه الحالة ، من الصعب التوصل إلى مقارنة أكثر ملاءمة. هل رأيت كيف تفترس أسماك القرش في مدارس الأسماك؟ هل لاحظت كم من الأسماك الصغيرة أكثر قدرة على المناورة ، حتى لو كانت في قطيع كبير؟ الذي يتفاعل أكثر وضوحا ، وأكثر قدرة على المناورة وأسرع - سمكة قرش أو إسقمري صغير؟ وينطبق الشيء نفسه على الشركات في السوق ككل. بالطبع ، نحن لا نأخذ بعين الاعتبار Microsoft أو Apple في تلك الأيام التي تناسبهم في المرآب ، فهذه حالات معزولة. لكن من الناحية الإحصائية ، فإن الصورة تجعل الشركات الكبيرة قادرة على إملاء الاتجاهات وتحديد الاتجاهات ، ومع ذلك ، فمن السهل على الشركات الصغيرة التكيف والتكيف بسرعة. وتحاول الشركات الكبيرة أيضًا زيادة التنقل والمرونة بطرق معقولة.
ولكن ، كما يقولون ، هناك فارق بسيط ... الشركات الكبرى في الواقع ليست متراصة. وهي تتألف من العديد من الإدارات ، مع العديد من الإدارات والفرق والوحدات ومجموعة أكبر من الموظفين. وفي سياق نظم المعلومات والتطوير ، على وجه الخصوص ، قد تتداخل مجالات عمل الفرق. وفقط عند هذا التقاطع ، تنشأ حالات الصراع هذه بين خدمات IS والمطورين. وهذا يعني أنه لا توجد شركات كبيرة أو متوسطة الحجم محصنة ضد هذه الصعوبات.
عاجلاً أم آجلاً ، عند استخدام الحاويات ، سيكون لدى المنظمة سؤال. يمكن أن يحدث هذا في بداية استخدامها ، أو ربما بعد وقوع بعض الحوادث ، ونتيجة لذلك ستتكبد الشركة خسائر.
كيفية جعل العمليات آمنة؟
بشكل أو بآخر ، نسمع هذا السؤال غالبًا ومع العميل الذي نفكر في الحل والبحث عن طرق مناسبة. كقاعدة عامة ، تتألف المؤسسة ، خاصةً المؤسسة الكبيرة التي نفذت CI / CD ، من متخصصين أذكياء وذوي خبرة ، بما في ذلك المتخصصون في أمن المعلومات. هؤلاء الناس يفهمون لماذا يحتاجون إلى استخدام الخدمات المصغرة ، والمشاكل التي سوف تحلها ، والصعوبات الجديدة التي ستظهر. لذلك ، يتخذون إجراءات من أجل التنفيذ الناجح للتكنولوجيا واستخدامها: إعداد البنية التحتية وإجراء عمليات التدقيق ونشر الأنظمة وبناء العمليات وتنسيق اللوائح الداخلية.
ومع ذلك ، ليس من الممكن دائمًا التنبؤ بكل شيء وتتبع كل شيء ومراقبة كل شيء. إليك كيف ، على سبيل المثال ، فهم ما إذا كان إصدار خادم SQL في الحاوية يحتوي على ثغرة أمنية حرجة؟ يدويا؟ دعنا نقول. وإذا كان هناك العشرات من الحاويات؟ والمئات؟
كيف يمكن لأخصائي أمن المعلومات التأكد من أن صورة نظام التشغيل الأساسي في الحاوية مع التطبيق لا تحتوي على استغلال مخفي؟ تحقق يدويا؟ وما بالضبط للتحقق ، أن ننظر فيها؟ على كل عشرات ومئات الحاويات؟ وأين يمكن الحصول على الكثير من الوقت والموارد؟
مع تطوير وتوزيع CI / CD ، أصبحت قضية الأمن في دورة التطوير أكثر حدة. بعد كل شيء ، تحتاج إلى التأكد من مستوى مقبول على الأقل في جودة الصور ، وعليك أن تعرف عن نقاط الضعف في البرامج والحزم ، وحالة حاويات العمل ، سواء كانت هناك إجراءات مشبوهة أو غير مشروعة بشكل واضح تحدث فيها. وإذا كنا نتحدث على وجه التحديد عن دورة التطوير ، فسيكون من المفيد وجود أدوات لضمان الأمن في عملية التطوير نفسها ، وفي خط أنابيبها ، وليس فقط في الحاويات. وتحتاج أيضًا إلى التحكم في الأسرار ومراجعة السجلات والتحكم في تفاعل الشبكة وما إلى ذلك. وهنا نأتي إلى القضية الرئيسية.
لماذا هناك حاجة إلى الأمن ، وما هي ميزاته في CI / CD؟
إنها في الأساس مجموعة من الممارسات لضمان الأمن في دورة التطوير وحولها. وهذا هو ، هو استخدام برامج خاصة ، وتطوير الأساليب واللوائح ، وحتى إعداد فرق (فرق هي مفتاح كل شيء!) لضمان الأمن. ونقطة مهمة: مقدمة مبررة لكل هذا الأمن في التنمية ، وليس قطع من الكتف!
هنا نسكن في مزيد من التفاصيل. النهج المعتاد لأمن تكنولوجيا المعلومات بشكل عام وفي التنمية بشكل خاص ، والذي يتبادر إلى الذهن ، يعتمد على مبادئ "حظر / تقييد / منع". إلى حد بعيد ، فإن نظام المعلومات الأكثر أمانًا هو النظام الذي لا يعمل على الإطلاق. ولكن يجب أن تعمل! ويجب أن يكون الأشخاص الذين يستخدمون هذا النظام قادرين على التعامل معه.
هناك تضارب في المصالح المذكورة أعلاه. يسعى أخصائي أمن المعلومات إلى جعل البيئة آمنة ويريد التحكم الكامل فيها ، ويسعى المطور إلى جعل المنتج ويريد أن يحدث بسرعة وسهولة ، كما يعمل مهندس تقنية المعلومات على جعل البيئة قابلة للتطبيق ومتسامحة مع الأخطاء ويسعى المطور جنبًا إلى جنب مع المطور من أجل الأتمتة.
لا تتعلق الحماية في CI / CD بالبرنامج أو اللوائح ، بل تتعلق بالعمل الجماعي وتضمين مفهوم الأمان في مجموعة التطوير. يهدف هذا النهج إلى المشاركة المتساوية لجميع المشاركين في العملية ، وتوزيع مجالات واضحة من المسؤولية ، والأتمتة ، والرصد ، والإبلاغ الشفاف. والأهم من ذلك ، هو تطبيق الأمن داخل عملية تطوير التطبيق بطريقة تظهر في المراحل المبكرة ولا تتطلب تخصيص موارد إضافية ، حاسوبية وبشرية.
دعنا نلقي نظرة على مثال. لنفترض أن أحد فرق التطوير يقوم بإنشاء تطبيق ، وهذا يحدث على وسيط حاوية تحت إشراف متخصصين في أمن المعلومات ، بينما يحافظ مديرو البنية التحتية على صحة هذه البيئة. في نهاية التطوير ، يظهر تطبيق جاهز يتدفق إلى الإنتاج ويبدأ العمل هناك ، ويستخدمه العملاء - الجميع سعداء. ولكن بعد مرور بعض الوقت ، يتم اكتشاف ثغرة أمنية خطيرة في الحاوية مع التطبيق. يقوم أخصائي أمن المعلومات بتسجيل هذه الثغرة الأمنية ويمررها إلى المطورين للتخلص منها ؛ ويقومون بدورهم بإصلاحها باستخدام تصحيح ، وبعد ذلك يتعين عليك إعادة كتابة التبعيات وتحديث بعض الحزم. ثم يتم طرح الإصدار التالي من التطبيق.
الوقت الذي يقضيه متخصصو IS في توطين المشكلة ، ووقت فريق التطوير لإصلاحها ، ووقت قليل ستجري خدمة IS مراجعة ثانية وإغلاق الحالة. ولكن ماذا لو استطعنا استخدام نوع من الأدوات وتنفيذها في مرحلة التطوير؟ ماذا لو لم يتم تطبيقنا على المنتج ، كونه غير مناسب لمستوى الأمان المحدد؟ وكل اختصاصي مشارك في العملية ، يمكنه معرفة التهديدات الموجودة في مجال مسؤوليته؟ ولكن ماذا لو كانت العملية بأكملها مؤتمتة أيضًا ، بدءًا من الكشف والانتهاء بالحوادث في تعقب الأخطاء؟
هذا هو الهدف من تنظيم التنمية الآمنة والتنفيذ. أنه ليس فقط آمن ، ولكن أيضا مريحة. يجب أن يؤدي إدخال عمليات جديدة أو استخدام أدوات إضافية إلى تبسيط الأنشطة وليس العكس.
هناك أدوات وتقنيات تتيح لك مراقبة حالة عناصر النظام ومراحل عملية التطوير اللازمة ومساعدة جميع الأطراف المعنية على مواكبة الأحداث داخل مجال مسؤوليتهم. لا ينصب التركيز هنا على البرامج المتخصصة ، ولكن على تفاعل الأشخاص مع النظام ومع بعضهم البعض. هل هو أكثر ملاءمة للمطور لإصلاح واختبار التطبيق مباشرة داخل حاوية العمل؟ حسنا ، دعه يصلح. في نفس الوقت ، تريد خدمة IS التأكد من عدم وجود إجراءات غير مشروعة داخل الحاوية؟ لا مشكلة ، وقالت انها سوف تكون في معرفة. تم الانتهاء من المهمة ، ولم يتدخل أي شخص مع أي شخص في هذه العملية. الكفاءة والعقلانية! وهذا ممكن إذا قمت بتطبيق أدوات أمان المعلومات الضرورية في الأماكن المناسبة في بيئة التطوير ومراجعة قواعد التفاعل بين الخدمات والفرق. ثم لن يكون هناك يوتوبيا ، لكن يجب أن توافق على أن التعايش مع كليهما سوف يصبح أسهل قليلاً.
لماذا ربط أيدي المطورين ، وتحميل خدمة IB بها ، إذا كنت تستطيع بناء عمليات بحيث يعمل المطور قدر استطاعته (من دون أنانية ، مرهق في النشوة من كمال كودته) ، وسيطر متخصص IB على هذه العملية (وليس التدخل ، ولكن مشاركة هذه المتعة فقط من الجانب).
سلامة الحاويات. هل يستحق كل هذا العناء؟
يتم الاتصال بنا من قبل العملاء في مراحل مختلفة تمامًا ولدينا خبرة مختلفة في CI / CD. كانت هناك مؤسسات كبيرة واجهت مستترًا غير مكتشف في الحاوية قيد الإنتاج تم من خلاله الوصول إلى البيانات المهمة وسرقة البيانات. نتيجةً لذلك ، أصبح من الواضح أنه في نظام كبير ومرهق ، من الصعب للغاية تتبع التهديدات المحتملة وتحييدها بشكل وقائي.
كانت هناك أيضًا شركات صغيرة استخدمت CI / CD مؤخرًا في التطوير. بعد تحليل العمليات في خطوط الأنابيب ، توصل خبراؤهم إلى أن أدوات أمن المعلومات المتاحة تغطي حجمًا غير كافٍ من العمليات ، وهناك أماكن خطيرة يمكن أن يحدث من خلالها الهجوم عاجلاً أم آجلاً. ربما ليس الآن ، ربما لاحقًا ، أو ربما لم يحدث أبدًا. ولكن إذا حدث هذا ، فسيكون سعر الخطأ مرتفعًا.
يتشارك عملاؤنا في مخاوفهم ، والتي تتلخص في معظم الحالات بمفهوم التغلب على أيدي المطورين والمهندسين وجميع المشاركين في العملية عند محاولة تجاوز الحد الزمني. لكن في بعض الأحيان يكون ذلك أسهل وأسرع ، وفي بعض الحالات يكون الأمر خلاف ذلك بشكل عام. ثم يجب على خدمة IS أن تنظر إلى الانتهاكات من خلال الأصابع. لكننا لمفهوم مختلف. لماذا تنتهك أو تتجاهل اللوائح التي كتبت بمثل هذا الألم؟ لماذا يجب أن تتداخل الخدمات مع بعضها البعض لإنجاز مهامها؟ في العمل مع العميل ، نبدأ في التواصل مع مشاكله. هم دائما هناك.
"لا تبحث عن عميل ، والعثور على مشكلة وتقديم حل - سيظهر العميل نفسه."
بعد الاستماع إلى العميل ، كقاعدة عامة ، نتفهم المشكلات التي يواجهونها. يمكن أن تكون صعوبات في تفاعل الفريق ، وقرارات غير ناجحة في تصميم "خط الأنابيب" ، ونقص كل من الموارد البشرية والحوسبية ، وأكثر من ذلك بكثير. في نهجنا لتنفيذ التحسينات الأمنية في البنية التحتية للعميل ، نحن نسترشد بالرغبة في المساعدة في حل مشكلاته وتحقيق ذلك بطريقة تقلل من احتمال حدوث مشكلات جديدة. وبالتالي ، يتم إنشاء الأساس للمستقبل ، لا يهم من الذي سيخدم النظام الذي تم إنشاؤه ، ينبغي توقع العديد من المشاكل وحلها في البداية. في المراحل المبكرة ، اتضح أن القرارات في معظم الحالات تكون أرخص من ارتفاع أعباء العمل في الإنتاج العميق.
بناءً على كل هذا ، نقترح البدء بالتدقيق ، والذي لا يشمل فقط حالة أنظمة المعلومات وعناصرها ، ولكن أيضًا فهم مكون العملية بين فرق التطوير ، ونهج خدمات أمن المعلومات ، إلخ. لا تنس أن الناس هم أهم عامل من حيث التهديدات ونتائج أداء النظام. تعتبر المراجعة مرحلة ضرورية ، حيث يمكن الكشف عن عيوب النظام أو سوء التقدير المهمة في التفاعلات التي يمكن مع العميل حلها أو معالجتها كشفها. من المهم أن نفهم أن الهدف لا يتمثل في تكديس العديد من حلول البرمجيات والمنتجات وعدم إغلاق نقاط الضعف التي اكتشفتها. على العكس من ذلك ، من المحتمل أن يكون السيناريو الذي لا يكون فيه شراء منتجات البرامج باهظة الثمن ضروريًا على الإطلاق.
غالبًا ، يمكن تحقيق عملية زيادة الأمان في بيئة CI / CD بمساعدة ميزات الأمان الحالية للمؤسسة ، سواء المضمنة في بيئة حاويات (في أوركسترا ، على سبيل المثال) ، والجهة الخارجية. الشيء المهم هو عدم كميتها أو جودتها بقدر التطبيق الصحيح.بناءً على نتائج التدقيق ، يصبح من الممكن وضع خطة عمل وخريطة طريق بأهداف مؤقتة واضحة وهدف نهائي مفهوم. حسنا ، كل شيء آخر هو مسألة فنية. التخطيط السليم في أي عمل هو جزء كبير من الانتهاء بنجاح.من المهم عدم الابتعاد وعدم نسيان سبب كل شيء. لا أحد لديه مهمة إنشاء نظام محمي بجنون لا يبدأ فيه أي حاوية عندما يتم الكشف عن أي تهديدات فيه ، أو يتم نشر أي تطبيق في الإنتاج إذا كان هناك أي انحراف عن النموذج المحمي. يجدر بنا أن نتذكر أن إدخال أو إطلاق أدوات الحماية يجب ألا يخدم فقط في زيادة الأمن ، ولكن أيضًا للراحة.على سبيل المثال ، تضمنت إحدى هذه الحالات إدخال برنامج حماية الحاويات وبيئات التنسيق. يبدو أنهم قاموا بتنفيذها وتهيئتها ومسحها ضوئيًا ورأوا فيها جميع نقاط الضعف - ثم العملية الطويلة للتخلص. ومع ذلك ، مع هذا النهج ، تنشأ مشاكل ، والتي نوقشت في البداية. تحتوي خدمة أمن المعلومات على أداة تسمح لك بحظر العديد من الأنشطة في بيئة تزامن ، والتي ، إذا تم استخدامها بشكل غير صحيح ، ستضر أكثر مما تنفع. يربط المطورون أيديهم ، لأن خدمة أمن المعلومات تقلل من قدراتهم. على سبيل المثال ، لم يعد بالإمكان إصلاح شيء ما داخل الحاوية "ساخن" ، وعندما يتم اكتشاف ثغرة أمنية في الحزمة ، يشارك المطور في البيروقراطية التنظيمية. نتيجة لذلك ، يتم تأخير حل المشكلة التي يمكن حلها خلال اليوم إلى أجل غير مسمى.لتجنب مثل هذه المواقف ، نوصي بترتيب العمليات بحيث لا تكون خدمة أمن المعلومات بعيدة عن عملية التطوير ، كما هو الحال غالبًا ، ولكنها مشارك فيها. من المؤكد أن الأمر يستغرق بعض الوقت ، لكن الأمر يستحق تصحيح العملية ، والحياة تزداد سهولة. على سبيل المثال ، تتيح لك أدوات IS مراقبة التهديدات الموجودة بالفعل في مرحلة التجميع داخل خط أنابيب CI / CD ، ويمكن لخدمة IS تسجيل ذلك. في الوقت نفسه ، يمكن نقل المعلومات حول التهديدات في كل مرحلة من مراحل التجميع تلقائيًا إلى الفريق أو المختص المسؤول عن مرحلة معينة ، وهذا بدوره سيتخذ الإجراءات اللازمة للقضاء على التهديد. كل هذا يحدث ليس تحت إشراف سوط ، ولكن تحت مراقبة خدمة IS.في النهاية ، يمكن تقليل الوقت الذي يقضيه في إصلاح الثغرات الأمنية بشكل كبير ، ومعه تكاليف الأعمال ، على سبيل المثال ، المالية أو السمعة.مع أي بيانات أولية ، فإننا نسعى جاهدين لتشكيل نهج لتنظيم وتحسين مستوى الأمان لتطوير الحاويات ، مع التركيز ليس فقط على تصميم وتنفيذ حلول محددة ، ولكن أيضا مع مراعاة الموارد البشرية. كل مشارك في العملية يؤدي دوره ، وأكثر ملاءمة ، كلما كان التدخل غير الضروري أقل ، كلما كانت النتيجة النهائية أفضل. وإذا وجدت توازنًا بين راحة جميع الأطراف المعنية ، فسينتهي بك الأمر إلى فريق فعال للغاية. في المستقبل ، بالطبع ، هناك العديد من التحسينات أو التطبيق أو الزيادة في التشغيل التلقائي لبعض العمليات ، وتفويض المهام ، وما إلى ذلك. لكن الفكرة الرئيسية تبقى دون تغيير - مراجعة للأمان على هذا النحو. الفصل بين الواجبات والمراقبة بدلاً من الحظر الطائش والمشاركة في مجالات مسؤوليتهاوبالطبع الراحة! الأمن يمكن أن تكون مريحة.