Федеративные удостоверения для безопасной работы в "облаке"

.

Зачем нужны федеративные удостоверения?

Чтобы понять растущее значение федеративных удостоверений, следует обратить внимание на проблемы, с которыми сталкиваются ИТ-администраторы и разработчики при использовании традиционной проверки подлинности в современной ИТ-среде, в частности протокола Kerberos. Назначение поставщика удостоверений, такого как Active Directory (AD), — свести воедино идентификационную информацию об используемых ресурсах. От внимания ИТ-специалистов, ответственных за учетные данные, часто ускользает, что цель проверки подлинности — в определении и проверке личности пользователя для предоставления доступа к ресурсам.

Протокол безопасности Kerberos (и построенные на его основе домены и леса AD) рассчитан на сравнительно безопасную среду, такую как корпоративная внутренняя сеть. Протокол Kerberos, в реализации для AD, предоставляет два компонента: подтверждение удостоверения и членства в группе безопасности. Если для ресурса (например, пространства имен DFS) требуется дополнительная информация, в частности о сайте, то эти сведения необходимо извлечь из другого места — собственно хранилища AD.

Однако в реальной жизни сценарии, не требующие модификации AD для сохранения дополнительной информации, относительно упрощенные. Например, для Microsoft Exchange Server требуется больше информации о пользователе, чем предоставляет базовая схема AD. Поэтому администраторы AD должны расширить схему, позволив Exchange сохранять дополнительные идентифицирующие пользователей данные. Расширения схемы не совершаются импровизированно; требуется время, чтобы подготовить и спланировать их реализацию. В результате другие приложения могут сохранять информацию для удостоверений в таких базах данных, как SQL Server или Active Directory Lightweight Directory Services (AD LDS). В этом случае не требуется такой солидной подготовки, как при изменениях схемы.

Как быть, если пользователи и ресурсы относятся к двум различным предприятиям (например, организован совместный бизнес или используется программное обеспечение в виде службы из «облака»)? Создавать удостоверения внешних пользователей, или управлять ими путем формирования теневых учетных записей в AD, или построить для них отдельную базу данных учетных записей? Как своевременно и аккуратно предоставлять и отзывать такие учетные записи? Как надежно защитить учетные данные от взломщиков?

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

Что такое федеративные удостоверения

Модель федеративных удостоверений пригодна для самых разных сценариев. Федеративное удостоверение обеспечивает перенос данных между доменами безопасности с использованием утверждений и проверочных утверждений от поставщика удостоверений с цифровой подписью. Рассмотрим это определение по частям. Как отмечалось в предыдущем разделе, хранилище удостоверений каждого предприятия можно описать как домен безопасности, независимо от использования AD или иной службы каталогов. В данной статье в качестве поставщика удостоверений внутри предприятия используется AD. Если требуется охватить несколько предприятий, поставщиком удостоверений является все предприятие, предоставляющее информацию для удостоверений (не только AD). А утверждения и подтверждения — важнейший элемент проверки подлинности на основе запросов.

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

В основе модели проверки подлинности на основе утверждений лежит несколько простых, интуитивно понятных принципов, но процесс проверки подлинности может быть довольно извилистым. Сравним основы этой модели с широко известным протоколом Kerberos.

В AD каждый прошедший проверку подлинности пользователь имеет один или несколько билетов Kerberos, содержащих информацию об удостоверениях. Основной элемент структуры проверки подлинности на основе утверждений — маркер, форматированный на языке SAML. На рисунке 1 показан маркер SAML, во многих отношениях схожий с билетом Kerberos. Билет Kerberos содержит полезные данные, именуемые маркером доступа: он указывает группы безопасности, членом которых является пользователь. Ресурс (например, сервер файлов) доверяет этому свидетельству, так как принадлежность билета надежному источнику удостоверений подтверждена шифрованием. В AD источником является центр распространения ключей (KDC) Kerberos контроллера домена (DC), с которым связывается сервер файлов.

Рисунок 1. Маркер SAML

Маркер SAML называется проверочным утверждением (assertion). Полезные данные этого проверочного утверждения содержат потенциально более широкий набор информации об удостоверении, именуемый утверждением, нежели билет Kerberos. Маркер SAML более гибок в этом отношении. Назначение утверждений определяет администратор: это может быть имя, адрес электронной почты, номер телефона, возраст, уровень привилегий, кулинарные пристрастия и т. д.

В AD назначены временные ограничения для использования билета Kerberos. Таким образом предотвращаются атаки, в ходе которых взломщик записывает учетные данные и воспроизводит их для получения доступа. Проверочное утверждение SAML также содержит условия, накладывающие более строгие ограничения на область допустимости подтверждений, чем в протоколе Kerberos. Можно указать рамки для времени утверждения; круга лиц, имеющих право использовать подтверждение; сколько раз можно его применять; можно ли делегировать проверочное утверждение. Таким образом, проверочное утверждение может быть нацелено на конкретное использование, и только на него, чтобы повысить надежность процесса проверки подлинности.

Наконец, билет Kerberos AD шифруется с применением серверного ключа назначения билетов (для билета предоставления билетов — TGT) или пользовательского ключа (для сеансового билета). Проверочное утверждение SAML подписано и может иметь различные степени шифрования от создавшего его поставщика удостоверений, от отдельных компонентов до всего подтверждения. Подпись гарантирует, что проверочное утверждение действительно исходит от указанного поставщика удостоверений, а благодаря шифрованию можно быть уверенным, что проверочное утверждение не изменено и не стало объектом шпионажа.

Однако, несмотря на все эти сходства, есть очень важное отличие: область действия билета Kerberos AD в основном внутри предприятия, а маркер SAML не имеет такого рода ограничений. Это означает, что приложение, настроенное для работы с утверждениями, одинаково успешно проверяет подлинность пользователей как внутри, так и за пределами корпоративного брандмауэра.

Этот маркер не возникает «из воздуха». Он должен быть создан, и AD ничего не известно об этом процессе. Представляем еще одного участника обработки утверждений: службу Security Token Service (STS). Она выдает маркеры в ответ на запросы от пользователей. На рисунке 2 показано, как STS взаимодействует с пользователем и AD, чтобы сформировать маркер, который можно предоставить приложениям, распознающим утверждения. Обратите внимание, что на рисунке 2 показан браузер пользователя. Дело в том, что браузер активно вовлечен в процесс, если в операционной системе пользователя нет клиента для передачи маркера.

Рисунок 2. Процесс создания маркера STS

Как действуют федеративные удостоверения: два сценария

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

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

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

Рисунок 3. Внутренний пользователь обращается к внутреннему приложению

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

Приложение запускает или инициирует вызов веб-службы (если клиент активен и распознает вызов) или перенаправление протокола HTTP через браузер (для пассивного клиента, не имеющего возможности обработать запрос), чтобы запросить маркер от службы STS.

Служба STS отвечает на запрос, передавая маркер приложению. Приложение может продолжать (например, передать данные пользователю или разрешить доступ к приложению).

Для такого сценария нужна лишь служба федерации, такая как Active Directory Federation Services (AD FS) 2.0, IBM Tivoli Federated Identity Manager или PingFederate компании Ping Identity, и приложение, пригодное для работы с утверждениями, такое как Microsoft SharePoint 2010.

Во втором сценарии (рисунок 4) пользователь находится внутри предприятия и нуждается в доступе к внешнему поставщику веб-службы. У этого сценария два основных применения. Первый — доступ к поставщику SaaS, в котором предприятие использует такую службу, как Salesforce, Google Apps или хост-поставщика электронной почты, не назначая отдельных паролей каждому поставщику. Второй — взаимодействие между компаниями (B2B), при котором пользователям внутри предприятия поставщика удостоверений необходимо без помех сотрудничать с пользователями внутри другого предприятия, у которых есть общие документы. В этом случае приложением, распознающим утверждения, может быть SharePoint, и пользователи обоих предприятий могут публиковать документы и работать с ними. Такой сценарий известен как однократная регистрация, single sign-on (SSO), через Интернет. Обратите внимание, что в этом сценарии пользователь не предпринимает никаких активных действий и ни одному приложению на локальном компьютере не известно о веб-службе; браузер пользователя просто перенаправляет весь трафик через него. Такой клиент называется пассивным.

Рисунок 4. Внутренний пользователь обращается к внешнему приложению

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

При использовании пассивного клиента и добавлении службы STS поставщика служб процесс удлиняется на несколько шагов. Клиент не принимает активного участия в процессе проверки подлинности, вместо этого служба приложения перенаправляет запрос через браузер клиента в службу STS поставщика служб для обнаружения нужных утверждений (шаг 3). Затем служба STS поставщика служб отправляет запрос маркера в службу STS поставщика удостоверений (шаг 4). После того как служба STS поставщика удостоверений формирует маркер SAML, маркер перенаправляется через браузер пользователя (ни пользователю, ни браузеру ничего о происходящем не известно) в службу STS поставщика служб. Эта служба STS проверяет маркер, формирует маркер с собственной подписью (единственной, которой доверяет приложение) и представляет его службе приложения (шаг 7). Затем процесс завершается, как и предполагалось, а пользователь перенаправляется к приложению и может работать с ним.

Обратите внимание, что поставщику служб не обязательно иметь собственную службу STS; приложение может напрямую доверять поставщику удостоверений. Однако такая ситуация более распространена в случае взаимодействия B2B, когда проблем с масштабированием не возникает.

Федерация также работает, если пользователь во втором сценарии находится вне предприятия (например, работает дома на компьютере, не подключенном к VPN). Пользователь находится вне домена Kerberos, поэтому служба STS выдает страницы проверки подлинности на основе формы, в которую пользователь вводит учетные данные. После того как подлинность пользователя подтверждена, процедура проверки на основе утверждений продолжается.

Как используется федеративное удостоверение

Теперь, после знакомства с некоторыми механизмами федерации, может возникнуть вопрос, взял ли кто-нибудь на себя хлопоты по внедрению метода. Поначалу внедрение технологии федерации шло медленно, так как немногие компании видели экономические выгоды от ее применения для внутренних приложений и редкого внешнего взаимодействия. Необходимый импульс федерации придали «облачные» вычисления, увеличение числа приложений, распознающих утверждения, и быстрый рост количества поставщиков SaaS. Каждый из нас уже использует федерацию, мы просто не знаем об этом. В сущности, в том и состоит цель федерации: если она функционирует успешно, пользователи не должны замечать ее. Федеративные удостоверения в потребительской сфере уже применяются всеми веб-службами, для которых требуется Windows Live ID (в том числе TechNet, MSDN, Windows Live Messenger) или любые другие свойства Windows Live.

Многие компании внедряют федерацию, чтобы идти в ногу с потребностями пользователей, желающих применять службы SaaS без риска и сохраняя возможности масштабирования. Если установить федеративное доверие с поставщиком, пользователи смогут регистрироваться в службе с применением собственных идентификаторов пользователя и паролей — им не придется создавать отдельные учетные записи и управлять ими; это будет сделано автоматически. Группе управления учетными записями на предприятии более не нужно беспокоиться об управлении дублированными учетными записями для нескольких поставщиков SaaS, особенно о важной для безопасности задаче отмены учетных записей, активность которых недопустима. А после того как подготовлена федеративная среда с собственной службой STS, не составит труда добавлять новые доверительные отношения по мере появления новых поставщиков служб и приложений.

Кто является ведущим поставщиком программ федерации и однократной регистрации через Интернет? Таких компаний несколько, и, несомненно, одна из них Microsoft. AD FS 2.0 — бесплатно загружаемый продукт для Windows Server 2008 R2 и Server 2008. Он полезен, но внедрить его — непростая задача; для начала нужно изучить документацию TechNet и воспользоваться поэтапными инструкциями в тестовой лаборатории. Помимо AD FS, основные корпоративные продукты для однократной регистрации через Интернет — Oracle Identity Federation, CA Federation Manager и PingFederate компании Ping Identity.

Существует еще один класс программ федерации, устраняющих необходимость локальной установки STS. С помощью таких продуктов, как PingConnect, Symplified и Okta компании Ping Identity, сама федерация превращается в «облачную» службу. Компании размещают программы федерации на своих серверах и управляют доверительными отношениями с многочисленными поставщиками SaaS, в результате подписчики служб автоматически получают безопасный доступ к поставщикам.

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

Рост рынка внутренних программ, распознающих утверждения (в ходе которого обновляются традиционные приложения и создаются новые), напоминает проблему «курицы и яйца». Поставщики программного обеспечения не хотят инвестировать в программы для работы с утверждениями, пока не появится спрос на такие продукты. Но спрос не появится, пока в их распоряжении потребителей не будет приложений со службой федерации и они не смогут задействовать такую форму проверки подлинности без крупных дополнительных затрат. В этом случае начнется широкое внедрение рассмотренного в данной статье сценария SaaS; компании, применяющие федерацию для работы с поставщиками SaaS, готовы к внутреннему использованию программ, распознающих утверждения. Чтобы ускорить процесс, требуйте от поставщиков SaaS федеративных возможностей. Благодаря им снижаются риски, улучшается ваша видимость в «облаке», поставщик освобождается от обязанности обслуживать хранилище удостоверений, а компании могут работать с программами, распознающими утверждения.

Следующий шаг к федеративным удостоверениям

Лучший способ изучить федеративные удостоверения — начать экспериментировать с ними. Организуйте в лаборатории федеративную службу. Я расскажу о своем опыте установки AD FS 2.0 в лаборатории в одной из следующих статей. Запланируйте проект, чтобы внедрить в компании федеративную службу. В первую очередь заручитесь поддержкой группы по информационной безопасности; если администраторы безопасности пока не осознали риска, связанного с отдельными учетными записями для каждого поставщика SaaS, следует развеять их заблуждения. Благодаря федеративной службе снижается риск, которому подвергается компания, так как уменьшается число дублированных учетных записей для поставщиков SaaS, сокращаются накладные расходы ИТ-подразделения на управление дублированными учетными записями и упрощается задача пользователей, которым требуется запоминать меньше паролей. Если вам не хочется самостоятельно развертывать федеративную службу, обратитесь к таким продуктам, как PingConnect, Symplified и Okta, чтобы получить федерацию как службу.

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

Шон Дьюби (sdeuby@windowsitpro.com) — старший аналитик в компании Platform Vision с 25-летним стажем работы в области корпоративных информационных систем. Внештатный редактор Windows IT Pro, имеет звание MVP