Глава 7. Упрочнение и безопасность

Windows Defender присутствовал на протяжении лет, но его терминология и возможности получили реальное развитие на протяжении последних пары выпусков ОС. Изначально он стартовал в Windows 8 как некий свободно распространяемый встроенный антивирусный продукт, и он не воспринимался всерьёз в то время. Быстро переходя к нашим дням, я теперь редко встречаю среди Windows 10 компьютеров представителей, имеющих отключёнными возможности Антивируса (AV) или межсетевого экрана Defender. Эти инструменты присутствуют в имеющейся ОС и по умолчанию включены, причём как результат получается уровень интеграции и оперативности, которым трудно соответствовать сторонним производителям. Я могу рассказать вам как много раз я отслеживал утечки памяти и случайные перезагрузки вызываемые плохой работой антивирусного программного обеспечения сторонних разработчиков, что неприемлемо в современном мире серверов. Кое- кто всё ещё рассматривает те антивирусные возможности, которые предоставляет Defender тусклыми, скорее всего по той причине, что они бесплатны, но я нахожу их надёжными м интегрированными с самим Windows. Я всё ещё наблюдаю продукт Windows Defender наполненный клиентами и серверами.

Ещё более новый и специфично звучащий ATP (Advanced Threat Protection, Расширенная защита от угроз) Windows Defender на самом деле некое семейство продуктов и систем, которые совместно работают для предоставления защиты машинам Windows. Антивирусы/ противодействие злым умыслам только одна из таких возможностей, а встроенный антивирус всё ещё достаточно новая идея, когда мы обсуждаем семейство ОС серверов Windows. Самый первый сервер, который я увидел со встроенным антивирусом Defender был Windows Server 2016. Я подозреваю, что большинство серверов работающих в промышленности для компаний всё ещё на данный момент продолжают оставаться Windows Server 2012R2, а следовательно усиленное присутствие инструментария Defender в Server 2019 ещё одна причина для того чтобы начать уже сегодня планировать свою миграцию.

Мы просто не располагаем достаточным пространством на страницах чтобы погружаться во все аспекты ATP Windows Defender, причём он постоянно совершенствуется. То что мы сделаем, так это исследуем некоторые имеющиеся взаимодействия, убедимся что вы знакомы с тем как применять наиболее распространённые компоненты и расширим ваши познания в некоторых наиболее современных свойствах, которые доступны для дальнейшего изучения и погружения в них.

Вы её уже выполнили! Windows Defender устанавливается по умолчанию в Windows Server 2019. На самом деле, пока вы не предпримите чего- нибудь чтобы изменить это, AV Defender не только установлен, но он также автоматически защищает вашу систему сразу после установки своей ОС. Но если вы не принимайте мои слова на веру, когда вы откроете Server Manager и выберите Add roles and features, кликните затем по странице Select features и вы должны обнаружить помеченным флажок, идущий вслед за Windows Defender Antivirus:

Если он по какой- либо причине пока ещё не помечен, это именно то место для посещения чтобы установить его и запустить в работу.

Сам интерфейс для инструментария Windows Defender в точности тот же, что и внутри самых последних версий Windows 10, но если вы его пока не изучали, мы его здесь быстренько рассмотрим. Пройдите вперёд и запустите Settings изнутри меню Start, затем кликните по Update & Security. Попав вовнутрь этого раздела, вы обнаружите слева перечисленными Windows Security. Здесь вы получаете служебный просмотр различных работающих сообща над защитой вашей системы компонентов Defender.

Помните, что вы не включали никакие из этих возможностей; все они доступны сразу после установки.

Кликнув далее по одной из этих Protection areas вы перенесётесь к более подробному описанию подробностей каждой из возможностей, а также ко множеству параметров которые включают и запрещают различные существующие определённые защиты. К примеру, если вы кликнули по Virus & threat protection, вы увидите итоговую информацию относительно AV Defender, когда обновлялись его файлы определений, что просканировано и и так далее. Затем кликните далее по ссылке с названием Manage settings вы получите свои параметры для отключения AV Defender если это вам потребуется, а также разнообразные прочие параметры которые вы можете выбирать или отключать. Вот некий снимок экрана всего лишь для небольшого числа доступных внутри AV Defender настроек. Я выбрал для отображения именно эти три, так как они важны для прочих тем, которые мы вскорости рассмотрим, когда будем обсуждать свою порцию ATP Defender:

Вы уже знаете, что AV Defender включён по умолчанию как и многие прочие компоненты, которые составляют обсуждаемое семейство продуктов Windows Defender. Перекинув в другое положение показанную на предыдущем снимке экрана кнопку, у вас имеется возможность временного отключения AV. Продвинемся ещё на один шаг вперёд если вы абсолютно уверены что вы не желаете применять AV Defender, поскольку у вас имеется собственное программное обеспечение AV, за которое вы уже заплатили, у вас есть две проторённые дороги которыми вы можете пойти.

Во- первых, AV Defender разработан с автоматическим шагом вниз в том случае когда установлен иной AV. Скорее всего, всё что вам требуется, это установить ваши антивирусный инструмент стороннего разработчика, а после того как ваш сервер завершит перезагрузку, AV Defendeer вернётся на место и позволит работу продукта стороннего разработчика с тем чтобы они не конфликтовали друг с другом. Это важно, так как это факт, что подавляющее большинство компьютерных специалистов не допускают исполнение множества программ AV в отдельной системе, так как в целом это ужасная идея. Зачастую это приводит к их конфликтам друг с другом, имеет ошибки выделения памяти, а также вызывает прочее странное и замедляющее поведение в вашей системе.

Если вы планируете применять своё собственное AV и желаете убедиться что Defender удаляется полностью, можно окончательно выполнить деинсталяцию с вашего сервера функций Defender. Проще всего это сделать через PowerSell следующей командой:

Uninstall-WindowsFeature -Name Windows-Defender
		

Достаточно сложно в точности определить что означает ATP, так как он является вершиной всех тех частей, фрагментов и механизмов безопасности Windows Defender, которые работают совместно чтобы защищать клиентов и серверы от плохого наполнения: AV, возможности межсетевого экрана, аппаратная защита, а также даже особая устойчивость к требующему выкупа кода. Такое сочетание совместных возможностей внутри раздела Безопасности Windows в Server 2019 и становится ATP.

Нечто, что должно быть особенно интригующим для всех нас, так это тот интеллектуальный способ, которым Microsoft теперь применяет связь с облаком и вычисления чтобы улучшать AV Defender на повседневной основе. Осознаём ли мы это или нет, большинство подключаемых в мире в Интернет машин Windows сейчас помогают друг другу сообщать о вновь возникающих уязвимостях и вредоносных активностях обратно в Microsoft. Эта информация впоследствии подвергается разбору и машинному обучению, а получаемая в результате информация получает возможность немедленно применяться всеми остальными машинами Windows по всему миру.

Хотя это слегка и созвучно с Большим Братом и наполнено подлежащим рассмотрению частным особенностям, я верю, что мы в целом как сообщество вскоре избавимся от этой боязни и осознаем те преимущества, которые перевешивают наши опасения. В наши дни миллионы пользователей пропускают свою электронную почту через Office 365; вы можете даже не осознавать это, но Office 365 также выполняет и такой вид обработки чтобы выявлять и блокировать подобную эксплуатацию. К примеру, если некий адрес электронной почты внутри какой- то компании непрерывно отправляет электронную почту большим группам людей, а это электронное сообщение содержит некий документ Word с включёнными макросами, что является чем- то тем, что обычно этот пользователь не выполняет, Office 365 скорее всего перенесёт этот документ в некую зону безопасности, откроет его (или запустит его если так случится что его присоединение является исполняемым) и выявит или нет что данный файл выступает некой разновидностью вредоносного обеспечения. Если это так, Office 365 немедленно начнёт блокировать такой файл, тем самым останавливая распространение такого потенциально пагубного поведения. Всё это произойдёт без вмешательства конкретного пользователя или соответствующей команды ИТ компании. Это даже не сопровождается особыми действиями внутри компании. Если одно из моих пользовательских электронных писем является первым полученным новым вирусом, а это будет выявлено Microsoft, такое поведение поможет блокировать такой новый вирус для всех прочих потребителей, которые также имеют свою электронную почту в облаке Microsoft. Это достаточно неправдоподобное наполнение!

Та же самая идея остаётся верной и для AV Defender когда вы выбираете разрешение позволить ему взаимодействовать с Microsoft и передавать информацию в облачные ресурсы Microsoft. Ранее я выставлял некий снимок экрана кое с какими возможностями AV Defender под названием cloud-delivered protection and automatic sample submission (движимая облаком защита и автоматическое представление образцов) - это та часть AV Defender, которая делает возможной магию облачного решения и преимущества всей популяции компьютеров.

И снова мы рассматриваем нечто выглядящее длинным заголовком для технологии, которая имеет очень специфические цели, так? Совсем нет. Такой новый Защитник применения (Exploit Guard) не является какой- то новой возможностью, а вместо этого целым набором новых возможностей, испечённых в семействе Windows Defender. В частности, эти новые защитные возможности разработаны в помощь выявлению и противодействию некоторых из распространённых манер поведения, которые применяются современными вредоносными атаками. Вот четыре первичных компонента ATP Защитника применения Defender:

Давайте поиграем в игру ассоциируемых слов. Я скажу что- нибудь, а вы ответите первым пришедшим вам в голову словом.

Сетевая безопасность.

Вы сказали межсетевой экран (firewall)? Когда мы рассуждаем о безопасности своих устройств на сетевом уровне, мы говорим о периметрах. Такие периметры определяются и защищаются межсетевыми экранами, причём в основном на аппаратном уровне, на чём специализируются сетевые устройства, сделанные для обработки таких определённых задач в наших сетевых средах. Сегодня мы здесь чтобы обсудить другой уровень межсетевых экранов, который вы можете и должны обслуживать в своих средах. Да, мы говорим о Межсетевом экране Windows. Прекратите хохотать, это грубо!

Легко подшучивать над Межсетевым экраном Windows на основе его истории. В дни Windows XP и Server 2003 им просто невозможно было пользоваться и он больше вызывал головную боль, чем решал проблемы. На самом деле это его восприятие стало настолько распространённым, что я и по сей день нахожу многие компании, которые полностью вовсе отключают Windows Firewall в своих подключаемых к домену системах в виде определяемой по умолчанию политики. Когда я спрашиваю их о причине, обычно она не определена - мы всегда делали так или это предписанная политика таковы стандартные ответы. И именно это основная проблема, поскольку WFAS (Windows Defender Firewall with Advanced Security, Межсетевой экран Windows Defender с расширенной безопасностью), который сегодня присутствует в ОС Windows намного более надёжен и современен, чем был когда- то ранее и совершенно точно может применяться для расширения вашей архитектуры безопасности. Я бы даже зашёл настолько далеко, что это абсолютно глупо отключать WFAS в современных ОС пока у вас нет совершенно конкретной и обоснованной причины для этого.

Во- первых, важно знать что имеются три консоли из которых у вас имеется возможность настраивать установки Межсетевого экрана Windows. Две из этих консолей являются избыточными друг относительно друга, а третья имеет гораздо больше возможностей чем остальные. Давайте быстро рассмотрим их одну за другой.

WDF (Панель управления)

Когда вы пробуете запустить любое приложение или установки в Windows Server 2019, обычно наиболее действенно просто кликнуть по кнопке Start и затем набрать некое слово, имеющее отношение к той задаче, которую вы намерены выполнить. В моём случае я выполняю клик по Start и набираю firewall. Наилучший вариант соответствия, который предоставился первым в результатах моего поиск, оказался Windows Defender Firewall (WDF), поэтому я двигаюсь далее и кликаю по нему.

Интересно, что данная ссылка открывет консоль настроек Межсетевого экрана Windows изнутри Control Panel, что является способом старой школы для выполнения настроек системы. Эта консоль всё ещё работает и полностью способна манипулировать базовыми функциями работы межсетевого экрана,такими как включение и отключение самого Межсетевого экрана Windows, но так этот инструмент расположен внутри Control Panel, у нас есть предположение, что на самом деле это не тот инструмент, который подразумевался Microsoft для применения нами. Запомните, все новые возможности настроек переместились в экраны Windows Settings, вместо того чтобы быть представленными в Control Panel:

Межсетевой экран и сетевая защита (Настройки безопасности Windows)

В то время как инструменты на основе Control Panel всегда занимали должное место для выполнения необходимых изменений в предыдущих версиях ОС, мы уже знаем, что многие параметры Windows Defender хранятся внутри Windows Settings. Может ли быть так, что и в этом случае установки настроек Межсетевого экрана Windows Defender хранятся внутри раздела Windows Security из Settings?

Да это несомненно так. Откройте Windows Settings и кликните по Update & Security, а затем по Windows Security. Вы уже бывали здесь ранее - это тот экран, который предоставляет быстрое резюме всех компонентов Windows Defender. Конечно же, здесь имеется такое с названием Firewall & network protection. Кликните по этой кнопке и вы войдёте в новую платформу настроек для функций Межсетевого экрана Windows, который не существовал в предыдущих версиях Windows Server:

Кликнув по любой из тех ссылок, которые представлены здесь, вы откроете дополнительные параметры настроек. Например, если вы желаете быстро включать и отключать определённые профили межсетевого экрана (вскоре мы изучим их), вы можете кликнуть по тем профилям которые вы желаете настраивать, например, профилю Domain network, и отсюда вы сможете запросто отключать свой межсетевой экран для этого сетевого профиля. Многие компании отключают для своих машин профиль Domain network чтобы этот межсетевой экран не защищал обмен, который происходит внутри корпоративной локальной сети.

Хотя запрет данного межсетевого экрана и является в целом плохой идеей, порой это требуется чтобы удовлетворить вашей бизнес- модели:

Данный экран настроек, доступный изнутри Windows Settings является хорошим местом чтобы выполнять простые решения на верхнем уровне относительно Межсетевого экрана Windows Defender, однако этот интерфейс ограничен в возможностях. Для любого реального применения функций или настроек межсетевого экрана ...

Межсетевой экран Windows с расширенной безопасностью (WFAS)

Если вы похожи на меня, вас не удовлетворит эта информация и вы захотите увидеть что происходит под капотом, а потому вы пожелаете слегка больше информации чем та, что способны вам предоставить базовые инструменты Межсетевого экрана Windows. Вы можете либо кликнуть по ссылкам Advanced settings, показанным в предыдущих снимках экранов, или просто открыть Приглашение командной строки или запустить приглашение Start | Run и набрать wf.msc. Любое из этих действий запустит полную консоль администрирования WFAS:

Здесь вы можете видеть гораздо больше глубинной информации относительно имеющейся активности и правил, которые вступают в игру при посредстве Межсетевого экрана Windows, а также выполнять намного больше неотложных регулировок в ваших разрешениях и блокированиях. Также имеется раздел Monitoring, в которм у вас есть возможность просмотра активных вовлечённых правил, включая Connection Security Rules. Это важный раздел, поскольку он подчёркивает тот факт, что WFAS выполняет гораздо больше чем простая блокировка сетевого обмена. Это не просто межсетевой экран, но также и платформа для подключений. Если вы планируете применять IPsec для шифрования сетевого обмена, будь то естественный IPsec внутри вашей сетевой среды, или же это происходит в технологии удалённого доступа DirectAccess, вы обнаружите наполняющие это раздел правила, которые являются определениями таких туннелей IPsec. Межсетевой экран Windows на самом деле отвечает за то, чтобы заставить установление таких шифрованных подключений. Именно это является более современным, нежели Межсетевой экран Windows вчерашнего дня.

Когда какая- то NIC в компьютере или сервере подключена к сетевой среде, имеющийся Межсетевой экран Windows назначает это подключение одному из трёх различных профилей. Скорее всего вы уже ранее взаимодействовали с этим процессом принятия решения, даже и не осознавая того. Когда вы подключаете свой ноутбук к Wi-Fi в своей местной кофейне, спрашивал ли вас Microsoft подключаетесь ли в к домашней, рабочей или общедоступной сетевой среде? Это именно Межсетевой экран Windows задаёт вам вопрос относительно того какой именно профиль вы предпочитаете назначить своему новому сетевому подключению. Основная причина, по которой вы можете назначать NIC и сетевые подключения различным профилям межсетевого экрана состоит в том, что вы можете назначать различные правила и критерии доступа для того что разрешается, а что нет поверх таких различных профилей. На самом деле он спрашивает вас насколько вы доверяете данной сетевой среде? К примеру, когда ваш ноутбук подключается к своей корпоративной сетевой среде, скорее всего вы можете быть слегка более расслабленным, нежели когда тот же самый ноутбук подключается в отелях по всей стране. Назначая более интенсивные правила межсетевого экрана в тот профиль, который активен когда вы пребываете в отеле, вы выстраиваете более высокое препятствие с которым сталкиваются атакующие когда вы работаете в таком общедоступном интернете. Давайте рассмотрим эти три различных типа доступных профилей с кратким описанием каждого:

Всякое сетевое подключение получает назначенным её собственное определение профиля, причём несомненно вы можете иметь активным более одного профиля межсетевого экрана в одно и то же время в одной и той же системе. Например, мой сервер RA1 подключён как к корпоративной, так и к общедоступной сетям. А внутри WFAS вы можете увидеть активными и Профиль домена и Общедоступный профиль:

В качестве альтернативы, когда вы откроете в этом сервере Network and Sharing Center, здесь мы также сможем обнаружить перечисленными эти профили, а вы сможете быстро выяснить какая NIC применяет какой профиль:

Теперь, когда мы знаем что составляет плоть и кровь нашего Межсетевого экрана Windows внутри имеющейся консоли WFAS, давайте воспользуемся WFAS чтобы создать собственное новое правило. В своём сервере RA1 я разрешу доступ RDP с тем, чтобы я легко мог управлять этим сервером со своего рабочего места. Тем не менее, включая RDP, я теперь разрешаю доступ RDP к этому серверу из всех сетевых сред. Это означает, что я могу получить доступ к серверу RA1 изнутри своей сетевой среды, но также я способен выполнять RDP и из Интернет, поскольку это сервер удалённого доступа и может так получаться что к нему будет выполняться подключение напрямую через Интернет. Это большая проблема, так как теперь любой yahoo из Всемирной паутины потенциально сможет обнаружить мой сервер, найти его приглашение на регистрацию RDP и попытаться силой войти таким образом в RA1.

Для частичного снятия данной проблемы я хочу плющить RDP только со своей внешней NIC. Я желаю оставить его активным внутри с тем, чтобы я мог продолжать доступ к этому серверу со своего рабочего места, но существует ли некий простой способ внутри WFAS для создания некого правила, которое блокирует RDP доступ только извне? Да, несомненно оно имеется.

Откройте wf.msc чтобы запустить Межсетевой экран с расширенной безопасности Windows Defender и перейдите к разделу Inbound Rules и вы увидите все имеющиеся входящие правила межсетевого экрана, которые присутствуют в этом сервере (если вы никогда не бывали ранее в этом разделе, здесь имеется перечисленными множество правил, все эти правила установлены при помощи ОС). Кликните правой кнопкой по Inbound Rules и выберите New Rule.... Это запустит мастер, из которого мы будем создавать своё новое правило межсетевого экрана. Самым первым экраном является тот, в котором мы будем указывать какой вид правила мы хотим создать. Вы можете создать некое правило, которое изменяет обмен для какой- то определённой программы, либо вы можете просмотреть некий перечень Predefined протоколов. Однако я хочу в точности знать что делает моё правило по причине того способа, который определяю я, а не по причине предварительно имевшегося определения протокола, а также мне известно, что RDP работает по порту 3389. Поэтому я собираюсь в этом экране выбрать порт и после того как я кликну по Next, я определю 3389 как конкретно тот порт, который я намерен изменить:

Наш третий шаг состоит в выборе того желаем ли мы разрешать или блокировать этот конкретный порт. В перечислении также имеется и третий вариант, относительно того чтобы разрешать это подключение только в случае его аутентификации через IPsec, что является мощным вариантом, но он требует уже установленного подключения IPsec в нашей сети. Из- за данного требования данный вариант неприемлем для большинства людей. Для нашего примера мы уже имеем работающим RDP, но мы не желаем заблокировать его для единственной определённой NIC, поэтому я намерен выбрать Block the connection:

Мы не желаем блокировать RDP для всех имеющихся NIC, следовательно данный экран очень важен. Здесь нам следует сослаться обратно на те знания, которые мы обсуждали относительно таких профилей. Вы помните, что все подключаемые к нашей сетевой среде домена внутренние NIC будут иметь назначенным им Профиль домена. В то время как все те NIC, которые не подключены к внутренней сети, в которой расположен контроллер домена, будут иметь активным либо Частный, либо Общедоступный профиль. Именно это знание нам требуется представить в данном экране. Если мы желаем запретить RDP только для всех внешних NIC, нам требуется активировать это правило только для Частных и Общедоступных профилей. На самом деле, оглядываясь назад на тот снимок экрана, который мы уже рассматривали, мы можем обнаружить, что внешней NIC определённо назначается значение Общедоступного профиля, а поэтому мы здесь можем пометить только флажок Public и RDP после этого будет блокироваться во всех внешних NIC. Однако в случае если мы добавим в будущем ещё NIC для этого сервера, с помощью которых мы желаем убедиться что доступ по RDP не возможен, мы оставим помеченными и флажок Public, и флажок Private , чтобы гарантировать в будущем лучшую безопасность. Убедитесь, что вы uncheck свой профиль Domain! В противном случае вы окончательно целиком заблокируете доступ RDP, а если вы в настоящий момент вы применяете RDP для подключение к данному серверу, вы вышибете себе самостоятельно и у вас не будет возможности подключиться повторно:

А теперь мы просто создаём некое название для своего нового правила и мы закончили! Наша возможность в RDP к данному серверу через интернет немедленно была отключена и мы сегодня ночью можем отдыхать намного проще.

Очень часто я нахожу что мне требуется создавать правило либо по разрешению, либо для блокирования ICMP. Иными словами, я часто обнаруживаю потребность регулировки в серверах межсетевого экрана чтобы включать или запрещать в серверах их возможность отвечить назапросы ping. Вероятно вы уже заметили, что для новых ОС серверов для их межсетевых экранов типичным является сразу после установки атоматическая блокировка ping (ICMP). Это является проблемой для сред, в которых ping является стандартным методом того, доступен ли некий употребляемый IP адрес. Вы можете смеяться, но, поверьте мне, что всё ещё имеется достаточно много администраторов ИТ, которые не отслеживают какие именно адреса IP они используют внутри своих сетевых сред, а когда они сталкиваются с ситуацией, связанной с установкой нового сервера и им требуется принять решение какой IP адрес ему присвоить, они просто запускают ping IP адресов в своей сетевой среде пока не обнаружат один из тех, который отвечает тайм- аутом! Я наблюдал это много раз. Хотя это и не самый лучший способ управления IP адресами, так бывает. К несчастью, этот метод сталкивается с громадной проблемой, потому как большинство новых установок Windows спроектированы на блокирование откликов ICMP сразу после установки, что означает, что вы не можете выполнять ping для некого IP адрес и получать некий тайм- аут, но тем не менее по этому адресу может присутствовать запущенный сервер.

Итак, давайте вернёмся к этому моменту. Вам может потребоваться включить ICMP в своём сервере с тем, чтобы он отвечал когда некто пытается выполнять ping к нему. Когда вам требуется создать новое правило, которое позволит происходить ping, мы настраиваем это правило в точности так же как мы делали это для RDP, но имеется одна большая западня. В самом первом экране Rule Type при создании вашего нового правила когда вы должны определить какой вид правила вы создаёте, нет никаких вариантов или предварительных определений для ICMP. Я нахожу это странным, так как это очень распространённый тип правила, чтобы быть помещённым здесь, но увы, выбор ICMP из имеющегося ниспадающего меню был бы слишком простым. Вместо этого вам придётся делать это через создание нового входящего правила, в точности как и для RDP, однако в самом первом экране для Rule Type убедитесь что вы выбрали вариант с названием Custom.

Далее оставьте значение выбранного варианта для определения этого правила для All programs. Снова кликните далее и теперь вы имеете ниспадающий блок с названием Protocol type. Именно в этом меню вы можете выбрать новое правило для манипуляций с ICMP обменом. Как вы можете видеть в следующем снимке экрана,у вас имеется вариант выбора из ICMPv4 или ICMPv6, в зависимости от того, какой сетевой обмен вы предпочитаете. Моя лаборатория для проверок является приспособленной только под IPv4, поэтому я намерен выбрать ICMPv4:

Для всего остатка создания правила ICMP следуйте тем же самым процедурам, которые мы вывели при создании своего правила RDP, выбирая разрешать или блокировать этот обмен, а также для каких профилей. После завершения ваше новое правило ICMPv4 немедленно вступит в действие и, если вы настроили правило Allow, ваш сервер теперь сможет отвечать на запросы ping:

Если вам требуется изменить некое правило, либо погрузиться в дополнительные подробности правила межсетевого экрана, вернитесь обратно в свой экран Inbound Rules, по которому вы кликнули правой кнопкой в любом персональном правиле межсетевого экрана и проследуйте в Properties. Внутри этих закладок у вас имеется возможность изменять любые критерии относительно данного правила. Например, вы можете выделить дополнительные порты, вы можете изменять к какому именно профилю его применять, или даже можете ограничить для каких конкретных адресов IP применять это правило, воспользовавшись закладкой Scope.

Это позволяет вам применять своё правило межсетевого экрана для входящего или исходящего обмена, происходящего в определённой части вашей сетевой среды, или конкретном подмножестве ваших машин. Напрмиер, здесь я изменил свою закладку Scopeчтобы отразить тот факт, что я желаю применять данное правило который происходит в моей подсети 192.168.0.0/16:

Управление правилами межсетевого экрана в ваших серверах и клиентах может стать гигантским шагом вперёд к более безопасное среде в вашей компании. Что тут самое лучшее? Эта технология является технологией корпоративного уровня и свободно доступна для применения так как она уже встроена в те ОС, которые вы применяете. Единственная цена, которую вы связываете с межсетевым экраном на данном уровне это то время, которое займет у вас размещение этих правил на свои места, что может стать ночным кошмаром администратора если вам требуется реализовать целый список разрешений и блокировок в каждой машине индивидуально.

Отдадим должное благости GPO (Group Policy Object). Как это имеет место и для большинства настроек и функций внутри платформы Microsoft, установка некой политики, которая применяется ко всем являетсялёгким ветерком для ваших подключаемых к домену машин. Вы даже имеете возможность разбить их на множество наборов политик, создавая GPO, который применят правила межсетевого экрана для ваших клиентов, а также отдельный GPO, который применяет правила межсетевого экрана для ваших серверов, как вы сочтёте нужным. Основной момент состоит в том, что вы можете группировать множество машин вместе по категориям, создавать наборы правил GPO для каждой из категорий, и автоматически применять их ко всем машинам применяя мощность возможностей распространения GPO.

Вы уже знакомы с созданием GPO, поэтому давайте пройдём далее и создадим GPO, который будет содержать некий настройки межсетевого экрана для нас, с которыми мы поиграем. Свяжите и отфильтруйте свой GPO надлежащим образом чтобы он получал только те машины, к которым вы желаете применить эту настройку. Возможно, хорошим местом для начала будет проверочный OU с тем, чтобы вы убедились что все правила, которые вы намерены поместить внутри данного GPO хорошо работают совместно, причём со всеми уже имеющимися политиками, прежде чем распространить эту новую политику на все ваши рабочие силы.

После того как вы создали новый GPO, кликните правой кнопкой по нему изнутри Group Policy Management Console и кликните по Edit...:

Теперь, когда вы рассматриваете этот новый GPO изнутри, нам сего лишь требуется определить правильное местоположение чтобы создать некие новые правила межсетевого экрана. Когда мы просматриваем правила внутри самой локальной машины, все они перечислены под заголовком Windows Defender Firewall with Advanced Security и он расположен в Computer Configuration | Policies | Windows Settings | Security Settings | Windows Defender Firewall with Advanced Security | Windows Defender Firewall with Advanced Security:

Как вы можете видеть, это также то место, это также и то место, в которое надо следовать, когда вы желаете убедиться, что определёно включаются или отключаются конкретные профили межсетевого экрана, или весь Межсетевой экран Windows целиком. Кликая по свойствам Межсетевого экрана Windows Defender, по показанной ранее ссылке, вы можете определять значение состояние для каждого профиля межсетевого экрана персонально:

После того как вы завершите настройки своих профилей в соответствии со своими потребностями, клините по OK и вы обнаружите что вернулись обратно в свой WFAS в часть GPO. Прямо внутри даной локальной консоли WFAS у вас имеются категории Inbound Rules и Outbound Rules. Просто кликните правой кнопкой по Inbound Rules и кликните по New Rule... чтобы начать построение правила прямо в этом GPO. Пройдите тот же самый мастер с которым вы уже ознакомились при создании некого правила в своей локальной консоли WFAS, а когда завершите, ваше новое правило межсетевого экрана будет отображено в этом GPO.

Это правило межсетевого экрана уже проделало свой путьв Active Directory и установило себя на те компьютеры и серверы, которые вы определили в ссылках и критериях фильтрации данной политики:

Идея, которая сделала большой шаг от того с чем пытаются поиграть большие организации к тому что требуется всем это применение шифрования. Многие из нас многие годы шифруют обмен наших вебсайтов с применением вебсайтов HTTPS, но даже в этой области имеются удивительные исключения: многие экономичные хостинговые компании по- прежнему предоставляют страницы входа, которые передают обмен в виде открытого текста. Это ужасно, так как всё то что вы передаёте через открытый интернет в наши дни применяя обычный HTTP или нешифрованную почту, всё это вы должны считать что это также доступно для прочтения и кому- то ещё. Скорее всего, вы страдаете параноей, и никто не перехватывает и не читает ваш обмен, но вы должны знать, что если обращаетесь к веб-сайту с сообщением HTTP в адресной строке или, если вы отправляете электронное письмо из любой бесплатной почтовой службы, любые данные, вводимые на этой веб-странице или в этом электронном письме, могут быть легко украдены кем-то на полпути в их Мир. Для корпоративной информации шифрование данных является абсолютно необходимым требованием относительно путешествующей через интернет корпоративной информации; хотя в то же самое время я говорю, что в глубине души мне возражают, что подавляющее большинство компаний по-прежнему не используют какие-либо технологии шифрования в своей системе электронной почты, и поэтому для большинства из них все еще остается ожидающей их потенциальная катастрофа.

В то время как мы всё лучше и лучше защищаем свой обмен в интернете через браузер, мы по- прежнему не уделяем большого внимания тем данным, которые пребывают в безопасности за стенами нашей организации. Теме не менее, плохие парни не глупы, и у них имеется очень большой набор трюков для социальной интеграции с нашими сетевыми средами. Оказавшись внутри, что они обнаруживают? В большинстве случаев это большая свобода для всех. Получите одну учётную запись пользователя или один компьютер, и у вас есть ключи от подавляющей части всего королевства. К счастью, в Windows Server 2019 имеется ряд технологий, разработаных для борьбы с подобными вторжениями и защиты ваших данных даже если они окружены четырьмя стенами вашего центра обработки данных. Давайте рассмотрим некоторые сведения о них чтобы у ввас была возможность изучить варианты применения таких технологий шифрования для дальнейшей защиты ваших данных.

BitLocker является технологией, которая стала достаточно знакомой для того чтобы наблюдать её в наших системах клиентов в рамках корпоративных сетевых систем. Это технология шифрования с полным приводом, которая снабжает нас преимуществом в том, что наши данные целиком защищены в ноутбуках или компьютерах, которые могут быть украдены. Если некий вор получает в свои руки ноутбук вашей компании, изымает его жёсткий диск и подключает его к своему компьютеру ... извини, Чарли, нет доступа, весь том зашифрован. Это имеет смысл для мобильного оборудования, которое может быть запросто утеряно или украдено, но на начальных этапах данной технологии никогда небыло реальных соображений относительно применения BitLocker для защиты наших серверов.

По мере эскалации приспособления к ресурсам облачных вычислений несомненно более существенным становится желание BitLocker в наших серверах. Более конкретно, когда мы обсуждаем облачные решения, то в чём мы действительно нуждаемся, это BitLocker в наших виртуальных машинах, будь то ОС клиента или сервера. Будете ли вы хранить свои VM (Virtual Machines, Виртуальные машины) в реальной облачной среде, предоставляемой общедоступным поставщиком облачных служб, или размещаетесь в своём собственном частном облачном решении, в котором арендаторы имеют богатые возможности создания и управления своими собственными ВМ без возможности шифрования таких виртуальных жёстких дисков - файлов VHD или VHDX - ваши данные абсолютно не безопасны. Почему нет? Потому что всякий обладающий правами администратора для данной платформы размещегия виртуализации запросто способен получить доступ к любым данным, располагающимся на жёстких дисках сервера, даже без каго бы то ни было доступа к вашей сетевой среде или учётной записи пользователя в вашем домене. Всё что им требуется, так это получить некую копию вашего файла VHDX (всего содержимого жёсткого диска вашего сервера), скопировать его на USB- устройство, принести домой, смонтировать этот виртуальный диск в своеёй собственной системе и бинго - они получают доступ к жёсткому диску вашего сервера и вашим данным. Именно в этом и состоит большая проблема соответствия безопасности.

Почему исторически не соблюдалось шифрование ВМ? По той причине, что BitLocker поступал с неким интересным требованием. Тот факт что жёсткий диск зашифрован, означает что он не способен загружаться без снятия защиты шифрованием. Как мы можем разблокировать свой жёсткий диск с тем, чтобы наша машина имела возможность для загрузки? Одним из двух способов. Самым лучшим методом является хранение значения ключа снятия блокировки внутри некого TPM (Trusted Platform Module, Доверенного модуля платформы). Это некий физический микрочип, который встроен прямо непосредственно в большинство компьютеров, которые вы приобретаете в наши дни {Прим. пер.: к сожелению, не в РФ.} Хранение ключа разблокирования BitLocker в этом чипе означает, что вам не приходится никак физически связываться с вашим компьютером для его загрузки, вы просто вводите некий пин- код для получеия доступа к имеющемуся TPM, а затем этот TPM снимает блокировку BitLocker. С другой стороны, когда вы выбираете развёртывание BitLocker без наличия некого TPM, для снятия блокировки с тома BitLocker и превращения его в загружаемый, вам требуется подключить некое физическое USB устройство, которое содержит соответствующие ключи BitLocker для снятия блокировки. Видите ли вы какие- нибудь проблемы с одним из этих сценариев установки виртуальных машин? Вм не могут иметь физического чипа TPM, а у вас также нет простого способа подключения какого- либо USB устройства! Итак, как мы можем шифровать такие ВМ, чтобы любопытные взгляды из хостинговой компании облачных решений не могли видеть в ё наше наполнение?

Введём виртуальный TPM. Эта возможность пришла к нам совершенно новой в Windows Server 2016; теперь у нас есть возможность придания своим серверам некого виртуального TPM, который может применяться для хранения подобных ключей! Это невероятная новость, и она означает, что мы наконец можем шифровать свои серверы, размещаются ли они на физических серверах Hyper-V в вашем центре обработки данных, или располагаются в облаке Azure.

Применяя BitLocker и виртуальный TPM для шифрования и защиты файлов виртуальных дисков производится нечто, именуемое Защтщённой ВМ (Shielded VM). Защищённые ВМ в качестве такой возможности впервые были предложены в Windows Server 2016 и были дадее усовершенствованы в Windows Server 2019. Я знаю, что это всего лишь крошечная проба и предварительный просмотр этой удивительной новой технологии, но я бы хотел упомянуть о ней здесь, поскольку она по определению относится к вопросам безопасности наших серверных сред.

Более подробно мы рассмотрим Защищённые ВМ в Главе 12, Виртуализация вашего центра обработки данных при помощи Hyper-V.

Разве не было бы замечательно если бы мы имели возможность настраивать, контролировать и управлять своими сетевыми средами из графического интерфейса администрирования, вместо того чтобы смотреть целыми днями на CLI маршрутизатора? Разве мы не получили бы выгоду от гибкости сетевой среды для перемещения серверов и рабочих нагрузок из одной подсети в другую без необходимости изменения IP адресации и маршрутизации на этих серверах? Неужели мы не можем найти некий способ автоматичиского шифрования всего обмена, который проходит между нашими серверами без необходимости настраивания такого шифрования в самих серверах?

Да, да, да! Мы можем делать все эти вещи псредством применения SDN (Software Defined Networking, Программно определяемых сетевых сред) и новой возможости, именуемой encrypted virtual networks (зашифрованными виртуальными сетями). Это раздел текста просто ориентировка, место, которое поможет вам вернуться к Главе 5, Построение сетей Windows Server 2019, если вы вдруг пропустили её, оказавшись в этом месте. Мы уже обсуждали SDN и их новые возможности по созданию автоматически шифруемых виртуальных сетей, которые протекаютмежду ВМ Hyper-V и серверами хостинга Hyper-V, поэтому если вас заинтересовала эта идея, вернитесь назад чтобы ещё раз познакомиться с этой главой.

Encrypting File System (EFS, Зашифрованная файловая система) является компонентом Microsoft Windows, который имеется как в ОС клиентов, так и в ОС серверов на протяжении многих лет. В то время как BitLocker служит для шифрования тома или диска целиком, EFS слегка более конкретная. Когда вы желаете зашифровать только определённые документы или папки, это именно то что вам требуется ключить. Когда вы выбираете шифрование файлов с помощью EFS, важно понимать, что Windows требуется применять некий сертификат пользователя в качестве общего процесса шифрации/ дешифрации, а следвательно ключом для успешного развёртывания является доступность некого внутреннего PKI. Также важо отметить, что ключи аутентификации связываются таким паролем пользователя, поэтому полностью взломанная учётная запись пользователя может свести на нет те преимущества, которые предоставляет EFS.

Я полагаю, что многие компании не применяют EFS потому что вы оставляете пользователю право на принятие решения какие именно документы шифровать. Это также означает, что вы зависите в первую очередь от того помнят ли они о необходимости шифрования, а это означает, что они обязаны осознавать всю важность этого чтобы заслуживать траты их времени на это. Я бы хотел упомянуть EFS потому что она всё ещё жива и всё ещё является действующей платформой в которй вы можете выполнять шифрование данных, но большинство администраторов в качестве лучшего решения применяют BitLocker. Отсутствие ответственности со стороны пользователя и достойная централизованная платформа управления помещают BitLocker на шаг вперёд по сравнению с EFS. Обе технологии, несомненно, могут соуществовать, сохраняя данные на разных уровнях, вместо того чтобы полагаться только на одну технологию шифрования для вас данных.

Вокруг данных в покое вращается большое число встроенных в ОС технологий шифрования. Но что относительно данных в их перемещении? Мы уже обсуждали применение SSL в вебсайтах HTTPS как некий способ шифрования данных веб браузера при их перемещении через Интернет, но что относительно данных, которые не перемещаются через некий веб браузер?

И что если я даже не рассматриваю сам Интернет; что если меня интересует защита обмена который происходит из одной точки в другую внутри моей корпоративной сетевой среды? Если что- то что может помогать с с такими видами требований? Естественно.

IPsec является комплектом протоколов, который может применяться для аутентификации и шифрования тех пакетов, которые могут возникать в процессе сетевого взаимодействия. IPsec не является некой технологией, которая специально разработана для мира Microsoft, однако в Windows Server 2019 существуют различные пути, которые могут применяться для безопасности данных, которые курсируют взад и вперёд между машинами.

Наиболее распространённое место, в котором демонстрируется взаимодействие IPsec в Windows Server, это при использовании роли Удалённого доступа. При настройке VPN в вашем сервере RA, у вас будет иметься некое число протоколов подключения VPN, которые могут применяться для подключения к этому серверу VPN. В этом перечне возможных платформ подключения содержатся туннели IPsec (IKEv2). Второй удалённой технологией, которая применяет IPsec является DirectAccess. Когда вы устанавливаете в своей сетевой среде DirectAccess, всякий раз когда некий компьютер клиента создаёт какой- то туннель DirectAccess через Интернет к его серверу DirectAccess, этот туннель защищается IPsec. К счастью, та Консоль управления Удалённого доступа, которую вы применяте для развёртывания как VPN, так и DirectAccess, достаточно интеллектуальны чтобы знать, что всё что им требуется, так это выполнить работу по аутентификации и шифрованию, и вам нет нужды знать какие- то обособленные моменты относительно IPsec чтобы заставить эти технолгоии удалённого доступа работать на вас!

Главным недостатком IPsec, обеспечиваемым ролью удалённого доступа, является обмен внутри вашей сетевой среды. Когда вы говорите о VPN или DirectAccess, вы обсуждаете обмен, происходящий через Интернет. Но что если вы просто желаете зашифровать обмен, который происходит между двумя серверами внутри одной сетевой среды? Или обмен, который протекает между компьютерами клиентов в офисе с их локальными серверами, также расположенными в самом офисе? Именно здесь вам пригодяться знания о параметрах политики IPsec, поскольку мы можем указать что мы желаем чтобы перемещающийся внутри нашей корпоративной сетевой среды обмен должен быть зашифрован при помощи IPsec. Для того чтобы это происходило, необходимо разместить верную политику.

Настройка IPsec

Существует два различных места, где могут настраиваться установки IPsec в среде Microsoft Windows. Как старые, так и новые системы могут снабжаться настройками IPsec через обычную оснастку Политики безопасности IPsec. Если вы запускаете все системы, которые являются более новыми, такие как Windows 7 и Server 2008 или выше, тогда вы можете иметь на службе в качестве альтернативы Межсетевой экран с Расширенной безопсностью Windows Defender для настройки ваших политик IPsec. WFAS является более гибким решением, но оно не всегда доступно в зависиомсти от состояния наследуемых систем в вашей среде.

Прежде всего давайте бросим взгляд на более старую политику консоли IPsec. Мы начнём отсюда, поскольку имеющиеся различные доступные варианты помогут вам построить для нас некий базовый уровень чтобы мы смогли сосредоточиться на том как взаимодействие IPsec осуществляется между двумя оконечными точками. Существуют три различные классификации политики IPsec, которые могут назначаться вашим машинам, которые мы перечисляем в этой консоли. Давайте портатим минутку для обяснения каждой из них, так как названия этих политик могут слегка запутвать. Понимание этих параметров поможет вам понять как работают настройки WFAS.

Политика сервера

Вероятно, политику сервера стоит переименовать в политику Запрашивающего (Requestor), поскольку она означает именно это. Когда некий компьютер или сервер делает какой- то сетевой запрос вовне к другому компьютеру или серверу, это запрос на установление некого сетевого подключения. Об этих запрашивающих компьютерах - которые инициируют данный обмен - мы и говорим как как о подлежащей приёму Политике сервера IPsec. Будучи применённой, эта Политика сервера сообает что данный компьютер или сервер запрашивает шифрование IPsec для данного сеанса взаимодействия между нашей инициирующей машиной и её удалённым компьютером. Если такой удалёный компьютер поддерживает IPsec, тогда создаётся необходимый туннель IPsec чтобы защищать весь обмен между данными двумя машинами. Однако, сама Политика сервера достаточно снисходительна хотя, и если ваш удалённый сервер не поддерживает IPsec, тогда данное соединений всё равно будет успешным, но останется нешифруемым.

Политика безопасного сервера

Основное отличие здесь состоит в том, что Политика безопасного сервера (Secure Server policy) для того чтобы соединение произошло, требует шифрования IPsec. Обычная Политика сервера, которую мы обсуждали ранее, будет выполнять шифрование IPsec когда оно возможно, а если оно не возможно, она будет продолжать свой поток обмена в незашифрованном виде. С другой стороны, Политика безопасного сервера выдаст отказ в установлении соединения совсем если между этими двумя машинами не возможно договориться об IPsec.

Политика клиента

Политику клиента следовало бы переименовать в политику Отклика (Response), так как именно она выступает другой стороной данного соединения. Эта Политика клиента не заботится о запросе некого подключения, она всего лишь ведает его получением. Когда некий компьютер делает какой- то запрос к серверу, а этот компютер имеет установленной Политику сервера или Политику безопасного сервера, а следовательно он запрашивает IPsec, тогда такому серверу потребуется назначенной ему Политику клиента чтобы принять и построить такой туннель IPsec. Данная Политика клиента отвечает за то чтобы разрешить чтобы в данном сеансе происходило шифрование.

Оснастка политики безопасности IPsec

Первоначальная консоль для манипуляции настройками IPsec доступна через MMC. Откройте его и добавьте соответствующую оснастку IP Security Policy Management. Примечательно, что когда выдобавляете эту оснастку, вы обратите внимание на то, что у вас имеется возможность просматривать либо саму локальную политику IPsec данной машины, в которой вы зарегистрированы в настоящий момент, или же вы можете открыть соответствующую политику IPsec для самого вашего домена.Если вы заинтересованы в настройке реализации IPsec по всему домену, это будет вашей зоной запуска для работы с такими настройками. Но для того чтобы просто немного заглянуть сюда вы можете выбрать свой Local computer чтобы рассмотреть её консоль:

Оказавшись внутри, вы можете наблюдать все имеющиеся политики IPsec, которые могут иметься установленными, либо вы можете начать создание своей собственной, воспользовавшись действием Create IP Security Policy..., доступным при правом клике по IP Security Policies. Сделав это мы запускаем некий мастер, который пройдёт по необходимым настройкам для вашей конкретной политики:

Применение вместо этого WFAS

Новой платформой, применяемой для установления правил подключения IPsec является Windows Defender Firewall with Advanced Security. Пройдём далее и откроем её, благо мы уже заем как это делать. оказавшись внутри, перейдём к разделу Connection Security Rules, который перечислен непосредственно за Inbound Rules и Outbound Rules. Connection Security Rules это то место, где вы определяете правила подключения IPsec. Если вы кликните по Connection Security Rules и выберете New Rule..., вы затем пройдётесь по мастеру, который аналогичен тому, в котором мы создавали правило межсетевого экрана:

Находясь внутри этого мастера для создания нового правила вы сможете обнаружить, что доступные вам возможности совершенно отличны от тех, которые были показаны нам при создании некого правила межсетевого экрана. Именно в этой платформе вы можете настраивать правила безопасности IPsec соединения, которые определяют как выглядят ваши туннели IPsec и для каких IP адресов машин они требуются быть доступными:

У нас нет здесь достаточного пространства чтобы описать все доступные в этом матере возможности, но я определённо рекомендую вам зацепиться за этот момент и сделать ещё один шаг в сторону добавления неких сведений из TechNet.

Если вы пользователь Azure Active Directory, вы уже имеете доступ к этой новой функции с названием Запрещённые пароли (banned passwords). Основная идея такова: Microsoft поддерживает глобальный пополняющийся перечень обычно плохих паролей (таких как слово paasword) и автоматически блокирует все варианты паролей, такие как P@ssword, Password123 и тому подобное. Все такие потенциальные пароли будут блокированы совместно если некий пользователь попробует создать один из них своим собственным паролем. У вас также имеется возможность добавлять ваши собственные индивидуальные запрещённые пароли внутри имеющегося интерфейса Azure Active Directory. После того как вы подняли Запрещёные пароли и работате в Azure, эта возможность может быть затем портирована также и в среду Active Directory на вашей площадке через реализацию службы посредника (прокси) защиты паролей Azure Active Directory. Такой интерфейс посредника между вашим Контроллером домена на площадке и вашим Azure Active Directory обеспечит соответствие определяемым Azure правилам алгоритмов Запрещёных паролей для тех пользователей, которые попытаются занять своё место в ваших локальных Контроллерах домена.

Чтобы применять данную технологию, естественно, вы обязаны применять Azure Active Directory, следовательно она доступна не всем. Однако, если вы получили и синхронизировали Azure Active Directory, тогда эта возможность даже имеет обратную портацию на более ранние Контроллеры домена на площадке. Эти серверы не должны быть старше Windows Server 2012.

Вот ссылка на дальнеюшую информацию относительно Запрещённых паролей.

По моему убеждению, одна из самых крутых функциональностей безопасности, пришедшая из Microsoft за последние несколько лет, это Advanced Threat Analytics (ATA, Расширенная аналитика угроз) и всё же я едва ли слышал чтобы кто- то говорил о ней. В любом случае, это не функциональность или функция встроенная в саму ОС Windows Server, но это локальное программное обеспечение, которое работает на базе Windows для создания неких удивительнейших функциональных возможностей. По сути, ATA отслеживает весь ваш обмен Active Directory и предупреждает вас об опасном или необычном поведении в реальном масштабе времени сразу же при его возникновении.

Основная идея ATA достаточно банальна для понимания и имеет столько здравого смысла, что все мы удивлены почему на её создание потребовалось так много времени. Причина этого, тем не менее, состоит в том, что под капотом тех обработки и обучения, которые выполняет ATA являются очень современными. Да, я сказал обучение. Именно это и составляет самую крутую часть ATA. Вы настраиваете свою сетевую среду с тем, чтобы весь тот обмен, который протекает через ваши Контроллеры домена, также приземлялся и в вашей системе ATA. Самым безопасным способом осуществления этого является сетевой уровень, на котором устанавливается зеркалирование порта с тем, чтобы все проходящие ваш Контроллер домена пакеты также совершали свой путь и в ATA, однако на некотором уровне, который не виден атакующему. Таким образом, даже если некто гнусный даже находится внутри вашей сетевой среды и пребывает в поиске некого вида защит работающих против него, ATA остаётся невидимой для его назойливых глаз. Тем не менее, зеркалирование порта для подобного обмена это нечто, что не могут сделать небольшие компании, или это будет слишком сложным для начальной настройки, а потому имеется и второй вариант установки некого агента ATA с малым весом прямо в сами Контроллеры домена. Такой агент затем отправляет всю необходимую информацию в имеющиеся серверы обработки ATA.

В любом случае, такие серверы обработки ATA получают все подобные данные и начинаю выискивать шаблоны. Если Betty применяет компьютер с названием BETTY-PC и планшет с названием BETTY-TABLET, ATA обнаружит такой шаблон и свяжет её уётную запись пользователя с такими устройствами. Он также будет отслеживать её обычные шаблоны обмена. Betty обычно регистрируется около 8 часов утра и ей обмен обычно прекращается где- то около 5 вечера. Она обычно осуществляет доступ к нескольким файловым серверам и серверу SharePoint. После недели или около того сбора и отслеживания данных, ATA имеет достаточно хорошее представление о стандартном образе действий Betty.

Сегодня ночью нечто произошло. ATA отследил массу отказов в приёме пароля для учётной записи Betty. Само по себе это не может быть чем- то волнующим, однако вдруг Betty регистрируется в системе терминального сервера, к которому она обычно не осуществляет доступа. Оттуда её учётные данные применяются для доступа к контроллеру домена. О, это очевидно выглядит как атака на меня. Что мы знаем при помощи встроенных в Active Directory инструментов, которыми мы располагаем сейчас? На самом деле не важно. Мы можем обнаружить отказы для своего пароля, когда мы копаемся в журналах событий, а на основании этого мы можем просмотреть журналы событий в прочих серверах чтобы выяснить к чему именно обращалась данная учётная запись, но у нас на самом деле не было никаких оснований подозревать что- нибудь. Это может стать большим проломом, а мы можем никогда его и не увидеть. К счастью ATA информирован лучше.

Интерфейс управления для ATA похож на канал социальных сетей, обновляемый практически в режиме реального времени. Во время событий, которые я только что изложил, если бы мы смотрели новостную ленту ATA, мы бы обнаружили происходящими все те моменты, на которые я указывал, как они происходили и сразу станет очевидны, что некто скомпрометировал учётную запись Betty для получения доступа к Контроллеру домена. Никогда ещё не имелось технологии, которая столь интенсивно отслеживала бы обмен Active Directory и, конечно же, не было ничего такого, что могло бы изучать такие схемы поведения м отклонений в поведении. Это на самом деле поразительная технология и я говорю это, потому что знаю тех парней, которые её создавали. Но раз так, я могу сказать вам что они великолепны, что уже очевидно, поскольку Microsoft подхватил их.

На данный момент ATA всё ещё достаточно нова чтобы большая часть сообщества ИТ взаимодействовала с нею и я вам настоятельно рекомендую изменить это. Это может спасти вашу задницу в один из дней. Ниже пригодится некий снимок экрана имеющегося веб интерфейса ATA, так что вы имеете возможность получать визуализацию в стиле канала социальных сетей. Этот снимок был взят из демонстрации Microsoft, когда они целенаправленно украли квитанцию (ticket) Kerberos некого пользователя, а эатем применили её в другом компьютере, чтобы получить доступ к неким конфиденциальным файлам, к которым имеет возможность доступа только Demi Albuz. Хотя ATA и не прекратила эти действия, она немедленно - я имею в виду в течении нескольких секунд - выдала предупреждение внутри данного канала чтобы показать данную Pass-the-Ticket Attack (Атаку передачи квитанции):

Вот другой пример, в котором пользователь Almeta Whitfield внезапно получила доступ к 16 компьютерам, которые никогда не применяла, с выставлением другого большого красного флага о том что что- то произошло в её учётной записи пользователя:

Для получения дополнительных подробностей как начать применять ATA, обратитесь к этой ссылке.

Порой нам требуется полагаться только на самих себя и нет необходимости в производимых вашей ОС функциональностях для безопасности наших систем. Имеется множество подходов на основе здравого смысла к искусству администрирования, но редко применяемых на местах. Ниже приводится ряд советов и уловок, которые я освоил за эти годы и которые помог реализовывать компаниям. Надеюсь, что вы, как читатель, моежет много чего добавить к этому списку, из того что отработано вами, но если нет ничего иного, данный раздел имеет целью подтолкнуть ваши мысли к поиску творческих вариантов при помощи которых вы сможете ограничивать административные возможноти и уязвимости в вашей сетевой среде.

Все ли ваши ИТ- специалисты имеют права администратора домена в день их приема на работу? Есть ли у кого-нибудь из ваших ИТ- специалистов доступ к встроенному паролю учётной записи администратора домена? У вас есть постоянные пользователи, чьи учётные записи имеют права администратора на своих компьютерах? Вы знаете, куда я иду с этим - всё это ужасные идеи!

К сожалению, это всё было существующим положением дел на протяжении многих лет почти в каждой сети, и эта тенденция сохраняется и сегодня. Я до сих пор постоянно наблюдаю, как инженеры используют учетную запись администратора домена для многих задач при настройке новых серверов. Это означает, что они не только имеют доступ к потенциально самой важной учетной записи в вашей сети и применяют её для повседневных задач, но также означает что всё настраиваемое с этой учётной записью пользователя, не имеет подотчётности. Что я имею под этим в виду? Когда я настраиваю новый сервер или изменяю существующий сервер, применяя учётную запись общего администратора, и в конечном итоге я вызываю какую-то большую проблему, поскольку никто не может доказать, что именно я это и сделал. Использование обобщенных учётных записей пользователей - верный способ снять ответственность в случае, если что-то идет не так. Я не пытаюсь иметь в виду что вы всегда в поиске того, кто это сделал? Но если я что- то испорчу в сервере приложений, которым обычно не занимаюсь, было бы неплохо, если бы те ребята, которые пытаются это исправить легко могли понять что это был я, и пришли бы спросить что же я натворил, чтобы они могли вернуть это. Есть много причин, по которым использование встроенной учётной записи администратора должно быть запрещено всеми нами.

Что касается стороны клиентов, ваши пользователи на самом деле нуждаются в административных правах на своих компьютерах. Правда? Я уверен что вы можете найти способ обойти это. Понижение прав обычных пользователей до пользователей или опытных пользователей в их собственных системах может оказывать огромное влияние на безопасность таких компьютеров. Вирусам гораздо сложнее установить самих себя если пользователю требуется проходить запрос на права администратора прежде чем он сможит продолжить установку. Это также поддерживает все ваши машины в более согласованном шаблоне поведения без новых и неизвестных приложений и настроек, вводимых этим пользователем.

Эта идея идёт прицепом к предыдущей, причём я даже начал применять её на всех домашних компьютерах, которые я устанавливал для друзей и членов семьи. На самом деле это сводится к следующему: применять две различные учётные записи пользователей. Одну с административным доступом, а другую без. Когда вы входите в систему для выполнения повседневных задач и дел, убедитесь что вы входите в систему с обыкновенной учётной записью пользователя, которая не имеет прав администратора, причём не на локальном компьютере, ни в домене. Тем самым, если вы попробуете что- то установить или нечто устанавливается самостоятельно, вам будет предложен блок UAC (User Account Control, Контроля учётных записей), прося вас ввести имя пользователя с правами администратора и его пароль прежде чем позволить такому установщику выполнить что либо. Я могу сообщить вам, что это работает, так как я позволял некоторым вирусам на моём собственном компьютере устанавливать себя, когда просматривал Интернет, чтобы провести исследование для того или иного проекта. Если я получаю приглашение UAC на ввод пароля администратора, я не щёлкаю по некому файлу установщика, потому что я знаю что мне это не нужно делать. Всё что мне требуется сделать, так это нажать No и этот установщик не заполучит мой компьютер. С другой стороны, если это именно то что я намерен установить, то ввод пароля моей учётной записи с правами администратора будет наименьшим неудобством и это позволит продолжать работу.

Сопровождение двух раздельных учётных записей позволит вам работать своим собственным способом с большинством повседневных задач и в то же самое время даже не задумываться о том что у вас нет прав непреднамеренно сделать нечто плохое для своей системы. Такой стиль мыслей также ограничивает тот объём действий, которые должна выполнять в компьютере или сетевой среде учётная запись с правами администратора, а также упрощает отслеживание этих учётных записей при внесении администраторами изменений в имеющейся среде.

Если вы желаете развить обсуждаемую идею раздельных учётных записей ещё дальше, вы можете сделать свою практику работы с компьютерами ещё более безопасной, применяя всеми вместе некий обособленный компьютер для выполнения задач административного уровня. Один компьютер для обычных задач опытного пользователя, а другой компьютер для административных задач. Это несомненно поможет вам сохранять вашу систему администрирования в безопасноти, а также те удалённые системы, к которым она должна выполнять доступ. И хотя иметь на своём рабочем столе два компьютера кажется обременительным, помните, что для большинства SKU в Windows 10 мы способны запускать Hyper-V прямо в своих настольных компьютерах. Я на самом деле поступаю так со своим собственным компьютером. У меня имеется компьютер под управлением Windows 10, а затем, уже внутри него я запускаю через Hyper-V я запускаю виртуальную машину для выполнения всех административных задач на чувствительных серверах. Тем самым компромисс с моей повседневной ОС не требует компромисса со всей моей средой.

Если вы решите разделить административный доступ на уровне учётной записи пользователя или на уровне компьютера, запомните такое простое правило: никогда не выполняйте задачи администрирования Active Directory с того же самого место, с которого вы просматриваете Facebook. Я полагаю, что это достаточно хорошо подводит общий итог.

Похож, и ежу понятно что все люди делают это. За работой в серверах мы проводим целые дни, причём очень часто приходится обращаться к веб- браузеру чтобы что- то проверять. Поскольку в серверах Windows имеется Internet Explorer, порой проще и быстрее проверить всё что нам требуется с самой консоли сервера, нежели возвращаться к обратно к своему рабочему столу. Удерживайтесь от соблазна! Очень легко наткнуться на плохие вещи в Интернете, в особенности работая с сервера, поскольку если какие- то машины в нашей сетевой среде и работают без антивирусной защиты, то скорее всего это происходит именно на стороне серверов. то же самое и относительно интернет- фильтрации. мы всегда следим за тем, чтобы обмен клиента проходил через наш корпоративный сервер посредника (прокси, если он у нас имеется), но нас не всегда беспокоит перемещается ли обмен нашего сервера тем же образом.

Не делайте этого даже для доверенных вебсайтов. Атака с человеком посредине или некая компрометация такого вебсайта самого по себе запросто способны разрушить ваш сервер. Намного проще заново отстроить клиента, нежели сделать это с сервером.

Сама фраза Role-Based Access Control (RBAC, Управление доступом на основе ролей) не ограничивается исключительно средами Microsoft. Это такде не какая- то определённая технология, которая может применяться внутри Windows Server 2019, а вместо того представляет некую идеологию, которая целиком посвящена разделению заданий для ролей и обязанностей. Когда мы рассматриваем разделение ролей своих сотрудников с точки зрения ИТ, мы обычно мыслим в терминах групп Active Directory. Хотя добавление учётной записи пользователя в группы и разрешает множество проблем относительно расщепления уровней полномочий и доступа, при таком образе мышления может быть ослажнён рост, и в конечном итоге группы AD предоставляют администраторам доступ к самим группам. Технологии RBAC делят роли на ином уровне, заботясь не только о полномочиях. RBAC больше сосредотачивается на описании заданий сотрудников, нежели на ограничениях доступа. Существует множество различных технологий, которые получают преимущества от интегрированного в них инструментария RBAC, что делает их чрезвычайно распространёнными по всей вашей организации и не ограничивает работу границами отдельного домена или леса.

Великолепным примером технологии RBAC, который содержится в Windows Server 2019, является Just Enough Administration (JEA), являющийся частью PowerShell. JEA предоставляет вам некий способ выделения особого привилегированного доступа для тех людей, причём без предоставления им прав администратора, которые требовались ранее для выполнения тех же самых обязанностей. Такая потребность в добавлении кого- то в имеющуюся группу администраторов в неком сервере с тем, чтобы он мог выполнять свои задания всё ещё достаточно распространена, однако JEA является самым первым шагом прочь от такой необходимости.

При нашем старом образе мыслей боло бы легко представлять себе что JEA делает нечто вроде предоставления пользователям доступа с правами администратора к самой ОС, однако он даже обладает большей мощностью. Построение JEA таково, что вы можете разрешать пользователям иметь доступ для запуска только определённых команд и cmdlet на административном уровне, при этом оставляя в темноте прочие команды, к которым не требуется доступ.

Фактически, если пользователь работает в рамках контекста JEA PowerShell, и он пытается вызвать некий cmdlet, который не входит в часть допустимых cmdlet, PowerShell притворяется что он даже и не распознаёт такой cmdlet. Он не сообщает извините, я не могу этого сделать - он игнорирует такую команду! Это несомненно позволяет удерживать посторонние пальцы от банки с печеньем, которую вы не желаете делить.

Давайте сделаем ещё один шаг вперёд. Возможно,вы являетесь администратором DNS и порой вам может потребоваться перезапускать службы DNS. Поскольку мы внедряем менталитет JEA/ RBAC,у вас не будет прав администратора в ОС данного сервера, но у вас будут права на уровне JEA в PowerShell чтобы вы имели возможность запускать инструменты, которые требуются для вашей работы. Перезапуск службы DNS требует доступ для применения cmdlet Restart-Service, так? Но разве это не означает,что я смог бы перезапустить в этом сервере любую службу и потенциально мог бы делать все виды тех действий, которые мне не требуются? JEA даже обладает достаточной мощность чтобы справиться и с таким сценарием. При настройке уровня доступа, который должен получить такой пользователь, вы даже имеете возможность погружаться в отдельные cmdleet и разделять полномочия. В нашем примере вы могли бы предоставить такому пользователю доступ к cmdlet Restart-Service, но при этом разрешить перезапуск лишь определённых служб, например тех, которые относятся к DNS. Если этот пользователь попытается Restart-Service для WINrm, он получит отказ.

В этом году для многих ИТ- руководителей самым первым пунктом повестки является безопасность. Безопасность ваших машин клиентов, безопасность ваших сетевых сред, безопасность ваших облачных ресурсов, а самое главное, безопасность ваших данных. Не существует единого решения для защиты вашей инфраструктуры, ибо для этого имеется множество движущихся частей и множество различных технологий, совместно работающих для обеспечения безопасности ваших ресурсов.Целью данной главы состояла в том, чтобы предоставить примеры мер безопасности и технологий, которые можно применять в любой среде, в также вкратце оценить важность безпасности в современном мире ИТ. Обеспокоенность относительно конфиденциальности и безопасности необходимо обсуждать для всякого внедряемого нами технологического решения. Очень часто я обнаруживаю внедряемые в организациях новые приложения вне зависимости от того насколько безопасна такая платформа. Следует удалять или изменять приложения, которые передают или хранят данные в незашифрованном виде. Защита информации имеет важне значение для долговечности важего бизнеса.

Мы не можем завершить обсуждение безопасности в Windows Server 2019 без обсуждения варианта установки ОС по умолчанию, который мы до сих пор игнорировали в этой книге. Переверните страницу и давайте окунёмся в Server Core, нашу выхолощенную и менее уязвимую версию Windows Server.