Аутентификация в облаке

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

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

Здесь я публикую перевод этой статьи.

Автор Manny Vellon, CTO, Likewise Software,
special to Network World November 10, 2010 03:09 PM ET
Так много всего написано про облачные вычисления, а теперь хочется уделить немного внимания аутентификации в облаке.
Но сначала давайте посмотрим, как работает аутентификация в локальной сети.
Когда вы входите на свою машину и пытаетесь получить доступ к какому либо ресурсу, ну, скажем, файловому серверу или базе данных, то кто-то должен гарантировать, что Ваши логин и пароль действительны. Если дело происходит на Windows машине, то аутентификацию осуществляет компонент, называемый "Local Security Authority Subsystem Service". Запустите Диспетчер задач и посмотрите на список запущенных процессов. Вы увидите программу, которая называется "lsass.exe". Если вы используете Likewise на машине с Linux/UNIX/Mac программу, то увидите в списке процесс "lsassd".
Пользователя можно аутентифицировать одним из двух способов: используя локальную учетную запись или используя запись в Active Directory. Если ваш компьютер включен в Active Directory, то, как правило, вход осуществляется с помощью учетной записи в AD (используя имя соответствующего домена). Если же компьютер не включен в AD, то он работает в режиме рабочих групп и вход осуществляется с использованием локальной учетной записи. В последнем случае вводимые имя и пароль сравниваются с информацией, которая хранится непосредственно на Вашем компьютере. В случае с AD происходит нечто более существенное: LSASS удостоверяет Ваши полномочия, обмениваясь данными с контроллером домена AD по протоколу Kerberos.
Kerberos – это удивительная вещь. Он позволяет подтвердить полномочия без непосредственной передачи пароля, ни в чистом виде, ни в виде хэша. Это очень важный момент, так как взлом учетной записи путем подбора пароля становится невозможным.
Kerberos также замечателен там, что поддерживает возможность однократного входа (single sign on). Как только вы входите на свою машину, вы получаете специальный «билет», который может использоваться для получения дополнительных «билетов», которые, в свою очередь, дают возможность обращаться к другим сервисам.
Если, к примеру, Вы обращаетесь к файловому серверу под управлением Windows, то, если Вам разрешен доступ, он не будет дополнительно спрашивать у Вас логин и пароль. Незаметная для Вас процедура аутентификация автоматически получает «билет» на файловый сервер на основе билета, полученного при входе в систему. Когда Вы обращаетесь к SQL серверу или сайту под управлением IIS, Вам не требуется вводить дополнительной информации, подтверждающей Вашу личность, необходимые для доступа «билеты» получаются автоматически. Великолепно!
В случае, когда вход осуществляется с использованием локальной учетной записи, вы лишаетесь всех описанных преимуществ. При обращении к файловому серверу будет использоваться уже устаревшая NTLM аутентификация и, учитывая тот факт, что сервер ничего не знает про Вашу локальную учетную запись, то, если доступ к файлам на сервере ограничен, при обращении к ним Вы увидите окошко для ввода логина и пароля. В случае SQL сервера и IIS будут использоваться более примитивные способы аутентификации (например, аутентификация SQL)
Сложности аутентификации в облаке
А теперь давайте рассмотрим облако. Или, правильнее сказать, облака, ведь обычно мы имеем дело сразу с несколькими решениями в облачной среде.
В то время как частные облака на базе VMWare могут в полной мере использовать все преимущества Acitive Directory и Kerberos, гибридные облака, включающие в себя внешние вычислительные ресурсы – это совсем другая история. В этом случае выбор метода аутентификации очень сильно зависит от реализации гибридного решения. Если внешние облачные ресурсы подключаются к частному облаку через VPN, то все участники облака фактически являются частью одной внутренней сети, и все должно быть ОК.
Все гораздо сложнее в случае публичного облака.
Публичные облака с самого начала создаются как внешние, по отношению к компаниям, их использующим. В них размещаются приложения, распространяющиеся по модели SaaS (software-as-a-service/приложение-как-услуга), как правило, это Web-приложения. Как будет осуществляться аутентификация в этом случае? Как будут проверяться Ваши учетные данные при входе в Web-приложение? К сожалению, правильный ответ звучит так: “любым доступным способом” – через LDAP, прямым поиском в базе данных или файле, даже иногда через Kerberos.
Проблема заключается в недостаточной связности, которая делает сложным многое, считающееся в частном облаке само собой разумеющимся. Есть сотрудник покидает компанию, то как буду блокироваться его учетные записи во внешних SaaS приложениях? Как пользователи отслеживают пароли для всех используемых приложений, если они не поддерживают технологию однократного входа (SSO)? Как можно ужесточить парольную политику при условии, что никакие две системы не используют один и тот же механизм аутентификации?
Пока мы только начинаем решать некоторые из перечисленных проблем. К примеру, протоколы SAML (Security Assertion Markup Language) и ADFS(Active Directory Federation Services) позволяют осуществлять федеративную аутентификацию. Это дает возможность приложениям, исполняемым в публичном облаке, аутентифицировать пользователей по их корпоративным учетным данным.
Компания SalesForce, к примеру, позволит Вам войти в систему используя логин и пароль от корпоративной сети, при условии, что у Вашей организации заключено с ней федеративное соглашение. К сожалению, федеративная идентификация хорошо проработана только для достаточно простых способов использования Web-приложений. Нет простого способа автоматически архивировать Ваш локальный диск в публичном облаке с использованием корпоративных учетных данных. Вы не сможете написать безопасное локальное приложение, которое, используя федеративную идентификацию, обращается к базе данных SQL в публичном облаке.
В конце концов, различия между корпоративной и облачной аутентификацией должны исчезнуть – все процессы аутентификации должны базироваться на маршрутизируемых протоколах интернета, а использование федеративной идентификации должно стать гораздо проще (не должно быть необходимости во внешних и внутренних серверах федеративной идентификации).
Все это потребует времени. Реализация LSASS от Microsoft не имеет ни малейшего представления о протоколах аутентификации, базирующихся на Web-технологиях. Когда нам удастся справиться с этим, необходимо убедиться, что не были потеряны многочисленные достоинства существующих механизмов. Kerberos – это замечательный безопасный протокол, позволяющий пользователям работать с большим удобством. Надо придумать как можно расширить область его применения в контексте публичных облаков.
Оригинал: http://www.networkworld.com/news/tech/2010/111010-authentication-in-the-cloud.html