Mastering Cyber Security in This Crazy World!

الطبعة الأولى · RWID · Ecobook Edition

من إعداد RWID Press.

نشأ هذا الكتاب من حدث حقيقي واحد: هجوم آلي على remoteworker.id في 2 أكتوبر 2026. وبدلًا من إخفائه، كشفناه واتخذنا من ذلك الهجوم مادة للتعليم. يسير كل فصل على النمط نفسه:

النظرية → الطريقة الشائعة في الصناعة → كيف تفعل Ecosphere ذلك → شذرات من الحادثة الحقيقية.

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

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

© RWID. نُشر بوصفه Ecobook.

كلمة تمهيدية

يعمل RWID (Remote Worker Indonesia) منذ عام 2017. وفي عام 2025 انتشر انتشارًا واسعًا، وصاحب هذا الانتشار اتهامات مسيئة من كثيرين لا يعرفونه: بأنه احتيال (scam). وقد رويتُ الجانب الإنساني من القصة في صفحة مرحبًا من هذا التطبيق، ولن أكرر كل ما فيها هنا. الذي ينبغي أن تعرفه نتيجة واحدة فقط: توقف RWID، ثم قرر العودة بعد عام.

وعندما قررتُ العودة، أعدتُ ترتيب الأولويات. ليست الميزات أولًا. وليس المظهر أولًا. الأمان أولًا. والسبب بسيط: تلك الاتهامات بالاحتيال، صحيحةً كانت أم خاطئة، جعلتني أدرك أن RWID لن يستطيع أبدًا إثبات أي شيء إذا انهار نظامه عند أول هجوم. في عام 2025 بنيتُ بسرعة، واستعنتُ بخدمات كثيرة من أطراف ثالثة، وتكيفتُ مع طرائق لا أراها أنا نفسي قابلة للاستمرار. وإحداها أضاعت كل الإجراءات المخزَّنة (stored procedures) في RWID. ومنذ ذلك الحين تمسكتُ بمبدأ واحد: Zero Trust — لا تثق بأي شيء قادم من الإنترنت حتى يثبت نفسه.

ولذلك حين عاد RWID في عام 2026، بنيتُه على أساس مختلف، وتحديتُ العالم علنًا:

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

وُلد هذا الكتاب من تلك الدعوة. فهو يشرح نظرية الأمان التي يقوم عليها، والبنية التي بنيناها، والهجمات الحقيقية التي صددناها فعلًا بعد ساعات من انتشار ذلك المنشور.

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

— RWID Press

كيف تقرأ هذا الكتاب

كُتب هذا الكتاب لـبُناة المنتجات، وخصوصًا من يتعلمون أثناء البناء (vibe coders، والبنّائين المنفردين، من المبتدئين إلى المتوسطين). ولا يفترض أنك تفهم الأمان مسبقًا. كل ما أفترضه: أنك تستطيع بناء تطبيق ويب، وتريد بناءه بمعايير الإنتاج.

يسير كل فصل على النمط نفسه، وهذا النمط هو ما يجعل هذا الكتاب مفيدًا:

1. النظرية. المفهوم الأساسي، وسببه. لا حفظ آلي.
2. الطريقة الشائعة في الصناعة. كيف يتعامل العالم عادةً مع الأمر.
3. طريقة Ecosphere. كيف تطبّقه المنصة التي نبنيها.
4. شذرات من الحادثة. مقتطفات من الهجوم الحقيقي في 2 أكتوبر 2026 توضح تلك النقطة.

يمكنك القراءة بالترتيب، أو القفز إلى الفصل الذي تحتاجه. تشير العلامة → إلى قراءة إضافية. وقد أبقيتُ المصطلحات التقنية الإنجليزية متى كانت هي المصطلح المعتمد (payload وrate limit وquery)، لتتعرف عليها في أي توثيق.

هذا الكتاب لا يغني عن الممارسة. وفي آخره قسم Tools: أزرار لتشغيل محاكاة هجوم في بوابة RWID، وقائمة تحقق لإعدادات الأمان، وقالب لتقرير يُرفع إلى مزوّد خدمة الإنترنت (ISP).

فهرس المحتويات

الجزء 1 · المسرح

• 1 · العالم الحي
• 2 · لمحة عن الحادثة: عنوان IP واحد، ثماني عشرة دقيقة
• 3 · ما هي Ecosphere (ولماذا لا يكفي LXS وحده)

الجزء 2 · لماذا هذا النظام قوي

• 4 · جذر النظرية: Domain-Driven Design & Bounded Context
• 5 · LXS: خدمات Linux بوصفها لبنات البناء
• 6 · Gateway & Auth: مصدر القوة الذي يُصلح بسرعة

الجزء 3 · أسس الأمان

• 7 · الأمان خاصية في النظام، وليس ميزة
• 8 · نموذج التهديدات & سطح الهجوم
• 9 · Deny-by-Default وLeast Privilege وDefense-in-Depth

الجزء 4 · فئات الهجوم & الدفاع

• 10 · الحقن & الاستعلامات المُعامَلة (parameterized)
• 11 · XSS والتهريب (escaping) وContent Security Policy
• 12 · الجلسات & المصادقة: من localStorage إلى HttpOnly
• 13 · إدارة الأسرار
• 14 · SSRF وOpen-Redirect والتحقق من عناوين URL
• 15 · إساءة الاستخدام: تسجيلات الرسائل المزعجة والبوتات والماسحات
• 16 · سلسلة توريد البرمجيات

الجزء 5 · العمليات & التوسع

• 17 · الحافة: WAF وDDoS، ولماذا يكاد الأصل (origin) لا يشعر بشيء
• 18 · المراقبة (Observability) & التنبيه: حارس يصرخ
• 19 · استجابة هادئة للحوادث
• 20 · الجاهزية للتوسع & الحصص

الجزء 6 · دراسة حالة & أدوات

• 21 · دراسة حالة: التسلسل الزمني الكامل لـ2 أكتوبر 2026
• 22 · بنية أمان Ecosphere من الطرف إلى الطرف
• 23 · Tools: اختبر نظامك بنفسك

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

1 · العالم الحي

قبل الحادثة، وقبل النظرية، ثمة أمر ينبغي أن تراه أولًا. هذا وجه RWID:

ذلك الـGlobe ليس زينة. لم يُصنع عشوائيًا. لقد صُمم بوصفه مراقبًا عالميًا للنظام في الزمن الحقيقي — شاشة واحدة تجيب عن سؤال «ما الذي يحدث الآن في كل أنحاء عالم RWID؟» دون الحاجة إلى فتح لوحة تقنية.

ما الذي يراقبه

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

وهو في الوقت نفسه أمران: دليل اجتماعي (يرى الزائر أن المجتمع حقيقي ونشط) ومراقب تشغيلي (من أين تأتي حركة المرور، وأي العقد سليمة). شاشة واحدة، ووظيفتان.

هذا ما يظهر عند وقوع هجوم

هذه لقطة للـGlobe أثناء هجوم 2 أكتوبر 2026. ظهرت أسماء غريبة من نقطة واحدة بعينها — Cikarang — متتابعة وسريعة وغير طبيعية: سلسلة بلا انقطاع من المدينة نفسها، بنمط لا يمكن أن يقوم به إنسان عادي. وفجأة امتلأ العالم الهادئ قبل لحظات بمصدر واحد لا غير.

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

تلك هي القيمة الحقيقية للمراقب: ليس مجرد عرض البيانات، بل جعل ما هو خاطئ مرئيًا ومسموعًا — يستحيل تفويته.

والـGlobe ليس الوحيد الذي يصرخ. في قناة Telegram، يرسل بوتنا التنبيه نفسه — تلقائيًا، من حارس (guard) يراقب الحافة:

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

لماذا يهم هذا في كتاب عن الأمان

لأنه هنا بالذات يتبين الشذوذ. حين يُراقَب نظام بوصفه عالمًا حيًا واحدًا، يبرز كل ما هو غير طبيعي — اسم غريب، ونبضة في غير موضعها. ليس لأن أحدًا يقرأ السجلات (logs) في الثالثة فجرًا، بل لأن العالم نفسه يُظهر أن شيئًا ما خاطئ.

المراقب الجيد لا يعرض الأرقام فحسب؛ بل يجعل ما هو خاطئ يبدو خاطئًا. والـGlobe هو أوضح مثال على ذلك المبدأ، والحادثة التي نناقشها ابتداءً من الفصل 2 هي برهانه.

→ الفصل 2 · لمحة عن الحادثة.

2 · لمحة عن الحادثة: عنوان IP واحد، ثماني عشرة دقيقة

قبل الدخول في النظرية، لنرَ أولًا ما حدث فعلًا. هذا مقتطف سبق أن نشرناه بوصفه مذكرة هندسية في توثيق Ecosphere، بعد تبسيطه لقارئ هذا الكتاب.

في 2 أكتوبر 2026، نحو الساعة 18:16–18:37 بتوقيت غرب إندونيسيا (WIB)، شغّل عنوان IP واحد في Cikarang بجاوة الغربية ماسح ثغرات آليًا ضد remoteworker.id. وخلال تلك الفترة، حظرت حافتنا (Cloudflare) 397 طلبًا. استهدف ذلك الماسح نقطتَي الدخول والتسجيل (/signin و/signup و/api/auth/register)، وأرسل مجسّات حقن، وفحص مسارات الثغرات في WordPress المعروفة منذ عقود.

المهم ليس الرقم. المهم هو ما لم يحدث:

• لم تُسرَّب أي بيانات على الإطلاق.
• بقي المعالج (CPU) في خادم الإنتاج دون الحمل الطبيعي؛ والمضيف لم يكد يرمش.
• لم يستطع أي حساب مزعج الدخول، لأن التحقق من البريد الإلكتروني إلزامي.
• خادمنا القديم لم يرَ أصلًا معظم تلك الطلبات، لأنها رُفضت كلها عند الحافة.

الأثر الوحيد الذي أفلت: 43 حسابًا مزعجًا سُجِّلت من ذلك العنوان IP. حذفناها كلها؛ وبقي 30 مسجِّلًا حقيقيًا سالمين.

الدرس الأول: الهجوم الذي يجعلك أقوى ليس الهجوم الفاشل، بل الهجوم الذي كُشف واحتُوي وأُبلغ عنه بالأدلة.

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

→ تابع إلى الفصل 3 · ما هي Ecosphere لفهم الأساس الذي جعل كل هذا ممكنًا.

3 · ما هي Ecosphere (ولماذا لا يكفي LXS وحده)

شرح «LXS» دون شرح Ecosphere أشبه بشرح اللبنة دون شرح البناء. لذا نبدأ من البناء.

المشكلة التي نريد الإجابة عنها

الطريقة المعتادة لبناء التطبيقات في عشرينيات هذا القرن تكدّس الطبقات: يُغلَّف التطبيق في حاوية (container)، وتُنسَّق الحاويات عبر Kubernetes، ثم تُضاف شبكة الخدمات (service mesh)، ووسيط الرسائل (message broker)، وسلسلة من الخدمات المُدارة. وهذا معقول للفرق الكبيرة. أما لشخص واحد يبني منتجًا، فهو عبء: كل طبقة تزيد من السطح الذي قد يخطئ، و— وهو الأهم لهذا الكتاب — السطح الذي يمكن مهاجمته.

تتخذ Ecosphere اتجاهًا آخر. فهي ترى التطبيق مجموعة من القدرات الصغيرة المتكاملة، لا كتلة واحدة عملاقة ولا حاويات لا تُحصى.

المصطلحات الأساسية

• Domain (النطاق). مسؤولية واحدة واضحة ومستقلة — الهوية، والمقالات، والمحفظة، والإشعارات. لكل نطاق بياناته الخاصة ويتحدث عبر عقد (contract)، لا عبر استيراد الشيفرة من بعضها.
• LXS (Linux Services). الطريقة التي يُعبَّأ بها النطاق في ملف تنفيذي واحد جاهز للتشغيل مع عقد صريح: المتغيرات المطلوبة، والمنفذ، والذاكرة، والمسارات (routes) التي يفتحها. التفاصيل في الفصل 5.
• Estate. سلسلة من LXS + الشيفرة الأساسية (domain core) التي تشكّل تطبيقًا كاملًا واحدًا. remoteworker.id هو estate.
• Registry (السجل). فهرس لـLXS ذات إصدارات. تعيد استخدام القدرات التي اختُبرت بدل أن تكتبها من جديد.

لماذا يهم هذا في الأمان

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

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

جرّب بنفسك

Ecosphere ليست نظرية محبوسة في هذا الكتاب. المنصة مفتوحة للتجربة — من التثبيت والتوثيق إلى تركيب تطبيقك الأول:

→ https://getecosphere.com

كلما زاد عدد من يبنون عليها، زاد عدد من يسهمون في تقوية الأساس نفسه. وهذا جزء من القصد: أمان يُشارَك، لا يُصان كلٌّ على حدة.

في الفصل التالي نتعمق في جذريها النظريين — Domain-Driven Design ومفهوم LXS نفسه — قبل أن ننتقل إلى الفصل الأهم في قوتنا: Gateway وAuth.

4 · جذر النظرية: Domain-Driven Design & Bounded Context

قبل LXS كانت الفكرة أولًا: Domain-Driven Design (DDD). لن يعلّمك هذا الكتاب DDD كاملًا، لكن ثمة مفهومًا واحدًا منه ينبغي أن تفهمه، لأن أمننا يرتكز عليه.

Bounded context: كلمة واحدة، معنى واحد

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

Bounded context هو الجواب: ضع حدودًا واضحة. لكل سياق نموذجه الخاص، وبياناته الخاصة، وعقده الخاص. ولا يستعير بعضها أنواع بيانات بعض.

القواعد الملزِمة (ولماذا هي مسألة أمان)

النظام المبني على حدود صارمة له خصائص ثمينة للأمان:

1. لا استيراد بين النطاقات. يتواصل النطاق مع النطاقات الأخرى عبر عقد عام (عادةً HTTP)، لا باستدعاء دواله الداخلية. وهذا يعني أن سطح الهجوم في النطاق مغلق بإحكام: لا يمكن الوصول إليه إلا عبر الباب المعلَن.
2. تخزين منفصل. لكل نطاق قاعدة بياناته. والثغرة في نطاق واحد لا تفتح قاعدة البيانات كلها تلقائيًا. فنطاق الانفجار (blast radius) صغير.
3. مراجع، لا نسخ. يحفظ النطاق إشارة إلى بيانات يملكها نطاق آخر (معرّف ID)، لا نسخة منها. فلا توجد بيانات مكررة وغير متسقة في أماكن كثيرة.
4. هوية صريحة عند الحدود. عمليات الكتابة لا تستنتج المالك من الرمز (token) بصمت؛ بل تطلب دليلًا صريحًا.

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

من المفهوم إلى الملف التنفيذي

يشرح DDD كيف تفكر في الحدود. لكنه لا يشرح كيف تعبّئ تلك الحدود في شيء يمكن تشغيله وتركيبه بأمان. لذلك نحتاج إلى LXS — موضوع الفصل التالي.

→ الفصل 5 · LXS: خدمات Linux بوصفها لبنات البناء.

5 · LXS: خدمات Linux بوصفها لبنات البناء

LXS هي الطريقة التي يُعبَّأ بها النطاق في ملف تنفيذي واحد جاهز للتشغيل، مع عقد يقرأه الإنسان والآلة معًا. ويعمل أصليًا (native) داخل LXC — بلا طبقة محاكاة افتراضية ثقيلة، وبلا صور حاويات متراكمة.

ما الذي يتضمنه عقد LXS

تعلن كل LXS عن نفسها علنًا:

• متغيرات البيئة التي تحتاجها (وأيها أسرار).
• المنفذ (port) الذي تشغله.
• الموارد (الذاكرة والقرص) التي تطلبها.
• المسارات التي تفتحها — وعلى أي مستوى من الوصول (public وauth و role:...).
• الشبكة: من أين يأتي الدخول، وإلى أين يكون الخروج.

هذا العقد ليس توثيقًا سلبيًا. فعند النشر (deploy)، تتحقق المنصة مما إذا كان estate يمنح فعلًا ما طُلب — وترفض التركيب غير المطابق. ولا تستطيع LXS أن تصل خِفية إلى شيء لم تعلن عنه.

إصدارات لا تتغير

تُنشر LXS في إصدارات غير قابلة للتغيير (immutable): [email protected] تعني ذلك الملف التنفيذي بعينه. فلا تعدّل إصدارًا نُشر؛ بل تصلح بنشر إصدار جديد. والنتيجة أن إصلاح الثغرة يصبح فعلًا حاسمًا وقابلًا للتتبع: إصدار جديد واحد، وسجل تغييرات واحد، وقرار واحد بالترقية في الـestate المتأثر.

نطاق واحد، ملف تنفيذي واحد

قاعدة «LXS واحدة = نطاق واحد» تُبقي الملف التنفيذي صغيرًا ومركّزًا. وسطح الهجوم فيه صغير بدوره: هذه العملية لا تحمل قدرات لا تحتاجها. لا مفسّر ضخم، ولا إطار عمل شامل؛ فقط ما هو لازم.

قدرات مشتركة، لا نسخ

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

وثمة LXS اثنتان هما الأكثر حسمًا في قوتنا. ونناقشهما في الفصل التالي.

→ الفصل 6 · Gateway & Auth: مصدر القوة.

6 · Gateway & Auth: مصدر القوة الذي يُصلح بسرعة

لو كان في هذا الكتاب فصل واحد أريدك أن تتذكره، فهو هذا الفصل.

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

نحن نفعل العكس. فثمة LXS اثنتان تتخذان تقريبًا كل القرارات الأمنية، وكلتاهما مركّبتان أمام كل estate.

Gateway: الباب الأمامي الذي يرفض افتراضيًا

الـGateway هو المدخل الوحيد من الإنترنت إلى خدمات الـestate. وهو يعمل بمبدأ deny-by-default: لا يمكن عبور مسار إلا إذا كتبه الـestate صراحةً، مع مستوى الوصول (public وauth و role:superadmin). لا «أعِد توجيه كل شيء». ولا طرق مختصرة.

والنتائج:

• لا تحتاج الخدمات الداخلية (ولا يجوز لها) أن تُكشف مباشرة. فالباب الأمامي وحده هو الذي يتحدث إلى العالم الخارجي.
• يُفحص كل طلب مرة واحدة في مكان واحد. وإذا ظهرت قاعدة جديدة أو ثغرة في منطق الوصول، أُصلحت في الـgateway، فيحصل كل estate عليها.
• حين تعلّمنا من حادثة مثل 2 أكتوبر، أضفنا القواعد في نقطة واحدة فقط — فأصبح الـestate كله آمنًا في لحظتها.

Auth: سلطة هوية واحدة

Auth هي LXS التي تمسك الهوية: كلمة المرور، والجلسة، والرمز (token)، والدور. ويمكنها أيضًا أن تعمل بوصفها مزوّد هوية (OIDC) بحيث تتشارك عدة تطبيقات حسابًا واحدًا. ولأن كل الـestates تستخدم Auth نفسها، فنموذج الجلسة موحّد كذلك — وهذا مهم، لأن معظم هجمات الويب تستهدف الجلسة.

ومن أكثر القرارات أثرًا نقل الجلسة من localStorage إلى cookie من نوع HttpOnly. لا يستطيع أي سكربت في الصفحة قراءة cookie HttpOnly، ولذلك فثغرة XSS واحدة لا تعني تلقائيًا سرقة الجلسة. وقد أُنجز هذا التغيير أيضًا مرة واحدة في Auth، ثم سرى على كل estate يستخدمها. (القصة الكاملة في الفصل 12.)

لماذا هذه «قوة منتشرة»

تخيّل ثلاثة عوالم:

• عالم النسخ. يُنسخ تسجيل الدخول في 10 تطبيقات. تُكتشف ثغرة في الجلسة. تصلح 10 أماكن. يفوتك بعضها. وما فاتك يبقى هشًا أشهرًا.
• عالم الكتلة الواحدة (monolith). إصلاح واحد يصل إلى كل شيء — لكن في ذلك التطبيق وحده. وتبقى التطبيقات الأخرى بمشكلاتها الخاصة.
• عالم LXS. تُصلح Auth مرة واحدة، ويُرفع إصدارها، ويمكن لـكل estate يركّبها أن يرتقي. إصلاح واحد، ومدى واسع، ومسجَّل.

لهذا أسمّي الـgateway وauth مصدر قوتنا. ليس لأنهما كاملتان، بل لأنهما تمكّناننا من التحرك بسرعة حين يُكتشف النقص — وهذا أهم بكثير من ادعاء «آمن» لا يمكن إثباته.

شذرات من الحادثة

حين أطلق ماسح 2 أكتوبر هجماته على مسارات الدخول، لم تكن كل خدمة هي التي صدّت. بل الـgateway هو الذي رفض الغالبية، وAuth هي التي ضمنت بقاء جدار التسجيل الناري (التحقق من البريد) سليمًا. لم نضطر إلى لمس عشرين مكوّنًا؛ يكفي باب واحد وسلطة واحدة.

→ هنا ينتهي الأساس المفاهيمي. الجزء 3 يبدأ من مبادئ الأمان التي تسري على أي نظام، سواء أكان LXS أم لا.