إضافة إدارة التصحيحات في GravityZone: تصحيحات Windows وmacOS وLinux من الوكيل نفسه ووحدة التحكم نفسها.
GravityZone Patch Management هي إضافة إدارة التصحيحات من Bitdefender. تفحص التصحيحات الأمنية وغير الأمنية وتنشرها بجدولة على أنظمة Windows وmacOS وCentOS وRed Hat Enterprise Linux وSUSE Linux Enterprise عبر وكيل GravityZone ووحدة تحكمه نفسها؛ وتوفّر خادم تخزين مؤقت للتصحيحات وخيار تجاهل التصحيحات (Ignore patches). وهي ليست افتراضية في أي حزمة GravityZone، بل تُرخَّص على حدة في كل فئة.
GravityZone Patch Management هي وحدة إدارة التصحيحات التي تُضاف إلى وكيل حماية نقاط النهاية من Bitdefender. تكتشف التصحيحات الناقصة في نظام التشغيل وتطبيقات الطرف الثالث عبر عمليات فحص مجدولة، وتنشر التصحيحات مركزيًا، وتضبط عملية النشر بالسياسة. ولا تتطلب وكيلًا منفصلًا ولا خادمًا منفصلًا ولا واجهة إدارة ثانية؛ إذ يتجمّع الجرد والاكتشاف والنشر في وحدة تحكم GravityZone نفسها.
وأكثر جوانب الوحدة التي يُساء فهمها هو الترخيص: Patch Management لا تأتي افتراضيًا في أي فئة من GravityZone. فهي مُدرجة كإضافة في صفحة المقارنة الرسمية لدى Bitdefender إلى جانب Full Disk Encryption وEmail Security وSecurity for Mobile وIntegrity Monitoring وContainer Security (Bitdefender، 2026). كما تُعرِّف وثائق Bitdefender TechZone الوحدة بأنها مكوّن إضافي يُركَّب على الأنظمة عبر إنشاء حزمة من وحدة تحكم GravityZone (Bitdefender TechZone، 2026).
ووجود إدارة التصحيحات داخل منتج أمني ليس صدفة. ففي تقرير The Forrester Wave: Endpoint Security, Q4 2023 جرى تقييم 13 مزوّدًا وفق 25 معيارًا؛ ووُضعت Bitdefender في موقع "Leader" ونالت أعلى درجة ممكنة في 10 معايير من بينها منع البرمجيات الخبيثة ومنع الاستغلال وحماية الهوية وكشف تهديدات الشبكة ومعالجة التصحيحات (Bitdefender، 2023). وتتولّى Sora Yazılım، بوصفها شريك قناة معتمدًا لدى Bitdefender، ترخيص الإضافة وتصميم حلقات النشر وبناء تقارير التدقيق بالتعاون معك؛ ويمكنك الاطلاع على عائلة المنتجات كاملةً في صفحة حلول Bitdefender لدينا.
الإجابة المختصرة: تجد التصحيحات الناقصة، وتتيح لك أن تقرر أي تصحيح يذهب إلى أين ومتى، وتُدير النشر مركزيًا. والوحدة ليست مقتصرة على التصحيحات الأمنية؛ إذ يمكن إدراج التصحيحات غير الأمنية ضمن النطاق أيضًا. وتُعرِّف Bitdefender TechZone الفارق بوضوح: تشمل التصحيحات الأمنية إصلاحات الثغرات وCVE، بينما تشمل التصحيحات غير الأمنية إصلاحات الأخطاء والوظائف الجديدة في تطبيقات الطرف الثالث (Bitdefender TechZone، 2026). وهذا التمييز مهم عمليًا: فبعض المؤسسات تفضّل تمرير التصحيحات الأمنية تلقائيًا وربط التحديثات الوظيفية بموافقة يدوية.
ويمكن تلخيص آلية العمل في أربع خطوات. الفحص: تُجرَد التصحيحات الناقصة على نقاط النهاية عبر مهام مجدولة ونوافذ صيانة (Maintenance Windows). القرار: تُحدَّد التصحيحات التي ستُنشَر بالسياسة؛ أما التصحيحات التي تسبب مشكلات أو غير المعتمدة داخل المؤسسة فتُستبعَد من الجرد ومن نطاق النشر عبر إجراء Ignore patches (تجاهل التصحيح) في وحدة التحكم. النشر: تُطبَّق التصحيحات في النوافذ المجدولة. التقارير: يُتابَع من وحدة التحكم أي جهاز على أي مستوى تصحيح. وتُنتج هذه الدورة إجابة قابلة للقياس عن السؤال الأكثر تكرارًا في عمليات التدقيق: "كم يستغرق إغلاق التصحيحات الحرجة؟"
وعلى صعيد عرض النطاق تستخدم الوحدة دور خادم التخزين المؤقت للتصحيحات (patch caching server). وتُعرِّف Bitdefender TechZone هذا المكوّن بأنه دور إضافي يُسرِّع النشر ويقلّل استهلاك عرض نطاق الإنترنت عبر الاحتفاظ بالتصحيحات المعنية كاملةً داخل الشبكة المحلية (Bitdefender TechZone، 2026). فتُنزَّل التصحيحات إلى نقطة واحدة وتحصل عليها نقاط النهاية من هناك؛ وبذلك لا يُسحَب الملف نفسه من الإنترنت مئات المرات. وعند تعذّر الوصول إلى خادم التخزين المؤقت تُنزّل الأنظمة التصحيحات مباشرةً من مواقع الشركات المصنّعة؛ أي إن انقطاع خادم التخزين المؤقت لا يوقف نشر التصحيحات كليًا لكنه يزيد حركة الإنترنت. وفي المؤسسات ذات البنية الفرعية المتفرقة يُعدّ موضع خادم التخزين المؤقت واحدًا من أكثر قرارات السعة ملموسيةً في المشروع.
لا تُدرَج في أيٍّ منها. فـPatch Management إضافة تُرخَّص على حدة في جميع الفئات، من Small Business Security حتى GravityZone Defense XDR. والمعلومة المتداولة كثيرًا على الإنترنت بأن "إدارة التصحيحات تأتي مشمولة إذا اشتريت Premium أو Enterprise" غير صحيحة. وبالمثل فعبارة "لا يمكن إضافة إدارة التصحيحات إلا إلى الفئات العليا" غير صحيحة أيضًا؛ إذ تظهر الإضافة تحت عنوان "تُشترى على حدة" في مقارنات الشركات الصغيرة والمؤسسات ومزوّدي الخدمات المُدارة الثلاث جميعها في صفحة المقارنة الرسمية (Bitdefender، 2026).
| المكوّن | هل هو مشمول في الفئة؟ | ملاحظات |
|---|---|---|
| Endpoint Risk Analytics (إدارة المخاطر) | قياسي في Business Security وما فوقها | يمنح درجة للأجهزة غير المُصحَّحة والمُهيَّأة بشكل خاطئ؛ لكنه لا ينشر التصحيح بنفسه |
| Patch Management | ليس افتراضيًا في أي فئة — إضافة | الفحص والنشر وخادم التخزين المؤقت وتجاهل التصحيح تأتي مع هذه الإضافة |
| Full Disk Encryption | إضافة | إدارة تشفير القرص الكامل عبر وحدة التحكم |
| Email Security / Extended Email Security | إضافة | ترشيح على طبقة البريد الإلكتروني؛ تكامل عبر واجهة برمجية أصلية مع Microsoft 365 |
| Integrity Monitoring | إضافة | مراقبة التغييرات في سلامة النظام |
| Container Security | إضافة | بيئات Docker وPodman وKubernetes وECS وEKS وAKS وGKE |
| Extended Detection (مستشعرات XDR) | إضافة | مستشعرات الهوية والشبكة والإنتاجية تأتي كمستشعرات اختيارية في فئة XDR؛ أما مستشعرا السحابة وAtlassian فيُشتريان على حدة حتى في فئة XDR |
| الاحتفاظ بالبيانات (Data Retention) | إضافة | مُدرج في صفحة المقارنة بخيارات 90 و180 و365 يومًا؛ ولا تُذكر مدة الاحتفاظ الافتراضية |
المصدر: صفحة المقارنة الرسمية لمنتجات أعمال Bitdefender (Bitdefender، 2026). ويُخلَط كثيرًا بين تحليلات المخاطر وإدارة التصحيحات: فـEndpoint Risk Analytics تجعل التصحيح الناقص مرئيًا، بينما تقوم Patch Management بـإغلاقه. والتركيب الذي ينتج درجة مخاطر فقط يُفضي في التدقيق إلى صورة "كنا نعرف المخاطرة لكننا لم نغلقها". ونشرح نطاق الفئة التمهيدية في صفحة GravityZone Business Security، وطبقة تحليل التهديدات المتقدمة في صفحة Business Security Premium.
يُخلَط بين هذين المفهومين باستمرار، مع أن الفرق بينهما واضح. إدارة التصحيحات الفعلية تطبّق الإصلاح الذي أصدرته الشركة المصنّعة على البرنامج نفسه؛ فتزول الثغرة. أما التصحيح الافتراضي فلا يمسّ البرنامج؛ بل يحجب بمجموعة قواعد الحركةَ أو نمطَ الطلب الذي يحاول استغلال الثغرة. وتبقى الثغرة موجودة في الشيفرة لكنها تصبح غير قابلة للاستغلال. وهذه بالضبط إحدى القدرات البارزة في Trend Micro Deep Security: فهو يطبّق التصحيح الافتراضي بقواعد نظام منع الاختراق (IPS) المستضاف على المضيف. وتُعرِّف وثائق Trend Micro ذلك بأنه تدريع الثغرات المعروفة بقواعد IPS إلى حين إمكانية تطبيق التصحيح، وتوفير هذا الضابط الذي تتوقعه كثير من لوائح الامتثال (وثائق Trend Micro Deep Security، تاريخ الاطلاع 2026).
وGravityZone Patch Management هي الطرف الذي ينشر التصحيح الفعلي؛ وهي لا تقوم بالتصحيح الافتراضي. أما الطبقات التي توقف محاولة الاستغلال على جانب Bitdefender فهي Advanced Anti-Exploit وNetwork Attack Defense، لكنهما تقومان على السلوك وتقنية الهجوم — ولا تقدّمان درعًا موقَّعًا مكتوبًا لثغرة بعينها. وعليه فالنهجان ليسا متنافسَين، بل طبقتان تحلّان مشكلتين مختلفتين.
| البُعد | التصحيح الفعلي (GravityZone Patch Management) | التصحيح الافتراضي (مثل Trend Micro Deep Security IPS) |
|---|---|---|
| الأثر على الثغرة | تُزال الثغرة؛ وتُصحَّح الشيفرة | تبقى الثغرة في مكانها ويُحجَب مسار الاستغلال |
| نقطة التطبيق | الملفات الثنائية لنظام التشغيل والتطبيقات | طبقة حركة الشبكة/المضيف وفحص الطلبات |
| إعادة التشغيل | تختلف بحسب التصحيح؛ ويُحدَّد في مهمة التثبيت خيار "أعد تشغيل نقاط النهاية عند اللزوم" | غير مطلوبة عادةً، وتدخل القاعدة حيّز التنفيذ فورًا |
| سرعة التفعيل | يُنتظَر حتى تصدر الشركة المصنّعة التصحيح | يمكن تطبيقها فور صدور القاعدة |
| مخاطر توافق التطبيقات | قد يحدث تغيّر في السلوك بعد التصحيح؛ وحلقة الاختبار شرط أساسي | مخاطر التوافق منخفضة لأن البرنامج لا يتغير؛ لكن يوجد خطر الإيجابيات الكاذبة |
| الأنظمة المنتهي دعمها | لا يقدّم حلًّا إن لم تصدر الشركة المصنّعة تصحيحًا | يوفّر جسرًا للأنظمة القديمة غير القابلة للتصحيح |
| المقابل في التدقيق | يُنتج دليل "أُغلقت الثغرة" | يُوثَّق كضابط تعويضي (compensating control) |
| الديمومة | حل دائم | حماية مؤقتة؛ ويجب تطبيق التصحيح الفعلي عند صدوره |
والتصميم الصحيح عادةً كالتالي: يُصحَّح كل ما يمكن تصحيحه، وتُحمى الأنظمة التي لا يمكن تصحيحها أو التي يتعذر إيجاد نافذة صيانة لها بالتصحيح الافتراضي، ويُسجَّل ذلك كاستثناء مؤقت. فإذا كنت لا تستطيع إعادة تشغيل خادم Windows قديم على خط الإنتاج، فالتصحيح الافتراضي يُبقيك واقفًا؛ لكن هذا ليس مبررًا لتأجيل التصحيح إلى أجل غير مسمى. ونشرح المقابل لدى Trend Micro بالتفصيل في صفحة Deep Security؛ كما نضع جدران الحماية FortiGate، التي تؤدي الوظيفة نفسها بنظام IPS على طبقة الشبكة في حركة الفروع والمركز، بوصفها طبقة مكمّلة.
تدعم GravityZone Patch Management إلى جانب Windows وmacOS توزيعات CentOS وRed Hat Enterprise Linux وSUSE Linux Enterprise (دعم Bitdefender B2B، 2026). أما الوكيل الذي تُركَّب عليه الوحدة، وهو Bitdefender Endpoint Security Tools، فيغطي طيفًا أوسع بكثير: من Windows 11 25H2 إلى الإصدار الأول من Windows 10، ومن Windows Server 2025 إلى Windows Server 2016 Core، وRed Hat Enterprise Linux 7.x–10.x وDebian 9–13 وUbuntu 16.04.x–26.04.x، إضافةً إلى أجهزة macOS بمعالجات Intel وسلسلة Apple M (دعم Bitdefender B2B، 2026). ويجب عدم الخلط بين هاتين القائمتين: فليس كل توزيعة يدعمها الوكيل مدعومةً بالضرورة في إدارة التصحيحات. كما تذكر وثيقة الدعم قيدين عمليين: تُحدَّث قوائم الشركات المصنّعة والمنتجات المدعومة شهريًا وتُنشَر كملفات CSV بحسب نظام التشغيل؛ وتُثبِّت Bitdefender التصحيحات الموقَّعة رقميًا فقط، وأي تصحيح غير موقَّع يجب تثبيته يدويًا حتى لو ظهر المنتج في القائمة (دعم Bitdefender B2B، 2026).
وعلى جانب تطبيقات الطرف الثالث يجب أن نكون صريحين. فلا واحد من الأرقام المتداولة على الإنترنت بصيغة "يدعم كذا تطبيقًا" بشأن Bitdefender Patch Management وارد في وثائق الشركة المصنّعة الرسمية. فصفحة Bitdefender الرسمية تتحدث فقط عن قائمة واسعة من تطبيقات الطرف الثالث، ووثيقة الدعم تنشر الشركات المصنّعة والمنتجات المدعومة كملفات دون ذكر عدد إجمالي. ولذلك لا ننشر نحن أيضًا عدد تطبيقات في هذه الصفحة. والطريقة الصحيحة هي استخراج جرد برمجياتك قبل المشروع ومقارنته بهذه القائمة — فقد يكون التطبيق الحرج لدى مؤسسة ما غير موجود في القائمة، ويجب معرفة هذه الفجوة منذ البداية.
وعلى جانب الخوادم والمحاكاة الافتراضية، لا ينبغي التفكير في إدارة التصحيحات بمعزل عن معمارية الحماية. ففي البيئات كثيفة المحاكاة الافتراضية يُحال عبء الفحص إلى جهاز أمني افتراضي ويبقى الوكيل خفيفًا؛ وتُخطَّط نوافذ نشر التصحيحات وفق هذه المعمارية أيضًا. ونتناول التصميم على جانب الخوادم في صفحة GravityZone Security for Servers. أما في موضع الجهاز الافتراضي ونوافذ الصيانة والأتمتة فتدخل خدمات DevOps والبنية التحتية لدينا.
المخاطرة الحقيقية في إدارة التصحيحات ليست التصحيح نفسه بل النشر بلا ضبط. ولهذا يُخطَّط للنشر على شكل حلقات: أولًا أجهزة فريق تقنية المعلومات نفسه، ثم مجموعة مستخدمين منخفضة المخاطر، ثم الأسطول العام، وأخيرًا الخوادم الحرجة. ويُترك بين كل حلقة وأخرى نافذة مراقبة كافية. وهذا النهج ليس اختراعًا جديدًا، بل ممارسة قياسية في إدارة التغيير تُنتظَر في عمليات التدقيق أيضًا.
إذا كان تصحيح ما يسبب مشكلة داخل المؤسسة أو كان تطبيق عملك معتمدًا على إصدار معيّن، فيجب عدم نشر ذلك التصحيح. وتفعل GravityZone Patch Management ذلك لا عبر وحدة "قائمة حظر" منفصلة، بل عبر إجراء Ignore patches (تجاهل التصحيح) في جرد التصحيحات: إذ تُستبعَد التصحيحات المختارة من الجرد ومن نطاق النشر (Bitdefender TechZone، 2026). ويجب إسناد مالك وسبب وتاريخ مراجعة لكل تصحيح مُتجاهَل — وهذا ليس حقلًا إلزاميًا في المنتج، بل قاعدة حوكمة نوصي بها. وإلا فستتحول قائمة التجاهل مع الوقت إلى قائمة ثغرات دائمة.
إذا أظهر تطبيق سلوكًا غير متوقع بعد التصحيح، فيجب أن يكون مسار التراجع محددًا مسبقًا. وهذا المسار لا يُترك لأداة التصحيح وحدها؛ إذ تُصمَّم معه خطة اللقطة (snapshot) أو الاسترجاع من النسخة الاحتياطية على الخوادم، وسيناريو إعادة التثبيت بالصورة القياسية على الأجهزة العميلة. وفي الأنظمة الحرجة تكون نافذة الصيانة وخطة التواصل بأهمية التصحيح نفسه. ويمكن تحديد خيار "أعد تشغيل نقاط النهاية عند اللزوم" في مهمة التثبيت؛ ولأنه لا يمكن معرفة أي تصحيح سيتطلب إعادة تشغيل مسبقًا، فتُوضع خطة النافذة على هذا الأساس. أما التحقق المستقل من تطبيق التصحيح فعليًا فهو من مهام جانب التقارير.
لا. فالتصحيح يغلق الثغرات المعروفة؛ أما ثغرات يوم-صفر وعمليات الدخول ببيانات اعتماد مسروقة وهجمات الهندسة الاجتماعية فلا تُمنَع بالتصحيح. ولذلك تُبنى إدارة التصحيحات جنبًا إلى جنب مع طبقة كشف واستجابة. ولرؤية سلاسل الهجوم التي تتجاوز نقطة النهاية ينبغي النظر إلى GravityZone XDR، وللمؤسسات التي لا تملك فريقًا داخليًا يراقب على مدار الساعة ينبغي النظر إلى Bitdefender MDR.
إدارة التصحيحات من أكثر التدابير التقنية التي يُطلَب دليل عليها في عمليات التدقيق. فالمادة 12 من القانون التركي رقم 6698 لحماية البيانات الشخصية (KVKK) تُلزِم المسؤول عن البيانات باتخاذ التدابير التقنية والإدارية المناسبة لمنع الوصول غير المشروع إلى البيانات الشخصية وضمان حفظها. وترك ثغرة معروفة مفتوحة لمدة طويلة يهيّئ الأرضية لتقييم مفاده "لم تُتخذ التدابير المناسبة" بعد وقوع انتهاك. وتقرير التصحيحات المركزي وثيقة دفاع ملموسة عند هذه النقطة.
وفي نطاق ISO 27001 تُعدّ إدارة الثغرات التقنية بندَ ضبطٍ مستقلًا، ويطلب المدقق عادةً ثلاثة أمور: كيف اكتُشفت الثغرات، وفي أي مدة أُغلقت، ولماذا لم تُغلَق تلك التي بقيت مفتوحة. وتُنتج Patch Management هذه الثلاثة جميعًا — الجرد وسجل النشر وسبب التجاهل. أما في بيئات بيانات البطاقات ضمن نطاق PCI-DSS فيُتوقع تطبيق التصحيحات الأمنية الحرجة خلال مدة محددة وتوثيق ذلك؛ ويجب أن تكون الضوابط التعويضية للأنظمة غير القابلة للتصحيح موثَّقة كتابيًا. والتصحيح الافتراضي هو تحديدًا الضابط التعويضي الذي يدخل عند هذه النقطة.
والصورة التي نصادفها أكثر من غيرها عمليًا في تركيا هي التالية: اشتُريت أداة إدارة التصحيحات لكن النشر التلقائي تُرك مُعطَّلًا لأن حلقات النشر لم تُحدَّد. فيبقى المنتج قائمًا في وحدة التحكم، بينما لا يمكن القول في التدقيق إن "هناك عملية للتصحيحات". ويهدف نطاق خدمتنا في Sora Yazılım إلى سدّ هذه الفجوة: استخراج جرد البرمجيات، وتحديد حلقات النشر ونوافذ الصيانة، وإرساء حوكمة قائمة التجاهل، وتحديد موضع خادم التخزين المؤقت، وإعداد تقارير قابلة للاستخدام في التدقيق. ولغة واجهة وحدة تحكم GravityZone ليست التركية؛ ونحن من يوفّر للمسؤولين التدريب بالتركية ونقل الوثائق والدعم بالتركية لحظة حدوث مشكلة.
شارِكنا عدد نقاط النهاية والخوادم لديك، والتطبيقات الحرجة التي تستخدمها، وكيف تسير عملية التصحيح الحالية لديك؛ ولنستخرج معًا مدى تغطية إضافة GravityZone Patch Management لجردك، والأنظمة التي ستحتاج فيها إلى ضابط تعويضي مثل التصحيح الافتراضي. ولترخيص الإضافة وتصميم النشر وتقارير التدقيق اطلب عرض سعر عبر صفحة التواصل؛ ونخطط لتركيب تقييمي على مجموعة تجريبية.
في المؤسسات الخاضعة للتنظيم، سؤال المدقق ليس "هل يوجد تصحيح" بل "كم استغرق إغلاق التصحيح الحرج وما سبب ما لم يُغلق". ويجعل جرد الفحص المجدول وسجل النشر وأسباب التجاهل هذه العناوين الثلاثة قابلةً للتوثيق. ونُرسي معًا كعملية إسنادَ مالك وسبب وتاريخ مراجعة لكل تصحيح مُتجاهَل.
إعادة التشغيل العشوائية غير مقبولة في محطات استقبال المرضى والتصوير. ويُنفَّذ نشر التصحيحات في نوافذ محددة خارج ساعات العيادات، وتُوضع الأجهزة الحرجة في مجموعة منفصلة وتُصحَّح في الحلقة الأخيرة. وفي المحطات التي تشترط فيها الشركة المصنّعة للجهاز الطبي إصدارًا معيّنًا، تُدرَج التصحيحات المعنية في قائمة التجاهل وتُوثَّق الضوابط التعويضية.
في خط إنتاج يعمل على مدار أربع وعشرين ساعة وسبعة أيام في الأسبوع، لا يمكن إعادة تشغيل بعض الخوادم؛ وفي هذه الحالة لا يكفي التصحيح الفعلي وحده. فتُصحَّح الأنظمة القابلة للتصحيح حلقةً بعد حلقة، ويُخطَّط لضابط تعويضي مثل التصحيح الافتراضي لغير القابلة للتصحيح، ويُسجَّل هذا الاستثناء بمدة محددة. فالاستثناء غير المحدد بمدة يتحول مع الوقت إلى قائمة ثغرات دائمة.
تنزيل التصحيح نفسه من الإنترنت بشكل منفصل في عشرات الفروع يستهلك سعة الخط. ويقوم خادم التخزين المؤقت للتصحيحات بتنزيل التصحيح إلى نقطة واحدة وتوزيعه على نقاط النهاية من هناك. وعند تعذّر الوصول إلى خادم التخزين المؤقت تستمر الأنظمة في تنزيل التصحيحات من مواقع الشركات المصنّعة؛ ويجب أخذ هذا السلوك في الحسبان منذ البداية في تخطيط السعة.
في ضابط إدارة الثغرات التقنية يطلب المدقق معرفة كيف اكتُشفت الثغرات وفي أي مدة أُغلقت وما سبب ما لم يُغلق. ويُنتج تقرير التصحيحات المركزي هذه المخرجات الثلاثة. وفي حواسيب المختبرات والاستخدام المشترك يُفضَّل التصحيح الجماعي في بداية الفصل الدراسي، ونوافذ مجدولة وأقل تواترًا خلاله.
في فرق تقنية المعلومات المكوّنة من شخص أو شخصين، يتعذر عمليًا الاستمرار في تشغيل أداة منفصلة لإدارة التصحيحات. ولأن Patch Management تعمل عبر الوكيل نفسه ووحدة التحكم نفسها فهي لا تُنشئ بنية تحتية ثانية؛ وتُدار سياسات الحماية وسياسات التصحيح من المكان نفسه. وبعد إنشاء حلقات النشر مرة واحدة وربطها بمهام مجدولة، تسير العملية إلى حد كبير من تلقاء نفسها.
المؤسسات المضطرة إلى إغلاق الثغرات المعروفة عبر عملية قابلة للتوثيق، والتي لا تملك موارد لتشغيل أداة منفصلة لإدارة التصحيحات، وتستخدم وكيل GravityZone أصلًا؛ إضافةً إلى شركات التمويل والرعاية الصحية والقطاع العام والتعليم والتصنيع والتجزئة متعددة الفروع الخاضعة لعمليات تدقيق KVKK (قانون حماية البيانات الشخصية في تركيا) وISO 27001 وPCI-DSS.
يفتح الوثائق التقنية الأصلية وصفحة المنتج للمصنّع في علامة تبويب جديدة.
Bitdefender — GravityZone Patch Management →المستوى التمهيدي من GravityZone للشركات الصغيرة والمتوسطة: وكيل واحد، وحدة تحكم واحدة، حماية للأجهزة الطرفية من دون EDR.
تفاصيلEDR كامل فوق طبقة EPP: ربط الأحداث بين الأجهزة الطرفية، وصيد التهديدات، والمعالجة بنقرة واحدة.
تفاصيلالفئة المتوسطة التي تضيف فوق Business Security تقنية HyperDetect وبيئة Sandbox السحابية والتحليل الجنائي للهجمات.
تفاصيلحماية للبريد الإلكتروني عبر بوابة أمنية وتكامل API مع Microsoft 365 ضد التصيّد واختراق البريد التجاري (BEC) والمرفقات الخبيثة.
تفاصيلنهج مكمّل عبر التصحيح الافتراضي
تفاصيلBitdefenderالفئة التمهيدية التي تُبنى فوقها الإضافة
تفاصيلBitdefenderمعمارية الحماية على جانب الخوادم والمحاكاة الافتراضية
تفاصيلBitdefenderطبقة الكشف للهجمات التي لا يغلقها التصحيح
تفاصيلتتولى Sora Yazılım الترخيص والنشر والتدريب والإدارة المستمرة — كل ذلك من خلال فريق واحد.