Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

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

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

Таким образом, объектом исследования работе является аутентификация, а предметом исследования сервер аутентификации Kerberos.

Целью данной работы является анализ систем аутентификации, на примере Kerberos, и определение важности их использования.

В рамках работы необходимо решить следующие задачи:

изучить литературу в области аутентификации и идентификации;
раскрыть понятие «аутентификация» и «идентификация»;
проанализировать основные протоколы аутентификации;
изучить основную концепцию Kerberos;
проанализировать принципы работы Kerberos.

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

1. Исследование предметной области

1.1 Понятие «Аутентификация» и его сущность

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

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

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

После аутентификации пользователь или процесс обычно подвергаются процессу авторизации, чтобы определить, должен ли аутентифицированный объект иметь доступ к защищенному ресурсу или системе. Пользователь может быть аутентифицирован, но не может получить доступ к ресурсу, если этому пользователю не было предоставлено разрешение в доступе [9, 14].

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

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

Многие компании используют аутентификацию для проверки пользователей, которые регистрируются на своих сайтах. Без правильных мер безопасности пользовательские данные, такие как номера кредитных и дебетовых карт могут попасть в руки киберпреступников [3, 10, 11].

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

Для предприятий и других крупных организаций аутентификация может быть выполнена с использованием единой системы единого входа (SSO), которая предоставляет доступ к нескольким системам с одним набором учетных данных для входа.

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

Традиционно аутентификация осуществлялась системами или ресурсами, к которым осуществляется доступ; например, сервер будет аутентифицировать пользователей, используя свою собственную систему паролей, реализованную локально, используя идентификаторы входа (имена пользователей) и пароли. Предполагается, что знание учетных данных для входа гарантирует подлинность пользователя. Каждый пользователь регистрируется вначале (или зарегистрирован кем-то другим, например, системным администратором), используя назначенный или самостоятельно созданный пароль. При каждом последующем использовании пользователь должен знать и использовать ранее объявленный пароль [4].

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

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

Аутентификация пользователя с идентификатором пользователя и паролем обычно считается самым основным типом аутентификации, полностью зависящим от пользователя, знающего две части одной важной информации: идентификатор пользователя или имя пользователя и пароль. Поскольку этот тип аутентификации основан только на одном коэффициенте аутентификации, это тип однофакторной аутентификации [2, 8, 11].

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

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

Используемые в настоящее время коэффициенты аутентификации включают:

Фактор знания: «То, что вы знаете». Коэффициентом знаний могут быть любые учетные данные аутентификации, которые состоят из информации, которой обладает пользователь, включая персональный идентификационный номер, имя пользователя, пароль или ответ на секретный вопрос [4].
Фактор владения: «То, что у вас есть». Коэффициент владения может представлять собой любые учетные данные, основанные на элементах, которые пользователь может им владеть и носить с собой, включая аппаратные устройства, такие как токен безопасности или мобильный телефон, используемый для приема текстового сообщения или запуска приложения аутентификации, которое может генерировать одноразовый пароль или PIN-код [4].
Фактор свойства: «То, что вы есть». Фактор свойства обычно основан на некоторой форме биометрической идентификации, включая отпечатки пальца или пальцев, распознавания лица, сканирования сетчатки глаза или на любой другой форме биометрических данных.
Фактор местоположения: «Где вы». Хотя он может быть менее конкретным, фактор местоположения иногда используется в качестве дополнения к другим факторам. Местоположение может быть определено с достаточной точностью устройствами, оснащенными GPS, или с меньшей точностью, путем проверки сетевых маршрутов. Фактор местоположения обычно не может использоваться сам по себе для аутентификации, но он может дополнять другие факторы, предоставляя средства для устранения некоторых лишних запросов. Например, это может помешать злоумышленнику, находящемуся в удаленной географической области, выдавать себя за пользователя, который обычно входит в систему только из дома или офиса в родной стране организации [5, 8, 12].
Фактор времени: «Когда вы аутентифицируетесь». Как и фактор местоположения, фактор времени сам по себе недостаточен, но он может быть дополнительным механизмом для отсеивания злоумышленников, которые пытаются получить доступ к ресурсу в то время, когда этот ресурс недоступен для авторизованного пользователя. Он также может использоваться вместе с местоположением. Например, если пользователь был в последний раз аутентифицирован в полдень в России, попытка пройти аутентификацию из США через час, будет отклоняться на основе комбинации времени и местоположения.

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

Добавление факторов аутентификации в процесс идентификации обычно повышает безопасность. Надежная аутентификация обычно относится к видам аутентификации, при которой используется по меньшей мере два фактора, при том эти факторы имеют разные типы. Различие важно; так как имя пользователя и пароль можно рассматривать как типы факторов знания, можно сказать, что базовое имя пользователя и аутентификация пароля используют два фактора знания для аутентификации — однако это не будет рассматриваться как форма двухфакторной аутентификации. Аналогично для систем аутентификации, которые полагаются на «вопросы безопасности», чтобы дополнить идентификатор пользователя и пароли [4, 11].

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

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

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

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

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

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

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

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

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

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

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

Kerberos свободно доступен из MIT, в соответствии с правами на доступ к авторским правам, очень похожими на те, которые используются для операционной системы BSD и X Window System. MIT предоставляет Kerberos в исходной форме, чтобы любой, кто хочет ее использовать, мог просмотреть код для себя и убедиться, что код заслуживает доверия. Кроме того, для тех, кто предпочитает полагаться на профессионально поддерживаемый продукт, Kerberos доступен как продукт от многих разных поставщиков [15].

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

Протокол Kerberos является более безопасным, более гибким и более эффективным, чем NTLM (протоколом сетевой аутентификации, разработанный Microsoft для Windows NT). Преимущества, полученные при использовании проверки подлинности Kerberos:

Делегированная аутентификация.

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

Интероперабельность.

Внедрение Microsoft протокола Kerberos основано на стандартизованных спецификациях, рекомендованных для целевой группы Internet Engineering Task Force (IETF). В результате реализация протокола Kerberos V5 в Windows Server закладывает основу для взаимодействия с другими сетями, в которых протокол Kerberos V5 используется для аутентификации.

Более эффективная аутентификация на серверах.

При аутентификации NTLM сервер приложений должен подключиться к контроллеру домена для аутентификации каждого клиента. С другой стороны, с протоколом проверки подлинности Kerberos V5 сервер не обязан переходить на контроллер домена. Вместо этого сервер может аутентифицировать клиента, проверяя учетные данные, представленные клиентом. Клиенты могут получать учетные данные для определенного сервера один раз, а затем повторно использовать эти учетные данные во время сеанса сетевого входа в систему. Возобновляемые сеансовые «билеты» заменяют сквозную аутентификацию.

Взаимная аутентификация.

Используя протокол Kerberos, сторона в конце сетевого подключения может проверить, что сторона на другом конце является сущностью, которую она утверждает. Хотя NTLM позволяет серверам проверять идентификационные данные своих клиентов, NTLM не позволяет клиентам проверять идентификатор сервера, а NTLM не позволяет одному серверу проверять личность другого. Проверка подлинности NTLM была разработана для сетевой среды, в которой серверы считались подлинными. Протокол Kerberos V5 не делает такого предположения [1, 7, 12].

Стандарты протокола Kerberos V5.

Протокол аутентификации Kerberos возник в MIT более десяти лет назад, когда он был разработан инженерами, работающими над Project Athena. Первым публичным релизом был протокол аутентификации Kerberos версии 4. После обширного обзора отрасли этого протокола авторы протокола разработали и опубликовали протокол аутентификации Kerberos версии 5.

Протокол Kerberos V5 теперь находится на стандартном треке с IETF. Реализация протокола в Windows Server 2003 тесно соответствует спецификации, определенной в Internet RFC 1510. Кроме того, механизм и формат передачи токенов безопасности в сообщениях Kerberos следует спецификациям, определенным в Internet RFC 1964.

Когда пользователь хочет получить доступ к серверу, серверу необходимо проверить личность пользователя. Рассмотрим ситуацию, в которой пользователь утверждает, что это, например, dima@dima.com. Поскольку доступ к ресурсам основан на удостоверениях и связанных с ними разрешениях, сервер должен быть уверен, что пользователь действительно имеет удостоверение личности, которое он утверждает. Для начала нужно надежно упаковать имя пользователя. Например, имя пользователя, то есть dima@dima.com, и учетные данные пользователя упаковываются в структуру данных, называемую билетом.

После шифрования билета сообщения используются для переноса учетных данных пользователя по сети.

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

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

К возможным ключам Kerberos относятся:

Долгосрочный ключ. Ключ, известный только целевому серверу и KDC, с которым шифруется клиентский билет.
Ключ сеанса клиента/сервера. Был подтвержден краткосрочный односеансовый ключ, созданный KDC и используемый для шифрования сообщений «клиент-сервер» и «сервер-клиент» после идентификации и авторизации.
Ключ сеанса KDC / пользователя. KDC и пользователь совместно используют секретный ключ шифрования, который используется, например, для шифрования сообщения клиенту, содержащему ключ сеанса.

Протокол Kerberos V5 может использовать как симметричное, так и асимметричное шифрование

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

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

Механизм аутентификации Kerberos создает и безопасно предоставляет аутентификатор — обычно на основе уникальных временных меток, вместе с билетом клиента. Аутентификатор уникален и действителен только для одного использования. Это ограниченное использование минимизирует возможность получения и повторного использования (повторения) клиентского билета, возможно, в попытке украсть и использовать личность клиента.

2.2 Принципы работы

Поток процессов протокола аутентификации Kerberos состоит из пяти шагов:

простая взаимная аутентификация на основе симметричной ключевой криптографии;
центр распространения ключей;
передача ключа сеанса в сеансах;
«билеты» на «билеты»;
cлужба обмена билетами.

Простая взаимная аутентификация на основе симметричной ключевой криптографии.

Рассмотрим пример: Дима (или клиент) хочет начать безопасную связь с сервером. Оба конца решили включить протокол Kerberos для обеспечения их идентичности. Рассмотрим, как работает процесс аутентификации. Как упоминалось ранее, Kerberos включает симметричную криптографию ключа, где используется один ключ для шифрования и дешифрования [15].

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

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

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

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

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

Центр распространения ключей.

Поскольку обе стороны используют один и тот же секретный ключ, здесь нужно подумать о том, как клиент и сервер поделились секретным ключом. Добавляя к этому, клиент может захотеть общаться с несколькими серверами, и ему нужен ключ для каждого сервера. Точно так же сервер может обмениваться данными с несколькими клиентами и ему нужен ключ для каждого клиента. Следовательно, трудно хранить, а также защищать несколько клавиш на многих системах. Центр распространения ключей (KDC), доверенный посредник, является решением протокола Kerberos для этой проблемы.

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

Если клиент хочет связаться с сервером, он отправляет запрос в KDC. Затем KDC распределяет сеансовый ключ как для клиента, так и для сервера в зашифрованной форме, где копия клиента зашифровывается с долгосрочным ключом и серверной копией клиента с долгосрочным ключом сервера [8].

Передача ключа сеанса в сеансовых билетах.

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

Чтобы избежать этой ситуации, вместо отправки сеансового ключа на сервер KDC отправляет клиенту копию ключа в виде сеансового билета [3, 7, 8].

В ответ на запрос клиента KDC отправляет обе копии ключа сеанса самому клиенту. Здесь клиентская копия зашифровывается с помощью долгосрочного ключа клиента, тогда как ключ сеанса сервера отправляется в структуре данных, известной как Session Ticket. Теперь клиент становится ответственным за управление билетом сеанса до тех пор, пока он не достигнет сервера. Здесь ничего плохого не произойдет, если сообщение от KDC достигнет неправильной «руки». Поскольку копия ключа сеанса клиента может быть получена только кем-то, кто знает, что секретный ключ клиента и копия ключа сеанса сервера могут быть извлечены только кем-то, кто знает секретный ключ сервера.

После получения ответа от KDC клиент отправляет сообщение серверу, когда он хочет общаться. В этом процессе взаимной аутентификации клиент отправляет сообщение, которое включает в себя аутентификатор, зашифрованный с помощью ключа сеанса, который был получен от KDC и сеансового билета. Теперь сеансовый билет и аутентификатор вместе становятся удостоверениями личности клиента [3, 4, 8].

Когда сервер получает сообщение, он расшифровывает сеансовый билет, используя секретный ключ (долгосрочный ключ сервера), который совместно используется сервером и KDC. Затем извлекая ключ сеанса для дешифрования аутентификатора. После проверки временной отметки клиента, это ответ с зашифрованной меткой времени, как описано в шаге 1.

«Билетные билеты».

Ключ сеанса клиента, отправленный из KDC клиенту, зашифровывается с использованием долгосрочного ключа клиента. Здесь долгосрочный ключ клиента берется из учетных данных, которые используются для входа в рабочую станцию Димы, используя одностороннюю хеш-функцию. С другой стороны, KDC извлекает свою копию долгосрочного ключа Димы из своей учетной записи в базе данных. Для того чтобы повысить безопасность, здесь долгосрочный ключ будет заменен ключом сеанса.

После создания долгосрочного ключа, когда Дима заходит на его рабочую станцию, он отправляет запрос KDC для сеансового ключа, который требует использования между клиентом и KDC. Как только KDC получает запрос от клиента, он извлекает долгосрочный ключ Димы из своей базы данных и отвечает клиенту с билетом сеанса, который называется Ticket Granting Ticket (TGT). TGT включает ключ сеанса, который будет использоваться KDC при общении с Димой. Наряду с TGT ответное сообщение также включает в себя ключ сеанса для использования клиентом для связи с KDC. TGT зашифрован с помощью долгосрочного ключа KDC, а ключ сеанса клиента зашифрован с помощью долгосрочного ключа клиента.

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

Служба обмена билетами.

Теперь клиент должен получить билет сеанса из KDC, чтобы запросить услугу с сервера. Здесь клиент отправляет сообщение, которое включает TGT и аутентификатор, который зашифрован с использованием ключа сеанса, совместно используемого клиентом и KDC. Работа KDC делится на две части для работы по перекрестному домену [7, 8].

Как только KDC получает сообщение клиента, служба выдачи билетов проверяет запрос и отправляет билет сеанса и ключ сеанса, как описано в шаге 3.

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

Что касается реализации протокола Kerberos в Windows, то надо отметить следующее:

Ключ пользователя генерируется на базе его пароля. Таким образом, при использовании слабых паролей эффект от надежной защиты процесса аутентификации будет сведен к нулю.
В роли Kerberos-серверов выступают контроллеры домена, на каждом из которых должна работать служба Kerberos Key Distribution Center (KDC). Роль хранилища информации о пользователях и паролях берет на себя служба каталога Active Directory. Ключ, который разделяют между собой сервер аутентификации и сервер выдачи разрешений формируется на основе пароля служебной учетной записи krbtgt - эта запись автоматически создается при организации домена и всегда заблокирована.
Microsoft в своих ОС использует расширение Kerberos для применения криптографии с открытым ключом. Это позволяет осуществлять регистрацию в домене и с помощью смарт-карт, хранящих ключевую информацию и цифровой сертификат пользователя.
Использование Kerberos требует синхронизации внутренних часов компьютеров, входящих в домен Windows.

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

ЗАКЛЮЧЕНИЕ

В рамках работы решены следующие задачи:

изучена литература в области аутентификации и идентификации;
раскрыто понятие «аутентификация» и «идентификация»;
проанализированы основные протоколы аутентификации;
изучена основная концепция Kerberos;
проанализированы принципы работы Kerberos.

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

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

Бирюков А.А. Информационная безопасность: защита и нападение. — ДМК-Пресс, 2012. — 476 с.
Гаранина А. Шифровка и дешифровка информации как аспекты прикладной лингвистики. — LAP Lambert Academic Publishing, 2011. — 80 с.
Запечинков, С.В. Информационная безопасность открытых систем в 2-х томах т.2 / С.В. Запечинков. — ГЛТ, 2008. — 558 c.
Малюк, А.А. Информационная безопасность: концептуальные и методологические основы защиты информации / А.А. Малюк. - М.: ГЛТ, 2004. — 280 c.
Райтман М. Искусство легального, анонимного и безопасного доступа к ресурсам Интернета. — БХВ-Петербург, 2016. — 615 с.
Родичев Ю.А. Информационная безопасность: нормативно-правовые аспекты. — Питер, 2008. — 273 с.
Семененко, В.А. Информационная безопасность / В.А. Семененко. — МГИУ, 2011. — 277 c.
Скабцов Н. Аудит безопасности информационных систем. — Питер, 2018. — 272 с.
Carter G. LDAP System Administration: Putting Directories to Work. — O'Reilly Media, 2003. — 312 p.
Conheim А. Computer security and cryptography. — WILEY, 2007. — 542 p.
Desmond B. Active Directory: Designing, Deploying, and Running Active Directory. — O'Reilly Media; Fifth edition, 2013. — 738 p.
Garman J. Kerberos: The Definitive Guide. — O'Reilly Media, 2003. — 274 p.
Spivey B. Hadoop Security: Protecting Your Big Data Platform. — O'Reilly Media; 1 edition, 2015. — 340 p.
Tung B. Kerberos: A Network Authentication System. — Addison-Wesley Professional, 1999. — 192 p.
Открытые системы [Электронный ресурс]. Сервер аутентификации Kerberos — Режим доступа: https://www.osp.ru/os/1996/01/178793/ (Дата обращения 10.03.2019)
Habr [Электронный ресурс]. Обзор способов и протоколов аутентификации в веб-приложениях. — Режим доступа: https://habr.com/ru/company/dataart/blog/262817/ (Дата обращения 10.03.2019)