صندوقك الأسود في السحابة: كيف حولت سجلات S3 إلى نظام إنذار أمني مبكر باستخدام Athena

يا هلا بيكم يا جماعة الخير، معكم أخوكم أبو عمر.

بتذكر مرة، كان يوم خميس المسا، وكنت قاعد بشرب فنجان الشاي بالنعناع ومبسوط إنه الأسبوع خلص على خير. فجأة، بيوصلني إيميل من AWS عنوانه “Budget Alert”. قلبي نقزني، لأنه هاي الرسالة ما بتيجي إلا لما المصاريف تكون “ولّعت”. فتحت الإيميل بسرعة، وإذ الفاتورة المتوقعة للشهر الحالي قافزة للسما! يا ساتر! شو اللي صار؟

أول شي خطر ببالي هجوم DDoS أو يمكن مفتاح وصول (Access Key) تسرّب وصار في حدا “بحتفل” على حسابي. المشكلة إنه لما يكون عندك بنية تحتية سحابية كبيرة، معرفة مصدر المشكلة زي ما تكون بتدور على إبرة بكومة قش. شغّلت المخ شوي… وين أكثر مكان ممكن يصير فيه استهلاك للبيانات أو عدد طلبات هائل؟ طبعًا، خدمة التخزين S3. لكن كيف بدي أعرف شو اللي بصير بالضبط داخل الـ Buckets تبعتي؟

وهون تذكرت الكنز المدفون اللي كثير ناس بتتجاهله: سجلات الوصول لـ S3 (S3 Access Logs). هاي السجلات هي الصندوق الأسود لكل ما يحدث على بياناتك. المشكلة؟ إنها عبارة عن آلاف، بل ملايين الأسطر من النصوص غير المفهومة. لكن مع الأداة الصح، هاد الكنز بصير منجم ذهب للمعلومات. وهون دخلت على الخط بطلة قصتنا: خدمة AWS Athena. في هذيك الليلة، وبكم استعلام بسيط، قدرت أعرف إنه في سكربت صغير على وحدة من سيرفرات EC2 دخل بـ “حلقة لا نهائية” (Infinite Loop) وكان بطلب نفس الملف ملايين المرات. حليت المشكلة خلال دقائق، وبدل ما أدفع آلاف الدولارات، رجعت الفاتورة لوضعها الطبيعي. ومن يومها، قررت إنه هاي السجلات ما رح تكون مجرد أرشيف، بل رح تكون خط الدفاع الأول عندي.

خلونا اليوم نتعلم سوا كيف نحول هالصندوق الأسود لنظام إنذار مبكر ذكي.

الصندوق الأسود: ما هي سجلات الوصول إلى S3 ولماذا هي مهمة؟

ببساطة شديدة، سجلات الوصول إلى خادم S3 هي سجلات مفصلة لكل طلب (request) يتم إرساله إلى الـ S3 bucket الخاص بك. فكّر فيها كحارس أمن يقف على باب المبنى ويسجل كل من دخل وخرج، ومتى، وماذا فعل.

هذه السجلات تحتوي على معلومات قيمة جدًا مثل:

  • من الذي طلب الوصول (عنوان IP، أو هوية المستخدم/الدور).
  • ما هو الملف (Object) الذي تم طلبه.
  • متى تم الطلب.
  • نوع الطلب (GET, PUT, DELETE, etc.).
  • هل نجح الطلب أم فشل (HTTP Status Code مثل 200, 403, 404).
  • كمية البيانات التي تم نقلها.

خطوتك الأولى: تفعيل السجلات

قبل ما نعمل أي شي، لازم نفعل هاي الميزة. للأسف، هي غير مفعلة بشكل افتراضي. العملية بسيطة:

  1. أنشئ Bucket جديد ليكون وجهة السجلات: من أفضل الممارسات إنك تخصص Bucket منفصل لتخزين السجلات فقط (مثلاً، `my-company-logs-bucket`). هذا يمنع الحلقات اللانهائية في التسجيل ويسهل إدارة الأذونات.
  2. اذهب إلى الـ Bucket الذي تريد مراقبته: اختر الـ Bucket الذي يحتوي على بياناتك المهمة.
  3. اذهب إلى تبويب “Properties”: انزل لأسفل حتى تجد قسم “Server access logging”.
  4. قم بتفعيله: اختر “Enable” وحدد الـ Bucket الذي أنشأته في الخطوة الأولى كوجهة للسجلات. يمكنك أيضًا إضافة “prefix” (بادئة) مثل `s3-access-logs/` لتنظيم الملفات داخل bucket السجلات.

نصيحة من أبو عمر: قم بتفعيل سياسة دورة حياة (Lifecycle Policy) على bucket السجلات. مثلاً، يمكنك نقل السجلات القديمة (أقدم من 90 يومًا) إلى فئة تخزين أرخص مثل S3 Glacier Instant Retrieval، وحذف السجلات القديمة جدًا (أقدم من سنة) تلقائيًا لتوفير التكاليف.

السحر يبدأ هنا: التعريف بخدمة AWS Athena

الآن صار عنا السجلات، لكنها مجرد ملفات نصية مضغوطة (`.gz`). فتحها واحدًا تلو الآخر مستحيل. هنا يأتي دور Athena، وهي خدمة استعلام تفاعلية تجعل من السهل تحليل البيانات الموجودة مباشرة في S3 باستخدام لغة SQL القياسية.

أجمل ما في Athena:

  • بلا خوادم (Serverless): لا حاجة لإدارة أي بنية تحتية.
  • الدفع حسب الاستخدام: أنت تدفع فقط مقابل البيانات التي يتم فحصها (scanned) بواسطة استعلاماتك. وهذا يجعلها فعالة جدًا من حيث التكلفة.

تجهيز Athena لقراءة سجلات S3

هذه هي الخطوة التقنية الأهم. سنقوم بإنشاء “جدول” في Athena يشير إلى ملفات السجلات الخاصة بنا. هذا الجدول هو مجرد تعريف للبيانات (metadata)، البيانات الفعلية تبقى في S3.

1. افتح لوحة تحكم Athena في AWS Console.

2. إذا كانت هذه هي المرة الأولى التي تستخدم فيها Athena، فستحتاج إلى إعداد موقع لنتائج الاستعلام (query result location). هذا مجرد bucket في S3 حيث ستحفظ Athena نتائج استعلاماتك.

3. في محرر الاستعلام، سنقوم بإنشاء جدولنا. انسخ والصق الكود التالي، مع تغيير `s3://your-log-bucket/path-to-logs/` إلى المسار الصحيح لسجلاتك.


CREATE EXTERNAL TABLE `s3_access_logs_db`.`my_bucket_logs`(
  `bucketowner` STRING,
  `bucket_name` STRING,
  `requestdatetime` STRING,
  `remoteip` STRING,
  `requester` STRING,
  `requestid` STRING,
  `operation` STRING,
  `key` STRING,
  `request_uri` STRING,
  `httpstatus` STRING,
  `errorcode` STRING,
  `bytessent` BIGINT,
  `objectsize` BIGINT,
  `totaltime` STRING,
  `turnaroundtime` STRING,
  `referrer` STRING,
  `useragent` STRING,
  `versionid` STRING,
  `hostid` STRING,
  `sigv` STRING,
  `ciphersuite` STRING,
  `authtype` STRING,
  `endpoint` STRING,
  `tlsversion` STRING)
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.serde2.RegexSerDe' 
WITH SERDEPROPERTIES ( 
  'input.regex'='([^ ]*) ([^ ]*) \[(.*?)\] ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ("[^"]*"|-) (-|[0-9]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ("[^"]*"|-) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*)')
LOCATION
  's3://your-log-bucket/path-to-logs/'

قد يبدو هذا الكود معقدًا، لكن لا تخف. كل ما يفعله هو إخبار Athena بكيفية تحليل كل سطر في ملف السجل وتقسيمه إلى أعمدة منظمة مثل `remoteip` و `httpstatus` و `bytessent`.

نصيحة احترافية: إذا كان لديك كمية هائلة من السجلات، ففكر في استخدام “التقسيم” (Partitioning) حسب التاريخ. هذا يسرّع الاستعلامات بشكل كبير ويقلل التكاليف، لأن Athena ستقوم فقط بفحص المجلدات (الأقسام) التي تحددها في استعلامك (مثلاً، سجلات اليوم الأخير فقط) بدلاً من فحص كل السجلات منذ البداية.

لنلعب دور المحقق: استعلامات عملية للكشف عن التهديدات

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

1. من يطرق بابي؟ تحديد أكثر عناوين IP وصولاً

هذا الاستعلام يساعدك على اكتشاف أي هجمات القوة الغاشمة (Brute-force) أو إذا كان هناك عنوان IP واحد يستهلك الكثير من الموارد.


SELECT
  remoteip,
  count(*) AS request_count
FROM my_bucket_logs
GROUP BY remoteip
ORDER BY request_count DESC
LIMIT 20;

2. البحث عن الأبواب المكسورة: كشف الطلبات الفاشلة (أخطاء 4xx)

كثرة أخطاء 403 (Forbidden) أو 404 (Not Found) قد تشير إلى محاولات وصول غير مصرح بها أو روابط معطوبة في تطبيقك.


SELECT
  remoteip,
  request_uri,
  httpstatus,
  count(*) as error_count
FROM my_bucket_logs
WHERE
  cast(httpstatus as integer) BETWEEN 400 AND 499
GROUP BY remoteip, request_uri, httpstatus
ORDER BY error_count DESC
LIMIT 20;

3. الخطر الأكبر: مراقبة الوصول المجهول (Anonymous Access)

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


SELECT
  remoteip,
  requestdatetime,
  key
FROM my_bucket_logs
WHERE
  requester IS NULL OR requester = '-'
LIMIT 100;

4. زاوية FinOps: تحليل التكاليف

هل تريد أن تعرف ما هي الملفات التي تسبب معظم تكاليف نقل البيانات (Data Transfer)؟ هذا الاستعلام يخبرك بذلك. هذا مفيد جدًا لتحسين التكاليف.


SELECT
  key,
  sum(bytessent) / 1024 / 1024 AS data_sent_mb
FROM my_bucket_logs
WHERE
  operation = 'GET.OBJECT'
GROUP BY key
ORDER BY data_sent_mb DESC
LIMIT 20;

من العمل اليدوي إلى الإنذار الآلي

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

  1. Amazon EventBridge (CloudWatch Events): قم بإعداد قاعدة تعمل وفقًا لجدول زمني (مثلاً، كل ساعة).
  2. AWS Lambda: اجعل القاعدة تشغل دالة Lambda.
  3. داخل Lambda: اكتب كودًا (باستخدام Python أو Node.js) يقوم بتشغيل أحد استعلامات Athena (مثل استعلام الوصول المجهول).
  4. التحقق من النتائج: إذا أعاد الاستعلام أي نتائج، فهذا يعني وجود مشكلة.
  5. إرسال تنبيه: استخدم خدمة Amazon SNS لإرسال بريد إلكتروني أو رسالة نصية أو إشعار إلى قناة Slack لتنبيهك فورًا.

بهذه الطريقة، يتحول نظامك من نظام تفاعلي (أنت تبحث عن المشكلة) إلى نظام استباقي (النظام يخبرك بالمشكلة).

الخلاصة: صندوقك الأسود ليس مجرد أرشيف 🧐

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

باستخدام أداة قوية وبسيطة مثل Athena، يمكنك تحويل هذه البيانات الخام إلى رؤى قابلة للتنفيذ. يمكنك بناء لوحات معلومات (Dashboards)، وأنظمة إنذار، وأدوات تحليل للتكاليف، كل ذلك ببضع استعلامات SQL.

نصيحتي الأخيرة لكم: لا تنتظروا وصول “Budget Alert” لتبدأوا بالاهتمام بسجلاتكم. فعّلوها اليوم، وجهّزوا Athena، وابدأوا بالاستكشاف. كن استباقيًا وليس رد فعل. سحابتك ستشكرك، ومحفظتك أيضًا. ودائمًا تذكر، الوقاية خير من قنطار علاج… أو فاتورة! 😉

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

التوظيف وبناء الهوية التقنية

سيرتي الذاتية عبرت فلتر الـ ATS لكنها فشلت أمام المدير التقني: كيف أعدت بناءها لتتحدث لغة المهندسين؟

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

28 فبراير، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

خدمة واحدة فاشلة كادت أن تسقط النظام بأكمله: كيف أنقذني نمط ‘قاطع الدائرة’ (Circuit Breaker) من كارثة متتالية؟

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

27 فبراير، 2026 قراءة المزيد
اختبارات الاداء والجودة

لقد ‘هاجمت’ تطبيقي بنفسي عمداً: كيف كشفت لي ‘هندسة الفوضى’ نقاط الضعف التي لم تظهرها الاختبارات التقليدية

أشارككم قصة حقيقية حول إطلاق فاشل كاد أن يدمر سمعتنا، وكيف قادتنا هذه التجربة المريرة إلى تبني "هندسة الفوضى" (Chaos Engineering). اكتشفوا معنا كيف يمكن...

26 فبراير، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

عاصفة من الطلبات كادت أن تغرق تطبيقي: كيف أنقذتني طوابير الرسائل (Message Queues) من كارثة الجمعة السوداء؟

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

24 فبراير، 2026 قراءة المزيد
البودكاست