البحث في الموقع

يعرف كل مطور أهمية اتباع أفضل ممارسات الأمان. لكننا في كثير من الأحيان نتصرف باقتصاد ولامبالاة، ربما لأنه يتعين علينا العمل بجد حتى تترسخ تلك الممارسات الأمنية. لسوء الحظ، يكون هذا مثل رؤية سلوك أمني سيء جدًا لدرجة لا يُمحى فيها من أدمغتنا. لقد رأيت الكثير من حالات ممارسات الأمان السيئة أثناء مسيرتي مديرًا للأنظمة، لكن الأمور الثلاثة التي سأصفها هنا أساسية ويجب على كل مطور برمجيات تجنبها. من المهم الإشارة إلى أنني رأيت الشركات الكبيرة والمطورين ذوي الخبرة يرتكبون هذه الأخطاء، لذلك لا يمكنك أن تربط هذه الأخطاء بالمهندسين المبتدئين. 1. لا تشفر كلمات المرور، بل جزّئها في وقت سابق من حياتي المهنية، عملت لدى شركة تستخدم نظامًا إداريًا يحتوي على بعض المعلومات المهمة. في أحد الأيام، طُلب مني إجراء مراجعة أمنية للشبكة والبرنامج الذي يُخزّن معلوماتنا المهمة. أمضيت بضع دقائق في التجول قبل أن أقرر استخدام برنامج وايرشارك لتحليل حركة المرور في الشبكة. استخدمت جهازي المحلي، وسجلت الدخول إلى نظام المعلومات، فلاحظت شيئًا غريبًا. على الرغم من أن هذا كان قبل انتشار بروتوكول SSL، إلا أنني لم أتوقع أن أرى البيانات بنص عادي يحتوي على بايتات مثل "اسم المستخدم" و "كلمة المرور". عند الفحص الدقيق، بدا أن النظام كان يرسل اسم المستخدم الخاص بي وسلسلة عشوائية، لم تكن كلمة المرور الخاصة بي، عبر الشبكة. لم أستطع ترك الأمر كذلك. لقد حاولت تسجيل الدخول مرة أخرى، إلا أنه في هذه المرة أدخلت كلمة المرور الخاصة بي خاطئة عن قصد. لم أغيرها كاملة، بل حرفا واحدًا فقط. ما كنت أتوقعه هو سلسلة عشوائية مختلفة تمامًا تمثل كلمة المرور. بدلاً من ذلك، تغيّر البايتان الأولان فقط. كان هذا مثيرًا للاهتمام. على الرغم من أنني كنت قليل الخبرة نسبيًا، فقد علمت أنه إذا تجزّأ تمثيل كلمة المرور الخاصة بي كما كان مفترضًا، فسيكون الأمر مختلفًا تمامًا، ولن يكون الاختلاف في حرفين فقط. تبًّا، فحتى مخطط تشفير جيد سيفعل ذلك. لكن هذا، مع ذلك، لم يفعل ذلك على الإطلاق. لقد جربت مرتين أخريين كلمات مرور خاطئة. أمضيت الساعتين التاليتين مسلّحا ببعض الأوراق وقلم رصاص في اكتشاف مخطط فك التشفير. في نهاية الساعتين، كان لديّ نص بايثون يمكن أن يأخذ أي كلمة مرور "مشفرة" ويفك تشفيرها للكشف عن كلمة المرور الأصلية، وهو أمر لا ينبغي لأحد أن يفعله. أنا متأكد من أن الشخص الذي تخيل مخطط التشفير هذا لم يفكر أبدًا في أن شخصًا ما سوف يجلس ساعتين ويستطيع حلّه، لكنني فعلت ذلك. لماذا؟ لأنني أستطيع ذلك. إذا كان عليك تخزين كلمات المرور للمقارنة، فلا تشفرها مطلقًا إذ يُحتمل دائمًا أن يجد شخص ما خوارزمية أو مفتاح فك التشفير. ليس للتجزئة (hash) انعكاس مباشر، مما يعني أنه لا يمكن لأحد عكسها ما لم يكن لديه بالفعل جدول مع التعيين من النص العادي إلى التجزئة (أو أن يخمنه ببساطة). لا تؤثر معرفة آلية التجزئة على سلامة البيانات، بينما يضر بها انكشاف مخطط ومفاتيح التشفير. 2. لا تضع أبوابا خلفية سرية في البرنامج كجزء من متابعة برنامج تابع لجهة خارجية، كنت أدعم بعض المستخدمين الذين أخبروني أن تسجيلات الدخول الخاصة بهم لا تعمل. كانت هذه خدمة مدفوعة الأجر مقدمة من بائع، لكن قبل أن أتعامل مع أحد كانت أكثر مكالمات الدعم إزعاجًا تحت عنوان "لا يعمل تسجيل الدخول الخاص بي"، اعتقدت أنني سأحاول ذلك بنفسي. لقد كان الأمر صحيحًا، لم تعمل تسجيلات الدخول. كان النظام عبارة عن منصة لإدارة التعلم عبر الإنترنت، والتي دفعنا مقابلها جزءًا صغيرًا من قدراتها الكبيرة. عندما بحثت بفضول في صفحة تسجيل الدخول، لفت انتباهي شيء ما. بدا لي حرف واحد في إحدى الكلمات مختلفًا. ربما كان خطًا مختلفًا للكتابة، أي شكلًا مختلفًا قليلاً لحرف "o". ولأنني أنا دون غيري، فتحت الصفحة بطريقة عرض المصدر، ولاحظت وجود رابط مرتبط بهذا الحرف المحدّد. لقد أُخفي الرابط عن قصد بحيث لا يتغير مؤشر الفأرة عند التمرير فوقه. لهذا حمّلت هذا الرابط الغامض بحذر شديد في نافذة متصفح جديدة. وفجأة ، قابلتني شاشة تعرض بالتفصيل مجموعة كاملة من أجهزة الحواسيب، وتمنحني سيطرة كاملة على ما يمكنها القيام به والقدرة على إيقاف تشغيلها، وإعادة تشغيلها، وأخذ لقطات للشاشة، سمِّها ما شئت. اتصلت ببائع البرنامج وطلبت التحدث إلى تقني المعلومات. بعد المرور على بعض الأشخاص، وصلت أخيرًا إلى شخصٍ يعرف مسبقًا ما الذي كنت أتحدث عنه. قال لي: "أوه نعم! لقد وضعنا ذلك في مكان يسهل الوصول إليه، ولم يعثر عليه أحد حتى الآن قبلك. سنقوم بإزالته على الفور". قبل أن ننهي المكالمة، سألني سؤالًا أخيرًا:" لماذا بدأت تبحث في HTML؟". كانت إجابتي بسيطة: "لأنني أستطيع". إن الأمر لا يستحق المخاطرة بوضع منفذٍ خلفيٍّ جميلٍ في أي نظام، لأنك قد تراهن بآخر دولار لديك وسيجده شخص ما. بغض النظر عن مدى الغموض، غالبًا ما يؤدي تحليل الشفرة، وحتى البحث الفضولي السطحي، إلى أكثر النتائج غرابةً وإثارة للاهتمام. 3. فعِّل تصديق هوية المستخدمين في كل صفحة، وليس فقط على صفحة تسجيل الدخول في مرحلة ما من حياتي المهنية، شاركت في مشروع لتطوير البرمجيات نفّذه مطوّر متمرس. بعد أن شعرت قليلاً بقلّة الحيلة أمام هذا التطبيق المميز، أخبرت مديري أننا سنحتاج إلى مراجعة أمنية معمقة للشيفرة. وطُلب مني النظر على أي حال لمعرفة ما يمكن أن أجده. بدأت اللعب مع التطبيق، وسجلت الدخول، وعرضت بعض البيانات. ثم وجدت شيئًا مثيرًا للاهتمام حقًا. إذا وضعت إشارة مرجعية على أحد عناوين URL التي ألج إليها كثيرا في النظام، فيمكنني فقط نسخها ولصقها في متصفح آخر، وقضي الأمر! سأكون هناك دون الحاجة إلى تسجيل الدخول. سألت المطور: "لماذا لا تُسجّل الدخول في كل صفحة؟ إذا أدخلت عنوان URL لصفحة ما في النظام، فيمكنني الوصول إليها دون تسجيل الدخول". فسألني: "لماذا تفعل ذلك؟". أجبته: "لأنني أستطيع". لا تترك أي شيء للصدفة حتى المطورون المتمرسون قد يرتكبون هذه الأخطاء. يعتقدون أن لا أحد سيحاول مطلقًا الخوض في نظام لا يستطيع الوصول إليه فعليًا. المشكلة هي أن الناس سوف يبحثون بفضول، وسوف يحفرون. نصيحتي الجوهرية التي أود أن أنقلها هنا لأي شخص مهمته مراعاة الأمان فقط هي: لا تترك أي شيء للصدفة. هناك أشخاص مثلي، يحبون الحفر في الأشياء ومعرفة علّة وكيفية عملها. ولكن هناك أيضًا عدد كبير من الأشخاص الذين سيحفرون لاستغلال عيوبك ونقاط ضعفك. لماذا؟ لأنهم يستطيعون! ترجمة وبتصرف للمقال ‎3 security tips for software developers لبيت سافايج

لقد كان هناك دائمًا جدل مستمر حول ما إذا كنا بحاجة إلى توسيع مفهوم DevOps من أجل جلب الأمان بوضوح. بعد كل شيء، من الواضح أن DevOps كانت دائمًا اختزالًا لمجموعة واسعة من الممارسات الجديدة باستخدام أدوات جديدة (غالبًا ما تكون مفتوحة المصدر) ومبنية على ثقافات أكثر تعاونًا. ولم لا نتجه نحو DevBizOps لتحسين التوافق مع احتياجات السوق؟ أو DevChatOps للتشديد على نظام اتصال أفضل وأسرع؟ ومع ذلك، كما كتب جون ويليس في وقت سابق من هذا العام عند وقوفه على المصطلحات الخاصة بـالDevSecOps: "نأمل أنه في يوم من الأيام سنكون في عالم ليس علينا أن نستخدم فيه كلمة DevSecOps، وسيكون الأمن جزءًا لا يتجزأ من جميع مناقشات تقديم الخدمة. حتى ذلك اليوم، وفي هذه المرحلة، استنتاجي العام هو أنها مجرد ثلاث حروف جديدة (Sec). والأهم من ذلك أن الاسم يميز حقًا مشكلتنا في عالم لا نقوم فيه بعمل رائع في مجال أمن المعلومات." فلماذا لا نقوم بعمل رائع في مجال أمن المعلومات؟ وماذا يعني القيام بعمل رائع في سياق DevSecOps؟ لم نتمكن من القيام بعمل كبير في مجال أمن المعلومات على الرغم من (أو ربما بسبب) الإنتاج الواسع للبرامج المعقدة التي تعالج المشاكل الضيقة. لكننا أيضًا قمنا بعمل جيد بما فيه الكفاية خلال تلك الفترة عندما كان الدفاع ضد التهديدات يركز على تأمين محيط العمل فقط، وكانت اتصالات الشبكة محدودة، وكان معظم المستخدمين موظفين يستخدمون أجهزة توفرها الشركة. لا تصف هذه الظروف بدقةٍ حقيقة معظم المنظمات منذ عدة سنوات حتى الآن. لكن الحقبة الحالية، التي لم تجلب مفهوم DevSecOps فحسب، بل حتى الأنماط الهيكلية للتطبيقات الجديدة، وممارسات التطوير، وعدد متزايد من التهديدات، تحدد وضعًا طبيعيًا جديدًا وقاسيًا يتطلب وتيرة تغيير أسرع. ليس تغيير منظومة الأمان مرتبطا بالDevSecOps منعزلة، ولكن الأمر يتطلب أمنًا معلوماتيًا بمقاربات جديدة. أمعن النظر في هذه المجالات الخمسة. 1. الأتمتة (Automation) إن السمة المميزة لـ DevOps بشكل عام هي الأتمتة بأكبر قدر ممكن. ويتعلق الأمر جزئياً بالسرعة. إذا كنت ستتحرك بسرعة (دون الإضرار بالأشياء)، فستحتاج حتمًا إلى عمليات قابلة للتكرار تُنفذ دون تدخل بشري كبير. في الواقع، تعد الأتمتة مدخلًا مهمًا لـDevOps، حتى في المؤسسات التي لا تزال تعمل في الغالب على التطبيقات القديمة المتجانسة. وتمثل أتمتة العمليات الروتينية المرتبطة بالتكوينات أو الاختبارات باستخدام أدوات سهلة الاستخدام مثل Ansible دفعةً سريعةً لبدء الطريق إلى DevOps. ليست DevSecOps مختلفة عن هذا المفهوم، فالأمن اليوم هو عملية مستمرة وليس نقطة تفتيش منفصلة في دورة حياة التطبيق، أو حتى فحصًا أسبوعيًا أو شهريًا. عندما يُعثر على الثغرات ويُصدر البائع إصلاحاته، يكون من المهم أن تُطبّق بسرعة لكي تنتهي عمليات استغلال هذه الثغرات الأمنية قريبًا. 2. التحرّك نحو اليسار (Shift left) غالبًا ما يُنظر إلى الأمن التقليدي كحارس بوابة في نهاية عملية التطوير. افحص جميع الصناديق وسيمرّ تطبيقك إلى مرحلة الإنتاج وإلّا حاول مرة أخرى. تُعرف فرق الأمن بأنها لا تكثر الكلام. وبالتالي، لم لا نحرك الأمن مبكرًا نحو اليسار (في الرسم النموذجي من اليسار إلى اليمين لمسلسل التطوير)؟ قد يصرّ الأمنيون على الرفض، ولكن عواقب إعادة الصياغة في مرحلة مبكرة من التطوير هي بالتأكيد أقل بكثير مما يكون عليه الحال عندما يكون التطبيق كاملًا وجاهزًا للتسليم. لا أحب مصطلح "التحرّك نحو اليسار" فذلك يعني أن الأمان لا يزال مجرّد حدثٍ لمرة واحدة نُقل لمرحلة مبكّرة. يجب أن يكون الأمان عملية مؤتمتة إلى حد كبير في كل مكان في دورة حياة التطبيق، من سلسلة التوريد إلى عملية التطوير والاختبار على طول الطريق حتى النشر. 3. إدارة التبعيات (Manage dependencies) أحد التغييرات الكبيرة التي نراها في تطوير التطبيقات الحديثة هو أنك غالبًا لا تكتب معظم الكود. ويعدّ استخدام المكتبات والأطر مفتوحة المصدر مثالًا واضحًا على ذلك. لكن يمكنك أيضًا استخدام الخدمات الخارجية من موفري الخدمات السحابية العامة أو مصادر أخرى. في كثير من الحالات، ستغطي هذه الأكواد والخدمات الخارجية على ما تكتبه بنفسك. نتيجة لذلك، تحتاج منظومة DevSecOps إلى تركيز جادٍّ على سلسلة التوريد الخاصة بالبرنامج. هل تحصل على برنامجك من مصادر موثوقة؟ هل هو مُحدّث؟ هل هو مدمج في عمليات الأمان التي تستخدمها لكودك الخاص؟ ما هي السياسات التي تطبقها في أيّ أكوادٍ وأيّ واجهات لبرمجة التطبيقات قد تستخدمها؟ هل يتوفر الدعم التجاري للمكونات التي تستخدمها لشيفرة المنتج الخاص بك؟ لن تكون هناك مجموعة من الإجابات تناسب جميع الحالات. قد تكون مختلفة في حالة "إثبات الجدوى" عنها في حالة الإنتاج على نطاق واسع. ولكن، كما كان الحال في التصنيع لفترة طويلة (هناك العديد من أوجه الشبه بين DevSecOps وكيفية تطور التصنيع)، تبقى سلامة سلسلة التوريد أمرًا بالغ الأهمية. 4. الرؤية (Vision) لقد تحدثت كثيرًا عن الحاجة إلى الأتمتة خلال جميع مراحل دورة حياة التطبيق. هذا يجعلنا نفترض أنه يمكننا رؤية ما يجري في كل مرحلة من تلك المراحل. تتطلب منظومة DevSecOps الفعالة بالضرورة أدوات فعالة حتى يتضح ما يجب على الأتمتة أن تقوم به. وتندرج هذه الأدوات في عدد من الفئات. هناك مقاييس طويلة الأمد وعالية المستوى تساعدنا في معرفة ما إذا كانت عملية DevSecOps الشاملة تعمل بشكل جيد. وهناك أدوات إنذار حساسة تتطلب تدخلًا بشريًا فوريًا (إذا كان نظام المسح الأمني معطّلًا!). وهناك إنذارات، مثل الفحص الفاشل، تتطلب علاجًا أو إصلاحًا. وهناك سجلات للعديد من البارامترات التي نلتقطها من أجل التحليل لاحقًا (ما الذي يتغير بمرور الوقت؟ وما الذي يتسبب في هذا الفشل؟). 5. الخدمات مقابل الوحدات المتراصة رغم أنه يمكن تطبيق ممارسات DevSecOps على العديد من هياكل تصميمات التطبيقات، إلا أنها تكون أكثر فاعلية من خلال المكونات الصغيرة والموضوعة بشكل فضفاض يتيح تحديثها وإعادة استخدامها دون فرض تغييرات في أماكن أخرى من التطبيق. يمكن أن تكون هذه المكونات في أنقى صورها خدمات مصغرة أو وظائف، لكن المبادئ العامة تنطبق حيثما كان لديك خدمات مقترنة بشكل فضفاض تتواصل عبر الشبكة. يقدم هذا النمط بعض التحديات الأمنية الجديدة. يمكن أن تكون التفاعلات بين المكونات معقدة ويمكن أن تكون المساحة المعرّضة للهجوم أكبر لأن هناك الآن المزيد من نقاط الدخول إلى التطبيق عبر الشبكة. من ناحية أخرى، يدلّ هذا النمط من الهياكل على أن الأمن والمراقبة الآليين يتمتعان أيضًا برؤية أكثر دقة لمكونات التطبيق لأنها لم تعد مدفونة بعمق داخل تطبيق متراصٍّ. لا تنغمس كثيرًا في مصطلح DevSecOps، ولكن عليك أن تتذكر أن الأمن يتطور لأن الطريقة التي نكتب بها وننشر التطبيقات تتطور. ترجمة وبتصرف للمقال ‎5 ways DevSecOps changes security لغوردون هاف

أنت تعمل على الانتقال إلى منظومة DevOps وتطبيقها في مؤسستك بالكامل أو في جزءٍ منها فقط: حسنًا! ها قد حقّق شخص ما في مكان ما قفزة نوعية. لنفترض، لأغراض هذا المقال، أن لديك موافقة من الإدارة: مهما كانت العقبات التي ينبغي عليك تجاوزها وكيفما كانت الجبال التي تحتاج لتسلقها للحصول على ذلك الجواب بـ "نعم". لقد حصلت على موافقة على الأدوات ووضعت كل الإجراءات والعمليات على الطاولة، والآن كل ما عليك القيام به هو إقناع الناس بالاندماج في المنظومة. يجب أن يكون هذا الأمر سهلا، أليس كذلك؟ نتمنى لو يكون كذلك. يتضح أنه ليس كل الناس مستنيرين مثلك أنت قارئ هذا المقال. لا يحب الناس كلّهم التغيير، وإذا كان هناك شيء واحد يمكنك التأكد منه، فهو هذا الأمرُ. ستحقق منظومة DevOps التغيير لمؤسستك: كيف عليك أن تعمل؟ وماذا تفعل؟ وكيف تتفاعل مع الأشخاص الآخرين داخل الفريق وخارجه؟ سوف أَصِفُ هنا خمسة أنواع من الأشخاص أو الأدوار الذين قد يعارضون عملية الانتقال إلى DevOps، كما سأعرض بعض الأفكار حول التكتيكات الممكنة للمساعدة في تحفيزهم للاندماج فيها. ومع ذلك، يجب أن نتذكر أنك قد لا تتمكن من تعبئة الجميع، وقد تكون هناك أسباب وجيهة لعدم رغبة الناس في تغيير ما يقومون به، بما في ذلك حقيقة أن ما يقومون به في الوقت الحالي قد يعمل بشكل جيد، سواء بالنسبة لهم أو للمنظمة. هذا لم يُخترَع من أجلنا: الخوف من المجهول "لقد فعلنا هذا على مدار الأعوام الماضية (سنة أو سنتان أو خمس أو عشر أو خمس وعشرون سنة)، وكان هذا الأمر ينجح دائمًا حتى اليوم". لقد سمعنا جميعًا عبارات كهذه. وقد يكون هذا صحيحًا أو قد لا يكون كذلك، ولكن إذا قررت إدارتك أنه يجب إجراء الانتقال إلى DevOps حتى لو كانت الممارسات الحالية تعمل، فمن الأرجح أن يكون هناك إدراك أن الأمور يمكن أن تكون أكثر كفاءةً أو سرعةً أو أمانًا. إن إحدى النقاط المُحدِّدَة لهذا النوع من الأشخاص أو الأدوار هي أنه يتصرف في كثير من الأحيان كفريق. وغالبًا ما تعتاد الفرق على طريقة معينة للقيام بالأشياء وعلى استقرار في الأدوار والروتينات التي تناسبها. وبالتالي فما تقترحه أنت هنا يمثل إزعاجًا للفريق ويجعل الناس يفعلون أشياء مختلفة. يجب أن تفكر في كيفية تحقيق أقصى استفادة من الفريق كما هو موجود الآن، أو ربما بنقل أعضاء ذلك الفريق معًا أو بإبداء نوع من الاحتفال بنجاحهم، بدلاً من اقتراح التغيير و تعليله بأنهم فشلوا بطريقة أو بأخرى. مجالي: الخوف من فقدان السيطرة هذا نوع من الأشخاص أعرفه تمامًا على المستوى الشخصي بحكم خلفيتي الأمنية. غالبًا ما يشعر الأشخاص الذين حصلوا على مستوى عالٍ من الخبرة في ميدان أو مجال معين بالتهديد عندما يُطلب منهم تغيير طريقة عملِهم أو تطبيقِ معارفهم. سيشعرون غالبًا بأنهم مطالبون بالتخلي عن السيطرة و بـ "تخفيف" خبراتهم في عالم جديد فيه "كلّ شخص هو الخبير". ما يهمّ التأكيد عليه في هذا السياق هو أنه بدلاً من تخفيف خبراتهم، تعدّ هذه فرصة لتطبيقها على مجموعة واسعة من العمليات. ينبغي على خبراء الاختبار أن يشرحوا للمطورين وأفراد العمليات، على سبيل المثال، كيف يمكن عرض منهجيات الاختبار في مجالاتهم. عادةً ما ينظر الخبراء بإيجابيةٍ إلى مسألة عرضهم أمام جمهور أوسع، وعلى الرغم من أنه سيكون هناك دائمًا شخصيات من نوع "البرج العاجي" تكافح من أجل التفاعل في إطار أكثر جماعية، فإن استخدام هؤلاء بطرق يأخذون فيها دور "الاستشاري" قد يوفر فرصًا إيجابيةً. متشبث بأسلوبي: الخوف من الجديد رغم أنه يشبه إلى حد بعيد شخصية "لم يخترع من أجلنا"، إلا أنه يعد فردًا أكثر من كونه سمة جماعية. قد تبدو معرفة ما ستكون عليه مهامك على أساس يومي تافهة للبعض ولكنها قد تكون مريحةً للغاية بالنسبة للكثيرين، وهذا هو السبب في أنهم قد لا يرغبون في الانتقال إلى عالم يبدو "أكثر حرية" وغير منظّمٍ. لا يمكن أن يكون الجميع مثل ذلك النوع من الموسوعيين الذين ينجحون في فهم جميع الأجزاء المختلفة من دورة DevOps. الخبر السار هنا هو أنك ستظل بحاجة إلى أشخاص مستعدين للاستقرار في مهام محددة وإكمالها بطرق معينة. في الواقع، على الرغم من وجود مخاوف مبدئية حول الانتقال إلى بيئة مختلفة للعمل، فإن توضيحك لأعضاء الفريق أنه سيكون لديهم قدر لا بأس به من التحكم في كيفية أدائهم لمهام معينة قد يكون رسالةً إيجابيةً عند محاولة مساعدة هذا النوع من الأفراد. ونأمل أن يساهم تضمينك للتدريب، رسميًا كان أو غير رسمي، كجزء من تحولك إلى DevOps وكذا الفرص المتاحة لتعلم مهارات جديدة (وبالتالي زيادة حركية الأفراد وفرص العمل) أيضًا كحوافز للتغيير. مدراء الأفراد: الخوف من فقدان السلطة يتمتع المديرون في العديد من المؤسسات، وخاصة تلك التي تتمتع بتسلسل هرمي قويٍّ ومتطوّرٍ، بقدر كبير من التحكم في كيفية انتشار موظفيهم وطبيعة مهامهم وكيفية إدارة تقدمهم الوظيفي. كل هذه الأمور يمكن أن تكون مباشِرة خلافًا لمقاربة DevOps التي تعدّ أكثر انفتاحًا. بالنسبة للمديرين الذين بنوا إمبراطوريتهم الصغيرة بالتحكم في تقاريرهم الرئيسية و الفرعية مثل البيادق حول لوحة الشطرنج، سيكون الانتقال إلى DevOps تحدّيًا كبيرًا. أما بالنسبة للمديرين الذين يحرصون على تطوير أعضاء فرقهم ليصبحوا موظفين أكثر خبرة، والذين يقيسون نجاحهم بعدد الفرق الأخرى التي تطلب إعارة تقاريرها إلى فرقهم، والذين يستمتعون كذلك برؤية مهارات جديدة وبالتقدم الوظيفي، ستكون DevOps بالتأكيد فرصةً مثيرةً. من الراجح أن يكون أسلوب العصا و الجزرة جزءًا من أي حلٍّ لمشكلة المديرين الذين يقاومون الإدارة التنفيذية. يمكن أن تتضمن الجزرة تغيير كيفية مكافأة المديرين وفقًا لآلية تتبنى هذه السلوكيات الجديدة، في حين قد تتضمن العصا تجريد فرقهم من بعض أعضائها أو إعادة تحديد دور هؤلاء المديرين. النقابات: الخوف من عدم اليقين في بعض المصانع والمناطق، هناك نقابات قوية. تتمثل المهمة الأساسية للنقابات في حماية العمال من الاستغلال من قبل الإدارة التي قد تحاول فرض تغييرات على العمال لن تعود عليهم بفائدة. تشتبه النقابات بشكل افتراضي ومفهومٍ كذلك في أي تغييرات تدخلها الإدارة، لذا فإن أي انتقال إلى DevOps تباركه الإدارة قد يثير مخاوف ومقاومة النقابات وأعضائها. في بعض الحالات، قد يكون الموظفون قد وصفوا بعناية أدوارهم الوظيفية التي تجعل من الصعب تقديم طرقٍ للعمل يتوقع منهم فيها القيام بدور أكثر موسوعيةً وتعلم مهارات جديدة، وهذان كلاهما من خصائص DevOps. والخبر السار هنا هو أن DevOps يمكن أن توفر المزيد من التحكم لأعضاء الفريق، بطرق مختلفة كثيرة، مما يقلل إلى حد ما من السيطرة التي تمارسها وظيفة الإدارة. سيكون توضيح ذلك والتأكد من إجراء عمليات الفحص المناسبة لحماية الوظائف أحد المفاتيح الرئيسية لإقناع النقابات وأعضائها بأن هذا تغيير جيد بالنسبة لهم. والشيء الآخر الذي كان يجب أن يحدث، بالطبع، هو أنه كان ينبغي على الإدارة إدماجهم مبكرًا في العملية للتأكد من انخراطهم من البداية، بدلاً من اتخاذ قرارٍ "نبت" فجأة في اللحظة الأخيرة. أفكار ختامية مع تقدمنا نحو مستقبل جديد مشرق، تجدر الإشارة إلى أن الخير العام للجميع لا يترجم دائمًا إلى تغيير إيجابي لكل فرد. يصعب القول أن بناء شبكات الصرف الصحي ليس خيرًا عامًّا، لكنه يؤذي من كانت وظيفتهم الحرص على نظافة الشوارع. نأمل ألا ترى انتقالك إلى DevOps كإنشاء مجموعة جديدة من شبكات الصرف الصحي لمؤسستك، ولكن انتبه إلى أولئك الذين قد يكون التغيير بالنسبة لهم صعبًا ومضطربًا. يمكن أن يكون هناك تكلفة بشرية لأي تطوير مهما حسنت نيته. بالنسبة لي، أهم نقطة ينبغي تذكرها هي أنه عندما يصبح الأشخاص دفاعيين، بل وأحيانًا عدوانيين، يكون ذلك عمومًا لأنهم يشعرون بالتهديد، وفي كل هذه الحالات التي فحصناها، قد يكون التغيير مهدِّدًا بالفعل. إن هؤلاء الناس هم زملاؤك. وهُم أناس أيضًا، ويجب معاملتهم باحترام وتقدير كأشخاص، وليس فقط كأدوار أو عقبات يتعين التغلب عليها. في بعض الحالات، قد يكون الحفاظ على الوضع الراهن في أجزاء خاصة من مؤسستك الخيار الأكثر أمانًا، في الوقت الحالي على الأقل. ترجمة وبتصرف للمقال Who will push back the most on a move to DevOps?‎ لمايك بورسيل

لا يدرك معظم الناس1 تمامًا مقدار المتعة التي في الأمان، أو بالضبط كيف تجعلك الخبرة الأمنية مثيرًا بالنسبة للأشخاص الآخرين2. نحن نعلم أنها شيقة وجذابة وممتعة، لكنهم لا يعلمون ذلك. لهذا السبب، عندما يتوجه مسؤولو الأمن إلى الأشخاص الآخرين (دعنا نسميهم "أشخاصًا عاديين" لأغراض هذه المقالة)، ويقولون لهم إنهم يفعلون شيئًا خاطئًا، ولا يمكنهم إطلاق منتجهم، أو نشر طلباتهم، أو أنه يجب عليهم التوقف عن استلام طلبات المبيعات على الفور وربما خلال اليومين المقبلين حتى يتم إصلاح ذلك، عندها قد لا يتفاعل هؤلاء الأشخاص العاديون دائمًا بمستوى الامتنان الذي نعتقد أنّه مناسب. في بعض الأحيان، في الواقع، سيعرضون ردودًا سلبية، قد تكون حتى شخصية، على هذه الاقتراحات. تكمن المشكلة في أنّ أفراد الأمن يعرفون كيف ينبغي أن تكون الأمور، و هذا آمن. لقد تلقوا التدريب وحضروا الدورات وقرأوا المقالات وتصفحوا الكتب الأمنية الضخمة3، وكل هذه المصادر تؤكّد بوضوح تامٍّ: يجب أن يكون كل شيء آمنًا. تعني كلمة "آمن" عمومًا "مغلقًا"، خاصة إذا كان أفراد الأمن لم يشاركوا بشكل كاف في إجراءات التصميم والتنفيذ والعمليات. يريد الناس العاديون، من ناحية أخرى، فقط أن تعمل الأشياء. هناك انفصال جوهري بين وجهتي النظر هاتين لأننا لن نستطيع الإصلاح إلا إذا كان الأمن هو المطلب الأساسي لأي مشروع من بدايته وحتى نهايته4. ليس الأشخاص العاديون الآن أغبياء. إنهم يعلمون أن الأمور لا تعمل دائمًا بشكل مثالي؛ لكنهم يرغبون في عملها أكبر قدر ممكن. وهذه هي الفجوة التي نحتاج إلى تخطيها. لقد تحدثت من قبل عن التدهور المُتحكّم فيه كمفهوم، وهذا جزء من القصة. أحد الأشياء التي ينبغي لأفراد الأمن أن يكونوا مستعدين للقيام بها هو توضيح أن هناك مخاطر يمكن التخفيف منها. بالنسبة لأفراد الأمن، يجب التخفيف من هذه المخاطر من خلال "الإغلاق". إنّه من السهل إيقاف الخطر إذ يمكنك فقط إيقاف تشغيل النظام، ولن يوجد خطر من إساءة استخدامه. ولكن بالنسبة للعديد من الأشخاص، هناك مخاطر أخرى: مثال على ذلك أن المؤسسة قد تتوقف في الواقع عن العمل تمامًا لأن بعض أفراد الأمن قد أغلقوا نظام الطلبات. إذا كانوا قد عرضوا عليّ خيار الموازنة بين مخاطرة التوقف عن تلقي الطلبات مقابل مخاطرة فقدان بعض بيانات الشركة الداخلية، فهل كنت سأقوم بالمخاطرة الأولى؟ حسنا نعم، قد أقدم عليها. ولكن إذا لم يُقدّم لي الاختيار، ولم تُوضّح لي المخاطرة، فلن يكون لدي خيار. هذا هو نوع الكلمات التي أودّ سماعها إذا كنت أدير أعمالًا. ليس هذا فقط هو نوع المخاطر الممكنة. فأن تأتي مثلًا إلى اجتماعِ المشروع قبل أسبوعين من إطلاقه وتعلن أنه لا يمكن نشر المشروع "لأن المحادثات على واجهة برمجة التطبيقات هذه تتم دون تصديق على الهوية" ليس أمرًا جيّدًا على الإطلاق لأي أحد. باعتباري مطوّرًا، فلديّ على أيّة حال مفردات مختلفة وهواجس مختلفة عن تلك الخاصة بمالك العمل. ماذا لو أنه بدلًا من العبارة التالية: "تحتاج إلى استخدام التّصديق على الهوية على واجهة برمجة التطبيقات هذه وإلّا لن تستطيع المتابعة"، يطرح مسؤول الأمان السؤال كالتالي: "ماذا سيحدث إذا كانت البيانات التي تُقدّم على واجهة برمجة التطبيقات هذه غير صحيحة، أو يقدّمها شخص ينوي تعطيل عمل النظام؟" وفقًا لتجربتي ، يهتمّ معظم المطورين ويلتزمون بالتشغيل الصحيح للنظام الذي يعملون عليه والبيانات التي يعالجها. في الغالب، تثير الأسئلة التي تُظهر التأثير المحتمل لانعدام الأمن ردود فعل إيجابية أكثر من "مناقشة" بدائية تنتهي أساسًا بالرفض. لا تفهمني خطأً؛ إن هناك أوقاتًا نحتاج فيها، كأفراد أمن، لأن نكون حازمين ومتشبثين بأسلحتنا5. ولكن في النهاية، فإن مالكي الأنظمة أو المنظمات أو وحدات الأعمال أو الموارد هم الذين يتخذون القرار النهائي. إن مهمتنا هي التحدث إليهم بكلمات يمكنهم فهمها والتأكد من أنهم مطلعون جيدًا قدر الإمكان و نتفادى أن يكون جوابهم مجرد "لا". أعني بذلك "أولئك المساكين الذين لا يقرؤون هذه المنشورات، على عكسك، عزيزي القارئ الذكي". يبدو أن زوجتي، للأسف، تندرج في هذه الفئة. الكتب التي عادة ما يكون على غلافها صورة قفلٍ. ونتمنى لك التوفيق في ذلك. مجازًا فقط، فأنا لا أقبل نقل أي أسلحة إلى مكان العمل بما في ذلك الأسلحة النارية. ترجمة وبتصرف للمقال Talking to normal people about security لمايك بورسيل

إن مفهوم DevSecOps كممارسة أو كشكل من أشكال الفن هو تطوير لمفهوم DevOps. لكي تفهم DevSecOps بشكل أفضل، ينبغي أولاً أن يكون لديك فهم كافٍ لما تعنيه DevOps، لذا ننصحك بالاطلاع على مقالات هذه السلسلة إن لم يكن لديك معرفة بماهية DevOps. وُلِدت ثقافة DevOps من دمج ممارسات التطوير (Development) والعمليات (Operations) وفك العزلة بينهما وتوحيد التركيز وتحسين الكفاءة والأداء لكلا الفريقين وللمنتج كذلك. لقد تشكّل مفهوم جديد للتعاون مع تركيز DevOps على صنع منتجات وخدمات تسهُل صيانتها وتعمل على أتمتة الوظائف العملية. إنّ الأمن حصن رئيسيّ مشترك لدى العديد من المؤسّسات. ويركّز المفهوم الأمنيّ على حماية المؤسسة، وهذا يعني أحيانًا إنشاء حواجز أو سياسات تبطئ من تنفيذ خدمات أو منتجات جديدة لضمان فهم كل شيء جيدًا وتنفيذه بأمان وعدم ظهور أي خطر على المؤسسة هي في غنى عنه. بالنظر إلى الطابع الاستثنائي للحصن الأمنيّ وإلى الاحتكاكات التي يمكن أن يظهرها، يعمل أفراد التطوير والعمليات أحيانًا في التفافٍ على الحصن الأمنيّ متجنّبين إياه من أجل تحقيق أهدافهم. في بعض الشركات، يخلق الحصن اعتقادًا بأن الأمن هو مسؤولية كاملة لفريق الأمن وأن الأمر متروك له لمعرفة ما هي العيوب أو المشكلات الأمنية التي يمكن ظهورها كنتيجة للمنتج. جاء مفهوم DevSecOps ليعمل على دمج نظام الأمان داخل منظومة DevOps. من خلال تعزيز الأمن أو بناءه في الدور التطويري أو العملياتي، أو من خلال تضمين الدور الأمني في مهامّ الفريق الهندسي، يجد الأمان نفسه في المنتج بشكل طبيعي ومقصود. يتيح ذلك للشركات إصدار منتجات وتحديثات جديدة بسرعة أكبر وبثقةٍ تامةٍ أنّ الأمان مضمّن كفايةً في المنتج. كيف تنسجم البرامج المتينة مع DevSecOps؟ يعدّ إنشاء البرامج المتينة (rugged software) جانبًا من جوانب ثقافة DevOps أكثر من كونه ممارسة منفصلة، وهو يكمّل ويعزز ممارسة DevSecOps. إن المنتج المتين مثله مثل شيء تصلّب و قَوِيَ عودُهُ من خلال التجارب و الخبرات. من المهم أن نلاحظ أن البرامج المتينة ليست بالضرورة آمنة بنسبة 100 ٪ (على الرغم من أنها قد تكون كذلك في وقت ما). ومع ذلك، فقد صُمّمت للتعامل مع مُعظم ما يمكن أن تواجهه. تتمثل المبادئ الأساسية لنشاط البرامج المتينة في تعزيز المنافسة والتجريب والفشل المتحكم فيه والتعاون. كيف تبدأ في DevSecOps؟ يتضمن الانطلاق في منظومة DevSecOps نقل متطلبات الأمان والتنفيذ إلى أقرب مرحلة ممكنة في عملية التطوير. إنّه يخلق في نهاية المطاف تحولًا في الثقافة يصبح معه الأمن مسؤولية الجميع، وليس فقط فريق الأمن. ربّما تكون قد سمعت بعض الفرق تتحدث عن "التحرّك نحو اليسار" (shift left). إذا بسطت مسلسل التطوير في خط أفقي لتضمين المراحل الرئيسية لتطور المنتج، من المرحلة البدئية إلى التصميم والبناء والاختبار وحتى التشغيل، فإن هدف الدور الأمني هو الاندماج في أقرب مرحلة ممكنة من هذه السلسلة. يسمح ذلك بتقييم المخاطر بشكل أفضل وتلطيفها وتخفيفها بشكل طبيعي. يعمل مفهوم "التحرّك نحو اليسار" على نقل هذه المشاركة إلى أقصى اليسار في هذا الخطّ الأفقي. تبدأ هذه الرحلة بثلاثة عناصر أساسية: التفويض التمكين التعليم يعني التفويض، في رأيي، تخفيف السيطرة والسماح للفرق باتخاذ قرارات مستقلة دون خوف من الفشل أو الارتداد. لكن التحذير الوحيد هنا هو أن المعلومات في غاية الأهمية لاتخاذ قرارات مستنيرة. من أجل تحقيق التفويض، يعتبر دعم الاستثمار والتنفيذ والذي يمكن القيام به من خلال المبيعات الداخلية والعروض التقديمية ووضع مقاييس لتحديد عوائد هذا الاستثمار أمرًا ضروريًا لكسر الحواجز القديمة وفكّ العزلة بين الفرق. سيساعدك بالتأكيد دمج الأمان في مهام فرق التطوير والعمليات وزيادة التواصل والشفافية في بدء الرحلة إلى DevSecOps. يسمح هذا التكامل والتعبئة للفرق بالتركيز على نتيجة واحدة تتجلى في بناء منتج تتشارك فيه المسؤولية وتتعاون على تطويره وأمانه بطريقة فعالة وموثوقة. سيأخذك هذا بعيدا في الطريق نحو تحقيق التفويض. إنه يجعل المسؤولية عن المنتج مشتركة بين الفرق التي تعمل على إنشائه ويضمن إمكانية فصل أي جزء من المنتج والحفاظ على أمانه. يتجلى التمكين في وضع الأدوات والموارد المناسبة في أيدي الفرق. يتعلق الأمر بخلق ثقافة مشاركة المعرفة من خلال المنتديات والتجمعات غير الرسمية. من المرجّح أن يساهم إنشاء ثقافةٍ تركز على الأتمتة وعلى وجوب ترميز المهام المتكررة إلى تخفيف العبء التشغيلي وتعزيز الأمان. يتجاوز هذا السيناريو مجرد توفير المعرفة بل يتعلق الأمر بإتاحة الوصول إلى هذه المعرفة بشكل كبير من خلال قنوات ووسائل متعددة توفرها العديد من الأدوات بما يتيح استخدامها ومشاركتها بأي طريقة تفضلها الفرق أو الأفراد. قد تعمل إحدى الوسائط بشكل أفضل في مرحلة كتابة الشيفرة بينما يكون غيرها مناسبًا في مراحل أخرى. اجعل الأدوات بسيطة وسهلة الوصول ودع الفريق يستخدمها بفعالية. سيكون لفرق DevSecOp المختلفة تفضيلات مختلفة، لذلك اسمح لهم بالاستقلال كلما أمكن ذلك. يعدّ هذا تمرينًا دقيقًا للتوازن لأنك تريد في الوقت ذاته وفرة في الإنتاج وقدرة على مشاركة المنتجات. سيساعد التعاون والمشاركة في اختيار وتجديد هذه الأدوات على تقليل الحواجز بين الفرق. أخيرًا، يدور مفهوم DevSecOps حول التدريب وبناء الوعي، و هذا ربّما هو الأمر الأهمّ في كل ما قلناه. تعد الاجتماعات واللقاءات الاجتماعية و العروض التقديمية الرسمية داخل المؤسسة طرقًا رائعة للأفراد لتلقين ومشاركة ما تعلّموه. في بعض الأحيان تبرز هذه التحديات أو المخاوف أو المخاطر المشتركة التي قد لا يلاحظها الآخرون. إن المشاركة والتدريب وسيلتان فعالتان للتعلّم ولإرشاد الفرق. وفقًا لتجربتي، تظلّ ثقافة كل مؤسسة فريدة من نوعها، لذلك لا يمكنك اتباع النهج القائل "مقاس واحد يناسب الجميع". تواصل مع فرقك واكتشف الأدوات التي يريدون استخدامها. اختبر مختلف المنتديات والتجمعات واعرف ما هو أفضل لثقافتك. ابحث عن التعليقات واسأل الفرق عمّا ينجح وعمّا يعجبهم ولماذا. تكيّف وتعلّم وكن إيجابيًا ولا تتوقف أبدًا عن المحاولة، وعلى الأغلب سوف يحالفك النجاح دائمًا. ترجمة وبتصرف للمقال ?What is DevSecOps لبريت هونولدت و آرون رينهارت