ملاحظة perev. : تم نشر أصل هذه المقالة على مدونة Kubernetes الرسمية وكتبها أندرو مارتن ، أحد مؤسسي شركة Control Plane البريطانية الشابة المتخصصة في أمن التطبيقات السحابية الأصلية التي تعمل على K8s.
لقد قطع الأمن في Kubernetes شوطا طويلا منذ وصول المشروع ، لكن المزالق لا تزال تحدث. نقدم قائمة من التوصيات المفيدة حول كيفية حماية المجموعات وزيادة استقرارها في حالة القرصنة: سنبدأ بمستوى التحكم ، ونستمر في أعباء العمل وأمن الشبكة ، وننتهي بتقييم للأمن المستقبلي.
الجزء الأول: طائرة التحكم
طائرة التحكم هي دماغ Kubernetes. لديه فكرة عامة عن كل حاوية وجراب يعمل في المجموعة ، ويمكنه تخطيط القرون الجديدة (التي يمكن أن تحتوي على حاويات مع وصول الجذر إلى العقد الأصلية) ، ويمكنه قراءة جميع الأسرار المخزنة في المجموعة. يعد هذا مكونًا مهمًا جدًا يحتاج إلى حماية مستمرة ضد تسرب البيانات غير المقصود والإجراءات الضارة: سواء عند الوصول إليه أو عندما لا يحدث أي شيء وعندما يتم نقل البيانات عبر الشبكة.
1. TLS في كل مكان
لكل مكون يدعم TLS ، يجب تمكينه - لمنع استنشاق حركة المرور والتحقق من هوية الخادم والتحقق من هوية العميل (في حالة Mutual TLS)."يرجى ملاحظة أن بعض المكونات وطرق التثبيت قد تنشط المنافذ المحلية لـ HTTP ، لذا يحتاج المسؤولون إلى التعرف على إعدادات كل مكون لتحديد المسارات المحتملة لحركة المرور غير الآمنة".
من وثائق Kubernetes
يوضح الرسم التخطيطي للشبكة أدناه من
Lucas Käldström المكان الذي تحتاج إليه TLS بشكل مثالي: بين كل مكون في المعالج ، وبين Kubelet وخادم API. تقدم
Kelsey Hightower Kubernetes The Hard Way الكلاسيكية
ووثائق الأمان على etcd تعليمات مفصلة لتحقيق هذه الأهداف.
تاريخيا ، لم يكن التحجيم التلقائي لعقد Kubernetes سهلاً ، لأن كل عقدة تتطلب مفتاح TLS للاتصال بالسيد ، وحفظ الأسرار في الصور الأساسية هو ممارسة سيئة. يسمح
Kubelet TLS bootstrapping الجديد لـ Kubelet بإنشاء طلب توقيع شهادة بحيث يتم إنشاء الشهادات في وقت التمهيد:
2. الحد الأدنى من الامتيازات في RBAC ، وتعطيل ABAC ، ومراقبة السجل
يوفر التحكم في الوصول المستند إلى الأدوار (RBAC) إدارة سياسات دقيقة يتم من خلالها وصول المستخدمين إلى الموارد مثل مساحات الأسماء.
تم استبدال التحكم في الوصول المستند إلى السمة (ABAC) في Kubernetes بـ RBAC منذ K8s 1.6 ولا يجب تمكينه على جانب الخادم من API. استخدم RBAC بدلاً من ذلك:
--authorization-mode=RBAC (أو هذه العلامة لـ GKE:
--authorization-mode=RBAC ).
هناك العديد
من الأمثلة الجيدة لسياسات RBAC للخدمات المختلفة في مجموعة ، وكذلك
الوثائق . ولكن لا تتوقف عند هذا الحد: يمكن الحصول على الإعدادات المختصة لسياسات RBAC باستخدام
Audit2rbac من سجلات
audit .
سياسات RBAC غير الصحيحة أو المفرطة هي خطر أمني إذا تم اختراق الموقد. يجب أن يكون الحفاظ على قواعد RBAC مع الحد الأدنى من الامتيازات ، ومراجعتها باستمرار ، وتحسينها جزءًا من "النظافة الفنية للديون" التي تطبقها الفرق في دورة حياة التطوير.
يوفر تسجيل التدقيق (بيتا في Kubernetes 1.10) واجهة برمجة تطبيقات تسجيل مخصصة لأحمال العمل (مثل الطلب والاستجابة) وعلى مستوى البيانات الوصفية. يمكن تكوين مستوى التسجيل وفقًا لسياسة أمان المؤسسة - يطبق
GKE قيمًا افتراضية معقولة لأولئك الذين بدأوا للتو في العمل معها.
بالنسبة لطلبات القراءة مثل
get و
list و
watch ، يتم تخزين الكائن المطلوب فقط في سجلات التدقيق ، بدون كائن استجابة. للاستعلامات التي تتضمن بيانات حساسة مثل
Secret أو
ConfigMap ، يتم تصدير بيانات التعريف فقط. بالنسبة لجميع الطلبات الأخرى ، يتم تسجيل كلا الجسمين في سجلات التدقيق: كلا من الطلب والاستجابة.
لا تنس: إن تخزين هذه السجلات داخل الكتلة يمثل خطرًا أمنيًا في حالة حدوث تسوية. يجب وضع هذه السجلات ، مثل أي سجلات أخرى حساسة للأمان ، خارج المجموعة لتجنب العواقب السلبية في حالة الضعف.
3. استخدم مصادقة الطرف الثالث لخادم API
تساعد مركزية المصادقة والتفويض للمؤسسة بأكملها (أي الدخول الموحد) في عمليات قبول الموظفين الجدد وتركهم ، وضمان حقوق وصول متسقة.يوفر تكامل Kubernetes مع موفري المصادقة من جهات خارجية (مثل Google أو GitHub) ضمانات للهوية من نظام أساسي بعيد (مع حماية مثل المصادقة الثنائية) ويزيل الحاجة إلى المسؤولين لإعادة تكوين خادم API في Kubernetes لإضافة / إزالة المستخدمين.
Dex هو OpenID Connect Identity (OIDC) وموفر OAuth 2.0 مع المكونات الإضافية. ذهب Pusher إلى أبعد من ذلك من خلال توفير
أدوات قابلة للتخصيص ، بالإضافة إلى وجود
بعض المساعدين
الآخرين الذين يركزون على التطبيقات الأخرى.
4. افصل وضع المجموعة الخاصة بك خلف جدار الحماية
يخزن etcd معلومات عن حالة Kubernetes وأسراره ، وهو عنصر حاسم في K8s - يجب حمايته بشكل منفصل عن بقية المجموعة.حق الوصول للكتابة إلى etcd في خادم API يعادل إصدار حقوق الجذر إلى المجموعة بأكملها ، ويمكن حتى الوصول إلى القراءة بسهولة لتصعيد الامتيازات.
تقوم أداة جدولة Kubernetes في بحث etcd بتعريفات الجراب التي لا تحتوي على عقدة. ثم يرسل جميع القرون الموجودة إلى Kubelet المتاحة للتخطيط. يتم التحقق من هذه الأقراص من قبل خادم API قبل كتابتها إلى etcd ، لذلك يمكن للمهاجمين الذين يكتبون مباشرة إلى etcd تجاوز العديد من آليات الأمان - على سبيل المثال ،
PodSecurityPolicies .
ينبغي تكوين etcd باستخدام
كل من شهادات TLS (
العميل والنظير ) ونشرها في العقد المخصصة. للحد من مخاطر السرقة واستخدام المفاتيح الخاصة من عقد العمل ، يمكنك أيضًا تحديد جدار الحماية لمجموعة خادم API.
5. تناوب مفاتيح التشفير
التدوير المنتظم لمفاتيح وشهادات الأمان هو أفضل ممارسة أمنية تسمح لك بتحديد "نصف قطر التدمير" عند اختراق المفتاح.ستقوم Kubernetes
تلقائيًا بتدوير بعض الشهادات (على وجه الخصوص ، شهادات Kubelet للعميل والخادم) من خلال إنشاء CSR جديدة بعد انتهاء صلاحية الشهادات الحالية.
ومع ذلك ، فإن
المفاتيح المتماثلة المستخدمة من قبل خادم API لتشفير قيم etcd لا يتم تدويرها تلقائيًا - يجب
القيام بذلك يدويًا . تتطلب هذه العملية وصولاً رئيسيًا ، لذلك تخفي الخدمات المُدارة (مثل GKE و AKS) المشكلة عن المستخدم.
الجزء 2: أعباء العمل
مع الحد الأدنى من الأمان على مستوى مستوى التحكم ، يمكن أن تعمل المجموعة بالفعل بأمان. ومع ذلك ، كما هو الحال مع السفينة التي يحتمل أن تكون خطرة ، يجب على حاويات هذه السفينة حماية البضائع في حالة وقوع حادث أو تسرب غير متوقع. وينطبق الشيء نفسه على أعباء عمل Kubernetes (Pods ،
Deployments ،
Jobs ،
Sets ، إلخ) - يمكن الوثوق بها في وقت النشر ، ولكن إذا كان الوصول إليها من الخارج ، فهناك دائمًا خطر أن يتم استغلالهم لاحقًا من قبل [المهاجمين]. يمكن تخفيف هذا الخطر من خلال تشغيل أعباء العمل مع الحد الأدنى من الامتيازات وتكوينها الآمن.
6. استخدام ميزات أمان Linux و PodSecurityPolicies
يحتوي Linux kernel على العديد من ملحقات الأمان المتداخلة جزئيًا (الإمكانيات ، SELinux ، AppArmor ، seccomp-bpf) التي يمكن تكوينها لمنح التطبيقات الحد الأدنى من الامتيازات.ستساعدك الأدوات المساعدة مثل
bane في إنشاء ملفات تعريف لـ AppArmor ، وسيساعدك docker
-slim في إنشاء ملفات تعريف seccomp ، ولكن كن حذرًا: لتحديد جميع الآثار الجانبية لتطبيق هذه السياسات ، تحتاج إلى مجموعة شاملة من الاختبارات للتحقق من جميع رموز التطبيق.
تحكم
PodSecurityPolicies استخدام ملحقات الأمان هذه ، بالإضافة إلى توجيهات أمان Kubernetes الأخرى. هم مسؤولون عن الحد الأدنى من المتطلبات التي يجب استيفاؤها للوصول إلى خادم API ، بما في ذلك ملفات تعريف الأمان ، وعلامة الامتياز ، وشبكة المضيف المشتركة ، والعمليات أو مساحات الأسماء لـ IPC.
هذه التوجيهات مهمة لأنها تساعد في منع العمليات الحاوية من الفرار من حدودها المعزولة.
مثال PodSecurityPolicy من Tim Allclair متعدد الاستخدامات للغاية - يمكنك أخذه كأساس وتخصيصه
لحالتك .
7. إجراء تحليل ثابت ل YAML
إذا كان PodSecurityPolicies يقيد الوصول إلى خادم API ، فيمكن أيضًا استخدام التحليل الثابت في عملية التطوير لنمذجة المتطلبات التنظيمية للمؤسسة والرغبة في المخاطرة.لا يجب تخزين المعلومات الحساسة في موارد YAML مثل المداخن (
Pods و
Deployments و
Sets وما إلى ذلك) ، ويجب تشفير
ConfigMaps والأسرار الحساسة باستخدام أدوات مثل
Vault (مع مشغل من CoreOS) أو
git-crypt أو sealing أو
KMS cloud مزود .
يمكن استخدام التحليل الثابت لتكوين YAML كأساس للأمان أثناء بدء التشغيل. يولد
kubesec تقييمات مخاطر للموارد:
{ "score": -30, "scoring": { "critical": [{ "selector": "containers[] .securityContext .privileged == true", "reason": "Privileged containers can allow almost completely unrestricted host access" }], "advise": [{ "selector": "containers[] .securityContext .runAsNonRoot == true", "reason": "Force the running image to run as a non-root user to ensure least privilege" }, { "selector": "containers[] .securityContext .capabilities .drop", "reason": "Reducing kernel capabilities available to a container limits its attack surface", "href": "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" }] } }
و
kubetest هو إطار عمل لاختبار وحدة تكوينات Kubernetes:
#
تقوم هذه الأدوات بتنفيذ نهج
التحول الأيسر (أي أنها تنقل المصادقة والتحقق إلى المراحل الأولى من دورة التطوير). يوفر اختبار الأمان في مرحلة التطوير للمستخدمين ملاحظات سريعة حول الكود والتكوين ، والتي يمكن رفضها لاحقًا عن طريق التحقق اليدوي أو الآلي ، ويمكن أيضًا تسهيل إدخال ممارسات أمان إضافية.
8. تشغيل الحاويات لا الجذر
غالبًا ما يكون للحاويات التي تعمل كجذر حقوق أكثر بكثير مما تتطلبه أعباء عملها ، وإذا تم اختراقها ، فإنها تساعد المهاجمين على تحقيق قدرات كبيرة.لا تزال الحاويات تعتمد على نموذج أمان UNIX التقليدي (يسمى DAC ،
التحكم في الوصول التقديري ) - كل شيء هو ملف ، ويتم منح الحقوق للمستخدمين والمجموعات.
لا تعمل مساحات أسماء المستخدمين في Kubernetes. هذا يعني أن جدول معرف المستخدم في الحاوية تم تعيينه إلى جدول المستخدم المضيف ، وبدء العملية بامتيازات الجذر داخل الحاوية يتسبب في تشغيله بامتيازات الجذر على المضيف. على الرغم من إضافة آليات إلى كل هذا لمنع الخروج من الحاوية ، إلا أنه لا يوصى بالتشغيل كجذر داخل الحاوية.
تستخدم العديد من صور الحاوية المستخدم الجذر لتشغيل PID 1: إذا تم اختراق هذه العملية ، يصبح المهاجم متجذرًا في الحاوية ، ومع أي خطأ في التكوين ، يصبح تشغيل المشكلة أسهل بكثير.
قام Bitnami
بعمل رائع في ترجمة صور الحاويات الخاصة به إلى المستخدمين
العاديين (غير الجذر) (وهو أيضًا متطلبات OpenShift الافتراضية) ، والتي يمكن أن تبسط عملية الترحيل إلى الصور غير الجذر أيضًا.
يمنع جزء PodSecurityPolicy عمليات الجذر من التشغيل في الحاوية والتصعيد إلى الجذر:
# Required to prevent escalations to root. allowPrivilegeEscalation: false runAsUser: # Require the container to run without root privileges. rule: 'MustRunAsNonRoot'
لا يمكن للحاويات التي لا تستخدم الجذر أن تشغل المنافذ ذات الامتيازات ، أي حتى 1024 (الإمكانية المقابلة في نواة Linux -
CAP_NET_BIND_SERVICE مسؤولة عن ذلك) ، ومع ذلك ، فإن استخدام
الخدمات يساعد على التحايل على هذا القيد. في ما يلي مثال لتطبيق MyApp ، الذي يشغل المنفذ 8443 في الحاوية ، لكن
الخدمة تجعله متاحًا على المنفذ 443 ، طلبات
targetPort لـ
targetPort :
kind: Service apiVersion: v1 metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 443 targetPort: 8443
ستظل الحاجة إلى تشغيل أحمال العمل بدون استخدام الجذر حتى يتم تضمين مساحة اسم المستخدم أو
وقت التشغيل لإطلاق حاويات بدون جذر في وقت تشغيل الحاوية.
9. استخدام سياسات الشبكة
بشكل افتراضي ، تسمح شبكة Kubernetes لجميع حركة المرور بين القرون. يمكن تقييد هذا الإعداد من خلال سياسة الشبكة - NetworkPolicy .
تقتصر الخدمات التقليدية على جدران الحماية باستخدام عناوين IP الثابتة ونطاقات المنافذ لكل خدمة. نظرًا لأن عناوين IP هذه تتغير نادرًا جدًا ، فقد تم استخدامها تاريخيًا كشكل من أشكال المصادقة. نادرًا ما تحتوي الحاويات على عناوين IP ثابتة - تشير طبيعتها إلى إمكانية السقوط السريع وإعادة الإنشاء ، حيث يتم استخدام اكتشاف الخدمة بدلاً من عناوين IP الثابتة. تعقد هذه الميزات بشكل كبير التكوين والتحقق من جدران الحماية.
نظرًا لأن Kubernetes يخزن جميع البيانات حول حالة النظام في etcd ، فمن الممكن تكوين جدار حماية ديناميكي - إذا كان هناك الدعم اللازم في المكون الإضافي لشبكة CNI. Calico و Cilium و kube-router و Romana و Weave Net - تدعم جميع هذه المكونات الإضافية سياسات الشبكة.
من المهم أن نلاحظ أن السياسات تعمل على مبدأ الفشل المغلق ، أي أن غياب
podSelector هنا بشكل افتراضي يساوي جميع القيم الممكنة (حرف البدل):
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny spec: podSelector:
فيما يلي مثال على
NetworkPolicy ، الذي يمنع كل شيء من الخروج باستثناء UDP 53 (DNS) ، والذي يمنع أيضًا الاتصالات الواردة للتطبيق. سياسات
الشبكة هي سياسات
رسمية ، لذلك سيستمر التطبيق في تلقي ردود على الاتصالات الصادرة.
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: myapp-deny-external-egress spec: podSelector: matchLabels: app: myapp policyTypes: - Egress egress: - ports: - port: 53 protocol: UDP - to: - namespaceSelector: {}
لا يمكن تطبيق سياسات شبكة Kubernetes على أسماء DNS. والسبب هو أن DNS يدعم خاصية التوجيه المستدير لعناوين IP متعددة واستجابات ديناميكية تعتمد على الوصول إلى IP ، لذلك تنطبق سياسات الشبكة فقط على عناوين IP الثابتة أو
podSelector (لعناوين IP الديناميكية Kubernetes).
أفضل الممارسات هي البدء بحظر جميع حركة المرور لمساحة الاسم وخطوة خطوة بخطوة بإضافة المسارات التي يتطلبها التطبيق لاجتياز اختبار القبول. يمكن أن تكون العملية صعبة ، لذلك طورت ControlPlane
netassert ، وهي أداة لاختبار أمان الشبكة في نصوص DevSecOps ذات nmap متوازية للغاية:
k8s: # used for Kubernetes pods deployment: # only deployments currently supported test-frontend: # pod name, defaults to `default` namespace test-microservice: 80 # `test-microservice` is the DNS name of the target service test-database: -80 # `test-frontend` should not be able to access test-database's port 80 169.254.169.254: -80, -443 # AWS metadata API metadata.google.internal: -80, -443 # GCP metadata API new-namespace:test-microservice: # `new-namespace` is the namespace name test-database.new-namespace: 80 # longer DNS names can be used for other namespaces test-frontend.default: 80 169.254.169.254: -80, -443 # AWS metadata API metadata.google.internal: -80, -443 # GCP metadata API
تُعد واجهة برمجة التطبيقات التي تحتوي على بيانات وصفية من موفر السحابة مصدرًا ثابتًا للتصعيد المحتمل (
كما هو موضح في مكافأة الأخطاء الأخيرة
من Shopify ) ، لذا فإن الاختبارات الخاصة التي تؤكد حظر واجهة برمجة التطبيقات على شبكة الحاويات ستساعد في الحماية من أخطاء التكوين.
10. مسح الصور وتشغيل IDS
خوادم الويب هي نقطة انطلاق لمهاجمة الشبكات التي ترتبط بها. يتيح لك فحص الملفات المثبتة في الصور التحقق من عدم وجود ثغرات معروفة يمكن للمهاجم استخدامها للوصول إلى الحاوية عن بُعد. تسجل أنظمة كشف التسلل (IDS) هذه الأحداث إذا حدثت.تسمح Kubernetes بالإرسال إلى المجموعة من خلال مجموعة من فحوصات التحكم (في
وحدة التحكم في
القبول ) ، والتي لا تنطبق فقط على القرون ، ولكن أيضًا على الموارد الأخرى مثل عمليات
النشر . فيها ، يمكن التحقق من صحة كل قسم فرعي للقبول أو يمكن تغيير محتوياته ، بالإضافة إلى دعم عمليات الرد على الويب على الجانب الخلفي الآن.
يمكن استخدام أدوات التتبع عبر الويب هذه بواسطة أدوات مسح صورة الحاوية للتحقق من الصور قبل نشرها في المجموعة. لن تتلقى الصور التي تفشل في التحقق موافقة وحدة التحكم.
يساعد فحص صور الحاوية بحثًا عن الثغرات الأمنية المعروفة على تقليل الوقت الذي يمكن للمهاجم من خلاله الاستفادة من CVE المفتوح. لمنع نشر الصور مع نقاط الضعف الحرجة في خط أنابيب النشر ، يمكنك استخدام أدوات مساعدة مجانية مثل
Clair من CoreOS و
Micro Scanner من Aqua.
تسمح لك أدوات مثل
Grafeas بتخزين البيانات الوصفية للصور للتحقق المستمر من الامتثال والتحقق من الثغرات باستخدام توقيع حاوية فريد (أو تجزئة
معالجة المحتوى الخاصة). مسح صورة حاوية باستخدام هذا التجزئة هو بمثابة مسح للصور المنشورة في الإنتاج ويمكن إجراؤه بشكل مستمر دون الحاجة إلى الوصول إلى بيئات الإنتاج.
ستكون ثغرات يوم 0 غير معروفة موجودة دائمًا ، لذلك يجب على Kubernetes نشر نظام كشف التسلل مثل
Twistlock أو
Aqua أو
Sysdig Secure . يكشف IDS عن سلوك غير عادي في الحاوية ويوقفها أو يقتلها.
Sysdig's Falco هو محرك قاعدة مفتوح المصدر ونقطة انطلاق لهذا النظام البيئي.
الجزء الثالث: المستقبل
يبدو أن المرحلة التالية من الأمن في "التطور الأصلي السحابي" هي شبكة الخدمة ، على الرغم من أن اعتمادها لن يحدث على الفور: يتطلب هذا الترحيل تحويل تعقيد التطبيقات إلى البنية التحتية للشبكة ، ويتعين على المنظمات تحقيق هذه أفضل الممارسات.
11. إطلاق شبكة الخدمة
شبكة الخدمة عبارة عن شبكة من الاتصالات المشفرة المستمرة التي يتم إجراؤها بين "متصلين جانبيًا" (على غرار "sidecar") ، وخوادم بروكسي عالية الأداء مثل Envoy و Linkerd. فهو يوفر إدارة المرور والمراقبة والسياسات - كل ذلك دون تغيير في الخدمات الدقيقة.كان نقل الأمان والرمز المرتبط بالشبكة من الخدمات المصغرة إلى مجموعة مكتبة مشتركة تم اختبارها في المعركة ممكنًا بالفعل مع
Linkerd ، وقدّم ظهور
Istio من Google و IBM و Lyft بديلاً لهذه المساحة. مع إضافة
SPIFFE لهوية التشفير لكل جراب والعديد من الميزات الأخرى ، يمكن لـ Istio تبسيط نشر أمان الشبكة من الجيل التالي.
في شبكات "الثقة صفر" ، قد لا تكون هناك حاجة لجدار حماية تقليدي أو سياسات شبكة Kubernetes ، حيث يحدث كل تفاعل باستخدام mTLS (TLS المتبادل) ، والذي لا يضمن فقط أمان التفاعل ، ولكنه يؤكد أيضًا هوية كلتا الخدمتين .
لن يكون هذا التحول من أساليب الشبكات التقليدية إلى مبادئ الأمان في Cloud Native أمرًا سهلاً لمن لديهم عقلية أمنية تقليدية. كمقدمة لهذا العالم الجديد ، نوصي بشدة
بكتاب Zero Trust Networking للكاتب
Evan Gilman من SPIFFE.
يتوفر Istio 0.8 LTS حاليًا ، ويقترب المشروع بسرعة من إصدار 1.0. يتم تنفيذ إصدار المشروع من حيث الاستقرار بشكل مشابه لنموذج Kubernetes: نواة مستقرة مع واجهات برمجة تطبيقات منفصلة يشار إليها بحالة ألفا أو بيتا باستخدام مساحات الأسماء. نتوقع رؤية Istio تتوسع في الأشهر القادمة.
الخلاصة
تحتوي تطبيقات Cloud Native على مجموعة أكثر تفصيلاً من بدائل الأمان خفيفة الوزن التي تساعد على حماية أعباء العمل والبنية التحتية. إن قوة ومرونة هذه الأدوات هي نعمة ونقمة على حد سواء: بدون أتمتة كافية [لاستخدامها] ، أصبح كشف التطبيقات غير الآمنة التي تسمح لها بتجاوز الحاوية أو أصبح نموذج عزلها أسهل.
يمكن الوصول إلى الأدوات المساعدة للحماية أكثر من أي وقت مضى ، ومع ذلك ، للحد من احتمال الهجوم واحتمال التكوينات غير الصحيحة ، يجب عليك استخدامها بحذر.
إذا أدى الأمن إلى إبطاء سرعة المؤسسة في إحداث التغيير ، فلن تكون الأولوية على الإطلاق. يسمح استخدام مبادئ التسليم المستمر فيما يتعلق بسلسلة توريد البرامج للمؤسسة بتحقيق الامتثال التنظيمي والتدقيق المستمر والإدارة المحسنة دون التأثير على أداء الأعمال.
يعد التحسين الأمني السريع والمتزايد أسهل طريقة باستخدام مجموعة اختبار شاملة. Continuous Security — pipeline', , , .
ملاحظة من المترجم
اقرأ أيضا في مدونتنا: