Оценка новой политики безопасности
На прошлой неделе я увидел кое-что, что меня очень обеспокоило. Находясь в гостях у друга в его офисе, один из ИТ-сотрудников рассказал мне о настройке безопасности, о которой он только что прочитал в Интернете. Рассказав мне о настройке, парень реализовал ее в производственной сети. Причина, по которой это беспокоило меня, заключалась в том, что сеттинг был применен по прихоти, без планирования и практически без размышлений о последствиях.
Лучшее решение
Вместо того, чтобы опрометчиво вносить изменения в политики безопасности вашей организации, я рекомендую использовать трехуровневый подход к изменениям политики безопасности. Первый уровень включает лабораторное тестирование, второй уровень состоит из ограниченного пилотного развертывания, а последний уровень состоит из полномасштабного развертывания.
Лабораторные испытания
Прежде чем пытаться внедрить политику в рабочей сети, следует протестировать влияние новой политики в лаборатории. В идеале ваша лабораторная среда должна точно имитировать вашу производственную сеть, но должна быть полностью изолирована от нее. В конце концов, вы бы не хотели, чтобы сбой в лаборатории повлиял на рабочий сервер.
Многие компании избегают тестовых лабораторий, потому что традиционно было очень дорого построить лабораторию, точно имитирующую производственную сеть. Задумайтесь об этом на мгновение... Если вы хотите точно смоделировать свою производственную сеть, вам потребуются серверы, коммутаторы, маршрутизаторы, рабочие станции и множество программного обеспечения. Хотя вам по-прежнему потребуется мощное оборудование, вы можете значительно снизить стоимость создания лаборатории, используя виртуализацию серверов. Виртуализация серверов позволяет использовать такой продукт, как Microsoft Virtual Server, для имитации нескольких серверов на одном компьютере. Очевидно, что виртуальные серверы не будут работать так быстро, как если бы серверные операционные системы запускались непосредственно на физической машине, но вы значительно сэкономите на стоимости оборудования.
Даже если вы виртуализируете свои серверы, вам все равно потребуются лицензии на программное обеспечение для вашей лабораторной среды. Вы можете сэкономить деньги на лицензиях на программное обеспечение, заказав подписку MSDN у Microsoft. MSDN — это набор программного обеспечения для использования в средах разработки. Вам придется посетить веб-сайт Microsoft, чтобы убедиться, что лицензионные требования MSDN подходят для вашей лаборатории, но MSDN может сэкономить вам много денег, поскольку содержит операционные системы и приложения.
После создания тестовой лаборатории необходимо настроить лабораторные серверы так, чтобы они вели себя так же, как рабочие серверы. Самый простой способ добиться этого — восстановить резервные копии рабочих серверов на лабораторных серверах. Имейте в виду, однако, что некоторые приложения могут работать некорректно, если на лабораторных серверах не установлены те же конфигурации жестких дисков, что и на их аналогах в производственной среде.
Итак, у вас есть лабораторная сеть, которая максимально точно имитирует вашу производственную сеть. Как вы проводите тестирование новой политики безопасности? Я рекомендую вам начать с тестирования наиболее очевидных эффектов политики. Например, если вы тестируете политику длины пароля, попробуйте изменить пароль на тот, длина которого точно соответствует требуемой. Пока вы это делаете, попробуйте изменить пароль на короткий пароль или пустой пароль. Не совершайте ошибку, тестируя только одну учетную запись пользователя. В зависимости от того, как настроена ваша сеть, политика более высокого уровня может переопределить недавно установленную политику для некоторых пользователей, поэтому вам следует поэкспериментировать с различными учетными записями пользователей.
После того, как вы выполнили базовое тестирование, чтобы убедиться, что новая политика работает, неплохо было бы поискать побочные эффекты. Помните, что некоторые приложения используют учетные записи служб, зависящие от пароля. Попробуйте одолжить несколько пользователей, чтобы они вошли в систему на лабораторном ПК и немного поработали, чтобы убедиться, что все работает так, как должно.
Прежде чем я продолжу, я хочу отметить одну вещь. В моем примере я использовал изменение политики длины пароля. Хотя изменение требуемой длины пароля может иметь неожиданные последствия, тратить десятки часов на тестирование изменения требования к длине пароля в лаборатории, вероятно, нецелесообразно для большинства организаций. В реальной жизни степень проводимого вами тестирования будет коррелировать со сложностью изменений, которые вы вносите. Даже если вы не делаете ничего сложного прямо сейчас, было бы неплохо создать лабораторию, потому что вы можете использовать ее для тестирования практически всего, что вы планируете делать в своей производственной сети (например, обновление операционной системы или развертывание). новое приложение).
Пилотное развертывание
Предполагая, что ваша лаборатория очень похожа на вашу рабочую сеть и что вы потратили достаточно времени на тестирование новой политики безопасности, у вас должно быть довольно хорошее представление о том, как новая политика повлияет на рабочую сеть. Пока кажется, что новая политика работает так, как ожидалось, без каких-либо серьезных негативных побочных эффектов, вы можете внедрить ее в своей производственной сети. Помните, однако, что трудно адекватно протестировать каждую возможную ситуацию в лаборатории, и вполне возможно, что пользователи столкнутся с условиями, которые никогда не моделировались в лаборатории. В этом случае рекомендуется сначала выполнить пилотное развертывание, а не полномасштабное развертывание.
Не существует правильного или неправильного способа выполнения пилотного развертывания. Фактический метод, который вы захотите использовать, во многом зависит от того, как настроена ваша сеть. Главное, что вы должны попытаться сделать, это создать пилотную тестовую группу, состоящую из пользователей с разными типами заданий. Идея состоит в том, что пользователи с разными должностными обязанностями используют сеть по-разному, и чем шире выбор, тем больше вероятность того, что ваша пилотная программа обнаружит какие-либо ошибки, которые могут присутствовать в вашей новой политике безопасности.
На протяжении многих лет я видел, как пилотные развертывания выполнялись разными способами. Например, если в организации много филиалов, может быть целесообразно назначить один из филиалов полигоном для тестирования вашей новой политики безопасности.
Если в вашей организации не так много филиалов, лучшей альтернативой может быть назначение одного конкретного домена в качестве группы пилотного развертывания. Я также видел, как несколько администраторов создавали организационное подразделение и назначали ему новую политику. Затем они перемещают случайную выборку пользователей во вновь созданную OU. Метод OU работает очень хорошо, но может быть непрактичным для организаций, в которых уже есть несколько подразделений.
Какой бы метод пилотного тестирования вы ни выбрали, вы должны понимать, что существует вполне реальная вероятность того, что любой или все ваши тестовые пользователи могут столкнуться с проблемами. Вы и ваш персонал службы поддержки должны быть готовы к возможному потоку обращений в службу поддержки, и вы должны быть готовы удалить новую политику, если будет установлено, что она вызывает проблемы. Однако более чем вероятно, что если вы хорошо поработали с лабораторным тестированием, новая политика будет нормально работать в ограниченном развертывании, и вы сможете перейти к полномасштабному развертыванию.
Полномасштабное развертывание
Надеюсь, к настоящему моменту у вас есть четкое представление о том, как именно изменение политики безопасности повлияет на пользователей, компьютеры и приложения. Как только вы освоитесь с тем, как ведет себя новый параметр политики безопасности, вы можете развернуть этот параметр в остальной части организации. В зависимости от характера новой политики вы также можете рассмотреть возможность рассылки памятки, информирующей пользователей о том, что произошло изменение, и о том, как это изменение повлияет на них. Конечно, служебная записка необязательна, но по моему опыту каждый раз, когда я когда-либо вносил заметные изменения в производственную сеть и не информировал всех заранее, служба поддержки была завалена телефонными звонками.
Вывод
В этой статье я объяснил, что, хотя Windows упрощает внесение изменений в политику безопасности вашей сети, незначительные изменения политики могут иметь серьезные последствия. Затем я объяснил, как можно использовать лабораторное тестирование и ограниченное пилотное развертывание для проверки последствий предлагаемого изменения политики безопасности до полномасштабного развертывания.