AuthIP – Усовершенствование возможностей и функционала IPsec

Я помню, когда был выпущен Windows 2000 Server. Один из моментов, которые я ждал в нем, была IPsec. Благодаря тому, что поддержка IPsec была внедрена непосредственно в ОС, я мог защищать подключения между всеми компьютерами в своей сети. Мне бы больше не пришлось беспокоиться о том, что кто-то с анализаторами пакетов будет воровать пароли, имена пользователей и информацию о приложениях во время ее передачи по сети. Хотя функция IPsec могла сделать это возможным, она оказалась слишком сложной, слишком ограниченной и, честно говоря, слишком большой головной болью при настройке.

В Windows Server 2003 все несколько упростилось. В то время как Windows 2000 Server требовал запуска мастера IPsec на каждой машине, на которой нужно было включить политику IPsec, Windows Server 2003 позволял использовать групповую политику (Group Policy) в форме оснастки IPsec Group Policy для настройки политики IPsec на сервере Windows Server 2003 и машинах Windows XP в сети. С помощью групповой политики, включенной посредством Active Directory, можно было масштабировать политики IPsec. Однако та сложность, которая присутствовала в настройках мастера IPsec Configuration Wizard в Windows Server 2000 IPsec, осталась и в ОС Windows Server 2003 и Windows XP.

IPsec является частью Windows TCP/IP стека, при этом IPsec драйвер является драйвером очень низкого уровня. Политика IPsec, как предполагает ее название, применяется на сетевом уровне, прежде чем данные прикладного уровня могут приниматься системой. Когда вы настраиваете IPsec политику, вы на самом деле настраиваете IPsec правила, которые определяют:

• для какого трафика будет включена защита IPsec,
• разрешать или блокировать трафик,
• если трафик разрешен, следует ли требовать аутентификации или шифрования, и
• если требуется аутентификация и/или шифрование, какой тип аутентификации и/или шифрования следует использовать.

Здесь также есть другие параметры, такие как, например, тот, что определяет адрес или сеть источника и цели, к которым будет применяться политика.

Хотя я считал IPsec действительно отличной функцией и причиной, по которой следует предвкушать выход Windows 2000 Server, мое мнение не было разделено среди сообщества ИТ специалистов по указанным выше причинам. Однако было нечто, что немного встряхнуло ситуацию с IPsec в 2005, когда компания Microsoft начала публиковать информацию о технологии изоляции серверов и доменов (Server and Domain Isolation – SDI). Суть SDI заключалась в том, что можно было логически разбивать сеть на сегменты для защиты активов доменов от узлов с меньшим уровнем доверия. С выходом SDI обещалась возможность логического сегментирования ценных активов от активов, представляющих меньшую ценность (или активов с высоким уровнем доверия от активов с меньшим уровнем) вместо физической изоляции этих зон безопасности друг от друга. Возможность логического сегментирования с помощью IPsec в качестве границы безопасности казалась очень привлекательной и, возможно, могла позволить значительно сэкономить расходы.

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

Все знают, что компании Microsoft требуется несколько попыток, чтобы все исправить. Они не хотели отказываться от мечты о том, что IPsec может предоставить ИТ администраторам, поэтому они рассмотрели проблему того, как IPsec реализовывалась и решили исправить некоторые из этих проблем. Это привело к развитию AuthIP ‘ реализации IPsec, которая имеет улучшения в протоколе Internet Key Exchange (IKE), исправившие одни из самых важных ограничений в предыдущих версиях IPsec. AuthIP была впервые представлена в Vista и Windows Server 2008, и также включена в Windows 7 и Windows Server 2008 R2.

AuthIP улучшения для IPsec

AuthIP действительно задает расширения для протокола IKE, которые включают новые флаги и методы обмена данными для повышения удобства IPsec. AuthIP может использоваться с компьютерами под управлением Vista, Windows 7, Windows Server 2008 и Windows Server 2008 R2. И если таким компьютерам необходима IPsec для взаимодействия с компьютерами более низкого уровня, которые не поддерживают AuthIP, они могут обращаться к использованию IKE.

AuthIP позволяет использовать следующие функции, которые не были доступны в предыдущих версиях IKE:

• Аутентификация пользователей новыми способами
• Аутентификация с помощью разнообразных протоколов и способов
• Использование более эффективного взаимодействия протоколов
• Использование нескольких наборов учетных данных для проверки подлинности

Аутентификация пользователей новыми способами

Если вы помните, как аутентификация работала с предыдущими версиями IPsec, вы знаете, что проверка подлинности основывалась на учетных данных компьютера. У вас было два варианта на выбор для проверки подлинности компьютера: аутентификация компьютера с помощью сертификата или проверка подлинности компьютера с помощью Kerberos. Да, вы могли использовать общий ключ, но эта опция стоит довольно низко в цепи питания, когда речь идет о масштабности и безопасности. Если вам нужно было контролировать то, какие пользователи имели доступ к серверному приложению, вам нужно было работать с аутентификацией пользователей на прикладном уровне ‘ что означало, что не доверенные пользователи с доверенных машин могли выполнять атаки на сетевом уровне на сервер, на котором располагалось интересующее приложение.

С AuthIP вы контролируете доступ на основе учетной записи компьютера, учетной записи пользователя или на основе обеих учетных записей. Это переводит аутентификацию на более низкий уровень в стеке TCP/IP, поэтому вам больше не нужно полагаться на приложение для аутентификации пользователя. С помощью AuthIP вы можете выполнять проверку пользователя на сетевом уровне и защищать приложение от атак сетевого уровня, которые происходят до аутентификации прикладного уровня.

Можно использовать следующие способы проверки подлинности пользователей с помощью AuthIP:

• Сертификат здоровья компьютера, который используется защитой сетевого доступа (Network Access Protection – NAP)
• Сертификат пользователя (клиентский сертификат в хранилище сертификатов пользователя)
• NTLMv2 для учетной записи пользователя, вошедшего в систему
• Kerberos для учетной записи пользователя, вошедшего в систему

Аутентификация с помощью различных методов

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

Возьмем к примеру ситуацию, в которой нам нужно использовать IPsec для защиты коммуникаций между сервером в демилитаризованной зоне (DMZ) и сервером, расположенным в центре данных. Сервер в зоне DMZ находится в лесу, в котором используется одностороннее отношение доверия с лесом сервера центра данных, поэтому DMZ лес доверяет лесу центра данных, но лес центра данных не доверяет лесу DMZ зоны. Это позволяет пользователям в центре данных подключаться к DMZ серверу с помощью учетных данных пользователя или компьютера, но не позволяет пользователям в DMZ лесу подключаться к ресурсам центра данных с помощью учетных данных пользователя или компьютера.

Однако, у вас установлены сертификаты на обоих серверах, и оба сервера доверяют сертификатам друг друга. Благодаря AuthIP у вас теперь есть поддержка сценариев, где проходящие проверку подлинности участники используют разные методы аутентификации. В этом сценарии, когда сервер центра данных аутентифицирует свое IPsec подключение к DMZ серверу, он будет использовать Kerberos аутентификацию учетной записи компьютера или пользователя. Когда DMZ сервер аутентифицирует подключение к серверу центра данных, он будет использовать аутентификацию на основе сертификата пользователя или компьютера. Несмотря на то, что каждый участник IPsec использует разные методы аутентификации, они все равно могут создавать IPsec подключение, так как целью здесь является успешная аутентификация, а не успешная аутентификация с использованием одинакового протокола проверки подлинности.

Более эффективное взаимодействие

Как уже говорилось выше, в предыдущих версиях IPsec (IKE) можно было проходить проверку подлинности на основе учетной записи компьютера с помощью сертификата компьютера или учетной записи компьютера с использованием Kerberos. Однако если предпочитаемый метод аутентификации давал сбой, весь процесс IPsec взаимодействия становился невозможным.

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

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

Использование нескольких наборов учетных данных для аутентификации

Как вы, возможно, поняли, читая различные новые сценарии, поддерживаемые AuthIP, теперь можно использовать несколько наборов учетных данных для проверки подлинности участников IPsec. Можно аутентифицировать IPsec участников с помощью учетных данных компьютера, пользователя или обоих. Если вы знаете о DirectAccess, новой технологии удаленного доступа в Windows 7 Enterprise/Ultimate версиях и Windows Server 2008 R2, вы, вероятно, знаете, что туннель инфраструктуры использует сертификат компьютера и NTLMv2 аутентификацию на основе учетной записи компьютера, в то время как туннель интрасети использует Kerberos аутентификацию на основе сертификата компьютера и учетной записи пользователя. Добавление пользовательских учетных данных в смесь аутентификации позволяет вам защищать свои серверы от злоумышленных пользователей, которые могут использовать доверенные машины.

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

Поддержка контроллеров домена теперь делает изоляцию серверов и доменов возможной для всех нас

Одной из причин, по которым IPsec не так широко использовалась в прошлом, является проблема с контроллерами домена. Если вы хотели использовать IPsec в своей сети с предыдущими версиями IPsec, вам нужно было исключать контроллеры домена из IPsec политик. Причина тому заключалась в том, что для аутентификации компьютера нужен был доступ к DC (контроллеру домена), и если у вас не было доступа к DC, невозможно было аутентифицироваться ‘ поэтому вы сталкивались с классическим парадоксом ‘курицы и яйца’.

Windows Server 2008 и выше, а также Vista и выше решили эту проблему путем обеспечения следующих возможностей:

• Больше не нужно создавать исключения для контроллеров домена, поскольку можно настроить IPsec так, чтобы она решала, когда использовать IPsec при взаимодействии с контроллерами домена.
• У компьютеров под управлением Vista и выше, а также Windows Server 2008 и выше могут запрашиваться учетные данные при подключении к контроллеру домена ‘ это решает старую проблему ‘присоединения к домену’, при которой нужно было исключать компьютер из политики IPsec защиты, если вы хотели присоединить его к домену. Путем предоставления возможности запроса учетных данных компьютеры, не являющиеся членами домена, могут запрашивать учетные данные для создания IPsec сеанса.
• Для клиентов более низких уровней можно легко настраивать политики (без необходимости создания правил исключения), которые запрашивают IPsec защиту, но не требуют ее.

Эти усовершенствования в интрадоменных IPsec взаимодействиях позволяют сделать IPsec развертывание более осуществимым в сегодняшних сетях.

Заключение

IPsec была впервые представлена в Windows 2000 Server. Хотя это была многообещающая технология, был ряд причин, по которым она не прижилась в корпоративных сетях. С выходом Vista и Windows Server 2008 (а затем и Windows 7 и Windows Server 2008 R2) появились службы AuthIP, которые значительно повышают гибкость и управляемость IPsec. Теперь есть мощные механизмы аутентификации, которые просты в настройке с помощью инструментов управления на основе групповой политики, позволяющих создавать надежные и мощные политики IPsec без лишней сложности, которая препятствовала использованию предыдущих версий IPsec. Сочетание новых опций проверки подлинности пользователя, возможности использования нескольких учетных данных, более гибкого взаимодействия аутентификации и возможности каждой стороны использовать разные способы аутентификации, делает AuthIP тем лекарством, которое требовалось IPsec для прорыва и использования по полной программе.