Сергей Пожарненков, руководитель практики систем идентификации и контроля доступа к ИТ ресурсам «Астерос Информационная безопасность» (группа «Астерос»)

IDaaS (Identity-as-a-Service) – молодой и пока еще очень спорный сегмент рынка информационной безопасности. Эксперты в ИБ чаще высказываются в негативном ключе относительно надежности такого рода систем, в то время как вендоры подталкивают компании вперед, предлагая новые средства заодно со всем спектром удобств и преимуществ, которые несет в себе перевод инфраструктуры компаний в облако. Давайте разберемся, что такое IDaaS, какие выгоды и риски он в себе несет.

По своей сути IDaaS – это облачный IAM, предоставляемый как сервис, обычно включающий следующие услуги (но не ограничивающийся ими):

  • Provisioning – управление жизненным циклом учетных записей;
  • Cloud SSO – облачная система сквозной однократной аутентификации;
  • Password Management – управление паролями;
  • Access Governance – управление доступом. В отличие от provisioning здесь сосредоточены высокоуровневые процессы, такие как поддержка ролевой модели, предоставление и отзыв полномочий пользователей, разграничение нежелательных полномочий и т. п.

Прелесть IDaaS (как и любого SaaS-продукта) состоит в том, что его можно использовать ровно в том объеме, в каком у вас возникла потребность. Предположим, некая организация решила создать портал, интегрировав на него ряд сервисов, и нуждается в однократной сквозной авторизации. Чтобы понять, как это работает, представим портал Google. Каждый сервис в нем, будь то почта, фотоальбом или Google-диск, – это самостоятельный элемент, требующий от пользователя авторизации. Но вы перемещаетесь между такими сервисами, не чувствуя «швов» и не вводя пароль каждый раз, когда переключаетесь с почты на фотографии. Это и есть SSO. Если компания решит создать для своих клиентов портал, куда захочет интегрировать готовые сервисы и обеспечить аналогичное удобство работы пользователей, ей придется обслуживать специальный сервис, который бы сопоставлял логин и пароль пользователя со специальной электронной меткой. Эта метка передается интегрируемым в портал сервисам и служит для аутентификации. Кроме того, в отличие от публичных сервисов Google к сервисам компании не все пользователи могут иметь одинаковый доступ, поэтому вам необходимо управлять политиками доступа пользователей к сервисам.

В данном примере очевидны расходы на создание собственного сервиса единого входа и его обслуживания, он будет потреблять ресурсы – мощность сервера и трафик. Это может быть оправданно, когда порталом пользуется большое количество сотрудников или клиентов. Но если использование вашего портала не очень интенсивно, то можно не строить собственный сервис SSO, а воспользоваться услугой в облаке. В этом случае все расходы на обслуживание сервиса несет провайдер, и такой вариант может быть более выгодным.

Сложнее, когда вы решаете не локальные задачи, а выстраиваете комплексную систему управления идентификационной информацией. Кроме преимуществ, которые несет в себе IDaaS, придется считаться и с рисками безопасности: процесс управления идентификационной информацией, критический для жизнедеятельности бизнеса, который раньше был защищен межсетевым экраном и находился внутри доверенной корпоративной сети, теперь передан третьей стороне. Безопасность процесса зависит от конкретного провайдера: насколько являются зрелыми его меры обеспечения безопасности данных своих клиентов, насколько они защищены от злоупотреблений со стороны сотрудников провайдера. Такие риски недостаточно оценить однократно, их придется учитывать на протяжении всего времени использования IDaaS. В настоящее время это является исключительно вопросом доверия, ибо не существует ни стандартов, ни достаточного количества положительных практических примеров передачи внешним провайдерам указанного процесса.

Перевод IAM полностью в облако для компании, имеющей зрелые и развитые процессы управления идентификационной информацией, – это скорее из разряда гипотез, чем из практической плоскости, и тому есть ряд причин.

Во-первых, IAM выстраивается индивидуально под клиента, отражая особенности его бизнеса, и унифицированные процессы управления идентификационной информации подойдут далеко не всем.

Во-вторых, ожидая получить от внедрения IAM максимальный экономический эффект, клиент подключает к ней максимум прикладных систем, обеспечивающих бизнес. Коннекторы к таким системам разрабатываются индивидуально. Таким образом, даже если будут успешно решены все технологические проблемы разработки коннекторов и их интеграции в сервис, эффект использования SaaS значительно снижается – вы все равно получаете кастомизированный продукт, частично управляемый вами, частично внешним поставщиком услуги.

Но облачный IAM несет в себе не только риски и неразрешенные проблемы. Небольшой организации сложно сосредоточить внутри себя достаточный уровень компетенций для построения зрелой и развернутой IAM-системы, а обращение к интеграторам может оказаться ей не по карману. Маленькие компании, выбрав путь сокращения затрат, склонны принимать более высокие риски и могут стать благодатной почвой для развития IDaaS. Обратившись к провайдеру подобной услуги, компания может получить качественный сервис ровно в том объеме, который необходим ей для обеспечения потребностей бизнеса в конкретный момент.

Но пользователями сервиса может стать не только малый и средний бизнес. Крупным компаниям подчас тоже приходится решать непростые задачи, и подобный сервис мог бы стать для них выходом. Представим себе крупную компанию, часть инфраструктуры которой является собственной, другая часть находится в облаке. Компании необходимо управлять идентификационными данными собственных сотрудников, которые могут и пользоваться облачными ресурсами, и получать доступ к ресурсам внутри корпоративной сети. Информация о сотрудниках, их группах и ролях хранится в домене. Кроме сотрудников есть еще внешние пользователи, скажем, клиенты компании, нуждающиеся в доступе к ряду облачных сервисов и идентификационной информацией которых тоже требуется управлять, но компания не хочет хранить информацию о них в домене. Неплохим решением здесь может стать комбинирование возможностей IAM, развернутой на инфраструктуре компании, и IDaaS, при котором управляемые данные разделены между двумя системами и сервисы каждой из систем имеют разные степени интеграции с инфраструктурой.

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

Итак, учитывая все выше изложенное, мы можем описать типовой портрет пользователя облачного IAM:

  • клиент должен иметь простой процесс управления жизненным циклом учетной записи пользователей либо возможность упростить его и унифицировать, подстраивая под возможности IDaaS;
  • чем меньше клиент привязан к унаследованным приложениям и приложениям в собственной инфраструктуре, тем лучше;
  • клиент должен быть морально готов к хранению данных в облаке;
  • фокус клиента при развитии инфраструктуры должен быть направлен в первую очередь на удобство конечных пользователей, а не на жесткое следование традиционным принципам и подходам в управлении ИТ и информационной безопасностью;
  • клиент должен быть готов принять риски использования новой технологии для своих бизнес-потребностей, понимая, что он будет первопроходцем в данной области, и трезво взвешивая выгоды, полученные от использования новых технологий.

Пока таких клиентов не очень много, но интерес к данной теме растет. И если вы думаете о том, чтобы вступить на этот путь, то вовсе не обязательно бросаться в омут головой. Возможно, стоит подумать о развитии в своей инфраструктуре гибридного решения, которое сможет объединить достоинства традиционного IAM и удобства отдельных облачных сервисов, например облачный SSO. Примером здесь может служить разработчик технологии identity bridge Centrify, представляющей собой коннектор к Active Directory, а также различные варианты хранения учетных данных: полностью в облаке, полностью в инфраструктуре или гибридный.

Весьма интересна для развития гибридных решений возможность усиления безопасности с помощью технологий двухфакторной аутентификации. Традиционно такая технология предполагала необходимость использовать токен или смарт-карту, где размещается ключевая информация. Однако это довольно неудобно и не всегда возможно, если вы используете мобильные устройства. Выход из подобной ситуации предлагает российский разработчик средств аутентификации Indeed ID со своей технологией AirKey, которая позволяет пользователям превратить в смарт-карту свое мобильное устройство. Такое мобильное устройство может использоваться как традиционная смарт-карта (будучи подключенным к компьютеру), смарт-карта в режиме «тонкого клиента» или генерировать одноразовые пароли. Работа AirKey строится на соответствии стандартным протоколам, интерфейсам и механизмам PKI-инфраструктуры. При этом закрытые ключи никогда не покидают память мобильного устройства и все криптографические операции выполняются внутри него. Виртуальная смарт-карта поддерживает все сценарии использования, которые можно реализовать с помощью классической смарт-карты или токена.

Применение такой технологии позволяет существенно усилить аутентификацию мобильных пользователей, организовать защищенное соединение между мобильным устройством и сервисом, цифровую подпись юридически значимых документов и операций.

Производители традиционных IAM тоже все чаще заявляют о поддержке мобильных устройств и облачных сервисов для обеспечения бесшовной аутентификации. Мир неумолимо движется в этом направлении. И прорывом здесь может стать предложенная производителями IDaaS стратегия миграции с традиционных IAM-решений на облачную платформу. Пока стратегии полной миграции, если они и есть, не получили широкого распространения. Большинство производителей продвигают стратегии гибридных IAM-систем, которые сейчас лучше воспринимаются рынком. Однако уже завтра все может поменяться.

Поделиться:
Спецпроект

Напряженный трафик или Современные требования к инфраструктуре ЦОД

Подробнее
Спецпроект

Специальный проект "Групповой спутниковый канал для территориально-распределенной сети связи"

Подробнее

Подпишитесь
на нашу рассылку