Как службы федерации решают проблемы идентификации и доступа к веб-приложениям в облаке IaaS

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

Некоторые компании неохотно выходят за пределы границ собственной инфраструктуры в силу, как они считают, сложности перехода на облачную площадку и неочевидности в вопросах безопасности. Но идентификация как сервис в облаке (Identity as a service, IDaaS) меняет правила игры для предприятий малого, среднего и крупного бизнеса в лучшую сторону. Если внимательно разобраться в озвученных вопросах, становится понятно, что облачные технологии все же отвечают требованиям безопасности и позволяют переносить в облако даже самую сложную инфраструктуру. Многое зависит от понимания концепции и умения пользоваться нужными инструментами. 

О классических проблемах идентификации и доступа

В то время, когда малый бизнес с легкостью использует облачный аутсорсинг, крупный бизнес к вопросу перехода в облако относится настороженно. Опасения связаны с организацией работы приложений и обеспечением должного уровня безопасности. На крупные компании возлагается особая ответственность, связанная с организацией защищенного доступа большого количества пользователей, использующих скоп приложений и получающих доступ с разрозненных удаленных площадок. При этом количество источников идентификации пользователей велико, популярными сегодня являются LDAP, AD, SQL и другие. Такая гетерогенность расширяет границы традиционных способов управления идентификацией и порождает сложности, приводящие к классическим проблемам контроля доступа.

Но есть и хорошая новость, заключающаяся в возможности организации безопасного и единого входа (SSO) через веб-приложения в облаке, что способствует быстрому принятию таких федеративных стандартов, как Security Assertion Markup Language (SAML), OAuth, OpenID Connect и прочее.

Как облаку IaaS помогают федеративные службы

Службы федерации решают ряд проблем, связанных с автоматизацией взаимодействия между предприятиями (B2B), играя особую роль для веб-приложений, «живущих» в облаке. Представьте ситуацию, когда компания, выпускающая запчасти для автомобилей, создает веб-приложение, позволяющее уполномоченным организациям-дилерам закупать товар по оптовым ценам. Это приложение размещается в облаке IaaS-провайдера и доступно 24 часа в сутки. Организаций-дилеров, обращающихся к облачному приложению, много, в каждой из них работают по два-три человека, использующих веб-портал для покупки товаров. Компания, продающая запчасти, хочет организовать безопасный доступ к веб-сервису, требуя идентифицировать конечных пользователей.

\

Рисунок 1. Классическая организация доступа к облачному веб-приложению

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

Рисунок 2. Принцип федеративных отношений

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

Вывод

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