В версии платформы «1С:Предприятие» 8.3.15 реализовали механизм, который обеспечит дополнительную защиту информационной базы. При входе в базу механизм потребует подтвердить личность пользователя двумя разными способами.
Аутентификация
В системе «1С:Предприятия» аутентификация означает проверку логина и пароля пользователя на корректность. Платформа выполняет эту операцию самостоятельно, или пользуется помощью другого надежного ресурса, будь то операционная система или аутентификация OpenID.
OpenID – открытый стандарт децентрализованной системы аутентификации. Технология позволяет создавать единую учетную запись для аутентификации на множестве не связанных друг с другом интернет-ресурсов.
У такой системы есть недостаток: для своего удобства пользователи придумывают простые и короткие пароли. Но это противоречит сути «запароливания» данных, которые мы хотим защитить: простые пароли легко взломать.
Двухфакторная аутентификация – один из самых надежных способов защиты информации. Чтобы пройти проверку личности, пользователю нужны два из трех типов данных, например:
- логин / пароль;
- мобильный телефон;
- отпечаток пальца.
Например, мы вводим логин и пароль, а затем входим по отпечатку пальца. Либо вводим присланный на мобильный телефон код.
Платформа «1С» проверит первый фактор самостоятельно, а для второго ей потребуется помощник – провайдер.
Провайдер второго фактора аутентификации
Провайдер-помощник – веб-сервис, обладающий некоторым интерфейсом, состоящим из HTTP-запросов. Это может быть:
- база «1С:Предприятия» с реализованным набором HTTP-сервисов, позволяющих пересылать сообщения или выполнять аутентификацию;
- сторонний сервис, генерирующий коды для второго фактора аутентификации.
Для нас важно, чтобы провайдер умел общаться посредством HTTP-запросов.
Сценарии аутентификации
Существует два возможных сценария для второго фактора аутентификации: для «простых» и «умных» провайдеров.
В первом случае клиентское приложение показывает пользователю окно дополнительной аутентификации:
Сервер генерирует код второго кода и отправляет HTTP-запрос провайдеру с сообщение для пользователя: «Ваш аутентификационный код 94573». Провайдер пересылает СМС с кодом на мобильный телефон пользователя, его остается лишь ввести в специальном окне.
В этом случае генерирует код и формирует сообщения сервер. Провайдер только передает сообщение пользователю, а платформа ждет ввода кода.
«Умные» провайдеры сами генерируют секретный код, сообщение, умеют информировать пользователя и проверять его данные. Сервер сообщает клиентскому приложению о необходимости дополнительно проверить пользователя. Клиентское приложение покажет окно второго фактора аутентификации.
Как работает «умный» провайдер
Сервер отправляет HTTP-запрос провайдеру с просьбой самостоятельно аутентифицировать пользователя. «Умный» провайдер просит у пользователя отпечаток пальца через специальное приложение. Пользователь сканирует палец и в окне дополнительной аутентификации указывает, что проверка пройдена. Провайдер сообщит серверу результаты, и при успешном завершении процедуры пользователь сможет начать работу.
Пользователи и провайдеры
Для каждого пользователя провайдер и способ аутентификации определяется отдельно. Чтобы описать HTTP-запросы, которые следует отправить провайдеру, в во встроенном языке платформы реализовали новый тип – ШаблонНастройкиВторогоФактораАутентификации.
Объекты этого типа – именованные объекты, которые можно сохранить в базе данных. Каждый шаблон используется для сохранения двух HTTP-запросов: один для запроса аутентификации, другой – для получения ее результата.
Оба этих запроса описываются с помощью привычных объектов HTTPЗапрос, но имеют две интересные особенности:
- для каждого из запросов задается свой HTTP-метод в виде строки;
- некоторые поля в запросах можно «параметризировать», используя «&» (например, &sms_phone_number). Запросы для разных пользователей будут одинаковыми, различаются лишь некоторые поля: номер телефона для отправки кода, например.
Шаблон для простого провайдера, отправляющего СМС, формируется по одному запросу – для аутентификации. Шаблон «умного» провайдера содержит два запроса: просьба выполнить аутентификацию и запрос результатов аутентификации.
После сохранения шаблонов для провайдеров, каждый из них присваивается определенному пользователю вместе с набором значений для параметров, которые должны подставляться в этот шаблон.
Для пользователя с шаблоном «простого провайдера» записывается один параметр: адрес для отправки HTTP-запроса (host):
Пользователь, для которого используется «умный» провайдер, потребует больше параметров:
Важно: каждому пользователю можно задать не один «набор» настроек, а несколько (массив). Свойство ОбработкаНастроекВторогоФактораАутентификации позволяет применять их по очереди в том случае, если исполнение текущего HTTP-запроса закончилось ошибкой. Например, провайдер не работает, тогда можно попробовать другого провайдера, который умеет выполнять аналогичные действия (другой набор настроек).
Журнал регистрации
Для всех новых сценариев аутентификации в журнал регистрации добавили новые события и новые поля некоторым старым событиям. Поэтому контролировать можно не только двухфакторную проверку пользователя, но и связанные с ней действия: изменение шаблонов или настроек пользователей.