Прочитав на сайте Wired.com опубликованную еще в 2012 году статью Kill the Password: A String of Characters Won’t Protect You (http://www.wired.com/2012/11/ff-mat-honan-password-hacker/), я пересмотрел свое отношение к паролям. Никому сегодня не нужно объяснять, сколь важно ограждать информацию от посягательств злоумышленников, и я уже давно защищаю свои данные с помощью сложных паролей, которые к тому же часто меняю. Но, когда я прочел эту статью, мне стало буквально не по себе: с какой же легкостью злоумышленники взламывают защищенные паролями учетные записи!

Теперь везде, где только возможно, я защищаю свои данные с помощью средств многофакторной аутентификации Multi-Factor Authentication (MFA). И не могу понять, почему пользователи платформы Office 365 до сих пор удовлетворяются средствами парольной защиты. Должен признаться: у меня нет точных сведений относительно того, какой процент пользователей Office 365 применяет средства MFA. Но неофициальное исследование, проведенное мною среди знакомых, показывает, что использование средств MFA не является нормой. Возможно, все дело в опасениях, что необходимость выполнения дополнительных аутентификационных процедур будет раздражать пользователей и сбивать их с толку. Мой опыт показывает, что на практике дела обстоят иначе, однако я вполне понимаю тех, кто придерживается такой точки зрения. Но как бы то ни было, теперь, когда средства аутентификации на базе OAuth (иногда именуемые средствами современной аутентификации) реализованы как в последней версии Office 2013, так и в Office 2016, надо полагать, что для администраторов наступило самое время рассмотреть вопрос о том, смогут ли средства MFA обеспечить защиту пользовательских данных.

Знакомство со средствами MFA платформы Office 365

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

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

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

Вспомогательные методы аутентификации, реализованные в пакете Azure Active Directory, многообразны и включают в себя телефонный звонок, текстовое сообщение, оповещение средствами мобильного приложения, код верификации и маркеры OATH от независимых поставщиков (это не опечатка — между стандартом OAuth и маркерами OATH существует определенное различие). Более подробные сведения о средствах MFA, реализованных в пакете Azure Active Directory, можно найти на сайте разработчика.

Azure Active Directory — это служба подтверждения полномочий Office 365. Чтобы подтвердить свои права доступа к службам с помощью пакета OAuth 2.0, приложения, разработанные для взаимодействия с MFA, используют библиотеку Active Directory Authentication Library (ADAL). OAuth — это открытый стандарт предоставления прав доступа, поддерживаемый многими другими поставщиками. Используя библиотеку ADAL, клиентские приложения, такие как Outlook или Outlook Web App, получают доступ к данным пользователей с помощью маркеров доступа, выдаваемых в процессе аутентификации. Применение маркеров доступа обеспечивает приложениям возможность продолжать обращаться к данным, не расходуя ресурсы на хранение или предоставление учетной информации пользователей.

Применяется два типа маркеров. Маркер refresh token выдается после успешного подтверждения аутентичности пользователя. Это главный маркер, служащий для получения маркеров, которые необходимы для обращения к данным пользователя. Так, при первом подключении клиента Outlook к системе Office 365 и подтверждении прав доступа к ней маркер refresh token предоставляется службой Azure Active Directory. После этого Outlook может использовать данный маркер для получения маркеров доступа, действительных для системы Exchange. Тот же refresh token действителен на всем пространстве Office 365, так что, если у программ Word или Excel возникает необходимость обращения к данным SharePoint или OneDrive for Business, клиентские приложения могут запросить маркер доступа, действительный для упомянутых серверных приложений. На данную ситуацию можно взглянуть и под другим углом: маркер доступа всегда задается ресурсом — будь то Exchange, SharePoint или какая-либо другая программа.

Если маркер refresh token не используется, срок его действия составляет две недели. Однако, если этот маркер применяется для генерирования маркеров доступа, он обновляется средствами Azure Active Directory. Разумеется, если вы выйдете из системы на срок свыше двух недель и не будете обращаться к Office 365 на протяжении этого времени, срок действия refresh token истечет, и вам придется вновь создавать его в процессе аутентификации.

Активация MFA для учетных записей Office 365

Активация MFA для учетных записей Office 365 осуществляется без каких-либо затруднений. Зарегистрируйтесь в центре администрирования Office 365 Admin Center, перейдите на вкладку Users и щелкните ссылку Setup рядом со строкой Set multi-factor authentication requirements. Теперь вы сможете активировать средства MFA для целой группы учетных записей или для отдельных учетных записей по своему выбору. Запустите процесс, щелкнув на пункте Enable, а затем укажите учетные записи, для которых должны быть активированы средства MFA.

В процессе следующей регистрации пользователей под активированными сейчас учетными записями каждому пользователю будет предложено дополнить процесс активации средства MFA указанием второго метода проверки подлинности личности. Как вы можете убедиться, взглянув на экран 1, я выбрал метод отправки текстового сообщения на мобильный телефон. На указанный номер телефона направляется SMS-сообщение, содержащее шестизначный код, и получатель для завершения процесса должен ввести это число в браузер.

 

Выбор методов верификации для средств MFA
Экран 1. Выбор методов верификации для средств MFA

Разработчики Azure Active Directory объединили указываемый пользователем номер мобильного телефона с соответствующей учетной записью. Когда для той или иной записи требуется дополнительная проверка подлинности, служба Azure Active Directory направляет по заданному номеру код верификации, и пользователь может ввести данный код в ответ на запрос. Этот метод с успехом применяется в браузерных приложениях и в современных мобильных приложениях, которые используют библиотеку ADAL, например в приложении Office 365 Groups. Кроме того, телефоны могут использоваться в процессе аутентификации посредством реакции на звонок. В этом случае пользователь принимает телефонный вызов и завершает процесс подтверждения подлинности нажатием на экране набора номера значка «решетка» (#).

Альтернативные методы аутентификации

Разработчики службы Azure Active Directory предусмотрели возможность применения методов многофакторной аутентификации в таких, например, случаях, когда пользователи перепутали свои смартфоны. Разумеется, никто из пользователей не предполагает, что ему придется прибегнуть к альтернативному методу, пока не возникнет критическая ситуация, но здесь у администраторов есть прекрасный повод принять решение о том, следует ли реализовать подобные методы в организации.

Иногда телефонные звонки и текстовые сообщения не могут быть применены в качестве механизмов проверки подлинности пользователей. Так, работающие с соединениями WiFi пассажиры авиалайнеров не имеют возможности завершить процесс аутентификации с помощью телефонного звонка или текстового сообщения. Но при наличии WiFi-соединения вы можете получать извещающие уведомления (push notifications) с помощью приложения Azure Authenticator (существуют версии для iOS, Android и Windows Phone). Это приложение, кстати, можно применять и в автономном режиме для генерации кодов, которые могут использоваться в процессе аутентификации. Понятно, что пользователям, не располагающим ни приложением Authenticator, ни доступом к сетевому соединению, придется довольствоваться теми вариантами автономного доступа, которые обеспечивают их клиенты.

Прежде чем воспользоваться средством аутентификации, вам придется из своей учетной записи Office 365 активировать его в качестве механизма верификации. Делается это так. Перейдите в раздел Office 365 Settings, выберите вкладку Additional security verification и щелкните на пункте Update your phone numbers used for account security. После этого вы сможете добавить приложение Azure Authenticator к списку программ, поддерживаемых вашей учетной записью, и завершить процесс настройки (см. экран 2).

 

Настройка приложения authenticator
Экран 2. Настройка приложения authenticator

Пароли приложений

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

 

Просмотр пароля приложения
Экран 3. Просмотр пароля приложения

Получив пароль приложения, пользователь должен обеспечить его неприкосновенность, поскольку этот пароль потребуется для проверки прав доступа средствами некоторых приложений, включая мобильные телефоны, оснащенные технологией ActiveSync. Освоить эту часть процесса труднее всего, поскольку, хотя у вас может быть несколько паролей приложений (скажем, по одному на каждое приложение или по одному на устройство), все эти пароли генерируются автоматически и, похоже, выдаются нам с гарантией: их ни за что не вспомнишь в тот момент, когда это потребуется. Средства MFA никак не проявляют себя сразу после активации: на данный момент у пользователей могут быть задействованы существующие соединения, срок действия которых должен истечь или которые должны быть разорваны перед тем, как новый режим аутентификации вступит в силу. Обычно первыми требуют использования средств MFA браузерные соединения (включая соединения с SharePoint и с OneDrive при открытии файлов, хранящихся в этих репозиториях). За ними следуют другие приложения, такие как Outlook 2016. После завершения проверки подлинности ее результаты остаются действительными в течение 14 дней.

Использование средств MFA

На то, чтобы привыкнуть к работе со средствами MFA, уходит некоторое время, но скоро эти навыки становятся вашей «второй натурой». Система не предлагает вам вводить свои учетные данные чаще, чем раньше, однако, когда это происходит, процесс проверки подлинности складывается из двух этапов. В большинстве случаев получение текстового сообщения с верификационным кодом (см. экран 4) никаких сложностей не вызывает. Единственная проблема, с которой мне приходилось сталкиваться при работе за пределами моей страны проживания, состояла в том, что иногда имела место некоторая задержка с передачей сигнала. Это телекоммуникационные компании прикидывали, как донести сообщение SMS с кодом верификации до моего мобильника. Что ж, таковы особенности роуминга. Пожалуй, в подобных случаях удобнее пользоваться приложением Azure Authenticator.

 

Введение одноразового кода, полученного через SMS
Экран 4. Введение одноразового кода, полученного через SMS

MFA и пакет PowerShell

Самая серьезная проблема, с которой мне довелось столкнуться, заключалась в отсутствии средств работы с многофакторной аутентификацией в среде PowerShell. Когда пользователь начинает сеанс удаленной работы с PowerShell с помощью подключения через Office 365, он может идентифицировать себя, только предоставив свое имя пользователя и пароль, так как механизм для передачи второго фактора аутентификации, включая пароли приложений, в этом случае не предусмотрен. Единственное решение — создать отдельную учетную запись для работы с PowerShell. Само по себе это несложно, к тому же отделение административных действий (которые вы будете выполнять с использованием PowerShell) от рутинных процедур взаимодействия с Office 365 отвечает требованиям безопасности. Кстати, специалисты Microsoft сейчас работают над оснащением PowerShell средствами MFA, так что в будущем вы сможете использовать различные методы верификации. Учтите, что, возможно, на первых порах модули PowerShell для различных приложений, включая Exchange, не будут поддерживать работу средств MFA. Но даже если такая поддержка и будет реализована, я все равно рекомендовал бы рассмотреть возможность использования отдельной учетной записи для работы с PowerShell.

Среда PowerShell может использоваться для просмотра учетных записей, настроенных для применения средств MFA. Как разъясняется в статье, подготовленной обладателем статуса Microsoft MVP Мишелем де Руиж, публикуемый в приведенном листинге код вы можете использовать для определения учетных записей Office 365, применяющих средства многофакторной аутентификации, а также для выявления методов, используемых для дополнительной проверки подлинности. Приведенные ниже данные показывают, что обе учетные записи настроены для использования аутентификации с помощью SMS (OneWaySMS), а также звонков по мобильному телефону (TwoWayVoiceMobile). Помимо прочего, вы можете использовать PowerShell для управления настройками MFA для учетных записей, хотя большинство пользователей устроит обращение в центр администрирования Office 365 Admin Center.

Казус с привередливым браузером

Более занятная проблема возникла в связи с тем, что Internet Explorer внезапно стал отказывать мне в соединении с использованием средств MFA (см. экран 5). Я работал под управлением новейшей версии Windows 10 (10586, или редакция Threshold 2); при этом, в отличие от IE, как Edge, так и Chrome работали с MFA без каких-либо нареканий. Я сделал все, что полагается в таких случаях: очистил кэш браузера и навел в Интернете справки по коду ошибки 50012, но оптимального решения так и не нашел. Проблема сохранялась в течение недели или чуть больше. В конце концов я решил деактивировать средства MFA для своей учетной записи и посмотреть, как на это отреагирует IE. Браузер работал после деактивации средств MFA и продолжал исправно функционировать и после ее повторного включения. Таким образом я получил еще одно подтверждение тому, что отключение функции с ее последующей активацией часто позволяет решить проблему.

 

Ошибка в работе IE
Экран 5. Ошибка в работе IE

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

Вопрос планирования

Разумеется, реализация средств MFA — это не такой шаг, на который вы решаетесь просто потому, что вам очень захотелось. Здесь я не рассматриваю тот случай, когда кто-то хочет сокрушить справочную службу, обрушив на нее лавину звонков от возмущенных пользователей, желающих обратиться к своим почтовым ящикам. В таких делах требуется предварительная подготовка, и в первую очередь — уведомление пользователей. Все они должны иметь представление о том, что именно происходит и как нужно реагировать на приглашение к проведению дополнительной верификации. Кроме того, целесообразно удостовериться в том, что приложения нормально функционируют с активированными средствами MFA, и составить список ответов на часто задаваемые вопросы (возможно, по образцу списка, подготовленного по данной теме специалистами Microsoft, https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-end-user-manage-settings/). Ознакомившись с этим списком, пользователи будут знать, чего им следует ожидать в процессе выполнения процедуры аутентификации.

Хотя специалисты Microsoft реализовали средства MFA во всей платформе Office 365, рассматриваемая функция не ограничена «облачной» службой. Механизм многофакторной аутентификации Azure Active Directory можно настроить и для обслуживания почтовых ящиков, размещенных на локальном оборудовании. Обладатель статуса Microsoft MVP Брайан Рийд раскрывает эту тему в своем журнале по адресу http://www.c7solutions.com/2015/01/exchange-owa-and-multi-factor-authentication. Кроме того, дополнительную информацию по реализации MFA в локальных приложениях, а также по планированию развертывания гибридных систем можно получить в Microsoft (https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-server/и https://support.office.com/en-us/article/Plan-for-multi-factor-authentication-for-Office-365-Deployments-043807b2-21db-4d5c-b430-c8a6dee0e6ba).

Ну и, разумеется, если вы не работаете с Office 365, но хотите защитить системы Exchange с помощью средств MFA, к вашим услугам множество решений, предлагаемых независимыми поставщиками; в этом вы сможете убедиться сами, выполнив простую процедуру поиска в Интернете.

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

С течением времени функции многофакторной аутентификации реализуются во все большем числе приложений, и в конечном итоге их применение станет нормой. Для иллюстрации этой мысли отмечу, что недавно специалисты Microsoft оснастили функциями MFA средства защиты управления правами Windows Rights Management (http://blogs.technet.com/b/rms/archive/2015/10/14/fall-update-document-tracking-ga-multi-factor-authentication-outlook-android-support-and-public-preview-for-rms-sharing-app-for-non-admin-users.aspx) для целого ряда клиентов, включая приложения Office 2016. Это полезное решение, подчеркивающее уязвимость информации в представлении получателей, которые могут получить доступ к тому или иному защищенному файлу, только идентифицировав себя с помощью механизма MFA.

В целом корпорация Microsoft осуществила простую в обращении реализацию механизма MFA внутри Office 365 и выпускает приложения, использующие этот механизм. Предлагаемое решение характеризуется определенным уровнем гибкости: клиенты не обязаны применять средства MFA, а если эти средства активированы, число их пользователей может быть ограничено заданными учетными записями. Так что, если вы сегодня не пользуетесь средствами MFA, может быть, стоит испытать их на небольшом числе учетных записей. В конце концов, что вы потеряете, повысив свой уровень защищенности?

Листинг. Определение альтернативного метода аутентификации
Get-MsOlUser | Where {$_.StrongAuthenticationRequirements} | Select UserPrincipalName, @{n=»MFA»; e={$_.StrongAuthenticationRequirements.State}}, @{n=»Methods»; e={($_.StrongAuthenticationMethods).MethodType}}
UserPrincipalName                      MFA      Methods                      
-----------------                      ---      -------                      
John.Smith@Office365ExchangeBook.com   Enforced {OneWaySMS, TwoWayVoiceMobile}
Ed.Banti@office365exchangebook.com     Enforced {OneWaySMS, TwoWayVoiceMobile}