اكتشاف استخدام الحساب الجذر

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

توصي AWS باستخدام مستخدم root فقط للمهام القليلة التي تتطلبه، ثم عدم استخدامه مجدداً. ينبغي تمكين MFA لـ root، وإزالة مفاتيح الوصول الخاصة به بالكامل، وإنشاء هويات IAM أو مستخدمين في Identity Center للعمل اليومي. وبعد عزله، ينبغي أن يكون النشاط المشروع لمستخدم root نادراً ومخططاً له.

نظراً إلى أن root لا ينبغي أن يسجل الدخول إلا نادراً جداً، فإن تسجيل دخول غير متوقع إلى root يمثل مؤشراً قوياً على الاختراق أو مخالفة السياسات. ويُعد اكتشاف ذلك أحد عناصر المراقبة الأساسية في CIS Benchmark وسيناريو متكرراً في الاختبارات: فالإجابة المتوقعة هي مرشح مقياس وتنبيه يغذيهما CloudTrail، وليس مراجعة يدوية.

يستخدم الاكتشاف ثلاثة مكونات تعرفونها بالفعل: يسجل CloudTrail أحداث تسجيل الدخول وواجهة API، وتستقبل CloudWatch Logs هذه الأحداث عند تهيئة CloudTrail لتسليمها إلى مجموعة سجلات، ثم يحول مرشح المقياس والتنبيه أحداث root إلى إشعار فوري. ويجب توفير كل مكون حتى تعمل السلسلة.

في حدث CloudTrail، تكون قيمة الحقل userIdentity.type مساوية لـ Root عندما ينفذ مستخدم root الإجراء. ويمكن لمرشح مقياس مطابقة هذا الحقل. ولتجنب الضوضاء الناتجة عن الأحداث المؤتمتة الاعتيادية، تستبعد المرشحات غالباً أيضاً أحداث خدمات AWS، بحيث لا تطلق التنبيه إلا إجراءات root البشرية الحقيقية.

يكتب CloudTrail افتراضياً إلى S3، وليس إلى CloudWatch Logs. ولإطلاق التنبيه في وقت قريب من الوقت الفعلي، يجب تهيئة المسار أيضاً من أجل تسليم الأحداث إلى مجموعة CloudWatch Logs. ويتطلب ذلك دور IAM يسمح لـ CloudTrail بالكتابة إلى مجموعة السجلات. ومن دون خطوة التسليم هذه، لن يجد مرشح المقياس شيئاً لمطابقته.

أنشئوا مرشح مقياس في مجموعة سجلات CloudTrail باستخدام نمط يطابق userIdentity.type = Root. واربطوا كل تطابق بمقياس مثل RootAccountUsageCount بقيمة واحد. وهكذا يزيد كل إجراء ينفذه root من مقياس يمكنكم مراقبته، فتحولون حقلاً مدفوناً في JSON إلى إشارة قابلة للقياس.

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

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

عندما يُطلق التنبيه، تعاملوا معه باعتباره حادثة إلى أن يثبت العكس. وتحققوا مما إذا كان النشاط مهمة مخططاً لها ومصرحاً بها. وإذا لم يكن كذلك، فأمّنوا الحساب: غيّروا كلمة مرور root، وتحققوا من سلامة MFA، وراجعوا إجراءات root الأخيرة في CloudTrail، وابحثوا عن هويات IAM أو مفاتيح جديدة ربما أنشأها مهاجم.

يربط اكتشاف استخدام root بين CloudTrail وCloudWatch Logs ومرشحات المقاييس والتنبيهات وSNS في عنصر تحكم واقعي واحد. توقعوا أسئلة تقترح إجاباتها الخاطئة المراجعة اليدوية أو تطبيق سياسات IAM على root أو استخدام SCPs. أما الإجابة الصحيحة فهي دائماً الاكتشاف المؤتمت مع الإشعار الفوري، لأن root لا يمكن تقييده، بل يمكن مراقبته فقط.

اختبروا نمط اكتشاف استخدام root.

يتمتع مستخدم root بصلاحيات غير مقيّدة، وينبغي عزله مع تفعيل MFA ومن دون مفاتيح وصول. ويُعد أي استخدام له حدثاً عالي الدلالة. اكتشفوه من خلال تسليم CloudTrail إلى CloudWatch Logs، وإضافة مرشح مقياس على userIdentity.type = Root، ثم إطلاق تنبيه CloudWatch إلى موضوع SNS. وفي المؤسسات، يوحّد مسار المؤسسة هذا الاكتشاف عبر جميع الحسابات.