книги хакеры / журнал хакер / 140_Optimized

позволяющие определить, что нужно предпринять для гарантированной защиты кода.

Для защиты управляемого кода используются две технологии:

• защита на основе признаков (evidence-based security)

позволяет определять, какие разрешения следует предоставлять коду;

• защита по правам доступа кода (code access security) позволяет проверять, весь ли код в стеке имеет необходимые разрешения на выполнение каких-либо действий. Эти две технологии связаны между собой концепцией разрешений.

По признакам и политике безопасности, устанавливаемой администратором, система защиты определяет, какие разрешения могут быть выданы коду. Программа сама может запрашивать какое-либо разрешение, влияя на состав окончательного набора разрешений. Запрос разрешения выражается в виде объявления на уровне сборки с синтаксисом пользовательских (custom) атрибутов. Однако, в любом случае, код не может получить более широкие или ограниченные разрешения, чем это предписано политикой безопасности. Разрешение предоставляется только раз и определяет права всего кода в сборке. Для просмотра и изменения политики безопасности используется инструмент настройки .NET Framework (Mscorcfg.msc).

ПЛАНИРУЕМ БОЕВЫЕ ДЕЙСТВИЯ

Есть такая японская пословица: «Выходи из дома так, как будто он окружен тысячей врагов». Понятно, что во времена феодальной Японии, когда туда-сюда бегали самураи, воевали между собой и искали других приключений,

dvd

Надискетынайдешь некоторыепрограммныепримеры, реализующиенаC# принципы, описанныевстатье.

HTTP://WWW

links

• blogs.msdn.com, www.eggheadcafe. com, bytes.com — на этихсайтахтысможешьнайтироссыпи интереснойинформацииотехнологиях

.NET ипополярных языках

CODING

Утилитаграфической настройки прав доступак коду GuiCaspol

•FileDialogPermission — доступ только к файлам, специально указанным пользователем;

•Isolated StorageFilePermission — постоянное хранилище (с меньши-

ми ограничениями);

•UlPermission — код может свободно использовать собственные окна верхнего уровня.

•Зона ограниченных сайтов, код из которой выполняется только с минимальными разрешениями.

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

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

ЗАЩИТА ДОСТУПА К МЕТОДАМ

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

Иногда приходится ограничивать доступ к методам, которые не предназначены для открытого использования, но все равно должны быть объявлены как открытые. Например, у тебя есть некий интерфейс, вызываемый вашими же DLL, и поэтому он должен быть открытым, но ты не хочешь, чтобы этот интерфейс был общедоступным, так как нежелательно, чтобы клиенты могли с ним работать, или чтобы злонамеренный код воспользовался им как точкой входа в твой компонент. Еще одна типичная причина ограничения доступа к методу, который не предназначен для общего использования (но, тем не менее, должен быть открытым) — стремление избежать документирования и поддержки интерфейса, применяемого исключительно на внутреннем уровне. Поэтому вот тебе несколько советов, как можно ограничить доступ к методам в управляемом коде:

•Ограничь область доступности классом, сборкой или производными классами (если им можно доверять). Это простейший способ ограничения доступа к методу. Замечу, что вообще-то производные классы могут быть менее доверяемыми, чем класс-предок, но в некоторых случаях они используют ту же идентификацию, что и надкласс. В частности, ключевое слово protected не подразумевает доверия, и его необязательно нужно использовать в контексте защиты.

•Разрешай вызов метода только вызывающим с определенной идентификацией (обладающим заданными вами признаками).

•Разрешай вызов метода только тем, у кого есть требуемые разрешения.

Аналогичным образом декларативная защита позволяет контролировать наследование классов. С помощью InheritanceDemand можно потребовать наличия определенной идентификации или разрешения от:

•всех производных классов;

•производных классов, переопределяющих те или иные методы.

НЕ ВЛЕЗАЙ — УБЬЕТ!

Какие разрешения несут в себе потенциальную опасность?

Для выполнения некоторых защищенных операций .NET Framework предоставляет разрешения, потенциально позволяющие обойти систему защиты. Эти опасные разрешения следует предоставлять только коду, заслуживающему доверия, и только при абсолютной необходимости. Обычно, если злонамеренный код получает такие разрешения, то защититься нельзя. К опасным разрешениям относятся:

[Security Permission]:

•Unmanaged Code — позволяет управляемому коду вызывать неуправляемый код, что зачастую весьма опасно;

•Skip Verification — код может делать что угодно без всякой верификации;

•ControlEvidence — управление признаками позволяет обмануть систему защиты;

•ControlPolicy — возможность изменять политику безопасности позволяет отключить защиту;

•SerializationFormatter — за счет сериализации можно обойти управление доступом;

•ControlPrincipal — возможность указывать текущего пользователя позволяет обходить защиту на основе ролей;

•ControlThread — возможность манипуляций с потоками опасна, так как с ними связано состояние защиты;

[ReflectionPermission]:

•MemberAccess — позволяет отключать механизм управления доступом (становится возможным использование закрытых членов).

ЗАЩИЩАЕМ ДОСТУП К МЕТОДУ ИЛИ КЛАССУ

Следующий пример показывает, как обезопасить открытый метод, ограничив доступ к нему.

1. Команда sn -k создает пару из закрытого и открытого ключа. Закрытая часть нужна, чтобы подписать код строгим именем (strong name), и хранится в безопасном месте издателем кода. Если она станет известной, указать твою подпись в своем коде сможет кто угодно.

sn -k keypair.dat

csc/r:App1.dll /a. keyfile: keypair.dat App1.cs sn -p keypair.dat public.dat

sn -tp public.dat >publichex.txt

[StrongNameldentityPermissionAttribute ( SecurityAction

. LinkDemand , PublicKey="...hex...",Name="App1", Version="0. 0.0.0")]

public class MyClass

2.Команда esc компилирует и подписывает Appl, предоставляя ему доступ к защищенному методу.

3.Следующие две команды sn извлекают из пары открытый ключ и преобразуют его в шестнадцатеричную форму.

4.Во второй половине показанного исходного кода содержится фрагмент защищаемого метода. Пользовательский атрибут (custom attribute) определяет строгое имя и в шестнадцатеричном формате вставляет открытый ключ, полученный командой sn, в атрибут PublicKey.

5. В период выполнения Appl имеет необходимую подпись со строгим именем и может использовать MyClass.

Вэтом примере для защиты API-элемента применяется атрибут

LinkDemand.

Впримере, показанном ниже, частично доверенному коду запрещается обращаться к классам и методам (а также к свойствам и событиям). Когда такие объявления применяются к классу, защищаются все методы, свойства и события этого класса. Однако декларативная защита не влияет на доступ к полям. Кроме того, учти, что требования

ксвязи (link demands) защищают только от непосредственно вызывающего кода — возможность атак с подменой сохраняется.

[System.Security.Permissions.

PermissionSetAttribute(System.Security.

Permissions.SecurityAction.InheritanceDemand,

Name="FullTrust")]

[System.Security.Permissions.PermissionSetAttribute

(System.Security.Permissions.SecurityAction.

LinkDemand,

Name="FullTrust")]

public class YourClass{...}

ПРИЕМЫ БЕЗОПАСНОГО КОДИНГА

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

[assemblyiFilelOPermissionAttribute

(SecurityAction.RequestMinimum,

Wrlte="C:\\test.tmp")]

[assembly:ÐårmissionSet (SecurityAction.RequestOptional. Unrestricted=false)]

... SecurityAction.RequestRefused ...

В этом примере системе сообщается, что код не должен запускаться, пока не получит разрешение на запись в C:\test.tmp. Если одна из политик безопасности не предоставляет такое разрешение, генерируется исключение PolicyException, и код не запускается. Ты должен убедиться в том, что коду выдается нужное разрешение, и тогда тебе не придется беспокоиться об ошибках из-за нехватки разрешений. Кроме того, здесь система уведомляется о том, что дополнительные разрешения нежелательны. Иначе код получит все разрешения, предусмотренные политикой безопасности. Лишние разрешения не принесут вреда, но, если в системе безопасности есть какая-то ошибка, уменьшение числа разрешений, выдаваемых коду, может прикрыть брешь в защите. Таким образом, если код обладает разрешениями, которые ему не нужны, возможны проблемы с безопас-

ностью. Еще один способ ограничить количество привилегий, предоставляемых коду — явно перечислить разрешения, от которых следует отказаться. Отказ от разрешений осуществляется объявлением необязательности разрешений и исключением конкретных разрешений из запроса.

ЗАКЛЮЧЕНИЕ

Уфф! На тему обеспечения безопасности твоего кода можно говорить бесконечно. В рамках этой статьи я постарался упомянуть только самое важное и, на мой взгляд, интересное. Иными словами, то, что должно помочь тебе сделать свои приложения непробиваемыми. В общем, да пребудет с тобой Сила!z

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

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

Итак, креализациипользовательскихверсийоператоровnew иdelete C++ предъявляетопределенныетребования. Одноизэтихтребований мырассмотреливпрошломномере— этофункция-обработчикnew.

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

Соглашения при написании оператора new

Первымделомпользовательскийnew долженвозвращатьправильноезначение. Вслучаеуспешноговыделенияпамятиоператордолженвернутьуказательнанее. Еслижечто-топошлонетак, следует возбудитьисключениетипаbad_alloc.

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

нулябайтпамяти. Какнистранноэтозвучит, ностандартC++ требуетв этомслучаекорректнойработыоператора. Такоеповедениеупрощает реализациюнекоторыхвещейвдругихместахязыка. Принимаяво вниманиевсеэто, можнопопробоватьнакидатьпсевдокодпользовательскогоnew:

Псевдокодпользовательскойреализацииоператораnew

void *operator new(std::size_t size) throw(std::bad_alloc)

{

using namespace std;

//обработать запрос на 0 байтов,

//считая, что нужно выделить 1 байт if (size == 0)

size = 1;

while(true)

{

// попытка выделить size байтов;

if (выделить удалось)

return (указатель на память);

//выделить память не удалось

//проверить, установлена ли функция-обработчик new_handler globalHandler = set_new_handler(0); set_new_handler(globalHandler);

if (globalHandler) (*globalHandler) ();

else

throw std::bad_alloc();

}

}

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

Такжесомнительнойможетпоказатьсяустановкауказателянаобработчикnew внулевоезначениеспоследующимеговосстановлением. Ксожалению, унаснетдругогоспособаполучитьадрестекущей функции-обработчика. Намнужнопроверитьэтотадрес, и, еслион нулевой, возбудитьисключениетипаbad_alloc.

Ещеразповторюсь, чтооператорnew вслучаепроблемсвыделением памятивбесконечномциклевызываетфункцию-обработчик. Очень важно, чтобыкодэтойфункциикорректноразрешалпроблему: сделал доступнойпамятибольше, возбудилисключениетипа, производного отbad_alloc, установилдругойобработчик, убралтекущийобработчик илиневозвращалуправлениевовсе. Впротивномслучаепрограмма, вызвавшаянашуверсиюnew, зависнет.

Отдельноследуетрассмотретьслучай, когдаnew являетсяфункцией- членомкакого-либокласса. Обычнопользовательскиеверсии операторовработыспамятьюпишутсядляболееоптимизированного распределенияпамяти. Например, new дляклассаBase заточенпод выделениепамятиобъемомsizeof(Base) — нибольше, нименьше. Ночтобудет, еслимысоздадимкласс, которыйнаследуетсяотBase? Вдочернемклассетакжебудетиспользоватьсяверсияоператора new, определенноговBase. Норазмернаследуемогокласса(назовем егоDerived), скореевсего, будетотличатьсяотразмерабазового: sizeof(Derived) != sizeof(Base). Из-заэтоговсяпользаотсобственной реализацииnew можетсойтинанет. Очем, кстати, многиезабываюти испытываютпотомнечеловеческиестрадания.

Проблеманаследованияоператораnew

class Base { public:

static void *operator new (std::size_t size) throw(std::bad_alloc);

...

};

// в подклассе не объявлен оператор new class Derived: public Base

{...};

//вызывается Base::operator new Derived *p = new Derived;

Решитьпроблемудостаточнопросто, ноделатьэтонадозаранее. Достаточновбазовомклассе, втелеоператораnew, выполнятьпроверкуразмеравыделяемойпамяти. Есликоличествозапрашиваемых байтовнесовпадаетсколичествомбайтоввобъектеклассаBase, то работуповыделениюпамятилучшевсегопередатьстандартнойреализацииnew. Ктомуже, такмысразужерешаемвопроссобработкой запросанавыделениенулябайтовпамяти— этимужебудетзаниматьсяштатнаяверсияоператора.

Решениепроблемынаследованияоператораnew

void *operator new (std::size_t size) throw(std::bad_alloc)

{

// если size неправильный, вызвать стандартный new

if(size != sizeof(Base)) return ::operator new(size);

// в противном случае обработать запрос

...

}

Науровнеклассаможнотакжеопределитьnew длямассивов (operator new[]). Этотоператорнедолженничегоделать, кромекак выделятьблокнеформатированнойпамяти. Мынеможемсовер- шатькакие-либооперациисещенесозданнымиобъектами. Даи, к томуже, намнеизвестенразмерэтихобъектов, ведьонимогутбыть наследникамикласса, вкоторомопределенnew[]. Тоестьколичествообъектоввмассивенеобязательноравно(запрошенноечисло байтов)/sizeof(Base). Болеетого, длядинамическихмассивовможет выделятьсябольшееколичествопамяти, чемзаймутсамиобъекты, дляобеспечениярезерва.

Соглашения при написании оператора delete

Чтокасаетсяоператораdelete, тотутвсегораздопроще. Основная гарантия, которуюмыдолжныпредоставить— этобезопасностьосвобожденияпамятипонулевомуадресу. Сучетомэтогопсевдокодdelete будетвыглядетьтак:

Псевдокодпользовательской реализацииоператораdelete

void *operator delete (void *rawMemory) throw()

{

//если нулевой указатель, ничего не делать if(rawMemory == 0) return;

//освободить память, на которую указывает rawMemory;

}

Еслиоператорdelete являетсяфункцией-членомкласса, то, какив случаесnew, следуетпозаботитьсяопроверкеразмераудаляемой памяти. Еслипользовательскаяреализацияnew дляклассаBase выделилаsizeof(Base) байтовпамяти, тоисамописныйdelete должен освободитьровностолькожебайтов. Впротивномслучае, еслиразмерудаляемойпамятинесовпадаетсразмеромкласса, вкотором определеноператор, следуетпередатьвсюработустандартному delete.

Псевдокодфункции-членаdelete

class Base { public:

static void *operator new (std::size_t size) throw(std::bad_alloc);

static void *operator delete

(void *rawMemory, std::size_t size) throw();

...

};

void* Base::operator delete (void *rawMemory, std::size_t size) throw()

{

CODING

// если нулевой указатель, ничего не делать if(rawMemory == 0) return;

if (size != sizeof(Base)) { ::operator delete(rawMemory); return;

}

// освободить память, на которую указывает rawMemory;

}

Операторы new

и delete с размещением

Функцияoperator new, принимающаядополнительныепараметры, называется«операторомnew сразмещением». Обычновкачестве дополнительногопараметравыступаетпеременнаятипаvoid*. Таким образом, определениеразмещающегоnew выглядитпримернотак:

void *operator new(std::size_t, void *pMemory).

Вболееширокомсмыслеnew сразмещениемможетприниматьлюбое количестводополнительныхпараметровлюбоготипа.

Операторdelete называется«размещаемым» потакомужепринципу

— онтожедолженпомимоосновныхприниматьидополнительные параметры.

Теперьдавайрассмотримслучай, когдамыдинамическисоздаем объекткакого-либокласса. Кодтакойоперациидолженбытьвсем хорошознаком: widget *pw = new Widget. Созданиеобъектапроисходитвдваэтапа. Напервомвыделяетсятребуемыйобъемпамяти стандартнымоператоромnew, анавторомвызываетсяконструктор классаWidget, которыйинициализируетобъект. Можетвозникнуть ситуация, когдапамятьнапервомшагебудетвыделена, аконструктор возбудитисключение, иуказатель*pw останетсянеинициализированным. Ахтунг! Такимобразоммыполучимпотенциальнуюутечку памяти. Чтобыэтогонепроизошло, заделодолжнавзятьсясистема времениисполненияC++. Онаобязанавызватьоператорdelete для выделеннойпамятинапервомэтапесозданияобъекта. Ноестьодин маленькийнюанс, которыйможетвсеиспортить. C++ вызоветdelete, сигнатуракоторогосовпадаетссигнатуройnew, используемогодля выделенияпамяти. Когдамыпользуемсястандартнымиформамиnew

иdelete, проблемневозникает, ноеслимынапишемсобственныйnew

сразмещениемизабудемнакодитьсоответствующуюформуdelete, томыпрактическисостопроцентнойвероятностьюполучимутечку памятипривозбужденииисключениявконструкторекласса.

Такойкодможетвызватьутечкипамяти

class Widget { public:

...

static void *operator new(std::size_t size, std::ostream& logStream) throw(std::bad_alloc);

static void *operator delete(void *pMemory, std::size_t size) throw();

...

};

Widget *pw = new (std::cerr) Widget;

114

Решениеэтойпроблемызаключаетсявнаписанииоператораdelete ссигнатурой, соответствующейсигнатуреnew сразмещением. Вслучаенеобходимостиотменитьвыделениепамятиименноэтотoperator delete будетвызвансистемойвремениисполненияC++. Вкодеэто можетвыглядетьтак:

Теперьутечекнедолжнобыть

class Widget { public:

...

static void *operator new(std::size_t size, std::ostream& logStream) throw(std::bad_alloc);

static void *operator delete(void *pMemory, std::size_t size)

throw();

static void *operator delete(void *pMemory, std::ostream& logStream)

throw();

...

};

Widget *pw = new (std::cerr) Widget;

Не следует забывать, что сконструированный объект может быть удален стандартной формой delete. Чтобы полностью избежать всех возможных проблем, связанных с выделением памяти, следует переопределить и этот вариант функции освобождения памяти. Ещеодинважныймоментсвязанссокрытиемименфункций. Если мыопределимкакую-либоформуnew, товсеостальныестандартные формыэтогооператорастанутнедоступны.

СОКРЫТИЕИМЕН

class Base { public:

static void *operator new (std::size_t size, std::ostream& logStream) throw(std::bad_alloc);

…

};

//Ошибка! Обычная форма new скрыта Base *pb = new Base;

//Правильно, вызывается размещенный new из Base Base *pb = new (std::cerr) Base;

Чтобыизбежатьэтого, можнонаписатьформы-переходники, которые будутперенаправлятьвызовыкстандартнымоператорамилиисполь- зоватьusing-объявления.

Заключение

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

XÀÊÅÐ 09 /140/ 10

НАЗНАЧЕНИЕFOREFRONT UAG

Продукт Forefront Unified Access Gateway (UAG) позиционируется как средство предоставления доступа к внутренним ресурсам сети через единую точку входа. Буквально за пару щелчков мышкой можно обеспечить клиенту подключение к самым разнообразным приложениям и сервисам, разработанным как в недрах Microsoft, так и сторонними производителями. По сравнению с Intelligent Application Gateway (IAG 2007), на платформе которого построен UAG, расширен список внутренних ресурсов, подлежащих публикации: Remote Desktop Services, SharePoint и Exchange (Outlook Web App и Anywhere), Dynamics CRM, Citrix XenApp, файловый сервис и так далее.

Еще одна фишка — политики доступа, при помощи которых админ задает требования для подключающихся клиентских систем: платформа, ОС, настройки системы и безопасности, наличие обновлений и т.д. Установка политик производится непосредственно в консоли управления UAG, также возможно использование политик NAP, расположенных на NPS-сервере (см. врезку «NAP & NPS»).

UAG может использоваться в трех вариантах:

•сервер публикаций (publishing server) — публикация корпоративных приложений и ресурсов и обеспечение доступа к ним;

•сервер DirectAccess — позволяет подключаться ко внутренней сети и ее ресурсам из любого места; в отличие от VPN, все настройки производятся автоматически, не требуя вмешательства пользователя;

•смешанный сервер (или несколько серверов), обеспечивающий обе функции.

Что особенно важно, UAG существенно расширяет возможности, заложенные в DirectAccess. В частности, упрощается доступ к практи- чески любым серверам, которые изначально не поддерживают эту технологию, в том числе устаревшим версиям Win2k3 и серверам, построенным на не-Windows платформе. Аналогичная ситуация и с другой стороны сети. Изначально DirectAccess поддерживают только Win7 и Win2k8R2, применение UAG обеспечивает SSL VPN доступ для клиентов XP/Vista, *nix/Mac OS X систем и различного рода мобильных девайсов. Применение UAG позволяет админам изменять настройки на клиентах, устанавливать обновления, изменять групповые политики, даже если пользователь еще не зарегистрировался в системе.

При работе в NLB (Network Load Balancing) массиве настройка производится из консоли UAG, при этом один из серверов назначается основным (master), все произведенные на нем настройки автомати- чески подхватываются остальными серверами. UAG поддерживает NLB, предоставляемую службой Win2k8R2. Как вариант возможна работа с продуктами сторонних разработчиков, некоторые из

них представлены на партнерской странице — go.microsoft.com/ fwlink/?LinkId=166184.

Публикация приложений производится при помощи транков (trunks). При этом подключение можно организовать по принципу «один ко многим», когда пользователь получает доступ ко всем приложениям с единого адреса. Вариант «один к одному» позволяет подключаться с одного IP на один опубликованный сервис.

Кроме того, Forefront UAG умеет производить предварительную аутентификацию клиента еще до того, как он будет подключаться ко внутреннему ресурсу. Для чего UAG поддерживает большое количество протоколов аутентификации: LDAP, RADIUS, TACACS, сертификаты SSL, WINHTTP.

Средствами UAG легко обеспечить единый вход (Single Sign-On) ко всем ресурсам, когда пользователь будет вводить пароль один раз. Для этого после авторизации на сервере UAG последний отсылает данные другим серверам для проверки подлинности, используя протоколы Kerberos, NTLM, HTTP. Возможна аутентификация пользователя и средствами внутреннего сервера. Поддерживается совместная работа со службой федерации AD — Active Directory Federation Services (AD FS).

Отмечу, что UAG никак не заменяет Forefront TMG (Threat Management Gateway, напомню, обеспечивает защиту периметра сети). Эти продукты направлены на решение разных задач, но принадлежность к единому семейству дает возможность их совместного использования и управления из единой консоли. По сути, UAG расширяет функции TMG.

УСТАНОВКАFOREFRONT UAG

Для установки потребуется сервер с CPU 2,66+ ГГц, 8+ Гб RAM (мастер установки выдаст предупреждение при наличии менее 4 Гб RAM), NIC 2+. Все это должно работать по д управлением Win2k8R2 версии Standard или Enterprise. Последние бывают только 64-бит- ными, поэтому и выбора, как такового, у нас нет. Никаких других ролей или приложений сервер содержать не должен, иначе это может вызвать сбои в работе мастера. Перед началом установки сервер должен быть подсоединен к домену.

На сайте доступна триал-версия, которая будет полнофункциональна в течение 120 дней. Проверить время до окончания пробного периода можно, запустив утилиту Uagver.exe (лежит в корне ISOобраза).

В окне приглашения программы установки доступен ряд ссылок, в частности на сопутствующую документацию проекта и ресурс

TechNet, где можно найти все требования, которые должны быть выполнены для инсталляции UAG. Также рекомендуется накатить все

обновления — нажатие на ссылку «Run Windows Update» запустит соответствующий мастер.

Теперь выбираем «Install Forefront UAG», после чего запускается Setup Wizard. По сути, ничего сложного в нем нет, просто пять раз жмем кнопку «Next». По окончании соглашаемся с перезагрузкой сервера, после которой обнаружим ряд новых запущенных сервисов (названия содержат Forefront).

В меню Пуск появляется подменю, где собраны ссылки для запуска консолей TMG и UAG. Выбираем консоль управления Forefront UAG Management. При первом запуске стартует мастер Getting Started Wizard, состоящий из трех шагов, выбор каждого приводит к запуску еще одного мастера. На этапе «Configure Network Setup» мастер проверяет настройки сетевых карт и выводит их список в небольшом окне. Устанавливаем чекеры из Unassigned в Internal и External и

в случае необходимости настраиваем сетевой интерфейс. Далее в «Define server Topology» выбираем топологию сервера UAG — одиночный (Single server) или член массива серверов (Array member).

Если компьютер не присоединен к домену, то будет доступен только вариант Single server. И, наконец, третий шаг — «Join Microsoft Update» — опциональный, он позволяет подключиться к сервису обновлений Microsoft Update для получения последних апдейтов. Все, активируем конфигурацию и устанавливаем пароль для бэкапа файлов.

КОНСОЛЬКОНФИГУРАЦИИFOREFRONT UAG

После загрузки консоли следует выбрать свой узел в корне сайта. Здесь будут отображены основные сообщения и проблемы, мешающие нормальной работе UAG, если таковые будут обнаружены. Установки в консоли конфигурации UAG разделены на три группы, в которых производятся настройки HTTP/HTTPS-подключений и DirectAccess. Первые две используются для создания новых транков (в терминологии ISA/TMG — «публикация ресурсов»), что позволяет настроить доступ к таким сервисам, как Outlook Web App, IIS, RDS, Citrix XenApp и некоторым другим приложениям.

Перед созданием HTTPS-транка необходимо сгенерировать сертификат в Certificate Manager, который будет использоваться для проверки подлинности сервера (подробно о создании сертификата смотри в статье «Слоеный VPN», опубликованной в ][ 08.2008). Для возможности SSO необходимо иметь настроенный Kerberos. Удобно, что большинство нужных ссылок, позволяющих корректно настроить необходимые для работы UAG параметры, собраны в меню Admin. Некоторые из произведенных здесь установок затем будут доступны при работе мастеров. Так, в Admin можно настроить сервер аутентификации и авторизации (Authentication and

Authorization Servers), сервер сетевой политики NPS, параметры балансировки нагрузки (Load Balancing), определить настройки SSL (SSL Protocol Settings), доступ к файлам (File Access) и многое другое. Принцип создания транка очень прост: выбираем в меню New Trunk

èследуем указаниям мастера. В процессе установок необходимо выбрать тип транка. Если отметить Portal trunk, то аутентификация будет производиться средствами UAG. Если планируем использовать для аутентификации средства Active Directory, ставим флажок напротив ADFS trunk. Флажок «Publish Exchange applications via the portal» позволяет публиковать в транке приложения Exchange.

Затем указываем название транка (оно должно быть уникальным), имя удаленного узла, к которому будет выполняться подключение,

èIP-адрес/порт. Опционально можно редиректить HTTP-трафик на HTTPS-порт, для этого нужно просто установить соответствующий флажок. Следующий шаг — выбор сервера аутентификации и авторизации: отмечаем в списке нужный или, если список пуст, нажав кнопку Add, производим настройку. В предложенном списке указываем протокол авторизации, данные сервера и пароль для доступа. Шаг 5 позволяет настроить использование политик доступа — внутренние политики (Forefront UAG access policies) или NAP (сервер NAP должен быть настроен). Политики UAG предлагаются по умолчанию, если их оставляем, то нужно указать политики для привилегированных и анонимных пользователей. При необходимости новую политику можно создать прямо в окне мастера, указав платформу или приложения. Если создаем HTTPS-транк, добавляется еще один шаг — выбор сертификата.

Все, транк создан, он будет показан в окне менеджера управления UAG. Аналогичным образом создаем и другие транки, если в них есть необходимость. Все произведенные настройки транка легко отредактировать. Выбираем нужный в окне менеджера и нажимаем кнопку Configure в области Trunk Configuration. В нескольких вкладках открывшегося окна можно указать максимальное количество подключений, изменить настройки аутентификации, настроить параметры сессии, проверку URL, парсинг и замену контента и другие настройки. Большая часть параметров понятна и без подсказки, поэтому остановлюсь лишь на некоторых. Во вкладке Portal настраиваем поиск и замену текста в URL, список URL, для которых такой анализ производиться не должен (например, локальный узел). Плюс здесь же вручную указываем список адресов, при вызове которых клиент будет перенаправляться на другой URL.

Вкладка URL Inspection позволяет задать список валидных методов для доступа к URL (POST, GET, PUT, DELETE и т.п.), установить ограничение по размеру для POST/PUT, указать список символов, которые разрешены в URL.