Применение облачных сервисов вслед за сегментом B2C все больше становится реальностью на российских предприятиях. Сегодня уже практически в любой коммерческой организации, как минимум, часть бизнес-функций автоматизируются облачными приложениями. Офисное П О, бухгалтерия, управление проектами и продажами — это только малая часть облачных сервисов, которые на ежедневной основе используются корпоративным сегментом. Предоставление контролируемого доступа к своим SaaS-приложениям сотрудникам организаций-партнеров стало основной формой интеграции предприятий в рамках кластеров различных типов, деловых сетей, при использовании и предоставлении услуг аутсорсинга.

Разумеется, охват облачной модели в крупных российских организациях пока не достиг масштабов полной замены on-premises приложений. Тем не менее в последние годы наметилась устойчивая положительная тенденция, действующая именно в этом направлении. Конечно, это связано с несомненными плюсами облачной технологии. К её «плюсам» относится: снижение затрат на поддержку, повышенное юзабилити, мобильность, прозрачная модель оплаты и т. п. В то же время, за эти преимущества надо платить. Передача важных функций, включая обработку критичной для бизнеса информации, на сторону «внешнего» сервиса повышает требования к информационной безопасности. При этом одной из главных задач становится обеспечение надежной аутентификации и авторизации пользователей в облачных приложениях, причем обязательно с высоким уровнем удобства (юзабилити) этих процессов для пользователей. Иными словами, пользователь не должен замечать разницы в процедурах доступа к корпоративным приложениям, предлагаемым по разным моделям. Добиться этой цели можно несколькими способами.

Первый способ, который кажется наиболее естественным, — это синхронизация каталогов пользователей. То есть, корпоративный каталог, как правило реализованный на базе технологии MS Active Directory (MS AD), который используется для аутентификации во внутренней корпоративной сети, может быть «продублирован» в облаке. Тогда пользователи смогут под тем же логином и паролем получать доступ как к внутренним, так и к облачными сервисам. Однако сразу возникает опасение, что этот простой в реализации и удобный для пользователя вариант несет в себе высокие риски ИБ. Ведь фактически мы передаем внешнему провайдеру данные для аутентификации к внутренним ресурсам предприятия (это строжайшая тайна любой организации!), не имея возможности обеспечить такой уровень контроля доступа к этой информации, который считаем необходимым. Это вполне реальная проблема, и именно поэтому такой вариант нельзя считать оптимальным. С другой стороны, эти риски можно снизить, создав дополнительную базу пользователей для доступа к облачным сервисам, в которой данные для идентификации и аутентификации будут отличаться от основного каталога. Однако это решение небезупречно. Мы можем обеспечить необходимый уровень ИБ, но при этом «нагружаем» пользователя дополнительным логином и паролем. Также возрастает нагрузка на администраторов, которые должны сопровождать еще один пользовательский каталог. Налицо нарушение критерия юзабилити. И это очень серьезное нарушение, ведь речь идет о удвоении пар логин-пароль для всех приложений и защищенных ресурсов, с которыми работает пользователь. А ведь эти данные должны еще и часто меняться — в соответствии с корпоративными политиками ИБ!

Эту проблему можно устранить с помощью технологии корпоративного SSO (Single Sign-On) — единой однократной аутентификации пользователя во всех нужных ему ресурсах. Она обеспечивает «прозрачную» аутентификацию в различных приложениях со своими каталогами пользователей. Суть этой технологии достаточно проста. На рабочую станцию пользователя устанавливается агентское приложение (SSO-агент), которое перехватывает окна аутентификации и подставляет в них необходимые данные пользователя из его защищенного профиля. Также в архитектуре решения присутствуют централизованная база данных, где хранятся пользовательские профили, а также SSO-сервер, отвечающий за их синхронизацию с агентом. Таким образом система SSO фактически эмулирует действия пользователя, освобождая его от необходимости запоминать логины и пароли ко всем системам. Пользователю достаточно запомнить лишь одну пару логин-пароль и вводить ее, например, при входе в ОС, в остальных приложениях за него это сделает система SSO, подставляя актуальное сочетание логина и пароля к каждому ресурсу. Такой метод резко повышает удобство доступа к информационным ресурсам. При этом непосредственно процесс аутентификации и хранение соответствующих пользовательских данных осуществляется на стороне каждого приложения в отдельности, как внутреннего, так и внешнего. Однако это решение нельзя считать безупречным, ведь сопровождение такой системы, включающее формирование и актуализацию профиля пользователя, по-прежнему будет требовать дополнительных трудозатрат администратора.

Как же сделать так, чтобы вход в приложения был единый, т. е. обеспечить SSO-аутентификацию, но на основе общего каталога пользователей? Решение этой задачи стало возможно с появлением систем класса IDP (identity provider) или, в более широкой терминологии, Web SSO. В соответствии с этой технологией аутентификация осуществляется в едином сервисе с общей базой пользователей, а приложениям только передается ответ об успешной аутентификации (токен), включающий в том числе идентифицирующие данные пользователя. Приложение, получив такой ответ, может понять, какому пользователю необходимо предоставить доступ — и авторизует его. Взаимодействие между IDP и приложением осуществляется в соответствии со стандартизированными протоколами, из которых наиболее популярны SAML 2.0, OAUTH 2.0 и OpenID Connect 1.0 (как расширение стандарта OAUTH).

С точки зрения пользователя процесс аутентификации через IDP выглядит так. После его обращения к web-приложению, он автоматически перенаправляется на страницу аутентификации IDP (это возможно за счет настроек приложения). Там он вводит свой корпоративный логин и пароль, а система IDP проводит его аутентификацию и (в случае успеха) перенаправляет пользователя на страницу приложения. Кроме того, система IDP передает приложению токен. А оно (на основании информации из токена) авторизует пользователя в соответствие с его правами доступа. Если пользователь, пройдя аутентификацию в одном приложении, обращается к другому, также интегрированному с IDP, то при перенаправлении его на сервис аутентификации, IDP проверит его текущую сессию в специальном хранилище и, если она существует, передаст второму приложению токен, не проводя повторную аутентификацию пользователя. Таким образом выполняется принцип единой однократной аутентификации пользователей.

Обеспечивая единую однократную аутентификацию, мы повышаем удобство для пользователя, но в то же время в некотором смысле ослабляем безопасность приложений, ведь одной пары логин-пароль достаточно, чтобы получить доступ к большому числу информационных ресурсов. Поэтому при использовании SSO — вне зависимости от применяемой технологии (агентская или IDP) — крайне желательно усиливать аутентификацию по логину и паролю дополнительными факторами аутентификации. В настоящее время в корпоративном SSO чаще всего используются аппаратные USB-токены или смарт-карты, реже встречается биометрия, например, по отпечатку пальцев. В IDP/Web SSO наиболее популярный метод усиленной аутентификации — это технология одноразовых паролей (OTP). Доставка одноразового пароля пользователю может быть организована по-разному, чаще всего с помощью SMS, генерации на специальном устройстве или в приложении на смартфоне. В силу особой популярности этого вида аутентификации, ее алгоритмы постоянно развиваются в направлении как повышения удобства использования, так и защищенности от взлома. В настоящее время наиболее надежной считается технология TOTP (Time-based One Time Password), реализованная, например, в приложении Google Authenticator. Отмечу, что развитые SSO-продукты позволяют усилить аутентификацию не только при первичной аутентификации, но и для отдельных приложений, оперирующих особо чувствительными данными. Например, чтобы войти в ОС и пройти аутентификацию в домене, достаточно логина и пароля, но для доступа к ERP-системе потребуется дополнительно ввести одноразовый пароль или приложить палец к считывателю.

С развитием облачных сервисов активно развиваются и облачные технологии управления доступом. Это подтверждают и исследования международных аналитических компаний, таких как Gartner. На западном рынке, где доля облачных приложений уже превысила on-premises, все больше производителей решений по управлению доступом предлагают облачные версии своих продуктов. Западные производители, например, Okta и OneLogin, лидеры зарубежного рынка access management, пока малоизвестны в России, даже в профессиональном сообществе. Причиной тому — недостаточное развитие «облаков» в России, законодательные сложности трансграничной передачи данных, да и общее недоверие к облачной технологии, тем более к иностранным сервисам. Нельзя сказать, что это недоверие безосновательно. Поэтому в настоящее время оптимальным решением для корпоративного рынка в России является применение внутрикорпоративного IDP-решения (in-house), которое позволяет обеспечить единый доступ не только к внутренним ресурсам, но и к внешним приложениям, сохраняя при этом все критичные данные пользователей внутри корпоративной сети.