تمكين GuardDuty عبر المؤسسة

يُعد تفعيل GuardDuty في حساب واحد أمرًا سهلًا، لكن البيئات الحقيقية تضم حسابات عديدة. ويؤدي تفعيل الكشف وإدارته يدويًا عبر جميع الحسابات إلى الأخطاء وترك ثغرات. وتحل AWS ذلك من خلال نموذج المسؤول المفوض المرتبط بـ AWS Organizations.

تتيح AWS Organizations تجميع حسابات متعددة ضمن حساب إدارة واحد، وترتيبها في وحدات تنظيمية (OUs). وهي الأساس للحوكمة متعددة الحسابات. وتت интегر العديد من خدمات الأمان، بما في ذلك GuardDuty، مع Organizations للعمل مركزيًا عبر كل حساب عضو.

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

يُعد حساب إدارة Organizations شديد الحساسية، ولذلك توصي AWS بالاحتفاظ به للفوترة وإدارة الحسابات فقط. ويحد تفويض إدارة الأمان إلى حساب منفصل من نطاق التأثير، ويطبق فصل المهام، وهو من أفضل ممارسات Well-Architected التي يفضلها الاختبار.

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

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

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

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

يتطلب إعداد ذلك تمكين الوصول الموثوق لـ GuardDuty في Organizations، ثم تسجيل المسؤول المفوَّض. بعد ذلك، يدير المسؤول العضوية والإعدادات مركزيًا. هذا إعداد يُجرى مرة واحدة ويحقق فوائد مع توسع المؤسسة.

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

قبل التكامل مع Organizations، كانت الحسابات تُربط عبر دعوة: إذ يرسل المسؤول دعوة إلى كل عضو، وكان على العضو قبولها. لا تزال هذه الطريقة تعمل، لكنها لا تتوسع بسهولة ولا تمكّن الحسابات الجديدة تلقائيًا. وتُفضَّل طريقة Organizations باستخدام مسؤول مفوَّض، لأنها تدير العضوية مركزيًا وتمكّن الحسابات الجديدة تلقائيًا، وهو ما تعتبره الاختبارات أفضل ممارسة حديثة.

طبّق الاكتشاف على مستوى المؤسسة.

وسّع نطاق GuardDuty باستخدام AWS Organizations ومسؤول مفوَّض (حساب أمان مخصص، وليس حساب الإدارة). يمكّن المسؤول GuardDuty عبر حسابات الأعضاء، ويستخدم التمكين التلقائي للحسابات الجديدة، ويعرض جميع النتائج مركزيًا. تذكّر أن GuardDuty تعمل على مستوى المناطق، لذا قم بتمكينها لكل منطقة للحصول على تغطية كاملة.