Portalguard مراجعة وتقييم

حل إدارة الهوية (الهوية) كخدمة (IDaaS) يلبي احتياجات الشركات الكبيرة ، ويقدم PortalGuard بوابة تسجيل دخول فردي قابلة للتخصيص (SSO) ، وإعداد التقارير المستندة إلى لغة الاستعلام الهيكلية (SQL) ، والعديد من إمكانات الأمان التي تستهدف لتخفيف نقاط الضعف الرئيسية في مصادقة تطبيق البرنامج كخدمة (SaaS). الجانب الإيجابي الآخر في عرض PortalGuard هو التسعير ، والذي يعتمد على مثيلات الخادم بدلاً من عدد المستخدمين. وهذا يؤدي إلى وفورات كبيرة في التكاليف المحتملة للعملاء المستهدفة. ومع ذلك ، فإن الافتقار إلى إمكانيات التزويد SaaS وعدم وجود دعم لهويات المستهلك يجعله وراء الفائزين في اختيار المحررين Microsoft Azure Active Directory (Azure AD) و Okta Identity Management في تقرير مراجعة IDaaS هذا.

الإعداد والتكامل

يتم تثبيت PortalGuard للنشر الداخلي أو الخاص السحابي باستخدام خدمات معلومات إنترنت لـ Microsoft (IIS) كنظام أساسي لخادم الويب الخاص بها. تتطلب لوحة معلومات PortalGuard Administrator أيضًا Microsoft SQL Server 2005 أو إصدار أحدث ، مما يتيح إمكانات تسجيل النشاط والإبلاغ عنه. كما هو الحال مع العديد من حلول IDaaS التي قمنا بمراجعتها ، وبصفة خاصة مع الحلول ذات الميل الداخلي ، يوفر PortalGuard دعمًا للقفازات البيضاء طوال عملية الإعداد. هذا يجب أن يخفف بعض القلق بشأن تعقيدات التثبيت. يمكن أيضًا استخدام SQL Server للحفاظ على بيانات ملف تعريف المستخدم بدلاً من التخزين المستند إلى الملفات ، والذي يمكن أن يوفر مزايا أداء في عمليات النشر الكبيرة.

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

يتم دعم بروتوكول الوصول إلى الدليل الخفيف (LDAP) عالميًا في حلول IDM التي اختبرناها ، و PortalGuard ليس استثناءً. على الرغم من أن Microsoft Active Directory (AD) هو الحل الأكثر شيوعًا للدليل ، إلا أن PortalGuard يدعم على وجه التحديد العديد من دلائل LDAP الأخرى من قطاع الصناعة مثل Novell و Oracle / Sun و IBM (Lotus Domino و Tivoli Directory Server). بغض النظر عن بائع دليل LDAP ، تتضمن عملية التكوين تكوين معلومات الاتصال للدليل ، مثل اسم مضيف الخادم ورقم المنفذ واسم المستخدم وكلمة المرور. يمكنك أيضًا تخصيص السمات المستخدمة لمتطلبات الحقل العامة مثل اسم مستخدم تسجيل الدخول والبريد الإلكتروني والاسم الشائع ، بالإضافة إلى تكوين عوامل تصفية البحث للمستخدمين والمجموعات داخل الدليل.

يدعم PortalGuard أيضًا هويات المستخدمين الموجودة في جداول قاعدة البيانات ، مما يسمح بتضمين تطبيقات الشركات التي تدير هوياتهم (المخزنة في جداول قاعدة البيانات) في حل IDaaS كليًا. تستخدم هذه الوظيفة اتصال قواعد البيانات المفتوح لـ Microsoft (ODBC) ، الذي يضيف طبقة تكوين أخرى ، ولكنه يجعل القدرة متوافقة مع مجموعة واسعة من بائعي قواعد البيانات. يتضمن تكوين مستودع مستخدم يستند إلى SQL تكوين اتصال ODBC وتوفير بيانات اعتماد لاتصال قاعدة البيانات وتكوين جداول قاعدة البيانات والأعمدة التي تحتوي على معلومات المستخدم الهامة. بالإضافة إلى ذلك ، يمكن تكوين عبارات SQL والمعلمات لكتابة التغييرات بشكل صحيح مرة أخرى إلى قاعدة البيانات.

علامة واحدة على

يوفر PortalGuard إمكانيات SSO للتطبيقات التي تدعم معايير لغة توكيد تأكيد الأمان (SAML) أو CAS (خدمة المصادقة المركزية) ، وكذلك تلك التي تقدم تسجيلات اسم المستخدم وكلمة المرور المستندة إلى النماذج فقط. تتم معالجة تكوين تطبيقات SSO من خلال محرر تكوين الهوية ، وهو تطبيق لسطح المكتب مثبت على خادم PortalGuard مع محرر تكوين PortalGuard. تتضمن عملية التكوين لكل نوع من أنواع SSO تكوين معلومات الاتصال الأساسية ، مثل عناوين URL المستخدمة في الاتصال وتحديد السمات وتنسيقها. يمكن اعتماد المستخدمين أو المجموعات أو الوحدات التنظيمية للتطبيقات أيضًا ، مما يضع أيقونة التطبيق في مدخل الدخول الموحد للمستخدم المناسب.

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

بوابة SSO للمستخدم النهائي بسيطة إلى حد ما ، ولكن القصد من ذلك هو قيام الشركات بتخصيص البوابة مع علاماتها التجارية الخاصة بها ، وبالتالي فإن البساطة هي الأفضل. ومع ذلك ، فإن رواد الفئات مثل Microsoft Azure AD و Okta Identity Management و OneLogin يوفرون للمستخدمين إمكانية تخصيص طريقة العرض الخاصة بهم عن طريق استخدام الفئات المستندة إلى المجلد أو إضافة تطبيقاتهم الخاصة أو حتى إخفاء التطبيقات التي لا يستخدمونها. يختار PortalGuard بوابة SSO سريعة الاستجابة يجب أن تعمل بشكل جيد على قدم المساواة على تطبيقات سطح المكتب أو الجهاز اللوحي أو الهاتف الذكي.

من حيث المقارنة مع حلول IDaaS المتنافسة ، فإن PortalGuard يحتوي على عدد من الإغفالات الصارخة من قائمة الميزات الخاصة به ، واحدة يمكن مسامحتها ، وواحدة أقل من ذلك بكثير. أولاً ، لا يدعم PortalGuard هويات المستهلكين في شكل حسابات Google أو Facebook أو Microsoft أو LinkedIn. تعد IDaaS للمستهلك مشكلة جديدة نسبيًا بالنسبة للعديد من الشركات ، ولن يمثل غيابها ضربة قاتلة للعديد من الأشخاص الذين يقررون خيار IDaaS. الغياب الثاني ، والأكثر خطورة ، هو نقص التزويد في تطبيقات SaaS. من الناحية الفنية ، يتطلب التوفير SaaS من تطبيق SaaS دعم التوفير من خلال واجهة برمجة التطبيقات (API) ، ولحل IDaaS للتكامل مع API لأغراض التوفير. السبب الذي يجعلنا نشعر أن هذه ميزة هامة هو الافتراض بأن حل IDaaS يتم تنفيذه جزئيًا لتخفيف عبء العمل الإداري الذي تنطوي عليه الهويات والأمن المحيط بهذه الهويات. إن عدم القدرة على أتمتة إنشاء حسابات مستخدمين في تطبيقات SaaS المهمة للأعمال يشبه الجلوس على كرسي ثلاثي الأرجل يفقد ساقه: إنه يتطلب عملاً إضافيًا فقط للبقاء في وضع مستقيم. يخبرنا PortalGuard أن الدعم لنظام إدارة هوية المجالات المشتركة (SCIM) 2.0 سيأتي في الربع الثالث من عام 2017 ، والذي سيوفر على الأرجح أدوات لتوفير SaaS.

الإبلاغ والتسعير

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

يعتمد تسعير PortalGuard على البنية التي تختار استخدامها. تبلغ قيمة عمليات النشر المحلية 5000 دولار سنويًا لصيانة البرامج ، مع رسوم إضافية مبدئية بقيمة 20.000 دولار للمؤسسات التي تضم أكثر من 1000 مستخدم متزامن (ستشهد عمليات النشر الأصغر إلغاء تكلفة بدء التشغيل الأولية). سيتم تشغيل اختيار نشر سحابي خاص بقيمة 455 دولارًا شهريًا للمؤسسات التي تضم ما يصل إلى 1000 مستخدم متزامن أو 663 دولارًا مع ما يصل إلى 10،000 مستخدم. في حين أن هذه الأسعار قد تتسبب في حدوث صدمة لاصقة عند مقارنتها بخيارات مثل Azure AD أو Okta Identity Management التي تقدم التسعير على أساس كل مستخدم ، تجدر الإشارة إلى أن التسعير يصبح منافسًا لتلك الحلول عند 50-100 مستخدمًا فقط.

يأتي PortalGuard مزودًا بدعم Silver ، والذي يوفر الوصول إلى الدعم من خلال البريد الإلكتروني أو الدردشة عبر الإنترنت من الساعة 9 صباحًا إلى 5 مساءً بالتوقيت الشرقي. يتوفر الدعم الذهبي بمبلغ إضافي قدره 1000 دولار شهريًا ، ويمنحك بضع ساعات إضافية في نافذة الدعم اليومية ، من الساعة 7 صباحًا إلى 7 مساءً بالتوقيت الشرقي. إذا كنت بحاجة إلى دعم على مدار الساعة وطوال أيام الأسبوع ، فإن مستوى دعم البلاتينوم يكون متاحًا بمبلغ 2،000 دولار سنويًا.

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