Вход в личный кабинет Что такое аутентификация?
После идентификации производится аутентификация:
Аутентификация – это процедура проверки подлинности (пользователя проверяют с помощью пароля, письмо проверяют по электронной подписи и т.д.)
Чтобы определить чью-то подлинность, можно воспользоваться тремя факторами:
- Пароль – то, что мы знаем (слово, PIN-код, код для замка, графический ключ)
- Устройство – то, что мы имеем (пластиковая карта, ключ от замка, USB-ключ)
- Биометрика – то, что является частью нас (отпечаток пальца, портрет, сетчатка глаза)
https://www.youtube.com/watch?v=ixDmnU7–d8
Получается, что каждый раз, когда вы вставляете ключ в замок, вводите пароль или прикладываете палец к сенсору отпечатков пальцев, вы проходите аутентификацию.
Ну как, понятно, что такое аутентификация? Если остались вопросы, можно задать их в комментариях, но перед этим разберемся еще с одним термином.
Что такое авторизация?
Когда определили ID, проверили подлинность, уже можно предоставить и доступ, то есть, выполнить авторизацию.
Авторизация – это предоставление доступа к какому-либо ресурсу (например, к электронной почте).
Разберемся на примерах, что же это за загадочная авторизация:
- Открытие двери после проворачивания ключа в замке
- Доступ к электронной почте после ввода пароля
- Разблокировка смартфона после сканирования отпечатка пальца
- Выдача средств в банке после проверки паспорта и данных о вашем счете
1 Словесное описание решаемой задачи
Компания ОАО «ПьемЧай» ежедневно требует работы от миллиона сотрудников и сотни тысяч гостей. Все сотрудники пьют чай и в этом состоит их работа. В компании есть гости, которые пить чай не могут, для них доступны опции, которые позволяют им видеть какой чай они смогут пить на своей будущей работе, а так же лучших сотрудников года, месяца и недели.
Некоторые сотрудники в пандемию работают удаленно и доступ к чаю им предоставляет курьерская служба Кракен, прямо к точке доставки. Удаленные сотрудники могут получать чай только из той точки доставки, к которой они привязаны. Находясь в офисе они все равно могут пить чай как обычные сотрудники.
Что такое идентификация?
Сначала давайте прочитаем определение:
1 немного теории
Основной задачей авторизации доступа является разграничение доступа к целевому объекту на основании данных о субъекте, запрашивающем доступ, и свойствах объекта.
При проектировании любой системы авторизации следует обращать внимания на характеристики, описываемые ниже.
1 Время восстановления/энтропия входных параметров
Авторизация принимает решение о разграничении доступа на основе множества входных параметров. Если таковых будет слишком много, либо мерность множеств окажется слишком большой, то авторизация будет терять слишком много ресурсов на выполнение ненужных операций. Это как сортировать данные пузырьком и qsort. Не следует выполнять ненужные операции.
Если у вашей системы есть на входе A,B,C,D,E,F — факты о пользователе, то если вы будете объединять все в одно, то получите A * B * C * D * E * F комбинаций, которые невозможно эффективно кешировать. По возможности следует найти такую комбинацию входных, что бы у вас было A * B * C и D * E * F комбинаций, а еще лучше A * B, C * D, E * F, которые вы уже легко сможете вычислять и кешировать.
Эта характеристика очень важна так же для построения системы правил, которые будут предоставлять пользователям доступы.
2 Детализация авторизации
Второй характеристикой является предел детализации авторизации, когда дальнейшее разграничение доступа становится уже невозможным. Например вы можете разграничивать доступ к ручкам микросервиса, но уже не иметь возможности ограничить доступ к сущностям, которые она выдает. Либо доступ к сущности вы ограничиваете, но вот операции доступны все и всем. И т.д.
От того, насколько детально нужно работать авторизации зависит как время восстановления, так и энтропия входных данных, т.к. работать вам придется со все увеличивающимся массивом входных данных. Разумеется, если вы не предпринимаете попытки для того, что бы уровни детализации друг на друга влияли аддитивно, а не мультипликативно.
2 обобщенная модель данных
Прежде чем проектировать, необходимо договориться о терминах и структурах данных с их взаимосвязями.
Вы можете убрать ненужные вам связи, главное — это то, что вам необходимо ограничивать.
Детально опишем все имеющиеся определения с которыми будем дальше работать.
1 Пользователь
Субъект, чей доступ необходимо авторизовать.
Данное определение задает субъекты, которые могут быть как людьми, так и автоматическими системами, которые получают доступ к вашим ресурсам. У любого пользователя могут быть свои роли, разрешения и группы.
10 О кешировании данных
Основной проблемой при работе авторизации является точка в которой необходимо кешировать результаты, что бы работало быстрее все, да еще желательно так, что бы нагрузка на ЦПУ не была высокой. Вы можете поместить все ваши данные в память и спокойно их читать, но это дорогое решение и не все готовы будут себе его позволить, особенно если требуется всего лишь пара ТБ ОЗУ.
Правильным решением было бы найти такие места, которые бы позволяли с минимальными затратами по памяти давать максимум быстродействия.
Предлагаю решить такую задачу на примере ролей пользователя и некоего микросервиса, которому нужно проверять наличие роли у пользователя. Разумеется в данном случае можно сделать карту (Пользователь, Роль) -> Boolean. Проблема в том, что все равно придется на каждую пару делать запрос на удаленный сервис.
Даже если вам данные будут предоставлять за 0,1 мс, то ваш код будет работать все равно медленно. Очевидным решением будет кешировать сразу роли пользователя! В итоге у нас будет кеш Пользователь -> Роль[]. При таком подходе на какое-то время микросервис сможет обрабатывать запросы от пользователя без необходимости нагружать другие микросервисы.
Разумеется читатель спросит, а что если ролей у пользователя десятки тысяч? Ваш микросервис всегда работает с ограниченным количеством ролей, которые он проверяет, соответственно вы всегда можете либо захардкодить список, либо найти все аннотации, собрать все используемые роли и фильтровать только их.
Полагаю, что ход мыслей, которому стоит следовать, стал понятен.
2 Сервис
Множество ресурсов объединенных в единое целое, как пример сервис проектов.
В рамках микросервисной архитектуры основным направлением разработки является выделение таких множеств ресурсов, которые можно назвать сервисом, так что бы программно-аппаратная часть могла эффективно обрабатывать заданный объем данных.
3 Ресурс
Единичный объем информации для работы авторизации, например проект.
В рамках сервиса могут существовать ресурсы, доступ к которым необходимо ограничивать. Это может быть как файл в облачном сервисе, так и заметка, видимая ограниченному кругу лиц.
4 Разрешение
Право пользователя выполнять операцию над сервисом и/или ресурсом.
5 Роль
Множество разрешений, по сути под словом роль всегда подразумевается множество разрешений.
Следует отметить, что в системе может не быть ролей и напрямую задаваться набор разрешений для каждого пользователя в отдельности. Так же в системе могут отсутствовать разрешения (речь про хранение их в виде записей БД), но быть роли, при этом такие роли будут называться статичными, а если в системе существуют разрешения, тогда роли называются динамическими, так как можно в любой момент поменять, создать или удалить любую роль так, что система все равно продолжит функционировать.
Ролевые модели позволяют как выполнять вертикальное, так и горизонтальное разграничение доступа (описание ниже). Из типа разграничения доступа следует, что сами роли делятся на типы:
Но отсюда следует вопрос, если у пользователя есть глобальная роль и локальная, то как определить его эффективные разрешения? Поэтому авторизация должна быть в виде одной из форм:
Подробное описание использования типа ролей и формы авторизации ниже.
Роль имеет следующие связи:
Следует отметить, что реализация статичных ролей требует меньше вычислительных ресурсов (при определении эффективных разрешений пользователя будет на один джойн меньше), но вносить изменения в такую систему можно только релизным циклом, однако при большом числе ролей гораздо выгоднее использовать разрешения, так как чаще всего микросервису нужно строго ограниченное их число, а ролей с разрешением может быть бесконечное число. Для больших проектов, стоит задуматься о том, что бы работать только с динамическими ролями.
6 Группа
Используя группы можно объединить множество ресурсов, в том числе расположенных в разных сервисах в одно целое, и управлять доступом к ним используя одну точку. Это позволяет гораздо проще и быстрее реализовывать предоставление доступа пользователя к большим массивам информации, не требуя избыточных данных в виде записи на каждый доступ к каждому ресурсу по отдельности вручную или автоматически. По сути вы решаете задачу предоставления доступа к N ресурсам создавая 1 запись.
Группы используются исключительно для горизонтального разграничения доступа (описание ниже). Даже если вы будете использовать группы для доступа к сервисам, то это все равно горизонтальное разграничение доступа, потому что сервис — это совокупность ресурсов.
Группа имеет следующие связи:
7 Вертикальное и горизонтальное разграничение доступа.
Самым простым способом представить себе работу авторизации — это нарисовать таблицы на каждого пользователя и каждый сервис, где колонки будут задавать разрешения, а строки — ресурсы, на пересечении ставятся галочки там, где доступ разрешен (привет excel-warrior’ам).
Для обеспечения доступа вы можете либо связать пользователя с ролью, что даст вам заполнение соответствующих разрешению ролей колонок в таблицах — такое разграничение называется вертикальным. Либо вы можете связать пользователя, роль и ресурс, что ограничит доступ до отдельного ресурса — такое предоставление доступ является горизонтальным.
8 Глобальность/локальность авторизации доступа в микросервисах
Несмотря на то, что все роли могут хранится в единой БД, то вот связи между ними и пользователями хранить все вместе на всю вашу огромную систему — это типичный антипаттерн, делать так является грубейшей ошибкой, это все равно что POSIX права на файлы хранить в облачном сервисе, вместе с таблицей inode.
9 Конъюнктивная/дизъюнктивная форма авторизации
Из-за того, что у теперь у нас существуют два варианта наборов разрешений пользователя, то можно выделить два варианта, как объединить все вместе:
Одним из важных преимуществ конъюнктивной формы является жесткий контроль за всеми операциями, которые может выполнять пользователь, а именно — без глобального разрешения пользователь не сможет получить доступ в следствие ошибки на месте. Так же реализация в виде программного продукта горазо проще, так как достаточно сделать последовательность проверок, каждая из которых либо успешна, либо бросает исключение.
Дизъюнктивная форма позволяет гораздо проще делать супер-админов и контролировать их численность, однако на уровне отдельных сервисов потребует написания своих алгортмов авторизации, которые в начале получит все разрешения пользователя, а уже потом либо успешно пройдет, либо бросит исключение.
Рекомендуется всегда использовать только конъюнктивную форму авторизации в виду ее большей гибкости и возможности снизить вероятность появления инцидентов по утечке данных. Так же именно конъюнктивная форма авторизации имеет большую устойчивость к ДДОС атакам в виду использования меньшего объема ресурсов.
Ее проще реализовать и использовать, отлаживать. Разумеется можно и дизъюнктивную форму натравить на анализ аннотаций метода и поиск соответствующих сервисов, но запросы вы отправлять будете скорее всего синхронно, один за другим, если же будете делать асинхронные вызовы, то много ресурсов будет уходить в пустоту, оно вам надо?
3 как использовать обобщенную модель данных
Теперь, определившись с терминами, можно разобрать несколько задачек, для того, что бы видеть как на практике применить материал.
1 Закрытый онлайн аукцион
Организатор может создать аукцион, пригласить участников. Участник может принять приглашение, сделать ставку.
Для того, что бы организатор мог создавать аукционы — нужно создать глобальную роль Организатор и при попытке создать аукцион — требовать эту роль. Созданные приглашения уже хранят в себе идентификаторы пользователей, поэтому когда пользователь делает ставку в аукционе, то это будет простейший запрос наличия записи перед вставкой ставки в аукцион.
2 Логистика
Огромная логистическая компания требует разграничить доступы для супервизоров и продавцов да еще с учетом региона. Работа такова, что продавец может выставить заявку на получение товара, а супервизор уже решает кому и сколько достанется. Соответственно продавец может видеть свой магазин и все товары в нем, а так же созданные им заявки, статус их обработки.
Для реализации такого функционала нам потребуется реестр регионов и магазинов в качестве отдельного микросервиса, назовем его С1. Заявки и историю будем хранить на С2. Авторизация — А.Далее при обращении продавца для получения списка его магазинов (а у него может быть их несколько)
, С1 вернет только те, в которых у него есть меппинг (Пользователь, Магазин), так как ни в какие регионы он не добавлен и для продавца регионы всегда пустое множество. Разумеется при условии, что у пользователя есть разрешение просматривать список магазинов — посредством микросервиса А.
Работа супервизора будет выглядеть немного иначе, вместо регистрации супервизора на каждый магазин региона, мы сделаем меппинги (Пользователь, Регион) и (Регион, Магазин) в этом случае для супервизора у нас всегда будет список актуальных магазинов с которыми он работает.
3 Секретные части документа
Некое министерство обязано выкладывать документы в общественный доступ, но часть документа является не предназначенной для показа любому желающему (назовем эту часть — номер телефона). Сам документ состоит из блоков, каждый из которых может быть либо текстом, либо номером телефона — скрытой частью, которую видеть могут только особые пользователи, подписавшие соглашение о неразглашении.
Когда пользователь обращается в сервис для получения блоков документа, микросервис в авторизации проверяет роль пользователя на чтение документов, далее в БД каждый блок имеет флаг — секрет. У документа есть меппинг (Пользователь, Документ) — список пользователей, которые подписали соглашение.
4 Команда и ее проекты
Если у вас большая команда, и много проектов, и такая команда у вас не одна, то координировать работу их будет той еще задачей. Особенно если таких команд у вас тысячи. Каждому разработчику вы доступы не пропишите, а если у вас человек еще и в нескольких командах работает, то разграничивать доступ станет еще сложнее.
Такую проблему проще всего решить при помощи групп.Группа будет объединять все необходимые проекты в одно целое. При добавлении участника в команду, добавляем меппинг (Пользователь, Группа, Роль).
Допустим, что Вася — разработчик и ему нужно вызвать метод develop на микросервисе для выполнения своих обязанностей. Этот метод потребует у Васи роли в проекте — Разработчик.Как мы уже договаривались — регистрация пользователя в каждый проект для нас недопустима.
Поэтому микросервис проектов обратится в микросервис групп, что бы получить список групп, в которых Вася — Разработчик. Получив список этих групп можно легко проверить уже в БД микросервиса проектов — есть ли у проекта какая-нибудь из полученных групп и на основании этого предоставлять или запрещать ему доступ.
2 Архитектура решения
Для решения поставленной задачи нам необходимы следующие микросервисы:
- Ролевая модель для глобальной авторизации запросов
- Чайный сервис для предоставления возможности пить чай и получать статистику по выпитому
- Кракен — гейт с проверкой доступа к точке, все остальные проверки совершит чайный сервис
Графически это будет выглядеть так:
В качестве БД будем использовать PostgreSQL.Предусмотрим следующие обязательные для решения задачи роли:
- Сотрудник — для возможности пить чай;
- Удаленный сотрудник — для доступа к микросервису кракена (так как сотрудники в офисе не должны иметь возможности пить чай через точки распрастранения чая);
- Кракен — учетная запись микросервиса, что бы была возможность обращаться к API чайного сервиса;
- Авторизационная учетная запись — для предоставления доступа микросервисов к ролевой модели.
5 реализация микросервисов
Для реализации воспользуемся Spring фреймворком, он довольно медленный, но зато на нем легко и быстро можно реализовывать приложения. Так как за перформансом мы не гонимся, то попробуем на нем достичь скромных 1к рпс авторизованных пустых запросов (хотя люди на спринге умудрялись 100к пустых запросов проворачивать [1]).
Весь проект поделен на несколько репозиториев:
Для начала разберемся с базой данных ролевой модели:
Аутентификация и авторизация
AUTHENTICATION AND AUTHORIZATION Ivanov V.1, Lubova E.2, Cherkasov D.3 АУТЕНТИФИКАЦИЯ И АВТОРИЗАЦИЯ Иванов В. В.1, Лубова Е. С.2, Черкасов Д. Ю.3
‘Иванов Вадим Вадимович /Ivanov Vadim — студент; 2Лубова Елена Сергеевна /Lubova Elena — студент;
3 Черкасов Денис Юрьевич / Cherkasov Denis — студент, кафедра компьютерной и информационной безопасности, Институт кибернетики Московский институт радиотехники, электроники и автоматики Федеральное государственное бюджетное образовательное учреждение высшего образования Московский технологический университет, г. Москва
Аннотация: аутентификация – это проверка соответствия субъекта и того, за кого он пытается себя выдать, с помощью некой уникальной информации (отпечатки пальцев, цвет радужки, голос и т.д.), в простейшем случае – с помощью имени входа и пароля. Авторизация -это проверка и определение полномочий на выполнение некоторых действий (например, чтение файла /var/mail/eltsin) в соответствии с ранее выполненной аутентификацией. Эти понятия представляют собой своеобразную первую линию обороны, обеспечивающую безопасность информационного пространства организации.
Abstract: authentication – is a conformity checking of the subject and the person for whom he is trying to give himself, with the help of some unique information (fingerprints, iris color, voice and so on.), In the simplest case – via a login and password. Authorization – this is a test and determination of the powers to perform certain actions (such as reading the file /var/mail/eltsin) in accordance with the previously performed authentication. These concepts represent a kind offirst line of defense, ensuring the safety of information space organization.
Ключевые слова: аутентификация, авторизация, токен, сервер. Keywords: authentication, authorization, token, server.
Аутентификация является, пожалуй, наиболее распространенным требованием любого приложения. Возможность быстро и легко зарегистрироваться или войти на сайт играет огромную роль для пользователя. В традиционном веб-приложении это обычно делается с помощью сервера, который отслеживает сеансы в той или иной форме. Статические приложения также могут отслеживать сессии, но работа клиента в непроверенной среде означает, что должны быть приняты дополнительные меры предосторожности, чтобы гарантировать, что пользователь проверен и заслуживает доверия.
Прежде чем мы продолжим, важно прояснить различие между аутентификацией и авторизацией. Аутентификация представляет собой процесс проверки того, что пользователь является тем, кем есть; это типичная регистрация в системе. Авторизация проверяет, что пользователи могут выполнять определенные действия, которые вы указали, и не более. Нужно убедиться, что пользователи не могут читать личные данные других лиц и выполнять административные действия.
Что такое непроверенная среда
Одним из самых больших различий между клиентской и серверной частями кода веб-приложения является то, что конечный пользователь может запустить произвольный код на стороне клиента без предварительного разрешения. Это означает, что все действия, которые может сделать ваше приложение с помощью JavaScript, пользователь может легко воспроизвести, открыв Инструменты разработчика в своем браузере. Это влечет за собой две проблемы:
– Авторизация в приложениях не должна размещаться внутри кода на стороне клиента, так как он может быть произвольно изменен любой стороной. (Либо авторизация в приложениях должна размещаться без возможности внесения правок со стороны клиента, поскольку иначе он может быть произвольно изменен любой стороной.)
– Код приложения на стороне клиента не может содержать «секретную» информацию, такую как ключи API или любого рода учетные данные для доступа, которые не являются специфическими для текущего пользователя.
Поскольку ненадежные среды создают проблемы и обнаруживают уязвимые места, стоит сосредоточиться на создании безопасной архитектуры. Статические приложения не могут позволить себе отказаться от обеспечения какой-либо защиты. Так что же делать?
Одно из лучших правил заключается в том, чтобы предоставить пользователям достаточную свободу действий, чтобы они могли уничтожить свои собственные данные, но не чужие. Очень важно помнить о том, что вы защищаете свое приложение от злоумышленников, а не пытаетесь необоснованно ограничить пользователей. Нет ничего страшного в том, что пользователь хочет взломать приложение и в процессе уничтожает свои собственные данные учетной записи пользователя. Нужно беспокоиться только тогда, когда его действия могут повлиять, скомпрометировать или уничтожить данные других пользователей.
Процесс аутентификации
Если вы не строите автономное приложение, предназначенное для хранения данных только в локальном браузере, ваш процесс аутентификации должен включать сервер. Самое простое средство аутентификации работает в основном так:
1. Клиент направляет пользователя к процессу аутентификации на стороне сервера. Это может быть сделано через всплывающее окно JavaScript или перенаправление браузера включается установкой window. location.
2. Сервер проверяет подлинность пользователя с помощью пароля, цифровых подписей или других средств.
3. Сервер создает случайно сгенерированный токен (ключ) и связывает его с уже прошедшим аутентификацию.
4. Сервер передает токен обратно клиенту.
5. Клиент использует предоставленный токен при последующих запросах к серверу в качестве документа, удостоверяющего личность, предоставляющего пользователю доступ к защищенным ресурсам.
Поскольку токен генерируется в момент входа в систему случайным образом, его присутствие служит достаточным доказательством того, что запрос исходит от пользователя, которому был выслан токен. Токен, который предоставляет доступ без каких-либо дополнительных требований, известен как токен носителя [1].
До того, как идентификация личности через токены стала распространенной, многие API-интерфейсы приложений использовали только имя пользователя и пароль учетных данных, передаваемых по запросу. Проверка подлинности через токен гораздо лучше подходит для такой системы по ряду причин:
1. Полномочия, особенно предоставленные пользователем пароли, должны храниться так надежно, как это возможно. Особенно, если приложение предоставляет доступ третьим лицам к серверу ресурсов, прямое использование пароля приведет к падению системы безопасности, что может поставить под угрозу аккаунты пользователей за пределами вашего приложения.
2. Сервер может отменить доступ к сгенерированному токену в любое время. Если у пользователя есть основания полагать, что один из авторизированных токенов был в некотором роде скомпрометирован, можно легко отменить доступ к токену без универсального сброса учетных данных пользователя или все предоставленных токенов.
3. Помимо ручного аннулирования доступа, у токенов может автоматически закончиться срок действия, что может потребовать дополнительных доказательств того, что они должны оставаться в силе. По сути, проверка подлинности на основе токенов дает вам возможность полностью контролировать аутентификацию и авторизацию приложения.
Обратите внимание на то, что каждый, кто предъявляет токен, немедленно получает доступ к данным. Поэтому жизненно важно, чтобы любое сообщение, которое включает токен, проходило через соединение, защищенное SSL-шифрованием.
Аутентификация и авторизация требуют обширных знаний, а потому вам нужно будет серьезно задуматься над стратегией, которую вы решите использовать. Простое предъявление токена кажется наилучшим выходом из ситуации, но эта система слишком уязвима. Если она будет перехвачена, то сможет полностью скомпрометировать учетную запись пользователя. Вот несколько советов, которые можно учесть для того, чтобы создать более высокий уровень безопасности пользователя для статического приложения [2]:
1. Не изобретайте колесо. Люди потратили много времени, думая на эти темы. Лучше всего придерживаться существующего протокола OAuth 2.0, а не пытаться придумать свой собственный.
2. Не позволяйте доступу к вашим токенам длиться вечно. Обновляйте токены или иным образом периодически требуйте повторную проверку подлинности, чтобы гарантировать, что устаревшие учетные данные клиента не станут основанием для нарушения безопасности.
3. Не храните токены доступа в незашифрованном виде или на локальном диске.
4. Используйте области авторизации. Когда клиент выполняет проверку подлинности, запросите список конкретных ресурсов, к которым он хочет получить доступ, даже если он полностью под вашим контролем.
Трехсторонняя аутентификация
В зависимости от потребностей вашего приложения, вы можете не реализовать свою собственную проверку подлинности пользовательских данных на основе токена. Если вы создаете приложение, которое в первую очередь взаимодействует с другой службой, могут быть доступны библиотеки JavaScript (например, Facebook’s JS SDK) или же они могут предложить способы создания авторизации токенов вручную (например, GitHub’s API).
Также появился относительно новый вариант, популярность которого растет, – он является фоновым провайдером аутентификации. Такие сервисы, как Firebase и UserApp, предлагают простые способы аутентификации пользователей статического приложения без генерирования кода на стороне сервера. Каждый сервис будет иметь свои сильные и слабые стороны, которые должны рассматриваться как часть общей стратегии аутентификации.
Авторизация пользователя (предоставление ему прав доступа к ресурсам) является положительным результатом аутентификации помимо установления доверительных отношений и выработки сессионного ключа. Процедура аутентификации необходима для обмена информацией между компьютерами. Для обеспечения защиты линии связи от прослушивания или подмены одного из участников взаимодействия используются сложные криптографические протоколы.
Литература
1. Под редакцией А. А. Шелупанова, С. Л. Груздева, Ю. С. Нахаева. Аутентификация. Теория
и практика обеспечения доступа к информационным ресурсам. М.: Горячая линия –
Телеком, 2009. С. 552.
2. Смит Ричард Э. Аутентификация: от паролей до открытых ключей. М.: Вильямс, 2002.
С. 432.
CHECKRECIPIENT SOLUTION OVERVIEW FOR EMAIL SECURITY
Patrakov E.1, Patrakova D.2 ОБЗОР РЕШЕНИЯ CHECKRECIPIENT ДЛЯ БЕЗОПАСНОСТИ ЭЛЕКТРОННОЙ ПОЧТЫ Патраков Е. И.1, Патракова Д. И.2
‘Патраков Евгений Иванович /Patrakov Evgeny — студент, департамент менеджмента;
2Патракова Дарья Ивановна / Patrakova Daria — студент, кафедра теоретических основ радиотехники, Уральский федеральный университет им. Б. Н. Ельцина, г. Екатеринбург
Аннотация: неверно адресованное письмо в современном мире вследствие непреднамеренной человеческой ошибки может стать результатом утечки конфиденциальных данных. Для решения данной проблемы были предложены следующие механизмы: «задержка отправки сообщения», «шифрование письма». Однако такие методы имеют существенные недостатки: уменьшение скорости отклика электронной почты, сложность реализации. Вследствие этого было предложено решение CheckRecipient, которое имеет две реализации: CheckRecipient Guardian, обнаруживающий и предотвращающий угрозы по электронной почте, используя искусственный интеллект, и CheckRecipient RuleBuilder, обнаруживающий и предотвращающий угрозы по электронной почте, используя машинное обучение. Abstract: incorrectly addressed letter in the modern world can become result of leakage of confidential data. To solve this problem, the following mechanisms have been offered: «delay of sending message», «encryption of a letter». However, such methods have significant drawbacks: reduction in the response speed of the email, the complexity of the implementation. As a result, it was suggested solution CheckRecipient, which has two implementations: CheckRecipient Guardian, detect and prevent threats by e-mail, using artificial intelligence, and CheckRecipient RuleBuilder, detect and prevent threats by email, using machine learning.
Аутентификация по ключам доступа
Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (
access key, API key
Аутентификация по одноразовым паролям
Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации
two-factor authentication
(2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.
Другой популярный сценарий использования одноразовых паролей — дополнительная аутентификация пользователя во время выполнения важных действий: перевод денег, изменение настроек и т. п.
Существуют разные источники для создания одноразовых паролей. Наиболее популярные:
- Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
- Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
- Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.
Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.
В веб-приложениях такой механизм аутентификации часто реализуется посредством расширения forms authentication: после первичной аутентификации по паролю, создается сессия пользователя, однако в контексте этой сессии пользователь не имеет доступа к приложению до тех пор, пока он не выполнит дополнительную аутентификацию по одноразовому паролю.
Аутентификация по сертификатам
Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный
certificate authority
(CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.
На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.
В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.
Использование сертификата для аутентификации.
Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:
- Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
- Сертификат должен быть действительным на текущую дату (проверка срока действия).
- Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).
Пример X.509 сертификата.
После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).
Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation).
Аутентификация по токенам
Такой способ аутентификации чаще всего применяется при построении распределенных систем
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-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.
Взаимосвязь идентификации, аутентификации и авторизации
Наверное, вы уже догадались, что все три процедуры взаимосвязаны:
Многофакторная аутентификация
Многофакторная аутентификация представляет собой метод, при котором пользователю для доступа к учетной записи или подтверждения операции с денежными средствами необходимо двумя различными факторами доказать, что именно он владелец учетной записи или что именно он осуществляет вход.
Среди видов многофакторной аутентификации наиболее распространена двухфакторная аутентификация (2FA — 2-factor authentication) – метод, при котором пользователю для получения доступа необходимо предоставить два разных типа аутентификационных данных, например, что-то известное только пользователю (пароль) и что-то присущее только пользователю (отпечаток пальца).
Однофакторная двухэтапная аутентификация
Благодаря тому, что смартфоны стали неотъемлемой частью нашей жизни, именно они стали одним из способов подтверждения личности пользователя. Они являются токенами для доступа к различным ресурсам. В этом случае одноразовый пароль генерируется или с помощью специального приложения, или приходит по SMS – это максимально простой для пользователя метод.
Аутентификация происходит следующим образом:
Определения
Идентификация, аутентификация и авторизация – три процесса защищающие Ваши данные или денежные средства от доступа посторонних лиц.
Понимание процессов придет быстрее, если дать им определения.
- Идентификация — процесс распознавания пользователя по его идентификатору.
- Аутентификация — процедура проверки подлинности, доказательство что пользователь именно тот, за кого себя выдает.
- Авторизация — предоставление определённых прав.
Для начала этих теоретических знаний будет достаточно. Вернемся к примеру с доступом в онлайн-банкинг. Каждое действие пользователя и системы рассмотрим подробно.
Проблемы безопасности при авторизации
Помните, как в сказке «Красная Шапочка» бабушка разрешает внучке войти в дом? Сначала бабушка спрашивает, кто за дверью, затем говорит Красной Шапочке, как открыть дверь. Волку же оказалось достаточным узнать имя внучки и расположение дома, чтобы пробраться в дом.
Какой вывод можно сделать из этой истории?
Каждый этап авторизации должен быть тщательно продуман, а идентификатор, пароль и сам принцип авторизации нужно держать в секрете.
Рекомендации
- Используйте уникальные, надежные пароли для разных учетных записей.
- Настройте двухэтапную однофакторную или многофакторную аутентификацию на всех ресурсах, где это возможно.
Стандарт saml
Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.
Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:
Стандарты 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, однако их подходы и реализация в некоторой степени отличаются.
Форматы токенов
Существует несколько распространенных форматов токенов для веб-приложений:
Заключение
В статье предложена универсальная модель для авторизации доступа множеству пользователей к множеству ресурсов с минимальными потерями по производительности, позволяющая делать эффективное кеширование и хранение промежуточных данных на микросервисах, для сборки результата авторизации just-in-time.
Предложена метрика (в виде коэффициента), для оценки работы авторизации микросервисов с учетом требований работы всего комплекса и показано, как он может меняться в зависимости от подхода, а именно наличия/отсутствия кеша, хранения ролей в JWT токене и т.д. Не показано, что этот коэффициент всегда растет с увеличением количества под в системе.
Предложенная модель данных позволяет разделить данные между частями микросервисной архитектуры, тем самым снизив требования к железу, дает возможность работать только с теми данными, которые нужны в конкретный момент времени конкретному сервису, не пытаться искать в огромном массиве все подряд или пытаться искать данные в полностью обобщенном хранилище.
Показано, что при малом количестве микросервисов нет смысла проводить кеширование на клиенте авторизации, так как это приведет к большей нагрузке на ЦПУ. Предоставлены данные, которые позволяют сделать вывод, что необходимо балансировать ресурсы в зависимости от размеров системы, если она слишком мала, то есть смысл нагружать больше сеть, но при увеличении и разрастании выгоднее добавить пару ядер в микросервисы, для обеспечения работы кешей и разгрузки сети, микросервисов авторизационных данных.
11 Выводы по обобщенной модели
Предложенная модель дает возможность сделать масштабируемую систему авторизации. Позволяет сделать глобальное разграничение один раз и далее только корректировать, добавляя новые роли, разрешения, группы, все более детализируя доступ к каждому конкретному ресурсу каждому пользователю.