Более того, ИТ-подразделения зачастую не владеют информацией о том, с какими именно приложениями работают конкретные пользователи, и как часто осуществляется доступ к этим приложениям, что фактически приводит к формированию теневых ИТ и снижает эффективность управления ресурсами. С точки зрения контроля доступа возникает также следующий вопрос: каким образом вы можете гарантировать, что в случае ухода сотрудника из компании он перестанет пользоваться корпоративными приложениями? Наконец, даже несмотря на наличие возможности обезопасить доступ к облачным ресурсам средствами многофакторной аутентификации, ИТ-подразделения зачастую не располагают информацией, кто из сотрудников все же позаботился об использовании такой аутентификации. В результате повышается вероятность компрометации данных, угроза фишинга, перебора паролей, взлома облачных баз данных и прочих угроз.
В отсутствие централизованных инструментов управления доступом использование облачных приложений в корпоративном окружении часто не предусматривает механизмов эффективного масштабирования, что приводит к появлению брешей безопасности, увеличению административной нагрузки, раздражению пользователей и снижению эффективности работы организации.
Управление доступом к облачным ресурсам: удостоверения в роли нового периметра безопасности
В 2015 году организация по исследованию хищений учетных данных Identity Theft Resource Center (ITRC) заявила, что утечки данных также неизбежны в нашей жизни, как смерть и налоги. В условиях этой новой реальности Джон Фонтана (John Fontana) из ZDNet предлагает под новым периметром безопасности понимать учетные записи пользователей, а для работы с таким периметром использовать новые средства, основанные на стандартах.
Аутентификация с использованием SAML
Язык разметки SAML (Security Assertion Markup Language) представляет собой открытый стандарт на основе XML, который предназначен для обмена данными аутентификации и авторизации между сторонами процесса. Ставший стандартом с 2002 года, SAML является разработкой Технического комитета по сервисами безопасности (Security Services Technical Committee), который работает при организации OASIS, занимающейся продвижением стандартов для работы со структурированной информацией. С помощью протокола SAML пользователи могут получать доступ ко множеству своих облачных приложений, указывая всего один логин и пароль. Такой подход получил название «федерации удостоверений», поскольку вместо запоминания целого множества логинов и паролей к каждому приложению, пользователю необходимо помнить лишь одну такую пару. При федерации удостоверений единая система, поддерживающая протокол SAML и получившая название доверенного поставщика удостоверений (Identity Provider, IdP), проводит аутентификацию пользователей, при этом облачные приложения «перекидывают» процесс аутентификации на эту IdP систему всякий раз при попытке пользователя получить к ним доступ.
Федерация удостоверений на базе протокола SAML
Федерация удостоверений и система единого входа позволяет избавиться от множества сложностей и проблем, связанных с необходимостью раздельного управления логинами и паролями для доступа к многочисленным веб-приложениям, не важно, реализованы ли они внутри организации, или являются внешними. Федерация стала возможной благодаря применению стандартов, и протокол SAML выступает в роли краеугольного камня в архитектуре и является основным стандартом для федерации удостоверений. Кроме того, широкое распространение этого протокола и рост его популярности также стали важными преимуществами SAML.
Поскольку в основе стандарта лежит язык разметки XML, SAML отличается исключительной гибкостью. Одного внедрения SAML достаточно, чтобы поддерживать подключение сервиса единого входа (single sign-on, SSO) для множества различных партнеров по федерации. Эта совместимость обеспечивает SAML определенные преимущества над другими, закрытыми механизмами единого входа, в частности, SAML позволяет организациям не ограничивать себя решениями какого-либо отдельного поставщика, дает возможность переходить с одной платформы SAML аутентификации на другую.
Чтобы продемонстрировать гибкость и совместимость SAML, в рамках инициативы Kantara была реализована программа тестирования на взаимосовместимость, когда поставщики SAML решений подтверждали возможность взаимодействия своих стандартных коробочных решений с проектами SAML других поставщиков. На сегодняшний день в списке Kantara Trust Registry представлено более 80 сертифицированных решений от многочисленных поставщиков и организаций со всего мира.
Каким образом устроена SAML аутентификация?
Аутентификация средствами SAML предусматривает возможность обмена данными учетных записей между доверенным поставщиком удостоверений (IdP) и облачными или веб-приложениями. Модель SAML аутентификации включает в себя поставщика удостоверений, который выдает 'SAML подтверждения' (SAML assertions) – в роли такого поставщика может выступать, например, SafeNet Authentication Service – и поставщика услуг, который принимает эти подтверждения, например, Google Apps, Office 365 или любое другое облачное приложение, поддерживающее SAML. Подтверждения SAML обычно подписываются с помощью подписи PKI, которая служит доказательством того, что подтверждение является подлинным.
Сервис аутентификации, выступающий в качестве поставщика удостоверений, получает пользовательские учетные данные и возвращает ответ тому облачному приложению, к которому осуществляется доступ. Этот ответ получил название SAML подтверждения. В зависимости от содержимого SAML подтверждения облачное приложение либо принимает, либо отказывает пользователю в доступе. Если SAML подтверждение содержит положительный ответ, то пользователь входит в систему.
Ключевым аспектом в реализации федерации удостоверений средствами SAML является привязка (mapping) пользователей к поставщику удостоверений (IdP) и поставщикам услуг, чтобы при обращении пользователя к сервисам вроде Office 365, эти сервисы понимали, на какого поставщика удостоверений им нужно перенаправить пользователя, чтобы он мог пройти процедуру строгой аутентификации.
Федерация удостоверений для централизованного управления доступом пользователей
SAML позволяет распространить сферу применения имеющихся корпоративных учетных записей пользователей и на облачные приложения. Благодаря федеративной системе проверки подлинности удостоверений пользователи могут полностью обойтись без запоминания многочисленных логинов и паролей. Они смогут получать доступ ко всем своим облачным приложениям, используя одну и ту же корпоративную учетную запись, то есть ту же самую учетную запись, указывая которую они каждое утро входят в сеть.
С точки зрения пользователей федеративная система проверки удостоверений на базе SAML работает максимально органично и незаметно. В SAML используются cookie-файлы, благодаря чему после входа в Office 365 пользователю не требуется проходить повторную аутентификацию при входе в другие облачные приложения в новых вкладках браузера, например в Dropbox, WordPress, Salesforce и т.д.
Преимущества федерации удостоверений на базе протокола SAML
Помимо того, что SAML аутентификация помогает избавить пользователей от необходимости запоминания множества логинов и паролей, эта технология позволяет ИТ-администраторам управлять лишь одной парой учетных данных на пользователя для всех приложений. Поэтому при увольнении сотрудника из организации, ИТ-подразделению достаточно аннулировать лишь одну пару логина и пароля. При этом учетную запись можно аннулировать без необходимости входа в каждое отдельное облачное приложение. Автоматизированные скрипты позволяют минимизировать административную нагрузку на ИТ-подразделения за счет синхронизации с системами хранения учетных записей пользователей, такими как MS SQL или Active Directory.
Если представить ИТ-инфраструктуру в виде офисного здания, то федеративная система проверки подлинности удостоверений с помощью SAML могла бы обеспечить сотрудникам компании более простой и удобный доступ к различным зонам этого здания – к кабинетам, конференц-залу, зоне отдыха, столовой и т.д. – с помощью всего одной карты доступа вместо того, чтобы иметь отдельные карты на каждую комнату.
Кому может потребоваться SAML?
Всем тем, кто сталкивается с необходимостью управлять доступом пользователей к облачным приложениям, и при этом должен добиваться высокой эффективности, безопасности и масштабируемости этого процесса. Веб-приложения вот уже многие годы повсеместно используются в корпоративном окружении, и, вероятно, осталось лишь очень немного компаний, которые без них обходятся.
Комментарии (6)
nmk2002
26.02.2017 18:52GemaltoRussia А можете дать ссылку по этой теме:
Стандарт OATH, в свою очередь, является частью открытой методики OASIS SAML и описывает использование криптографических алгоритмов для создания токенов одноразовых паролей (one-time password, OTP)
?GemaltoRussia
27.02.2017 11:42@nmk2002 в сети довольно много информации по теме, например, можно посмотреть обзор технологии на сайте https://www.oasis-open.org/standards/translations#russian и подробнее о решениях Gemalto http://bit.ly/2lWqTHG
nmk2002
27.02.2017 11:52GemaltoRussia удивительно, но ссылки на переводы стандартов, которые доступны по первой вашей ссылке не работают. Одна «Server Not Found», а вторая — домен предлагается к продаже.
Описание решений gemalto я вроде не просил.
В любом случае, я не уверен, что вы прочитали мой вопрос. Мне интересно только откуда у вас информация о том, что OATH является частью методики OASIS SAML. Я знаком и с SAML и с OATH и искренне удивлен такое прочитать. Не понимаю как эти вещи вообще связаны.GemaltoRussia
28.02.2017 14:32@nmk2002 к сожалению, ресурс, на который дана первая ссылка нами не управляется, возможно, они еще обновят информацию. Что же касается приведенного фрагмента текста – спасибо за замеченную неточность, действительно, OATH был создан организацией Initiative for Open Authentication (OATH) https://openauthentication.org/, в то время как SAML создан Organization for the Advancement of Structured Information Standards (OASIS) https://www.oasis-open.org/ – эти стандарты не являются частью друг друга.
methlab
Позанудствую:
— что это за термин? Можете его пояснить?
GemaltoRussia
@methlab, это прямой перевод английского термина Identity federation, обозначающего возможность обмена данными учетных записей между доверенными сторонами для аутентификации пользователей.