الأتمتة المعتمدة على الواجهة مع بوابات الأطراف الثالثة

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

هذه البوابات لا تمتلك APIs. أو لديها APIs غير موثقة أو محدودة المعدل أو مقصورة على "الشركاء المفضلين" الذين يدفعون مقابل الوصول. تقيم البيانات خلف صفحة تسجيل دخول، تُعرض في HTML، والطريقة الوحيدة للحصول عليها هي تسجيل الدخول والتنقل في الواجهة.

تستخدم الأتمتة التقليدية سكريبتات متصفح. سكريبتات Selenium أو Playwright أو Puppeteer تسجّل الدخول وتتنقل إلى الصفحة المناسبة وتجد العناصر بمحدد CSS أو XPath وتستخرج البيانات وتسجّل الخروج. تعمل هذه السكريبتات حتى تتوقف. إعادة تصميم البوابة تغيّر أسماء فئات CSS. يُضاف CAPTCHA جديد إلى تدفق تسجيل الدخول. ينتقل قائمة التنقل من شريط جانبي إلى قائمة منسدلة. بانر موافقة ملفات تعريف الارتباط يبدأ بتغطية زر الإرسال. تتعطل السكريبتة بصمت، ولا يلاحظ أحد حتى تبدأ العملية المنبثقة التي تعتمد على البيانات في توليد أخطاء.

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

كيف تحل Triggerfish هذا

تجمع أتمتة متصفح Triggerfish Chromium المتحكم بـ CDP مع التنقل البصري المبني على LLM. يرى الوكيل الصفحة كبكسلات مُعرَضة ولقطات إمكانية الوصول، لا كشجرة DOM. يُحدد العناصر بما تبدو عليه وبما تفعله، لا بأسماء فئات CSS. عند إعادة تصميم البوابة، يتكيف الوكيل لأن نماذج تسجيل الدخول لا تزال تبدو كنماذج تسجيل دخول وقوائم التنقل لا تزال تبدو كقوائم تنقل وجداول البيانات لا تزال تبدو كجداول بيانات.

التنقل البصري بدلاً من سكريبتات المحددات

تعمل أدوات أتمتة المتصفح عبر سبع عمليات: التنقل، اللقطة، النقر، الكتابة، الاختيار، التمرير، والانتظار. يتنقل الوكيل إلى عنوان URL، يأخذ لقطة للصفحة المُعرَضة، يستدل حول ما يراه، ويقرر الإجراء الذي يتخذه. لا توجد أداة evaluate تُشغّل JavaScript عشوائياً في سياق الصفحة. هذا قرار أمني متعمد. يتفاعل الوكيل مع الصفحة كما يفعل الإنسان، عبر الواجهة، ولا يستطيع تنفيذ كود يمكن استغلاله من قِبَل صفحة خبيثة.

عند مواجهة الوكيل لنموذج تسجيل دخول، يُحدد حقل اسم المستخدم وحقل كلمة المرور وزر الإرسال استناداً إلى التخطيط البصري ونص العنصر النائب والتسميات وبنية الصفحة. لا يحتاج إلى معرفة أن حقل اسم المستخدم له id="auth-input-email" أو class="login-form__email-field". عند تغيير تلك المعرفات في إعادة تصميم، لا يلاحظ الوكيل لأنه لم يعتمد عليها أبداً.

أمان النطاق المشترك

تتشارك أتمتة المتصفح نفس إعدادات أمان النطاق مع عمليات جلب الويب. يُعرّف كتلة إعداد واحدة في triggerfish.yaml قوائم رفض SSRF وقوائم السماح بالنطاق وقوائم رفض النطاق وتعيينات النطاق إلى التصنيف. عند تنقل الوكيل إلى بوابة مورد مصنفة بمستوى CONFIDENTIAL، يتصاعد taint الجلسة تلقائياً إلى CONFIDENTIAL، وتخضع جميع الإجراءات اللاحقة في سير العمل لقيود مستوى CONFIDENTIAL.

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

وضع علامة مائية على ملف تعريف المتصفح

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

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

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

إدارة بيانات الاعتماد

تُخزَّن بيانات اعتماد البوابات في keychain نظام التشغيل (المستوى الشخصي) أو خزنة المؤسسة (المستوى المؤسسي)، لا في ملفات إعداد أو متغيرات بيئة. يُسجّل hook SECRET_ACCESS كل عملية استرداد لبيانات الاعتماد. تُحل بيانات الاعتماد عند وقت التنفيذ من قِبَل محرك سير العمل وتُحقن في جلسات المتصفح عبر واجهة الكتابة، لا عن طريق تعيين قيم النماذج برمجياً. يعني هذا أن بيانات الاعتماد تتدفق عبر نفس طبقة الأمان كأي عملية حساسة أخرى.

المرونة أمام التغييرات الشائعة في البوابات

إليك ما يحدث عند وقوع تغييرات شائعة في البوابات:

إعادة تصميم صفحة تسجيل الدخول. يأخذ الوكيل لقطة جديدة، يُحدد التخطيط المحدَّث، ويجد حقول النموذج بالسياق البصري. ما لم تتحوّل البوابة إلى طريقة مصادقة مختلفة كلياً (SAML أو OAuth أو رمز مادي)، يستمر تسجيل الدخول في العمل دون أي تغيير في الإعداد.

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

بانر موافقة ملفات تعريف الارتباط الجديد. يرى الوكيل البانر، يُحدد زر القبول/الرفض، ينقر عليه، ويستمر في المهمة الأصلية. يعالج هذا الفهم العام للصفحة لدى LLM، لا معالج خاص لملفات تعريف الارتباط.

إضافة CAPTCHA. هنا يواجه النهج حدوداً صريحة. CAPTCHAs الصورية البسيطة قد تكون قابلة للحل اعتماداً على قدرات رؤية LLM، لكن reCAPTCHA v3 وأنظمة التحليل السلوكي المماثلة تستطيع حجب المتصفحات الآلية. يُوجّه سير العمل هذه الحالات إلى طابور تدخل بشري بدلاً من الفشل الصامت.

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

المعالجة الدفعية عبر بوابات متعددة

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

كيف يبدو هذا عملياً

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

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

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