الانتقال إلى المحتوى الرئيسي
كتبت سياسة جدار حماية — موقف حجب افتراضي، وdeny على shell.exec، وقائمة سماح egress — وتعتقد أنها صحيحة. لكن قلبها للوضع الفعّال مقابل حركة مرور الوكيل الإنتاجية قفزة إيمان: قاعدة واحدة فضفاضة وأنت تحجب استدعاءات يصدرها وكلاؤك بشكل مشروع. وضع الظل لجدار الحماية هو مفتاح الطرح الآمن. إنه علامة لكل سياسة تخبر البوابة بأن تقيّم السياسة تماماً كما ستفعل في الإنتاج، وتسجّل كل شيء، لكن لا تحجب شيئاً. يُخفَّض كل حكم فارض إلى audit، ويُسبَق سبب الحدث بـ [shadow] would … فتقرأ بالضبط ما كانت السياسة ستفعله — دون أن تكون فعلت أي شيء بعد.
وضع الظل علامة على السياسة، تُضبط في وحدة التحكم (أو مسارات الإدارة /api/workspace/firewall/policies، التي تستخدم جلستك / رمز الوصول — وليس مفتاح ترحيل sk-orca-…). تبديله إجراء Developer+. استدعاءات ترحيل /v1/* لوكيلك لا تتغيّر.

​
1. ماذا يفعل وضع الظل لجدار الحماية

عندما تكون علامة shadow_mode للسياسة مفعّلة، تجري البوابة التقييم الكامل — تحل السياسة، تجتاز القواعد بترتيب الأولوية، تختار حكماً — ثم، قبل أن يحدث الحكم أثره مباشرةً، تخفّض أي شيء كان سيغيّر الاستدعاء:
الحكم المُحَلتحت وضع الظل
deny← audit، السبب [shadow] would deny — …
sanitize← audit، السبب [shadow] would sanitize — …
pending_approval← audit، السبب [shadow] would pending_approval — …
allow / auditدون تغيير (غير حاجبة أصلاً)
يمر الاستدعاء دائماً. لا شيء يُحجب، ولا تُنقّح وسائط، ولا يُفتح تعليق بشري — لكن الحدث يُسجَّل بالحكم الذي كانت السياسة ستنتجه، فتقرأ تغذية الأحداث كتشغيل إنتاجي مع إطفاء الفرض.
بادئة [shadow] would … هي فلترك الرئيسي. رتّب تغذية الأحداث لأجلها ولديك قائمة كاملة بكل استدعاء توشك هذه السياسة على البدء في حجبه، قبل أن تحجب واحداً.

​
2. طرح ملموس واحد

لنقل إن لديك سياسة prod-agents بقاعدة deny على أوامر shell المدمّرة، وتريد تأكيد أنها لن تتعثّر على أي شيء مشروع.
1

فعّل وضع الظل

في Security → Firewall → Policies، افتح prod-agents، بدّل Shadow mode إلى مفعّل، واحفظ. تحتفظ السياسة بربطها وقواعدها — إنها تتوقف عن الفرض فحسب.
2

دع حركة المرور الحقيقية تتدفّق

يبقى وكلاؤك يستدعون البوابة تماماً كما كانوا. يُقيَّم كل استدعاء أداة؛ لا شيء يُحجب. امنحها نافذة تمثيلية — طويلة بما يكفي لتغطية مزيج أدواتك الحقيقي.
3

اقرأ الرفضات المحتملة

افتح الأحداث وفلتر لأجل سبب [shadow]. يُظهر كل صف الأداة والسطح والتشغيل والقاعدة التي طابقت — فـ [shadow] would deny — destructive shell command على استدعاء shell.exec هو بالضبط ما ستراه في الإنتاج، ناقص الـ HTTP 400.
4

أطفئ وضع الظل

بمجرد أن تُظهر التغذية أن السياسة تُطلق على ما تتوقعه ولا شيء لا تتوقعه، بدّل وضع الظل إلى مطفأ. من الاستدعاء التالي فصاعداً، تصبح أحداث [shadow] would deny تلك رفضات firewall_blocked حقيقية.
إذا أظهر وضع الظل إيجابية كاذبة — استدعاء مشروع طابق قاعدة deny — أصلح القاعدة (شدّد الـglob أو أضف عبارة وسائط) بينما لا تزال في الظل، وراقب التغذية مجدداً. تكرّر مقابل حركة المرور الحقيقية بنصف قطر انفجار صفري.

​
3. ما لا يخفّفه وضع الظل

وضع الظل معاينة لـالسياسة، وليس مفتاح إطفاء رئيسياً.
المهارات المحكومة تظل تفرض تحت سياسة ظل. مهارة في وضع block تظل ترفض، ومهارة في وضع quarantine تظل تعلّق للموافقة، حتى عندما تكون السياسة المطابقة في الظل. وضع فرض المهارة خاصية لحالة مراجعة المهارة، وليس للسياسة التي تعاينها — تظليل سياسة لم يكن أبداً طلباً لرفع الحجر الصحي عن مهارة. تبقى السياسة موسومة كمظلَّلة في الأحداث، لكن تصرّف المهارة يفوز.
بضعة حدود أخرى تستحق المعرفة:
فقط الأحكام الفارضة (deny وsanitize وpending_approval) تُخفَّض. allow أو audit يمرّر الاستدعاء أصلاً، فلا شيء لتخفيفه — تلك الأحداث لا تزال تحمل وسام الظل فيمكنك معرفة أن السياسة كانت في الظل حين سُجِّلت.
قاعدة cap_cost تُحَل إلى allow أو deny ملموس بناءً على الإنفاق المتراكم للتشغيل، وذلك الحكم المُحَل هو ما يخفّضه وضع الظل بعد ذلك — رفض تجاوز سقف محتمل يظهر كـ [shadow] would deny كأي رفض آخر.
يعيش وضع الظل على كل سياسة باستقلالية. يمكنك تظليل سياسة جديدة تماماً بينما تظل أخرى مجرَّبة في المعارك تفرض — لا يوجد مفتاح ظل على مستوى مساحة العمل تنسى إطفاءه.

​
4. وضع الظل مقابل أقراص الطرح الأخرى

يمنحك جدار الحماية ثلاثة عناصر تحكم مختلفة بـ “لا تكسر شيئاً بعد”. تحل مشاكل مختلفة:
التحكمالنطاقالسؤال الذي يجيب عليه
وضع الظلسياسة واحدة”ماذا كانت هذه السياسة ستحجب لو فرضتها؟“
حكم افتراضي auditسياسة واحدة”سجّل كل شيء لا تسمّيه قاعدة، لا تحجب شيئاً.”
وضع observeمساحة العمل”أي الأدوات تعمل بـ لا سياسة تغطّيها؟”
وضع الظل هو ما تلجأ إليه عندما يكون لديك سياسة حقيقية فارضة وتريد قياس أثرها الدقيق قبل أن تغيّر حركة المرور. حكم افتراضي بـ audit هو لـ الذيل غير المطابق لسياسة واحدة؛ ووضع observe يتعلّق بـ ثغرات التغطية عبر مساحة العمل، وليس بفرض سياسة محددة.
يمكنك تكديسها. سياسة حجب افتراضي جديدة تحت وضع الظل هي ألطف طرح ممكن: حتى أرضية الحجب الافتراضي تسجّل فقط [shadow] would deny بدلاً من الحجب، فترى المجموعة الكاملة من الاستدعاءات التي لا تغطّيها قواعد السماح لديك بعد قبل أن يصبح الحجب حياً.

​
5. حزم الامتثال تهبط في الظل أولاً

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

​
6. تبديله

في وحدة التحكم، وضع الظل مبدّل في محرر السياسة. نفس العلامة مكشوفة على API الإدارة كـ shadow_mode على كائن السياسة — تستخدم هذه المسارات جلستك / رمز الوصول وتتطلب Developer+:
الطريقة والمسارالدورملاحظة
PUT /api/workspace/firewall/policiesDeveloper+اضبط shadow_mode: true / false على السياسة في الجسم.
GET /api/workspace/firewall/policies/:idMemberاقرأ حالة shadow_mode الحالية لسياسة.
كل تغيير يكتب صف تدقيق ويرفع عدد version للسياسة، فتفعيل الظل وإطفاؤه نفسه متعقَّب.

​
أين تذهب بعد ذلك

إنشاء وربط سياسة

الإعداد من خطوتين الذي يطرحه وضع الظل — أنشئ السياسة، اربط مفتاحاً.

سجل الأحداث

حيث يظهر [shadow] would … — فلتر، تعمّق في التشغيلات والقواعد.

الأحكام

الأحكام الفارضة التي يخفّضها وضع الظل، وماذا يفعل كل منها حياً.

أوضاع الفرض

كيف يلائم الظل والتدقيق وobserve نموذج الفرض الأوسع.
للتهديدات التي توقفها سياسة بمجرد إطفائك للظل، انظر استدعاءات الأدوات الخطرة و الوكالة المفرطة.