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

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

1. Введение

Государственная политика импортозамещения в сфере информационных технологий и устранения технологической зависимости от зарубежных разработок продолжается в России уже более 10 лет. Развитие собственной высокотехнологичной промышленности стимулируется правительством через различные правовые механизмы: принятие новых законов с целью улучшения условий для ведения деятельности; финансовая поддержка организаций, осуществляющих деятельность в сфере информационных технологий (предоставление грантов); утверждение льгот в Налоговом кодексе РФ. Наравне с общим уменьшением ставок за аренду территорий и производственных мощностей, существуют методы поддержки и развития наиболее значимых отраслей – IT, научных исследований, экспериментов, инженерно-конструкторских разработок. Внутренние процессы этих производств объединены аббревиатурой НИОКР* (научно-исследовательские и опытно-конструкторские разработки). В случае присвоения такой разработке статуса НИОКР [1] при наличии научной новизны, организация имеет право претендовать на увеличенный бюджет или применить повышенный коэффициент к расходам по налогу на прибыль организаций [2] (т.е. сумму фактических затрат по работам можно увеличить в полтора раза и включить в расходы).
Данная льгота предусмотрена последовательной государственной политикой, ведущейся с 2008 года. Льгота является эффективным рычагом налогового стимулирования инновационной активности с целью создания благоприятных условий для осуществления инновационной деятельности в Российской Федерации при наличии научной новизны для развития национальной науки и техники в целом и устранения технологической зависимости от иностранных разработок и развития собственной высокотехнологичной промышленности [3].
В случае применения указанной льготы налогоплательщик должен представить в налоговый орган отчет о выполненных НИОКР, оформленный в соответствии требованиями, установленными национальным стандартом (Межгосударственный стандарт ГОСТ 7.32-2001) [4].
Налоговые органы осуществляют проверку представленного отчета о выполненных НИОКР по двум направлениям:

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

Вместе с тем, на практике встречаются случаи, когда налогоплательщики неправомерно применяют льготу, предусмотренную статьей 262 Кодекса, что выявляется в ходе налоговых проверок после назначения и проведения экспертиз специалистами научно-исследовательских организаций и вузов.
Таким образом, экспертиза документации, представляемой IT-компаниями, является важным процессом проверки обоснованности предоставления налоговых льгот не только в России, но и в мировой практике [5].
При проведении НИОКР и подготовке отчетной документации компания, претендующая на предоставление ей налоговых преференций, использует целый ряд цифровых сервисов, таких как система «Антиплагиат» [6], информационно-поисковые системы, реализованные на цифровой платформе Роспатента [7], онлайн-база данных ВИНИТИ РАН и т.п. Эксперты, осуществляющие научно-техническую экспертизу проектов, также используют цифровые сервисы. Процесс проверки отчетной документации инициируют и администрируют налоговые инспекции, используя ведомственные сервисы.
Проведение подобных экспертиз представляет собой многоэтапный процесс, в котором участвуют налогоплательщики, налоговые инспекторы и эксперты. Документация, представляемая на экспертизу, состоит из большого числа текстовых документов, разнообразных как по содержанию, так и по форме. В ряде случаев отчетные документы плохо структурированы, не соответствуют российским и международным стандартам, используют различные форматы. Все это существенно усложняет процесс экспертизы, а выполнение рутинных операций по первичной обработке документов значительно увеличивает ее трудоемкость.
Для повышения эффективности процесса проведения научно-технических экспертиз используются разнообразные автоматизированные системы. Однако все они имеют ярко выраженный отраслевой характер и основаны на анализе текстов с помощью различных NLP-алгоритмов [8, 9]. Зачастую такие системы архитектурно представляют собой монолитные приложения, реализующие функции проверки текста на соответствие эталонной структуре, анализа содержания текста по ключевым словам, выявления заимствований и т.п.
Рассматриваемая в работе система поддержки проведения научно-технических экспертиз [5] разработана на основе требований инспекций Федеральной налоговой службы, компаний-налогоплательщиков, а также представителей экспертного сообщества. К их числу относятся следующие основные требования:

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

Архитектура системы представляет собой платформенное решение, интегрированное с рядом цифровых сервисов, обеспечивающих проверку отчетной документации о выполненных НИОКР как по форме, так и на предмет их соответствия критерию научной новизны. При этом для налогоплательщиков и экспертов предлагаемое решение будет относиться к типу облачных сервисов SaаS, а для налоговых инспекций – PaaS [10].
Использование пользователями большого количества разнообразных облачных сервисов порождает целый ряд проблем при их эксплуатации и поддержке в рамках интеграционного решения. Одним из наиболее важных вопросов является обеспечение безопасности при использовании интернет-сервисов. Для этого широко применяется технология единого входа, направленная на решение данной проблемы. Технология единого (однократного) входа (англ. Single Sign-On, SSO) – это технология доступа к различным приложениям посредством однократной процедуры аутентификации [11].
Данная технология призвана решить целый ряд задач, в том числе:

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

При проектировании системы были рассмотрены следующие сервисы: Личный кабинет налогоплательщика, «Антиплагиат», Поиск патентов [7]. Каждый ресурс предъявляет собственные требования к безопасности и определяет собственные процедуры идентификации и аутентификации.
Разрабатываемый подход должен обеспечить возможность формирования системы единого входа для пользователей рассматриваемых сервисов и облегчить их использование. Решение этой задачи проводилось в соответствии со следующими этапами:

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

2. Анализ способов аутентификации пользователя

Применительно к RESTful API, как правило, выделяют шесть способов аутентификации (их на самом деле больше):

Basic;
Digest;
Token;
Certificate;
Digital signature;
с применением ключей API (oAuth, oAuth 2.0).

Первый и второй способ используют для доверенных клиентов. Ключи API используют для сторонних клиентов.

2.1. Basic-аутентификация

Метод базовой аутентификации – наиболее простой при разработке, но он обеспечивает наиболее низкий уровень защиты, прописанный в опциях протоколов. Чаще всего используется в течение разработки, но не рекомендуется для использования в интегрированной системе [12].
Пример использования: JIRA REST API – Basic authentication.

2.2. Digest-аутентификация

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

клиент запрашивает страницу, которая требует аутентифицироваться, но не вводит имя пользователя и пароль;
сервер отвечает 401 «клиент-ошибка», предоставляя область аутентификации и случайно сгенерированное одноразовое значение;
на данном шаге клиент предоставит область аутентификации (как правило, описание компьютера или системы, осуществляющей доступ) пользователю и запросит имя пользователя и пароль, в этот момент пользователь может принять решение об отмене;
как только имя пользователя и пароль были предоставлены, клиент повторно посылает тот же самый запрос, но добавляет заголовок аутентификации, который включает код ответа;
сервер принимает аутентификацию, и страница возвращается, а в случае, если имя пользователя является недействительным и/или пароль неверный, сервер может вернуть код ответа «401» – и клиент будет запрашивать их у пользователя еще раз [12].

Digest-аутентификация обладает существенными недостатками:

Digest-авторизация является медленной, так как необходимо выполнить два запроса;
уязвима к атаке «человек посередине» (англ. man-in-the-middle), атака на воспроизведение;
пароль, хранящийся на сервере, может быть взломан.

2.3. OAuth (oAuth2)

Принцип работы oAuth заключается в использовании временных токенов.
Схема действия оправдывает свое использование для клиентов третьей стороны: у них нет логина, пароля и разрешений, аналогичных пользовательским, поэтому необходимо отдельно хранить все разрешения для независимых клиентов. Для этих целей разработчик получает ключ API (API key) – длинные уникальные строки, содержащие произвольный набор символов, по сути, заменяющие собой комбинацию username/password, – а пользователи разрешают доступ к подконтрольным им данным. Например, доступ на просмотр имени, почтового адреса и т.п. [12].
После выдачи разрешений третьей стороне ей выдается токен на доступ, по которому они получают доступ уже к пользовательским данным.
Недостатки:

сложнее в реализации;
является зависимым от состояния (аналогичен cookie – stateless);
уязвим к атакам «человек посередине».

2.4. Аутентификация по cookie

В идеальном RESTful-сервисе контроль за состояниями полностью производится на стороне клиента. Для не-браузерных клиентов cookies сложны в обработке.
Сценарий использования данного подхода заключается в следующем:

API смотрит на заголовок «Authorization», в случае не-браузерных клиентов именно туда будет помещена информация для авторизации;
если такой заголовок отсутствует, то проверяется сессионная cookie для осуществления авторизации на стороне сервера.

Этот подход имеет следующие недостатки:

не отвечает требованиям RESTful-сервиса в вопросе независимости от состояния;
уязвима к атакам «человек посередине»;
на стороне сервера каким-то образом нужно хранить сессионную ID, что противоречит REST-идеологии.

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

Такой способ аутентификации чаще всего применяется при построении распределенных систем, использующих единый сервис для входа (SSO), где одно приложение, выступающее в качестве сервиса-поставщика (англ. service provider, SP), делегирует функцию аутентификации пользователей другому приложению – сервису-поставщику идентификационных услуг (англ. identity provider, identity assertion provider, IdP). Сервис-поставщик идентификационных услуг решает следующие основные задачи:

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

Реализация этого способа заключается в том, что IdP-сервис предоставляет достоверные сведения о пользователе в виде токена, а SP-приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.
Для данного способа аутентификации существует несколько стандартов, определяющих протокол взаимодействия между клиентами (активными и пассивными), IdP и SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML и WS-Federation.
Сам токен обычно представляет собой структуру данных, которая содержит информацию о том, кто сгенерировал токен, кто может быть получателем токена, срок действия токена, набор сведений о самом пользователе (claims). Кроме того, токен дополнительно подписывается для предотвращения несанкционированных изменений и гарантий подлинности.
Процесс аутентификации в данном методе выглядит следующим образом:

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

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

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

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

3. Обоснование выбора метода аутентификации

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

основное назначение: взаимодействие с front-end-частью системы для выполнения основной бизнес-логики системы;
вторичное: использование методов, предоставляемых API, сторонними приложениями;
точка доступа для осуществления однократного входа пользователя в рамках использования нескольких систем.

Основные типы клиентов можно подразделить на:

браузерные;
не-браузерные.

Исходя из архитектуры разработанной системы [5], предлагается использовать следующие методы аутентификации:

аутентификация по cookie, являющаяся классическим решением для браузеров;
аутентификация по токену, являющаяся широко распространенным решением для RESTful-сервисов.

4. Реализация аутентификации и авторизации
4.1. Аутентификация по cookie
Для реализации метода входа в систему с дальнейшим присвоением пользователю аутентификационной cookie была выбрана стандартная реализация, имплементированная в OWIN Middleware.
Такой способ аутентификации требует предварительных настроек в конфигурационном файле, отвечающем за настройки аутентификации и авторизации проекта.
Для настройки аутентифицирующей cookie были выбраны следующие параметры:
– срок действия cookie – 12 часов с момента аутентификации;
– режим аутентификации – активный, что гарантирует создание пользовательской сущности, как только получен запрос.
Реализация аутентификации по cookie включает следующие два метода:
– POST api/account/session – вход в систему;
– DELETE api/account/session – выход из системы.
Блок-схемы алгоритмов аутентификации и выхода из учетной записи представлены на рисунках 1 и 2.

Рис. 1. Блок-схема алгоритма аутентификации пользователя по cookie.

Рис. 2. Блок-схема алгоритма выхода из системы пользователя, авторизованного по cookie.

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

Авторизация на основе токенов состоит из нескольких компонентов:

клиент, который обращается к веб-сервису – может представлять собой веб-браузер, мобильное приложение, десктопное приложение;
веб-сервис, к ресурсу которого обращается клиент;
токен доступа (access token), наличие которого дает доступ к ресурсам веб-сервиса;
bearer-токен – специальный вид токена доступа;
сервер авторизации, который выдает токены доступа клиенту.

Реализация аутентификации по токену включает следующие два метода:

POST api/account/token – вход в систему;
DELETE api/account/token – выход из системы.

Блок-схемы алгоритмов аутентификации и выхода из учетной записи представлены на рисунках 3 и 4.

Рис. 3. Блок-схема алгоритма аутентификации пользователя по токену.

Рис. 4. Блок-схема алгоритма выхода пользователя по токену.
Настройки аутентификации по токену имеют следующие параметры:

срок действия токена – 14 дней с момента аутентификации;
режим аутентификации – пассивный.

4.3. Регистрация пользователя и управление паролем

Наряду с процедурой аутентификации и авторизации пользователя также был реализован метод регистрации пользователя и управления его паролем:
1. Регистрация – POST api/account/register.
2. Смена пароля авторизованного пользователя – PUT api/account/password.
3. Запрос токена для сброса пароля неавторизованным пользователем – DELETE api/account/password.
4. Сброс пароля по токену неавторизованным пользователем – POST api/account/password?token=&email=.

5. Заключение

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

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

[1] Аникейчик Н.Д., Кинжагулов И.Ю., Федоров А.В. Планирование и управление исследованиями и разработками. Методическое пособие. – СПб.: Университет ИТМО, 2016. – 192
[2] Налоговый кодекс Российской Федерации (часть вторая) от 05.08.2000 № 117-ФЗ (ред. от 18.03.2023) (с изм. и доп., вступ. в силу с 01.04.2023)
[3] Постановление правительства РФ от 24 декабря 2008 г. № 988 “Об утверждении перечня научных исследований и опытно-конструкторских разработок, расходы налогоплательщика на которые в соответствии с пунктом 7 статьи 262 части второй Налогового кодекса Российской Федерации включаются в состав прочих расходов в размере фактических затрат с коэффициентом 1,5” (с изменениями и дополнениями) // https://base.garant.ru/12164440/
[4] Отчет о научно-исследовательской работе. Структура и правила оформления // https://docs.cntd.ru/document/1200026224
[5] Decision Support System for scientific and technical expertise / Belov A. V, Bikbaev B. I., Gevondyan M. S., Levitan D. A., Panina I. Yu. // in Proceedings of the 2023 Conference of Russian Young Researches in Electrical and Electronic Engineering (EIConRus). IEEE, 2023, p.p. 188-193
[6] https://antiplagiat.ru/
[7] https://searchplatform.rospatent.gov.ru/
[8] Эффективная классификация текстов на естественном языке и определение тональности речи с использованием выбранных методов машинного / Плешакова Е.С., Гатауллин С.Т., Осипов А.В., Романова Е.В., Самбуров Н.С. // обучения // Вопросы безопасности. – 2022. – No 4. – С. 1 – 14. DOI: 10.25136/2409-7543.2022.4.38658
[9] Анализ методов машинного обучения на примере задачи многоклассовой классификации текста / М. В. Лаптев // Информатика: проблемы, методы, технологии. – 2022. – С. 1155-1163
[10] Cloud Computing: Concepts, Technology & Architecture Thomas Erl, Ricardo Puttini, Zaigham Mahmood, NY, Pearson, 2013, p. 346
[11] Технология Single Sign On: инструменты централизованной аутентификации для функциональной системы сервисов. / А.Ю. Демидова, А.В. Жуков // Инженерный вестник Дона, №3, 2020, http://ivdon.ru/ru/magazine/archive/N3y2020/6353
[12] Обзор способов и протоколов аутентификации в веб-приложениях // https://habrahabr.ru/company/dataart/blog/262817/

Об авторах:

Александр Владимирович Белов, профессор, руководитель Департамента прикладной математики МИЭМ НИУ ВШЭ, avbelov@hse.ru
Александр Александрович Антышев, ведущий научный сотрудник ФКУ НПО «СТиС» МВД России, a166aa@yandex.ru
Маргарита Саркисовна Гевондян, начальник правового отдела N 1 Межрегиональной инспекции ФНС России по крупнейшим налогоплательщикам N 1, m.gevondyan.r9977@tax.gov.ru