Retest في Active Directory: مشروع بخمس تغييرات يعلّمك تتأكد أن الثغرة انقفلت والعمل ما تعطل

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

بنجهز مشروع لاب مستقل بخمس حالات من Active Directory والخدمات المرتبطة به، ونكتب لكل واحدة معيار نجاح ودليلًا مناسبًا. الفكرة تصلح للتدريب على تقارير اختبار الاختراق والتحضير لـCRTP وCRTE، وليست متطلبًا رسميًا لأي امتحان. ما ننفذ تغييرات على بيئة حقيقية في المقال؛ مسؤول اللاب يجهز الحالات ويطبق التصحيحات، وأنت تقرأ وتقارن وتختبر عمليات تدريبية متفقًا عليها.

جهز سجلًا قبل التصحيح حتى تعرف ماذا تعيد اختباره

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

في مشروعنا خمس حالات: عضوية دعم تتسع إلى إدارة خدمة، وتفويض OU يشمل كائنًا حساسًا خارج الدور، وسياسة مصادقة بقيت في Audit بدل الفرض المعتمد، وتطبيق LDAP لا يحقق متطلبات الخادم، وحساب تطبيق يملك عملية غير مطلوبة في قاعدة تدريب. كل واحدة لها مالك ومتطلب ودليل؛ لا تجمعها في نتيجة واحدة اسمها AD غير آمنة.

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

حدد حالات السماح والمنع مقدمًا. لكل تغيير توجد وظيفة ينبغي أن تستمر، وعلاقة أو عملية ينبغي أن تتوقف. لا تختار معاييرك بعد ظهور النتيجة حتى تبدو ناجحة. المعايير المكتوبة تجعل الإغلاق واضحًا، وتساعد المسؤول يفهم أن إعادة الاختبار تقيس التصحيح المتفق عليه وليس توقعًا جديدًا أضفته في آخر اللحظة.

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

الحالة الأولى: عضوية أزيلت، لكن هل أُزيلت العلاقة المطلوبة؟

كان مستخدم الدعم lab-support-user ضمن مجموعة تمنحه علاقة إدارة غير معتمدة على هوية خدمة. يقول المسؤول إنه أزال العضوية. ابدأ بقراءة المجموعة المحددة والعلاقة الحالية من المصدر الذي تعتمد عليه، ثم راجع هل هناك مسار عضوية آخر داخل النطاق يحقق القدرة نفسها. إزالة صف واحد من القائمة لا تضمن أن كل ما تحتاجه النتيجة تغيّر.

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

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

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

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

الحالة الثانية: تضييق ACE يحتاج قراءة الأب والهدف

كان تفويض على Training-Users يصل إلى حساب خدمة لا ينبغي أن يديره الدعم. التصحيح المقترح يضيق الخاصية أو نوع الكائن أو جمهور الإذن وفق التصميم. راجع ACE في مكان تعريفها، ثم كائن الخدمة الذي كان يستقبلها، وكائن مستخدم عادي ينبغي أن يبقى ضمن التفويض المشروع. هذه ثلاث قراءات تجيب أسئلة مختلفة.

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

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

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

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

الحالة الثالثة: الانتقال من Audit إلى Enforce ليس لقطة Boolean فقط

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

استخدم حساب تدريب ينطبق عليه التصميم ومصدرًا معتمدًا وآخر غير معتمد، مع طريقة بدء سياق معروف يحددها المدرب. لا تستخدم حسابًا مستثنى في التقنية ثم تعمم النتيجة، ولا تقارن جلسة قديمة حصلت على سياق قبل التغيير بمحاولة جديدة من غير توضيح. شروط التجربة جزء من الدليل.

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

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

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

الحالة الرابعة: تحديث عميل LDAP مع بقاء المتطلب الأمني

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

اقرأ المتطلب الفعلي على الخادم وسياق العميل، ثم راجع مراحل TLS وBind والبحث بالقدر الذي يخص الحالة. نجاح جلب المستخدمين لا يشرح وحده حماية الجلسة. كذلك نجاح TLS لا يثبت أن كل شروط المصادقة والقناة المطلوبة صارت متحققة. كل دليل يحتاج أن يُستخدم للمستوى الذي يقيسه.

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

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

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

الحالة الخامسة: تضييق صلاحية التطبيق في SQL

كان حساب التطبيق يملك عملية زائدة في قاعدة TrainingReports، بينما دوره المعتمد قراءة مجموعة بيانات تدريبية محددة. التصحيح ينبغي أن يزيل الزيادة ويحافظ على القراءة اللازمة. ابدأ باتصال التطبيق أو سياق تدريب يمثله وفق خطة المالك، ثم اقرأ Login وUser واسم القاعدة حتى تتأكد أنك تقيس الهوية والمورد نفسيهما.

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

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

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

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

نتائج الإغلاق: ناجح أو جزئي أو غير محسوم، وكل واحدة لها معنى

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

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

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

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

للمراجعة داخل المجتمع، هذه مقالات تكمل حالات المشروع:
تفويض ACL وكيف تبني الدليل: https://courses.cyberpts.com/community/139/mn-acl-ala-ntyjh-amnyh-kyf-tthbt-altfwyd-alzayd-fy-active-directory-bdwn-ma-tbal
المراقبة والفرض في سياسات المصادقة: https://courses.cyberpts.com/community/136/authentication-policy-silos-alhsab-mrtbt-balsyash-bs-hl-almna-mtbq-fala-afhm-aud
متطلبات LDAP والتوافق: https://courses.cyberpts.com/community/133/ldap-signing-wchannel-binding-alfrq-alamly-wlysh-ldaps-whdh-ma-ythbt-aktmal-alhm
WinRM وهوية SQL: https://courses.cyberpts.com/community/142/winrm-yfth-wsql-yrfd-mn-dakhl-aljlsh-afhm-second-hop-whwyh-login-wuser-qbl-tghyy
ولتعريف مسارات التدريب من الجهات الرسمية: https://www.alteredsecurity.com/adlab وhttps://www.alteredsecurity.com/redteamlab