У статті розглядається технологія аутентифікації Swivel, яка може бути інтегрована в хмарні сервіси пакету Office 365. Технологія аутентифікації PINpad, розроблена компанією Swivel, є більш захищеною, ніж проста процедура перевірки пароля, при цьому вона не вимагає додаткового каналу передачі одноразових паролів або додаткових пристроїв.
1. Введення
2. Загальні відомості
3. Архітектура і системні вимоги
4. Інтеграція
5. Результати
6. Висновки
Вступ
Хмарні сервіси все частіше використовуються в бізнесі - це зручно і не вимагає вкладень в покупку і підтримку власних серверів. Однак робота з хмарними сервісами не завжди безпечна. Найчастіше захищені вони тільки одним паролем, який може бути легко підібраний за словниками або переглянутий за допомогою фішинговою атаки.
За прикладами далеко ходити не потрібно. Нещодавно в пресі з'явилися інтимні фотографії американських знаменитостей, які були отримані з хмарного сервісу компанії Apple - вони були зібрані через перехоплення паролів на доступ до звичайних сервісів. А недавно набули широкого розголосу великі бази паролів таких поштових сервісів як Mail.ru, "Яндекс" і Google. Це саме по собі є істотним погіршенням ситуації з паролями, оскільки витекли бази стали сировиною для словників. Після цих випадків розробники хмарних сервісів запропонували ввести додатковий спосіб аутентифікації за допомогою SMS, надісланих на мобільний телефон, хоча це і більш дорогий спосіб аутентифікації і менш зручний - SMS не завжди вчасно доходить.
Проте, для компаній, особливо розподілених, використання в своїй роботі хмарних сервісів досить зручно, тому розробники засобів захисту пропонують технології, які дозволяють зробити аутентифікацію навіть по паролю достатньо надійною, не вдаючись при цьому до використання для цього другого каналу передачі інформації, такого як SMS, або додаткових пристроїв генерації одноразових паролів. Зокрема, це можна зробити за допомогою технології екранної панелі аутентифікації PINpad, яку пропонує компанія Swivel.
Загальні відомості
Набір офісних сервісів Office 365 є одним з найбільш популярних інструментів для організації бізнес-процесів, тому співробітники компаній довіряють йому найбільш цінні дані. До того ж Office 365 часто використовується для взаємодії співробітників з клієнтами і партнерами, але при цьому рідко хто користується можливістю двофакторної аутентифікації, закладеної в цьому сервісі. В результаті, іноді перехоплений або підібраний пароль дозволяє зловмисникам втручатися в роботу корпоративних бізнес-процесів, а якщо з корпоративних адрес розсилаються спам або фішингові повідомлення, то це може негативно відбитися на репутації компанії. Зафіксовані навіть випадки, коли отримання віддаленого доступу до хмарного сервісу компанії дозволяло зловмисникові повністю знищити дані і зупинити нормальну роботу компанії. Саме тому клієнтам, які активно використовують даний сервіс в своїй роботі варто задуматися про те, як убезпечити своїх співробітників від подібних неприємностей під час роботи - це може принести як репутацією, так і цілком фінансових збитків. При цьому Microsoft надає можливість по налаштуванню двухфакторной федеративної аутентифікації в Office 365 через корпоративну службу Active Directory, але мало хто цією можливістю користується.
Звичайно, можна скористатися сервісом аутентифікації за допомогою одноразових паролів, які надсилаються через SMS на мобільні телефони співробітників, однак використання додаткового каналу взаємодії з сервісом і коштує дорожче, і сильно ускладнює взаємодію з ним. Наприклад, іноді в дорозі виникає ситуація, коли комп'ютер для доступу до корпоративної мережі є, а мобільний телефон для отримання SMS розрядився. До того ж самі SMS не безкоштовні, а недавно російські оператори мобільного зв'язку підняли вартість на SMS-розсилки для корпоративних користувачів.
На щастя, компанія Swivel запропонувала не менше зручний, але досить дешевий спосіб аутентифікації без використання додаткових каналів передачі інформації. Його використання не складніше класичного пароля, але краще захищає як від перехоплення пральний інформації, так і від її підбору. Детальніше Anti-Malware.ru вже описували цей метод аутентифікації в огляді технології. Варто тільки сказати, що компанія Microsoft пропонує метод, який дозволяє використовувати Swivel PINpad для аутентифікації в тому числі і в хмарному сервісі Office 365.
Архітектура і системні вимоги
Чому пароль, що вводиться за допомогою PINpad надійніший для користувачів, ніж класичні, хоча на PINpad використовуються тільки цифри, а в класичній системі паролів можна використовувати найрізноманітніші символи? Справа в тому, що класичний пароль завжди однаковий і передається у відкритому вигляді. Його набір виконується за допомогою клавіатури, що дозволяє просто перехопити введено жодного символу за допомогою спеціальної троянської програми або спеціально встановленої відеокамери, при цьому вже буде неважливо дещо складним є сам пароль. Навіть набір символів на екранній клавіатурі не завжди рятує, оскільки хакери можуть перехоплювати натискання кнопки миші і записувати положення, в якому вона була, щоб в подальшому просто повторити ті ж натискання і в тому ж місці - втручання людини для цього не потрібно.
У той же час PINpad щоразу змінюється і створює нову віртуальну клавіатуру, тому для розкриття пароля потрібно як мінімум розпізнавання віртуальної клавіатури людиною, що вже складніше автоматизувати. До того ж пароль не передається на сервер у відкритому вигляді - код відповіді залежить від запиту сервера. В результаті, вартість атаки на даний механізм аутентифікації є поки досить високою, що не дозволяє робити атаку на дану процедуру аутентифікації масовою.
Слід зазначити, що в разі інтеграції механізму аутентифікації Swivel в хмарні сервіси Microsoft Office 365 використовується технологія федеративної аутентифікації. Тобто для аутентифікації використовується така схема, в якій хмарний сервіс довіряє механізм аутентифікації сторонньому ресурсу - в даному випадку корпоративному північ Active Directory (точніше проміжного сервера федеративної аутентифікації AD - сервера ADFS). Це дозволяє контролювати тих користувачів, які намагаються отримати доступ до корпоративної частини хмари Microsoft - всі запити на аутентифікацію спочатку проходять через захисні механізми Microsoft, а потім передаються в корпоративний домен AD через ADFS, де інформація про запит на аутентифікацію може бути зафіксована і в подальшому використана для проведення аналізу або розслідування.
Власне, перш, ніж налаштовувати аутентифікацію за допомогою паролів Swivel варто спочатку просто налаштувати так званий єдиний вхід в Office 365 - для цього в інтерфейсі управління користувачами потрібно натиснути кнопочку «Єдиний вхід: настройка».
Малюнок 1. Попереднє налаштування так званого єдиного входу за допомогою механізму федерації AD
На жаль, повністю описувати процес створення єдиного середовища довіри між Office 365 і нашим власним невеликим доменом тут не представляється можливим. Проте, цей процес добре описаний і документований в самому Office 365, в тому числі і російською мовою.
Малюнок 2. Інтерактивна інструкція по налаштуванню федеративного доступу між Office 365 і нашим «корпоративним»
інтеграція
Процес підготовки до інтеграції можна розділити на два етапи. Спочатку потрібно налаштувати федеративну аутентифікацію між Office 365 і корпоративною службою Active Directory, як це описано в інтерактивній інструкції в самому сервісі. Цілком можливо, що така інтеграція вже була вами зроблена. Далі можна інтегрувати сам продукт Swivel в корпоративну структуру Active Directory, як це було описано в уже опублікованому на Anti-malware.ru матеріалі . Сама ж інтеграція полягає в модифікації корпоративного шлюзу для федеративної аутентифікації, який потрібно було побудувати на першому етапі, так, щоб реалізувати в ньому підтримку технології аутентифікації Swivel.
Тепер кілька слів про розгорнуту в нашій корпоративної мережі системі. В першу чергу в ній розташовується віртуальна машина з розгорнутою в ній простенької структурою Active Directory, яка забезпечує аутентифікацію користувачів в нашому домені AD. Однак, щоб налаштувати хмарний сервіс для аутентифікації в моєму "корпоративному" домені, потрібно було встановити додатковий ADFS-сервер і спочатку інтегрувати його у відповідності з процедурою (див. Малюнок 2) з Office 365, щоб забезпечити перекидання запитів на аутентифікацію з хмарного сервера в мою «корпоративну» інфраструктуру.
Далі мені потрібно було відкрити доступ до домашнього комп'ютера з мережі Інтернет. Для цього довелося замовити у провайдера прямий IP - благо таку послугу мій провайдер представляє. З цього IP можна було отримати доступ до мого маршрутизатора, який встановлений у мене в квартирі. Далі мені довелося налаштувати доступ від маршрутизатора до комп'ютера, на якому була розгорнута віртуальна машина з контролером домену. Для цього довелося створити в моїй локальній мережі демілітаризовану зону - благо маршрутизатор це дозволяв.
Малюнок 3. Створення маршруту з - поза до комп'ютера з встановленим ADFS, AD і Swivel (його локальний IP - адреса 192.168.1.5)
Після того, як заробила федеративна аутентифікація з Office 365, її потрібно було модифікувати, щоб вбудувати в неї процедуру Swivel. Втім, інтеграція Active Directory і Swivel була досить докладно описана в попередній статті серії, тому зупинятися на ній зараз докладно ми не будемо. Варто відзначити тільки один момент - повинна бути налаштована одноканальна аутентифікація, як це зазначено на Малюнок 4.
Малюнок 4. Налаштування сервера Swivel для одноканальної процедури аутентифікації
Не менш важливою частиною виконаної нами роботи була інтеграція необхідних елементів аутентифікації в ADFS-сервер, який власне і забезпечує проведення процедури для зовнішніх користувачів. Для настройки його інтерфейсу мені потрібен був набір файлів, які пропонує компанія Swivel у вигляді архіву ADFSfiles.zip . З нього потрібно скопіювати файли pinsafe_image.aspx і exists.aspx в спеціально створену директорію adfs \ ls - це сторінки для видачі користувачам інтерфейсу аутентифікації.
Також потрібно скопіювати файли PINsafeASPNetFilter.dll і PINsafeClient.dll в директорію adfs \ ls \ bin - це виконані частини фільтра, який перенаправляє процес аутентифікації в мій сервер Swivel і контролер домену. У наборі файлів також є приклад конфігурації для сервера ADFS, з якого потрібно перенести одну секцію в реальний web.config. Зразкове утримання секції таке (опису є не для всіх ключів - тільки для важливих, детальну інформацію по ключам можна знайти на спеціальній сторінці https://kb.swivelsecure.com/wiki/index.php/Microsoft_Office_365 ):
<AppSettings>
<Add key = "PINsafeServer" value = "192.168.1.6" />
<! - Тут потрібно вказати IP-адресу або доменне ім'я AD з встановленим на нього модулем Swivel - у мене він розташовувався в сусідній віртуальній машині ->
<Add key = "PINsafePort" value = "8080" />
<! - Порт ->
<Add key = "PINsafeContext" value = "pinsafe" />
<! - Ім'я програми ->
<Add key = "PINsafeSecure" value = "True" />
<Add key = "PINsafeSecret" value = "secret" />
<Add key = "PINsafeLogonPath" value = "/ adfs / ls /" />
<Add key = "PINsafeLogoffPath" value = "/ adfs / ls /" />
<! - Шляхи для установки сторінок аутентифікації, куди я помістив відповідні форми pinsafe_image.aspx і exists.aspx ->
<Add key = "PINsafeExcludedPaths" value = "/ adfs / ls / MasterPages /;./ pinsafe_image.aspx" />
<! - Тут вказуються всі додаткові шляхи на сервері, які можуть бути використані ->
<Add key = "PINsafeIgnoreDomain" value = "true" />
<Add key = "PINsafeAcceptSelfSigned" value = "True" />
<Add key = "PINsafePassword" value = "True" />
<Add key = "PINsafeImage" value = "True" />
<Add key = "PINsafeMessage" value = "False" />
<Add key = "PINsafeCookieSecret" value = "jRKQLRgI // Szz4UfCYtgNI / 1KTbOwRYV + X / efvljcGNMW0tWEmlvJdORTl69rXP /" />
<Add key = "PINsafeIdleTimeSecs" value = "300" />
<Add key = "AllowNonPINsafeUsers" value = "False" />
<Add key = "PINsafeFilterEnabled" value = "True" />
<Add key = "PINsafeAuthenticationDomain" value = "" />
<Add key = "PINsafeUsernameField" value = "ctl00 $ ContentPlaceHolder1 $ UsernameTextBox" />
<Add key = "PINsafeOTCField" value = "otc" />
</ AppSettings>
Крім того, мені довелося модифікувати файл FormsSignIn.aspx сервера, в який потрібно вставити фрагменти з прикладу Swivel, щоб на сторінці перевірки аутентифікації Office 365 з'явилися необхідні інтерфейсні елементи для аутентифікації. Виконавши всі ці дії, мені вдалося домогтися, щоб вхід в Office 365 можна було виконати за допомогою Swivel PINpad.
результати
Власне, процедура аутентифікації в Office 365 після всіх пророблених мною операцій виглядає приблизно так: спочатку набирається логін і пароль в самому сервісі, як це було і раніше, см. Малюнок 5.
Малюнок 5. Головна сторінка аутентифікації Office 365
Однак відразу після основної аутентифікації виконувалася переадресація на підготовлений мною ADFS-сервер, де вже доводилося проходити посилену процедуру аутентифікації за технологією Swivel.
Малюнок 6. Сторінка для аутентифікації по технології Swivel
Правда, далеко не завжди вдавалося правильно потрапити по потрібних клавішах віртуальної клавіатури, і тоді можна було виявити ось таке повідомлення:
Малюнок 7. Повідомлення про помилку аутентифікації Swivel
При правильно ж набраному додатковому коді аутентифікації мій сервер переадресовував вже браузер на основний сайт Office 365.
Хотілося б відзначити, що з моєї точки зору як користувача, інтеграція Swivel з авторизацією в Office 365 закриває для зловмисника такі можливості, як автоматичний збір і створення бази даних паролів. Для цього доведеться, як мінімум, наймати людей, які будуть розпізнавати пароль за зібраними троянцем даними. І навіть якщо паролі розпізнані вручну, для їх використання доведеться також використовувати ручну працю. Це сильно здорожує злом механізму аутентифікації при мінімумі витрат для компанії-клієнта. У той же час для користувача, особливо працюючого на планшетних операційних системах, типу Windows 8.1, iOS або Android, процедура аутентифікації не сильно змінюється. Але головне, не потрібно додаткового каналу для аутентифікації, який може виявитися дорогим і не зручним у використанні. Тобто впровадження подібного механізму цілком виправдано, особливо для великої кількості користувачів.
висновки
Технологія екранної аутентифікації, пропонована компаній Swivel є більш захищеною, ніж набір пароля за допомогою клавіатури, без задіяння при цьому другого каналу комунікацій, такого як SMS, що могло б зробити використання хмарного сервісу більш дорогим і менш зручним. Природно, від цілеспрямованих атак з можливістю залучення ручного розпізнавання вона не захистить - в цьому випадку варто використовувати більш дорогі методи аутентифікації із залученням додаткових пристроїв. Технологія ж Swivel добре підходить для посилення захисту масового доступу користувачів до корпоративної мережі. Наприклад, її можна використовувати для доступу клієнтів або партнерів в особистий кабінет компанії на корпоративному SharePoint або рядових співробітників до корпоративної пошти Exchange.
У моєму окремому випадку інтеграція зажадала досить складної настройки - кілька днів, щоб розібратися, отримати демонстраційний доступ до Office 365 і придбати прямий IP-адреса. Але для корпоративних користувачів, які вже мають федеративну аутентифікацію по домену Active Directory і використовують сервіс Office 365, це напевно не буде проблемою. Швидше за все, у них це вийде швидше.
Для настройки потрібно самостійно правити файли конфігурації ADFS-сервера, що могло призвести до проблем, проте компанія Swivel запропонувала набір готових шаблонів, що сильно прискорило роботу. Документація по інтеграції написана тільки англійською і не дуже докладна - зокрема, не всі ключі настройки для файлу web.config визначені навіть в англомовній документації. Проте, розібратися в ній цілком можливо.
Важливо відзначити, що технологія Swivel потрібна компаніям, які використовують Office 365 для реалізації складних бізнес-процесів в розподіленої інфраструктури або з залученням партнерів, оскільки вона дозволяє захистити рядових співробітників або партнерів від використання складних і дорогих схем аутентифікації, будучи при цьому досить ефективним бар'єром для хакерів.
