🔐Разбираемся в технологиях безопасной аутентификации |

🔐Разбираемся в технологиях безопасной аутентификации

Статьи

Технологии безопасной аутентификации

Существует несколько технологий, позволяющих повысить безопасность в части аутентификации пользователей. К ним относятся, например single sign-on (SSO) и различные службы аутентификации.

Single sign-on (SSO) или Технология единого входа

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

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

Несколько крупных интернет-провайдеров используют SSO, но только для своего собственного набора услуг и приложений. Например, пользователь Google может получить доступ ко всем функциям Google, таким как Gmail, Google Документы и электронные таблицы, Календарь и Фотографии, введя используя единое имя пользователя и пароль от учетной записи Google. Microsoft предлагает аналогичную услугу через Microsoft Account. Преимуществом использования единого имени пользователя и пароля является то, что настройки, сделанные на одном устройстве, автоматически синхронизируются со всеми другими устройствами. Однако эти SSO являются собственными и ограничены приложениями Google или Microsoft и не являются “объединенными” с другими организациями.

В настоящее время существует несколько технологий для систем федерации.

Название Описание Объяснение
OAuth (Open Authorization) Фреймворк федерации
с открытым исходным кодом
OAuth 2.0 – это основа для поддержки
разработки протоколов авторизации
Open ID Открытый стандарт децентрализованного
протокола аутентификации
Протокол аутентификации, который может быть использован в OAuth 2.0
в качестве стандартного средства для получения
идентификационных данных пользователя
Shibboleth Программное обеспечение с открытым исходным кодом
для проектирования SSO
Использует стандарты федерации для обеспечения SSO и
обмена атрибутами.

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

Службы аутентификации

Пользователь, имеющий доступ к компьютерной системе, должен предъявить удостоверение подлинности или идентификационные данные при входе в систему. Для обеспечения аутентификации могут использоваться различные службы. К ним относятся RADIUS, Kerberos, Terminal Access Control Access Control Systems (TACACS), службы каталогов, язык Security Assertion Markup Language и фреймворковые протоколы аутентификации.

RADIUS

RADIUS, или Remote Authentication Dial-In User Service, был разработан в 1992 году и быстро стал промышленным стандартом широко поддерживаемый почти всеми производителями сетевого оборудования. Изначально RADIUS был разработан для удаленного доступа к корпоративной сети. Однако сейчас слово “удаленный” в названии RADIUS является практически ошибочным термином, поскольку аутентификация RADIUS используется не только для подключения к удаленным сетям. С развитием системы безопасности портов IEEE 802.1x для проводных и беспроводных локальных сетей, RADIUS стал использоваться еще шире.

Клиент RADIUS – это не устройство, запрашивающее аутентификацию, как например, стационарный компьютер или ноутбук с беспроводной связью. Напротив, клиент RADIUS обычно является устройством, таким как беспроводная точка доступа (AP) или сервер сетевого доступа, который отвечает за отправку учетных данных пользователя и параметров соединения в форме сообщения RADIUS на сервер RADIUS. Сервер RADIUS проверяет подлинность и авторизует запрос клиента RADIUS и отправляет ответ в виде сообщения RADIUS.

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

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

 

  1. Беспроводное устройство, называемое запрашивающим устройством (оно формирует “запрос” на доступ), посылает запрос в точку доступа (access point – AP), запрашивая разрешение на присоединение к беспроводной сети.
  2. Точка доступа (AP), выступающая в качестве аутентификатора, который принимает или отклоняет беспроводное устройство, создает из этой информации пакет данных, называемый запросом аутентификации. Этот пакет включает такую информацию, как идентификация конкретной точки доступа, которая отправляет запрос аутентификации, а также имя пользователя и пароль. Для защиты от подслушивания точка доступа (действующая как клиент RADIUS) шифрует пароль перед отправкой на сервер RADIUS. Запрос на аутентификацию отправляется по сети от точки доступа к серверу RADIUS. Эта коммуникация может осуществляться как по локальной, так и по глобальной сети. Это делает возможность RADIUS-клиентам быть удалёнными от RADIUS-сервера. Если сервер RADIUS недоступен, точка доступа может перенаправить запрос в локальную сеть на альтернативный сервер.
  3. При получении запроса на аутентификацию сервер RADIUS сначала проверяет, что запрос исходит от согласованной точки доступа, а затем расшифровывает пакет данных для доступа к информации об имени пользователя и пароле. Эта информация передается в соответствующую базу данных пользователей. Это может быть текстовый файл, файл паролей UNIX, проприетарная система безопасности или пользовательская база данных.
  4. Если имя пользователя и пароль указаны правильно, сервер RADIUS отправляет подтверждение аутентификации которое включает в себя информацию о сетевой системе пользователя и условиях подключения. Например, сервер RADIUS может сообщить точке доступа, что пользователю необходим TCP/IP. Подтверждение может даже содержать в себе информацию о настройках фильтрации для ограничения доступа пользователя к определенным ресурсам в сети.
  5. Если имя пользователя и пароль неверны, сервер RADIUS отправляет на точку доступа сообщение об отказе в аутентификации, и пользователю отказывают в доступе к сети. Чтобы гарантировать, что на запросы не ответят неавторизованные лица или устройства в сети, сервер RADIUS отправляет ключ аутентификации, или подпись, идентифицирующую себя клиенту RADIUS.
  6. Если сервером RADIUS поддерживается accounting (управление учетных записей) – то в базу данных заноситься запись.
  7. Как только информация сервера получена и проверена точкой доступа, она предоставляет доступ в беспроводной сети пользователю в соответствующей конфигурации.

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

Kerberos

Kerberos – это система аутентификации, разработанная Массачусетским технологическим институтом (MIT) в 1980-х годах и используемая  для проверки подлинности пользователей в сети. Протокол назван в честь трехголового пса из греческой мифологии, который охранял ворота Аида. Для обеспечения безопасности Kerberos использует шифрование и аутентификацию.Kerberos функционирует под различными ОС, такими как Windows, macOS и Linux.

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

Terminal Access Control Access Control System+

Подобно RADIUS, Terminal Access Control Access Control System (TACACS) – это служба аутентификации, обычно используемая на устройствах UNIX, которая взаимодействует путем передачи информации об аутентификации пользователя на централизованный сервер. Централизованный сервер может быть либо базой данных TACACS, либо базой данных, такой как файл паролей Linux или UNIX с поддержкой протокола TACACS. Первая версия называлась просто TACACS, а более поздняя версия, представленная в 1990 году, была известна как Extended TACACS (XTACACS). Текущая версия – TACACS+.

Имеется несколько различий между TACACS+ и RADIUS. Они приведены в таблице ниже.

Особенность RADIUS TACACS+
Транспортный протокол UDP TCP
Аутентификация и авторизация объединенная разделенная
Коммуникация Незашифрованная Зашифрованная
Взаимодействие с Kerberos нет да
Может проверять подлинность сетевых устройств нет да

Служба каталогов

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

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

Security Assertion Markup Language (SAML)

Security Assertion Markup Language (SAML)- это стандарт XML, который позволяет веб-доменам защищено обмениваться данными аутентификации и авторизации пользователей. Этот подход позволяет хранить учетные данные пользователя у одного поставщика идентификационных данных пользователей вместо того, чтобы хранить их на сервере каждого поставщика веб-услуг.

SAML широко используется для онлайн-транзакций электронной коммерции между предприятиями бизнес ту бизнес (B2B) и между бизнесом и потребителями (B2C). Этапы транзакции SAML, показанные на рисунке ниже, следующие:

  • Пользователь пытается зайти на веб-сайт поставщика услуг, который требует ввода имени пользователя и пароля.
  • Поставщик услуг генерирует запрос SAML-аутентификации, который затем кодируется и встраивается в URL-адрес.
  • Поставщик услуг отправляет в браузер пользователя URL-адрес перенаправления, содержащий закодированный запрос SAML-аутентификации, который затем отправляется провайдеру идентификации.
  • Провайдер идентификации декодирует запрос SAML и извлекает встроенный URL-адрес. Затем поставщик идентификационных данных пытается аутентифицировать пользователя либо путем запроса учетных данных для входа в систему, либо путем проверки наличия действующих файлов cookie сессии.
  • Провайдер идентификации генерирует ответ SAML, содержащий имя пользователя, прошедшего аутентификацию, которое затем подписывается цифровой подписью.
  • Партнер по идентификации кодирует ответ SAML и возвращает эту информацию браузеру пользователя.
  •  Внутри ответа SAML имеется механизм, позволяющий браузеру пользователя переслать эту информацию обратно поставщику услуг, либо отображая форму, требующую от пользователя нажатия кнопки Submit, либо путем автоматической отправки поставщику услуг.
  • Поставщик услуг проверяет ответ SAML с помощью открытого ключа поставщика идентификационных данных. Если ответ успешно проверен, пользователь входит в систем

    SAML работает с различными протоколами, включая Hypertext Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), и протокол передачи файлов (FTP)

    В концепции IEEE 802.1x обмен данными между клиентом, аутентификатором и сервером аутентификации долен быть безопасным. Фреймворк для передачи протоколов аутентификации известен как расширяемый протокол аутентификации (Extensible Authentication Protocol ) – EAP

    Протоколы структуры аутентификации В конфигурации IEEE 802.1x связь между доверенным лицом, аутентификатором и сервером аутентификации должна быть безопасной. Фреймаворк для передачи протоколов аутентификации известна как расширяемый протокол аутентификации (EAP). EAP был создан как альтернатива менее защищенному протокола аутентификации Challenge-Handshake Authentication Protocol (CHAP), а также версия CHAP от Microsoft (MS-CHAP), и Password Authentication Protocol (PAP).

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

    Пакет EAP содержит поле, указывающее на функцию пакета (например, ответ или запрос), и поле идентификатора, используемое для сопоставления запросов. поле, используемое для сопоставления запросов и ответов. Пакеты ответа и запроса также имеют поле, которое указывает на тип передаваемых данных (например, протокол аутентификации). данных (например, протокол аутентификации), а также сами данные.

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