تواجه مجموعات Kubernetes محاولات اختبار خلال 18 دقيقة من النشر. تم تصميم OpenShift للتعامل مع ذلك – وهو معزز افتراضيًا، وسهل الامتثال، ومصمم للتشغيل في أي مكان بدءًا من السحابة العامة ووصولاً إلى مراكز البيانات المعزولة. لكن كون النظام الأساسي آمنًا لا يعني أن تكون بيئتك آمنة. تقع على عاتقك مسؤولية أعباء العمل والتكوينات والهويات والبيانات الخاصة بك. هذا هو نموذج المسؤولية المشتركة، وهو المكان الذي تعيش فيه معظم الفجوات الأمنية.
نموذج أمان موحد لـ OpenShift
غالبًا ما تضطر فرق الأمان المسؤولة عن تأمين OpenShift إلى تجميع منصة لإدارة الموقف، وأداة منفصلة للكشف عن وقت التشغيل، وأدوات امتثال مستقلة، وضوابط قبول مجزأة – مع عدم وجود رؤية موحدة لكيفية اتصال هذه المخاطر ببقية البنية التحتية الخاصة بهم.
إن تأمين الجانب الخاص بك من نموذج المسؤولية المشتركة يعني التمتع بالرؤية قبل نشر عبء العمل، أثناء تشغيله، وعبر كل بيئة يلامسها – من السحابة إلى المعدن العاري إلى الهواء المفرغ.
يتعامل Wiz مع أمان OpenShift باعتباره دورة حياة مستمرة:
-
رسم خرائط لبنية Kubernetes والعلاقات السحابية
-
التحقق المستمر من الموقف والامتثال
-
منع أعباء العمل غير الآمنة قبل وصولها إلى الإنتاج
-
اكتشاف التهديدات في الوقت الفعلي عند ظهورها
يتم تغذية كل إشارة في الرسم البياني للأمان والتحقيق الخاص بـ Wiz، لذا بدلاً من ربط إشارات OpenShift عبر الأدوات غير المتصلة، يحصل فريقك على عرض سياقي واحد للمخاطر والتهديدات عبر بيئة OpenShift بأكملها.
يبدأ أمان Kubernetes وOpenShift بفهم كيفية اتصال كل شيء – ما هي أحمال العمل التي لها أذونات زائدة، وما هي الهويات التي لها مسارات إلى الموارد السحابية، وما هي تكوينات الدخول التي تعرض الخدمات إلى الإنترنت. بدون هذه الخريطة، أنت لا تدير المخاطر، بل تخمنها.
تقوم Wiz Kubernetes Connectors باستجواب Kubernetes وOpenShift APIs بشكل مستمر لإنشاء تلك الخريطة، وتغذية البيانات التعريفية مباشرة في Wiz Security Graph. بالنسبة لبيئات OpenShift المُدارة ذاتيًا – سواء كانت تعمل على VMware أو بنية أساسية غير معدنية أو غير متصلة – تقوم Wiz بتصميم كل مجموعة ككيان من الدرجة الأولى، مما يجعل من الممكن رؤية مدى ارتباط أعباء عمل OpenShift الخاصة بك بالهويات السحابية، والتعرض للإنترنت، والحزم الضعيفة، ومسارات الهجوم المحتملة. يتضمن ذلك فرص الحركة الجانبية التي تمتد عبر البنية التحتية المختلطة ولن تظهر أبدًا في أداة لا ترى سوى بيئة واحدة في كل مرة.
والنتيجة هي مخزون موحد ورؤية المخاطر عبر بصمة OpenShift وKubernetes بالكامل – وليس عرضًا منعزلاً لمجموعاتك، ولكن صورة كاملة لكيفية اتصالها بكل شيء آخر.
يقوم Wiz بتوسيع التغطية الأمنية لبيئات OpenShift المحلية والمختلطة من خلال Wiz Runtime Sensor وSensor Workload Scanner – التقييم المستمر لأحمال العمل الجارية بحثًا عن نقاط الضعف والبرامج الضارة والأسرار المكشوفة والبيانات الحساسة والتكوينات الخاطئة للمضيف. وهذا أمر يتجاوز المجموعة نفسها: إن عبء عمل OpenShift المحلي الذي يقوم بتخزين بيانات اعتماد AWS أو مفاتيح API السحابية لا يمثل مجرد خطر محلي، بل هو مسار حركة جانبي لبيئتك السحابية.
يتم تغذية كل نتيجة في نفس العرض الموحد للمخاطر – لذا سواء كان التهديد ينشأ في السحابة أو في مجموعة OpenShift المحلية، يرى فريقك الصورة الكاملة في مكان واحد.
لا يقتصر أمان OpenShift الحديث على اكتشاف التهديدات بعد نشر أحمال العمل فحسب – بل يتعلق أيضًا بالتحقق المستمر من تكوين المجموعات وفقًا لأفضل ممارسات الأمان قبل أن تتحقق تلك التهديدات. لكن معظم أدوات الامتثال تتعامل مع هذا باعتباره سير عمل تدقيق منفصلاً، منفصلاً عن صورة المخاطر الفعلية.
تقوم Wiz KSPM بتقييم بيئات Kubernetes وOpenShift بشكل مستمر مقابل أطر الأمان ومعايير الامتثال – بما في ذلك CIS Red Hat OpenShift Container Platform Benchmark وPCI DSS وSOC 2 وHIPAA وNIST – لتحديد التكوينات الخطرة وعلاقات RBAC الضعيفة ومسارات تصعيد الامتيازات والخدمات المكشوفة وانجراف التكوين عند حدوثها. بالنسبة لعملاء OpenShift الذين يعملون في الصناعات المنظمة، فإن هذا يعني التحقق المستمر من صحة الأطر الأكثر أهمية لأعمالهم، وليس مجرد لقطة في وقت محدد.
ما يجعل هذا مختلفًا هو السياق. تصبح سياسة RBAC التي تم تكوينها بشكل خاطئ أكثر خطورة بشكل ملحوظ عندما يتم دمجها مع التعرض الداخلي ومسار الحركة الجانبية إلى بيانات الاعتماد السحابية – وهذا هو بالضبط نوع المخاطر المجمعة التي تظهر على Wiz، مما يساعد الفرق على تجاوز الامتثال لقائمة التحقق (وهو أمر مطلوب) وتحديد أولويات المخاطر لإصلاح ما يمكن استغلاله.
يساعد التحليل المستمر للمخاطر لبيئات الإنتاج لديك فرق إدارة الأمن السحابي وإدارة الثغرات الأمنية على تحديد أولويات مسارات الهجوم الأكثر أهمية – ولكن أفضل وقت للتعامل مع عبء العمل غير الآمن هو قبل أن يصل إلى مرحلة الإنتاج. وهنا يأتي دور وحدة تحكم القبول Wiz (AC).
تقوم وحدة التحكم في القبول Wiz بفرض سياسات أمان Kubernetes وOpenShift مركزيًا باستخدام خطافات القبول على الويب، مما يمنح الفرق القدرة على إدارة عمليات النشر بشكل استباقي قبل قبول أعباء العمل في المجموعات. وهذا يعني أن الصور من السجلات الموثوقة فقط هي التي يمكنها المرور، ويتم حظر الحاويات المميزة وأحمال العمل التي تعمل بنظام الجذر عند البوابة، والبودات بدون حدود للموارد أو غير مناسبة NodePort يتم اكتشاف التعرض قبل أن يصبح مشكلة.
بالنسبة لأمان سلسلة توريد البرامج، يضمن Wiz AC نقل الصور الموثوقة والمتحقق منها فقط من خطوط أنابيب CI/CD إلى الإنتاج – مع توسيع تطبيق السياسة عبر بيانات Kubernetes ومخططات Helm وملفات Dockerfiles. يعد هذا ذا قيمة خاصة في بيئات OpenShift التي تقوم بتشغيل مجموعات متعددة المستأجرين، وسير عمل GitOps، وفرق هندسة النظام الأساسي المشتركة، حيث يمكن أن يكون لعبء عمل واحد غير آمن تأثير كبير عبر البيئة.
يعد Wiz Runtime Sensor عبارة عن مستشعر خفيف الوزن يوفر رؤية عميقة في وقت التشغيل مع الحد الأدنى من الحمل التشغيلي – مراقبة العمليات الجارية، واتصالات الشبكة، ونشاط الملفات، ومكالمات النظام، وتنفيذ الحاويات، وسلوك العملية المشبوهة عبر Kubernetes، وOpenShift، ومضيفي Linux، والبنية التحتية المختلطة.
عندما يتم اكتشاف تهديد، لا يقوم Wiz فقط بالتحذير، بل يقوم بالتحقيق. يجمع تطبيق Wiz’s Forensics بين قياس وقت التشغيل عن بعد، ونسب العملية، وسياق Kubernetes، والعلاقات السحابية في قصة موحدة، بحيث يمكن لمحللي SOC وفرق IR أن يفهموا بالضبط كيف تم الكشف عن الهجوم دون الاضطرار إلى تجميع التنبيهات المعزولة معًا عبر الأدوات يدويًا.
على سبيل المثال، لنأخذ عبء عمل OpenShift المميز الذي نفذ عمليات nsenter وchroot للتفاعل مع مساحات أسماء المضيف – وهو نشاط يرتبط عادةً بمحاولات الهروب من الحاوية وتصعيد الامتيازات وتسوية العقدة. يقوم Wiz Runtime Sensor على الفور بإنشاء اكتشاف مهم لوقت التشغيل، وربط تنفيذ العملية، ومستوى امتياز الحاوية، وسياق عمل Kubernetes، وعلاقات عقدة OpenShift في تحقيق واحد.
يقدم OpenShift اعتبارات أمنية إضافية غالبًا ما لا يتم تصميم أدوات kubernetes العامة للتعامل معها. تفرض قيود سياق الأمان (SCC) – وخاصة قيود SCC الافتراضية المقيدة بالإصدار الثاني – التنفيذ غير الجذري، وتمنع تصعيد الامتيازات، وتقييد وصول المضيف عبر جميع أحمال العمل، بما في ذلك أدوات الأمان التي تنشرها. تضيف نطاقات UID الخاصة بمساحة الاسم، والتي تم تعيينها عبر openshift.io/sa.scc.uid-range، طبقة أخرى من التكوين التي يجب أن تتوافق مع متطلبات النشر.
تم تصميم Wiz مع وضع هذه القيود الخاصة بـ OpenShift في الاعتبار. يدعم كل من Kubernetes Connector، وRuntime Sensor، وAdmission Controller، وSensor-Based Workload Scanner نماذج النشر المدركة لـ OpenShift عبر عمليات نشر Helm الموحدة – مما يسمح للمؤسسات بالانضمام بشكل آمن مع البقاء متوافقًا تمامًا مع متطلبات OpenShift التشغيلية والأمنية.
لا يتطلب تأمين الجانب الخاص بك من نموذج المسؤولية المشتركة OpenShift أداة مختلفة لكل بيئة تقوم بتشغيلها. يجمع Wiz بين رؤية kubernetes، وإدارة الوضع المستمر، والتحكم في القبول، وحماية وقت التشغيل، والتحقيقات المدعومة بالذكاء الاصطناعي في سير عمل تشغيلي واحد – يغطي عمليات نشر OpenShift السحابية والهجينة والمعدنية والحافة والمزودة بفجوات هوائية من منصة واحدة.
إذا كنت تقوم بتشغيل OpenShift وكنت أحد عملاء Wiz على متن بيئة OpenShift الخاصة بك في Wiz اليوم، وإذا كنت مهتمًا بالعرض التوضيحي لكيفية مساعدة Wiz في تأمين بيئة OpenShift الخاصة بك، فقم بجدولة عرض توضيحي اليوم.
