كيف تحافظ على صدارة الأمن في عام 2023

يعد الأمان والأداء حجر الزاوية لكل مشروع وموقع وتطبيق ومكون تقوم بتطويره. ولكن في هذا المشهد المتغير باستمرار ، قد يكون من الصعب البقاء على رأس أفضل الممارسات الأساسية ، مع الابتكار أيضًا.

في هذه المحادثة ، استمع لأفضل الخبراء التقنيين حول كيفية بقائهم على اطلاع بالأمان والأداء في عام 2023.

مكبرات الصوت:

• Ramadass Prabhakar ، نائب الرئيس الأول ورئيس قسم التكنولوجيا في WP Engine
• لورنس إدموندسون ، كبير مسؤولي التكنولوجيا في Barbarian
• سيرجي إيساسي ، نائب رئيس المنتج ، أداء التطبيق في Cloudflare
• تيم ناش ، مستشار أمان WordPress في timnash.co.uk
• جيمي سكوايرز ، CTO في space150

نص:

رمضان: مرحباً بالجميع. مرحبًا بكم في الإصدار الرابع من Decode. لقد كان من الرائع رؤية النمو في الحضور كل عام. على مدى العامين الماضيين ، كان هناك تحول كبير في المشهد الأمني ​​عبر الصناعة. لقد رأينا نشرات إخبارية منتظمة حول الاختراقات الأمنية والأمان كموضوع يأتي بشكل متكرر في المناقشات مع العملاء والمطورين على حد سواء. لذلك اليوم ، قمنا بتجميع مجموعة رائعة من خبراء الصناعة المتحمسين للأمن وهم هنا للإجابة على أسئلتنا ومشاركة ما تعلموه معنا. لنبدأ بمقدمة موجزة لأعضاء اللجنة. لورانس ، إليكم.

لورانس إدموندسون: شكراً جزيلاً لاستضافتنا. لورنس إدموندسون هنا ، كبير التكنولوجيا في بربري. Barbarian هي وكالة رقمية كاملة الخدمات. نحن موجودون في نيويورك.

رماداس: شكراً لك يا لورانس. إليكم يا سيرجي.

سيرجي إيساسي: شكرًا. أنا نائب رئيس المنتج في Cloudflare. Cloudflare ، نحن نبني المنتجات التي تجعل أي شيء لعملائنا وشركائنا ، مثل WPE ، يتصل بالإنترنت أكثر أمانًا وأسرع ، وأنا في سان فرانسيسكو.

المنسق: شكرا لك سيرجي. وتيم ، إليكم.

تيم ناش: أنا مستشار أمان في WordPress هنا في المملكة المتحدة. وأنا أقضي حياتي بشكل أساسي في إخافة المطورين.

المنسق: شكرا لك. وجيمي.

جيمي سكوايرز: نعم ، شكرًا لك. أنا مع Space 150 ، وهي أيضًا وكالة رقمية كاملة الخدمات من Minneapolis و CTO هناك.

منسق الجلسة: شكرًا لك على موافقتك على أن تكون عضوًا في فريقنا اليوم. لذا أود أن أبدأ بالحديث عن شيء فريد تقوم به في مجال الأمن اليوم داخل مؤسستك أو ضمن فرقك. لذا ربما لنبدأ بسيرجي.

سيرجي إيساسي: نعم ، سأستمتع بمقدمة تيم ، حيث يخيف المطورين. أحد الأشياء التي نحاول القيام بها أكثر في Cloudflare هو إعطاء عملائنا مزيدًا من المعرفة حول حركة المرور الخاصة بهم وتقليل العبء التشغيلي. لذلك ، تاريخيًا ، إذا كنت ترغب في العثور على ما قد يؤثر على شبكتك ، وما قد يهاجمك قد تراه ، فستقوم بنشر WAF ، وستضعه في وضع السجل ، وبعد ذلك سيكون لديك محلل أمني يطلع على السجلات و انظر ما اكتشفه. وهناك القليل من الموارد للقيام بذلك في هذه الأيام.

لذا فإن تركيزنا لهذا العام هو إعطاء رؤى لعملائنا حول الهجمات التي نراها عليهم ، حتى لو لم يستخدموا المنتج الذي من شأنه منع هذا الهجوم اليوم. حتى يتمكنوا من معرفة ما إذا كان تطبيقهم يتعرض للهجوم أم أنه في حالة جيدة بشكل عام. وهذا هو تركيزنا في الفترة المتبقية من العام ، حيث نقدم جميع منتجاتنا الأمنية ونسمح لعملائنا بمعرفة ما قد يحدث أو ما يحدث بالفعل على شبكتهم وما إذا كانوا يريدون حظره أم لا.

المنسق: رائع. هذا يبدو حقا قويا. أنا أتطلع إلى سماع المزيد عن ذلك. لذا تيم ، ماذا عن نفسك؟

تيم ناش: لذا فأنا أعمل مع العديد من العملاء المختلفين ، كلتا الوكالتين ، ولكن أيضًا مواقع الويب الفردية الأصغر. وأنا أقوم بالكثير من مراجعات الكود ومراجعات الموقع. وحتى هذا العام ، لم أشهد نموًا في الأشخاص الذين يهتمون كثيرًا بالفعل لدرجة أن الناس سعداء جدًا بالحصول على مراجعة والقيام فقط بالعمل الذي تطلب منهم القيام به. لذلك إذا أعطيتهم مجموعة من التوصيات ، فإنهم يتابعون ذلك. ولكن بعد ذلك ، إذا عدت إلى الموقع في العام التالي ، فسأقدم لهم مجموعة أخرى من التوصيات. لذلك لقد رأيت كثيرًا تحولًا في العام الماضي في الأشخاص الذين يهتمون بما يكفي لطرح الأسئلة. وهكذا بالنسبة لي ، تم التخلص من عمليات تدقيق الكود في السطر الكبير الطويل هنا 6 ، 4 ، 2 من هذا الملف ، بلاه ، يجب القيام به على هذا النحو.

لقد تخلصت من كل ذلك وبدأت حقًا في التركيز على التعليم وأدركت أنه ، لأكون صادقًا ، ما يريده معظم الناس هو عدم إخباره ، يجب عليك إصلاح هذا الخط ، ولكن ليتم إخبارك ، إليك كيفية الإصلاح كل سطر هناك. لذلك بالنسبة لي ، كان التغيير الكبير والتغيير الكبير في التركيز على التعليم. وهذا شيء على مستوى الصناعة. أعتقد أن هناك المزيد والمزيد من الأشخاص الذين يتحدثون عن الأمن هذا العام أكثر من الماضي وأكثر وأكثر من السنوات السابقة.

المنسق: لا ، هذا رائع. يعجبني حقًا التركيز على التحول من إعطائك السمك إلى تعليمك كيفية صيد الأسماك. إذن هذا حقًا-

تيم ناش: كنت أحاول تجنب هذا القياس بأي ثمن لكوني مبتذلة.

المنسق: شكرا لك.

تيم ناش: أحسنت.

المنسق: حسنًا ، جيمي.

جيمي سكوايرز: نعم ، أعتقد أن هناك الكثير ، قررت التركيز على شيء واحد محدد حقًا للتحدث عنه في هذه الإجابة. وهذا يقيد نطاقك حقًا عندما تتعامل مع رموز API والوصول إليها. أعتقد أن اختراق مستودع Heroku و GitHub في العام الماضي كان بمثابة تذكير جيد حقًا بأنك تتحكم فقط في أشياء كثيرة. لذلك عندما نعمل مع مطورينا ، نذكرهم بأهمية سياسة الوصول المحددة النطاق على أي نظام أساسي أو نظام قد تعمل معه. في كثير من الأحيان ، يريد المطور حقًا الوصول المفتوح على نطاق واسع في وقت مبكر من التطوير فقط من أجل السهولة. وأحيانًا هذه الأشياء ربما - جميعًا نخجل من الاعتراف بها - لا يتم تشديدها إلى المستوى الذي يجب أن تكون عليه قبل الإنتاج. لذا البدء مبكرًا في التفكير حقًا في تلك النطاقات الأمنية.

المنسق: شكرا لك جيمي. ولورنس ، أعلم أنك تعمل أيضًا كثيرًا مع المطورين. إذن ما الذي تبحثون عنه جميعًا في تلك الجبهة من أجل ذلك؟

لورانس إدموندسون: أجل ، بالتأكيد. فقط للبناء على ما قاله جيمي ، بالتأكيد ، كلانا يعمل في مجال الإعلان. لذلك أعتقد أننا نرى الكثير من نفس التحديات عندما تعمل في مجال الإعلان مقابل العمل في بيئة منتج. بالنسبة لنا ، نتطرق إلى الكثير من التقنيات المختلفة ، والكثير من مجموعات التكنولوجيا المختلفة. علينا أن نكون محايدين من الناحية الفنية. لذا فإن ما نراه هو أن المستهلكين ينخرطون بطرق متعددة الآن من خلال الأجهزة المحمولة ووسائل التواصل الاجتماعي. قبل بضع سنوات ، كان سطح المكتب هو الوسيلة الأساسية للوصول إلى المواقع والمحتوى. الآن انقلبت تماما. لقد انتقلت من سطح المكتب إلى الهاتف المحمول إلى اجتماعية الآن.

لذلك ، يجب تأمين طبقات واجهة برمجة التطبيقات (API) الخاصة بك وطبقات التطبيق الخاصة بك بطرق تحتوي على القليل من جنون العظمة الصحي المرتبط بها. لذلك ما نراه هو أن طيف الهجوم ينمو ، لذلك نحن نبحث باستمرار عن طرق جديدة لجعل DevOps يفكر مثل المبرمجين حتى يفهموا الطرق الممكنة لخرق الأشياء. هذا نوع من ما نفعله اليوم.

المنسق: شكرا لك على ذلك. وقد ذكرت كيف يتزايد متجه الهجوم. وهذا شيء لدينا هنا ، في WP Engine ، كنا نبحث في المزيد عن كيفية تبني آلية دفاع في العمق. لذلك لا تثق في أي طبقة لتكون آمنة. فكيف تدمج ذلك في طريقة ترميزك والطريقة التي تكتب بها البرامج. لذا شكرا لكم على ذلك. كما تحدثتم جميعًا عن الاتجاه المتغير الذي يحدث هناك ، الانتهاكات التي حدثت في العام الماضي. لذا ، عندما تنظر إلى عام 2023 ، ما هي بعض الموضوعات أو التهديدات الرئيسية التي تنتبهون إليها جميعًا؟ وربما ، يا سيرجي ، يمكنك أن تبدأنا. نعم.

سيرجي إيساسي: بالتأكيد. وسيبدو هذا سخيفًا لأنه عام 2023 وسأقول كلمة DDOS ، لكنه لا يزال شيئًا. وقد كان حقًا تحولًا مثيرًا للاهتمام في الأشهر التسعة أو الاثني عشر الماضية في عالم DDOS. الحجمي ليس في الحقيقة ناقل DDOS هذه الأيام. هناك انعكاس أقل بكثير. ومن منظور ممثل التهديد ، من الأسهل إطلاق DDOS لأن لديك الكثير من الأدوات الجاهزة ، أليس كذلك؟ لقد عدنا تقريبًا إلى أيام TD النصية ، ولكن لديك أيضًا عدد أقل بكثير من الأنظمة المخترقة للهجوم. لذلك إذا كنت تحاول القيام بالتفكير ، فليس هناك الكثير من البنية التحتية التي يديرها شخص ربما لم يقم بإصلاح نظامه ، لذا يمكنك أخذ حزمة واحدة وتحويلها إلى 10. هذا ليس شيئًا كبيرًا بعد الآن.

لذا فهم ينتقلون إلى الطبقة 7. والطبقة 7 هي أكثر تكلفة لبدء التشغيل من حيث أنك تحتاج إلى الكثير من وحدة المعالجة المركزية للقيام بذلك ، ولكنها أيضًا مكلفة للغاية للتخفيف. لذلك إذا كان لديك نوع من نظام حماية DDOS ، فعليك في الواقع قبول الاتصال وفحصه ثم البدء في إسقاطه مقابل شيء يمكنك إسقاطه في طبقة أقل. ما وجدناه وقمنا بتخفيف أكبر مستوى تم الإبلاغ عنه من Layer 7 DDOS الشهر الماضي فقط على الإطلاق. الموضوع الرئيسي في تلك الهجمات هو الأجهزة الأكثر قوة.

لذا إذا فكرت في كل الأشياء التي قمنا بتوصيلها في المنزل هذه الأيام ، فإن المعالج الموجود على هذا الجهاز أفضل بكثير مما كان عليه قبل ثلاث أو أربع سنوات. لذا تعمل الكاميرا الخاصة بك أكثر من ذلك بكثير. لذلك فهي تحتوي على وحدة معالجة مركزية أفضل ، حتى أجهزة التوجيه الخاصة بك هي في الواقع آلة قوية إلى حد ما. وأي حل وسط لهذه الأجهزة يمكن أن يسمح بهجوم كبير وكبير ، خاصةً أنه إذا قمت بالتسريب ، فأنت الآن تتنازل بشكل أساسي عن جميع الأجهزة المتصلة.

الشيء الآخر الذي نتحدث عنه قليلاً هذه الأيام ، لكن الهدوء أكثر قليلاً ، لقد انتقلنا من الأجهزة المخترقة إلى الحسابات المخترقة في الخدمات السحابية. الخدمات السحابية لها وحدة معالجة مركزية غير محدودة بشكل فعال. لذلك إذا تمكنت من الوصول إلى عدد من حسابات الأفراد أو الشركات وقمت بتدوير كل ما أريد في هذا النظام السحابي ، فيمكنني حينئذٍ شن هجوم كبير للغاية. وهذا ما نراه في الهجمات القياسية. حسنًا ، 2023 ، لا يزال DDOS شيئًا ما ، ولكن الآن في الطبقة 7 مقابل الطبقات السفلية.

المنسق: شكرا لك. هذا أمر مخيف ، ولكن في نفس الوقت أيضًا ، أعتقد أنه يشير إلى كيفية استمرارنا في تحسين بروتوكولات الأمان الخاصة بنا واستمرار نمو مجال التركيز. أعلم ، لورانس ، لقد تحدثت أنا وأنت في الماضي حول الذكاء الاصطناعي باعتباره طفرة وتهديدًا. أود أن أسمع بعض أفكارك حول الذكاء الاصطناعي التوليدي وكيف ترى أن ذلك يؤثر فعليًا على مساحة سطح الأمان في عام 2023.

لورانس إدموندسون: أنا متحمس جدًا ومتفائل جدًا بشأن الذكاء الاصطناعي. نحن في Barbarian ، لكن في نفس الوقت ، الأمر مخيف للغاية. إمكانية استخدام شيء مثل chatGPT بطرق ضارة. لذلك على سبيل المثال ، يمكن أن يكون لديك Chat GPT يعلق على التعليمات البرمجية الخاصة بك. وهو في الواقع يقوم بعمل لائق ، اعتمادًا على اللغة ومدى فوضى الكود الخاص بك ، فإنه يقوم بعمل جيد جدًا. لذا فإن الشيء التالي ، على ما أعتقد ، سنراه هو الدردشة GPT - وقد يكون هذا قيد التنفيذ بالفعل لأنه كل يوم ، هناك مثل ، Chat GPT يفعل هذا. مثل اليوم ، رأيت أنه قادر على الرد في Slack والعثور على إجابات في Slack.

لذا أعتقد أن الشيء التالي ، فيما يتعلق بالأمان ، في Chat GPT هو أن تجد Chat GPT ثغرات وتقوم بالفعل بكتابة التعليمات البرمجية إلى - شفرة ضارة لاستغلال نقاط الضعف التي تجدها حقًا. لذلك نحن نرى ذلك ، خاصةً إمكانية حدوث ذلك في الذاكرة. لذلك لا تترك هجمات الذاكرة توقيعًا طوال الوقت. إذاً ، الفيروسات وأجهزة فحص الفيروسات التقليدية ، تعمل على البحث عن تواقيع هجوم. في هجمات الذاكرة ، أنت تهاجم التطبيق. أنت تفعل شيئًا مثل تجاوز سعة المخزن المؤقت. أنت تبحث عن اختراق التطبيق في وقت التشغيل. أعتقد أن Chat GPT مهيأة بالفعل للقيام بذلك. وأعتقد أنها مجرد مسألة وقت حتى نرى أول استغلال واسع النطاق لـ ChatGPT يحدث.

تيم ناش: كيف تتخيل حدوث ذلك بالفعل؟ لأنه من الواضح أن ChatGPT ، في جوهرها ، هي مجرد مجموعة من طلبات APIs إلى الخادم. وأنت ترسل طلبًا يقول ، مهلاً ، أنشئ لي بعض الشفرات الخبيثة. إنها تعيدها. أعني ، هناك الكثير من الأشخاص يقومون بالفعل بإنشاء تعليمات برمجية ضارة. كيف ستصبح بعد ذلك أسوأ من الشفرة الخبيثة الموجودة بالفعل؟

لورانس إدموندسون: هذا هو بالضبط الأمر. يوجد بالفعل مستودع كبير للتعلم منه. لذا فإن ChatGPT ، ما يفعله ، ينظر إليه في الواقع - عليك تدريب النموذج. وبمرور الوقت ، يقوم المهندسون بتدريب النموذج على التعرف على ما يقوله أحدهم ، هذا في الواقع ما يقصدونه. لذا فهم السياق. هذا هو بالضبط ، ولكن بطريقة مختلفة. إنه تدريب النموذج على كتابة الكود وما يعنيه في الواقع. وبعض اللغات سهلة للغاية. إذن PHP ، من السهل جدًا كتابة التعليمات البرمجية بلغة PHP. هذه اللغات المفسرة أسهل كثيرًا. إنه أمر أكثر فوضوية ، ولكن مقابل القيام بشيء مثل Java ، والذي يجب تجميعه ، هل تعرف ما أعنيه؟

لذلك أعتقد أن الطريقة السهلة للقيام بذلك تتمثل في إنشاء نموذج قائم على chatGPT 3 ، والذي في الواقع ، تقوم بتدريبه على الواقع - تمر عبر عناصر بناء الجملة ، وتتصفح جميع الأشياء الأساسية في علوم الكمبيوتر ثم تأخذها خطوة للأعلى وانطلق ، حسنًا ، تحتوي حزم NPM هذه على هذه الثغرات. ابحث عنها واكتشف طريقة فعلاً - لديهم نقاط الضعف هذه ، أنا آسف ، وانظر في طريقة لاستغلال تلك الثغرات الأمنية. أنا أضمن ذلك ، لسنا بعيدين جدًا عن رؤية شيء كهذا يحدث.

منسق الجلسة: شكرا لك يا لورانس. أعتقد أنها منطقة ناشئة جدًا. الأمر المثير للاهتمام في هذا الفضاء هو فقط عن ذلك مع الذكاء الاصطناعي ، بشكل عام ، إنه يحتوي على هذا التوازن فيما يمكنك الاستفادة منه ، سواء كان ذلك لاستخدام هذه التوقيعات فعليًا لمنعه والتعلم منه لمعرفة كيف يمكنك منعنا من كتابة كود رديء أو كود ضعيف. وفي الوقت نفسه ، تمامًا كما رأينا أن الناس يتحدثون ، مهلا ، لقد كتبت أول مكون إضافي لي في خمس دقائق مع Chat GPT ، أعتقد - نعم ، يتعلق الأمر أكثر ببدء تمكين الأشخاص من إنشاء برامج ضارة قليلاً أسرع؟ لكن أعتقد أنه يحتوي على كلا الجانبين.

يتعلق الأمر أكثر بكيفية الاستمرار في الاستفادة من أي من هذه الأدوات لمجرد التحسن في كتابة التعليمات البرمجية ، ولكن كتابة تعليمات برمجية أكثر أمانًا. وأنا أعلم ، تيم ، أن هذا مجال شغفك به. هل ترغب في التحدث أكثر قليلاً عن كيفية تطور برنامج Secure Code في عام 2023 وما الذي تفعله في هذا المجال؟

تيم ناش: حسنًا ، أعني ، من نواح كثيرة ، تعد Chat GPT مثالًا جيدًا على ذلك. إذا كنت أفكر في متجه للهجوم ، فسأكون صادقًا ، لم أكن أفكر في القيام بمسح جماعي ، وإطعامه الكثير من الأشياء كممثل سيء. كنت أفكر في الأمر على أنه مطور الكود المتوسط ​​الذي كان يحاول توفير الوقت وكان يغذي الأشياء في Chat GPT ويطرحها وليس بالضرورة أن يفهم تمامًا كل الكود الذي يتم كتابته ، والذي يتم إنتاجه ، ولم يكتب أي اختبارات لـ تماشى مع الامر. هذا مجرد شيء سريع ، إنه مجرد نص سريع ، كل شيء على ما يرام. يدخل في الإنتاج ، إنه ليس جيدًا وكل شيء يحترق.

الآن هذا هو بالضبط نفس الشيء الذي يفعله كل مطور كل يوم ، بغض النظر. لا يغير Chat GPT ذلك ، ولكنه يمكّنه بسهولة أكبر قليلاً. إنه يعطي - هناك حواجز أقل.

سيرجي إيساسي: نعم ، ليس الأمر مشابهًا تمامًا للنسخ واللصق من مثل Stack Overflow ، والذي أعتقد أنه ما تشير إليه ، Tim ، وهو أساسًا كل ما أفعله من أجل الكود. لكنني أعتقد أنها زيادة في الكفاءة بالتأكيد ، من الناحيتين الإيجابية والسلبية. لكنني أعتقد أنه يسمح بإجراء تغييرات أكثر دقة واستغلالًا أسرع لشيء لا يمكن للمحرك المستند إلى التوقيع أن يلحق به حقًا. لذلك أنت حقًا عندما تقوم بالكشف ، تحتاج إلى نظام يقول ، هل يبدو هذا مشابهًا لشيء رأيته في الماضي ، بدلاً من المطابقة المباشرة لشيء رأيته في الماضي. وهذا في الواقع على جانب الاكتشاف من المحتمل أيضًا أن يتم تقديمه بشكل أفضل مع ML أو AI أو أي شيء تريد تسميته.

لقد تعلمنا أنه مع حركة المرور الآلية ، كما تعلم ، على الروبوتات بشكل أساسي. أفضل طريقة لمعرفة كيفية الالتفاف حول الاكتشاف المستند إلى التوقيع هي باستخدام ML. لكنك الآن تنتقل من ، أنا أعلم تمامًا أن هذا أمر سيء ، حسنًا ، من المحتمل أن يكون آليًا ، أو من المحتمل أن يبدو مثل التوقيع الذي رأيته من قبل ، ولكن ليس تطابقًا تامًا.

المنسق: رائع. شكرًا لك. شكرًا ، سيرجي وتيم على هذا السياق الإضافي. لذا من بين الحاضرين لدينا الكثير من المطورين والوكالات الموجودة هنا اليوم. ويفكر الكثير من الأشخاص في إنشاء أفضل الممارسات ، خاصة وأن السيناريوهات تتغير من حيث نواقل التهديد. إذن ما هي بعض أفضل الممارسات التي قد توصي بها عند إنشاء موقع أو تطبيق أو نظام أساسي ، أو عندما تبدأ في مشروع جديد. إذن ما هي بعض الأشياء التي يجب أن يبحث عنها الناس؟

سيرجي إيساسي: لذا يمكنني أن أبدأ ذلك. سيكون أكثر على الجانب التشغيلي من جانب التنمية. أعتقد أن أحد الأشياء التي نكرز بها هنا هو ، أولاً ، افتراض أن شيئًا سيئًا سيحدث. لذا فإن الخرق قادم ، لا يمكنك أن تفاجأ به. من المحتمل أن يحدث في مرحلة ما. ومفتاحنا - لذا ، واحد ، قم بإنشاء كتاب تشغيل لذلك. لذلك عندما يحدث ذلك ، تعرف على الأفراد الذين يجب الاتصال بهم وماذا سيكون ردك ، سواء من الاكتشاف والاستجابة ، ولكن أيضًا التواصل مع عملائك إذا كان يؤثر عليهم. وفي هذه النهاية ، الشيء الذي أعتقد أننا نقوم به جيدًا في Cloudflare وكان جزءًا من علامتنا التجارية وأعتقد أنه خدمنا جيدًا هو أن نكون صريحين ومنفتحين ومتواصلين قدر الإمكان حول أي شيء الذي حدث.

كان الانفتاح أمرًا أساسيًا للغاية لإعادة بناء الثقة مع العملاء عند حدوث شيء ما ، سواء كان ذلك خرقًا للبرامج أو خطأ ما ارتكبته فيما يتعلق بحادث ما. الاختباء وراءها ليس هو الخيار الصحيح على الإطلاق.

المنسق: نعم.

جيمي سكوايرز: أعتقد أن شيئًا آخر هو أننا - الآن بعد أن أصبح كل شخص بعيدًا بشكل واضح وخاصة في فرق التطوير ، فإننا في الواقع نأخذ الوقت في بداية المشروع للقيام ببعض التخطيطات المعمارية واللوحات البيضاء. من السهل جدًا الغوص في المتطلبات والتخلص من قصص التنمية ، لكن قضاء الوقت مع أقرانك لتحدي كيف يمكن استغلال ذلك؟ قم بتشغيل السيناريوهات. نحن نقوم بالكثير من تخطيط السيناريو الذي يؤدي إلى الكثير من المحادثات الجيدة مع كيف نريد دعم أجزاء مختلفة من التطبيق.

لورنس إدموندسون: وفقط في ذلك ، لا أعرف ما إذا كان أي شخص يعرف ، لكن MPM هو في الواقع أكبر مستودع مشترك - إنه أكبر مستودع منفرد لمكتبات التطبيقات ، ولكن هذا يعني أيضًا أنه يمثل أكبر خطر. لذا فإن أحد الأشياء التي ندركها جيدًا عند تنفيذ مشروع جديد إذا كنا نستخدم NPM هو التأكد من أننا نبحث في نقاط الضعف ، وأننا نحتفظ بالإصدارات التي ندفعها لتحفيزها ، وذلك قبل نقوم بإجراء تحديث ، ونتأكد من أنه شيء متوافق ، ولكنه آمن أيضًا. لا توجد تهديدات مفتوحة لأننا رأينا الكثير من نقاط الضعف تتسلل عبر NPM. لذلك هذا مجرد شيء واحد يجب البحث عنه.

تيم ناش: أعتقد أننا نديرها في كل مكان.

جيمي سكوايرز: تفضل ، تيم.

تيم ناش: أعتقد أننا نحول كل هذا إلى فكرة أن الثقة تنكسر تمامًا في دورات التنمية لسنوات. بدأ الناس يدركون ذلك الآن. وإذا كنت مطور PHP يعمل في WordPress على سبيل المثال ، فأنت تجلس هناك تستدعي الإجراءات والمرشحات ، لكن لا يجب أن تثق بهذه الإجراءات والمرشحات. أي بيانات واردة ، يجب أن تتحقق من صحتها ، يجب أن تتحقق منها. يجب تطهيرها. ولكن عندما تخرج من قاعدة البيانات ، فلا يزال عليك عدم الوثوق بها.

على الرغم من أنك قد تكون قد وضعت هذه البيانات في قاعدة البيانات ، فلا يجب أن تثق في البيانات التي تظهر. إذا مررنا شيئًا ما إلى مكتبة تابعة لجهة خارجية ، سواء كانت NPM ، أو حزمة الملحن تلك ، أو مجرد مكون إضافي لبرنامج WordPress ، فسيتم تركه على الفور تحت سيطرتنا ، ولا نثق به مرة أخرى. ولكن عندما يعود ، حتى لو قمنا بفحصه ، فإننا ما زلنا لا نثق به. وإذا اتبعت هذه العقلية ، بصفتك مطورًا ، أنه لا ينبغي الوثوق بكل جزء من البيانات ويجب عزله بالكامل ويجب عليك إجراء فحوصات الأمان عليه في كل نقطة معينة ، فستظهر لك مع نظام أكثر أمانًا. قد تخرج بنظام أبطأ قليلاً. قد تصادف نظامًا أكثر إحباطًا قليلاً ، ونظام يحتاج إلى الكثير من الاختبارات للتأكد من أن ما تفعله لا يتسبب في الواقع في مشاكل أكثر مما يساعد.

المنسق: أجل.

تيم ناش: أضف تعقيدًا ، لكنك في النهاية ستحصل على نظام أكثر أمانًا. وهذا ما يريده معظم الناس.

لورانس إدموندسون: أجل.

المنسق: أجل. أنت محق تماما. يتعلق الأمر بعدم الوثوق بأي جزء آخر من التعليمات البرمجية يتم الوصول إليه. وإلى ما تحدث عنه جيمي وسيرجي ، فإن الأمر يتعلق بوضع خطة ومن منظور معماري ، أو من منظور تشغيلي ، ولكن جمع كل ذلك معًا في ممارستك العامة ، سواء كان ذلك مثل آليات التشفير الآمن أو ما إذا كان لديك دليل أحداث. لذا ، تيم ، أنا مهتم جدًا بسماع المزيد منك من حولك - تقوم بالكثير من التدريب ، وتقوم بالكثير من التدريس حول العالم. ما هي بعض الأخطاء الشائعة التي تراها عندما يبدأ الأشخاص في العمل في المشاريع ، أو الأخطاء التي ربما تكون قد ارتكبتها ، لقد ارتكبت الكثير منها.

تيم ناش: كنت سأقول ، أنا متأكد من أنني مذنب بكل خطأ أنا على وشك التحدث عنه. وأكبرها وأبسطها هو أن تكون شخصًا لطيفًا. يفترض معظم المطورين حسن النية. يفترض معظم الناس أنك ستستخدم تطبيقهم بالطريقة التي كتبت بها طلبهم. في كثير من الأحيان ، لا نكتب الوثائق حتى لا يكون لدى المستخدم أي فكرة عن كيفية استخدام التطبيق في المقام الأول ، ولكن هذه مشكلة منفصلة. سيأتي الممثل السيئ ويأخذ أي خطأ ويذهب ، هذا ليس خطأ ، بالنسبة لممثل سيء ، هذه ميزة. هذه فرصة. إنه يفعل شيئًا لا يتوقعه المطور ، لذلك ، هناك طريق محتمل لذلك.

وبشكل عام ، شيء تراه مرارًا وتكرارًا ، عندما تقول ، انظر ، لديك مجموعة من اختبارات الوحدة. اوه رائع. لكنك فقط اختبرت الأشياء الإيجابية ، النتيجة التي تريدها. أنت لم تختبر ما يحدث إذا ذهبنا خارج هذه الحدود. لقد اختبرت للتو للتأكد من أن الشيء يعمل وفقًا لما يريده رئيسك في العمل. إذن ما لديك بالفعل هو اختبارات القبول ، اختبارات القبول المشكوك فيها. ثم يعود إلى كل الأساسيات. كمطور ، تم التراجع عن ذلك ، لا تثق في الأشياء. وإذا كنت مطور WordPress على وجه الخصوص ، فإن WordPress لديه بالفعل بعض الوظائف المساعدة الجيدة حقًا للقيام بكل أنواع إجراءات الأمان القياسية التي نطلب من الأشخاص القيام بها.

ويتعلق الأمر بالتعليم والتعلم لاستخدامها. عندما أقوم بمراجعات الكود ، سأرى نفس المشاكل مرارًا وتكرارًا. وإذا رأيته مرة واحدة في جزء من التعليمات البرمجية ، فسأراه 1000 مرة في نفس مجموعة التعليمات البرمجية. وستكون أشياء مثل ، حسنًا ، لقد سمحنا فقط بظهور أي عناصر قديمة على الصفحة. لم نكن عناء التحقق مما إذا كان هناك أي شيء هناك أم لا. نعم ، نضع أشياء في قاعدة البيانات. أوه ، انظر ، قد يبدو مثل استعلام SQL ، قد لا.

يسهل إصلاح كل هذه الأنواع من الأشياء وقد قدمنا ​​بالفعل الأدوات اللازمة لإصلاحها. والسبب في عدم إصلاحها في كثير من الأحيان ليس حتى أن الناس لا يعرفون أنه لا ينبغي لهم السماح بحدوث هذه الأشياء ، إنه مجرد أننا نشعر بالكسل ، ونقوم بالأشياء بسرعة ، ونحصل على التعليمات البرمجية من Stack Overflow ، نحصل على Chat GPT للقيام بالأشياء لنا ، نحن لا نتحقق من الأمور. والكثير من المشاكل الأمنية تأتي من هذه الحالة ، يجب أن أتسرع. لا بد لي من التسرع. لا بد لي من التسرع ، علي أن أنجز هذا. أنتقل إلى الشيء التالي ، سأنتقل إلى الشيء التالي.

ومن الغريب ، بالنسبة إلى الكثير من المطورين ، منحهم الوقت والمساحة والقول ، لا بأس في قضاء بعض الوقت للتحقق مما فعلته بالفعل ، وعندما يحدث ذلك - وفي الحالات التي أشارك فيها ، أعود وأقول ، حسنًا ، كل هذه الأشياء والمطورين يبدون خجولين. إنهم ذاهبون ، نعم ، نحن نعرف كل هذا. لم يكن لدينا الوقت.

لذلك نأمل أن نمنح الأشخاص مزيدًا من الوقت ومنحهم بالفعل الأدوات ، التي حصلنا عليها بالفعل داخل WordPress. يحتوي WordPress على مجموعة رائعة حقًا من الوظائف المساعدة لمعظم مشكلات الأمان الشائعة التي قد تواجهها في مكون WordPress الإضافي أو القالب. لذا فالأمر يتعلق فقط بتعلم هؤلاء ثم استثمار الوقت لتطبيقهم فعليًا.

المنسق: أجل. وأعتقد أن هذا أمر قوي حقًا ، استثمر الوقت. في أغلب الأحيان ، يعرف المطورون ما يجب إصلاحه. لذا منحهم الوقت. لذا أحببت هذه الرسالة حقًا. وجيمي ، أعلم أنك أدخلت هذا في سير عملك في وكالتك. هل تريد التحدث أكثر قليلاً عن ممارسات سير العمل الآمنة التي قمت بتنفيذها؟

جيمي سكويرز: نعم ، بالتأكيد. وفي الحقيقة ، يبدأ الأمر بمجرد وجود شيء قال سيرجي إنه وجود خطة ، وفي الواقع وجود إرشادات ومعايير لفريق التطوير لديك ليتبعها. أعلم أن هذا قد يبدو أساسيًا للغاية ، لكنني رأيت الكثير من المنظمات وسمعت من الكثير من المهندسين الذين وظفناهم على مر السنين أنها غير موجودة. لم يكن هناك تنظيم في مكان العمل الذي أتوا منه.

لذا ما نحب القيام به هو أن لدينا مجموعة قياسية من الإرشادات ، يحتاج جميع مهندسينا الجدد إلى قراءة ذلك من الأعلى إلى الأسفل. إنها ليست ثقيلة لدرجة أنها غير قابلة للاستهلاك. نود أن نبقيها في تخفيض السعر ، لذلك كل شيء في المستودع. من المحتمل أن نفتح مصدره بالفعل في مرحلة ما. لا يوجد أي شيء مملوك حقًا ، ثم نشجع الجميع على المساهمة فيه. هذا طلب لجميع المهندسين.

لذلك حتى في إرشاداتنا ، قم بعمل ثغرات حيث يمكننا أن نضيف ، حيث يمكننا أن نكون أفضل ، وننمي ذلك باستمرار. لكن قضاء بعض الوقت في ذلك ، بعض الأشياء الأساسية مثل OWASP ، هذه ممارسة قديمة حقًا ، ولكن عليك أن تمر بها مع طلبك ، مع الأخذ في الاعتبار هذه الأشياء. إنه نوع من ما قاله تيم ، إنه حقًا يستغرق بعض الوقت ويكون على ما يرام لأخذ الوقت في ذلك. كنت أرغب في إضافة نقطة إضافية مرة أخرى إلى محادثة الذكاء الاصطناعي. التحدث مع عدد قليل من مهندسينا الأسبوع الماضي كان له بالفعل حدث. هذا شيء نستخدم Chat GPT من أجله هو في الواقع اختبار للوحدة. من خلال أخذ وظيفة واستكشافها بطرق مثيرة للاهتمام ، كيف يمكنك الاستفادة من شيء مثل Chat GPT لكتابة اختبار وحدة حيث لن تكون أفضل مؤلف لاختبار الوحدة هذا ، إلى حد Tim. هذا هو المكان الذي أعتقد أنه يمكننا فيه الاستفادة من الذكاء الاصطناعي أكثر بطريقة وقائية.

لورانس إدموندسون: أجل. ما نقوم به من جانبنا ، أعتقد أن قوائم المراجعة ووجود كتاب قواعد لعب رائعة. نحن نستخدم أدوات آلية مثل SonarQube ولدينا حقًا الفحص في مكانه وأشياء من هذا القبيل ، فقط لرفع جودة الشفرة باستخدام الفحص ، ولكن أيضًا نستخدم SonarQube للتأكد من أن الشفرة أكثر أمانًا ، وهذا ما نبحث عنه عن نقاط الضعف وأشياء من هذا القبيل. أعتقد أن بعض اللغات أسهل من غيرها في العثور على ثغرات ، كما ذكرت من قبل ، فقط بسبب طبيعة اللغة. وأيضًا فقط بعض الأطر التي تكون فيها جودة المبرمجين الذين يساهمون في قاعدة الكود هذه نموذجيًا - نرى ذلك عادةً مع Open Source ، حيث يكون الأمر كذلك تمامًا - هناك الكثير من النسخ واللصق Stack Overflow ، مقابل الأشخاص الذين درسوا بالفعل CS ويعلمون حقًا ما يفعلونه. لذلك هذا مجرد شيء واحد رأيته.

تيم ناش: أشعر أنه يجب علينا الإشارة ، بالتأكيد لنفسي ، إلى أنني أستخدم Stack OverFlow إلى حد كبير كل يوم. ولذا فنحن جميعًا مذنبون في ذلك. من الجيد التمسك بها ، لكنني لا أعتقد - أعني ، أتذكر عندما بدأت البرمجة لأول مرة. حصلت على مجلة وكنت أكتب رمزًا من المجلة وأضغط على Enter. لا أستطيع أن أتخيل أن الويب يعمل حقًا اليوم إذا كنا ما زلنا عالقين في القيام بذلك ولم يكن لدينا Stack Overflow ، أو ما شابه ذلك.

سيرجي: لا ، إنه المسرع. ونأمل أن يكون الذكاء الاصطناعي هو المرحلة التالية من ذلك. لكن نعم ، إنها ميم ممتعة.

المنسق: شكرا لك. حتى يتحول قليلا. هناك الكثير من الزخم الذي يحدث في الصناعة حول تطبيقات مقطوعة الرأس وبلا رأس. وقد رأينا أيضًا في بعض قنواتنا الأخرى اليوم أو جلسات أخرى تتحدث عن مقطوعة الرأس. لذلك عندما بدأنا العمل مع Atlas في WP Engine ، التقينا بالعديد من المطورين وكان الأمان دائمًا دافعًا رئيسيًا. إذن كيف تنظر إلى الأمان مع مقطوعة الرأس؟ وأنا أعلم ، جيمي ، هذا مجال قمت فيه ببعض المشاريع حوله. نود الحصول على رأيك في ذلك.

جيمي سكوايرز: نعم ، نقوم بالكثير من العمل في مقطوعة الرأس. أعتقد أن جميع مشاريعنا تقريبًا في هذه المرحلة ربما تتخذ نهجًا معماريًا بلا رأس. أعتقد أن هناك بضع نقاط أريد فقط توضيحها ، من حيث صلتها بالأمن. لذلك أعتقد أن الأول هو أنه عندما تختار هندسة مقطوعة الرأس ، فإنك تضع نفسك بشكل عام أكثر في معسكر مفتوح المصدر في البداية. وهناك الكثير من الجدل بالطبع حول ما هو أكثر أمانًا أو مفتوح المصدر أو مصدر مغلق. أنا أميل إلى الوقوع في معسكر مشاريع OSS أكثر أمانًا بطبيعتها. لذا فأنت تختار أطرًا مثل Next و WordPress ، حيث يكون لديك مجتمع عملاق. وهذا يميل إلى مزيد من الأمان من خلال الانكشاف فقط.

لذلك أعتقد أن هذا واحد. أعتقد أن الثاني هو شيء مثل Static Generation. لذا فالكثير من مواقع الويب والمنتجات التي تم إنشاؤها ، لا تحتاج إلى الطبيعة الديناميكية لإدارة محتوى كبيرة ، ونظام متآلف بالمعنى التقليدي. يمكنك الاستفادة من شيء مثل Cloudflare وإنشاء أجزاء كبيرة من هذا التطبيق بشكل ثابت ، وبالتالي تقليل بصمتك للمتجهات والتعرض. لذلك نحن معجبون بهذا. وبعد ذلك ، بالطبع ، ستحصل على جميع مزايا الأداء مع ذلك أيضًا. هذه مجرد بضع نقاط أردت توضيحها في الهندسة المعمارية مقطوعة الرأس. لكن العديد من الأسباب من وجهة نظر أمنية نحبها. لكنني أعتقد أن هذين المجالين ربما يكونان من أكبر المجالات البارزة.

تيم ناش: أرغب في العودة نوعا ما وتذكير الناس بأنه لا يزال هناك نظام لإدارة المحتوى في الخلف. وهذا كثيرًا ما أسمعه أن مقطوعة الرأس آمنة تمامًا. إنه مثل ، نعم ، لكن نسخة WordPress المكشوفة التي لا تزال موجودة هناك ، فقط لأنك لا تتصل بها مباشرة من موقع الويب ، نعم ، لا تزال موجودة على admin.yoursite.com. وأنت لا - هناك اعتقاد مؤكد أنه ، نعم ، حسنًا ، نحن آمنون الآن لذلك لا داعي للقلق بشأن تحديثه لأنه ليس موقع الويب. إنه مثل ، لا ، لا ، ما زلت بحاجة إلى كل الأشياء التي كنت تفعلها من قبل والآن لدينا الجانب الآخر أيضًا.

وأعني ، مصطلح مقطوعة الرأس هو مصطلح رائع يتعلق بشيء كان موجودًا منذ فترة طويلة ويحصل على الكثير من الزخم ، لكننا كنا نفعل ذلك قبل أن يكون لدى WordPress واجهة برمجة تطبيقات REST. كنا ندفع المحتوى من WordPress إلى أشياء مثل Jekyll للحصول على موقع ثابت على الأقل منه. وكان السبب الأصلي لفعل ذلك هو تغيير نظام WordPress أو نظام إدارة المحتوى الخاص بك داخل شبكتك. لذلك يمكنك قفله وإبعاده عن شبكة الويب الكبيرة والمخيفة.

الآن نحصل على الكثير من شركات الاستضافة التي تقدم حلول بدون رأس. And that infrastructure is now out in the cloud again. So we've sort of moved the big benefit for Headless. And we're slowly shifting it back into the public domain again, which seems like a very almost backwards move, but it's the only move for widespread adoption. So there's a balancing act we have there. But yeah, just a small little warning into the big space of keep the backend secure still. You can't just rely on it being–

TIM NASH: Just because something's got some HTML files at the front, the back end still needs to stay just as secure as before.

MODERATOR: Yeah, absolutely. I mean, Headless, by default, doesn't mean that everything is secure. It means that you have a different paradigm. And that's what I think I was interested in, looking at what practices that you bring in as you look at Headless infringers. So yeah, I think that's you're very apt in stating that you still have to secure both the CMS part, as well as the web part of it. So as we are wrapping up, what I would love to do is we have had a lot of good topics to talk about in here, but I would love to take like 10 seconds from each one of you to say that if there is one thing that our audience could do in these next two months after the end of the session, what would that be? What's your recommendation?

LAWRENCE EDMONDSON: I guess I'll start off. My recommendation would be very simple. Security should be everyone's business. I think a lot of times, security doesn't become a topic or consideration until there's a problem. If I were a developer, I would make sure that I am being very proactive in terms of taking the necessary steps. It's 2023, we shouldn't be storing anything in clear text.

Everything should be encrypted as much as you can. Use Hashicorp, encrypt your database and make sure that your keys are stored securely, or it's something that's not easily compromised. But that's what I would encourage folks to make sure that security is top of mind all the way throughout.

MODERATOR: Thank you, Lawrence. Sergi, what about you?

SERGIS ISASI: I would say get an inventory of what's exposed. Know what's on the internet and make sure that the proper– at least aware of what's there, if not fully protecting it.

MODERATOR: Thank you. And Jimmy?

JIMMY: Scenario planning. Take the time in your project to do the scenario planning and create those playbooks, both preventative and then reactive once something does happen, to Sergi's point earlier. What are your action steps for that? Take that time and the project will pay off dividends later.

MODERATOR: Wonderful. شكرًا لك. And Tim, bring us home.

TIM NASH: Oh, I want to reinforce what Lawrence said. Security is everybody's responsibility. Give people the time and space to actually do their jobs properly and you'll find that you will come out with a much more secure project.

MODERATOR: Thank you. Security is indeed everyone's responsibility. So thank you to our amazing panelists for taking the time today and also to everybody in the audience. Hope you enjoyed this session. Thank you and bye.