Облака закрывают видимость

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

Облачные сервисы часто выступают в качестве альтернативы службам ИТ, которые отделы ИТ предоставляют локально («на месте»). Однако при этом надо оценить, выполняются ли необходимые требования к функциональности и соблюдаются ли прочие исходные условия. Ведь облака по сути являются «лишь очередной моделью развертывания (Deployment)», поэтому, как и любую другую службу ИТ, их следует оценивать с точки зрения обеспечения нужного качества сервиса. Весомое значение при оценке данного параметра имеет информационная безопасность, для которой, в свою очередь, чрезвычайно важно управление идентификацией и доступом (Identity and Access Management, IAM), то есть возможность регулировать права доступа пользователей к той или иной информации и службам.

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

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

Рисунок 1. Важнейшие технологии и стандарты для реализации IAM в облаках.

IAM в облаках — это тема, актуальная для всех облачных служб, а не только для услуг по предоставлению программного обеспечения в виде сервиса (Storage as a Service, SaaS). В платформах разработки (Development Platform) необходимо регулировать доступ для разработчиков и тестировщиков программного обеспечения, при предложении инфраструктуры в качестве сервиса (Infrastructure as a Service, IaaS), например EC2 от Amazon, нужно как минимум держать под контролем собственных администраторов и операторов и иметь возможность не только настраивать права доступа, но и целенаправленно их контролировать.

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

ИНТЕГРАЦИЯ: ПРОЩЕ В ОДНОРОДНЫХ СРЕДАХ

Эта задача без проблем решается в однородных средах. К примеру, компания Microsoft предлагает для своих сред, таких как пакет Office 365, уже довольно удачную привязку к существующим инфраструктурам Active Directory, что, впрочем, неудивительно, ведь и в Office 365, и в Azure используется Active Directory.

А вот когда речь заходит об интеграции с другими инфраструктурами, дела уже не столь хороши. Службы объединения Active Directory (Active Directory Federation Services, ADFS) версии 2 действительно обеспечивают поддержку стандартов интеграции, но до сих пор это документально зафиксировано только для соединений с инфраструктурами Microsoft. Правильным подходом к решению проблемы является внедрение таких стандартов, как LDAP, а также технологий объединения с использованием протокола разметки утверждений безопасности (Security Assertion Markup Language, SAML). И пока совсем не решены задачи аудита, причем вне зависимости от типа облачных сервисов, поскольку в этой области стандартов вообще не существует.

ИНТЕГРАЦИЯ С ИМЕЮЩИМИСЯ ИНФРАСТРУКТУРАМИ

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

Таким образом, система управления идентификацией и доступом должна быть интегрированной. Это обусловлено не только понятными желаниями пользователей, но и причинами правового характера: требования по обеспечению соответствия нормативным актам (Compliance) не заканчиваются за периметром предприятия (кстати, в большинстве случаев довольно дырявым). При решении вопросов о правах доступа пользователей и о правилах разделения полномочий (Segregation of Duties, SOD) никого не интересует, где реализуется сервис и какой именно. Правила SOD и обеспечения доступа обуславливаются бизнес-требованиями и нормами безопасности и должны распространяться на облачные решения.

АДМИНИСТРИРОВАНИЕ ПОЛЬЗОВАТЕЛЕЙ В ОБЛАКАХ

Такую интегрированную концепцию IAM можно реализовать путем распространения возможности инициализации (Provisioning) пользователей на облака, то есть интеграции внешних сервиспровайдеров в существующие решения, с помощью которых отдел ИТ регистрирует новых пользователей и отслеживает изменения в различных каталогах.

Все больше провайдеров решений инициализации работают над поддержкой облачных сервисов посредством специальных «коннекторов», однако основной акцент при этом делается на нескольких наиболее распространенных платформах, таких как Salesforce.com или Google Apps (см. Рисунок 2). Проблема в том, что до сих пор нет единого стандарта для управления пользователями в облаках. В результате при разработке коннекторов провайдеры инициализации вынуждены использовать проприетарные интерфейсы API различных поставщиков облачных услуг и поэтому фокусируются лишь на нескольких наиболее важных интерфейсах.

Рисунок 2. Для систем инициализации предлагается все больше специализированных коннекторов с облачными решениями.

Концепция простого управления идентификацией в облаках (Simple Cloud Identity Management, SCIM) призвана прийти на смену давно существующему, но малораспространенному языку разметки инициализации сервисов (Service Provisioning Markup Language, SPML). SMPL малопригоден для реализации требований, предъявляемых облаками, прежде всего из-за своих коммуникационных механизмов. Ожидается, что SCIM будет базироваться на технологии передачи репрезентативного состояния (Representational State Тransfer, REST) и сможет работать гораздо эффективнее. Пока сложно предугадать, удастся ли этой технологии закрепиться в качестве стандартного интерфейса для поставщиков облачных услуг. До тех пор предстоит обходиться коннекторами, предоставляемыми провайдерами инициализации, или разрабатывать их самостоятельно.

ФЕДЕРАТИВНАЯ ИДЕНТИФИКАЦИЯ: ЗНАЧИТЕЛЬНЫЙ КРАТКОСРОЧНЫЙ ПОТЕНЦИАЛ

В отличие от инициализации, когда провайдер облачных услуг самостоятельно создает пользователей и управляет ими, у концепции федеративной идентификации (Identity Federation) потенциал весомее. Все большее число облачных сервисов поддерживает протокол SAML (см. Рисунок 3). С его помощью можно управлять пользователями в собственной компании или в любой другой службе каталогов, если последняя подключена к решению для федеративной идентификации. Аутентификация выполняется так называемым провайдером идентичности (Identity Provider), а провайдер облачных сервисов доверяет такой аутентификации как достоверной и предоставляет пользователю доступ к соответствующим услугам.

Рисунок 3. Федеративная идентификация на базе SAML представляет собой подход, принцип действия которого аналогичен аутентификации Windows на базе Kerberos. Отличие одно — он действует во всех средах.

При необходимости дополнительное управление авторизацией может осуществляться с помощью атрибутов, передаваемых посредством сообщений SAML или последующих запросов. SAML обеспечивает большую гибкость. Однако это касается главным образом аутентификации, в то время как правила авторизации зачастую по-прежнему приходится устанавливать через нестандартные административные интерфейсы провайдеров облачных услуг. Такие стандарты, как расширяемый язык разметки контроля доступа (Extensible Access Control Markup Language, XACML) практически не поддерживаются, а ведь с их помощью можно было бы стандартизовать описание правил авторизации и предоставлять их различным провайдерам облачных сервисов.

СИЛЬНАЯ АУТЕНТИФИКАЦИЯ И ОДНОКРАТНАЯ РЕГИСТРАЦИЯ

Основной вопрос — как обеспечить, с одной стороны, относительно надежную, а с другой — удобную регистрацию пользователей. Для сильной аутентификации и однократной регистрации (Single Sign-on), уже предложено несколько интересных решений. Так, существуют облачные сервисы, поддерживающие сильную аутентификацию для других облачных сервисов, к примеру SecureAuth. Естественно, для обеспечения доступа к облакам можно использовать и уже имеющиеся решения для однократной регистрации пользователей — по сути это обычная Web-аутентификация, поэтому проблем, как правило, не возникает. Другие подходы, в частности решение компании Symplified, реализуют своего рода услугу по администрированию Web-доступа в виде облачного сервиса.

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

ОБЛАЧНОЕ IAM ЕЩЕ В НАЧАЛЕ СВОЕГО ПУТИ

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

При использовании SAML обычно обеспечивается хотя бы минимальный уровень поддержки, но когда дело касается управления авторизацией, стандартов вроде XACML, централизованного аудита и уж тем более управления и контроля действий привилегированных пользователей в облаках, то ситуация выглядит достаточно плачевно. Поэтому при выборе облачных сервисов нужно учитывать не только функциональные характеристики — следует серьезно задуматься об обеспечении безопасности.

Мартин Куппингер — старший партнер компании Kuppinger Cole + Partner, системный архитектор, эксперт и аналитик.