owasp/docker-securityإحكام السيطرة على أمان الحاويات
===============
هذا هو OWASP Docker Top 10. إنه عمل قيد التقدم.
يصف هذا المستند أهم 10 نقاط أمنية لبناء بيئة حاويات آمنة. يمكنك استخدامه كورقة مواصفات إذا كنت تبدأ من الصفر، أو بدلاً من ذلك يمكنك تسليمه إلى مقاول سيتولى ذلك نيابة عنك.
يمكن استخدامه أيضًا لتدقيق أو تأمين تثبيت قائم، ولكن هنا بشكل خاص يجب أن تبدأ التفكير في الأمن مبكرًا جدًا. الأفضل أن يكون ذلك في مرحلة التصميم. ففي وقت لاحق يصبح تغيير بعض القرارات التي اتخذتها إما صعبًا أو مكلفًا، سواء من حيث المال أو الوقت.
على الرغم من أن اسم المستند يشبه OWASP Top 10، إلا أنه مختلف تمامًا. أولاً، إنه لا يتعلق بالمخاطر المبنية على البيانات المجمعة مثل OWASP Top 10. ثانيًا، النقاط العشر هنا تشبه الضوابط (الاستباقية).
هذا الدليل موجه للمطورين والمدققين والمهندسين المعماريين ومهندسي الأنظمة والشبكات. كما هو موضح أعلاه، يمكنك أيضًا استخدام هذا الدليل مع المقاولين الخارجيين لإضافة متطلبات تقنية رسمية إلى عقدك. كما ينبغي أن يكون لدى مسؤول أمن المعلومات بعض الاهتمام به أيضًا لتلبية متطلبات الأمن الأساسية وما يتجاوزها.
هذه النقاط العشر هي في معظمها (انظر أسفل هذه الفقرة) حول أمن الأنظمة والشبكات وهندسة الأنظمة والشبكات. وبصفتك مطورًا، لا يتعين عليك أن تكون خبيرًا في تلك المجالات -- فهذا هو الغرض من هذا الدليل. ولكن كما هو موضح أعلاه، من الأفضل البدء في التفكير في هذه النقاط ومعالجتها مبكرًا. من فضلك لا تبدأ في البناء فحسب.
ويجب ألا يُساء فهم إحدى النقاط العشر: إدارة التصحيحات ليست نقطة تقنية. إنها عملية إدارية. وأخيرًا وليس آخرًا، بالنسبة للإدارة التقنية أو إدارة أمن المعلومات التي لم تكن قلقة كثيرًا بشأن الحاويات، يقدم هذا المستند أيضًا رؤى حول المخاطر التي تنطوي عليها.
غالبًا ما يبدو أن الأمن في بيئات Docker يساء فهمه. كانت/لا تزال مسألة ما يُفترض أن تكون عليه التهديدات محل خلاف كبير. لذا قبل الغوص في نقاط Docker Top 10، يجب نمذجة التهديدات، وهذا ما يحدث في بداية هذا المستند. إنه لا يساعد فقط في فهم أي تأثيرات أمنية، بل يمنحك أيضًا القدرة على تحديد أولويات مهامك.
يرجى الاطلاع على CONTRIBUTING.md. ولتسهيل المساهمات في النقاط المفتوحة، يرجى تقديم طلبات السحب (PRs) الخاصة بك إلى فروع التطوير المقابلة (D06_dev, D07_dev, ...).
يمكنك بناء نسخة PDF بنفسك طالما كان لديك Docker و docker-compose مثبتين.
docker-compose run --rm build
لا يتم تحديثها بشكل متكرر في هذا المستودع لأنها بخلاف ذلك تسد هذا المستودع.
على الرغم من أن اسم هذا المشروع يحمل كلمة "Docker"، إلا أنه يمكن استخدامه أيضًا مع قدر ضئيل من التجريد لحلول الحاويات الأخرى. Docker هو حاليًا الأكثر شيوعًا، لذلك تركز التفاصيل المتعمقة في الوقت الحالي على Docker. وقد يتغير هذا لاحقًا.
إذا كنت تشغّل أكثر من 3 حاويات على خادم، فمن المحتمل أن يكون لديك حل تنسيق لإدارتها. المزالق الأمنية المحددة لمثل هذه الأداة هي حاليًا خارج نطاق هذا المستند. هذا لا يعني أن هذا الدليل يهتم فقط بحاوية واحدة أو بضع حاويات تُدار يدويًا -- بل على العكس. إنه يعني فقط أننا ننظر إلى الحاويات بما في ذلك شبكاتها وأنظمتها المضيفة في مثل هذه البيئة المُنسَّقة، وليس إلى المزالق الخاصة مثل Kubernetes أو Swarm أو Rancher أو OKD/OpenShift.
بصراحة، بالنسبة لنا نحن البشر، يبدو الرقم 10 جذابًا، وعند تجميع كل ذلك معًا، اعتُبرت هذه النقاط العشر هي الأكثر أهمية.