Якщо прибрати всю блискучу обгортку і лушпиння, то сенс роботи ІТ-фахівця стане гранично чітким і зрозумілим: основне завдання ІТ полягає в створенні, управлінні та забезпеченні безпечного доступу до бізнес-програм та даних. Все інше - установка пакетів виправлень, пошук усунення неполадок, підтримка користувачів - підпорядковане головному завданню. І ІТ-фахівця на великому підприємстві, і майстру на всі руки в дрібній компанії платять гроші, по суті, за одне - за забезпечення безпеки даних і безперебійної роботи додатків.
Саме тому технологія віддаленого робочого столу (RDS) - відмінне рішення, що дозволяє вирішувати зазначену завдання. Використання віддаленого робочого стола стає стандартним методом забезпечення повсюдного та безпечного доступу до додатка з будь-якої точки мережі.
Що нам знадобиться
Для початку потрібно два сервера. Один з них повинен бути обладнані потужним процесором і об'ємної пам'яттю (точні цифри я пропоную вам визначити самостійно). Такий потужний сервер буде хостом RDS, або RDSH (Remote Desktop Session Host). На ньому будуть встановлюватися додатки, доступ до яких потрібно надавати користувачам, тому крім іншого у нього повинно бути достатньо ресурсів для підтримки багатьох одночасних підключень користувачів цих додатків.
Для другого сервера не потрібно стільки мощі, оскільки він буде грати роль шлюзу віддаленого робочого столу (Remote Desktop Gateway, RDG), і працювати як свого роду проксі-сервер між «зовнішніми» підключеннями з Інтернету і «внутрішнім» RDSH-сервером. Робота в якості шлюзу набагато менш напружена, тому цього сервера можна виділити істотно менше ресурсів.
При підготовці RDG-сервера на брандмауері потрібно відкрити один-єдиний порт між Інтернетом і RDG-сервером. Відкриття 443 протоколу TCP дозволить зовнішнім клієнтам підключатися до RDG-сервера, який буде працювати в якості захисного шлюзу, що пересилає клієнтам захищений RDSH-трафік (зазвичай через порт 3389 TCP) (див. Рис. 1).
Мал. 1. RDG-сервер працює як захисний шлюз між клієнтами Інтернету і RDSH-хостом
Третій компонент - SSL-сертифікат з ім'ям шлюзу, точніше доступним з Інтернету повним доменним ім'ям RDG-сервера. Ви маєте право створити такий сертифікат безкоштовно, використовуючи вбудовані в ОС служби сертифікації Microsoft, але краще витратити приблизно 30 доларів в рік на публічний сертифікат, виданий довіреною центром сертифікації, так як це сильно спростить реалізацію. В даному прикладі сертифікат прив'язаний до сервера server1.contoso.com.
Установка RDSH-сервера
В процесі установки RDSH потрібно налаштувати чотири важливі параметри:
Отримавши відповіді, установник встановить RDSH на сервер # 92; # 92; server2. Далі треба встановити пакет Microsoft Office. Майте на увазі, що установка додатків на сервер RDSH вимагає додаткового кроку, який відсутній при звичайній установці. В Панелі управління (Control Panel) знайдіть елемент «Install Application on Remote Desktop Server», де введіть шлях до файлу установки Office і дочекайтеся завершення установки в рамках Панелі управління.
Установка шлюзу віддалених робочих столів
Встановивши RDSH-сервер, можна відкрити його для доступу клієнтів Інтернету. Спочатку треба встановити придбаний SSL-сертифікат на сервер # 92; # 92; server1. Процес отримання цього сертифіката визначається його видавцем, але в кінцевому підсумку сертифікат повинен бути встановлений в особистому сховище сертифікатів комп'ютера (але не в особистому сховище користувача).
Мал. 2. Конфігурація сертифікатів на RDG
Після установки сертифіката встановлюють роль Remote Desktop Services на сервер # 92; # 92; server1, але на цей раз зі службою Remote Desktop Gateway. Як видно на рис. 2. цей процес конфігурації складніше, ніж настройка RDSH, але все одно все зводиться до чотирьох речей:
- Server authentication certificate (сертифікат перевірки автентичності сервера). Якщо ви правильно встановили SSL-сертифікат в особистому сховище локального комп'ютера, він з'явиться у відповідному полі (див. Рис. 2).
- RD Gateway User Groups (групи користувачів шлюзу віддалених столів). Групи користувачів, яким дозволено підключатися до внутрішніх ресурсів через цей RDG-сервер.
- RD CAP (політика перевірки автентичності при підключенні до віддаленого робочого столу) визначає, які механізми використовуються для перевірки особу користувача на RDG шлюзі.
- RD RAP (політика перевірки автентичності при підключенні до віддаленого робочого столу) визначає, до яких внутрішнім ресурсам дозволено отримувати доступ користувачами, які підключилися через RDG.
Конфігурація Outlook RemoteApp
Для багатьох адміністраторів-універсалів саме тут починаються складності. Наступний етап налаштування виконується на RDSH-сервері, де потрібно створити конфігурацію RemoteApp для Microsoft Outlook. У ній треба вказати всю необхідну інформацію, щоб зовнішні клієнти могли підключатися до RDG-сервера через Інтернет.
Мал. 3. Конфігурування параметрів RDG на RDSH-сервері
Наступний крок - визначення RDG-сервера, до якого будуть підключатися Інтернет-клієнти. Натисніть кнопку Change поруч з RD Gateway Settings - відкриється вікно, показане на рис. 3. Тут ви можете задати ім'я свого RDG-сервера, а також спосіб входу в систему. Зверніть увагу, що один прапорець вже встановлено. Він забезпечує щось типу єдиного входу, коли користувачі вводять облікові дані тільки раз і отримують доступ до RDG і RDSH. Другий прапорець дозволяє користувачам локальної мережі підключатися, минаючи RDG-сервер. Так як знаходяться в локальній мережі користувачі не потребують додаткового захисту, що надається RDG-сервером, вибір цього прапорця дозволяє їм підключатися до RDSH безпосередньо. Переконайтеся, що встановлені обидва прапорця і клацніть OK.
Конфігурації параметрів RDG на RDSH-сервері Заключний етап нашого прикладу - створення файлу підключення до Outlook для користувачів. Для цього клацніть Outlook RemoteApp і виберіть Create .rdp File, після чого клацніть Next і Finish. У папці C: # 92; Program Files # 92; Packaged Programs з'явиться файл з розширенням .rdp, який можна роздавати користувачам. Щоб підключитися до Outlook через інтернет, користувачам буде достатньо двічі клацнути файл і ввести свої облікові дані.
Ще одне повідомлення і ще один сертифікат
Після завершення і двічі клацнувши RDP-файл підключення до Outlook, ви побачите повідомлення про помилку (рис. 4). З технічної точки зору це не помилка, хоча це повідомлення часто бентежить користувачів. Воно вимагає додаткової перевірки автентичності RDP-файлу клієнтом віддаленого робочого столу перед запуском цього файлу. Воно вимагає додаткової перевірки автентичності RDP-файлу клієнтом віддаленого робочого столу перед запуском цього файлу. Як і раніше, питання вирішується шляхом підписання RDP-файлу сертифікатом, причому це може бути той же сертифікат, що використовувався при установці RDG.
Мал. 4 Повідомлення про помилку клієнта віддаленого робочого столу, яке повідомить про необхідність ще одного публічного SSL-сертифіката на кожному RDSH-сервері
Щоб позбутися від повідомлення про помилки, встановіть сертифікат RDG в особисте сховище сертифікатів RDSH-сервера, потім поверніться до вузла RemoteApp Manager в диспетчері серверів. Натисніть кнопку Change поруч з Digital Signature Settings. У вікні, встановіть прапорець Sign with a digital certificate і клацніть кнопку Change. Якщо ви правильно встановили сертифікат в особистому сховище локального комп'ютера, сертифікат може бути перелічений. Після цього перебудували RDP-файл для Outlook.
В результаті повідомлення про помилку перетворитися в питання про те, чи довіряєте користувач видавцеві цієї програми RemoteApp. Якщо користувач згоден, йому досить натиснути кнопку Connect, перед цим він може встановити прапорець, щоб дане повідомлення більше не з'являлося.
Ось, власне, і вся інструкція з надання доступу з Інтернету до внутрішньої програмі Outlook розміром трохи менше 2 тисяч слів. Явно, що в RDS є істотно більше варіантів конфігурації і захисту середовища. Але цей простий приклад - просто початок на вашому великому шляху до повсюдного і безпечного доступу до додатків.