Олег Губка, директор по развитию бизнеса компании Аванпост
Web-технологии уже давно стали основным подходом в разработке пользовательских интерфейсов программного обеспечения. В отличие от приложений с «толстым» клиентом web-приложения не требуют установки клиентского ПО, независимы от аппаратной части и легче сопровождаются.
Web-технологии уже давно стали основным подходом в разработке пользовательских интерфейсов программного обеспечения. В отличие от приложений с «толстым» клиентом web-приложения не требуют установки клиентского ПО, независимы от аппаратной части и легче сопровождаются. компьютер, смартфон и даже телевизор, и из любой точки мира. Web-технологии способствовали активному развитию облачных сервисов, без которых уже сложно представить будущее информационных технологий.
Такое проникновение «паутины» во все сферы нашей жизни кроме очевидных плюсов несет в себе и определенные сложности. Это становится наиболее заметно и критично в корпоративной среде. Каждое приложение для обеспечения безопасности данных требует защищенного входа с использованием личного идентификатора пользователя (логина) и пароля. Причем, пароль должен удовлетворять определенным требованиям. Как правило, он не должен быть меньше 8 символов, включать строчные и прописные буквы, цифры и спецсимволы. Запомнить такой пароль уже для одного приложения не так просто, а так как для работы чаще всего необходим доступ к нескольким приложениям, то эта задача сложно выполнима даже для подготовленного пользователя. Поэтому пароли в большинстве случаев содержат в себе «слабую» последовательность, которая легче взламывается. Либо пароль для доступа к личным приложениям, например, электронная почта или социальные сети, применяется для корпоративных, что тоже серьезно ослабляет их безопасность. Но главная «боль» безопасника — это пароли, записанные на бумажке, которую хранят, как правило, в доступном месте. Думаю, не надо объяснять, насколько высок риск компрометации паролей в данном случае.
Для того, чтобы обеспечить удобство пользователя при доступе к приложениям, а также снизить риски несанкционированного доступа, появились решения класса SSO (SingleSign-On). Решения данного класса позволяют организовать единый вход в информационные системы, не связанные между собой с точки зрения подтверждения подлинности пользователя – аутентификации. То есть системы, в которых для доступа нужна своя пара логин-пароль, объединяют на уровне аутентификации. Пользователю достаточно однократно ввести единый логин и пароль, после чего он «прозрачно» получает доступ к приложениям, в которые он ему разрешен. Таким образом пользователю нужно запомнить только один «сильный» пароль, который сложнее скомпрометировать.
Есть два основных подхода к реализации принципа SSO. Первый — это так называемое корпоративное SSO, когда на рабочее место пользователя устанавливается программный агент, который перехватывает окно входа в приложение и подставляет логин и пароль к этому приложению из защищенного профиля пользователя. Защищенный профиль пользователя хранится на SSO-серверe, периодически обновляется после смены паролей в приложениях и синхронизируется с SSO-клиентом на компьютере пользователя. Фактически система SSO эмулирует действия пользователя, подставляя его данные для аутентификации. Пользователю достаточно однократно ввести логин и пароль при первичной аутентификации, например, при включении компьютера и входе в операционную систему, далее SSO-клиент обеспечит ему прозрачный вход при запуске приложений. Очевидно, что при необходимости установки и сопровождения клиентской части системы, такая архитектура SSO применима только в корпоративной ИТ-инфраструктуре. Поэтому SSO-решения данного типа называют корпоративными. В случае, когда необходимо обеспечить доступ к web-приложениям большого числа, как правило, внешних пользователей, подход с корпоративным SSO перестает эффективно работать. Поэтому для решения таких задач есть второй вариант – это Web SSO.
Решения класса Web SSO построены по принципу организации единого сервиса аутентификации. То есть функцию подтверждения подлинности пользователя выполняют уже не конечные приложения, а система WebSSO. Для того, чтобы приложению сообщить об успешной аутентификации пользователя в Web SSO, обеспечивается соответствующая интеграция. С точки зрения пользователя сценарий входа в приложение выглядит следующим образом. При доступе к приложению он автоматически перенаправляется на страницу аутентификации WebSSO, где он вводит свой логин и пароль. После успешной проверки пользователь возвращается на страницу приложения под своим профилем. После первичной аутентификации система Web SSO запоминает данные об успешной аутентификации (сессии) пользователя и при повторном входе, в том числе в другие приложения, пользователь будет получать доступ прозрачно без ввода логина и пароля. Таким образом обеспечивается принцип однократности входа.
Несмотря на то, что корпоративное SSO при установке дополнительных плагинов в браузере также может работать с web-приложениями, Web SSO проще в эксплуатации и сопровождении. В Web SSO отсутствует клиентская часть, которую достаточно сложно сопровождать, тем более при разнородном парке рабочих станций и операционных систем. При этом Web SSO обеспечивает единый каталог пользователей для всех приложений, что значительно снижает нагрузку на администраторов по поддержке. В качестве примера можно привести значительное сокращение количества заявок по сбросу паролей, которые пользователи часто забывают, например, после отпуска. Поэтому решения Web SSO все чаще применяются не только для внешнего доступа к информационным системам, но и для внутреннего доступа к корпоративным ресурсам сотрудниками организации.
В зависимости от возможностей интеграции с приложениями в системах Web SSO могут использоваться разные архитектурные решения. Наиболее перспективным вариантом является IDP (identity provider), когда сервис SSO стоит рядом с приложением и взаимодействует с ним по стандартизованным протоколам, таким как SAML 2.0 и Open ID Connect 1.0. Данные протоколы обеспечивают обмен данными о пользователе и его аутентификации. Плюсами IDP являются умеренные требования к аппаратной части, так как в архитектуре решения он стоит в стороне от приложений и даже при большой нагрузке на приложения получает только запросы на аутентификацию. Минусами применения IDP является необходимость поддержки выше названных протоколов на стороне информационных систем. Это не является серьезной проблемой, так как большинство современных промышленных web-приложений поддерживают их «из коробки», и даже в случае отсутствия таких возможностей «из коробки», доработка приложений не несет серьезных трудозатрат для разработчика. В то же время это может вызвать определенные сложности, в случае недоступности разработчика приложения и/или отсутствия контракта на его сопровождение. Другое решение по интеграции Web SSOс приложениями называется reverse proxy. В этом случае система Web SSO ставится в разрыв между пользователем и приложением. При запросе пользователя к приложению он сразу попадает на страницу аутентификации Web SSO. После успешной аутентификации система добавляет к запросу пользователя его идентификатор, чтобы приложение смогло его определить и авторизовать. Так как reverseproxy пропускает через себя все запросы пользователей, он более требователен к аппаратной части, чем IDP и масштабируется вместе с приложениями. Это основной минус reverse proxy. Плюсом является возможность более простой интеграции, не требующей доработки приложений.
Для повышения безопасности входа в приложения в Web SSO могут применяться дополнительные факторы аутентификации, то есть, кроме логина и пароля, необходимо предъявить дополнительный элемент, которым владеет только пользователь. Когда речь идет о доступе внешних пользователях, например клиентов организации, чаще всего используются одноразовые пароли. Пользователь может получить одноразовый пароль по смс в процессе аутентификации или же сгенерировать в мобильном приложении. Для внутрикорпоративных сервисов могут использоваться аппаратные факторы аутентификации, такие как usb-токены или смарт-карты. Применяется и биометрическая аутентификация, например, по отпечатку пальца.
С развитием облачных сервисов стала доступна модель облачного Web SSO. На сегодняшний день по такой модели работают только иностранные производители, например, Okta и One Login.Но если у вас в компании используются преимущественно облачные приложения от мировых производителей, облачный Web SSO– оптимальный вариант. Он не требует установки и сопровождения в вашей инфраструктуре, продается по подписке с разумными ценами, предлагает широкую функциональность и удобство использования. Но пока компаний с облачной инфраструктурой в России очень мало, поэтому Web SSO чаще всего используется по модели on-premises, то есть устанавливается в инфраструктуре организации. В этом случае список продуктов намного шире и представлен, в том числе, российскими производителями. Каждый из вендоров находит своего заказчика и пока конкуренция имеет скорее пассивный характер. Тем не менее, любое многообразие продуктов несет определенные риски для заказчика при выборе. Все производители заявляют похожую функциональность и сложно понять, какой продукт вам лучше подходит. Выход из этой ситуации, как всегда, один – пилотировать данные решения в своей инфраструктуре и знакомиться с реальными кейсами внедрения. После правильного выбора и проектирования внедрение системы Web SSO займет еще несколько месяцев. Но преимущества от использования WebSSO станут заметны не только на уровне ИТ- и ИБ-подразделений, но и на уровне бизнеса, что положительно повлияет на успешность как внутренней, так и внешней деятельности организации.
