Файл: Сервер аутентификации Kerberos (Цербер) (Понятие «Аутентификация» и его сущность).pdf

Системе и процессам также может потребоваться авторизация их автоматизированных действий в сети. Онлайн-службы резервного копирования, системы исправления и обновления и системы удаленного мониторинга, такие как те, которые используются в технологиях телемедицины и смарт-сетки, все должны надежно пройти аутентификацию, прежде чем они смогут убедиться, что это авторизованная система, участвующая в любом взаимодействии, а не злоумышленник [4].

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

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

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

Другие методы проверки подлинности включают:

• двухфакторная аутентификация (2FA) добавляет дополнительный уровень защиты к процессу аутентификации. Она требует, чтобы пользователь предоставил второй коэффициент аутентификации в дополнение к паролю. Системы 2FA часто требуют, чтобы пользователь вводил код подтверждения, полученный посредством текстового сообщения на предварительно зарегистрированном мобильном телефоне, или код, созданный приложением аутентификации [4, 7];
• многофакторная аутентификация требует от пользователей аутентификации с несколькими факторами аутентификации, включая биометрический фактор, такой как отпечаток пальца или распознавание лица, фактор владения, такой как фейс-ключ безопасности или токен, созданный приложением-аутентификатором [4, 7];
• одноразовый пароль представляет собой автоматически создаваемую числовую или буквенно-цифровую строку символов, которая аутентифицирует пользователя. Этот пароль действителен только для одного сеанса входа или транзакции и обычно используется для новых пользователей или для пользователей, потерявших свои пароли, и им предоставляется одноразовый пароль для входа в систему и перехода на новый пароль;
• трехфакторная аутентификация (3FA) — это тип MFA, который использует три фактора аутентификации, как правило, коэффициент знания (пароль) в сочетании с фактором владения (маркер безопасности) и коэффициентом свойства (биометрический);
• биометрия, тоже к ним относится. Хотя некоторые системы аутентификации могут зависеть исключительно от биометрической идентификации, биометрические данные обычно используются в качестве второго или третьего коэффициента аутентификации. Более распространенные типы биометрической аутентификации включают сканирование отпечатков пальцев, сканирование лица или сетчатки глаза и распознавание голоса;
• мобильная аутентификация — это процесс проверки пользователя через его устройства или проверка самих устройств. Это позволяет пользователям входить в безопасные места и ресурсы из любого места. Процесс мобильной аутентификации включает в себя многофакторную аутентификацию, которая может включать одноразовые пароли, биометрическую аутентификацию или проверку QR-кода;
• при непрерывной аутентификации, вместо того, чтобы пользователь вошел в систему или вышел из нее, приложение компании постоянно вычисляет «оценку подлинности», которая измеряет вероятность того, что владелец учетной записи является физическим лицом, использующим устройство [1, 7].
• следующая это проверка подлинности API. Стандартными методами управления аутентификацией API являются: базовая аутентификация HTTP; API и OAuth. В базовой аутентификации HTTP сервер запрашивает информацию об аутентификации, то есть имя пользователя и пароль, от клиента. Затем клиент передает информацию аутентификации серверу в заголовке авторизации. В методе аутентификации ключа API первому пользователю присваивается уникальное сгенерированное значение, которое указывает, что пользователь известен. Затем каждый раз, когда пользователь пытается снова войти в систему, его уникальный ключ используется для проверки того, что он тот же пользователь, который ранее ввел систему, а Open Authorization (OAuth) является открытым стандартом для аутентификации и авторизации на токенах в Интернете. OAuth позволяет использовать информацию учетной записи пользователя сторонними службами, такими как Facebook, без раскрытия пароля пользователя. OAuth выступает в качестве посредника от имени пользователя, предоставляя службе токен доступа, который разрешает совместное использование определенной информации учетной записи [5, 13].

---

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

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

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

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

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

1.2 Протоколы аутентификации

Основным, базовым элементом для понимания решений управления идентификацией являются протоколы. Решения для идентификации часто основаны на стандартных протоколах. К сожалению, различные типы ИТ-ресурсов решили поддерживать разные протоколы. Устройства поддерживают определенные протоколы, приложения поддерживают другой набор (и различные типы приложений поддерживают разные), а сетевые устройства поддерживают другие протоколы. Вся эта разнообразность протоколов усложняет ситуацию [9, 11].

---

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

Служба удаленного доступа к службе аутентификации (RADIUS) — это протокол аутентификации, в основном используемый сетевыми службами, такими как беспроводные сети, VPN и сетевое инфраструктурное оборудование. Серверы RADIUS обычно подключаются к центральной службе каталогов, которая содержит учетные данные пользователя. RADIUS в основном использовался интернет провайдерами и тому подобными организациями на ранней стадии развития интернета, но с тех пор перешел на новый уровень, и теперь может использоваться в организациях для управления беспроводным доступом [3].

Как и в случае с LDAP, существуют варианты, при которых компании не будут иметь дело с собственными серверами RADIUS. RADIUS-as-a-Service (RaaS) предоставляет предварительно построенный, сконфигурированный, масштабируемый и полностью управляемые и поддерживаемые серверы RADIUS.

Язык разметки безопасности (SAML) — это протокол аутентификации, который чаще всего ассоциируется с решениями единого входа для веб-приложений. Открытый стандарт широко используется веб-приложениями и поставщиками веб-сервисов [7].

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

SAML добилась больших успехов в секторе веб-приложений, но не используется для устройств и вообще не используется внутренними приложениями.

Еще один механизм аутентификации для веб-приложений OpenID получил некоторое признание благодаря поддержке значительных пользовательских веб-приложений, таких как Google и Yahoo!. OpenID работает аналогично SAML, но его менее сложно реализовать. Используя OpenID, стороннее веб-приложение может разрешить пользователям входить в свои службы через Google или Yahoo ID [5].

Этот механизм аутентификации в значительной степени использовался для веб-приложений, ориентированных на потребителя, хотя начинает проявлять определенную тягу к бизнес-сценариям из-за популярности Google Apps for Work.

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

---

Также известны стандарты OAuth и OpenID Connect. Первая версия стандарта разрабатывалась в 2007 – 2010 гг., а текущая версия 2.0 опубликована в 2012 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

Варианты:

• попросить пользователя указать данные своей учетной записи, — плохой вариант.
• попросить пользователя создать ключ доступа, — возможно, но весьма сложно.

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.

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

Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail) [16].

Стандарт описывает четыре вида грантов, которые определяют возможные сценарии применения:

1. Authorization Code — этот грант пользователь может получить от сервера авторизации после успешной аутентификации и подтверждения согласия на предоставление доступа. Такой способ наиболее часто используется в веб-приложениях. Процесс получения гранта очень похож на механизм аутентификации пассивных клиентов в SAML и WS-Federation.
2. Implicit — применяется, когда у приложения нет возможности безопасно получить токен от сервера авторизации (например, JavaScript-приложение в браузере). В этом случае грант представляет собой токен, полученный от сервера авторизации, а шаг № 2 исключается из сценария выше.
3. Resource Owner Password Credentials — грант представляет собой пару username/password пользователя. Может применяться, если приложение является «интерфейсом» для сервера ресурсов (например, приложение — мобильный клиент для Gmail).
4. Client Credentials — в этом случае нет никакого пользователя, а приложение получает доступ к своим ресурсам при помощи своих ключей доступа [16].

---

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

Зачастую API сервера ресурсов включает операцию, предоставляющую информацию о самом пользователе (например, /me в Facebook API). Приложение может выполнять эту операцию каждый раз после получения токена для идентификации клиента. Такой метод иногда называют псевдо-аутентификацией.

Использовать стандарт OpenID Connect, разработанный как слой учетных данных поверх OAuth. В соответствии с этим стандартом, сервер авторизации предоставляет дополнительный identity token на шаге № 2. Этот токен в формате JWT будет содержать набор определенных полей (claims) с информацией о пользователе.

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

TACACS широко используется на рынке сетевой инфраструктуры, является относительно простым протоколом аутентификации. TACACS был впервые разработан в середине 1980-х годов для управления аутентификацией в неклассифицированной сети Министерства обороны США [3, 7].

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

В рамках данной главы были рассмотрены понятия «аутентификация», «идентификация», а также протоколы аутентификации.

2. Особенности сервера аутентификации Kerberos

2.1 Основная концепция

Идентификация и проверка подлинности пользователей или аутентификация — основное средство защиты информационных систем от постороннего вмешательства. В соответствии с технологией клиент/сервер, организация такой защиты заключается в создании специального сервера проверки подлинности, услугами которого будут пользоваться другие серверы и клиенты информационной системы. На сегодняшний день на роль фактического стандарта сервера аутентификации претендует Kerberos, продукт, разработанный в середине 1980-х годов в Массачусетском технологическом институте и претерпевший с тех пор ряд принципиальных изменений. Клиентские компоненты Kerberos присутствуют в большинстве современных операционных систем - концерн OSF, например, сделал Kerberos частью своей распределенной компьютерной среды (DCE) [13].

---