Якщо веб-сервери Windows мають бути членами домену Active Directory

14

З точки зору безпеки та керованості - яка найкраща практика?

Потрібно веб-серверів

Додайте до нього та керуйте ним із домену Active Directory

або

Будьте частиною робочої групи "веб-сервера", яка є окремою від активного каталогу "сервер ресурсів"?

Існує не вимога, щоб на веб-серверах існували облікові записи користувачів, лише облікові записи (управління сервером, системна звітність, розгортання вмісту тощо)

— Девід Крістіансен
джерело

Ці веб-сервери в Колорії чи в DMZ у вашому офісі?

— Роб Бергін

Гарний момент для підвищення. Сервери знаходяться під нашим контролем у власному серверному залі.

— Девід Крістіансен

8

Якщо ви хочете використовувати делегацію Kerberos для створення захищеної інфраструктури (і ВИ РОБИТЕ), вам потрібно буде приєднати ці веб-сервери до домену. Веб-серверу (або обліковому запису служби) знадобиться можливість делегувати призначений йому для того, щоб дозволити імперсонації користувача проти вашого SQL-сервера.

Ви, мабуть, хочете осторонь використання аутентифікації на основі SQL на сервері SQL, якщо у вас є якісь вимоги до аудиту або встановлені законодавством вимоги щодо відстеження доступу до даних (HIPAA, SOX тощо). які групи, як це було схвалено та ким) і весь доступ до даних має бути через призначений користувачем обліковий запис.

Що стосується питань DMZ, пов’язаних із доступом до AD , ви можете вирішити деякі з них за допомогою сервера 2008, використовуючи постійний постійний струм (RODC), але все ще існує ризик розгортання в DMZ. Існують також деякі способи змусити постійного струму використовувати конкретні порти для пробивання через брандмауер, однак цей тип крометомізації може ускладнити усунення проблем аутентифікації.

Якщо у вас є конкретні потреби, щоб дозволити користувачам Інтернету та Інтранету доступ до одного і того ж додатка, можливо, вам доведеться розглянути один із продуктів Federated Services, або пропозицію Microsoft, або щось на зразок Ping Federated.

— Райан Фішер
джерело

8

Внутрішнє використання, абсолютно. Таким чином, ними керує GPO, виправлення не так вже й складно, і моніторинг можна здійснити без купового обходу.

У DMZ, як правило, я б радив ні, вони не повинні бути на DMZ. Якщо вони знаходяться в домені та в DMZ, проблема, з якою ви стикаєтесь, полягає в тому, що веб-сервер повинен мати певне підключення до принаймні одного постійного струму. Тому, якщо зовнішній зловмисник компрометує веб-сервер, він може зараз безпосередньо запускати атаки проти одного з постійних клієнтів. Власний DC, власник домену. Володійте доменом, володійте лісом.

— К. Брайан Келлі
джерело

Дякуємо КБ та Роб. Створення ще однієї AD в периметровій мережі - це одна відповідь, але я не можу виправдати, що потрібно купувати інший сервер, щоб бути хостом AD для веб-серверів. Ург. Іншим ускладненням є те, що веб-сервери повинні мати деякий трафік у внутрішній 'довіреній' мережі (наприклад, SQL) і що SQL-трафік забезпечується за допомогою надійного мережевого з'єднання. Я думаю, ми повинні говорити про два рекламні оголошення і про довіру між ними?

— Девід Крістіансен

Це найбезпечніший маршрут, так. У вас є ліс для серверів, що базуються на DMZ, і він має один спосіб довіри назад до внутрішнього лісу. Однак я хотів би спочатку дозволити аутентифікацію на основі SQL Server.

— К. Брайан Келлі

Я згоден, це шлях.

— шквал

6

Чому б не мати домен веб-сервера в DMZ?

Це може бути окремий ліс із односторонніми довірчими стосунками для адміністрування домену з вашого основного домену без надання дозволу на домен WS для вашого основного домену.

Всі радощі AD / WSUS / GPO - особливо корисні, якщо у вас є ціла ферма - і якщо це порушено, це не ваша основна мережа.

— Джон Роудс
джерело

1

Це найбезпечніший шлях, якщо вам доведеться використовувати домен. Однак ви все ще говорите про отримання прямої атаки на постійний струм. І в сценарії, який ви даєте, якщо я отримаю цей DC, якщо ви не вилучили кешовані облікові дані, я все одно можу витягнути їх і мати облікові дані для використання в первинному домені / лісі.

— К. Брайан Келлі

KB, не цікаво, чи можете ви описати "кешовані дані"

— David Christiansen,

1

Якщо ви не вимкнете його, система Windows буде кешувати облікові дані пароля (насправді хеш-хешами), коли ви входите в систему. Це те, що дозволяє вам мати ноутбук та входити в систему за допомогою входу в домен, коли ви знаходитесь поза корпоративною мережею. Витягніть це, використовуючи веселкові столи, ви отримаєте ідею.

— К. Брайан Келлі

3

Якщо довіра лише одна, кешовані облікові дані не мають значення, оскільки сервер DMZ ніколи не підтвердить автентифікацію щодо основного домену.

— Джон Роудс

2

Якщо веб-сервер знаходиться в тій самій мережі, що і контролери домену, я б точно додав його до домену - оскільки це очевидно додає великої керованості. Однак, як правило, я б прагнув розмістити веб-серверів у DMZ для підвищення безпеки - це робить доступ до домену неможливим без проколів (і це дуже погана ідея!)

— Роб Голдінг
джерело

1

Як уже згадували інші, якщо вони є загальнодоступними та не потребують автентифікації користувачів щодо каталогу, тоді не вводьте їх у домен.

Однак, якщо вам потрібна якась автентифікація або пошук інформації з AD, можливо, погляньте на запуск режиму додатків Active Directory ( ADAM ) у DMZ. Можливо, вам доведеться копіювати відносну інформацію з AD в розділ Applicationaton, оскільки ADAM не синхронізує стандартні розділи AD.

Якщо ви просто шукаєте функції управління, ADAM не застосовується.

— Дуг Люксем
джерело