20 أكتوبر 2025·8 دقيقة
جاي تشودهري وزسكالر: الثقة الصفرية مصممة لمقياس السحابة
نظرة عملية على كيفية استخدام جاي تشودهري وزسكالر لأمن السحابة والثقة الصفرية وتوزيع الشركاء لبناء شركة أمنية مؤسسية رائدة.
نظرة عملية على كيفية استخدام جاي تشودهري وزسكالر لأمن السحابة والثقة الصفرية وتوزيع الشركاء لبناء شركة أمنية مؤسسية رائدة.
هذا ليس سيرة ذاتية لجاي تشودهري. إنه قصة عملية عن كيف ساعدت زسكالر في إعادة تشكيل أمن المؤسسات—ولماذا كانت اختياراتها (تقنية وتجارية) مهمة.
ستتعلم شيئين متوازيين:
أمن المؤسسة الحديث هو مجموعة الضوابط التي تسمح للموظفين باستخدام الإنترنت والتطبيقات الداخلية بأمان، دون افتراض أن شيئًا ما آمن لمجرد أنه "داخل" شبكة الشركة. الأمر أقل عن بناء جدار أكبر حول مركز بيانات، وأكثر عن التحقق من من يتصل، ما الذي يتصل به، وهل يجب السماح بالاتصال—في كل مرة.
بنهاية القراءة ستتمكن من تلخيص رهان زسكالر الأساسي في جملة، والتعرف أين تُستبدل مفاهيم عصر الـ VPN بتفكير الثقة الصفرية، ولماذا قد تكون استراتيجية التوزيع بنفس أهمية تصميم المنتج.
جاي تشودهري رائد أعمال متسلسل معروف كمؤسس ومدير تنفيذي لزسكالر، شركة ساعدت في دفع أمن المؤسسات من "حماية الشبكة المؤسسية" إلى "تأمين المستخدمين والتطبيقات أينما كانوا". قبل زسكالر، أسس وباع عدة شركات أمنية، مما أعطاه رؤية مباشرة لكيفية تغيّر سلوك المهاجمين وتقنية تكنولوجيا معلومات المؤسسات بسرعة.
كان تركيز تشودهري مع زسكالر بسيطًا: مع انتقال العمل والتطبيقات خارج الشبكة المؤسسية (نحو الإنترنت العام وخدمات السحابة)، بدأ نموذج إعادة توجيه كل شيء عبر مركز بيانات مركزي للفحص يتهاوى.
هذا التحول خلق مفاضلة مؤلمة لفرق تكنولوجيا المعلومات:
الفرضية المؤسسة لزسكالر كانت أن الأمان يجب أن يتبع المستخدم، لا المبنى.
ما يبرز هو كيف أن رؤية المنتج بقيادة المؤسس أثّرت على استراتيجية الشركة في المراحل الأولى:
لم يكن هذا مجرد تعديل تسويقي؛ بل ألهم قرارات المنتج، الشراكات، وكيف شرحت زسكالر "لماذا" للمشترين المحافظين. مع الوقت، ساعدت هذه الوضوح في تحويل "الأمن المقدم سحابيًا" و"الثقة الصفرية" من أفكار إلى بنود ميزانية—شيء يمكن للشركات الكبيرة شراؤه ونشره وتوحيده.
لسنوات، بُني أمن المؤسسات حول فكرة بسيطة: احتفظ بـ "الأشياء الجيدة" داخل الشبكة المؤسسية، وضع جدارًا حولها. ذلك الجدار كان عادة مجموعة من الأجهزة المحلية—جدران الحماية، بروكسيات الويب، أنظمة منع التسلل—متراصة في عدد قليل من مراكز البيانات. الموظفون البعيدون كانوا يدخلون عبر VPN، الذي فعليًا "يمد" الشبكة الداخلية إلى أي مكان.
عندما كانت معظم التطبيقات تقيم في مراكز بيانات الشركة، كان هذا يعمل بشكل معقول. كانت حركة الويب وتطبيقات الأعمال تمر عبر نفس نقاط الاختناق، حيث يمكن لفرق الأمان التفتيش والتسجيل والحجب.
لكن النموذج افترض شيئان بدآ يصبحان غير صحيحين:
مع ازدياد تنقل الموظفين وتسارع تبني SaaS، قلبت أنماط الحركة. الأشخاص في المقاهي بحاجة إلى وصول سريع إلى Office 365 وSalesforce وعشرات الأدوات المتصفحة—غالبًا دون مماسهم لمركز بيانات الشركة.
للحفاظ على فرض السياسة، أعادت العديد من الشركات توجيه الحركة: أرسل طلبات الإنترنت وSaaS لمستخدم إلى HQ أولًا، فحصها، ثم أعد إرسالها. والنتيجة متوقعة: بطء في الأداء، مستخدمون غير سعداء، وضغط متزايد لفتح ثغرات في الضوابط.
ارتفعت التعقيدات (أجهزة أكثر، قواعد أكثر، استثناءات أكثر). أصبحت الـ VPNs محمّلة ومخاطِرة عندما تمنح وصولًا شبكيًا واسعًا. وكل فرع جديد أو استحواذ يعني طرح أجهزة جديدة، مزيدًا من تخطيط السعة، وهندسة أكثر هشاشة.
ذلك الفجوة—الحاجة لأمان متسق دون إجبار كل شيء على المرور عبر محيط مادي—خلقت الفرصة لأمن مُقدَّم سحابيًا يمكنه اتباع المستخدم والتطبيق، لا المبنى.
رهان زسكالر الحاسم كان بسيطًا منطوقًا لكنه صعب التنفيذ: تقديم الأمان كخدمة سحابية، موضوعة بالقرب من المستخدمين، بدلًا من أجهزة داخل شبكة الشركة.
في هذا السياق، "أمن السحابة" لا يعني حماية خوادم السحابة فقط. يعني أن الأمان نفسُه يعمل في السحابة—فالمستخدم في فرع، بالمنزل، أو على هاتف متصل بنقطة وجود قريبة، وتُطبق السياسة هناك.
"التحويل إلى خط المسار" يشبه توجيه الحركة عبر نقطة تفتيش أمنية في طريقها إلى الوجهة.
عندما يذهب موظف إلى موقع ويب أو تطبيق سحابي، يتم توجيه اتصاله عبر الخدمة أولًا. تفحص الخدمة ما يمكن (بمقتضى السياسة)، تحجب الوجهات الخطرة، تمسح للتهديدات، ثم تُعيد توجيه المرور المسموح به. الهدف أن المستخدمين لا يحتاجون أن "يكونوا داخل الشبكة" للحصول على حماية بمستوى المؤسسة—الأمان يسافر مع المستخدم.
الأمن المقدم سحابيًا يغير الواقع اليومي لفرق تكنولوجيا المعلومات والأمن:
هذا النموذج يتماشى أيضًا مع كيفية عمل الشركات الآن: غالبًا ما يتجه المرور مباشرة إلى SaaS والإنترنت العام، لا "للعودة إلى المقر" أولًا.
إدخال طرف ثالث مباشرًا يثير مخاوف حقيقية يجب على الفرق تقييمها:
الرهان الأساسي إذًا ليس تقنيًا فقط—بل ثقة تشغيلية بأن مزود السحابة يستطيع فرض السياسة بشكل موثوق، شفاف، وعلى نطاق عالمي.
الثقة الصفرية مبدأ بسيط: لا تفترض أبدًا أن شيئًا ما آمن لمجرد أنه "داخل شبكة الشركة". بدلًا من ذلك، تحقق دائمًا من هوية المستخدم، حالة جهازه، وما إذا كان يجب أن يصل لتطبيق أو بيانات معينين—في كل مرة يكون ذلك مهمًا.
فكر في الـ VPN التقليدي كأنه يمنح شخصًا شارة تفتح مبنى بأكمله عند دخوله. بعد اتصال VPN، تتعامل الكثير من الأنظمة مع المستخدم على أنه "داخلي"، ما قد يعرض أكثر مما يجب.
الثقة الصفرية تقلب ذلك النموذج. تشبه إعطاء شخص حق الدخول لغرفة واحدة لمهمة واحدة. لا "تلتحق بالشبكة" على نحو واسع؛ بل يسمح لك بالوصول فقط للتطبيق الذي تمت الموافقة عليه.
مقاول يحتاج الوصول إلى أداة إدارة مشاريع لمدة شهرين. مع الثقة الصفرية، يمكن منحه الوصول لذلك التطبيق الوحيد—دون حصوله على طريق إلى أنظمة الرواتب أو أدوات الإدارة الداخلية.
موظف يستخدم جهازه الشخصي أثناء السفر. يمكن لسياسات الثقة الصفرية أن تطلب فحوصات تسجيل أقوى أو تمنع الوصول إن كان الجهاز قديمًا أو غير مشفّر أو يظهر عليه علامات اختراق.
يصبح تأمين العمل عن بُعد أسهل لأن قرار الأمان يتبع المستخدم والتطبيق، لا شبكة المكتب الفيزيائية.
الثقة الصفرية ليست منتجًا واحدًا تشتريه وتفعّله. إنها نهج أمني يُنفَّذ عبر أدوات وسياسات.
ولا تعني أيضًا "عدم الثقة في أحد" بطريقة عدائية. عمليًا، تعني أن الثقة تُكسب باستمرار عبر فحوصات الهوية، حالة الجهاز، ومبدأ الأقل امتياز—حتى لا تنتشر الأخطاء والخرقات تلقائيًا.
من الأسهل فهم زسكالر كنقطة تحكم سحابية تجلس بين الناس وما يحاولون الوصول إليه. بدلًا من الوثوق بحاجز شبكة الشركة، تقوم بتقييم كل اتصال بناءً على من هو المستخدم وكيف تبدو الظروف، ثم تطبق السياسة المناسبة.
معظم النشرات يمكن وصفها بأربع قطع بسيطة:
تُقسّم زسكالر حركة المرور إلى مسارين:
هذا الفصل مهم: أحد المسارين يتعلق باستخدام آمن للإنترنت؛ والآخر يتعلق بالوصول الدقيق للأنظمة الداخلية.
القرارات لا تستند إلى عنوان IP لمكتب موثوق. بل على إشارات مثل من هو المستخدم، صحة الجهاز (مُدار مقابل غير مُدار، محدث مقابل قديم)، ومكان/طريقة الاتصال.
إذا نُفّذ جيدًا، يقل هذا النهج سطح الهجوم المكشوف، يحدّ من الحركة الجانبية عند حدوث اختراق، ويحوّل التحكم في الوصول إلى نموذج بسيط ومتسق—خاصة مع ازدياد العمل عن بُعد واعتماد التطبيقات السحابية.
عندما يتحدث الناس عن "أمن المؤسسات"، غالبًا يتخيلون التطبيقات الخاصة والشبكات الداخلية. لكن جزءًا كبيرًا من المخاطر يجلس على جانب الإنترنت المفتوح: الموظفون يتصفحون مواقع إخبارية، ينقرون روابط في البريد، يستخدمون أدوات متصفحة، أو يرفعون ملفات إلى تطبيقات ويب.
بوابة الويب الآمنة (SWG) هي الفئة المصممة لجعل هذا الاستخدام اليومي للإنترنت أكثر أمانًا—دون إجبار حركة كل مستخدم على الالتفاف عبر مكتب مركزي.
ببساطة، تعمل SWG كنقطة تفتيش مسيطرة بين المستخدمين والويب العام. بدلًا من الثقة بكل ما يصل إليه الجهاز، تطبّق البوابة السياسة والفحص حتى تقلل المنظمة من التعرض لمواقع خبيثة، تنزيلات خطرة، وتسرب بيانات عرضي.
الحمايات النموذجية تشمل:
الزخم جاء مع انتقال العمل بعيدًا عن المكاتب الثابتة ونحو SaaS والمتصفحات والأجهزة المحمولة. إذا كان المستخدمون في كل مكان والتطبيقات في كل مكان، يضيف الالتفاف عبر محيط مركزي زمنًا ويخلق نقاط عمياء.
تطابقت SWG المقدمة سحابيًا مع الواقع الجديد: السياسة تتبع المستخدم، يمكن فحص المرور بالقرب من مكان اتصاله، وتحصل فرق الأمان على تحكم متسق عبر المقر والفروع والعمل عن بعد—دون اعتبار الإنترنت استثناء.
بُنيت VPNs لزمن كانت فيه "الوجود على الشبكة" يعني "القدرة على الوصول إلى التطبيقات". ينهار هذا التفكير عندما تكون التطبيقات موزعة عبر سحب متعددة وSaaS وقلة من الأنظمة المحلية.
الوصول المتمحور حول التطبيق يقلب الافتراض. بدلًا من وضع المستخدم على الشبكة الداخلية (ومن ثم الاعتماد على سياسات التقسيم)، يُنشأ اتصال محدود لتطبيق محدد. المستخدم يثبت هويته وما له من أذونات، ثم يُنشأ مسار تحكم قصير للوصول إلى ذلك التطبيق—دون نشر نطاقات IP داخلية على الإنترنت ودون منح رؤية "داخلية" واسعة للمستخدم.
تقسيم الشبكة قوي، لكنه هش في المؤسسات الحقيقية: الاستحواذات، شبكات VLAN مسطّحة، التطبيقات القديمة، والاستثناءات تتراكم. تقسيم التطبيقات أسهل للفهم لأنه يطابق النية التجارية:
يقلل هذا الثقة الضمنية ويجعل سياسات الوصول قابلة للتدقيق: يمكنك مراجعتها حسب التطبيق ومجموعة المستخدمين بدلًا من تتبع المسارات والشبكات الفرعية.
معظم الفرق لا تستبدل VPN بين ليلة وضحاها. عادةً ما يبدو النشر العملي كالتالي:
عندما يُنجز الوصول المتمحور حول التطبيق جيدًا، تظهر المكاسب بسرعة: تذاكر دعم أقل متعلقة بالـ VPN، قواعد وصول أوضح يمكن للأمن وتكنولوجيا المعلومات شرحها، وتجربة مستخدم أكثر سلاسة—خاصة للموظفين البعيدين والهجينين الذين يريدون فقط أن يعمل التطبيق دون "الاتصال بالشبكة" أولًا.
المنتجات الأمنية الجيدة لا تصبح معايير مؤسسية تلقائيًا. عمليًا، "التوزيع" في أمن المؤسسات يعني طرق الوصول والربح والانتشار داخل المنظمات الكبيرة—غالبًا عبر شركات أخرى.
في الأمن، يشمل التوزيع عادةً:
هذه ليست إضافات اختيارية. إنها الأنابيب التي تربط البائع بالميزانيات وصانعي القرار وقدرة التنفيذ.
الشركات الكبيرة تشتري بحذر. يوفر الشركاء:
بالنسبة لمنصة مثل زسكالر، يعتمد التبني غالبًا على عمل هجرة حقيقية—نقل المستخدمين من أنماط VPN القديمة، تكامل الهوية، وضبط السياسات. يمكن للشركاء جعل هذا التغيير يبدو ممكنًا.
التوصيل السحابي يحول العمل من تثبيت لمرة واحدة إلى اشتراك، توسع، وتجديدات. يغير ذلك التوزيع: لم يعد الشريك "مغلق الصفقة" فقط. بل يمكن أن يكون شريك نشر مستمر تتوافق حوافزه مع نتائج العميل—إذا صُمم البرنامج جيدًا.
انظر عن قرب إلى حوافز الشركاء، جودة تمكين الشركاء (تدريب، أوراق لعب، دعم البيع المشترك)، وكيف تتم عمليات تسليم نجاح العميل بعد توقيع العقد. العديد من النشرات تفشل ليس لأن المنتج ضعيف، بل لأن الملكية بين البائع والشريك والعميل تصبح غير واضحة.
نادراً ما يبدأ الشراء الأمني بـ "نحتاج أمنًا أفضل". عادةً يبدأ بتغيير شبكي يكسر الافتراضات القديمة: مزيد من التطبيقات تنتقل إلى SaaS، الفروع تعتمد SD-WAN، أو يصبح العمل عن بُعد دائمًا. عندما لا يعود المرور يمر عبر مكتب مركزي، يتحول نموذج "حماية كل شيء بالمقر" إلى اتصالات بطيئة، استثناءات فوضوية، ونقاط عمياء.
تُذكر زسكالر غالبًا في نفس محادثات SASE وSSE لأن هذه التسميات تصف تحوّلًا في كيفية توصيل الأمان:
الـ"ترجمة العملية للفائدة" ليست الاختصار—إنها عمليات أبسط: أجهزة محلية أقل، تحديثات سياسة أسهل، ووصول مباشر أكثر للتطبيقات دون الالتفاف عبر مركز بيانات.
شركة عادةً ما تقيم نهج SSE/SASE عندما:
عندما تظهر تلك المحفزات، تصل الفئة "طبيعيًا"—لأن الشبكة قد تغيّرت بالفعل.
شراء منصة ثقة صفرية عادةً ما يكون الجزء السهل. جعلها تعمل عبر شبكات فوضوية، تطبيقات موروثة، وأناس حقيقيين هو حيث تنجح المشاريع—أو تتعثر.
التطبيقات القديمة هي المخالف المتكرر. قد تفترض الأنظمة القديمة "داخل الشبكة = موثوق"، تعتمد على قوائم سماح بعناوين IP ثابتة، أو تتعطل عند فحص الحركة.
النقاط الاحتكاكية الأخرى بشرية: إدارة التغيير، إعادة تصميم السياسات، ونقاشات "من يملك ماذا". الانتقال من وصول شبكي واسع إلى قواعد تطبيق دقيقة يجبر الفرق على توثيق كيفية العمل فعليًا—وقد يكشف ذلك عن ثغرات مهملة.
تسير النشرات بسلاسة عندما لا يحاول الأمن العمل بمفرده. توقع التنسيق مع:
ابدأ بمجموعة منخفضة المخاطر (مثل قسم واحد أو مجموعة من المقاولين) وحدد مقاييس نجاح من البداية: قِلّة تذاكر VPN، وصول أسرع للتطبيقات، انخفاض قابل للقياس في السطح المعرض، أو رؤية محسّنة.
شغّل التجربة على دفعات: هاجِر فئة تطبيق واحدة في كل مرة، اضبط السياسات، ثم وسّع. الهدف هو التعلم بسرعة دون تحويل الشركة كلها لبيئة اختبار.
خطط للتسجيل واستكشاف الأخطاء من اليوم الأول: أين تُخزن السجلات، من يمكنه الاستعلام عنها، مدة الاحتفاظ، وكيف ترتبط التنبيهات باستجابة الحوادث. إذا لم يستطع المستخدمون الحصول على مساعدة عندما "يُمنع التطبيق"، تنخفض الثقة بسرعة—حتى لو كان النموذج الأمني سليمًا.
معجِّل عملي وغالبًا ما يُغفل هو الأدوات الداخلية: بوابات بسيطة لطلبات الاستثناء، مراجعات الوصول، جرد التطبيقات، تتبع النشر، والتقارير. تبني الفرق هذه "تطبيقات الغراء" الخفيفة داخليًا بدلًا من انتظار خارطة طريق البائع. منصات مثل Koder.ai يمكن أن تساعد الفرق في بناء هذه الأدوات الداخلية بسرعة عبر سير عمل مدفوع بالدردشة—مفيد عندما تحتاج لوحة معلومات React مع خلفية Go/PostgreSQL، وزيارات سريعة مع تطور السياسات والعمليات.
نقل ضوابط الأمن من أجهزة تملكها إلى منصة سحابية يمكن أن يبسط العمليات—لكنه يغيّر ما تراهن عليه. القرار الجيد أقل عن "الثقة الصفرية ضد القديم" وأكثر عن فهم أوضاع الفشل الجديدة.
إذا وفرت منصة واحدة أمن الويب، وصول التطبيقات الخاصة، فرض السياسات، والتسجيل، فإنك تقلل فوضى الأدوات—لكنك أيضًا تجمع المخاطر. نزاع تعاقدي، تغيير تسعيري، أو فجوة منتج يمكن أن يكون لها أثر واسع أكثر مما لو كانت هذه القطع موزعة عبر أدوات متعددة.
الأمن السحابي يضيف قفزة إضافية بين المستخدمين والتطبيقات. عندما يعمل بشكل جيد، بالكاد يلاحظ المستخدم. عندما يحدث عطل إقليمي أو مشكلة توجيه، قد يبدو الأمر كما لو أن "الإنترنت معطل". هذا أقل عن بائع واحد وأكثر عن الاعتماد على الاتصال دائمًا.
الثقة الصفرية ليست درعًا سحريًا. السياسات المهيّأة بشكل سيئ (متساهلة جدًا، صارمة جدًا، أو غير متسقة) إما تزيد التعرض أو تقاطع العمل. كلما كان محرك السياسة أكثر مرونة، كلما احتجت إلى انضباط أكثر.
النشرات المرحلية تساعد: ابدأ بحالة استخدام واضحة، قِس الكمون ونتائج الوصول، ثم وسّع. عرّف السياسات بلغة بسيطة، نفّذ المراقبة والتنبيه مبكرًا، وخطط للتكرار (توجيه متعدد المناطق، وصول طارئ، ومسارات تراجع موثقة).
اعرف أنواع البيانات التي تحميها (منظمة أم عامة)، ووافق الضوابط مع متطلبات الامتثال، وحدد مراجعات وصول دورية. الهدف ليس الشراء بدافع الخوف—بل التأكد من أن النموذج الجديد يفشل بأمان وبشكل متوقع.
الدرس المتكرر لزسكالر هو التركيز: نقل تنفيذ الأمان إلى السحابة وجعل الوصول مدفوعًا بالهوية. عند تقييم البائعين (أو بناء واحد)، اطرح سؤالًا بسيطًا: "ما هو الرهان المعماري الواحد الذي يبسط كل شيء؟" إذا كان الجواب "يعتمد"، فتوقع ظهور التعقيد لاحقًا في التكلفة ووقت النشر والاستثناءات.
"الثقة الصفرية" نجحت لأنها ترجمت إلى وعد عملي: افتراضات ثقة ضمنية أقل، بنية شبكة أقل، وتحكم أفضل مع انتقال التطبيقات خارج المقر. للفرق، هذا يعني شراء النتائج، وليس المصطلحات التجارية. اكتب النتائج المرغوبة لديك (مثلاً: "لا وصول وارد"، "أقل امتياز للتطبيقات"، "سياسة متسقة للمستخدمين عن بُعد") وربط كل واحدة بقدرات ملموسة يمكنك اختبارها.
ينتشر أمن المؤسسات عبر شبكات الثقة: الموزعون، GSIs، MSPs، وأسواق السحابة. يمكن للمؤسسين تقليد ذلك ببناء منتج جاهز للشركاء مبكرًا—تغليف واضح، هوامش متوقعة، أوراق لعب للنشر، ومقاييس مشتركة. يمكن لقادة الأمن أيضًا الاستفادة من الشركاء: استخدمهم لإدارة التغيير، تكامل الهوية، والهجرات المرحلية بدلًا من محاولة رفع كفاءة كل فريق داخليًا دفعة واحدة.
ابدأ بحالة استخدام عالية الحجم واحدة (غالبًا الوصول إلى الإنترنت أو تطبيق حرج واحد)، قِس قبل/بعد، ثم وسّع.
أسئلة مهمة للنشر:
لا تكتفِ بـ "بيع الأمان"—بع طريق هجرة. القصة الرابحة عادة: الألم → أبسط خطوة أولى → فوز قابل للقياس → توسع. ابنِ الانضمام والتقارير التي تجعل القيمة مرئية خلال 30–60 يومًا.
نمط مناسب للمؤسسين هو إكمال المنتج الأساسي بتطبيقات رفيقة سريعة البناء (سير عمل التقييم، متتبعات الهجرة، حاسبات العائد على الاستثمار، بوابات الشركاء). إذا أردت إنشاء هذه دون إعادة بناء أنبوب تطوير تراثي كامل، فـ Koder.ai مصممة لـ"vibe-coding" لتطبيقات كاملة الواجهة الخلفية—مفيدة لوضع أدوات داخلية أو للعميل بسرعة ثم التكرار مع تطور عملية التوزيع.
إذا أردت الغوص أعمق، انظر /blog/zero-trust-basics و /blog/sase-vs-sse-overview. لأفكار التغليف، زر /pricing.
الـ"ثقة الصفرية" هي نهج حيث تُتخذ قرارات الوصول لكل طلب بناءً على الهوية، حالة الجهاز، والسياق، بدلاً من الافتراض بأن شيئًا ما آمن لمجرد أنه "داخل الشبكة". عمليًا، يعني ذلك:
عادةً ما تضع VPN التقليدية المستخدم "على الشبكة"، مما قد يتيح الوصول إلى أنظمة أوسع مما يحتاجه. الوصول المتمحور حول التطبيق يقلب هذا النموذج:
الـ"مباشر" يعني توجيه الحركة عبر نقطة تفتيش أمنية قبل أن تصل إلى الإنترنت أو تطبيق سحابي. في نموذج مُقدَّم سحابيًا، توجد تلك النقطة في قُرب المستخدم في نقطة وجود (PoP)، بحيث يمكن للمزود:
الهدف هو أمن متسق دون إجبار كل حركة على المرور عبر المقر الرئيسي.
إعادة التوجيه عبر المقر الرئيسي ترسل حركة الويب وSaaS لمستخدم بعيد إلى مركز بيانات مركزي للفحص ثم تُعاد إلى الإنترنت. وغالبًا ما يفشل ذلك لأنه:
بوابة الويب الآمنة (SWG) تحمي المستخدمين أثناء تصفحهم الإنترنت واستخدامهم لتطبيقات SaaS. القدرات الشائعة تشمل:
تُصبح مفيدة بشكل خاص عندما تكون معظم الحركة متجهة للإنترنت والمستخدمون ليسوا خلف جدار ناري مركزي واحد.
الأمن المُقدَّم سحابيًا يمكن أن يبسط العمليات، لكنه يغيّر ما تعتمدون عليه. التوازنات الرئيسية لتقييمها:
عادةً ما ينجح برنامج تجريبي منخفض المخاطر عندما يكون محدودًا وقابلًا للقياس:
الهدف هو التعلم السريع دون تحويل الشركة بأكملها إلى بيئة اختبار.
خطأ التهيئة شائع لأن الانتقال من "الوصول إلى الشبكة" إلى "الوصول عبر التطبيقات/السياسات" يجبر الفرق على تعريف النية بدقة. لتقليل المخاطر:
SSE هو ضوابط أمنية مُقدَّمة من السحابة (مثل SWG والوصول إلى التطبيقات الخاصة) مُقَرَّبة للمستخدمين. SASE يجمع تلك الطبقة الأمنية مع جانب الشبكات (عادة SD-WAN) بحيث تُصمم الاتصال والأمن معًا.
من منظور الشراء:
المؤسسات الكبيرة غالبًا ما تشتري عبر شركاء وتحتاج قدرة تنفيذية. شركاء القنوات، SIs، وMSPs يساعدون من خلال:
يمكن أن يحدّد نظام الشركاء القوي ما إذا كانت منصة ستصبح معيارًا أم تتعثر بعد نشر صغير.