Методы защиты при использовании аутентификации по паролю. Для защиты паролей от взлома следует настроить соответствующую политику. Для этого необходимо с помощью меню Start->Administrative Tools-> Group Policy Management запустить консоль управления групповыми политиками GPMC, выбрать требуемый объект групповой политики раздел Computer Configuration->Policies->Security Settings->Account Policies->Password Policy См. Рис. 1 (Управление параметрами паролей).
Рис. 1 Управление параметрами паролей.
Можно задать минимальную длину пароля, что позволит нам избежать коротких паролей (Minimum password length ). Для того чтобы, пользователь задавал сложные пароли следует включить требование сложности (Password must meet complexity requirements ).
Для обеспечения регулярной смены пароля нужно задать его максимальный срок жизни (Maximum password age ).
Для того чтобы, пользователи не повторяли старые пароли, требуется настроить хранение истории паролей (Enforce password history ) .
Ну и наконец, для того, чтобы пользователь не менял свой пароль на старый путем многократной смены паролей, задать минимальный срок, в течение которого пароль нельзя поменять (Minimum password age ).
Для того, защиты от атаки по словарю, настроим блокировку учетной записи при неоднократном неправильном вводе пароля. Для этого необходимо в консоли управления групповыми политиками GPMC выбрать требуемый объект групповой политики раздел Computer Configuration -> Policies -> Security Settings -> Account Policies -> Account Lockout Policy . См. Рис. 2 (Управление блокировкой учетной записи пользователя).
Рис. 2 Управление блокировкой учетной записи пользователя.
Для настройки окончательной блокировки учетной записи (до разблокирования ее администратором) следует задать нулевое значение параметру продолжительности блокировки (Account lockout duration ).
В счетчике количества неуспешных попыток входа в сеть (Account lockout threshold ) нужно указать требуемое значение. В большинстве случаев приемлемым вариантом является 3-5 попыток входа.
Наконец, следует задать интервал сброса счетчика неуспешных попыток (Reset account lockout counter after ).
Для защиты от «троянских коней» следует использовать антивирусные средства и блокировку несанкционированного программного обеспечения.
Для ограничения возможностей пользователей по внесению вирусов в информационную систему, оправдано: настройка запрета на работу с внешними устройствами (CD, DVD, Flash), строгий режим работы UAC, использование отдельно стоящих Интернет киосков, на базе компьютеров не входящих в состав рабочей сети. И, наконец, внедрение строгих регламентов работы, определяющих правила работы пользователей в корпоративной сети (запрет передачи своих учетных данных кому бы то ни было, запрет оставлять свои учетные данные в доступных местах, требования обязательной блокировки рабочей станции при оставлении рабочего места, и. т. п.).
В результате, мы сможем добиться уменьшение рисков, связанных с нарушением безопасности компании.
Предположим, все это сделано. Тем не менее, говорить о том, что нам удалось обеспечить безопасную аутентификацию в своей системе, пока преждевременно.
Человеческий фактор – самая большая угроза.
Существуют еще угрозы, справиться с которыми нам не удалось. Одна из наиболее существенных – человеческий фактор. Пользователи наших информационных систем не всегда достаточно сознательны и, несмотря на разъяснения администраторов безопасности, записывают свои учетные данные (имя пользователя и пароль) и не заботятся о секретности этой конфиденциальной информации. Мне не раз доводилось обнаруживать стикеры на мониторе см. Рис. 3, или под клавиатурой см. рис. 4 с именем пользователя и паролем.
Рис. 3. Замечательный подарок злоумышленнику, не так ли?
Рис. 4. Еще один подарок взломщику.
Как мы можем видеть, в системе внедрены длинные и сложные пароли и ассоциативный ряд явно не просматривается. Тем не менее, пользователи нашли «эффективный» способ запоминания и хранения учетных данных…
Таким образом, вы видите, что в этом случае как раз и сработала особенность, о которой я говорил выше: Длинные и сложные пароли записываются, и могут храниться не надлежащим образом.
Инсайдинг
Еще одна существенная угроза безопасности заключается в потенциальной возможности физического доступа злоумышленника к рабочей станции легального пользователя и передача конфиденциальной информации третьим лицам. Т. е. речь идет о ситуации, когда внутри компании существует сотрудник, похищающий информацию у своих коллег.
Вполне очевидно, что «физическую» безопасность рабочей станции пользователя обеспечить очень трудно. В разрыв клавиатуры можно без труда подключить аппаратный клавиатурный шпион (keylogger), перехват сигнала от беспроводных клавиатур тоже возможен. Такие устройства существуют. Разумеется, кто попало не пройдет в офис компании, однако всем известно, что самым опасным является внутренний шпион. У него уже есть физический доступ к вашей системе, и разместить клавиатурный шпион, не составит труда, тем более эти устройства доступны широкому кругу лиц. Кроме того, нельзя сбрасывать со счетов программы – клавиатурные шпионы. Ведь, несмотря на все усилия администраторов, возможность установки такого «шпионского» программного обеспечения не исключена. Всегда ли пользователь блокирует свою рабочую станцию, покидая свое рабочее место? Удается ли администратору информационной системы добиться, чтобы пользователю не назначались избыточные полномочия, особенно при необходимости использования старых программных продуктов? Всегда ли администратор, а особенно в небольшой компании, обладает достаточной квалификацией, чтобы внедрить рекомендации производителей программного и аппаратного обеспечения по построению безопасных информационных систем?
Таким образом, можно сделать вывод о ненадежности парольной аутентификации в принципе. Следовательно, требуется аутентификация многофакторная, при этом такого вида, чтобы пароль пользователя не набирался на клавиатуре.
Что нам может помочь?
Имеет смысл, рассмотреть двухфакторную аутентификацию: 1-ый фактор обладание паролем, 2-ой знание пин кода. Доменный пароль больше не набирается на клавиатуре, значит, не перехватывается клавиатурным шпионом. Перехват доменного пароля чреват возможностью входа, перехват пин кода не так опасен, т. к. дополнительно требуется смарт карта.
На это можно возразить, что пользователь вполне может оставить свою карту в считывателе, а пин написать на стикере, как и раньше. Однако существуют системы контроля, которые могут заблокировать оставленную карту как, это реализовано в банкоматах. Дополнительно существует возможность разместить на карте пропуск для входа/выхода из офиса, т. е. мы можем использовать карточку с RFID меткой, объединив тем самым систему аутентификации в службе каталога с системой разграничения физического доступа. В этом случае для того, чтобы открыть дверь пользователю потребуется его смарт карта или USB токен, так что он будет вынужден ее всегда носить с собой.
Кроме того, современные решения для двухфакторной аутентификации предполагают не только возможность аутентификации в AD или AD DS. Использование смарт карт и USB-ключей помогает и во многих других случаях, например при доступе к публичной электронной почте, в Интернет магазины, где требуется регистрация, к приложениям, имеющим свою собственную службу каталога и. т. д.
Таким образом, можно получить практически универсальное средство аутентификации.
Внедрение двухфакторной аутентификации на основе асимметричной криптографии в AD DS.
Служба каталога Active Directory поддерживает возможность аутентификации с помощью смарт карт, начиная с Windows 2000.
По сути своей, возможность аутентификации с помощью смарт карт заложена в расширении PKINIT (public key initialization – инициализация открытого ключа) для протокола Kerberos RFC 4556. См. . Расширение PKINIT позволяет использовать сертификаты открытого ключа на этапе предаутентификации Kerberos.
Благодаря чему и появляется возможность использования смарт карт. Т. е. мы можем говорить о возможности двухфакторной аутентификации в системах Microsoft на основе штатных средств, начиная с ОС Windows 2000, т. к. уже реализована схема Kerberos + PKINIT.
Примечание. Предаутентификация Kerberos – процесс, обеспечивающий дополнительный уровень безопасности. Выполняется до выдачи TGT (Ticket Granting Ticket ) от сервера распространения ключей (KDC ). Используется в протоколе Kerberos v . 5 для противодействия оффлайн атакам на угадывание пароля. Подробнее о принципах работы протокола Kerberos можно узнать в RFC 4120. C м
Разумеется, речь идет о компьютерах в составе домена. Если же есть необходимость прибегнуть к двухфакторной аутентификации при работе в рабочей группе, или при использовании более ранних версий операционных систем, то нам придется обратиться к программному обеспечению третьих фирм, например SafeNet (Aladdin) eToken Network Logon 5.1. См.
Вход в систему может быть обеспечен, как при использовании службы каталога домена, так и локальной службы каталога. При этом пароль пользователя не набирается на клавиатуре, а передается из защищенного хранилища на смарт карте.
Аутентификация с помощью смарт карт реализуется посредством расширения Kerberos PKINIT, это расширение обеспечивает возможность использования асимметричных криптографических алгоритмов.
Что касается требований для внедрения использования смарт карт в связке с PKINIT, то для операционных систем Windows 2000, Windows 2003 Server, они следующие:
· Все контроллеры доменов и все клиентские компьютеры в рамках леса, где осуществляется внедрение нашего решения, обязательно должны доверять корневому Удостоверяющему Центру (Центру Сертификации).
· Удостоверяющий центр, выдающий сертификаты для использования смарт карт, должен быть помещен в хранилище NT Authority
· Сертификат должен содержать идентификаторы Smart Card Logon и Client Authentication
· Сертификат для смарт карт должен содержать UPN пользователя.
· Сертификат и частный ключ должны быть помещены в соответствующие разделы смарт карты, при этом частный ключ должен находиться в защищенной области памяти смарт карты.
· В сертификате должен быть указан путь к списку отзыва сертификатов CRL distribution point
· Все контроллеры доменов должны иметь установленный сертификат Domain Controller Authentication, или Kerberos Authentication, т. к. реализуется процесс взаимной аутентификации клиента и сервера.
Целый ряд изменений в требованиях произошел в операционных системах, начиная с Windows Server 2008:
· Больше не требуется CRL extension в сертификатах smart card logon
· Теперь поддерживается возможность установки взаимосвязи между учетной записью пользователя и сертификатом
· Запись сертификата возможна в любой доступный раздел смарт карты
· Расширение EKU не обязано включать Smart Card Logon OID, при этом справедливости ради надо отметить, что если вы планируете использовать единственный шаблон сертификата для клиентов всех операционных систем, то, разумеется, Smart Card Logon OID должен быть включен.
Несколько слов о самой процедуре входа клиента. Если говорить об операционных системах от Windows Vista и выше, то следует отметить, что и тут произошел ряд изменений:
· Во-первых, процедура входа в систему по смарт карте больше не инициируется автоматически, когда вы вставили смарт карту в карт ридер, или подключили ваш USB -ключ к USB порту, т. е. вам придется нажать Ctrl+Alt+Delete.
· Во-вторых, появившаяся возможность использования любого слота смарт карты для хранения сертификатов предоставляет пользователю выбор из множества идентификационных объектов, хранящихся на карте, при этом необходимый в данный момент сертификат отображается как доступный к использованию.
Выводы
Итак, мы разобрали несколько основных аспектов, касающихся теоретической части двухфакторной аутентификации в Active Directory Domain Services, и можно подвести итоги.
Обеспечение безопасности процесса аутентификации в системе критически важно. Существующие на сегодняшний день виды взломов паролей формируют потребность в мультифакторной аутентификации.
Для небольшой компании можно ограничиться строгой политикой защиты учетных данных, внедрением антивирусного программного обеспечения, лишить пользователей возможности работы с внешними носителями информации блокировать запуск несанкционированного программного обеспечения, внедрить регламенты работы пользователей и. т. п.
Когда речь идет крупной компании, или о компании, в которой есть явная заинтересованность со стороны злоумышленников – этих средств недостаточно. Ошибки и инсайдинг могут свести на нет усилия по построению системы защиты, поэтому надо выбрать другой путь. Здесь уже имеет смысл говорить о внедрении безопасной аутентификации.
Использование двухфакторной аутентификации – хорошее решение с точки зрения безопасности.
У нас появляется второй фактор аутентификации, помимо пин кода, пользователю надо обладать еще и смарт картой, или USB ключом.
Использование смарт карт или USB ключей дает нам возможность обеспечить двухфакторную аутентификацию как в среде AD, так и в AD DS.
В одной из следующих статей я расскажу, как осуществляется внедрение двухфакторной аутентификации на практике. Мы рассмотрим развертывание и настройку инфраструктуры удостоверяющих центров (PKI) на основе Windows Server 2008 Enterprise R2.
Список литературы.
Http://www.rfc-archive.org/getrfc.php?rfc=4556
Http://www.rfc-archive.org/getrfc.php?rfc=4120
Http://www.aladdin.ru/catalog/etoken_products/logon
NCSC-TG-017 – "A Guide to Understanding Identification and Authentication in Trusted Systems," опубликованный U.S. National Computer Security Center.
RFC4120 – The Kerberos Network Authentication Service (V5)
RFC4556 – Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Brian Komar Windows Server 2008 PKI and Certificate Security
Леонид Шапиро,
MCT, MCSE:S, MCSE:M, MCITP EA, TMS Certified Trainer
1) В самом начале настройки сервера, вводите команду:
multiotp.exe -debug -config default-request-prefix-pin=0 display-log=1 после неё не требуется вводить пин-код при настройке пользователя и включается отображение лога каждой операции в консоль.
2) С помощью этой команды можно регулировать bantime, для пользователей, которые ошиблись с паролем (по умолчанию 30 сек):
multiotp.exe -debug -config failure-delayed-time=60
3) То, что будет написано в приложении google Authenticator над 6 цифрами, называется issuer, можно поменять с дефолтного MultiOTP на что-то другое:
multiotp.exe -debug -config issuer=other
4) После проделанных операций, команда по созданию пользователя становится чуть проще:
multiotp.exe -debug -create user TOTP 12312312312312312321 6
(время обновления цифр, равное 30 секундам, я не задаю, кажется оно по умолчанию равно 30).
5) Каждому пользователю можно изменить description (текст под цифрами в приложении Google Auth):
multiotp.exe -set username description=2
6) QR-коды можно создавать сразу в приложении:
multiotp.exe -qrcode username c:\multiotp\qrcode\user.png:\multiotp\qrcode\user.png
7) Можно использовать не только TOTP, но и HOTP (на вход функции хэширования подаётся не текущее время, а значение инкрементального счетчика):
multiotp.exe -debug -create username HOTP 12312312312312312321 6
Пароль является не очень надежным средством защиты. Очень часто используются простые, легко подбираемые пароли или же пользователи не особо следят за сохранностью своих паролей (раздают коллегам, пишут на бумажках и т.д.). В Microsoft уже давно реализована технология, позволяющая для входа в систему использовать SmartCard, т.е. аутентифицироваться в системе по сертификату. Но не обязательно использовать непосредственно смарт-карты, ведь для них нужны еще и считыватели, поэтому проще их заменить на usb токены. Они позволят реализовать двухфакторную аутентификацию: первый фактор — это пароль от токена, второй фактор — это сертификат на токене. Далее на примере usb токена JaCarta и домена Windows я расскажу как внедрить этот механизм аутентификации.
Первым делом в AD создадим группу «g_EtokenAdmin» и уч. запись «Enrollment Agent», входящую в эту группу. Эта группа и пользователь будут рулить центром сертификации.
Дополнительно установим Web службу для запроса сертификатов.
Далее выбираем вариант для предприятия. Выбираем Корневой ЦС (если у нас это первый центр сертификации в домене)
Создаем новый закрытый ключ. Длину ключа можно оставить туже, а вот алгоритм хеширования лучше выбрать SHA2 (SHA256).
Введем имя CA и выберем срок действия основного сертификата.
Остальные параметры оставляем по умолчанию и запускаем процесс установки.
После установки зайдем в оснастку центра сертификации и настроим права на шаблоны.
Нас будут интересовать два шаблона: Агент регистрации (Enrollment Agent) и Вход со смарт-картой (Smartcard logon).
Зайдем в свойства этих шаблонов и на вкладке безопасность добавим группу «g_EtokenAdmin» с правами чтение и заявка.
И они появятся у нас в общем списке.
Следующим шагом настроим групповые политики:
Первым делом расскажем всем компьютерам домена о корневом центре сертификации, для этого изменим Default Domain Policy.
Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Политики открытого ключа -> Доверенные корневые центры сертификации -> Импорт
Выберем наш корневой сертификат, расположенный по пути: C:\Windows\System32\certsrv\CertEnroll. Закрываем Default Domain Policy.
На следующем шаге создадим политику для контейнера, в котором будут находится компьютеры с аутентификацией по токену (Смарт-карте).
По пути Конфигурация компьютера -> Политики -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Параметры безопасности. Настроим два параметра «Интерактивный вход в систему: требовать смарт-карту» и «Интерактивный вход в систему: поведение при извлечении смарт-карты».
На этом с настройками все, теперь можно генерировать клиентский сертификат и проверять аутентификацию по токену.
Залогинемся на компьютере под учетной записью «Enrollment Agent» и откроем браузер, перейдя по ссылке http://Имя_сервера_MS_CA/certsrv
Выбираем пункт Запрос сертификата -> Расширенный запрос сертификата -> Создать и выдать запрос к этому ЦС
Если возникнет ошибка вида «Чтобы завершить подачу заявки на сертификат, следует настроить веб-узел для ЦС на использование проверки подлинности по протоколу HTTPS», то нужно на сервере IIS, на котором установлен MS CA, сделать привязку сайта к протоколу https.
Продолжим получение сертификата, для этого на открывшейся странице выберем шаблон: «Агент регистрации» и нажмем кнопку выдать и установить сертификат.
Теперь пользователь Enrollment Agent может выписывать сертификаты для других пользователей. К примеру запросим сертификат для пользователя test. Для этого откроем консоль управления сертификатами certmgr.msc, т.к. через web интерфейс не получится записать сертификат на usb токен.
В этой консоли на папке личное сделаем запрос от имени другого пользователя
В качестве подписи выбираем единственный сертификат «Enrollment Agent» и переходим к следующему шагу, на котором выбираем пункт «Вход со смарт-картой» и нажимаем подробности для выбора криптопровайдера.
В моем случае я использую токены JaCarta, поэтому вместе с драйверами был установлен криптопровайдер «Athena…»:
На следующем шаге выбираем доменного пользователя, для которого выписываем сертификат и нажимаем на кнопку «Заявка».
Вставляем токен, вводим пин код и начинается процесс генерации. В итоге мы должны увидеть диалоговое окно с надписью «Успешно».
Если процесс окончился неудачно, возможно дело в шаблоне получения сертификата, в моем случае его надо было немного подправить.
Приступим к тестированию, проверим работу токена на компьютере, находящемся в OU с групповой политикой входа по смарт-карте.
При попытке войти под учетной записью с паролем мы должны получить отказ. При попытке войти со смарт-картой (токеном) мы получим предложение ввести пин и должны успешно зайти в систему.
P.s.
1) Если не работает автоматическая блокировка компьютера или выход из системы, после вытаскивания токена, смотрите запущена ли служба «Политика удаления смарт-карт»
2) На токен можно записать (сгенерировать сертификат) только локально, через RDP не получится.
3) Если не получается запустить процесс генерации сертификата по стандартному шаблону «Вход с смарт-картой», создайте его копию с такими параметрами.
На этом все, если будут вопросы, задавайте, постараюсь помочь.
Сегодня расскажем, как можно быстро и просто настроить двухфакторную аутентификацию и зашифровать важные данные, причем даже с возможностью использования биометрии. Решение будет актуально для небольших компании или просто для персонального компьютера или ноутбука. Важно, что для этого нам не потребуется инфраструктура открытых ключей (PKI), сервер с ролью центра сертификации (Certificate Services) и даже не потребуется домен (Active Directory). Все системные требования будут сводиться к операционной системе Windows и наличию у пользователя электронного ключа, а в случае биометрической аутентификацией еще и считывателю отпечатка пальцев, который, например, может быть уже встроен в ваш ноутбук.
Для аутентификации будем использовать ПО нашей разработки – JaCarta SecurLogon и электронный ключ JaCarta PKI в качестве аутентификатора. Инструментом шифрования будет штатный Windows EFS, доступ к зашифрованным файлам будет осуществляться также через ключ JaCarta PKI (тот же, который используется для аутентификации).
Напомним, JaCarta SecurLogon - сертифицированное ФСТЭК России программно-аппаратное решение компании Аладдин Р.Д., позволяющее осуществить простой и быстрый переход от однофакторной аутентификации на основе пары логин-пароль к двухфакторной аутентификации в ОС по USB-токенам или смарт-картам. Суть работы решения довольно проста - JSL генерирует сложный пароль (~63 символа) и записывает его в защищенную память электронного ключа. При этом пароль может быть неизвестен самому пользователю, пользователь знает только ПИН-код. Вводя ПИН-код при аутентификации, происходит разблокировка устройства, и пароль передается системе для аутентификации. Опционально можно заменить ввод ПИН-кода сканированием отпечатка пальца пользователя, а также можно применить комбинацию ПИН + отпечаток пальца.
EFS также как и JSL умеет работать в режиме standalone, не требуя кроме самой ОС ничего. Во всех операционных системах Microsoft семейства NT, начиная с Windows 2000 и новее (кроме home версий), существует встроенная технология шифрования данных EFS (Encrypting File System). EFS-шифрование основано на возможностях файловой системы NTFS и архитектуре CryptoAPI и предназначено для быстрого шифрования файлов на жестком диске компьютера. Для шифрования в EFS используется закрытый и открытый ключи пользователя, которые генерируются при первом использовании пользователем функции шифрования. Данные ключи остаются неизменными все время, пока существует его учетная запись. При шифровании файла EFS случайным образом генерирует уникальный номер, так называемый File Encryption Key (FEK) длиной 128 бит, с помощью которого и шифруются файлы. Ключи FEK зашифрованы мастер-ключом, который зашифрован ключом пользователей системы, имеющего доступ к файлу. Закрытый ключ пользователя защищается хэшем пароля этого самого пользователя. Данные, зашифрованные с помощью EFS, могут быть расшифрованы только с помощью той же самой учетной записи Windows с тем же паролем, из-под которой было выполнено шифрование. А если хранить сертификат шифрования и закрытый ключ на USB-токене или смарт-карте, то для доступа к зашифрованным файлам потребуется еще и этот USB-токен или смарт-карта, что решает проблему компрометации пароля, так как будет необходимо наличие и дополнительного устройства в виде электронного ключа.
Аутентификация
Как уже отметили, для настройки не нужен AD или центр сертификации, нужен любой современный Windows, дистрибутив JSL и лицензия. Настройка проста до безобразия.Нужно установить файл лицензии.
Добавить профиль пользователя.
И начать пользоваться двухфакторной аутентификацией.
Биометрическая аутентификация
Есть возможность использовать биометрическую аутентификацию по отпечатку пальца. Решение работает по технологии Match On Card. Хэш отпечатка записывается на карту при первичной инициализации и в дальнейшем сверяется с оригиналом. Из карты никуда не уходит, в каких-то базах не хранится. Для разблокировки такого ключа используется отпечаток или комбинация ПИН + отпечаток, ПИН или отпечаток.Для начала использования нужно просто инициализировать карту с необходимыми параметрами, записать отпечаток пользователя.
В дальнейшем такое же окно будет всплывать перед входом в ОС.
В настоящем примере карта инициализирована с возможностью аутентификации по отпечатку или ПИН-коду, о чем и сообщает окно аутентификации.
После предъявления отпечатка или ПИН-кода, пользователь попадет в ОС.
Шифрование данных
Настройка EFS тоже не очень сложная, сводится к настройке сертификата и выпуску его на электронный ключ и настройки директорий шифрования. Как правило, шифровать весь диск не требуется. Действительно важные файлы, получать доступ к которым третьим лицам не желательно, обычно находятся в отдельных директориях, а не разбросаны абы как по диску.Для выпуска сертификата шифрования и закрытого ключа откройте учетную запись пользователя, выберите - Управление сертификатами шифрования файлов. В открывшемся мастере, создайте самозаверенный сертификат на смарт-карте. Так как мы продолжаем использовать смарт-карту с BIO-апплетом, для записи сертификата шифрования нужно предъявить отпечаток или ПИН.
На следующем шаге укажите директории, которые будут связаны с новым сертификатом, при необходимости можно указать все логические диски.
Сама шифрованная директория и файлы в ней будут подсвечены другим цветом.
Доступ к файлам осуществляется только при наличии электронного ключа, по предъявлению отпечатка пальца либо ПИН-кода, в зависимости от того что выбрано.
На этом вся настройка окончена.
Можно использовать оба сценария (аутентификация и шифрование), можно остановиться на чем-то одном.
Реалии стран где живёт большинство хабровчан таковы, что держать сервера с важной информацией за пределами страны ведения бизнеса стало хорошим тоном, позволяющим сохранить свои нервы и данные.
Первый вопрос, который возникает при переезде в облако после шифрования данных, а может и перед ним, это гарантия того, что доступ к данным с учетной записью пользователя осуществляется именно пользователем, а не кем-то еще. И если неплохой способ шифрования данных, размещенных в частном облаке, рассмотрен в статье моего коллеги , то с аутентификацией все сложнее.
Про пользователей и методы защиты
Природа типичного пользователя такова, что к сохранности паролей от учетных записей отношение достаточно легкомысленное и исправить это невозможно. Наш опыт показывает, что даже если в компании применяются строгие политики, тренинги пользователей и т.д., все равно найдется незашифрованное устройство, покинувшее стены офиса, а просматривая список продуктов одной известной компании понимаешь, что извлечение паролей из незашифрованного устройства лишь дело времени.
Некоторые компании для контроля доступа к данным в облаке устанавливают туннели между облаком и офисом, запрещают удаленный доступ https://habrahabr.ru/company/pc-administrator/blog/320016/ . На наш взгляд - это не совсем оптимальное решение, во-первых, теряется часть преимуществ облачного решения, а во-вторых есть проблемы с производительностью, отмеченные в статье.
Решение с использованием терминального сервера и Remote Desktop Gateway (RDG) более гибкое, можно настроить высокий уровень безопасности, как описал мой коллега https://habrahabr.ru/post/134860/ (статья 2011 года, но сам принцип до сих пор актуален). Данный способ позволяет предотвратить передачу данных из облака, но накладывает ограничения на работу пользователя и не полностью решает проблему аутентификации, скорее это DLP решение.
Возможно лучшим способом гарантировать, что под учетной записью пользователя не работает злоумышленник, является двухфакторная аутентификация . В статьях моего коллеги https://habrahabr.ru/post/271259/ https://habrahabr.ru/post/271113/ описывается настройка MFA от Microsoft и Google для клиентского VPN. Способ хороший, но, во-первых, он требует наличия CISCO ASA, что не всегда легко реализуемо, особенно в бюджетных облаках, а во-вторых, работа через VPN неудобна. Работа с терминальной сессией через RDG значительно комфортнее, да и SSL протокол шифрования выглядит более универсальным и надежным, чем VPN от CISCO.
Решений с двухфакторной аутентификацией на самом терминальном сервере много, вот пример настройки бесплатного решения - http://servilon.ru/dvuhfaktornaya-autentifikaciya-otp/ . Это решение, к сожалению, не работает через RDG.
RDG сервер запрашивает подтверждение авторизации у сервера MFA. MFA в зависимости от выбранного способа аутентификации звонит, отправляет смс или посылает запрос в мобильное приложение. Пользователь подтверждает или отклоняет запрос на предоставление доступа. MFA возвращает результат второго фактора аутентификации на RDG сервер.
Установка и настройка Azure Multi-Factor Authentication Server
Создание поставщика аутентификации в портале Microsoft Azure
Заходим в Microsoft Azure (учетная запись должна иметь подписку или установлена триальная версия) и находим Multi-Factor Authentication (MFA).На данный момент управление MFA не добавлено в новую версия портала Azure, поэтому откроется старая версия портала.
Для создания нового поставщика многофакторной проверки подлинности необходимо слева внизу нажать «СОЗДАТЬ → Службы приложений → Active directory → Поставщик многофакторной проверки подлинности → Быстрое создание». Указать имя и модель использования.
От модели использования зависит как будет начисляться оплата, либо по количеству пользователей, либо по количеству аутентификаций.
После создания MFA отобразится в списке. Далее переходим к управлению, нажав соответствующую кнопку.
Переходим в загрузки и скачиваем MFA сервер
Развертывание MFA сервера
Устанавливать MFA сервер необходимо на виртуальную машину отличную от RDG сервера. Поддерживаются ОС старше Windows Server 2008 или Windows 7. Для работы необходим Microsoft .NET Framework 4.0.Должны быть доступны адреса по 443 порту:
Устанавливаем MFA сервер, при установке отказываемся от мастера настроек.
При первом запуске необходимо ввести данные от учетной записи, которые надо сгенерировать на странице загрузки сервера.
Далее добавляем пользователей. Для этого переходим в раздел Users и нажимаем на Import from Active Directory, выбираем пользователей для импорта.
При необходимости можно настроить автоматическое добавление новых пользователей из АД:
«Directory Integration → Synchronization → Add», а т.ж. добавить каталог, который будет автоматически синхронизироваться по указанному интервалу времени.
Проведем тест работоспособности MFA сервера. Переходим в раздел Users. Для своей учетной записи указываем номер телефона (если еще не задан) и выбираем способ аутентификации «Звонок телефона». Нажимаем кнопку Test и вводим логин, пароль. На телефон должен прийти вызов. Отвечаем на него и нажимаем #.
Настройка MFA сервера на работу с Radius запросами
Переходим в раздел Radius Authentication и ставим галочку «Enable RADIUS Authentication».Добавляем нового клиента, указывая IP адрес NPS сервера и общий секретный ключ. Если аутентификация должна проводиться для всех пользователей, ставим соответствующую галочку (в данном случае все пользователи должны быть добавлены на MFA сервер).
Так же необходимо убедиться, что указанные для соединения порты соответствуют портам, указанным на NPS сервере и их не блокирует брандмауэр.
Переходим на вкладку Target и добавляем Radius сервер.
Примечание: Если в сети нет центрального NPS сервера, IP адреса Radius клиента и сервера будут одинаковыми.
Настройка RDG и NPS сервера на работу совместно с MFA
Шлюз удаленных рабочих столов необходимо настроить на отправку Radius запросов на сервер MFA. Для этого открываем свойства шлюза и переходим на вкладку «RDG CAP Store», выбираем «NPS работает на центральном сервере» и указываем адрес MFA сервера и общий секретный ключ.
Далее производим настройку NPS сервера. Разворачиваем раздел «Клиенты и серверы Radius → Удаленные группы серверов Radius». Открываем свойства группы «TS gateway server group» (группа создаётся при настройке RDG) и добавляем наш MFA сервер.
При добавлении, на вкладке «Load Balancing» увеличиваем лимиты времени ожидания сервера. Выставляем «Число секунд без ответа, после которого запрос считается отброшенным» и «Число секунд между запросами, после которого сервер считается недоступным» в диапазоне 30-60 секунд.
На вкладке «Authentication/Accounting» проверяем правильность указанных портов и задаем общий секретный ключ.
Теперь перейдем в раздел «Клиенты и серверы Radius → Клиенты Radius» и добавим MFA сервер, указав «Friendly name», адрес и общий секрет.
Переходим в раздел «Политики → Политики запросов на подключение». В данном разделе должна быть политика, созданная при настройке RDG. Эта политика направляет запросы Radius на MFA сервер.
Дублируем политику и заходим в ее свойства. Добавляем условие сопоставляющее «Client Friendly Name» c «Friendly name», заданным в предыдущем шаге.
На вкладке «Settings» меняем поставщика услуг аутентификации на локальный сервер.
Данная политика будет гарантировать то, что при получении Radius запроса от MFA сервера, запрос будет обработан локально, что избавит от зацикливания запросов.
Проверяем что данная политика размещена над исходной.
На данном этапе связка RDG и MFA находится в рабочем состоянии. Следующие шаги необходимы тем, кому требуется иметь возможность использовать аутентификацию с помощью мобильного приложения или предоставить пользователям доступ к некоторым настройкам многофакторной авторизации через пользовательский портал.
Установка SDK, веб-службы мобильного приложения и пользовательского портала
Подключение к данным компонентам производиться по HTTPS протоколу. Поэтому, на сервера где они будут развернуты, необходимо установить SSL сертификат.Пользовательский портал и веб-служба мобильного приложения используют пакет SDK для связи с сервером MFA.
Установка SDK
SDK устанавливается на сервер MFA и требует наличия IIS, ASP.NET, Basic Authentication, которые необходимо предварительно установить, используя Server Manager.Для установки SDK переходим в раздел Web Service SDK в Multi-Factor Authentication Server и нажимаем кнопку установить, следуем мастеру установки.
Установка веб-службы мобильного приложения
Данная служба необходима для взаимодействия мобильного приложения с сервером MFA. Для корректной работы службы, компьютер, на который она будет установлена, должен иметь выход в интернет и открыт 443 порт для подключения из интернета.Файл установки службы находиться в папке C:\Program Files\Azure Multi-Factor Authentication на компьютере с установленным MFA. Запускаем установщик и следуем мастеру установки. Для удобства пользователей можно заменить имя виртуального каталога «MultiFactorAuthMobileAppWebService» на более короткое.
После установки заходим в папку C:\inetpub\wwwroot\MultiFactorAuthMobileAppWebService и изменяем файл web.config . В данном файле необходимо задать ключи , отвечающие за учетную запись, входящую в группу безопасности PhoneFactor Admins. Эта учетная запись будет использоваться для подключения к SDK.
В этом же файле необходимо указать URL адрес по которому доступен SDK.
Примечание: Соединение с SDK производиться по SSL протоколу, поэтому необходимо ссылаться на SDK по имени сервера (указанному в SSL сертификате), а не по IP адресу. Если обращение осуществляется по локальному имени, нужно добавить в hosts файл соответствующую запись, чтобы использовать SSL сертификат.
Добавляем URL, по которому доступна веб-служба мобильного приложения, в приложение Multi-Factor Authentication Server в раздел Mobile App. Это необходимо для правильной генерации QR кода в пользовательском портале для подключения мобильных приложений.
Также в этом разделе можно установить галочку «Enable OATH tokens», что позволить использовать мобильное приложения как Software token, для генерации одноразовых паролей на основании времени.
Установка пользовательского портала
Для установки требуется IIS, ASP.NET и роль совместимости мета базы IIS 6 (для IIS 7 или более поздней версии).Если портал устанавливается на сервере MFA, достаточно в Multi-Factor Authentication Server перейти в раздел User Portal, нажать кнопку установить и следовать мастеру установки. Если компьютер присоединен к домену, то при установке будет создан пользователь, входящий в группу безопасности PhoneFactor Admins. Этот пользователь необходим для защищённого соединения с SDK.
При установке на отдельный сервер, необходимо скопировать файл установки с сервера MFA (файл установки располагается в папке C:\Program Files\Multi-Factor Authentication Server ). Произвести установку и отредактировать файл web.config в расположение C:\inetpub\wwwroot\MultiFactorAuth . В данном файле необходимо изменить ключ USE_WEB_SERVICE_SDK со значения false на true. Указать данные учетной записи, входящей в группу PhoneFactor Admins в ключах WEB_SERVICE_SDK_AUTHENTICATION_USERNAME и WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD . И указать URL адрес SDK службы, не забывая при необходимости поправить hosts файл, чтобы работал SSL протокол.
Добавляем URL, по которому доступен пользовательский портал в приложение Multi-Factor Authentication Server в раздел User Portal.
Демонстрация работы Azure MFA для аутентификации RDG подключений
Рассматривать работу MFA будем со стороны пользователя. В нашем случае вторым фактором аутентификации будет мобильное приложение, так как сотовая сеть имеет ряд уязвимостей, позволяющих при должной подготовке перехватывать звонки и SMS.Первым делом, пользователю понадобиться зайти на пользовательский портал и указать свой номер телефона (если не указан в AD) и привязать к аккаунту мобильное приложение. Заходим на портал под своей учетной записью и вводим ответы на секретные вопросы (они нам понадобятся в случае восстановления доступа к аккаунту).
Далее выбираем метод аутентификации, в нашем случае мобильное приложение и нажимаем кнопку «Создать код активации». Будет сгенерирован QR код, который надо отсканировать в мобильном приложении.
Так как при импортировании пользователей на MFA сервер была выставлена аутентификация с помощью PIN кода, нам будет предложено создать его. Вводим желаемый PIN код и нажимаем «Проверить мою подлинность». В мобильном приложении необходимо подтвердить появившийся запрос. После данных действий мы имеем привязанное к аккаунту приложение и полноценный доступ к порталу для изменения личных настроек.
