إنشاء جداول فوق بيانات CloudTrail

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

تسلّم CloudTrail الأحداث بتنسيق JSON، حيث يصف كل سجل استدعاء API واحدًا ويحتوي على حقول متداخلة مثل userIdentity وeventName وsourceIPAddress وrequestParameters. ويجب أن يعكس مخطط الجدول هذا التداخل، بما في ذلك استخدام أنواع struct للكائنات، حتى تتمكن الاستعلامات من الوصول إلى حقول مثل userIdentity.arn.

لا يتعين عليكم كتابة المخطط يدويًا. تنشر AWS عبارة CREATE TABLE قياسية لـ CloudTrail، ويمكن لوحدة تحكم CloudTrail وAthena إنشاؤها لكم. ويضمن استخدام DDL المتوفر تعيين كل حقل، بما في ذلك الحقول المتداخلة بعمق، بشكل صحيح، حتى لا تفوّت استعلاماتكم أي بيانات.

يُخبر SerDe (المُسلسِل/مُزيل التسلسل) Athena بكيفية تحليل كل ملف. تستخدم جداول CloudTrail ‏SerDe مصممًا لهيكل JSON الخاص بـ CloudTrail، ويفهم مصفوفة السجلات والبنى المتداخلة. ويُعد اختيار SerDe الصحيح أمرًا أساسيًا؛ إذ يؤدي اختيار SerDe غير صحيح إلى أخطاء في التحليل أو إلى أعمدة بقيم فارغة.

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

بعد إنشاء الجدول، يمكنك الاستعلام عن الحقول المتداخلة باستخدام الصياغة النقطية، مثل userIdentity.arn أو requestParameters.bucketName. وتساعد دوال SQL في تفكيك المصفوفات وسلاسل JSON. وهنا تتألق Athena في التحقيقات: إذ يمكنك التصفية بدقة حسب اسم الحدث والكيان الأساسي والمعلمات لأي استدعاء API.

بدلًا من كتابة DDL يدويًا، يمكن لبرنامج AWS Glue crawler فحص بيانات S3 واستنتاج مخطط وإضافته تلقائيًا إلى Data Catalog. وبالنسبة إلى التنسيقات المعروفة مثل CloudTrail، يكون DDL المتوفر عادةً أكثر وضوحًا، لكن برامج crawler مفيدة للتنسيقات المخصصة أو المتغيرة للسجلات، عندما تفضلون عدم كتابة المخطط يدويًا.

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

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

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

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

اختبروا معرفتكم بإنشاء الجداول.

للاستعلام عن CloudTrail في Athena، تنشئون جدولًا يربط ملفات JSON بالأعمدة، باستخدام CREATE TABLE DDL الذي توفره AWS، وSerDe الصحيح، وLOCATION الصحيح في S3. استعلموا عن الحقول المتداخلة باستخدام الصياغة النقطية، وحلّلوا أعمدة سلاسل JSON وقت تنفيذ الاستعلام، وتحققوا من النتائج باستخدام SELECT صغير. ويمكن أن يكون مسار المؤسسة جدولًا واحدًا للبحث عن التهديدات على مستوى المؤسسة.