что такое сервер аутентификации

Сервер аутентификации

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

Ключевые особенности

Использование многофакторной аутентификации непременно снижает риски компрометации аутентификационных данных клиента. Применение одноразовых паролей (One-Time Password; OTP) в качестве одного из факторов в разы уменьшает риск несанкционированного доступа к системе. Ключевой особенностью ОТР является их однократное использование в процессе выполнения каждой операции (аутентификация, подтверждение транзакции…). Таким образом, знание одноразового пароля не предоставляет злоумышленнику дополнительной информации о данных пользователя. Для получения ОТР используются программные или аппаратные генераторы. Примером программного генератора может служить генерация пароля сервером аутентификации или мобильным приложением, а аппаратного – генерация ОТР посредством отчуждаемого носителя (аутентификатора). Разумеется, использование аппаратных генераторов является более безопасным методом. Поэтому сервер аутентификации должен обладать необходимыми функциями поддержки различных ОТР-генераторов, включая различные типы банковских карт с поддержкой стандарта OATH (TOTP, HOTP, OCRA) или EMV, сертифицированных по стандарту VISA и MasterCard в качестве платежных банковских карт.

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

С увеличением спроса на дистанционное обслуживание появляются и новые сервисы, разрабатываемые организациями для своих клиентов. Возможность сервера аутентификации интегрироваться с различными типами систем и приложений позволит реализовать доступ к этим сервисам по различным каналам аутентификации. Каналы аутентификации могут использоваться для разграничения доступа клиентов к сервисам в зависимости от типа производимых операций, выполняемых ими действий, либо в качестве дополнительного канала, используемого с целью повышения уровня безопасности для доступа к какому-то определенному сервису. Примеры каналов аутентификации: web, мобильный клиент, корпоративный «толстый» клиент, 3D Secure, IVR.

Для доступа к различным сервисам могут использоваться один или несколько аутентификаторов. Поэтому наряду с поддержкой различных каналов аутентификации, сервер должен обеспечивать и различными методами, на основе которых могут использоваться следующие типы аутентификаторов: PKI-токены (X.509), матричные карты, SMS-сообщения, аппаратные и программные генераторы одноразовых паролей. Такая функциональность позволит организациям не ограничиваться одним методом аутентификации для разрешения доступа клиента к различным сервисам, а, наоборот, обеспечит его максимально удобным и безопасным способом работы с системой в рамках единого комплексного решения. К тому же клиенты могут использовать дополнительные аутентификаторы для подключения к новым сервисам или же использовать несколько устройств сразу в зависимости от уровня риска и решаемых задач.

Говоря об аутентификации клиентов в различных системах и сервисах, необходимо обращать внимание и на безопасный доступ к самому серверу аутентификации. Имеет ли смысл использовать решение по безопасности, не позволяющее реализовать собственную защиту? Очевидно, нет. Доступ к интерфейсу (консоли) управления сервером аутентификации получают специально уполномоченные лица – администраторы, менеджеры, операторы и пр. Они могут конфигурировать сервер, создавать пользователей, назначить им роли. Для входа в консоль управления необходимо предоставлять одновременный доступ нескольким уполномоченным лицам. Разграничение прав доступа таким образом позволит предоставить только необходимые полномочия выше указанным лицам и избежать полного доступа одним сотрудником, тем самым, уменьшая риск НСД и принятия важных решений одним лицом. А использование при аутентификации смарт-карт и PIN-кодов позволит дополнительно увеличить уровень безопасности системы.

Сервер аутентификации выполняет различные криптографические операции и хранит различные данные аутентификации. Чтобы достичь максимального уровня защищенности этих процессов, необходима поддержка аппаратных модулей безопасности (Hardware Security Module; HSM). К сожалению, не каждый сервер поддерживает эти модули. Поэтому при выборе сервера аутентификации в зависимости от требуемого уровня защищенности необходимо рассматривать то решение, которое поддерживает различные HSM (Thales nShield, SafeNet, Utimaco, функционирующих в режиме FIPS).

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

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

Источник

Статьи

Зачем нужен сервер аутентификации

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

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

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

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

Самое неприятное начинается, когда внутри компании решают, что необходимо обеспечить защиту, например, электронной почты. Помимо настройки TLS-шифрования, конечно, вспоминают о двухфакторной аутентификации, или, сокращенно, 2FA. Если почтовый сервер поддерживает 2FA «из коробки», то используют эту возможность. Если же такого функционала нет — компания может решить «допилить» его самостоятельно. Даже не буду углубляться в особенности доморощенных модулей аутентификации. Главное, что теперь у пользователя есть какой-то способ строгой аутентификации при входе в почтовый ящик: аппаратный или программный токен, смарт-карта или что-то еще.

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

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

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

Сервер аутентификации — это единый центр администрирования всех процессов проверки подлинности сразу для всех приложений/сервисов/ресурсов. Промышленные такие серверы поддерживают целый набор методов аутентификации. Как правило, это OATH HOTP, TOTP, OCRA, PKI-сертификаты, RADIUS, LDAP, обычный пароль, SMS, CAP/DPA и многие другие. Каждый ресурс, использующий сервер аутентификации, может использовать метод, который требуется именно ему.

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

Теперь добавление второго фактора для проверки подлинности не потребует от компании создания нового «костыля» для приложения и закупки новых токенов. Вообще добавление нового метода аутентификации — стандартная задача для подобных систем. Приведу пример. Банк А проверял подлинность владельцев дебетовых или кредитных карт в клиент-банке по сертификатам на USB-токенах. Его платежные карты были исключительно с магнитной полосой, но в какой-то момент банк наладил выпуск карт с EMV-чипом, который, по сути, является микрокомпьютером. Карту с EMV-чипом можно использовать для аутентификации по алгоритму Master Card Chip Authentication Program (CAP). То есть теперь банк А может отказаться от применения для каждого пользователя дорогостоящих PKI-токенов и сменить этот метод аутентификации на CAP, для которого требуется только недорогой криптокалькулятор. Через некоторое время банк А начинает выпуск платежных карт с дисплеем и реализованным алгоритмом OATH TOTP и для того, чтобы избавить пользователя от использования дополнительного криптокалькулятора, настраивает аутентификацию TOTP для клиент-банка. Следует понимать, что помимо дистанционного банковского обслуживания в банке А есть множество других сервисов, как внутренних, так и предназначенных для клиентов или партнеров, требующих аутентификации. Для каждого приложения служба информационной безопасности может выдвинуть свои требования по необходимым методам проверки подлинности пользователей. Вся аутентификация банка А может производиться на сервере аутентификации. Нет никакой необходимости заниматься разработками для каждого приложения отдельно.

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

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

Некоторые промышленные серверы аутентификации поддерживают использование Hardware Security Module (HSM). Это обеспечивает сохранность всей чувствительной информации путем шифрования. Ключи шифрования при таком подходе хранятся в аппаратном модуле HSM. Их невозможно извлечь, и даже все операции с этими ключами производятся только внутри HSM. Так достигаются высочайший уровень защищенности аутентификационных данных и высокая скорость работы криптографических алгоритмов, выполняемых внутри аппаратных модулей HSM.

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

Cтатья была впервые опубликована в PCWeek

Источник

Зачем нужен сервер аутентификации

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

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

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

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

Самое неприятное начинается, когда внутри компании решают, что необходимо обеспечить защиту, например, электронной почты. Помимо настройки TLS-шифрования, конечно, вспоминают о двухфакторной аутентификации, или, сокращенно, 2FA. Если почтовый сервер поддерживает 2FA «из коробки», то используют эту возможность. Если же такого функционала нет — компания может решить «допилить» его самостоятельно. Даже не буду углубляться в особенности доморощенных модулей аутентификации. Главное, что теперь у пользователя есть какой-то способ строгой аутентификации при входе в почтовый ящик: аппаратный или программный токен, смарт-карта или что-то еще.

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

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

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

Сервер аутентификации — это единый центр администрирования всех процессов проверки подлинности сразу для всех приложений/сервисов/ресурсов. Промышленные такие серверы поддерживают целый набор методов аутентификации. Как правило, это OATH HOTP, TOTP, OCRA, PKI-сертификаты, RADIUS, LDAP, обычный пароль, SMS, CAP/DPA и многие другие. Каждый ресурс, использующий сервер аутентификации, может использовать метод, который требуется именно ему.

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

Теперь добавление второго фактора для проверки подлинности не потребует от компании создания нового «костыля» для приложения и закупки новых токенов. Вообще добавление нового метода аутентификации — стандартная задача для подобных систем. Приведу пример. Банк А проверял подлинность владельцев дебетовых или кредитных карт в клиент-банке по сертификатам на USB-токенах. Его платежные карты были исключительно с магнитной полосой, но в какой-то момент банк наладил выпуск карт с EMV-чипом, который, по сути, является микрокомпьютером. Карту с EMV-чипом можно использовать для аутентификации по алгоритму Master Card Chip Authentication Program (CAP). То есть теперь банк А может отказаться от применения для каждого пользователя дорогостоящих PKI-токенов и сменить этот метод аутентификации на CAP, для которого требуется только недорогой криптокалькулятор. Через некоторое время банк А начинает выпуск платежных карт с дисплеем и реализованным алгоритмом OATH TOTP и для того, чтобы избавить пользователя от использования дополнительного криптокалькулятора, настраивает аутентификацию TOTP для клиент-банка. Следует понимать, что помимо дистанционного банковского обслуживания в банке А есть множество других сервисов, как внутренних, так и предназначенных для клиентов или партнеров, требующих аутентификации. Для каждого приложения служба информационной безопасности может выдвинуть свои требования по необходимым методам проверки подлинности пользователей. Вся аутентификация банка А может производиться на сервере аутентификации. Нет никакой необходимости заниматься разработками для каждого приложения отдельно.

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

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

Некоторые промышленные серверы аутентификации поддерживают использование Hardware Security Module (HSM). Это обеспечивает сохранность всей чувствительной информации путем шифрования. Ключи шифрования при таком подходе хранятся в аппаратном модуле HSM. Их невозможно извлечь, и даже все операции с этими ключами производятся только внутри HSM. Так достигаются высочайший уровень защищенности аутентификационных данных и высокая скорость работы криптографических алгоритмов, выполняемых внутри аппаратных модулей HSM.

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

Автор статьи — инженер по информационной безопасности компании «Пауэр Секьюрити».

Источник

Kerberos за 5 минут: знакомство с сетевой аутентификацией

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

В этой статье мы ответим, что такое Kerberos, как он работает, и рассмотрим типичные атаки, которые инженеры безопасности Kerberos должны преодолевать ежедневно.

К концу вы получите новую оценку современной сетевой безопасности и, надеюсь, пик интереса к кибербезопасности!

Что такое Kerberos?

Kerberos — это протокол проверки подлинности компьютерной сети, предназначенный для упрощения и безопасности проверки подлинности.

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

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

Наиболее известное использование Kerberos — это Microsoft Active Directory, служба каталогов по умолчанию, включенная в Windows 2000 и более поздних версий для управления доменами и аутентификации пользователей.

Другие известные применения — Apple, НАСА, Google, Министерство обороны США и университеты по всей территории Соединенных Штатов.

Преимущества Kerberos

Kerberos так широко используется из-за его простоты и непревзойденной безопасности данных. Вот лишь некоторые из его преимуществ:

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

Пример взаимной аутентификации:

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

Основные компоненты Kerberos

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

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

Билет на выдачу билетов

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

Клиенты не могут расшифровать TGT, так как у них нет ключа TGS. Следовательно, они должны слепо представить TGT желаемым службам (которые могут получить доступ к TGS) и позволить службам решить, может ли клиент получить к нему доступ.

Скрывая TGT от клиента, Kerberos предотвращает мошенническое копирование или изменение разрешений клиентом.

Сервер аутентификации

Сервер аутентификации — это первая остановка при аутентификации с помощью Kerberos. Сначала клиент должен аутентифицироваться в AS, используя имя пользователя и пароль для входа.

После этого AS перенаправляет имя пользователя в KDC, который, в свою очередь, предоставляет TGT. Без выполнения этого первого шага клиент не сможет взаимодействовать с какой-либо другой частью системы Kerberos.

Служба выдачи билетов

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

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

Как работает Kerberos?

Проверка подлинности Kerberos состоит из 4 этапов, в зависимости от того, какие компоненты взаимодействуют между собой:

Пример процесса Kerberos

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

В начале рабочего дня вы вводите пароль в свой клиент. Пароль аутентифицируется AS, а затем KDC предоставляет вам TGT. В этом билете есть набор ключей от dataScienceкоролевства.

Затем TGT кэшируется на вашем компьютере для дальнейшего использования. Этот доступ позволяет вам использовать любые услуги в dataScienceобласти, например, доступ к покупательскому поведению клиентов.

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

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

Разбивка процесса Kerberos (16 шагов)

Теперь мы разберем каждый этап процесса, чтобы вы лучше понимали, что происходит за кулисами:

1. Войти

Пользователь вводит свое имя пользователя и пароль. Затем клиент с поддержкой Kerberos преобразует этот пароль в секретный ключ клиента.

2. Запросы клиентов на сервер выдачи билетов

Затем клиент отправляет серверу аутентификации текстовое сообщение, содержащее:

3. Сервер проверяет имя пользователя.

Имя пользователя проверяется на соответствие проверенным именам пользователей, хранящимся в KDC. Если имя пользователя знакомо, программа продолжится.

4. Выдача билета. Билет возвращается клиенту.

Сервер аутентификации отправляет клиенту два зашифрованных сообщения:

5. Клиент получает сеансовый ключ TGS.

Теперь клиент расшифровывает, message Aиспользуя секретный ключ клиента, предоставляя клиенту доступ к ключу сеанса TGS. Message Bхранится локально в зашифрованном состоянии.

6. Клиент запрашивает доступ к службе с сервера

Теперь клиент отправляет обратно два сообщения:

7. Сервер проверяет службу.

Затем TGS проверяет, существует ли служба запросов в KDC. Если это так, программа продолжается.

8. Сервер получает сеансовый ключ TGS.

Теперь сервер получает все еще зашифрованные message Bотправленные message C. Message B(TGT) затем расшифровывается с использованием секретного ключа TGS сервера, давая серверу сеансовый ключ TGS.

Теперь с помощью этого сеансового ключа TGS сервер может расшифровать message D.

Теперь у сервера есть отметка времени и имя из message Bи message D(сообщения аутентификатора). Сервер следит за тем, чтобы имена и временные метки совпадали, чтобы предотвратить мошеннические сообщения. Он также проверяет метку времени на соответствие времени жизни билета, чтобы убедиться, что время ожидания не истекло.

9. Сервер генерирует служебный сеансовый ключ.

Затем сервер генерирует случайный ключ сеанса службы и еще два сообщения.

10. Клиент получает ключ сеанса обслуживания.

Используя ключ сеанса TGS, кэшированный на шаге 5, клиент расшифровывает, message Fчтобы получить ключ сеанса службы.

11. Клиент связывается с Сервисом

Теперь клиент отправляет еще два сообщения, на этот раз службе:

12. Расшифровка сервисов Message G

Затем служба расшифровывает message Hсвой секретный ключ службы, чтобы получить ключ сеанса службы изнутри. С помощью этого ключа сервис расшифровывает message G.

13. Сервис проверяет запрос

Затем служба проверяет запрос, сравнивая имена пользователей, временные метки и время жизни из messages Gи H.

14. Сервис аутентифицируется для клиента.

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

15. Клиент проверяет услугу.

Затем клиент расшифровывает, message Iиспользуя ключ сеанса службы, кэшированный с шага 10. Затем клиент проверяет идентификатор и временные метки, содержащиеся в нем. Если оба соответствуют ожидаемым результатам, услуга считается безопасной.

16. Свободное общение между клиентом и службой

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

Можно ли взломать Kerberos?

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

Хакеры нашли 5 основных способов обойти систему Kerberos, основанных на нацеливании на уязвимые системные настройки, слабые пароли или распространение вредоносного вредоносного ПО. Давайте рассмотрим каждый из 5 типов атак:

Что изучать дальше

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

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

Источник