بنية النظام — تدفق البيانات من البداية إلى النهاية (System Architecture — End-to-End Data Flows)

تشرح هذه الصفحة كيفية اتصال وتواصل كل مكون في أنظمة AuroraSOC. ستتعلم وتستكشف ما يحدث عندما يدخل أي تنبيه وإنذار إلى النظام، وكيف ينسق الوكلاء (agents) للتحقيق والتحري فيه، وكيف تصل النتائج إلى لوحة المتابعة والمشاهدة الخاصة بالمحلل.

---

بنية عالية المستوى

---

التدفقات والمسارات الخمسة الأساسية (The Five Core Flows)

التدفق 1: استيعاب واحتواء الإنذارات الخارجية (External Alert Ingestion)

ما الذي يحدث عندما يدخل تنبيه إلى النظام من مصدر خارجي ومستقل (SIEM، موجز تغذية طرف ثالث، ألخ.).

External Source → FastAPI POST /api/alerts → Deduplication Check → PostgreSQL → Redis Stream (aurora:alerts)

1. المصدر الخارجي (External source) يُرسل طلب HTTP POST إلى المسار /api/alerts مزوداً ومحمولاً ببيانات الإنذار والتنبيه (العنوان، الأهمية والخطورة، المصدر، مؤشرات الاختراق IOCs، وتكتيكات وتقنيات MITRE).
2. واجهة ونقطة نهاية اتصال FastAPI تتحقق من صحة الطلب (validates) باستخدام مسودات وقوالب (Pydantic models) وتُراجع تصريحات وتوثيقات المصادقة المعززة بنموذج (JWT authentication).
3. إزالة التكرار (Deduplication) — يتم احتساب وحصد تجزئة وقيمة معمّاة من نوع SHA-256 مشتقة كلياً ومُركبة من العنوان + المصدر + مؤشرات الاختراق. فإذا ما وجد مُسبقاً في النظام تنبيه يحمل تجزئة مطابقة ومماثلة لهذه تماماً، فسيُجرى استبعاد النسخة المتكررة حديثاً واعتماد الأصل.
4. كتابة وإيداع لقاعدة PostgreSQL — يتم تخزين وتدوين الإنذار الجديد كلياً داخل جدول الإنذارات alerts.
5. إصدار ونشر مسار Redis Stream — يُنشر ويُعلن عن التنبيه إلى قناة aurora:alerts لكي تتمكن مستهلكات العمليات الخلفية (كالوكلاء وبثوث شبكة WebSocket) من الاستجابة المباشرة والتصرف حيال هذا الإنذار.
6. البث المباشر (WebSocket broadcast) — يقرأ المُستهلك الخلفي لـ FastAPI من جدول aurora:alerts ومن ثم يرسل الإنذار بشكل توجيهي مباشر نحو كافة عملاء لوحة التحكم المُتصلين عبر بروتوكولات وشبكات اتصال (WebSocket).

التدفق 2: استيعاب واحتواء إنذارات أجهزة إنترنت الأشياء والأنظمة المادية السيبرانية (IoT/CPS Alert Ingestion) (الطرف → Rust → Redis)

ما الذي يحصل عندما يكتشف جسم أو جهاز مادي أمراً وتغييراً مستغرباً وغير اعتيادي.

Firmware → MQTT (mTLS) → Mosquitto → Rust Core → Normalize → Redis Stream (aurora:cps:alerts)

1. البرامج الثابتة (Firmware) (التي تعمل على متحكمات STM32 أو nRF52 أو ESP32-S3) ترصد وتكتشف وتلتقط أمر أو فعل وحالة شذوذ في وتيرة عملها — حدث تلاعب أو تعدي (tamper event)، كتابة ولصق محتوى مريب وغير مألوف داخل تجويفات البرمجة الثابتة، تنشيط طارئ لأحد منافذ واجهات الاستكشاف والتشخيص البرمجي (debug interface activation)، أو التقاط ورصد قراءة غير عادية وتسجيل استشعار مادي يعلو مقاييس النطاقات الطبيعية الاعتيادية.
2. النشر والإصدار في بروتوكول MQTT — يعمد الجهاز لإشهار الإشعار لعنوان منوال ونموذج مشابه وقريب من aurora/devices/{device_id}/telemetry باستخدام نمط اتصال وإقرار وجودة اتصال تسمى QoS 2 (الوصول المؤكد والسليم لمرة واحدة فقط exactly-once) مُنفذ عبر عباءة بروتوكولات مأمونة ومُشفّرة (mTLS) (يتحقق كلا الجانبين من بطاقات وصكوك الشهادات الرقمية).
3. وسيط التسليم (Mosquitto broker) يستلم الرسالة ويمرر ويُوَجِّه الرسالة نحو واجهتها المُلائمة.
4. الماكنة والمحرك الأساسي المركز للغة (Rust Core Engine) مُشترك ومُنصت ومُتابع لمواضيع وعناوين MQTT. حينما تَحُط وتَفِدُ رسالة، فإنه:
   • يُوحّد ويُسوّي وينسّق (Normalizes) دمج محتويات وفحوى المرفق السمح (raw payload) بهيئة وانسجام وشكل تنبيه قياسي وموحد (وذلك بصرف وإغفال ما كانت الصيغة والبيانات الأولية المصدرية تحمل هيئة مثل CEF، أو Syslog، أو JSON، أو تنسيق خام وثنائي raw binary).
   • يتحقق ويتوثق من الإفادات والشهادات (attestation) إذا ما كانت الرسالة تتضمن وتملك بداخلها بطاقة أو شهادة إفادة برمجية تابعة للعتاد والمعدات الصلبة (تحقق من توقيع معمارية ECDSA P-256).
   • ينشر ويُشهر (Publishes) الإنذارات الموحده والمُعالجة وينقلها نحو قنوات الاتصال والعبور aurora:cps:alerts بواسطة خطوط مرور Redis Stream.
5. خط مسارات مرور Redis Stream يوصل ويدفع عبر تنبيه إنذارات CPS نحو الواجهات البرمجية وطبقات العمليات المرتبطة والخاصة بمحافل الذكاء (API and agent layer).

التدفق 3: تحقيق وتحري الوكيل الذكي (المنسق Orchestrator → المتخصصين Specialists)

ما الذي يحدث عندما يقرر ويتجه النظام للتدخل والتحقيق في إنذار معين.

Alert → Orchestrator → ThinkTool → HandoffTool[Specialist] → MCP Tools → Results → Synthesize → Report

هذا هو التدفق الأهم والأكثر محورية داخل بنية العمل بأكملها. دعنا نتعمق في آثاره خطوة بخطوة:

1. الزناد ومشغل الفتيل (Trigger) — يطرأ ويصل إنذار أو تنبيه منبعث إما (من إحدى قنوات واجهة برمجة التطبيقات REST API أو تدفقات وجداول مسارات Redis Stream) مما يفرض ويشترط وجوب التدخل والتحقيق.
2. المنسق العام يتلقى المهمة (Orchestrator receives the task) — عبر مسارات إيعاز وتدفقات قنوات مهام الوكيل بريدجا وتكليفاً aurora:agent:tasks Redis Stream أو استدعاء وعن طريق نداء API.
3. أداة التفكير والتخطيط (ThinkTool) (خطوة أولية إجبارية mandatory first step) — قبل الشروع واتخاذ أي رده فعل، يخضع المنسق للضغط والمُسائلة والإكراه بوساطة وقيد إجراء ConditionalRequirement(ThinkTool, force_at_step=1) المُرغم فيلزم عليه خط واستحداث خطة عمل استقرائية وتنسيقية ممنهجة ومليئة بالبراهين والأجزاء المُسبقة الواضحة:
   • ما هو طراز وتركيبة هذا الإنذار؟
   • ما هم أصناف وفئات الوكلاء التخصصيين المطلوب إدراجهم ضمن التحقيق؟
   • بأي رتبة وتراتبية أو مسار منطقي يُتوجب عليهم ممارسة أعمال التدقيق والتحري؟
   • هل توجد أية أصول وأنظمة منزوية تتبع طيف CPS/IoT لها ارتباط وتعلق ومطرق بهذه الواقعة؟
4. تسليم وتفويض الاختصاص ونقل المهمة (HandoffTool delegation) — يستخدم الوكيل المُرتب والمُنسق ترسانات ومعاول BeeAI وتحديداً عتاد أداة التسليم HandoffTool لتحويل وتخصيص مهام وتفويع أعمال لطبقات أدنى من وكلاء الخبراء المتخصصين. يتم حل عناوين A2A عبر settings.a2a.get_agent_url(...) وفق إعداد A2A_DISCOVERY_MODE:

    وضع compose: delegate_to_SecurityAnalyst → http://agent-security-analyst:9001
    وضع compose: delegate_to_ThreatHunter    → http://agent-threat-hunter:9002
    وضع k8s:    delegate_to_SecurityAnalyst → http://agent-security-analyst-svc:9001
    وضع k8s:    delegate_to_ThreatHunter    → http://agent-threat-hunter-svc:9002

5. يتسلم الوكيل المتخصص المهام المطلوبة الموفدة إليه عن طريق مسار واتصال A2A (Specialist receives task via A2A) — يتلقى محرك خوادم الوكالة BeeAI وموزعه الخاص بالتواصل الداخلي الخفي بين الوكلاء المُستقلين A2AServer الوظائف المتبوع بانتظار إنجازها وتنفيذها.
6. المنهمك والاختصاصي يستخدم عتاد مسننات أدوات (MCP tools) — يتصل المنهمك بملحقات الترسانات المرصودة ضمن مجال مساحة تدخله واختصاصه الحصري المُهيكل به سلفاً. على سبيل التوضيح الافتراضي والقياسي نُدرج ما يعتزم محلل الأمن والسلامة SecurityAnalyst الشروع به للتقصي من خلال الاتصال والعبور لمسالك وقواعد السيرفرات المُتفرعة:
   • خوادم سجلات وتقارير المتابعة SIEM MCP server (:8101) للتنقيب بالملفات وجداول تسجيل الأحداث logs
   • أطوار أتمتت الاستجابة وخوادم تنسيق الكوارث SOAR MCP server (:8102) والمشرب الأطواري وتتبع كتيب وسجلات النظم الحركية (playbooks).
   • خوادم وسرابات تجميع المصادر المفتوحة وأطياف الاستطلاع OSINT MCP server (:8110) لإثراء ومعاضدة حواسيب وملقمات ومؤشرات الاختراق IOCs وتغذيتها وإكسابها عمقاً غنياً بالثراء الخارجي.
7. المنهمك الاختصاصي يُرجِع خلاصة ما أفشَت إليه جُحوره وزياراته من مُكتشفات (Specialist returns findings) — هياكل مجدولة وقِطَافة مُحكمة ومقنونة بظواهر وحوائط صيغ JSON محتوية ومحاطة بصالات الأهمية، ثقة ويقين الاستدلال، تكتيكات وتقنيات ماتر MITRE، ومؤشرات الاختراق والتوصيات الفضلى المنصوح بالرجوع لها والأخذ والعمل حيالها.
8. عمليات التجانس والتآلف والتوليف (Synthesizes) التي يُجريها المنُسق الأكبر العام (Orchestrator) — يقتنص ويصطاد المنسق شباك المكتشفات الشاملة التي تفيض وتتدفق بها شتى بوابات وخوادم المتخصصين والاختصاصيين وُيفلتر جميع التقارير والتضاربات التخصصية من بين سواعد الوكالة، فيوحد شضايا المحتويات لتشكل تِرسانة وحِصنًا يقيميّاً لبيان وحزم الأهميات الإجمالية.
9. بوابات إقرار وصُنع وتوكيل القرار البشري والإنساني (Human approval gate) — إذا لَوّحَ، وأشار، واستدل وأفصح المنُسق بأي قرار أو عمل أو سلوك وقائي ذو تبعيات وأمواج عالية التكلفة والمخاطر ومفرزاتها المترتبة جراء تداعياتها الصعبة كعمليات (كمثل، وجوب وقَطع وعزل وفصل مفرزات خادم سيرفر مركزي للتشغيل الفعلي كلياً عن بؤرة ومحيط شبكات النظام production server isolation)، أو إسقاط وإبطال وفسخ صلاحيات شهادات وتراخيص الاتصال)، فإن النُظم المنسقة يُسارع لرفع شارات الإقرار المُقيدة والحُكم المَوقوف بموافقة وتدخل ورؤية عنصر القرار البشري ذو الصلاحيات المُقننة والمُعرفة: requires_human_approval = true. لتُولّد أذرع واجهات التطبيقات API وتَخلق إبرام تسجيلة لواقعة إجازات وسجلات التدخل وتصدير القرار وتشكله وتودعه بطيات وجيب نموذج وقالب حفظي تحت راية HumanApprovalModel مصحوب ببث لرسوم وتنبيهات حية تُعرض مباشرة في مركز المراقبة عبر تقنية WebSocket. لتتوقف حين إذن مسارات الإجرآت وعمليات التقاصي إلى توقف تعليق كلي pauses وحينها يتحول مصير المسار للرضوخ والمكوث تحت سقف انتظار إجابات وأوامر وردود الأفعال المباشرة للعنصر والمكون ومحلل الطاقم البشري ذو الاختصاص لإبداء وإقرار رأي المصادقة والتنفيذ النهائي بالإيجاب والأمر بالقبول الفعلي وإتمامه، أو رفض واجتثات الخُطط من أصولها وإبطال مفعول التجاوز.
10. إصدار وطباعة ونفاذ نتائج التحقيقات النهائية (Results published) — يُصدر ويُدون حصاد وجني واستنتاج تقارير المتابعة الأمنية والقرارت النهائية للتحقق ويصار لإيداعها وحفظها أمنتا بمخازن وسجلات أرشفه مُدارة وتتسند تحت بنى وجدر وقباب أقفال وقواعد جداول PostgreSQL، وذلك عقب الإنتهاء من عبور مراحل طباعتها وتصويبها وطرحها ضمن أرصفة وحواضن ممرات نشر وتبليغ المحتويات بوسط وقنوات تدفق نتائج التخصيات الأمنية aurora:agent:results.

التدفق 4: ذاكرة الوكلاء والتعلم المكتسب (Agent Memory and Learning)

كيف يتذكر الوكلاء التحقيقات السابقة.

Investigation Complete → Summary Embedded → Qdrant Store → Future Query → Similar Cases Retrieved

1. الذاكرة المتدرجة الطبقات (Tiered Memory) — يمتلك كل وكيل 3 مستويات للذاكرة:

   • الطبقة 1 (الذاكرة العاملة Working): SlidingMemory — آخر 20-60 رسالة في المحادثة الحالية. هذا هو ما يراه النموذج اللغوي الكبير (LLM) كسياق.
   • الطبقة 2 (ذاكرة الأحداث Episodic): EpisodicMemoryStore والمدعوم بمخازن Qdrant — يتم تخزين ملخصات التحقيقات المكتملة كتضمينات متجهة (vector embeddings).
   • الطبقة 3 (معلومات استخبارات التهديدات Threat Intel): ThreatIntelMemory مدعومة بقواعد بيانات Qdrant + Redis — التخزين المؤقت لعمليات بحث مؤشرات الاختراق (IOC) ومعلومات استخبارات التهديدات.

2. الاحتفاظ التلقائي (Auto-persist) — بعد عدد قابل للإعداد والتكوين من الرسائل (على سبيل المثال، كل 20 استدعاء add() لـ ANALYST_MEMORY)، يقوم نظام الذاكرة تلقائيًا بالاحتفاظ بملخص للمحادثة الحالية في مخزن الأحداث الدائم.

3. الاسترجاع والإستدعاء (Recall) — عندما يصل إنذار جديد لم يره الوكيل من قبل، يمكنه استدعاء recall_similar("DNS tunneling via TXT records") والذي يقوم بالآتي:

   • يقوم بتضمين نص الاستعلام في متجه باستخدام نماذج (Sentence Transformers)
   • يبحث في مكتبات Qdrant عن 5 ملخصات تحقيقات سابقة ومرتبطة ومماثلة
   • يعيدها كسياق إضافي للتحقيق الحالي

التدفق 5: الاتحاد والتأزر عبر المواقع المختلفة (Cross-Site Federation (NATS JetStream))

كيف تتشارك عمليات نشر AuroraSOC المتعددة في المعلومات الاستخباراتية.

Site A detects IOC → NATS publish (aurora.intel.ioc.*) → Site B receives → IOC stored locally

1. الموقع (أ) Site A — يرصد ويحدد محلل أو وكيل مؤشر اختراق IOC جديد (IP خبيث، نطاق، هاش ملف).
2. نشر وإصدار NATS publish — يُنشر مؤشر IOC إلى موضوع من مواضيع قنوات NATS JetStream مثل aurora.intel.ioc.ip.
3. التوصيل والربط عبر المواقع (Cross-site delivery) — تجهز قنوات NATS JetStream إيصالاً وحيداً دقيقاً (exactly-once delivery) مع إقرارات استلام للرسائل. يتم تخزين IOC بشكل دائم ومستمر في NATS حتى يتم الإقرار به من قبل جميع المواقع المشتركة.
4. الموقع (ب) يستلم Site B receives — يتلقى مستهلك الـ IOC في الموقع (ب) الرسالة، ويتحقق منها، ويخزنها محليًا لاستخدامها من قبل الوكلاء.

مواضيع وعناوين الاتحادات التعاونية Federation subjects:

حقل مسار الموضوع (Subject Pattern)	المحتوى (Content)	الجوهر والقيمة الغائية (Purpose)
aurora.intel.ioc.*	سجلات مؤشرات الاختراق IOC records	مشاركة مؤشرات وسجلات التهديد عبر المواقع المتعددة
aurora.alerts.federation	ملخصات الإنذارات Alert summaries	الرؤية المتبادلة للإنذارات وتتبعها عبر نُظم المواقع المختلفة
aurora.cps.attestation	نتائج وشهادات الاعتماد (Attestation results)	مشاركة ومقاسمة حالة مدى ثقة وصلاحيات الجهاز

---

أطوار التوثيق والتصريح بالصلاحيات (Authentication and Authorization)

كل طلب يتم تمريره وتوجيهه نحو واجهة (API) يجب أن يكون موثقاً ومُصادقاً عليه (authenticated). وإليك كيفية سير ذلك:

تدفق وثيقة الـ JWT (JWT Token Flow)

التحكم المعتمد على الأدوار (RBAC - Role-Based Access Control)

يمتلك النظام 5 أدوار تنظيمية، ولكل دور منها درجات مراتب وصلاحيات مختلفة:

الدور (Role)	القائم بالدور وصفته (Who)	ما يتمتع بقدرة وميزات القيام به (Can Do)
مُدير admin	مدير للنظام	يتحكم بكل شيء — إدارة المستخدمين، تكوين وإعداد النظام، وتتمتع بوصول شامل واستحواذ للـ API
المحلل analyst	محلل بمركز المراقبة (SOC analyst)	استعراض والتحقيق في الإنذارات، إدارة القضايا والحالات، وتشغيل خطوط وسجلات النظم الحركية التشغيلية (playbooks)
المُشغل operator	مشغل (SOC operator)	مشاهدة التنبيهات والحالات، وتشغيل وتنفيذ محدود وقياسي لكراس قواعد دوال (playbook)
العارض viewer	مستخدم للقراءة فقط	رؤية واجهات العرض لوحات وتقارير المعلومات فقط
حساب الخدمة api_service	حساب خدمة وظيفي (Service account)	تبادل الاتصال والمتوافق والتواصل بين وكيل وواجهة البرمجيات Agent-to-API communication، وضبط أتمتة الوصول للأدوات

الأذونات دقيقة وعميقة — كل واجهة إتصال (endpoint) محددة تقتضي وتحتاج إلى موافقات أذون صلاحيات مخصوصة. على سبيل المثال:

• alert:create — الصلاحية مقتصرة وحصرية لـ admin، analyst، api_service
• case:investigate — الصلاحية متاحة فقط لمناصب admin، analyst
• playbook:execute — الصلاحية مناطة للثلث وهم: admin، analyst، operator
• device:revoke_cert — صلاحية حصرية تنطوي وتنعقد فقط لمجال الـ admin

---

قاطع الدائرة التعطيلية (Circuit Breaker Pattern)

يعتمد المنسق الأكبر العام (Orchestrator) على تفعيل نمط وتصميم قاطع دائرة الحجب والفصل (circuit breaker) للتعامل بمرونة وسلاسة ورزانة مع الوكلاء المتخصصين الذين يخفقون أو يتعرضون للتعطيل ولحالات الفشل:

• مغلقة ومستقرة (CLOSED) — تشغيل وعملية اعتيادية. تنساب وتتدفق الطلبات بفعالية إلى الوكيل المتخصص.
• مفتوحة ومنفصلة (OPEN) — بعد 5 إخفاقات وفشل مُتتالي ومتتابع، تُفتح وتنفصل الدائرة "opens." يتم رفض واقصاء جميع الطلبات فوراً دون أية محاولة لإعادة الاتصال بالوكيل الذي يعاني من إخفاق وتعطل. يمنع هذا الأمر السقوط التراكمي والفشل التتالي (cascading failures).
• نصف مفتوحة (HALF_OPEN) — بعد انقضاء وفوات 60 ثانية، يُسمح بتمرير ومرور طلب اختبار وتسيير وحيد ومُفرد. إذا كُلل هذا الطلب بالنجاح، تُغلق الدائرة (حيث يتعافى الوكيل). وإذا أخفق الطلب وفشل، فإن الدائرة تعاود الانفصام وتفتح مجدداً.

إعادات المحاولة تستخدم التراجع الأُسي (exponential backoff) من خلال مكتبة tenacity — الانتظار لمدة 1 ثانية، 2 ثوانٍ، 4 ثوانٍ بين المحاولات، بحد أقصى 3 محاولات.

---

خدمات الخلفية الاستباقية (Background Services)

يُشغل تطبيق FastAPI العديد من خدمات عمال الخلفية (background workers):

الخدمة (Service)	مجال ومسؤوليات الخدمة (What It Does)	الآلية والنمط (How)
بث إنذارات الويب سوكيت (Alert WebSocket Broadcaster)	يقرأ تدفقات aurora:alerts stream، ويدفع وتذيع الإنذارات لعملاء نظام הـ WebSocket	عبر asyncio.create_task() أثناء دورة حياة التطبيق lifespan
بث أفكار الوكيل (Agent Thought Broadcaster)	يستجوب قنوات aurora:audit stream، وتنفث وتبرز مسارات التفكير للوكلاء (agent reasoning traces)	عبر asyncio.create_task() خلال دورة حياة التطبيق lifespan
ُالمجدول (Scheduler)	يُشغل ويُجدول الأعمال والمهام الدورية المُسلسلة المنسوخة (periodic tasks)	المُجدول اللامتزامن AsyncIOScheduler لمنصة أعمال التنسيقات (APScheduler)

المهام المُجدولة والمنعقدة (Scheduled Tasks)

يتكفل المجدول الزمني بتشغيل المهام الدورية الآتية:

طبيعة المهام والوظيفية المنظورة (Job)	وتيرة المواعيد (Frequency)	الجوهر والقصد (Purpose)
إزالة تنقية التكرار (Alert deduplication cleanup)	كل 5 دقائق مستدامة	محو وتمشيط عناوين التجزئة من التكرار المبالغ (dedup hashes) المنتهية الصلاحية
صيد و استطلاع مُجدول للتهديدات (Scheduled threat hunting)	كل ساعة	مسح وعمليات صيد وقائية للتهديدات (hunting sweeps) مبكّرة
تصدير مقاييس ملقم بروميثيوس (Prometheus metrics export)	كل 60 ثانية	استخراج وضخ مقاييس نحو Prometheus
تحقق انقضاء وصلاحية الموافقات (Approval expiry check)	كل 5 دقائق	الرفض والإقصاء الآلي للموافقات المنقضية المنتهية صلاحيتها

---

مرجع بوابات الشبكة (Network Ports Reference)

صنف الخدمة والعمليات (Service)	البوابات (Port)	بروتوكول الاتصال (Protocol)	الغايات والمناط (Purpose)
واجهة FastAPI	8000	حزم HTTP/WS	ممر وسبل REST API ومنافذ إرتباط وقنوات WebSocket
لوحة واجهة التحكم Next.js Dashboard	3000	عبر HTTP	واجهة المستخدم بالمتصفح Browser UI
محطات المنسق الدائم (Orchestrator)	9000	واجهات تواصل HTTP (A2A)	مُنسق الوكلاء المركزي والضابط الأساس Master agent coordinator
الوكلاء الاختصاصيون (Specialist Agents)	9001-9016	حزم عبر بوابات HTTP (A2A)	15 وكيل تخصصي استجلاب
خادم أداة MCP SIEM	8101	بروتوكول HTTP (MCP)	خادم أدوات ومقايس مركزية الـ SIEM
خادم أداة MCP SOAR	8102	بروتوكول HTTP (MCP)	خادم أدوات ومقايس الـ SOAR
خادم أداة MCP EDR	8103	بروتوكول HTTP (MCP)	خادم أدوات ومقايس الـ EDR
خوادم أدوات MCP Network	8104	بروتوكول HTTP (MCP)	حوايل أدوات الشبكات وخوادم الارتباط
خوادم أدوات وتحليل MCP Malware	8105	بروتوكول HTTP (MCP)	أدوات ومعامل تحاليل البرمجيات الخبيثة
خادم أدوات MCP Threat Intel	8106	بروتوكول HTTP (MCP)	خوادم منصات الاستخبار في التهديدات
خادم أدوات MCP CPS	8107	بروتوكول HTTP (MCP)	خادم أدوات الـ CPS/IoT (أجهزة إنترنت الأشياء)
أدوات MCP UEBA	8108	بروتوكول HTTP (MCP)	خوادم ورصد وتحليل سلوكيات المستخدم UEBA
أدوات التحقيق والأدلة الجنائية MCP Forensics	8109	بروتوكول HTTP (MCP)	أدوات التحري والمختبر الجنائي
خادم مصادر الأدوات المفتوحة MCP OSINT	8110	بروتوكول HTTP (MCP)	خادم أدوات الـ OSINT والمصادر المفتوحه
التقاط رُزم الشبكات MCP Net Capture	8111	بروتوكول HTTP (MCP)	أدوات التقاط ونسخ سير وحزم الشبكات
خادم إنشاء ونسخ تقارير MCP Document	8112	بروتوكول HTTP (MCP)	خادم إنتاج مخرجات التقارير وإصدار المستندات
خادم واستخبار ومكائد MCP Malware Intel	8113	بروتوكول HTTP (MCP)	خادم وعقول أدوات استخبارات البرمجيات الخبيثه ومكائدها
نظام والخدمات السحابية MCP Cloud	8114	بروتوكول HTTP (MCP)	أدوات ومنصات المزودات والموردات السحابية
ثغرات وخوادم استخبار الثغرات MCP Vuln Intel	8115	بروتوكول HTTP (MCP)	خوادم ونظم رصد واستخبار وفجوات الثغرات
قاعدة بيانات PostgreSQL	5432	مجال TCP	قاعدة البيانات الرئيسية الأولى للتشغيل
التخزين المؤقت Redis	6379	مجال TCP	محطة التخزين المؤقت والتدفقات (Cache + Streams)
قاعدة وتوجيه متجهات Qdrant	6333/6334	مجال HTTP/gRPC	قاعدة بيانات المتجهات (Vector database)
رسائل وتراسل المواقع NATS	4222/8222	مسارات TCP/HTTP	مراسلات وتواصل عبر المواقع Cross-site messaging
وسيط ونظارات IoT MQTT Mosquitto	1883/8883	مسارات MQTT/MQTTS	وسيط أجهزة إنترنت الأشياء IoT broker (عادي plain/مشفر TLS)
مُجمع لرقائق القياس المتري OTel Collector	4317/4318	مسارات gRPC/HTTP	تجميع مقايس ومعطيات القياس ومؤشرات الاستنطاق القياسي عن بعد Telemetry intake
مقايس ونظم قواعد بيانات بروميثيوس Prometheus	9090	مسارات HTTP	قاعدة مقاييس بيانات وتقارارير الـ Metrics
شاشات ورؤي استطلاعات مشاهد Grafana	4000	مسارات HTTP	عروض ولوحات استتطلاع القيادة Dashboards

---

دوافع وخلفيات هذا النهج المعماري (Why This Architecture?)

القرار المتخذ (Decision)	الحل البديل (Alternative)	أسباب ودوافع إختيارنا (Why We Chose This)
تدفقات Redis (وليس Kafka)	Apache Kafka	تعمل نُظم منصة AuroraSOC بمواقع مُشتركة متجاورة. توفر تدفقات Redis زمن استعراض واستجابة وتدفق بكسرات الثانية دون أي تواجد لأعباء لآلة جافا الافتراضية JVM overhead. بينما صمم Kafka للتعامل مع النطاقات عبر ومابين مراكز ومُجمعات البيانات المتعددة وهو ما لا نحتاجه.
تبني NATS للاتحادات (ليس Kafka)	Apache Kafka	توفر ملقمات NATS إيصالاً وحيداً دقيقاً (exactly-once delivery)، وتشفير وبنية خفيفة الوزن، وتجميع وتكتير للعُقد الطرفية (leaf-node clustering). وهو مثالي لمزامنه وارتباطات ما بين المواقع بدون الحجم الوظيفي والتشغيلي المزعج لرديفه Kafka.
تبني MQTT للأجهزة (وليس النبض والاستطلاع الترددي HTTP)	بروتوكول HTTP polling	لا تستطيع الأجهزة المُقيدة (Constrained devices) تحمل وتمرير إرهاقات وسماكات العبئ من اتصالات (TCP) الخاصة بالـ HTTP المستبده. لذلك صُنع وطُور MQTT خصيصاً ليناسب مسالك الشبكات الضعيفة، الضئيلة، النطاق المنخفض والغير موثقة. و تضمن إعدادات الـ QoS 2 إيصالاً وحيداً دقيقاً.
تناوب مهام وتمريرات إستلام وتسليم وكلاء A2A handoffs (وليست مكالمات وتمريرات إستدعاء دوال مباشرة direct function calls)	استدعاء واستنفار وظائف دوال Python (Python function calls)	كل وكيل وموظف إختصاصي يعمل كخدمة شبكية وإرتباط وتواصل HTTP بأسلوب مُنفصل ومستقل بذاته — حيث يمكن توسعته، إعادة تشغيله، أو استبداله بمعزل وإستقلاليه عما سواه. تضمن حدود الشبكة وفواصلها المعمارية العزل وإحراز التجرد الوظيفي المطلوب والحمايه.
تبديلات وملحقات MCP للأدوات (وليست ومساند صلده ومُعطلة وثابتة الشفرات hardcoded)	إستجلاب ملفات ووحدات بايثون القياسيه المغلقة (Import Python modules)	صيغة ومحرك MCP يسهل ويجعل الولوج ووصول واستخدامات ونفاذ الأدوات مُيسره وقابلة لعمليات المُراجعة والتدقيق والتدوير والإستبدال والمناوره (auditable and swappable). وبمرونتها يمكن لأي خادم ومقره أن يكون ملائم ومتوائم لـ منصات وطلبات العمل وتوافق أداء حزم MCP. إجراء وتبديل أي تحولات وتحديثات على مسار الأدوات (Tool changes)، لا يتطلب ولن يشترط إعادة إقلاع شامل ومُجدد ومحط ونشر أخر للوكلاء أبدا (agent redeployment).

التالي (Next): وُكَلَاء الذكاء الاصطناعي (AI Agents) → — غَوص عميق وسِبَاحة دقيقة وتفصيل شامل لكل وكيل متخصص.