Двухфакторная аутентификация

Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.

Планируется в версии 8.3.15.

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

Аутентификация

Применительно к системе 1С:Предприятие аутентификация – это процедура проверки логина и пароля, которые ввёл пользователь, на корректность. Эту операцию платформа может выполнять самостоятельно, либо может воспользоваться результатами аутентификации, которую выполнил другой ресурс, которому она доверяет (операционная система или аутентификация OpenID). В любом случае либо там, либо там пользователь выбирает некоторый логин и вводит пароль. Если логин и пароль корректные, платформа считает, что пользователь идентифицирован и предоставляет ему доступ к данным.

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

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

Двухфакторная аутентификация требует, чтобы пользователь имел два из трех возможных типов аутентификационных данных:

• Нечто ему известное, то, что он помнит (например, логин / пароль),
• Нечто, чем он владеет (например, мобильный телефон),
• Нечто ему присущее (например, отпечаток пальца).

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

Проверку первого фактора аутентификации выполняет платформа 1С:Предприятия, а для работы со вторым фактором аутентификации используется некоторый сторонний сервис, который мы будем называть провайдером.

Провайдер второго фактора аутентификации

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

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

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

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

1. Пользователь запускает клиентское приложение. Оно запрашивает у него первый фактор аутентификации – логин и пароль. Пользователь вводит их, клиентское приложение отправляет их на сервер.
2. Сервер проверяет логин и пароль на корректность. Если они верные, сервер проверяет, нужно ли для этого пользователя использовать второй фактор аутентификации.

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

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

Простой провайдер

1. Сервер сообщает клиентскому приложению о том, что пользователь должен ввести второй фактор аутентификации.
2. Клиентское приложение показывает пользователю окно дополнительной аутентификации, например:
   
3. Сервер генерирует код второго фактора (например, 94573) и отправляет HTTP -запрос провайдеру. Этот запрос содержит сообщение, которое провайдер должен передать пользователю, например «Ваш аутентификационный код 94573. Не сообщайте его никому».
4. Провайдер отсылает это сообщение пользователю, например, на мобильный телефон.
5. Пользователь читает код, присланный в СМС.
6. Пользователь вводит этот код в окно дополнительной аутентификации (п.2)
7. Сервер проверяет код на корректность. Если он верный, то считается, что пользователь полностью идентифицирован и может начинать работу.

Этот сценарий можно использовать для «простых» провайдеров второго фактора, которые могут только передать фиксированное сообщение пользователю (например, с помощью СМС сообщения на номер телефона). В этом сценарии платформа (сервер) сама генерирует код второго фактора и полностью формирует сообщение, которое провайдер должен передать пользователю. Провайдер только передает сообщение пользователю, а платформа ожидает, когда пользователь введёт код второго фактора в окно дополнительной аутентификации.

«Умный» провайдер

1. Сервер сообщает клиентскому приложению о том, что пользователь должен выполнить аутентификацию второго фактора на стороне провайдера.
2. Клиентское приложение показывает пользователю окно дополнительной аутентификации, например:
   
3. Сервер отправляет HTTP-запрос провайдеру с просьбой самостоятельно аутентифицировать пользователя.
4. Провайдер начинает процедуру аутентификации, например, с помощью мобильного приложения просит у пользователя отпечаток пальца.
5. Пользователь прикладывает палец к сканеру.
6. Пользователь нажимает в окне дополнительной аутентификации (п.2) ОК, сообщая тем самым платформе, что он выполнил дополнительную аутентификацию.
7. Сервер запрашивает провайдера о результатах аутентификации.
8. Провайдер сообщает серверу результат аутентификации. Если она выполнена успешно, то считается, что пользователь полностью идентифицирован и может начинать работу.

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

Пользователи и провайдеры

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

Чтобы описать HTTP-запросы, которые следует отправить провайдеру, мы реализовали во встроенном языке новый тип – ШаблонНастройкиВторогоФактораАутентификации. Объекты этого типа – это именованные объекты, которые вы можете сохранять в базе данных. Каждый такой шаблон позволяет сохранить сразу два HTTP-запроса: один для запроса аутентификации, другой – для получения её результата. Оба этих запроса описываются с помощью привычных объектов HTTPЗапрос, но имеют две интересные особенности:

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

В результате, например, шаблон для простого провайдера, отправляющего СМС, вы можете сформировать, задав только один запрос – запрос для аутентификации. В этом запросе будут использованы два параметра – host (адрес провайдера) и secret (код второго фактора, который сформирует платформа):

Шаблон «умного» провайдера будет содержать уже два запроса (просьба выполнить аутентификацию и запрос результатов аутентификации):

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

Например, для пользователя, который будет использовать «простого» провайдера вы можете записать единственный параметр – адрес, на который будет отправляться HTTP-запрос (host):

А для пользователя, который будет использовать «умного» провайдера, параметров понадобится больше:

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

Журнал регистрации

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

По материалам “Зазеркалья”:

https://wonderland.v8.1c.ru/blog/dvukhfaktornaya-autentifikatsiya/

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>