تأمين تطبيقات SaaS من خلال ضوابط على مستوى المتصفح

يقوم نظام CASB الخاص بك بمنع أحد المتعاقدين من تنزيل قائمة عملاء من Salesforce إلى جهاز كمبيوتر محمول غير خاضع للإدارة. وبعد خمس ثوانٍ، يقوم نفس المقاول بتحديد الجدول بأكمله، ونسخه إلى الحافظة، ولصقه في نافذة كتابة رسالة بريد إلكتروني شخصية على Gmail، ثم النقر على «إرسال». ولا يلاحظ نظام CASB ذلك أبدًا. لكن المتصفح لاحظ ذلك — وكان بإمكانه إيقافه لو توفرت الضوابط المناسبة. يرشد هذا الدليل مسؤولي أمن SaaS ومشغلي CASB عبر نهج تدريجي لسد تلك الثغرة من خلال تطبيق ضوابط متعددة المستويات على مستوى المتصفح — remote browser isolation (RBI)، وسياسات secure web gateway SWG)، ونظام منع تسرب البيانات (DLP)، وإجراءات الجلسة — فوق عمليات نشر CASB الحالية.

المتطلبات الأساسية: ما يجب تجهيزه قبل البدء

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

1. تم بالفعل نشر نظام CASB مع وضعي الوكيل الأمامي والوكيل الخلفي. أنت بحاجة إلى فحص حركة المرور المباشر لتطبيقات SaaS الخاضعة للعقوبات (الوكيل الخلفي) والرؤية الكاملة لتكنولوجيا المعلومات غير المعتمدة (الوكيل الأمامي) كأساس لتنفيذ السياسات. إذا كان نشر نظام CASB الخاص بك يعتمد على واجهة برمجة التطبيقات (API) فقط، فإنك تفتقر إلى المسار المباشر الذي توفره أدوات التحكم في المتصفح.

2. محرك سياسات DLP موحد. يجب أن تشير عناصر التحكم على مستوى المتصفح إلى نفس تصنيفات البيانات — المعلومات الشخصية المحددة للهوية (PII)، والمعلومات الصحية المحمية (PHI)، والسجلات المالية، وشفرة المصدر، والملكية الفكرية — التي تستخدمها سياسات CASB وسياسات DLP الخاصة بالبريد الإلكتروني. إذا كانت تعريفات DLP الخاصة بك موجودة في أقسام منفصلة، فابدأ بتوحيدها. يؤدي عدم اتساق التصنيف إلى قيام قناة ما بحظر ما تسمح به قناة أخرى. وتجنب منصة DLP المركزية هذا التجزؤ.

3. تكامل مزود الهوية (IdP) وتقييم حالة الجهاز. تصبح ضوابط المتصفح أكثر فائدة بكثير عندما تتكيف بناءً على هوية المستخدم والجهاز الذي يستخدمه. فيجب أن يخضع المتعاقد في مجال التسويق الذي يستخدم جهاز MacBook شخصي لضوابط أكثر صرامة مقارنةً بمحلل مالي يعمل بدوام كامل ويستخدم جهازًا طرفيًّا يعمل بنظام Windows خاضعًا للإدارة. ويتطلب ذلك تكاملًا عبر بروتوكولي SAML/OIDC مع مزود الهوية الخاص بك وفحوصات حالة الجهاز (خاضع للإدارة مقابل غير خاضع للإدارة، ومستوى تحديثات نظام التشغيل، وحالة تشفير القرص).

4. قائمة جرد تطبيقات SaaS مصنفة حسب درجة الحساسية. لا يمكنك تحديد نطاق سياسات المتصفح دون معرفة أي تطبيقات SaaS تحتوي على بيانات حساسة. قم بتصنيف أهم 20 أو 50 تطبيقًا من تطبيقات SaaS الخاصة بك حسب مستوى حساسية البيانات (حرجة، عالية، متوسطة، منخفضة). توصي «أفضل ممارسات حوكمة SaaS» الصادرة عن CSA بتقييم المخاطر خلال جميع مراحل دورة حياة SaaS — التقييم، والاعتماد، والاستخدام، والإنهاء. وتصبح قائمة الجرد هذه مدخلات لتحديد نطاق سياساتك.

المرحلة الأولى: سد الثغرات المتعلقة بالحافظة والتنزيل في السيناريوهات عالية المخاطر

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

السيناريو الذي يبرر المرحلة الأولى: يقوم مدقق خارجي بتسجيل الدخول إلى مثيل Workday الخاص بك من جهاز كمبيوتر محمول شخصي باستخدام ميزة تسجيل الدخول الموحد (SSO). يقوم الوكيل العكسي لـ CASB بالتحقق من صحة الجلسة ويحظر تنزيل الملفات وفقًا للسياسة. لكن المدقق يفتح تقريرًا عن تعويضات الموظفين، ويختار ثلاثين صفًا من بيانات الرواتب، وينسخها، ثم يفتح علامة تبويب جديدة في جدول Google Sheet شخصي، ويلصقها. لاحظ CASB وجود جلسة Workday تم التحقق من صحتها وجلسة Google Sheets — وهما حدثان منفصلان ومسموح بهما بشكل فردي. ولم يلاحظ أبدًا انتقال البيانات بينهما لأن عملية الحافظة حدثت بالكامل داخل سياق عرض المتصفح.

ما يجب نشره: قم بتمكين remote browser isolation جلسات الأجهزة غير المدارة remote browser isolation تصل إلى تطبيقات SaaS من المستوى 1 (الحرجة) والمستوى 2 (عالية المخاطر). تعمل تقنية RBI على عرض تطبيق SaaS في حاوية مستضافة على السحابة، ولا تقوم إلا ببث وحدات البكسل إلى متصفح المستخدم. تمنحك هذه البنية تحكمًا دقيقًا في إجراءات الجلسة:

قيود النسخ/اللصق: حظر عمليات الكتابة/القراءة في الحافظة من الجلسة المعزولة، أو السماح باللصق من الجلسة المعزولة مع حظر النسخ منها، وذلك لمنع خروج البيانات من سياق تطبيق SaaS.

منع التنزيل: منع تنزيل الملفات من الجلسة المعروضة تمامًا، أو تقييد التنزيلات على أنواع ملفات محددة.

حظر الطباعة: تعطيل أوامر الطباعة والطباعة إلى ملف PDF.

وضع علامة مائية على لقطات الشاشة: إدراج علامة مائية مرئية أو جنائية تحتوي على البريد الإلكتروني للمستخدم والطابع الزمني في دفق العرض، مما يردع عملية التقاط لقطات الشاشة.

تنص المواصفة NIST SP 800 53 SC 7 على ضرورة عزل مكونات النظام باستخدام آليات حماية حدودية للتحكم في تدفق المعلومات والحد من الأضرار المحتملة الناجمة عن الهجمات العدائية والأخطاء. ويقوم نظام RBI بإنشاء هذا الحد الفاصل بالضبط بين بيانات تطبيق SaaS والجهاز المحلي للمستخدم، مما يتيح فرض ضوابط على تدفق المعلومات لا يستطيع وكيل الشبكة فرضها.

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

المرحلة الثانية: توسيع نطاق نظام منع تسرب البيانات (DLP) في المتصفح ليشمل النقاط الطرفية الخاضعة للإدارة وتغطية أوسع لخدمات البرمجيات كخدمة (SaaS)

بمجرد استقرار المرحلة الأولى — عادةً بعد 4 إلى 6 أسابيع من جمع بيانات القياس عن بُعد وضبط السياسات — قم بتوسيع نطاق التغطية ليشمل الأجهزة الخاضعة للإدارة ومجموعة أوسع من تطبيقات SaaS.

السيناريو الذي يبرر المرحلة الثانية: يقوم مندوب مبيعات يعمل بدوام كامل، ويستخدم جهاز كمبيوتر محمول خاضع للإدارة، بالوصول إلى Salesforce عبر متصفح Chrome. يفتح سجل حساب أحد العملاء، وينسخ اسم جهة الاتصال واسم الشركة ورقم الهاتف، ثم يلصقها في ChatGPT لإنشاء رسالة بريد إلكتروني تواصلية مخصصة. لم يتم تنزيل أي ملف. ولم يتم انتهاك أي قاعدة مشاركة في Salesforce. لكن المعلومات الشخصية المحددة للهوية (PII) الخاصة بالعميل غادرت للتو بيئة SaaS الخاضعة لسيطرتك ودخلت إلى أداة ذكاء اصطناعي تابعة لجهة خارجية عبر الحافظة في المتصفح.

وفقًا لتقرير «حالة أمن خدمات البرمجيات كخدمة (SaaS)» الصادر عن CSA (2025)، أفادت 63% من المؤسسات بحدوث مشاركة مفرطة للبيانات مع أطراف خارجية، بينما ذكرت 56% منها أن الموظفين يقومون بتحميل بيانات حساسة إلى تطبيقات SaaS غير مصرح بها — غالبًا عبر مسارات الحافظة والتحميل هذه بالذات التي تفوتها الضوابط التقليدية. ويُعد نظام منع تسرب البيانات (DLP) على مستوى المتصفح هو الضابط الذي يعترض هذه الإجراءات قبل وصول البيانات إلى الوجهة غير المصرح بها.

ما الذي يجب نشره:

قامت secure web gateway (SWG) بفرض فحص DLP على الأجهزة الطرفية الخاضعة للإدارة. حيث يقوم secure web gateway باعتراض حركة مرور المتصفح وتطبيق تصنيف DLP على البيانات أثناء نقلها — بما في ذلك عمليات إرسال حقول النماذج، وعمليات اللصق من الحافظة إلى تطبيقات الويب، وعمليات تحميل الملفات عبر المتصفح. وهذا يتيح رصد السيناريو المذكور أعلاه المتعلق بـ Salesforce وChatGPT.

تطبيق RBI الانتقائي للفئات الحساسة. بدلاً من عزل جميع عمليات التصفح، يتم توجيه جلسات العمل إلى تطبيقات SaaS من المستوى 1 والمستوى 2 عبر RBI عندما يُشير سلوك المستخدم إلى وجود إشارة خطر (مثل: الوصول إلى كائن بيانات العميل، أو فتح عرض للتصدير، أو الانتقال إلى أداة ذكاء اصطناعي باستخدام بيانات اعتماد الشركة).

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

مبدأ تصميم السياسات المستمد من NIST SP 800-53 AC 4: يمكن استخدام آليات فرض الوصول على مستوى التطبيقات والخدمات لتعزيز أمن المعلومات والتحكم في تدفقات المعلومات بما يتجاوز ما تحققه ضوابط مستوى الشبكة. وتعمل تقنيات منع تسرب البيانات (DLP) والتحكم في السلوك (RBI) على مستوى المتصفح على مستوى التطبيقات والخدمات هذا بالضبط، مما يضيف مستوىً من الفرض لا تستطيع وكلاء CASB على مستوى الشبكة الوصول إليه.

المرحلة 3: دمج عناصر التحكم في المتصفح في بنية سياسة SSE الخاصة بك

يؤدي نشر عناصر التحكم في المتصفح كطبقة مستقلة إلى زيادة الأعباء التشغيلية: سياسات منفصلة، ووحدات تحكم منفصلة، وقوائم انتظار منفصلة للحوادث. تعمل المرحلة الثالثة على توحيد عملية التطبيق على مستوى المتصفح مع نظامك الأوسع نطاقًا Security Service Edge (SSE) الخاصة بك بحيث يتحكم محرك سياسات واحد في قرارات CASB وSWG وDLP وRBI وZTNA.

السيناريو الذي يبرر استخدام «المرحلة 3»: يتلقى مركز العمليات الأمنية (SOC) الخاص بك ثلاثة تنبيهات: تنبيه من CASB يفيد بأن أحد المستخدمين قد دخل إلى تطبيق SaaS ظلّي، وتنبيه من SWG يفيد بأن جلسة متصفح المستخدم نفسه قد أثارت تطابقًا مع نمط DLP، وتنبيه من RBI يفيد بأنه تم حظر عملية نسخ إلى الحافظة. ثلاث وحدات تحكم، وثلاثة محللين، وثلاث تذاكر دعم — كل ذلك لمستخدم واحد يقوم بسلسلة إجراءات واحدة. تعمل سياسة SSE الموحدة على دمج كل ذلك في حدث واحد مترابط مع مسار عمل استجابة واحد.

ما الذي يجب نشره:

قواعد سياسة موحدة تشير إلى هوية المستخدم، وحالة الجهاز، ومستوى حساسية تطبيق SaaS، وتصنيف البيانات، ونوع الإجراء الذي يقوم به المتصفح (التنزيل، الحافظة، الطباعة، التحميل) في عبارة شرطية واحدة.

العزل التكيفي الذي يقوم تلقائيًا بترقية الجلسة إلى مستوى RBI الكامل عندما تكتشف منصة SSE مجموعة من الإشارات — مثل وصول جهاز غير مُدار إلى تطبيق من المستوى 1 في الوقت الذي يكتشف فيه نظام DLP محتوى حساسًا في الصفحة.

توجيه بيانات القياس عن بُعد الخاصة بالجلسة إلى نظام SIEM/SOAR بحيث تظهر الأحداث على مستوى المتصفح (حجب محتويات الحافظة، وإدراج العلامات المائية، ومنع التنزيل) جنبًا إلى جنب مع أحداث CASB وSWG وZTNA، وذلك لأغراض الربط والتحقيق.

يدعو «نموذج نضج نهج الثقة الصفرية» (Zero Trust Maturity Model) التابع لوكالة الأمن السيبراني والبنية التحتية (CISA) المؤسسات إلى إدارة وتأمين التطبيقات المنشورة باستخدام ضوابط وصول دقيقة وحماية متكاملة ضد التهديدات، بهدف الوصول إلى مستوى النضج الأمثل عبر ركائز «التطبيقات وأحمال العمل» و«البيانات». ويُعد دمج ضوابط مستوى المتصفح في سياسة SSE هو الطريقة التي يمكنك من خلالها تفعيل تلك الإرشادات بالنسبة لتطبيقات SaaS التي يتم الوصول إليها عبر المتصفح.

نقاط التكامل: الأماكن التي تتصل فيها عناصر التحكم في المتصفح بمجموعة التقنيات الحالية لديك

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

لنتأمل مثالاً عملياً على تسلسل التكامل: تستخدم مؤسسة رعاية صحية وضع واجهة برمجة التطبيقات (API) الخاص بـ CASB لفحص المعلومات الصحية المحمية (PHI) المخزنة في «Box» وفرض سياسات المشاركة. ولكن عندما تفتح ممرضة ممارسة، عبر جهاز لوحي شخصي، مستندًا خاصًا بأحد المرضى من خلال المتصفح، يكون الفحص عبر واجهة برمجة التطبيقات قد تم بالفعل — ولن يمنع ذلك نسخ تشخيص المريض من الحافظة إلى تطبيق مراسلة. وتعمل جلسة RBI التي تتضمن قيودًا على الحافظة ووضع علامات مائية على سد هذه الثغرة دون الحاجة إلى وكيل نقطة نهاية على الجهاز اللوحي الشخصي. يتعامل نهج Skyhigh Security لحماية التطبيقات السحابية من الأجهزة غير المدارة مع هذه الحالة الاستخدامية بالضبط من خلال الجمع بين الوكيل العكسي وRBI وDLP في سياسة متكاملة.

المقاييس ومعايير النجاح

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

المؤشرات التشغيلية (يتم تتبعها أسبوعيًا):

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

أحداث حظر التنزيل. تتبعها حسب تطبيق SaaS ودور المستخدم. قد يشير ارتفاع عدد التنزيلات المحظورة من تطبيق معين إلى حاجة المستخدمين إلى بديل آمن (مثل عارض للقراءة فقط أو سير عمل تصدير خاضع للرقابة).

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

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

مؤشرات الحد من المخاطر (يتم تتبعها كل ثلاثة أشهر):

انخفاض في حوادث البيانات الحساسة التي تتعلق بحافظة البيانات أو مسارات التحميل في تطبيقات SaaS. قارن حجم الحوادث قبل وبعد تطبيق ضوابط المتصفح على نفس تطبيقات SaaS ونفس مجموعات المستخدمين.

نطاق التحكم في جلسات الأجهزة غير المدارة. قم بقياس النسبة المئوية لجلسات SaaS الخاصة بالأجهزة غير المدارة التي تمر عبر RBI مقارنة بتلك التي تتجاوزها. استهدف تغطية بنسبة 95٪ أو أكثر للتطبيقات من المستوى 1.

متوسط الوقت اللازم لاكتشاف محاولات تسريب البيانات عبر المتصفح. ومن المفترض أن تقلل تقنية القياس عن بُعد للمتصفح من وقت الكشف من أيام (عند الاعتماد على تنبيهات فحص DLP بعد وقوع الحادث) إلى ثوانٍ (حظر الحافظة في الوقت الفعلي).

كشف تقرير Verizon 2025 DBIR أن 60% من حالات الاختراق تضمنت العنصر البشري — أي قيام المستخدم بالنقر والنسخ والتحميل واللصق. تولد ضوابط مستوى المتصفح بيانات قياس عن بعد خاصة بالتنفيذ تتعلق بهذه الإجراءات البشرية بالذات، مما يمنح مركز عمليات الأمن (SOC) الخاص بك رؤية واضحة لنقطة ضعف تغفلها ضوابط الشبكة وواجهات برمجة التطبيقات (API) تمامًا. وفي الوقت نفسه، تشير شركة «فورستر» إلى أن حوالي واحد من كل خمسة انتهاكات للبيانات ينشأ عن حوادث داخلية (2026)، وتوفر ضوابط جلسات المتصفح تنفيذًا مباشرًا وفي الوقت الفعلي ضد الحافظة ومسارات التحميل التي يستغلها الموظفون الداخليون بشكل متكرر.

الأخطاء الشائعة

الخطأ الأول: تطبيق العزل الكامل لـ RBI على جميع المستخدمين من اليوم الأول. يؤدي العزل الكامل لبث البكسلات إلى تغيير تجربة التصفح. يزداد زمن الاستجابة بشكل طفيف، وتتوقف بعض ملحقات المتصفح عن العمل، وقد يتم عرض تطبيقات الويب المعقدة بشكل مختلف. إذا قمت بتطبيق هذا على 5,000 موظف في آن واحد، فسوف يثور موظفو مركز الدعم، وستقوم الإدارة بإلغاء المشروع. ابدأ بالأجهزة غير المدارة والتطبيقات عالية المخاطر. ثم قم بالتوسع تدريجيًا.

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

الخطأ الثالث: تجاهل وجهات أدوات الذكاء الاصطناعي في سياسة DLP. قامت العديد من المؤسسات بتكوين نظام DLP الخاص بالمتصفح لحظر عمليات التحميل إلى فئات «تكنولوجيا الظل» التقليدية — مثل التخزين السحابي الشخصي والبريد الإلكتروني عبر الويب — لكنها نسيت تضمين المساعدات التي تعمل بالذكاء الاصطناعي. أصبحت أدوات الذكاء الاصطناعي الآن من بين الوجهات غير المصرح بها الأكثر شيوعًا للبيانات التي يتم لصقها وتحميلها. قم بتحديث فئات عناوين URL في كل من SWG وDLP لتشمل خدمات الذكاء الاصطناعي التوليدي، وقم بتطبيق نفس قيود الحافظة والتحميل التي تفرضها على التطبيقات الأخرى غير المصرح بها.

الخطأ الرابع: التعامل مع عناصر التحكم في المتصفح كمشروع مستقل بدلاً من اعتبارها امتداداً لسياسة SSE. فإذا كانت عناصر التحكم في المتصفح موجودة في وحدة تحكم منفصلة ذات سياسات مستقلة، فإنها تصبح أداة أخرى يتجاهلها مركز العمليات الأمنية (SOC). لذا، قم بدمجها في منصة SSE الخاصة بك بدءاً من المرحلة الثالثة فصاعداً، بحيث يتم ربط أحداث المتصفح بأحداث CASB وSWG وZTNA ضمن مسار عمل واحد للحوادث.

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