المحتوى عن 'تعرف على devopssec'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • التجارة الإلكترونية
  • الإدارة والقيادة
  • مقالات ريادة أعمال عامة

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML
    • HTML5
  • CSS
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • Sass
    • إطار عمل Bootstrap
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 2 نتائج

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

    إن مفهوم 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 لبريت هونولدت و آرون رينهارت