Windows Azure: Используйте ADFS для аутентификации в Windows Azure

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

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

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

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

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

На 2013 RSA Conference менеджер проекта по доступу с портативных устройств из United States National Security Agency утверждал, что даже самые критичные к безопасности среды должны обеспечивать целостную поддержку «блуждающих» пользователей. ИТ-отделы обязаны предоставлять сервисы и устройства, поддерживающие различные механизмы аутентификации пользователей.

Для типичного веб-приложения, выполняемого в облачной среде Windows Azure и автоматизирующего определенный вид деятельности (line-of-business, LOB), можно адаптировать существующее решение по управлению идентификациями, такое как Microsoft Active Directory Federation Services (AD FS). Можно также без усилий применить общую схему описанного в статье решения к другим решениям по управлению идентификациями, приложениям и облачным сервисам.

Существующие методы аутентификации

Directory Services всегда была традиционным репозитарием корпоративных пользовательских идентификаций в инфраструктуре Windows. Она предназначена для предоставления сотрудникам доступа к сетевым ресурсам, находящимся за брандмауэром, причем основным протоколом является Kerberos.

Поскольку Kerberos не рекомендуется использовать в Интернете, большинство организаций применяет протоколы аутентификации для Интернета, такие как Security Assertion Markup Language (SAML), Simple Web Token (SWT) и JSON Web Token (JWT). Эти новые веб-маркеры (Web tokens) еще не поддерживаются большинством корпоративных служб каталогов, поэтому для соединения традиционных каталогов с новейшими веб-приложениями нужна дополнительная служба — Security Token Server (сервер маркеров безопасности, STS).

Важно разделить роли. Ни один сервер бизнес-приложений не должен осуществлять аутентификацию пользователей. Серверу приложений нужна возможность положиться на какой-то другой сервис, который выполнит всю тяжелую работу по предоставлению информации для аутентификации и авторизации, обеспечив достаточную гибкость. Это есть и то, что обычно называют «федеративной идентификационной информацией (federated identity).

Федерация означает, что сервер приложений (доверяющая сторона, relying party, RP) устанавливает доверительное отношение с провайдером идентификаций. Он должен знать, как оценивать метаданные пользовательских идентификаций, предоставляемые в виде утверждений (claims).

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

Рис. 1. Когда пользователь запрашивает защищенный контент, инициируется ряд перекрестных проверок

AD FS и Windows Azure на практике

Один из вариантов — использовать AD FS в качестве STS. AD FS защищает внутреннюю Active Directory Domain Services (AD DS) от внешних атак, когда принимает запросы аутентификации из Интернета. AD FS преобразовывает идентификации Active Directory в формат, подходящий для доступа из Интернета.

Внешним устройством в данном случае является планшет под управлением Windows. Устройство взаимодействует через внешнее сетевое соединение с веб-сервером приложений (RP), расположенным в облаке Windows Azure. Сервер приложений должен знать, использует ли пользователь, проходящий аутентификацию в AD FS, компьютер, совместимый с сетевыми политиками.

Как несколько лет назад сказал эксперт по безопасности Батлер Лэмпсон (Butler Lampson), «все доверие локально». Другими словами RP нужна возможность выполнять свою собственную проверку утверждений перед предоставлением доступа к контенту приложений. Эта проверка и авторизация основаны на утверждениях относительно идентификации пользователей и совместимости устройств, выпускаемых STS. Поэтому устройство осуществляет обмен данными о полномочиях (рис. 2).

Рис. 2. Чтобы проверить, разрешить ли доступ к данным, требуется запросить несколько утверждений

Агент на устройстве собирает утверждения из различных источников и объединяет их в ответ для сервера приложений. Этот ответ должен соответствовать всем критериям, определенным для предоставления доступа к данным. Утверждения об идентификации пользователей и о совместимости устройств могут поступать от различных STS (как показано на рис. 2) или от одного STS, получающего метаданные из различных источников (например, Active Directory и Microsoft System Center Configuration Manager).

Чтобы выполнить требования веб-сервиса, выступающего в роли RP, можно изменить сочетание провайдеров идентификаций и атрибутов. Например, можно сочетать аутентификацию Office 365 с измерениями клиентских устройств, чтобы проверять соответствие политикам защиты от потери данных. Во всех случаях запрос RP поступит пользовательскому агенту на устройство пользователя. В результате из нескольких источников поступят утверждения, соответствующие запрос RP.

Во многих сценариях аутентификации через Интернет пользовательское устройство вправе кэшировать утверждения для дальнейшего использования. Их часто называют сценариями «Сохраните мой вход» (Keep Me Signed In). RP даже имеет возможность запрашивать у пользователя дополнительные утверждения, когда это нужно для выполнения транзакций, запрашиваемых пользователем. Это называют поэтапной (step up) авторизацией.

AD FS и поддержка идентификаций

Для бизнес-приложений, основанных на Windows, поддержка федераций встроена в Microsoft .NET Framework 4.5. Разработчикам больше не нужно становиться экспертами по безопасности, чтобы реализовать описанные в статье сценарии.

Хотя в .NET Framework 4.5 не входит поддержка SWT and JWT, добавление этих структур хорошо документировано. Microsoft выпустила JWT-обработчик для .NET Framework 4.5. AD FS 2.1 входит в Windows Server 2012 как интегрированная серверная роль, которая теперь поддерживает пулы приложений .NET Framework 4. Она вам понадобится для поддержки JWT-обработчика и других продвинутых функций.

Управление доступом на основе утверждений удобно, когда осуществляется взаимодействие с партнерами, находящимися за пределами предприятия, поскольку отделяет аутентификацию (например, в Active Directory на стороне предприятия) от авторизации (например, в совместно используемом облачном сервисе доступа к данным). Утверждения упрощают администрирование управления доступом, основанное на ролях, поскольку AD FS и другие провайдеры идентификаций могут генерировать утверждения, поддерживаемые различными проверками полномочий в RP.

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

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