Разработка приложений под Windows Azure. Безопасность в облаке. Access Control Service.

Добрый день. Мы продолжаем знакомиться с платформой  Windows Azure и темой моего сегодняшнего поста будет безопасность облачных приложений.
Итак, принимая решение о разворачивании приложения в облаке, мы естественным образом задумываемся  о том, будут ли наши данные защищены от несанкционированного доступа. И это вполне обоснованные мысли, так как в случае использования облака все наши данные (иногда очень важные и конфиденциальные) будут храниться на удаленных серверах сторонней компании, а не на наших собственных. Когда мы говорим о безопасности приложений, то необходимо учитывать все возможные дыры в защите, через которые злоумышленник может получить доступ к конфиденциальным данным. Как правило полностью защищенные данные означают полную защиту на всех уровнях безопасности,среди которых следует отметить
следующие:

 

Прежде всего необходимо задуматься о физической безопасности, а именно защитить данные от физической кражи. Кроме того, необходимо иметь последнюю операционную систему с новейшими обновлениями, что поможет предотвратить множество низкоуровневых атак. Как правило большинство данных хранится в реляционных базах данных, поэтому вопросы обеспечения безопасного хранения таких данных также являются чрезвычайно важными. Очень  важна сетевая безопасность, что подразумевает наличие хорошего файерволла и защищенной сетевой инфраструктуры. В конце концов необходимо продумать безопасность собственных бизнес-процессов в нашем приложении.
Что касается Windows Azure, то на первых 3-х уровнях мы получаем полную гарантию безопасности наших данных. Физически доступ к датацентру может получить лишь строго ограниченный список людей, в основном это обслуживающий персонал. Поговаривают даже, что вокруг каждого датацентра можно наблюдать больше людей с автоматами чем с ноутбуками (лично я не проверял, поэтому не могу сказать насколько правдивой может быть данная информация :) ). Высокая безопасность на 2-м уровне гарантируется благодаря тому, что каждое приложение работает в рамках своей виртуальной машины, тем самым ограничивается доступ к реальным физическим ресурсам и другим виртуальным машинам. Кроме того каждый процесс работает под определенным Windows-аккаунтом. В конце концов операционная система постоянно обновляется до последних версий, тем самым гарантируя высокую защищенность и актуальность системы защиты. В целом можно с уверенностью сказать, что мы получим гораздо более высокую степень защиты в облаке, чем если бы мы использовали свои собственные сервера. Как Вы понимаете в задачи разработчика входит реализация безопасности на последнем уровне. Здесь мы должны позаботиться о следующих аспектах:

• Валидация входящих данных
  
• Аутентификация / авторизация
  
• Управление сеансами
  
• Управление конфигурацией
  
• Криптография
  
• Аудит и логирование
  
• Обработка исключений

Как мы все прекрасно понимаем, все перечисленные пункты играют очень важную роль и заслуживают отдельного разговора. Я хотел бы остановится на сценариях аутентификации и авторизации. В этом контексте одним из основных понятий есть понятие идентичности. В моем понимании идентичность – это набор артефактов, позволяющих с уверенностью ответить на вопрос : “Кто Вы есть на самом деле ?”.

На сегодняшний день существует 2 основных стратегии по работе с идентичностями:

• На основе ролей
  
• На основе утверждений

Всем нам широко известна стратегия на основе ролей, которая предполагает, что каждая из идентичностей может принадлежать одной или более ролям. Каждой роли в свою очередь присваивается определенный набор прав и возможностей. Это довольно таки  распространенный подход, применяемый в большинстве современных web-приложений. Следует отметить что Windows Azure предлагает нам 2  основных средства для организации механизма управления идентичностями на основе  ролей – это Domain Join и всем нам широко известный ASP.NET Membership провайдер. Не буду долго останавливаться на этой стратегии, так как большинство разработчиков тем или иным способом с ней уже сталкивались.
Более прогрессивной является стратегия на основе утверждений. Согласно основным принципам этого подхода все задачи по аутентификации, хранению пользовательских данных, получению данных пользователя и др. берет на себя сторонняя система (в терминах Claims Based Authentication такая система называется STS – Security Token Service). Для большего понимания давайте посмотрим на процесс получения доступа к закрытому в ресурсу в рамках аутентификации на основе утверждений.

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

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

Как видим одной из ключевых систем в Claims Based аутентфикации является STS и при помощи Windows Identity Foundation процесс создания такой системы значительно упрощен, но все равно занимает определенное время. К счастью в облаке присутствует полнофункциональная STS под названием Access Control Service, о которой я и хотел бы поговорить во 2-й части этой публикации.
Access Control Service.
Итак, как я уже говорил ACS – это STS в облаке. Из основных особенностей системы я хотел бы выделить следующие:

При помощи этой технологии мы можем подключать к своему приложению большое количество сторонних провайдеров (например, Google, Facebook и др.). Для этого нам достаточно настроить маппинг внешних утверждений, приходящих с одного из подключенных провайдеров, на утверждения, которые использует наше приложение. Фактически ACS – это просто великолепная интегрирующая инфраструктура, которая позволяет нашему приложению получать пользовательские данные из большого количества других провайдеров в очень удобной и простой манере.
В продолжении темы я хотел бы показать простейшее приложение, демонстрирующее особенности взаимодействия с Access Control Service. Так как технология сейчас находится в CTP версии, то получить доступ к ней мы можем при помощи портала AppFabric Labs. После перехода технологии в RTM версию мы увидим ее на регулярном портале. AppFabric Labs доступен по адресу https://portal.appfabriclabs.com. Первым делом необходимо создать новый неймспейс (служит удобным способом логической компоновки всех сервисов, предоставляемых Azure AppFabric)

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

Как видно по скриншоту есть  возможность “прицепить” множество готовых провайдеров. Кроме того существует возможность добавления своего собственного провайдера.
Следующим шагом будет настройка клиентского приложения. Для этого перейдем в секцию Relying Party и установим основные параметры приложения (такие как название, url приложения, поддерживаемые провайдеры). Частично экран добавления приложения представлен чуть ниже:

Как видим, здесь мы должны прописать url адрес приложения (в терминах Claims Based Authentication такое приложение/клиент называется Relying Party), чуть ниже мы указываем формат токенов (SAML 2,0 по умолчанию) и подключаемые к приложению провайдеры идентичностей (в нашем случае подключим Google). На последней стадии необходимо настроить маппинг утверждений Google в утверждения, используемые нашим приложением. Делается это в разделе  Rule Groups. Здесь для простоты нажмем Generate и в автоматическом режиме получим готовый маппинг:

На этом стадия настройки ACS завершена. Все что нам осталось сделать – это скопировать URL с метаданными STS. Найти этот адрес можно в разделе Application Integration.
Нашим клиентом будет обычное ASP.NET MVC 3 приложение с единственным контроллером и единственным экшеном, в теле которого будет следующий код:

public ActionResult Index()
{
if (User.Identity.IsAuthenticated)
{
ViewBag.Name = ((IClaimsIdentity)User.Identity).Claims.Where(entry => entry.ClaimType == ClaimTypes.Name).Select(entry => entry.Value).SingleOrDefault();
}
return View();
}

В теле самой вьюхи просто отображаем имя текущего пользователя:

@{
Layout = null;
}
Hello, @ViewBag.Name

Для того, чтобы подключить к приложению недавно созданную STS на базе Access Control Service нам необходимо кликнуть правой кнопкой на веб проекте и выбрать пункт меню “Add STS Reference” (примечание, данный пункт меню появляется после установки на машину Windows Identity Foundation). После чего перед нами откроется удобный визард:

На первом шаге указываем URL адрес нашего приложения. На следующем прописываем адрес метаданных STS (вставляем адрес, предварительно скопированный нами на портале)

После чего необходимо выбрать режим передачи данных без шифрования (для тестового приложения этого достаточно) и список импортируемых утверждений, которые автоматически подтянутся из метаданных. По окончании работы визарда в текущий Web.config будут добавлены необходимые настройки и при запуске приложения мы получим следующую картину:



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

Как видим процесс организации Claims Based Authentication довольно таки прост и благодаря таким технологиям как AppFabric Access Control Service и Windows Identity Foundation построение такой инфраструктуры не отнимет много времени.
На этом я хотел бы завершить публикацию. Надеюсь было интересно :). To be continued !