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

Статьи

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

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

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

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

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

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

Источник

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

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

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

Использование многофакторной аутентификации непременно снижает риски компрометации аутентификационных данных клиента. Применение одноразовых паролей (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.

Источник

Шенген в цифровом мире. Blitz Identity Provider — единый сервер аутентификации

Содержание статьи

Постановка задачи

Сперва определимся, что нам нужно для полного счастья, а затем попробуем подобрать решение. В идеале у него должны быть:

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

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

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

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

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

На тестовом стенде начального уровня ПО Blitz Identity Provider устойчиво функционирует при нагрузке 1700 запросов в секунду, обеспечивая среднее время отклика одной операции в 70 мс (95% запросов имели отклик менее 200 мс). На протяжении 8-часового тестового цикла не было зафиксировано ни одного неуспешного запроса.

Немаловажен и дизайн — пользовательские страницы должны выглядеть привлекательно, а у администратора должна быть возможность легко изменить тему оформления и редактировать ее.
Как видишь, требований достаточно много, но, к счастью, подходящее решение есть — Blitz Identity Provider от РЕАК СОФТ.

Досье

РЕАК СОФТ известны как команда программистов, разработавших Единую систему идентификации и аутентификации (ЕСИА) сайта gosuslugi.ru. Сейчас в этой системе зарегистрировано более 40 миллионов аккаунтов. Возможно, там есть и ты, наш читатель, и, возможно, ты использовал эту систему для доступа к каким-либо из более 1000 подключенных к ЕСИА сайтов.

Основные возможности Blitz Identity Provider

Сервер аутентификации Blitz Identity Provider эффективно решает задачу защиты пользовательских учетных записей. Также он предоставляет готовые (и при этом гибко настраиваемые под заказчика) функции защиты учетных записей:

Данный продукт идеально подходит для решения нескольких задач: обеспечить пользователям доступ к интернет-сервисам компании и контролировать доступ сотрудников к ресурсам своей организации. Также Blitz Identity Provider можно использовать в качестве интеграционной платформы для подключения приложений организации и ее филиалов к LDAP и серверам Microsoft Active Directory.

Как работает Blitz Identity Provider

Типичная схема развертывания Blitz Identity Provider изображена на рис. 1. Разберемся, что есть что. Как видишь, есть приложения и есть сервер аутентификации, к которому обращаются пользователи для получения доступа к приложениям. Сервер аутентификации обеспечивает все основные функции: саму аутентификацию, сервисы самообслуживания (регистрация, личный кабинет, восстановление доступа), а также предоставляет консоль управления. Опционально могут быть использованы хранилище учетных записей, SMTP-сервер и SMS-шлюз.

В качестве хранилища можно взять существующее хранилище на основе LDAP или Microsoft Active Directory либо иную систему хранения учетных записей и паролей (в этом случае потребуется разработка REST-сервисов, обеспечивающих возможность интеграции Blitz Identity Provider и хранилища учетных записей).

Рис. 1. Схема развертывания Blitz Identity Provider

Консоль управления

В разделе «Приложения» консоли управления настраиваются твои приложения, которым нужна аутентификация (рис. 2). На рис. 3 показан пример конфигурации одного из приложений с помощью протокола SAML — нужно ли шифровать и подписывать идентификаторы и утверждения, какие атрибуты пользователя должны использоваться и так далее.

Рис. 2. Список настроенных приложений

Рис. 3. Пример конфигурации приложения

Раздел «Хранилище» позволяет добавить новое хранилище. Сейчас сконфигурировано два хранилища — встроенное и LDAP (рис. 4). Сконфигурировать доступные методы аутентификации можно в разделе «Аутентификация». Ненастроенные методы отмечаются желтым (рис. 5). Поддерживается много разных методов:

В этом же разделе («Аутентификация») задается максимальная продолжительность сессии и продолжительность сессии при бездействии пользователя.

Рис. 4. Настройка хранилища

Рис. 5. Доступные методы аутентификации

Внешние поставщики идентификации настраиваются в разделе «Поставщики идентификации». Именно здесь можно настроить идентификацию посредством Google, Facebook, VK, ЕСИА.

Рис. 6. Внешние поставщики идентификации

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

Рис. 7. Сервисы самообслуживания

Ранее мы говорили о том, что сервер аутентификации должен поддерживать темы оформления, чтобы предоставляемые им сервисы (регистрация, личный кабинет, восстановление доступа) можно было «вписать» в дизайн сайта. Тему оформления можно выбрать в разделе «Внешний вид».

Рис. 8. Выбор темы оформления

Что видит пользователь

А теперь посмотрим, что видит пользователь. Типичная страница входа показана на рис. 9. Можно войти как по обычному паролю, так и через Facebook и другие социальные сети. Также доступен вход через филиал в Санкт-Петербурге — доступные внешние источники идентификации настраиваются в разделе «Поставщики идентификации» (рис. 6).

Рис. 9. Типичная страница входа

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

Рис. 10. Личный кабинет

В разделе «Безопасность» можно сменить пароль, настроить привязку к учетным записям в социальных сетях, а также настроить подтверждение входа (рис. 11). Поддерживаются различные способы подтверждения, в том числе популярная нынче доставка SMS-кодов подтверждения доступа.

Рис. 11. Подтверждение входа

Рис. 12. Подключенные социальные сети

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

Рис. 13. Вход через Facebook

Дорого?

Смотришь на все это, и создается впечатление, что такое решение должно стоить дорого. Отнюдь. Есть две редакции продукта: Standard Edition и Enterprise Edition. Так вот, Standard Edition для некоммерческого использования бесплатна. Standard Edition можно свободно загрузить с сайта производителя. Существуют версии для Windows и Linux (Ubuntu, Debian, RHEL, CentOS).

Рис. 14. Страница загрузки Standard Edition

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

Стоимость Enterprise-версии можно узнать у партнеров компании РЕАК СОФТ.

Заключение

Пользователи могут входить в созданное тобой приложение и в другие приложения компании (о существовании которых ты даже можешь и не знать), используя учетную запись Blitz Identity Provider в качестве признаваемой всеми приложениями «визы». Пользователи избавлены от парольного хаоса. Больше не нужно иметь различные логины и пароли в каждом из приложений.

Система аутентификации Blitz Identity Provider существует не в вакууме — она стыкуется с аналогичными системами: системами идентификации социальных сетей, системой идентификации в корпоративном Kerberos-домене, партнерскими системами федеративного входа, удостоверяющими центрами и хранилищами учетных записей. С Blitz Identity Provider ты конструируешь свое собственное Шенгенское соглашение, определяешь пространство доверия и включаешь в него приложения, пользователей и механизмы аутентификации.

Источник