Ви маєте віддалених користувачів, яким потрібен доступ до внутрішніх додатків, таких як BI (Business Intelligence) панелі, інтранет, HR чи заробітна плата? Чи потрібен їм VPN? Або, можливо, вони не мають доступу до додатків, коли знаходяться поза офісом? Більше не хвилюйтеся – ось універсальний посібник для встановлення віддаленого доступу до лінійки веб-додатків для бізнесу. І це можна зробити менш ніж за дві години! Не жартуємо – ми вже це робили. Тут ми розглянемо низку рішень для швидкого забезпечення дистанційного доступу до додатків та даних за допомогою хмари Microsoft. Наша мета – полегшити вам вибір правильного варіанту для ваших потреб та надати всі ресурси, необхідні для його використання.
Сервіси Microsoft для віддаленого доступу
Існують різні сервіси і немає універсального рішення. Але найголовніше: ви можете комбінувати різні варіанти. Це чудовий спосіб оптимізувати витрати та вплив на ваше середовище. Подумайте про зменшення використання мережевої пропускної здатності, мінімізацію витрат або простоту розгортання.
Які доступні варіанти?
| Сервіс | Рівень простоти розгортання | Тип рішення | Найкраще підходить для | Тип додатку | Рівень доступу | Час для запуску |
| Microsoft Teams / Office 365 | Легкий | SaaS | Продуктивність та співпраця | Набір Office, Microsoft Teams – веб- або клієнтська версія | Веб- або клієнтська версія | Години |
| Azure VPN | Середній | Мережа | Віддалена робота з повним доступом до мережі | Робоча станція, підключена до мережі | Зашифроване мережеве з'єднання | Дні |
| Azure AD Web Application Proxy | Легкий | Зворотні проксі-сервер програми | Доступ до веб-програм | Браузерні програми | HTTPS | Години |
| Remote Desktop Services на Azure IaaS | Складний | Інфраструктура віддаленого робочого стола | Віддалений доступ до програм робочого стола | Desktop, fat client | Термінальна сесія (RDP) | Дні (тижні) |
| Azure Windows Virtual Desktop | Складний | Віддалений робочий стіл як сервіс | Віддалений доступ до програм робочого стола | Desktop, fat client | Термінальна сесія (RDP) | Дні |
Ми поки що пропустимо Office 365 та Azure VPN, і перейдемо одразу до Azure AD Web Application Proxy (Azure AD WAP).
Чому Azure AD WAP?
Швидко розгортається, є економічно вигідним і може працювати у різних ситуаціях. Також дуже безпечний – ви можете застосувати весь важкий арсенал безпеки Microsoft Azure AD – від MFA до повного Conditional Access. А що найкраще? Це те, що немає потреби в жодних змінах у додатках чи мережі з вашого боку. Вам не потрібно змінювати додаток, і ви можете зробити його доступним для віддалених працівників надійно і майже миттєво, створюючи повноцінне віддалене цифрове робоче місце.
Бізнес-сценарій
Ваші користувачі використовують внутрішні веб-застосунки. Це може бути один з наступних (але не обмежується ними):
- портал SharePoint;
- SQL Reporting Services / Power BI;
- HR-додаток (payroll, SAP, Oracle EBS);
- рішення для веб-звітності;
- ваш внутрішній додаток для будь-яких цілей.
Це не обов'язково має бути комерційний продукт. Це може бути ваш власний додаток, розроблений у вашій компанії. Користувачам потрібно працювати віддалено та отримувати доступ до нього з дому. Звісно, є VPN – але чи дійсно нам потрібен VPN, щоб надати їм доступ до браузерного додатка? Ось рецепт для забезпечення доступу до цих додатків без VPN менш ніж за дві години.
Інгредієнти і флоу
Azure AD Web Application Proxy – це PaaS сервіс (Microsoft ним керує, і немає інфраструктури на вашій стороні). Цей сервіс є частиною функціональності Azure AD. Відправною точкою є наявність ліцензії. Вам потрібна ліцензія Azure AD P1 або P2 (P1 достатньо – ось порівняння ліцензій). Ми припускаємо, що ви вже виконали підготовчі роботи, і ваші користувачі вже використовують Office 365 та Azure AD. Якщо ні – є прості кроки для його включення. Ви завжди можете звернутися до нас, і ми можемо допомогти вам. Вам потрібно завантажити та встановити у вашу локальну мережу невеликий компонент, що називається Web Application Proxy Connector. Розгорніть принаймні два таких компоненти, щоб забезпечити високу доступність та балансування навантаження. У простому випадку – це все. Для великомасштабних впроваджень (тисячі користувачів, складна мережа) може знадобитися деякий дизайн. Ось передумови для публікації вашого першого додатку у вигляді списку:
- Azure AD Tenant з принаймні P1 ліцензією (якщо ви використовуєте Office 365, у вас вже є Azure AD, будь ласка, перевірте опції ліцензій).
- Користувачі, синхронізовані з Azure AD (виконано, якщо у вас є Office 365).
- 3. Завантаження та встановлення Application Proxy Connector.
Час, необхідний за умови, що у вас вже є тенант Office 365 з користувачами: 1 година. Все перевірено. Тепер подивімося на додаток.
Додатки
Azure AD Web Application Proxy працює з браузерними додатками, використовуючи:
- аутентифікацію Windows (SSO на основі домену Active Directory на місці);
- SAML аутентифікацію;
- інші механізми для входу (ім'я користувача та пароль), за винятком того, що користувач не має повного SSO досвіду (все одно потрібно входити до застосунку).
Ви можете публікувати додаток у двох режимах:
- попередньо аутентифікований – користувач отримує повний SSO досвід на базі використання Office 365;
- наскрізний – користувач безпечно отримує доступ до додатка, але повинен окремо увійти до нього.
Ваш додаток наразі доступний у внутрішній мережі – наприклад, Intranet на SharePoint може бути доступний за адресою `https://intranet.<домен компанії>`. Ви можете опублікувати його під тим же іменем або використовуючи ваш комерційний, зовнішній домен. Для користувача це просто – вони вводять `https://app.domain.com` у додатку і миттєво отримують до нього доступ. Щоб усе це працювало, вам знадобиться SSL-сертифікат. Ви можете запросити його у комерційного провайдера, такого як DigiCert, або у Let's Encrypt (некомерційний сертифікаційний центр). Що вам потрібно у підсумку:
- Внутрішній URL додатку: як користувачі мають до нього доступ зараз.
- Зовнішній URL додатку: як його бачить користувач.
- SSL-сертифікат: комерційний або від довіреної особи.
Необхідний час: 1-2 години..
Як це працює? Чи потрібне мені якесь обладнання?
Azure AD надає точку входу для ваших користувачів. Він публікує ваш зовнішній URL додатку в Інтернеті. З іншого боку, конектор Azure AD WAP створює вихідне з'єднання з цим проксі. Важливо: це – вихідне з'єднання. Немає вхідних з'єднань і жодних відкритих портів з вашого боку. Коли користувач звертається до зовнішнього URL додатку, Microsoft Azure «пробуджує» ваш конектор і передає йому трафік користувача. Конектор, розташований у вашій мережі, перенаправляє його на внутрішній URL додатку.
Внутрішні механізми
Ось у чому секрет. Коли користувач підключається до зовнішнього URL додатку, Azure AD виконує складні процеси:
- Користувач аутентифікується з Azure AD (включаючи MFA, якщо він встановлений, – пам'ятайте: з Security Defaults це безкоштовно).
- Застосовує правила Conditional Access (якщо вони встановлені), щоб переконатися, що клієнт, який підключається до додатка, є сумісним і що доступ безпечний.
Якщо додаток базується на аутентифікації Windows, він також робить дуже розумну річ, запитуючи тікет Kerberos для користувача (делегація) для доступу до додатку.
Автор
