Подготовка удостоверений "облачных" служб с применением SCIM

.

Немного об IAM

Прежде чем перейти к описанию проблемы, для решения которой создается SCIM, полезно ознакомиться с некоторой общей информацией. В целом в управлении удостоверениями и доступом (IAM) — независимо от того, основано ли оно на локальных или «облачных» ресурсах, — можно выделить четыре категории, иногда называемые «четыре A».

Аутентификация. Первая категория — аутентификация (часто сокращаемая до AuthN), представляющая собой проверку подлинности удостоверяющего утверждения (например, «Я — Шон Дьюби») через доверенный центр авторизации (Active Directory в Penton Media). Аутентификация, безусловно, наиболее развитая из четырех категорий; здесь уже созданы разнообразные стандарты и технологии, хотя «облачная» версия пока далека от полной зрелости.

Авторизация. Вторая категория — авторизация (AuthZ, также именуемая «управление доступом»), то есть процесс предоставления удостоверению доступа к определенным ресурсам через доверенный центр авторизации. Например, администраторами AD в Penton Media мне предоставляется доступ к конкретным совместно используемым сетевым ресурсам на файловом сервере Fort Collins. В мире «облачных» удостоверений авторизация пока неразвита и форма ее реализации у разных «облачных» поставщиков различна, хотя все чаще применяются стандарты, такие как eXtensible Access Control Markup Language (XACML).

Аудит. Третья категория — аудит, который в рамках данной статьи я определю как регистрацию и контроль деятельности, относящейся к IAM. По крайней мере, в сфере «облачных» служб аудит — также относительно неразвитая категория. Организация, занимающаяся вопросами «облачной» безопасности, Cloud Security Alliance (cloudsecurityalliance.org), реализует проект CloudAudit, задачей которого является обеспечение общего интерфейса и пространства имен, что позволит поставщикам «облачных» служб автоматизировать аудит, утверждения, оценку и контроль для сред инфраструктуры (IaaS), платформы (PaaS) и приложений (SaaS) и даст возможность авторизованным пользователям их служб действовать одинаково с применением открытого, расширяемого и защищенного интерфейса и методологии.

Аккаунт. Последняя из четырех категорий, относящихся к «облачным» удостоверениям, — учетные записи. Неотъемлемой частью деятельности любой системы IAM является взаимодействие с учетными записями и группами пользователей. Для обозначения жизненного цикла работы с такими группами часто используется аббревиатура CRUD: create (создание, подготовка), read (чтение), update (обновление) и de-provisioning (удаление или деинициализация). Эта категория, относящаяся к удостоверениям, развита лучше, чем аудит и авторизация, но также имеет свою долю растущих проблем.

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

Значительно меньше поставщиков служб выходят за рамки этих простых методов, предлагая для подготовки учетных записей специальные API или коннекторы (которые нельзя применять повторно для других поставщиков служб) либо поддерживая синхронизацию каталогов (дублирование содержимого контейнеров AD — например, организационных единиц (OU) — и своевременное обновление этих данных у поставщика службы). Очень немногие поставщики поддерживают стандарты IAM, такие как Security Assertion Markup Language (SAML), для подготовки учетных записей по принципу «строго в нужное время». Существует специальный стандарт подготовки, называемый Service Provisioning Markup Language (SPML), который, однако, не был принят в отрасли.

Почему не был принят стандарт SPML

По-видимому, одной из причин отказа от SPML является то, что этот стандарт создавался как полное решение, охватывающее все возможные ситуации и поэтому получившееся слишком «тяжеловесным» в реализации для большинства поставщиков служб. По мнению Патрика Хардинга из Ping Identity, эта причина аналогична той, по которой мы используем протокол Lightweight Directory Access Protocol (LDAP) вместо DAP для доступа к каталогам. Вы когда-нибудь слышали о DAP? Задавались ли вы вопросом, зачем в названии протокола доступа к каталогам понадобилось употребить слово «облегченный», если бы ранее не существовало «тяжелого» варианта?

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

Миру «облачных» вычислений необходим стандарт подготовки пользователей, который каждый сможет применять для успешного осуществления своей основной деятельности, связанной с предоставлением или использованием услуг. Специалисту по удостоверениям следует помнить, что управление удостоверениями — не конечная цель, а лишь средство ее достижения. Стандарт должен быть как можно проще, «прозрачнее» в реализации и безопаснее. Именно эту задачу должен решить SCIM.

Лучшее определение для SCIM приводится на странице simplecloud.info: «Спецификация SCIM призвана упростить управление удостоверениями пользователей для «облачных» приложений и служб. Данная спецификация строится на основе опыта, с применением существующих схем и вариантов развертывания и с особой ориентацией на простоту разработки и интеграции при применении действующих моделей аутентификации, авторизации и защиты конфиденциальности».

Прежде чем перейти к более подробному описанию SCIM, хочу пояснить, почему было выбрано именно такое название. Поскольку речь идет о подготовке к работе, к SCIM больше подходит определение «управление пользователями», а не «управление удостоверениями», но в таком случае получилась бы аббревиатура SCUM — «отбросы». С другой стороны, если в название включить «управление доступом» или «управление атрибутами», то получится SCAM — «мошенничество». Поэтому создатели стандарта остановились на менее точном, но более благозвучном «управлении удостоверениями».

Подробнее о SCIM

Исходя из уроков SPML можно сказать, что буква S в сокращении SCIM имеет большое значение: стандарт должен быть простым. SCIM не предназначен для охвата всех возможных ситуаций подготовки, но лишь для наиболее распространенных случаев, что значительно упрощает его по сравнению с SPML. Стандарт применим к обработке создания, обновления и удаления учетных записей пользователей и групп; поиску; XML- и JSON-представлениям, а также к привязке SAML для подготовки по принципу «строго в нужное время».

SCIM реализует общую пользовательскую схему, поэтому пары ‘имя-значение’ (например, имя, фамилия, адрес электронной почты) означают одно и то же, независимо от поставщика SaaS, для которого осуществляется подготовка учетной записи пользователей, и эта схема при необходимости может быть расширена в соответствии с определенными требованиями поставщика удостоверений или поставщика службы. SCIM использует API RESTful, что облегчает интеграцию с «облачными» службами. Стандарт SCIM разрабатывается с ориентацией на быстроту реализации. На последнем семинаре Internet Identity Workshop (IIW) в октябре (iiw.idcommons.net/SCIM_(Simple_Cloud_Identity_Management)_(3H)) разработчики осуществляли реализацию SCIM-совместимых коннекторов для поставщиков служб в пределах одного рабочего дня.

В отличие от SPML, данная спецификация разрабатывается в самой отрасли на основе практического опыта. Salesforce.com, Cisco, Google, Ping Identity, Technology Nexus и UnboundID, среди прочих, полагают успешное развитие этого стандарта одной из своих приоритетных задач и активно вносят последние штрихи для окончательной доработки версии 1.0.

Как мы видим, SCIM и SPML представляют собой очередной пример правила 80/20: поддержка 80% имеющихся случаев подготовки учетных записей пользователей позволит упростить спецификацию, поскольку дополнительная сложность возникнет лишь в оставшихся 20% случаев. При необходимости реализации возможностей, попадающих в эти 20% и недостижимых путем расширения схемы SCIM, вероятно, потребуется прибегнуть к особому решению.

Другая движущая сила развития SCIM — необходимость ускорения. Всем известно, что в использовании «облачных» служб, особенно приложений SaaS, наблюдается взрывное развитие. Каждый день в отсутствие стандарта подготовки учетных записей пользователей поставщики «облачных» служб вынуждены изобретать собственные способы предоставления поставщикам удостоверений доступа к своим службам, которые впоследствии придется подгонять под стандарт.

Состояние SCIM

SCIM развивается быстро. На семинаре IIW в октябре многие поставщики тестировали свои службы на оперативную совместимость с SCIM. В частности, разработчиками Salesforce.com прямо на семинаре была с нуля создана функциональная конечная точка с реализацией SCIM. Предполагается, что в декабре 2011 года рабочая группа SCIM объявит о готовности версии 1.0, и, по мнению Хардинга (одного из основных инициаторов SCIM), в 2012 году Google Apps, Cisco Webex и Salesforce.com будут иметь конечные точки SCIM в рабочем состоянии.

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

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