Как внедрить много-факторную аутентификацию

[ndabbot]

Я не разработчик или администратор Dynamics AX.
Мне нужно узнать, возможно ли настроить много-факторную аутентификацию (пароль ну и к примеру СМС токен, единовременный пароль, софт токен) непосредственно для Dynamics AХ 2012. Моя сфера работы ИБ, Dynamics не знаю и никогда руками не трогал, однако стоит задача найти возможный продукт или решение вроде RSA SecurID.
Клиент хочет что бы его менеджеры, находясь в офисе или вне его, заходя через клиент или через веб портал, вводили не только пароль, но и дополнительный токен.
Насколько я понял у клиента пользователи входят в Dynamics с отдельными аккаунтами, не интегрированными в Active Directory, по какой то причине компания не хочет использовать технологию единого входа (SSO).
Видение клиента состоит в том, что он хочет заставить менеджеров вводить пароль и токен при авторизации каких либо транзакций, иначе они просто отдают пароль секретарям.

[Kabardian]

В стандартной AX подобную аутентификацию можно настроить с использованием электронной цифровой подписи. Подойдет?

[ndabbot]

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

Заране спасибо.

[gl00mie]

Цитата:

Сообщение от ndabbot

Я не разработчик или администратор Dynamics AX.
Мне нужно узнать, возможно ли настроить много-факторную аутентификацию (пароль ну и к примеру СМС токен, единовременный пароль, софт токен) непосредственно для Dynamics AХ 2012.

В стандарте так сделать нельзя, потому что из Dynamics AX, начиная с версии 4.0 (т.е. 2 версии назад), выкинули собственный механизм аутентификации, привязав всё к AD с использованием SSO.

Цитата:

Сообщение от ndabbot

Клиент хочет что бы его менеджеры, находясь в офисе или вне его, заходя через клиент или через веб портал, вводили не только пароль, но и дополнительный токен.

Тут нужно абстрагироваться от Аксапты, см., например, Authenticate Clients Using Smart Cards (для IIS и того же портала).

Цитата:

Сообщение от ndabbot

Насколько я понял у клиента пользователи входят в Dynamics с отдельными аккаунтами, не интегрированными в Active Directory

Это как?..

Цитата:

Сообщение от ndabbot

по какой то причине компания не хочет использовать технологию единого входа (SSO).

Тогда они не того вендора выбрали

Цитата:

Сообщение от ndabbot

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

Выходит, дело не в SSO, не в использовании AD для аутентификации пользователей, а в некоторых бизнес-процессах, требующих одобрения менеджерами тех или иных документов/действий. И сейчас просто менеджерам неудобно это делать в Аксапте самостоятельно, потому они и передают свои учетные данные посторонним людям, чтобы те выполняли одобрение за них.
Если так, то идти, мне кажется, нужно в противоположном направлении: не пытаться усложнить менеджерам вход в Аксапту, а напротив, упростить им одобрение тех или иных документов/действий в системе. Это решается иначе, например, через функционал Workflow: в 2012-й куча бизнес-процессов может быть штатно привязана к Workflow, выполняющемуся на базе Windows Workflow Foundation (WF). WF позволяет "выходить за рамки" системы, в частности, уведомление о том, что пользователю передан на одобрение тот или иной документ или действие, может приходить в т.ч. на электронную почту, можно прямо в том же Outlook "проголосовать" - и ответ вернется в WF, повлияв на дальнейшее выполнение бизнес-процесса в Аксапте. См. также Workflow examples.
А секретарям можно просто объяснить, что "авторизация транзакций" за менеджеров не только не входит в их обязанности, но и может преследоваться как уголовное преступление (п.2 статьи 272 УК РФ, штраф до 300 тыщ или лишение свободы на срок до 5-и лет).

[KiselevSA]

Есть еще вариант решения задачи: переход на смарт-карты и клавиатуры со считывателем и вводом запрета ввода пароля для не администраторов. При этом для "ужесточения" безопасности внедрить ЕСКД, карту использовать для входа/выхода в офис и помещения, для аутентификации AD и прочее. Менеджерам не надо будет вводить пароль, на компьютерах подразделений можно запретить вход со смарт-картами "чужих" подразделений, регистрировать попытки неразрешенных входов, проводить разъяснительную беседу, при повторении - наказывать.

[gl00mie]

Тут еще вопрос, как относиться к менеджерам Помнится, Дуглас Макгрегор предложил теориии X и Y:

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

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

[ndabbot]

Поясните пожалуйста, по тем документам, которые я прочитал на сайте МС, я так понял что есть возможность заводить пользователей вне AD, т.н. claim-based user. Может я не до конца понимаю концепцию, но разве это не решает вопрос с пользователями не интегрированными в AD? Может ли claim-based user заходить в приложение через клиент а не веб портал?
Я пока не подтвердил это с клиентом, но он точно утверждал что его пользователи логинятся в Windows с аккаунтом из AD и в приложение с отдельным аккаунтом. Есть вероятность того что он не до конца понял наш вопрос о том где хранятся его пользователи. Главный его запрос к нам был обеспечить много-факторную аутентификацию именно в Dynamics. Подобное решение на уровне операционки мы уже предложили.

[Kabardian]

Цитата:

Сообщение от gl00mie

В стандарте так сделать нельзя, потому что из Dynamics AX, начиная с версии 4.0 (т.е. 2 версии назад), выкинули собственный механизм аутентификации, привязав всё к AD с использованием SSO.Тут нужно абстрагироваться от Аксапты

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

Другой вопрос, насколько оправдано это. Подозреваю, что в компании сложилась практика когда менеджерам часть работы могут помогать выполнять секретари, и ничего плохого в этом нет - менеджер при этом может отвлекаться только на подтверждение действительно важных операций, которые как я понял из топика и требуется подтверждать. Проведите аналогию, например, с розничной торговлей и ролями кассир, старший кассир, если даже взять сценарии из стандартной коробки AX 2009/2012 Retail - там кассир по-сути операционист и выплоняет 95% работы, кассиров много и они могут ошибаться, тогда например, сброс чека может выполнить только старший кассир со своим паролем. Здесь скорее всего, аналогичная ситауция, и нужно придумать работающее решение. Если ситуация именно такая, то первый вопрос приходящий на ум - почему у секретарей нет своего логина и своих прав доступа? Возможно, ограниченное количество рабочих мест и за одним рабочим местом работают сразу несколько сотрудников поочередно и т. п. В общем, фантазировать можно много на эту тему.. и до тех пор пока не будет больше вводной информации о том как это сейчас работают у клиента, и почему именно так от топикстартера, ситуация совсем непонятная.

Цитата:

Сообщение от gl00mie

Выходит, дело не в SSO, не в использовании AD для аутентификации пользователей, а в некоторых бизнес-процессах, требующих одобрения менеджерами тех или иных документов/действий. И сейчас просто менеджерам неудобно это делать в Аксапте самостоятельно, потому они и передают свои учетные данные посторонним людям, чтобы те выполняли одобрение за них.

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

Цитата:

Сообщение от gl00mie

Если так, то идти, мне кажется, нужно в противоположном направлении: не пытаться усложнить менеджерам вход в Аксапту, а напротив, упростить им одобрение тех или иных документов/действий в системе. Это решается иначе, например, через функционал Workflow: в 2012-й куча бизнес-процессов может быть штатно привязана к Workflow, выполняющемуся на базе Windows Workflow Foundation (WF). WF позволяет "выходить за рамки" системы, в частности, уведомление о том, что пользователю передан на одобрение тот или иной документ или действие, может приходить в т.ч. на электронную почту, можно прямо в том же Outlook "проголосовать" - и ответ вернется в WF, повлияв на дальнейшее выполнение бизнес-процесса в Аксапте. См. также Workflow examples.

А вот с воркфлоу идея и правда интересная, но требует больше усилий для решения вопроса, чем просто сделать двухшаговую аутентификацию:

• обосновать ключевым пользователям/безопасникам необходимость воркфлоу и плюшки от его использования
• научить сотрудников работать с воркфлоу
• настроить/поддерживать воркфлоу
• разработать/настроить воркфлоу для конкретных бизнес-процесов (скорее всего нужных не будет)

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

[Kabardian]

Цитата:

Сообщение от ndabbot

Поясните пожалуйста, по тем документам, которые я прочитал на сайте МС, я так понял что есть возможность заводить пользователей вне AD, т.н. claim-based user.

Такая возможность есть, но не вижу смысла ее обсуждать - мы отвлекаемся от темы.

Цитата:

Сообщение от ndabbot

Может я не до конца понимаю концепцию, но разве это не решает вопрос с пользователями не интегрированными в AD? Может ли claim-based user заходить в приложение через клиент а не веб портал?

Если вкратце, то обычный клиент поддерживает только windows-аутентификацию, а корпоративный портал - как windows-аутентификацию, так и аутентификацию на основе форм (логин и пароль, которых нет в Active Directory). Лучше у вашего клиента получить больше вводных какие виды аутентификации у него есть сейчас применяются и какое у него видение о том, как в идеале должен работать дополнительный этап аутентификации. А то мы сейчас даже не знаем что хочет клиент, как у него сейчас все работает, а уже пытаемся продумать решение .

Цитата:

Сообщение от ndabbot

Я пока не подтвердил это с клиентом, но он точно утверждал что его пользователи логинятся в Windows с аккаунтом из AD и в приложение с отдельным аккаунтом. Есть вероятность того что он не до конца понял наш вопрос о том где хранятся его пользователи.

Вот, надо уточнять.

Цитата:

Сообщение от ndabbot

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

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