Организация единой аутентификации и удаленного доступа

65% российских компаний за удаленную работу

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

При этом 78% опрошенных в России (для сравнения, 65% в Италии, 59% в Великобритании) заявили, что они бы приобрели технологии, обеспечивающие работу сотрудников из дома, если бы у них была возможность сначала их испытать и оценить преимущества. Основными аргументами «за» отечественные компании считают снижение расходов.

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

Зададимся логичным вопросом: является ли технологическая неподготовленность основным препятствием на пути внедрения концепции дистанционной работы? Далеко не всегда. Наш вывод подтверждает следующий показатель: руководство большинства компаний (66% в России, 65% в Великобритании и в 61% в Италии) настаивает на том, что сотрудники должны находиться на рабочем месте в офисе каждый день.

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

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

Sso — однократная аутентификация для компании

Несмотря на простоту и высокую степень защиты, SSO обеспечивает максимальную защиту только в том случае, когда инженеры корректно ее настраивают, c чем инженеры Cloud Networks смогут помочь.

SSO имеет следующие особенности:

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

Среди компаний, которые применяют SSO, пользуясь нашими услугами, — ВТБ, X5 Retail Group, СУЭК, Ростелеком, TatNeft, РОСНАНО, СОГАЗ и многие другие. Благодаря технологии единого входа повышается безопасность, а высвобожденные временные ресурсы направляются на решение профильных задач.

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

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации
two-factor authentication
(2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

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

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Организация единой аутентификации и удаленного доступа
Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

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

Аутентификация по паролям и цифровым сертификатам

Для подключения удалённого рабочего места пользователя к корпоративной сети организации необходимо установить на компьютер сотрудника CSP VPN Client. Данное ПО предназначено для обеспечения защищенного сетевого взаимодействия с использованием российской криптографии в рамках международного стандарта IPsec.

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

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

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

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

Наиболее распространённым и безопасным вариантом подключения к корпоративной сети при использовании упомянутого CSP VPN Client является предварительное размещение в защищённой памяти ключа eToken закрытого ключа пользователя и политик безопасности (опционально).

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

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

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем
Single Sign-On
(SSO), где одно приложение (
service provider
или
relying party
) делегирует функцию аутентификации пользователей другому приложению (
identity provider
или
authentication service
). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение
доверяет
функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.На общем уровне, весь процесс выглядит следующим образом:

Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
Клиент аутентифицируется в SP-приложении при помощи этого токена.

Организация единой аутентификации и удаленного доступа
Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем.

Организация единой аутентификации и удаленного доступа
Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

Токен был выдан доверенным identity provider приложением (проверка поля issuer).
Токен предназначается текущему SP-приложению (проверка поля audience).
Срок действия токена еще не истек (проверка поля expiration date).
Токен подлинный и не был изменен (проверка подписи).

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

Варианты аутентификации

При аутентификации пользователей сети удалённого доступа обычно используются следующие варианты:

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

Похожее: OAuth : что это такое, как убрать

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

Сведём основные плюсы и минусы указанных методов в таблицу:

Таблица 1. Преимущества и недостатки различных методов аутентификации

Метод аутентификации	Преимущества	Недостатки
Pre-shared key	Простота технического решения	Сложность в использовании технически неподготовленным сотрудником, низкая масштабируемость системы, требуется доверенный канал для распространения ключей, неприемлемо низкий уровень безопасности
Цифровой сертификат с закрытым ключом, хранящимся на компьютере	Простота управления (создание, распространение, отзыв сертификатов), масштабируемость системы	Требуется наличие инфраструктуры открытых ключей (PKI, Public Key Infrastructure), дополнительные эксплуатационные расходы, низкая мобильность пользователя в силу «привязки» сертификата к конкретному компьютеру
Цифровой сертификат с закрытым ключом, хранящимся в памяти токена	Простота управления (создание, распространение, отзыв сертификатов), масштабируемость системы, простота использования, высокий уровень обеспечиваемой безопасности, возможность использования однократной аутентификации (Single Sign-On)	Требуется наличие инфраструктуры открытых ключей (PKI), дополнительные эксплуатационные расходы и затраты на токены
Цифровой сертификат и одноразовый пароль	Простота управления (создание, распространение, отзыв сертификатов), масштабируемость системы, увеличение стойкости	Требуется наличие инфраструктуры открытых ключей (PKI) , инфраструктуры аутентификации (TACAS или RADIUS), высокие эксплуатационные расходы, дополнительные затраты на устройства и наличие

В зависимости от структуры сети, аутентификация пользователя при доступе к ресурсам и приложениям может выполняться на шлюзе внешнего или внутреннего периметра, а также внутри него. Многократное прохождение процедуры аутентификации не слишком удобно, в связи с чем, широкое распространение получили методы сквозной аутентификации Single Sign-On (SSO).

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

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

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

Взаимодействие фронта с микросервисами. axios

Для взаимодействия с микросервисами будем использовать библиотеку AXIOS.

Поскольку у нас будут 2 типа запросов:авторизированные (для работы с микросервисами) и неавторизированные (для самой авторизации и refresh токена) – для каждого типа запроса будем использовать отдельный инстанс axios.

Итак, создадим утилитарный класс с нашими axios – AxiosInstance.js и добавим в него экземпляр axios для авторизированных запросов:

export const axiosInstance = axios.create({
    headers: { Authorization: `Bearer ${getToken()}` }
});

Здесь мы добавили в заголовок параметр авторизации со значением – bearer-token. Он будет посылаться в каждом запросе.

Кроме того, перед каждым запросом с фронта нам придется проверять валидность токена и, в случае если он невалиден (истек срок действия например) – делать его refresh. После этого в запросе уйдет уже обновленный валидный token.

Итак, добавим вызов метода verifyToken в axios request interceptor:

axiosInstance.interceptors.request.use(request => {
    verifyToken().catch(() => refreshToken(getRefreshToken()));
    return request;
});

В случае, если токен невалиден, метод кидает исключение, в обработке которого вызываем обновление токена методом refreshToken, а в качестве его аргумента передаем refresh_token который хранится в нашем localStorage и доступный через утилитарный метод getRefreshToken.

Теперь осталось только проверить статус ответа в авторизированных запросах. Сделаем это через axios response interceptors:

axiosInstance.interceptors.response.use(response => {
    if (response?.headers?.authorization) {
        setToken(response.headers.authorization);
    }
    return response;
}, error => {
    if (error?.response?.status === 401) {
        logout();
    }
    return Promise.reject(error);
});

Всё хорошо?

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

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

Делегирование полномочий

Давайте попробуем создать отдельный модуль. Назовём его совершенно бесхитростно — security.php, и оформим как отдельный скрипт. Будем подключать его ко всем закрытым страницам нашего проекта в самом начале. Внутри этого файла будем анализировать некие условия, а по итогам его работы выставлять специальный флаг в 0 или 1. Пусть этот флаг будет храниться в переменных сессии (массив $_SESSION в PHP).

Что нам это даёт? Мы можем запихать в этот скрипт сколь угодно хитрую логику, вплоть до анализа последних действий пользователя и добавления его в бан-лист по IP, либо блокировки его аккаунта на тот или иной срок. Но сперва реализуем очень базовую функциональность: будем сверять значение хэша, пришедшего из куки, с тем, что должно было бы получиться, если хэш не был искажён. Сервер знает IP, знает юзер-агент, знает пароль текущего пользователя… Кажется, всё готово!

Как быть?

Очевидно, с этим надо что-то делать. Да, можно сразу бежать покупать сертификат и подключать SSL. Но можно сделать кое-что ещё до этого, и существенно снизить тем самым необходимость в нём. В конце концов, в том же ВКонтакте SSL стал принудительным всего полгода назад, а до этого как-то ведь жили.

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

Можно пойти дальше, и при создании хэша использовать юзер-агент. Теперь взломщику придётся использовать браузер той же версии, что и у нас (а в случае с IE ещё и с тем же набором плагинов тех же самых версий, что выходит уж очень маловероятно, особенно если взломщик не догадался подсмотреть юзер-агент).

Модели и средства аутентификации пользователей в корпоративных системах управления и облачных вычислениях

_Доклады БГУИР_

2022 № 3 (97)

УДК 004.732.056(075.8)

МОДЕЛИ И СРЕДСТВА АУТЕНТИФИКАЦИИ ПОЛЬЗОВАТЕЛЕЙ В КОРПОРАТИВНЫХ СИСТЕМАХ УПРАВЛЕНИЯ И ОБЛАЧНЫХ ВЫЧИСЛЕНИЯХ

В.А. ВИШНЯКОВ, М.М. ГОНДАГ САЗ

Белорусский государственный университет информатики и радиоэлектроники П. Бровки, 6, Минск, 220600, Беларусь

Поступила в редакцию 15 декабря 2022

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

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

Введение

Идентификация позволяет субъекту, процессу, действующему от имени определенного пользователя назвать себя (сообщить свое имя). Посредством аутентификации вторая сторона убеждается, что субъект действительно тот, за кого он себя выдает. Аутентификация бывает односторонней (клиент доказывает свою подлинность серверу) и двусторонней [1, 2]. Субъект может подтвердить свою подлинность, предъявив одну из следующих сущностей: что он знает (пароль, личный идентификационный номер, криптографический ключ и т. п.); чем он владеет (личную карточку или иное устройство аналогичного назначения); нечто, что есть часть его самого (голос, отпечатки пальцев и т. п., то есть свои биометрические характеристики) [1, 2].

В основе одного протокола аутентификации (секретный ключ) лежит принцип, применяемый во многих протоколах: одна сторона посылает другой случайное число, которое другая сторона преобразует особым образом и возвращает результат. Второй протокол, позволяющий не встречавшимся ранее людям устанавливать общий секретный ключ, называется протоколом обмена ключами Диффи-Хеллмана (Diffie-Hellman key exchange). Третий подход состоит в организации доверительного центра распространения ключей (KDC, key distribution center). При такой схеме у каждого пользователя всего один ключ, общий с KDC. Взаимная аутентификация также может выполняться с помощью шифрования с открытым ключом [1, 2].

В работе протокола Kerberos, помимо рабочей станции (РС), принимают участие еще три сервера [3]: сервер аутентификации (AS, Authentication Server): проверяет личность пользователей при входе в сеть; сервер выдачи билетов (TGS, Ticket Granting Server): выдает «билеты, подтверждающие подлинность»; сервер, предоставляющий услуги РС [1, 2].

1. Использование стандартных паролей. Эта схема является наиболее уязвимой с точки зрения безопасности – пароль может быть перехвачен и использован другим лицом.

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

3. Контрольные суммы используются при создании резюме фиксированной длины для представления длинных сообщений.

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

Если рассматривать аутентификацию пользователя с точки зрения возможности реализации угрозы по перехвату и использованию «ключа» злоумышленником, получено распределение и значение весомости по риску реализуемости угрозы [3]: перехват стандартных паролей 0,5 – возможность реализации угрозы средняя 0,3 < Y < 0,6; перехват S/key паролей 0,35 — возможность реализации угрозы средняя 0,3 < Y < 0,6; контрольные суммы 0,75 — возможность реализации угрозы высокая 0,6 < Y < 0,8; перехвата электронной цифровой подписи 0,25 — возможность реализации угрозы низкая 0 < Y < 0,3. Весомости каждого показателя: использование стандартных паролей — 0,27; S/Key (одноразовые пароли) — 0,18; контрольная сумма — 0,41; электронная подпись — 0,14.

Похожее: php - Отсутствует заголовок авторизации с использованием JWT -

Идентификация пользователей компьютерных систем по динамике подсознательных движений с использованием альтернативных сценариев авторизации состоит из 2-х этапов: ввод парольной фразы на клавиатуре и ввод подписи при помощи графического планшета [4]. Алгоритм подразумевает 4 варианта окончания процедуры идентификации: 1) авторизация в соответствии с правами учетной записи пользователя (пользователь «свой» и он идентифицирован); 2) авторизация с правами ограниченной учетной записи, предусмотренной для таких случаев (пользователь «свой», но есть сомнения в том, кем он является); 3) отказано в доступе (есть сомнения, что пользователь «свой» и/или кем он является, либо уже на первом этапе очевидно, что пользователь – «чужой»); 4) «обманный» доступ (нет сомнений, что субъект является нарушителем). Механизмы аутентификации можно рассмотреть по приоритету их использования: основные — при штатном входе в систему, резервные (почтовый ящик) — при потере пароля либо взломе учетной записи, последние (last resort) — при вмешательстве администрации ИС. Наибольшие результаты в проблему социальной идентификации внесли три коллектива исследователей: RSA Laboratories, Microsoft, Fasebook [5].

Методика и алгоритм аутетификации в КИС

Современные корпоративные информационные системы (КИС) могут включать использование сред облачных вычислений (ОВ), так называемые интегрированные КИС (ИКИС). Вопросы исследования работы пользователей в ИКИС являются актуальными [6]. Потому рассмотрим два подхода аутентификации. В работе [5] представлена модель аутентификации, базирующаяся на трех классах объектов: S — ИС с подсистемой разграничения доступа, реализующей технологию аутентификации с помощью доверенных лиц, назовем ее СА; User — пользователь, имеющий учетную запись в S; Voucher — поручитель, способный подтвердить личность пользователя. В процессе аутентификации поручители должны подтвердить личность пользователя в СА. Выбор модели обусловлен ее простотой реализации в ИКИС.

Рассмотрим модификацию этой модели. Она включает КИС, пользователей, поручителей и множества аутентификаторов. Обозначим: ai = {e’o, e’i.e’n} — аутентификатор, где eo — владелец; {ei,…en} — множество лиц, которым известен этот аутентификатор. A = {a1,…, aN}; Pr(x) {x = e’o} — функция, определяющая аутентификаторы, для объекта х; Kn(x) — функция, определяющая аутентификаторы, известные объекту х, но не принадлежащие ему. Обозначим неизвестные величины: Pv — вероятность успешной аутентификации на основании оценок v.

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

F(User, Voucherk, a’) = {1, if (User(a’), Vouchen(a)) С [kmin, kmcix]},

F(User, Voucherk, a’) = {0, if (User(a), Vouchen(a)) Сф [kmin, kmax] }.

Модифицированный алгоритм аутентификации имеет следующий вид.

1. Пользователь проходит проверку с вероятностью pi, после чего посылает в центр аутентификации (ЦА) идентификатор своей учетной записи, которую надо восстановить User {Log} ^ CA.

2. ЦА генерирует временную учетную запись (ВрУЗ), передает пользователю логин Ns и пароль Pat. В качестве логина выступает номер восстановления пароля (НВП) путем добавления числа в диапазоне [2—5] к предыдущему НВП: Ns = Ns ran [2-5]; CA ^ { Ns, Pat} ^ User;

User — пользователь; Voucherk — k-ый поручитель, способный подтвердить личность пользователя; Zk =(Pr(User)UKn(User))n(Pr(Voucherk)UKn(Voucherk)) — множество аутентификаторов, которые используются для проверки пользователя k-м поручителем.

3. ЦА определяет время модерации tp и разницу между последней сменой пароля пользователем Tr и моментом создания новой записи ВрУЗ To. Если To > tp Tr, ЦА высылает пользователю сообщение об этом, ждет ответа о прекращении процедуры восстановления пароля, получив его, прекращает работу с ним.

4. Если ответа пользователя не последовало или tp Tr > To, то ЦА передает пользователю перечень ников из списка поручателей, содержащий имена, каналы связи, отношения с пользователем и объем общения с поручателем.

5. ЦА рассылает всем поручителям из списка сообщение связаться с пользователем и получить его НВП и методику проверки личности пользователя.

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

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

8. Получив эту информацию, ЦА вычисляет компетентность k-го поручителя nk, (выступает экспертом), которая зависит от перечня вопросов для проверки пользователя. В ЦА имеется множество нечетких количественных мер у, учитывающих компетентность поручителей. Эта мера используется для борьбы с атаками злоумышленников.

9. Общая оценка равна Е = min у. Если общая компетентность поручителей (сумма их оценок) превышает минимальный (ngr) вес поручителей > ngr, и общая оценка компетенции превышает границу доверия E > Egr , аутентификация успешно пройдена. ЦА высылает пользователю его ВрЗУ, новый пароль учетной записи СА ^ {Passnew} ^ User.

Аутентификация пользователей в среде облачных вычислений

В работе [7] представлены элементы подхода для безопасной работы пользователей в среде ОВ. Участники взаимодействий: пользователь (пользователями могут быть физические лица и организации), аутентификатор подлинности (Trusted Authenticator — TA), облачный провайдер услуг (Cloud Service Provider — CSP), цифровая подпись (Digital Signature — DS), агент CSP’s. Ниже представлены функции элементов данного подхода.

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

2. TA устанавливает соединение с органом аутентификации. Задача TA в облачной среде — обеспечить пользователю безопасный доступ к облачным сервисам через поставщика услуг.

3. Облачный провайдер услуг (CSP). Облачный сервис может динамически масштабироваться для удовлетворения потребностей пользователей, потому что поставщик услуг предоставляет необходимое для обслуживания оборудование и программное обеспечение.

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

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

Расширим эту модель: Х — пользователь, У — аутентификатор подлинности. Для описания введем обозначения: tx — временная метка, rx, ry — случайные числа Х и У соответственно; Sx, Sy — подписи, сгенерированные Х и У; Ско*, Скоу — сертификаты открытого ключа Х и У. Приведем алгоритмы аутентификации.

1. Односторонняя аутентификация с применением меток времени: Х ^ У: Ско*, tx, Ix, Sx(tx, Ix).

После принятия сообщения аутентификатор подлинности проверяет правильность метки времени tx, полученный идентификатор Ix и, используя открытый ключ из сертификата Ско*, корректность цифровой подписи Sx(tx, Ix).

2. Односторонняя аутентификация с применением случайных чисел: У ^ Х, Гу У (1); Х^ У: Скох, Гх, 1у, Sx(гx, Гу, 1Х) У (2).

Атентификатор подлинности направляет пользователю Х случайное число Гу на основании сообщения от Х. Используя открытый ключ Х из сертификата Скох, У проверяет корректность подписи Sx(Гx, Гу, IX) под числом Гх, числом Гу, полученным в первом сообщении, и его идентификатором 1Х.

3. Двухсторонняя аутентификация с применением случайных чисел: У ^ Х, Гу (1); У, Гx, SxX(гx, Гу, 1х) (2); У * X: СKсу, ^(гx, Гу, IX) (3).

В этом алгоритме обработка сообщений 1 и 2 выполняется как и в предыдущем, а сообщение 3 обрабатывается аналогично сообщению 2.

Заключение

В КИС используются следующие средства аутентификации: стандартные пароли, одноразовые пароли, аутентификации с использованием S/Key, контрольные суммы (при создании резюме фиксированной длины для представления длинных сообщений), электронные подписи (создаются шифрованием контрольной суммы и дополнительной информации при помощи личного ключа отправителя). Механизмы аутентификации можно рассмотреть по приоритету их использования: основные — при штатном входе в систему, резервные (почтовый ящик) — при потере пароля либо взломе учетной записи, последние (last resort) — при вмешательстве администрации информационной системы. Наибольшие результаты в проблему социальной идентификации внесли три коллектива исследователей: RSA Laboratories, Microsoft, Fasebook. Математическая модель модифицированной аутентификации в КИС позволяет по заданному числу неудовлетворительных оценок вычислить вероятность успешной аутентификации с использованием метода вычисления времени премодерации, позволяющего восстанавливать пароль как при его утере, так и при смене злоумышленником. Представлен модифицированный алгоритм на базе этой модели, позволяющий выполнять аутентификацию пользователей с привлечением поручителей.

AUTHENTIFICATION USER TOOLS IN CORPORATIVE INFORMATION SYSTEMS AND CLOUD COMPUTING AREAS

U.A. VISHNIAKOU, М.М. GONGAG SAS Abstract

Analysis elements of users work in information corporative systems (ICS) are done. The mathematical model of social authentification in ICS allows on given quality of unsatisfactory marks to calculate the probability of successful authentification with the use of time primoderatin calculating. It allows to restore the user password during losing and by villain exchanging. The modifying algorithm on this model base is reproduced which allows to execute user authentification on charger with attraction. The approach for save user activity in clouding computer area is done.

Список литературы

1. Афанасьев А.А., Веденьев Л.Т., Воронцов А.А. и др. Аутентификация. Теория и практика обеспечения безопасного доступа к информационным ресурсам. М., 2022.

2. КоноплевА.С. Метод контроля и управления доступом в распределенных вычислительных сетях: Автореф. дисс. … канд. техн. наук. СПб, 2022.

Похожее: Займы Mili (Мили) - Вход в личный кабинет

3. ВасильчукК.С. // Молодой ученый. 2022. № 4.2. С. 118-121.

4. Волокитина Е.С. Метод и алгоритмы гарантированного обезличивания и реидентификации субъекта персональных данных в автоматизированных информационных системах: Автореф. дисс. . канд. техн. наук. СПб, 2022.

5. МалковА.А. Технология аутентификации с помощью доверенных лиц: Автореф. дисс. … канд. техн. наук. Уфа, 2022.

6. Вишняков В.А. Информационное управление и безопасность: методы, модели, программно-аппаратные решения. Минск, 2022.

7. Гондаг С.М., Вишняков В.А. // Тез. докладов XIII Бел.-росс. НТК «Технические средства защиты информации». Минск, 2022. С. 29.

О соответствии требованиям регуляторов

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

При построении информационных систем, обрабатывающих персональные данные, в соответствии с законодательством необходимо использование российских криптографических алгоритмов: ГОСТ 28147-89 (шифрование), ГОСТ Р 34.11-94 (хеширование), ГОСТ Р 34.10-94, ГОСТ Р 34.

10-2001 (электронная цифровая подпись). В этом контексте важной особенностью решения Aladdin, Cisco и S-Terra CSP является возможность использования российской криптографии для аутентификации пользователей и защиты передаваемых данных. Недавно полученный компанией Aladdin Сертификат соответствия №1883 ФСТЭК России от 11 августа 2009 года распространяется на всю линейку электронных ключей eToken, включая новые модели на платформе eToken Java и программное обеспечение eToken PKI Client 5.1.

С получением данного сертификата eToken стал фактически единственным на российском рынке средством аутентификации и хранения ключевой информации, имеющим уровень доверия ОУД 2 и рекомендуемым для использования в информационных системах операторов персональных данных.

Компания S-Terra так же уделяет пристальное внимание вопросу соответствия своих продуктов требованиям регуляторов. В настоящее время получены сертификаты ФСТЭК как на модуль NME-RVPN, так и на программное обеспечение CSP VPN Client.

Предыстория

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

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

Решение на стыке технологий

Один из вариантов решения проблемы защищенного корпоративного взаимодействия при удалённой работе пользователей был представлен в рамках технологического проекта компаний Aladdin, Cisco и S-Terra. Совместное решение компаний объединило различные методы аутентификации, интегрированные инновационные решения для IP-телефонии, передачи данных, голоса, видео и решения для построения VPN-соединений.

В широкой продуктовой линейке средств построения безопасных сетевых соединений компании S-Terra особого внимания заслуживает модуль NME-RVPN. Данный аппаратный модуль может использоваться в составе маршрутизаторов серии Cisco® 2800 и 3800 Integrated Services Routers.

Устройство позволяет обеспечить эффективную маршрутизацию и защиту трафика данных, голоса, видео. При этом для управления им не требуется дополнительных интерфейсов – модуль NME-RVPN использует интерфейс Cisco для формирования правил маршрутизации и защиты сетевых взаимодействий.

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

В сценариях удалённого доступа ключи eToken могут использоваться не только для аутентификации пользователей. Так, например, в защищённой памяти ключа могут сохраняться политики безопасности самого VPN-клиента (см. Рис.1). Данные политики определяют права доступа пользователя и уровень его привилегий при подключении к корпоративной сети организации.

Сервис авторизации

Итак, первое что нужно для нашей задачи – сервис авторизации (далее auth server) осуществляющий авторизацию пользователей (предоставление access_token), продление токена (refresh_token) и валидацию токена. Сам сервис будет максимально простым и содержать минимум boilerplate кода, потому что большая его частьбудет переложена на “плечи” KeyCloak.

Поскольку сам auth server будет написан на Spring Boot, для его интеграции с KeyCloak будем использовать Spring Boot KeyCloak Adapter. Данное решение рекомендуют сами разработчики KeyCloak.

Стандартная реализация

Итак, сессия в PHP по умолчанию хранится в файле. Её id сохраняется в cookie (если куки отключены — задействуется механизм передачи через адресную строку, если это не отключено в конфигурации). Время жизни такой сессионной куки по умолчанию — до момента закрытия браузера (и обычно его никто не меняет).

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

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

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

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

Стандарты oauth и openid connect

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

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

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

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

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

Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).

Организация единой аутентификации и удаленного доступа
Взаимодействие компонентов в стандарте OAuth.

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

Стандарты ws-trust и ws-federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Страница авторизации

На странице авторизации создадим метод login и повесим его в качестве обработчика на кнопку «Войти».

AuthPage.js:

const login = async () => {
    await authenticate(credentials.login, credentials.password)
        .then(() => {
            window.location.href = '/';
        }).catch(() => setError(true));
};

Здесь мы вызываем созданный ранее метод authenticate, а в качестве обработчика успешного выполнения метода передаем редирект на корневой маппинг приложения (‘/’). В качестве обработчика ошибки выполнения метода передаем вызов функции setError, в моем случае – это просто установка хука error, означающего, что надо показать сообщение об ошибке.