بنية إضافات الدفاع: CrowdStrike وJamf وBaramundi

الخلاصة. كفّ عن قياس منصة أمنية بحجم كتالوج تكاملاتها. المهم هو كم يستغرق فريقك، لا فريق المورّد، لإضافة تكامل لا يحويه الكتالوج. فإن كانت الإجابة «فترة بعد ظهر واحدة»، أمكنك مجاراة التهديدات الجديدة؛ وإن كانت «افتح تذكرة شراكة وانتظر ربعين»، تخلّفت عنها. وشكل واجهة الإضافات هو ما يحدد أي الإجابتين ستحصل عليها.

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

سؤالان يخبرانك بمدى صحة هذا الادعاء.

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

يستعرض هذا المقال بنية الإضافات المستخدمة في وحدة الدفاع لدى Krasper Suite، وهي الطبقة التي تتحدث إلى أنظمة نقاط النهاية والهوية وإدارة الأجهزة. والتكاملات التوضيحية الثلاثة هي CrowdStrike (كشف واستجابة لنقاط النهاية) وJamf (إدارة أجهزة Apple) وBaramundi (إدارة موحّدة لنقاط النهاية). وهي ملموسة بما يكفي لإثبات أن النمط يعمل مقابل واجهات مورّدين حقيقية بأشكال شديدة الاختلاف؛ وهي أيضًا بديل عن الإجابة الأطول، وهي أن أيًا منها يمكن أن يستبدله أو يضيف إليه مهندس لدى العميل في أقل من ساعة بكثير مقابل الواجهة الموصوفة أدناه.

المحتويات

ضريبة التكامل: ما الغرض الفعلي من بنية الإضافات
واجهة إضافة الدفاع
اكتشاف البيانات الوصفية والتسجيل
إضافة مخصصة في نحو 50 سطرًا
نمط فحص الصحة الذي تتخطاه معظم الإضافات
دورة حياة الإضافة: التثبيت والتفعيل والإصدار والتقاعد
لماذا يثبت ثلاثة مورّدين مختلفين صحة النمط

1. ضريبة التكامل: ما الغرض الفعلي من بنية الإضافات

كل منصة عمليات أمنية تدفع ضريبة تكامل. وشكلها يعتمد على كيفية بناء المنصة.

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

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

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

2. واجهة إضافة الدفاع

إضافة الدفاع في Suite هي أي شيء ينفّذ أربعة عقود:

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

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

   ┌──────────────────────────────────────────────┐
   │  DefensePlugin (interface)                    │
   │                                               │
   │  + describe()        → PluginMetadata         │
   │  + discover_assets() → AssetRecord[]          │
   │  + ingest()          → AsyncIterator[Event]   │
   │  + execute(action)   → ActionResult           │
   │  + health()          → HealthReport           │
   └──────────────────────────────────────────────┘

واجهة إضافة الدفاع: أربع دوال مطلوبة

لكل دالة قيمة إرجاع مُنمّطة؛ ولكل استدعاء خارجي مهلة محدودة؛ وكل أثر جانبي يمر عبر طبقة عدم التكرار نفسها التي تستخدمها بقية المنصة. ومؤلفو الإضافات لا ينفّذون تلك الضمانات؛ بل يرثونها من الصنف الأساس.

3. اكتشاف البيانات الوصفية والتسجيل

الإضافة الجديدة لا تتطلب إعادة نشر المنصة. فحلقة الاكتشاف تلتقطها من سجل الإضافات، وتقرأ بياناتها الوصفية، وتتيحها لتهيئة المستأجرين. وتصف البيانات الوصفية ما تدّعي الإضافة القيام به، وما تحتاجه من بيانات اعتماد، وما تدعمه من إجراءات، وما تضمنه من عقد إصدار.

   ┌──────────────────────────────────────────────┐
   │  PluginMetadata                               │
   │                                               │
   │  name: "acme-edr-plugin"                      │
   │  version: "1.2.0"                             │
   │  vendor: "acme"                               │
   │  capabilities:                                │
   │    - asset_discovery                          │
   │    - telemetry_ingest                         │
   │    - action.isolate_endpoint                  │
   │    - action.run_remediation_script            │
   │  credentials_schema: { ... JSON Schema ... }  │
   │  api_contract_version: "1"                    │
   └──────────────────────────────────────────────┘

البيانات الوصفية للإضافة: الاكتشاف وإعلان القدرات

الحقل api_contract_version هو الحقل الحامل. فهو إصدار واجهة إضافات المنصة التي بُنيت الإضافة مقابلها، لا إصدار واجهة المورّد. وترفض المنصة تحميل الإضافات التي لا تستطيع تلبية إصدار عقدها، وهو ما يمنع نمط الفشل الذي تسيء فيه إضافة قديمة التصرف بصمت مقابل واجهة أحدث.

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

4. إضافة مخصصة في نحو 50 سطرًا

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

python

from suite_plugins import (
    DefensePlugin, PluginMetadata, AssetRecord,
    Event, ActionResult, HealthReport,
)
from suite_plugins.errors import UpstreamError


class AcmeEdrPlugin(DefensePlugin):

    def describe(self) -> PluginMetadata:
        return PluginMetadata(
            name="acme-edr-plugin",
            version="1.0.0",
            vendor="acme",
            capabilities=[
                "asset_discovery",
                "telemetry_ingest",
                "action.isolate_endpoint",
            ],
            credentials_schema={
                "type": "object",
                "required": ["api_token", "base_url"],
                "properties": {
                    "api_token": {"type": "string"},
                    "base_url": {"type": "string", "format": "uri"},
                },
            },
            api_contract_version="1",
        )

    async def discover_assets(self):
        async for raw in self.client.list_endpoints():
            yield AssetRecord(
                native_id=raw["device_id"],
                resolution_hints={
                    "serial": raw.get("serial_number"),
                    "mac": raw.get("primary_mac"),
                    "hostname": raw.get("hostname"),
                },
                os=raw.get("os_platform"),
                last_seen=raw.get("last_checkin_at"),
            )

    async def ingest(self):
        async for raw in self.client.stream_alerts():
            yield Event(
                event_type="edr.alert.created",
                native_id=raw["alert_id"],
                native_asset_id=raw["device_id"],
                severity=raw["severity"],
                payload=raw,
            )

    async def execute(self, action):
        if action.type == "isolate_endpoint":
            try:
                await self.client.isolate(action.target.native_id)
                return ActionResult.success()
            except UpstreamError as e:
                return ActionResult.failure(reason=str(e))
        return ActionResult.unsupported()

    async def health(self) -> HealthReport:
        try:
            await self.client.ping()
            return HealthReport.ok()
        except UpstreamError as e:
            return HealthReport.degraded(reason=str(e))

إضافة كشف نقاط نهاية بالحد الأدنى: توضيحية لا جاهزة للإنتاج

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

والنمط المهم: كل دالة ترتبط بنظافة بعقد تفهمه المنصة أصلًا. فـAssetRecord هو شكل الأصل المعياري الذي يتوقعه محلل المنصة. وEvent هو الشكل الذي يشترك فيه ناقل الأحداث. وActionResult هو الشكل الذي تفهمه كل عقدة في أدلة التشغيل. والإضافة لا تخترع مفردات؛ بل تربط مفردات المورّد بمفردات المنصة.

5. نمط فحص الصحة الذي تتخطاه معظم الإضافات

تبدو health() تافهة: استدعِ الأعلى، وأعد «سليم» أو «متدهور». وما يفصل فحص صحة حقيقيًا عن فحص شكلي هو التحديد.

فحص صحة يعيد «سليم» أو «فاشل» بالكاد مفيد. فالمشغّل يكتشف أن التكامل معطّل؛ لكنه لا يكتشف لماذا. وعندها يُستدعى مؤلف الإضافة على أي حال.

أما فحص الصحة المفيد فيعيد بنية تكفي للفرز:

   ┌────────────────────────────────────────────┐
   │  HealthReport                               │
   │                                             │
   │  status: ok | degraded | down               │
   │  upstream_reachable: bool                   │
   │  auth_valid: bool                           │
   │  rate_limit_remaining: int | null           │
   │  last_successful_call: timestamp            │
   │  message: human-readable detail             │
   └────────────────────────────────────────────┘

تقرير الصحة: إشارة فرز مهيكلة

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

وتستدعي المنصة health() على كل إضافة بوتيرة منتظمة وتعرض النتيجة على لوحة العمليات. ويُنفَّذ الاستدعاء نفسه أيضًا كفحص جاهزية قبل تشغيل أي دليل تشغيل يعتمد على الإضافة. فلا يعمل دليل تشغيل بصمت مقابل تكامل معروف العطل.

6. دورة حياة الإضافة: التثبيت والتفعيل والإصدار والتقاعد

لحياة الإضافة أربع مراحل، لكل منها دلالات صريحة.

عند التثبيت، تُرفع إضافة جديدة أو تُسحب من سجل الإضافات. وتتحقق المنصة من بياناتها الوصفية، وتفحص إصدار العقد، وتسجّلها كمتاحة لتهيئة المستأجرين، مع أنها ليست فعّالة لأحد بعد.

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

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

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

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

7. لماذا يثبت ثلاثة مورّدين مختلفين صحة النمط

التكاملات الثلاثة التي نشحنها في وحدة الدفاع لدى Suite (CrowdStrike وJamf وBaramundi) موجودة كدليل تجريبي على أن واجهة الإضافات أعلاه تعمّم عبر أشكال أعلى شديدة الاختلاف.

يعرض CrowdStrike تغذية تنبيهات متدفقة عالية الإنتاجية وواجهة REST للإجراءات؛ فتشترك دالة ingest() في التدفق، وتستدعي execute() نقاط REST. أما Jamf فمتمركز حول Apple، وبشكل إدارة أجهزة محمولة، بمفردات مختلفة حول الأجهزة وملفات تعريف التكوين؛ وتربط الإضافة تلك المفردات بأشكال الأصول والإجراءات المعيارية التي تتحدثها بقية المنصة. ويغطي Baramundi الإدارة الموحّدة لنقاط النهاية المتمركزة حول Windows مع الترقيع وجرد البرمجيات؛ وتتولى الإضافة تعداد الأصول بالجملة وأحداث تثبيت البرمجيات.

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

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

خاتمة

كتالوج التكاملات طريقة رديئة لقياس منصة أمنية. فالمهم هو كم يكلّف فريقك أن يوسّعها حين يقصر الكتالوج، وواجهة إضافات حسنة الشكل، بعقود مُنمّطة واكتشاف مدفوع بالبيانات الوصفية وفحوص صحة حقيقية ودورة حياة صريحة، تُبقي تلك الكلفة متوقعة ومنخفضة.

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

قراءات إضافية

Plugin Architectures in Production Systems، أنماط تصميم للمنصات القابلة للتوسعة
NIST SP 800-128: دليل إدارة التكوين المرتكزة على الأمن
MITRE D3FEND: تقنيات التحصين والعزل التي تشير إليها تكاملات كشف نقاط النهاية

بنية إضافات الدفاع: دمج CrowdStrike وJamf وBaramundi في أقل من 30 دقيقة