16.03.2011
Критерии оценки Single Sign-On решений
При выборе Single Sign-On (SSO) решения, приходится учитывать множество факторов, от которых зависит успешность проекта. Новый продукт необходимо встроить в существующую информационную среду, не создав дополнительной нагрузки на ИТ-службу, и, главное, SSO должно эффективно выполнять свои функции в конкретном окружении компании. В этом посте я постарался собрать вместе и описать критерии, которые полезно учитывать при выборе SSO-системы.
| Критерий | Комментарий |
|---|---|
| Поддержка технологии строгой аутентификации | Технологий Single Sign-On, упрощая жизнь конечных пользователей, может стать причиной снижения информационной безопасности. Если при однократной аутентификации используется пароль (т.н. мастер-пароль), то злоумышленник, узнав данный пароль, автоматически получает доступ ко всем приложениям, входящим в SSO-профиль пользователя. По этому, крайне желательно, чтобы для однократной аутентификации использовались надежные технологии аутентификации. |
| Какие технологии строгой аутентификации поддерживаются SSO-решением | Отдельно стоит оценить технологии аутентификации, предлагаемые SSO-решением. По этой теме есть хороший пост в нашем блоге. |
| Как происходит наполнение SSO-профиля доступа сотрудника учетными данными | Возможные сценарии:
|
| Централизованное администрирование системы | Централизованное управление доступом, например, дает возможность оперативно отозвать доступ сотрудника (например, при увольнении). |
| Доступ к рабочему столу Windows® | Возможность использовать технологию строгой аутентификации при доступе к рабочему столу. В этом случае, момент первоначальной аутентификации в SSO-системе, как правило, совмещается в понятной конечному пользователю точке — моменте входа в Windows. |
| Возможность защитить запуск SSO-приложения с помощью требования повторной аутентификации при каждом входе в приложение | В большинстве случаев, данная функциональность гарантирует что вход в приложение выполняется в присутствии и с согласия пользователя (т.е. пользователь уже не сможет сказать «Я отошел от ПК и в этот момент кто-то запустил приложение и выполнил какие-то действия»). |
| Возможность работы в offline-режиме | В offline-режиме недоступна ИТ инфраструктура предприятия. Например, доступ в приложения с ноутбука в командировке. |
| Поддержка терминального режима работы (терминальные сервера, тонкие клиенты) | Позволяет ли SSO-решение выполнять вход в приложения, запущенные на терминальных серверах (Microsoft TS, Citrix Metaframe и т.п.). Поддерживаются ли при этом тонкие клиенты. |
| Использование ролевой модели предоставления доступа. | Ролевая модель позволяет установить соответствие между должностью (ролью) сотрудника и набором приложений, доступном сотруднику. |
| Аудит событий системы | Фиксирует ли система факты изменения/предоставления/получения доступа. В каком формате это делается, возможно ли построение отчетов на базе этой информации. |
| Поддерживаемые платформы приложений | Какие целевые приложения поддерживаются:
|
| Возможность поддержки нового целевого приложения силами клиента | Можно ли самостоятельно интегрировать новое приложение в SSO-систему, насколько это сложно сделать. |
| Возможность поддержки нового целевого приложения силами вендора | Такая возможность будет полезна, например, в случае сложного для интеграции приложения. |
| Необходимость модификации целевого приложения | Нужно ли что-то менять в целевом приложении. Как правило, менять приложение очень не желательно (например, можно лишиться технической поддержки, в случае изменения программной части). |
| Интеграция с популярными Identity Management (IDM) системами | Например, с Oracle IDM или Microsoft Forefront Identity Management. Интеграция с такими системами позволяет добиться полной автоматизации в предоставлении доступа пользователям. После занесения нового пользователя в систему и определения его должности, (а) для него автоматически создаются все необходимые учетные записи (отрабатывает IDM-решение) и (б) он сразу получает прозрачный доступ во все необходимые приложения (часть Single Sign-On). |
| Интеграция с СКУД системами | Интеграция возможно как на уровне носителя аутентификации: использования единой карты для прохода через турникеты и входа в приложения; так и на более глубоком уровне, позволяя, например, учитывать местоположение сотрудника при предоставлении ему доступа в приложения. |
| Поддержка PKI инфраструктуры | Возможность шифрования паролей от приложений сертификатом пользователя. |
| Возможные хранилища для данных системы | Как правило, в качестве хранилища могут выступать
|
| Системные требования: поддерживаемые серверные/клиентские ОС, аппаратные требования. | В т.ч. возможность работы на терминальных серверах. |
