نظرة معمّقة على المخزون في الوقت الفعلي

في وقت مبكر من مسيرة FireMon (أي قبل أن نصبح FireMon)، أدركنا أن محاولة التقييم المباشر لحسابات العملاء السحابية (بما في ذلك الاشتراكات/المشاريع) أمر... إشكالي. فتشغيل هذا العدد من التقييمات كان سيصطدم سريعًا بحدود الخدمة، وقد يؤدي إلى تعطيل استدعاءات واجهات برمجة التطبيقات الداخلية لدى العميل. ويجدر التنويه إلى أننا بدأنا هذا العمل قبل نحو 7 سنوات، قبل ظهور CSPM أصلًا، وكان الجميع يتعلمون الدروس نفسها.

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

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

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

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

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

أفضل طريقة للاطلاع على ذلك هي عبر جولتنا المصوّرة التي تستغرق 90 ثانية! وفي ما يلي بعض لقطات الشاشة الرئيسية:

الصفحة الرئيسية، وتعرض كمًا وافرًا من البيانات المهمة في عرض واحد:

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

يتتبع عرض السجل هذا التغييرات ترتيبًا زمنيًا مع رسم بياني يوضح اتجاهات النشاط. والنقر على الخط الزمني ينقلك إلى ذلك التاريخ:

هل احتجتم يومًا إلى معرفة المورد السحابي المؤقت الذي كان يملك عنوان IP الذي ظهر في السجلات في لحظة زمنية محددة؟ فرق الاستجابة للحوادث تعشق هذه الميزة...

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