Дистанционная поддержка образовательного процесса. Радиус администрирования определяется по

Графическое моделирование организационных структур

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

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

Для четкого представления организационной структуры следует придерживаться нескольких правил:

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

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

Рыночные

Конкуренция

Динамика рынка высока: вкусы и предпочтения покупателей меняются постоянно, структура рынка чрезвычайно подвижна

Выявление первичных количественных характеристик организационной структуры

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

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

Определение некоторых количественных характеристик

В качестве количественных оценок могут быть предложены некоторые показатели. В нижеприведенной таблице представлена методика их исчисления.

Количественные оценки организационной структуры

Таблица 4.1.

№ п/п

Наименование

Коэффициент

Обозначение

Структурный коэффициент централизации

Kсц

Nцп

Nоп

Nцп - количество структурных подразделений, управляемых из единого центра

Nоп – общее количество структурных подразделений одного уровня

Количественный коэффициент централизации

Kкц

Nцч

Nоч

Nцч – численность работников подразделений, управляемых из единого центра

Nоч – общая численность работников организации

Объемный коэффициент централизации

Kок

Oц

Oо

Оц – объем работ, выполняемых централизованными подразделениями

Оо – общий объем работ организации

Коэффициент централизации управления

Kцу

Nуц

Nуо

Nуц – количество работников централизованного управления

Nуо – общее количество работников управления

Коэффициент централизации функций

Kцф

Чцц

Чцц+Чцп

Чцц – численность работников по централизованным функциям в центральном аппарате

Чцп – то же в аппарате подразделений

Коэффициент централизации отдельных функций

Kц

Тт

Тт+Тц

Тт – затраты труда работников аппарата управления по отдельным функциям, чел-дн.

Тц – затраты труда прочих работников, чел-дн.

Коэффициент централизации в среднем по всем функциям

Kц

Радиус администрирования

Ar – годовой объем работ в удаленном филиале

R – расстояние до объекта

Средняя плотность управления

Aо – годовой объем работ на удаленном филиале

Абсолютная плотность управления

Нс

S – площадь административного района, находящегося в зоне действия организации

Уровень специализации

Ус

Nсп

Nсп – число специализированных подразделений (бизнес-единиц)

N – общее число подразделений

Коэффициент использования организационных резервов

Kн

Xф

Чн

X ф.н. – фактические и нормативные значения определенного параметра структуры управления

Обобщающий коэффициент использования организационных резервов

Kн

Коэффициент структурной напряженности

Kсн

d - удельный вес работников аппарата управления в % от общей численности

Коэффициент соблюдения норм управляемости Kупр

Чф

Чн

Ч ф.н. – соответственно фактическая и нормативная численность работников, подчиненных одному руководителю.

Критерий эффективности – приведенные затраты

(С+ Eн К)

C – текущие затраты на управление

Eн – нормативный коэффициент эффективности инвестиций

K – единовременные затраты на управление (инвестиции

Коэффициент соответствия должности

Kсд

Чс

Чау

Чс – численность работников аппарата управления, соответствующих должности по результатам аттестации

Чау – общая численность аппарата управления

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

Кф =,

где .- количество формализованных должностей,

Чо – общее количество должностей по штатному расписанию.

Важным показателем организационной структуры является оценка сложности ее управления, которая определяется как отношение:

Ксл=,

где Ч – общая численность работников предприятия.

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

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

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

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

- получение на основе этих рангов весовых характеристик, то есть их относительной значимости;

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

Рассмотрим оценку соответствия организационной структуры состоянию внешней среды, технологии и размерам предприятия.

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

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

studfiles.net

Все про протокол RADIUS Accounting ExpertBilling

Протокол авторизации RADIUS является ключевой частью большинства биллинговых систем. Для лучшего понимания принципов работы ExpertBilling System советуем вам ознакомиться с данной статьей.Здесь присутствуют элементы документации RFC 2865 и RFC 2866.

Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Со временем выкристаллизовались и другие области применения этой технологии. К ним относятся серверы виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве своем поддерживают Rаdius, — а также точки доступа беспроводных локальных сетей (Wireless LAN, WLAN), и это далеко не все.

Концепция службы идентификации удаленных пользователей подразумевает, что клиент RADIUS — обычно сервер доступа, сервер VPN или точка доступа беспроводной локальной сети — отсылает серверу RADIUS параметры доступа пользователя (в англоязычной документации они часто называются Credentials, т. е. мандат, куда, к примеру, входят его настройки безопасности и права доступа), а также параметры соответствующего соединения. Для этого клиент использует специальный формат, так называемый RADIUS-Message (сообщение RADIUS). В ответ сервер начинает проверку, в ходе которой он аутентифицирует и авторизует запрос клиента RADIUS, а затем пересылает ему ответ — RADIUS-Message-response. После этого клиент передает на сервер RADIUS учетную информацию.

Сами по себе сообщения RADIUS передаются в форме пакетов UDP. Причем информация об аутентификации направляется на порт UDP с номером 1812. Некоторые серверы доступа используют, однако, порты 1645 (для сообщений об аутентификации) или, соответственно, 1646 (для учета) — выбор должен определять своим решением администратор. В поле данных пакета UDP (так называемая полезная нагрузка) всегда помещается только одно сообщение RADIUS. В соответствии с RFC 2865 и RFC 2866 определены следующие типы сообщений:

Access-Request - "запрос доступа". Запрос клиента RADIUS, с которого начинается собственно аутентификация и авторизация попытки доступа в сеть;
Access-Accept - "доступ разрешен". С помощью этого ответа на запрос доступа клиенту RADIUS сообщается, что попытка соединения была успешно аутентифицирована и авторизована;
Access-Reject - "доступ не разрешен". Этот ответ сервера RADIUS означает, что попытка доступа к сети не удалась. Такое возможно в том случае, если пользовательских данных недостаточно для успешной аутентификации или доступ для пользователя не авторизован;
Access-Challenge - "вызов запроса". Сервер RADIUS передает его в ответ на запрос доступа;
Accounting-Request - "запрос учета", который клиент RADIUS отсылает для ввода учетной информации после получения разрешения на доступ.

Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из которых содержит ту или иную информацию о попытке доступа: например, имя и пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким образом, главной задачей атрибутов RADIUS является транспортировка информации между клиентами и серверами RADIUS. Атрибуты RADIUS определены в нескольких RFC, а именно: RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869 и RFC 3162.

Протокол CHAP (Challenge Handshake Authentication Protocol)— это протокол проверки подлинности типа «запрос-ответ», использующий стандартную схему хеширования Message Digest 5 (MD5) для шифрования ответа. Протокол CHAP используется множеством поставщиков серверов и клиентов доступа к сети. Сервер, использующий маршрутизацию и удаленный доступ, поддерживает CHAP таким образом, что выполняется проверка подлинности клиента удаленного доступа, требующего данный протокол. Так как CHAP требует использования обратимо зашифрованного пароля, рекомендуется использовать другой протокол проверки подлинности, например MS-CHAP версии 2.

Операционные системы семейства Windows Server 2003 поддерживают протокол MS-CHAP v2, обеспечивающий взаимную проверку подлинности, создание более надежных начальных ключей шифрования данных для MPPE (Microsoft Point-to-Point Encryption) и разные ключи шифрования для отправки и приема данных. Чтобы свести к минимуму риск раскрытия пароля во время обмена паролями, из протокола исключена поддержка старых методов обмена паролями MS-CHAP.

Поскольку версия MS-CHAP v2 обеспечивает более надежную защиту, чем MS-CHAP, при подключении сначала предлагается использовать именно ее (если она доступна), а затем уже MS-CHAP.

Протокол MS-CHAP v2 поддерживается на компьютерах, работающих под управлением Windows XP, Windows 2000, Windows 98, Windows Millennium Edition и Windows NT 4.0. Компьютеры, работающие под управлением Windows 95, поддерживают MS-CHAP v2 только для подключений VPN, но не для подключений удаленного доступа.

Кроме того, возможно применение RADIUS вместе с PPP, протоколом передачи «точка-точка» (Point-to-Point Protocol). Результаты сеанса аутентификации между сервером доступа и действующим клиентом передаются на сервер RADIUS, который их потом удостоверяет.

Для защиты сообщений клиент и сервер RADIUS обладают «общим секретом» или, проще говоря, ключом. При этом речь, как правило, идет о цепочке символов, имеющейся как на серверах, так и на клиенте RADIUS.

НЕПРАВИЛЬНО СКОНФИГУРИРОВАННЫЙ ОБЩИЙ СЕКРЕТ

Еще одна потенциально слабая точка реализации RADIUS касается «общего секрета» (Shared Secret). Это связано с тем, что очень часто один и тот же «общий секрет» служит для поддержки максимального количества пар «клиент-сервер» в службе RADIUS. К тому же в большинстве случаев криптологически он недостаточно устойчив против атаки с перебором слов по словарю в автономном режиме. Значение поля Response Authenticator и содержимое атрибута Message Authenticator легко вычисляются. Потом эти данные сравниваются с перехваченным сообщением Access-Accept, Access-Reject или Access-Challenge. Таким образом, легко разгадываемый «общий секрет» может быть быстро скомпрометирован.

Сложившаяся ситуация усугубляется также некоторыми вариантами реализации RADIUS — довольно часто длина «общего секрета» не может превышать определенной величины, или же набор символов, из которых образуется ключевое слово, ограничен. В качестве примера приведем распространенную установку на использование только тех символов из набора ASCII, которые находятся непосредственно на клавиатуре — то есть лишь 94 из доступных 256 символов ASCII.

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

RFC 2865 предписывает использование 16 символов в «общем ключе». Однако для достижения энтропии (в теории информации энтропия отражает количество информации в последовательности символов) равной 128 бит каждый отдельный символ должен иметь энтропию 8 бит. В случае же, когда выбор символов ограничен имеющимися на клавиатуре, энтропия 8-битного символа уменьшается до 5,8 бит. Поэтому, чтобы добиться уровня энтропии в 128 бит, необходимо 22 символа. В среде Windows 2000 максимально возможная длина «общего секрета» может быть равна 64 символам (из имеющихся на клавиатуре).

Качественно улучшить результаты позволяет использование программ для генерирования «общего секрета», поскольку при этом обычно получаются лучшие, по сравнению с ручным вводом, значения энтропии. Кроме того, пара «клиент-сервер», использующая RADIUS, всегда должна быть защищена одним и тем же «общим секретом».

ПРИМЕНЕНИЕ RADIUS

Соблюдение некоторых принципов при вводе RADIUS в эксплуатацию поможет свести различные риски к минимуму. При этом следует использовать алгоритм шифрования Triple DES. Такой метод описан также в документе RFC 3162. Путем шифрования всего сообщения RADIUS защищаются особо чувствительные его части — такие, как поле удостоверения запроса в сообщении запроса доступа — и атрибуты RADIUS (к примеру, пароль пользователя или атрибуты ключа МРРЕ). Тому, кто предпримет попытку проникновения в систему, понадобится сначала расшифровать защищенное с помощью ESP сообщение RADIUS, и лишь после этого он сможет анализировать его содержимое. Чтобы предотвратить атаки на сервер RADIUS извне, рекомендуется установить программное обеспечение для аутентификации с использованием сертификатов. Помимо этого, возможны и другие варианты защиты.

Используемый "общий секрет" должен иметь длину не менее 32 шестнадцатеричных символов или, соответственно, 22 символов клавиатуры;
Для всех сообщений с запросом доступа обязательны атрибуты удостоверения сообщения. Для клиента RADIUS это означает, что атрибут удостоверения сообщения нужен и для всех сообщений запроса доступа. Это правило требуется соблюдать также в случае сервера RADIUS;
С криптографической точки зрения непременным условием является качественное удостоверение запроса.

Нижеперечисленные советы помогут в реализации дополнительной защиты аутентификации:

Следует пользоваться ЕАР или схемами типа ЕАР с поддержкой сильных методов аутентификации. Хороший пример подобного метода - ЕАР-TLS. Он требует обмена сертификатами между клиентом, пытающимся получить доступ, и сервером RADIUS. Все сообщения ЕАР должны иметь атрибуты удостоверения сообщения для защиты сообщений запроса доступа.

Желательно выбирать методы аутентификации, рассчитанные на двустороннюю аутентификацию. При таком подходе противоположные конечные точки соединения аутентифицируют свои системы. Если с какой-либо стороны аутентификация пройдет неудачно, то в установлении соединения будет отказано. Примерами подобных методов служат ЕАР-TLS и MS-CHAPv2. Так, в случае ЕАР-TLS сервер RADIUS проводит проверку пользовательского сертификата клиента, пытающегося получить доступ, а клиент в свою очередь - сертификата сервера RADIUS.

Если аутентификация производится посредством РАР, то эту опцию следует отключить. При аутентификации с помощью однократных паролей или токенов происходит откат к PAP. Но поскольку IEEE 802.1x не поддерживает РАР, в подобных случаях чаще всего пользуются соединениями РРР.

РАСШИРЕННЫЙ ПРОТОКОЛ АУТЕНТИФИКАЦИИ

Расширенный протокол аутентификации (Extensible Authentication Protocol, EAP) изначально задумывался как дополнение к РРР для поддержки различных механизмов аутентификации доступа к сети. Протоколы аутентификации для РРР, например CHAP, MS-CHAP и MS-CHAPv2, определяют механизм аутентификации во время фазы установления соединения. На этом этапе необходимо применять согласованный протокол аутентификации, с целью «верификации» соединения. В данном случае речь идет о заранее определенной последовательности сообщений, причем они должны отсылаться в соответствии с заданной схемой, а точнее, в указанной очередности.

При использовании EAP в процессе установления соединения в рамках РРРспециальный механизм аутентификации не определяется. Лишь на этапе аутентификации участники взаимодействуют по специальной схеме аутентификации EAP, обозначаемой также как «схема типа EAP». ЕАР позволяет осуществлять обмен сообщениями между клиентом, запрашивающим доступ, и аутентифицирующим сервером (в его роли часто выступает сервер RADIUS). При этом обмен сообщениями может варьироваться с учетом особенностей различных соединений; он состоит собственно из запросов, в которых требуется предоставление информации об аутентификации, а также из соответствующих ответов. Длительность и конкретные детали сеанса аутентификации зависят от заданной схемы EAP.

В архитектурном плане ЕАР задумывался таким образом, чтобы аутентификацию можно было выполнять с помощью подключенных модулей с обеих сторон соединения: от клиента и от сервера. Если библиотечный файл ЕАР установить на обоих концах, то в любой момент можно применить новую схему аутентификации. Тем самым ЕАР предоставляет гибкую среду для внедрения безопасных методов аутентификации. ЕАР удобен при таких видах аутентификации, как токены (Generic Token Card), однократные пароли (One Time Password), запрос/ответ (MD5-Challenge) или защита на транспортном уровне (Transport Level Security). Кроме того, эта концепция открыта для применения лучших технологий аутентификации в будущем. Однако ЕАР используется не только вместе с РРР. Он, помимо всего, поддерживается на канальном уровне стандарта IEEE 802.

К примеру, службу RRAS операционной системы Windows 2000 можно настроить таким образом, что система с каждым сообщением запроса доступа станет отправлять атрибут удостоверение сообщения (Message-Authenticator). При этом в соответствующем диалоговом окне необходимо выбрать в свойствах опцию always use digital signatures («всегда использовать цифровую подпись»). Служба аутентификации в Internet (Internet Authentication Service, IAS) настраивается со стороны Windows 2000 так, чтобы при получении любого сообщения запроса доступа проверялось наличие атрибута Message-Authenticator. Администратор должен установить соответствующий флажок в свойствах клиента RADIUS, чтобы клиент постоянно пересылал в запросе атрибут подписи.

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

expertbilling.ru

О Radius подробно | Журнал сетевых решений/LAN

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

Oсновные составные части службы идентификации удаленных пользователей (Remote Authentication Dial-In User Service, RADIUS) описываются двумя RFC от IETF: RFC 2865 под названием Remote Authentication Dial-In User Service (RADIUS) в форме проекта стандарта и RFC 2866 под названием RADIUS Accounting в виде «информационного RFC». Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Со временем выкристаллизовались и другие области применения этой технологии. К ним относятся серверы виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве своем поддерживают Rаdius, — а также точки доступа беспроводных локальных сетей (Wireless LAN, WLAN), и это далеко не все.

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

Access-Request - "запрос доступа". Запрос клиента RADIUS, с которого начинается собственно аутентификация и авторизация попытки доступа в сеть;
Access-Accept - "доступ разрешен". С помощью этого ответа на запрос доступа клиенту RADIUS сообщается, что попытка соединения была успешно аутентифицирована и авторизована;
Access-Reject - "доступ не разрешен". Этот ответ сервера RADIUS означает, что попытка доступа к сети не удалась. Такое возможно в том случае, если пользовательских данных недостаточно для успешной аутентификации или доступ для пользователя не авторизован;
Access-Challenge - "вызов запроса". Сервер RADIUS передает его в ответ на запрос доступа;
Accounting-Request - "запрос учета", который клиент RADIUS отсылает для ввода учетной информации после получения разрешения на доступ;
Accounting-Response - "ответ учета". Таким образом сервер RADIUS реагирует на запрос учета и подтверждает факт обработки запроса учета.

Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из которых содержит ту или иную информацию о попытке доступа: например, имя и пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким образом, главной задачей атрибутов RADIUS является транспортировка информации между клиентами, серверами и прочими агентами RADIUS. Атрибуты RADIUS определены в нескольких RFC, а именно: RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869 и RFC 3162.

RADIUS может совместно работать с различными протоколами аутентификации. Наиболее часто используются протокол аутентификации пароля (Password Authentication Protocol, РАР), протокол аутентификации с предварительным согласованием (Challenge Handshake Authentication Protocol, CHAP), а также MS-CHAP (CHAP от Microsoft в первой версии или MS-CHAPv2 — во второй). Кроме того, возможно применение RADIUS вместе с PPP, протоколом передачи «точка-точка» (Point-to-Point Protocol). Результаты сеанса аутентификации между сервером доступа и действующим клиентом передаются на сервер RADIUS, который их потом удостоверяет.

РАСШИРЕННЫЙ ПРОТОКОЛ АУТЕНТИФИКАЦИИ

ЕАР позволяет осуществлять обмен сообщениями между клиентом, запрашивающим доступ, и аутентифицирующим сервером (в его роли часто выступает сервер RADIUS). При этом обмен сообщениями может варьироваться с учетом особенностей различных соединений; он состоит собственно из запросов, в которых требуется предоставление информации об аутентификации, а также из соответствующих ответов. Длительность и конкретные детали сеанса аутентификации зависят от заданной схемы EAP.

ЕАР удобен при таких видах аутентификации, как токены (Generic Token Card), однократные пароли (One Time Password), запрос/ответ (MD5-Challenge) или защита на транспортном уровне (Transport Level Security). Кроме того, эта концепция открыта для применения лучших технологий аутентификации в будущем. Однако ЕАР используется не только вместе с РРР. Он, помимо всего, поддерживается на канальном уровне стандарта IEEE 802.

НЕПРАВИЛЬНО СКОНФИГУРИРОВАННЫЙ ОБЩИЙ СЕКРЕТ

МЕХАНИЗМ СОКРЫТИЯ

Для шифрования пароля пользователя и прочих атрибутов применяются «общий секрет», аутентификатор запросов и алгоритм хэширования MD5. Эту комбинацию нельзя назвать верхом совершенства с точки зрения надежности шифрования, что отражено и в RFC 2865 — в документе рекомендуется как можно лучше позаботиться о надежности передачи.

Примером лучшей защиты атрибутов является применение IPSec. В комплекте с протоколом инкапсуляции защищаемой полезной нагрузки (Encapsulated Security Payloаd, EPS) и мощным шифровальным механизмом, наподобие Triple DES, можно добиться очень высокой надежности передачи данных и конфиденциальности сообщения RADIUS.

Если же совместная работа IPSec, ESP и алгоритма шифрования невозможна, у администратора сети остается еще один способ уменьшения вероятности взлома выполненной реализации RADIUS:

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

ПРИМЕНЕНИЕ RADIUS

Соблюдение некоторых принципов при вводе RADIUS в эксплуатацию поможет свести различные риски к минимуму. Для повышения достоверности передаваемых сообщений RADIUS рекомендуется применение IPSec и EPS. При этом следует использовать алгоритм шифрования Triple DES. Такой метод описан также в документе RFC 3162. Путем шифрования всего сообщения RADIUS при помощи IPSec защищаются особо чувствительные его части — такие, как поле удостоверения запроса в сообщении запроса доступа — и атрибуты RADIUS (к примеру, пароль пользователя или атрибуты ключа МРРЕ). Тому, кто предпримет попытку проникновения в систему, понадобится сначала расшифровать защищенное с помощью ESP сообщение RADIUS, и лишь после этого он сможет анализировать его содержимое. Чтобы предотвратить атаки на сервер RADIUS извне, рекомендуется установить программное обеспечение для аутентификации IPSec с использованием сертификатов. Помимо этого, возможны и другие варианты защиты, которые могут использоваться как в совокупности с IPSec, так и отдельно.

Используемый "общий секрет" должен иметь длину не менее 32 шестнадцатеричных символов или, соответственно, 22 символов клавиатуры.
Для всех сообщений с запросом доступа обязательны атрибуты удостоверения сообщения. Для клиента RADIUS это означает, что атрибут удостоверения сообщения нужен и для всех сообщений запроса доступа. Это правило требуется соблюдать также в случае сервера RADIUS.
С криптографической точки зрения непременным условием является качественное удостоверение запроса.

Нижеперечисленные советы помогут в реализации дополнительной защиты аутентификации.

Следует пользоваться ЕАР или схемами типа ЕАР с поддержкой сильных методов аутентификации. Хороший пример подобного метода - ЕАР-TLS. Он требует обмена сертификатами между клиентом, пытающимся получить доступ, и сервером RADIUS. Все сообщения ЕАР должны иметь атрибуты удостоверения сообщения для защиты тех сообщений запроса доступа, к которым IPSec не применяется.
Желательно выбирать методы аутентификации, рассчитанные на двустороннюю аутентификацию. При таком подходе противоположные конечные точки соединения аутентифицируют свои системы. Если с какой-либо стороны аутентификация пройдет неудачно, то в установлении соединения будет отказано. Примерами подобных методов служат ЕАР-TLS и MS-CHAPv2. Так, в случае ЕАР-TLS сервер RADIUS проводит проверку пользовательского сертификата клиента, пытающегося получить доступ, а клиент в свою очередь - сертификата сервера RADIUS.
Если аутентификация производится посредством РАР, то эту опцию следует отключить. При аутентификации с помощью однократных паролей или токенов происходит откат к PAP. Но поскольку IEEE 802.1x не поддерживает РАР, в подобных случаях чаще всего пользуются соединениями РРР.

ИСПОЛЬЗОВАНИЕ RADIUS ДЛЯ УДАЛЕННОГО ДОСТУПА И VPN

Рисунок 2. Пункт «Конфигурация RAS» в Windows 2000 предлагает несколько опций.

Рисунок 3. Сервер RAS должен понимать протоколы, посредством которых отдельные клиенты пытаются получить к нему доступ.

Подключение работающего сервера RADIUS к виртуальной частной сети (Virtual Private Network, VPN) или службе удаленного доступа (Remote Access Service, RAS) выполняется сравнительно просто. В операционной системе Windows 2000 для этого предусмотрены опции Remote Access Service (RAS) и VPN Server. Начать следует с пункта «Конфигурация сервера». Затем пользователю будут помогать различные программные эксперты. Для конфигурации RAS посредством «Ассистента настройки для сервера маршрутизации и RAS» в меню «Пуск — Программы — Управление» нужно выбрать пункт «Маршрутизация и удаленный доступ». Затем указать желаемое имя сервера, щелкнуть мышью на пункте «Конфигурация и активизация маршрутизации и RAS» в исходном меню и нажать кнопку «Далее». Администратору предоставится возможность выбора нескольких опций (см. Рисунок 2). Он должен выбрать пункт «cервер RAS», перейти к окну выбора протокола поддержки удаленного клиента (см. Рисунок 3) и отметить в нем тип соединения, через которое происходит связь с Intranet.

Рисунок 4. Соединение сервера RAS с сервером Radius.

Далее необходимо указать способ распределения IP-адресов в диалоговом окне «Распределение IP-адресов». Если администратор выберет пункт «Автоматически», тогда сервер удаленного доступа для распределения IP-адресов между удаленными клиентами будет использовать протокол динамической конфигурации хоста (Dynamic Host Configuration Protocol, DHCP). С другой стороны, одну или даже несколько специальных областей IP-адресов можно распределить статично. По завершении этого этапа появляется окно «Управление несколькими серверами RAS». После чего в игру вступает соединение с RADIUS (см. Рисунок 4). Если администратор остановит выбор на пункте «Да, должен использоваться сервер RADIUS», то он обязан сразу же специфицировать первый сервер RADIUS, а при необходимости и второй (но это необязательно). После чего выполняются завершающие действия, и службу RAS можно запускать. Если применяется сервер VPN, то конфигурацию осуществляют соответствующим образом.

Роберт Шотт — независимый автор. С ним можно связаться по адресу: [email protected].

? AWi Verlag

www.osp.ru

ISSP \ Домен 02. Управление доступом. Часть 8

В этой части рассмотрены следующие вопросы:

Администрирование доступа
Централизованное администрирование управления доступом
RADIUS
TACACS
Diameter
Децентрализованное администрирование управления доступом

Обновлено: 27.03.2010

Итак, после того как компания разработала политику безопасности, а также поддерживающие ее процедуры, стандарты и руководства (см. Домен 01), она должна выбрать тип модели управления доступом: DAC, MAC или ролевое. Затем компания должна выбрать и внедрить различные технологии и техники управления доступом, среди которых могут быть матрицы контроля доступа, ограниченные интерфейсы, контекстно- или контентно-зависимое управление, либо управление на основе правил. Если среда не требует высокого уровня безопасности, компании следует выбрать дискреционную или ролевую модель. Модель DAC позволяет владельцам данных управлять доступом пользователей к своим ресурсам, поэтому компания должна полностью осознавать возможные последствия, выбирая эту модель. Если в компании большая «текучесть» кадров и/или требуется более централизованный метод управления доступом, целесообразно выбрать ролевую модель. Если среда требует более высокого уровня безопасности, и в ней только администратор должен иметь возможность предоставления доступа к ресурсам, тогда наилучшим выбором будет модель МАС. Теперь осталось определить, как компания будет администрировать выбранную модель управления доступом. Существует два основных варианта администрирования управления доступом: централизованный и децентрализованный. При принятии решения необходимо понимать оба подхода, чтобы выбирать из них именно тот, который позволит обеспечить необходимый уровень безопасности.При централизованном администрировании доступа (centralized access control administration) один субъект (человек или подразделение) следит за доступом ко всем корпоративным ресурсам. Этот субъект (администратор безопасности) настраивает механизмы, которые реализуют управление доступом, выполняет изменения пользовательских профилей, отзывает права доступа при необходимости, полностью блокирует доступ пользователя в случае его увольнения. Этот тип администрирования предоставляет последовательные и унифицированные методы управления правами доступа пользователей. Он обеспечивает строгий контроль данных, т.к. только один человек (или подразделение) имеет необходимые права для изменения профилей доступа и разрешений, однако это довольно медленный способ, поскольку все изменения должны быть выполнены одним человеком (подразделением).

В следующих разделах будут приведены несколько примеров технологий централизованного удаленного управления доступом. Применяющиеся для этих целей протоколы аутентификации называют AAA-протоколами (аутентификация, авторизация и аудит).

В зависимости от протокола, существуют различные способы аутентификации пользователей в клиент-серверной архитектуре. Традиционные протоколы аутентификации: PAP (password authentication protocol), CHAP (challenge handshake authentication protocol) и новый метод EAP (extensible authentication protocol). Каждый из этих протоколов будет рассмотрен в Домене 05.

RADIUS (remote authentication dial-in user service) – это сетевой протокол, который обеспечивает клиент-серверную аутентификацию, авторизацию и аудит удаленных пользователей. Для подключения удаленных пользователей, в сети должны быть установлены серверы доступа и средства для удаленного подключения (например, модемный пул, DSL, ISDN или линия Т1). Сервер доступа запрашивает у пользователя учетные данные для входа и передает их на сервер RADIUS, на котором хранятся имена пользователей и пароли. При этом удаленный пользователь является клиентом сервера доступа, а сервер доступа является клиентом RADIUS-сервера.

В настоящее время большинство интернет-провайдеров используют RADIUS для аутентификации клиентов, перед тем, как разрешить им доступ к сети Интернет. Сервер доступа и программное обеспечение клиента «договариваются» о протоколе аутентификации, который они будут использовать (PAP, CHAP или EAP), посредством процедуры «рукопожатия» (handshake), после чего клиент передает серверу доступа свое имя пользователя и пароль. Это взаимодействие происходит через соединение PPP. Взаимодействие сервера доступа с RADIUS-сервером осуществляется по протоколу RADIUS. Сервер доступа уведомляет RADIUS-сервер о фактах начала и окончания сеанса в целях предоставленных тарификации услуг (биллинга).

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

RADIUS был разработан компанией Livingston Enterprises для своей серии серверов доступа, но затем был опубликован в виде стандартов RFC 2865 и RFC 2866. Это открытый протокол, который может использовать любой производитель в своих продуктах. Конфигурации и учетные данные пользователей могут храниться на серверах LDAP, в различных базах данных или текстовых файлах. Рисунок 2-13 показывает некоторые примеры возможных реализаций RADIUS.

Рисунок 2-13. В различных средах инфраструктура RADIUS может быть реализована по-разному

TACACS (Terminal Access Controller Access Control System) прошел через три поколения: TACACS, Extended TACACS (XTACACS) и TACACS+. TACACS объединяет процессы аутентификации и авторизации, XTACACS разделяет процессы аутентификации, авторизации и аудита, а TACACS+ – это XTACACS с расширенной двухфакторной аутентификацией пользователей. TACACS использует постоянные пароли для аутентификации, а TACACS+ позволяет использовать динамические (одноразовые) пароли, обеспечивая более высокий уровень безопасности. ПРИМЕЧАНИЕ. TACACS+ на самом деле не является новым поколением TACACS и XTACACS. Это новый протокол, который обеспечивает похожую функциональность и использует ту же схему имен. И поскольку это совершенно другой протокол, он не совместим с TACACS или XTACACS.TACACS+ реализует в основном ту же функциональность, что и RADIUS с некоторыми отличиями. Во-первых, TACACS+ использует в качестве транспорта протокол TCP вместо протокола UDP в RADIUS, и поэтому ему не требуется дополнительный код для обнаружения и исправления ошибок передачи сетевых пакетов. Во-вторых, TACACS+ шифрует всю информацию (включая имя пользователя, данные учета и авторизации), а RADIUS шифрует только пароль пользователя, позволяя злоумышленнику перехватить важную информацию. В-третьих, TACACS+ использует настоящую архитектуру ААА, обеспечивая дополнительную гибкость при настройке процесса аутентификации удаленных пользователей, тогда как RADIUS объединяет функциональность аутентификации и авторизации.

Например, перед сетевым администратором Томом была поставлена задача организации удаленного доступа для пользователей, и он должен выбрать между RADIUS и TACACS+. Если в имеющейся среде аутентификация всех локальных пользователей осуществляется через контроллер домена с помощью Kerberos, Том может аналогичным образом настроить процесс аутентификации удаленных пользователей, как показано на Рисунке 2-14. Вместо того чтобы одновременно поддерживать базу данных удаленных пользователей на сервере удаленного доступа и базу данных локальных пользователей в Active Directory, Том может настроить работу через одну базу данных. Разделение функциональности аутентификации, авторизации и учета позволяет сделать это. TACACS+ также позволяет сетевому администратору настроить более детальные профили пользователей, указывая реальные команды, которые пользователи могут выполнять.

Рисунок 2-14. TACACS+ работает в рамках клиент-серверной модели

Помните, что RADIUS и TACACS+ являются протоколами, а протоколы являются не более чем согласованным способом взаимодействия. Когда RADIUS-клиент связывается с RADIUS-сервером, он делает это посредством протокола RADIUS, который на самом деле представляет собой некий набор полей, в которые записываются некоторые значения. Эти поля называют парами атрибут-значение (AVP – attribute-value pair). В качестве аналогии, предположим, что я посылаю вам пустой бланк, на котором есть несколько пустых строк, каждая из которых имеет название: фамилия, имя, цвет волос, размер обуви. Вы заполняете эти строки соответствующими значениями и отправляете заполненный банк обратно мне. В общем виде, именно так работают протоколы: отправляющая система просто заполняет поля необходимой для принимающей системы информацией, которая затем извлекает ее и обрабатывает.

TACACS+ имеет больше AVP, что обеспечивает более детальный контроль того, что могут и что не могут делать пользователи, а также позволяет сетевому администратору определять списки ACL, фильтры, привилегии пользователей и многое другое. Таблица 2-2 показывает различия между RADIUS и TACACS+.

Таблица 2-2. Отдельные различия между двумя ААА-протоколами

Таким образом, RADIUS является подходящим протоколом, если используется упрощенная аутентификация по имени пользователя и паролю, и системе нужно только решить, разрешать доступ пользователю или нет (как, например, для работы интернет-провайдера). TACACS+ лучше подходит для сред, в которых требуется более надежная аутентификация и жесткий контроль более сложных действий по авторизации (как, например, в корпоративных сетях).Сторожевые таймеры (Watchdog). Сторожевые таймеры, как правило, используются для выявления программных ошибок, таких как некорректно завершившийся или «зависший» процесс. Сторожевая функция посылает периодические запросы, чтобы определить, отвечает ли на них сервис. Если она не получает ответа от сервиса, он может быть остановлен или сброшен. Сторожевая схема предотвращает взаимные блокировки программного обеспечения, бесконечных циклов и проблем с приоритетами процессов. Такая функциональность может использоваться в протоколах AAA для выявления необходимости повторной отправки пакета, либо закрытия и повторного открытия соединения, с которым возникли какие-либо проблемы.Diameter – это протокол, разработанный на базе функциональности RADIUS, устраняющий многие из его ограничений. Diameter – это еще один ААА-протокол, предоставляющий такую же функциональность, как RADIUS и TACACS+, но являющийся более гибким и отвечающий современным требованиям. Одно время все удаленные подключения осуществлялись по протоколам PPP и SLIP, а аутентификация пользователей производилась через PAP или CHAP. Но сегодня технологии стали значительно сложнее, появилось множество различных устройств и протоколов, между которыми можно выбирать. Сегодня мы хотим, чтобы наши беспроводные устройства и смартфоны могли аутентифицироваться в нашей сети, мы используем протоколы роуминга, мобильные IP, PPP через Ethernet, голос через IP (VoIP) и т.п. Традиционные ААА-протоколы не могут работать со всем этим. Поэтому был разработан новый ААА-протокол Diameter, который решает эти проблемы, а также многие другие.

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

Мобильный IP. Эта технология позволяет пользователю перемещаться из одной сети в другую и при этом продолжать использовать один и тот же IP-адрес. Это усовершенствование протокола IP, которое позволяет пользователю иметь свой домашний IP-адрес, связанный с его домашней сетью, и обслуживающий адрес (care-of address). Обслуживающий адрес меняется при перемещении из одной сети в другую. Весь трафик, адресованный на домашний IP-адрес пользователя, перенаправляется на его обслуживающий адрес.До появления концепции Diameter, в IETF были отдельные рабочие группы, которые определяли порядок работы протоколов VoIP (голос через IP), FoIP (факс через IP), Мобильный IP, а также протоколов удаленной аутентификации. Внедрение их по отдельности в любой сети легко может привести к целому ряду сложностей, включая проблемы совместимости. Это требует от клиентов развертывать и настраивать несколько серверов с различными политиками и увеличивает стоимость каждого нового дополнительного сервиса. Diameter предоставляет базовый протокол, который определяет формат заголовков, параметры безопасности, команды и AVP. Этот базовый протокол позволяет связать расширения с другими сервисами, такими как VoIP, FoIP, Мобильный IP, аутентификацию беспроводных устройств и мобильных телефонов. Таким образом, Diameter может использоваться в качестве ААА-протокола во всех этих случаях. В качестве аналогии, рассмотрим ситуацию, в которой десяти сотрудникам одной компании нужно попасть на работу. Они могут ездить на работу на своих автомобилях по своим маршрутам, но это потребует дополнительную территорию для организации стоянки, а также найма охранника, чтобы он стоял около ворот и пропускал только машины сотрудников компании. С другой стороны, все они могут воспользоваться автобусом компании. Автобус в данном случае является общим элементом (как базовый протокол), позволяющим всем сотрудникам (различным сервисам) попасть в одно и то же место – на работу (сетевую среду). Diameter обеспечивает общий ААА и структуру безопасности, в рамках которой могут работать различные службы, как показано на Рисунке 2-15.

Рисунок 2-15. Diameter предоставляет архитектуру ААА для различных сервисов

ПРИМЕЧАНИЕ. ROAMOPS (Roaming Operations) позволяет пользователям PPP получить доступ к сети Интернет без необходимости звонить своему домашнему интернет-провайдеру. Интернет-провайдер, который имеет роуминговое соглашение, выполняет перекрестную аутентификацию клиентов, что позволяет пользователю позвонить любому интернет-провайдеру по месту своего присутствия и получить доступ в Интернет.RADIUS и TACACS+ являются клиент-серверными протоколами, т.е. серверная часть не может по своей инициативе отправлять команды клиентской части. Diameter – это одноранговый (peer-based) протокол, что позволяет любой стороне инициировать взаимодействие. Функциональность позволяет серверу Diameter отправлять сообщения серверу доступа, чтобы запросить у пользователя другой набор учетных данных, если он пытается получить доступ к защищаемому ресурсу.

Diameter не является полностью обратно совместимым с RADIUS, но он предоставляет возможности для перехода с RADIUS. Diameter использует UDP и AVP, и обеспечивает поддержку работы через прокси-сервер. По сравнению с RADIUS, он лучше выявляет и исправляет ошибки, обладает повышенной отказоустойчивостью. Diameter также предоставляет сквозную (end-to-end) безопасность посредством использования IPSec или TLS, которые недоступны в RADIUS.

Diameter может предоставлять функциональность AAA другим протоколам и сервисам, поскольку имеет широкий набор AVP. RADIUS имеет 2^8 AVP, тогда как Diameter – 2^32. Как было сказано ранее в этом домене, AVP похожи на пустые строки на бланке, которые описывают как стороны могут взаимодействовать друг с другом. Поэтому, большее количество AVP позволяет обеспечить больше функциональности и сервисов для взаимодействия систем. Diameter предоставляет следующую функциональность AAA:

Аутентификация

PAP, CHAP, EAP
Защита аутентификационной информации между конечными точками
Защита от атак повтора (replay attack)

Авторизация

Перенаправление, безопасные прокси, ретрансляция (relay), посредничество (broker)
Согласование состояния
Отключение по собственной инициативе
Переавторизация по запросу

Учет

Отчетность, учет ROAMOPS (roaming operations), мониторинг событий.

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

Ссылки по теме:

Метод децентрализованного администрирования управления доступом (decentralized access control administration) передает управление доступом людям, которые непосредственно связаны с ресурсами и лучше понимают, кто должен и кто не должен иметь доступ к определенным файлам, данным и ресурсам. Обычно это функциональные руководители, которые предоставляют права доступа сотрудникам. Компании следует выбрать децентрализованную модель, если ее руководители имеют хорошее представление о том, какие пользователи к каким ресурсам должны иметь доступ, а также в компании отсутствуют требования о необходимости использования централизованной модели.

Управление доступом в децентрализованной модели может происходить быстрее, поскольку этим занимается больше людей в компании. Однако при этом может возникнуть конфликт интересов. Поскольку не один человек (подразделение) управляет всеми правами доступа, различные руководители и подразделения могут выполнять функции по управлению доступом и обеспечению безопасности различными способами. Это не позволит обеспечить унификацию и справедливость в рамках всей компании. Одни руководители будут слишком заняты своими ежедневными задачами и легко позволят кому угодно получить полный доступ ко всем системам своего подразделения. Другие подразделения, напротив, будут применять строгие и детальные методы управления, предоставляя сотрудникам только тот уровень доступа, который необходим им для выполнения своих задач. Кроме того, в некоторых случаях функции управления доступом будут накладываться друг на друга, что может стать причиной того, что некоторые нежелательные действия не будут запрещены и заблокированы. Если Майк, входящий в группу бухгалтерии, был заподозрен в несанкционированном изменении информации о заработной плате персонала, руководитель бухгалтерии может ограничить его доступ к соответствующим файлам правами «только чтение». Однако руководитель бухгалтерии не делает этого, и Майк продолжает иметь к этим файлам полный доступ в рамках сетевой группы, членом которой он является. Таким образом, метод децентрализованного администрирования не обеспечивает целостного управления и достаточного уровня согласованности в процессе защиты компании. Например, если Шон уволен с работы за просмотр порнографии на своем рабочем компьютере, руководитель соответствующей группы, в которую входит Шон, может не заблокировать его учетную запись, и у Шона после увольнения останутся права доступа. Это может привести к серьезным проблемам у компании, если Шон захочет отомстить.

dorlov.blogspot.com

RADIUS - это... Что такое RADIUS?

RADIUS (англ. Remote Authentication in Dial-In User Service) — протокол для реализации аутентификации, авторизации и сбора сведений об использованных ресурсах, разработанный для передачи сведений между центральной платформой и оборудованием. Этот протокол применялся для системы тарификации использованных ресурсов конкретным пользователем/абонентом. Центральная платформа и оборудование Dial-Up доступа (NAS[1] с системой автоматизированного учёта услуг (биллинга),

RADIUS используется как протокол AAA:

англ. Authentication — процесс, позволяющий аутентифицировать (проверить подлинность) субъекта по его идентификационным данным, например, по логину (имя пользователя, номер телефона и т. д.) и паролю.
англ. Authorization — процесс, определяющий полномочия идентифицированного субъекта на доступ к определённым объектам или сервисам.
англ. Accounting — процесс, позволяющий вести сбор сведений (учётных данных) об использованных ресурсах. Первичными данными (то есть, традиционно передаваемых по протоколу RADIUS) являются величины входящего и исходящего трафиков: в байтах/октетах (с недавних пор в гигабайтах). Однако протокол предусматривает передачу данных любого типа, что реализуется посредством VSA (Vendor Specific Attributes).

История

Протокол RADIUS был разработан Карлом Ригни (Carl Rigney) в фирме Livingston Enterprises для их серверов доступа (Network Access Server) серии PortMaster к сети интернет, и позже, в 1997, был опубликован как RFC 2058 и RFC 2059 (текущие версии RFC 2865 и RFC 2866). На данный момент существует несколько коммерческих и свободно распространяемых (open-source) RADIUS-серверов. Они несколько отличаются друг от друга по своим возможностям, но большинство поддерживает списки пользователей в текстовых файлах, LDAP, различных базах данных. Учетные записи пользователей могут храниться в текстовых файлах, различных базах данных, или на внешних серверах. Часто для удаленного мониторинга используется SNMP. Существуют прокси-серверы (proxy/forwarding) для RADIUS, упрощающие централизованное администрирование и/или позволяющие реализовать концепцию интернет-роуминга (internet roaming). Они могут изменять содержимое RADIUS-пакета на лету (в целях безопасности или для выполнения преобразования между диалектами). Популярность RADIUS-протокола, во многом объясняется: открытостью к наполнению новой функциональностью при сохранении работоспособности с устаревающим оборудованием, чрезвычайно высокой реактивностью при обработке запросов ввиду использования UDP в качестве транспорта пакетов, а также хорошо параллелизуемым алгоритмом обработки запросов; способностью функционировать в кластерных (Cluster) архитектурах (например OpenVMS) и мультипроцессорных (SMP) платформах (DEC Alpha, HP Integrity) — как с целью повышения производительности, так и для реализации отказоустойчивости.

В настоящее время (с середины 2003-го года) разрабатывается протокол DIAMETER (текущие версии RFC 3588 и RFC 3589), который призван заменить RADIUS, оставшись обратно совместимым с ним.

Возможности

Будучи частью биллинговой системы RADIUS-сервер является интерфейсом взаимодействия с телекоммуникационной системой/сервером (например маршрутизатором или коммутатором) и может реализовывать для такой системы следующие сервисы:

Общие

Создание и хранение учётных записей пользователей (абонентов)
Управление учётной записью пользователя (абонента) из персонального интерфейса (например веб-кабинета)
Создание карточек доступа (логин/PIN-код) для предоставления услуг, с некоторым лимитом действия (Dial-Up доступа в Интернет и карточной IP-телефонии)
Ручная и автоматическая блокировка учётной записи абонента по достижению заданного критерия или лимита
Сбор и анализ статистической информации о сессиях пользователя и всей обслуживаемой системы (в том числе CDR)
Создание отчётов по различным статистическим параметрам
Создание, печать и отправка счетов к оплате
Аутентификация всех запросов в RADIUS-сервер из обслуживаемой системы (поле Secret)

Аутентификация

Проверка учётных данных пользователя (в том числе шифрованных) по запросу обслуживаемой системы

Авторизация

Выдача состояния блокировки учётной записи пользователя
Выдача разрешения к той или иной услуге
Сортировка данных на основе анализа статистической информации (например динамическая маршрутизация) и выдача результата сортировки по запросу

Учёт (Accounting)

Онлайн-учёт средств абонента: уведомления о начале и конце сессии со стороны обслуживаемой системы
Промежуточные сообщения о продолжении сессии (Interim-пакеты)
Автоматическое принудительное завершение действия сессии на обслуживаемой системе в рамках услуги (packet of disconnection)
BOOT message — специальный пакет, который отправляется телекоммуникационной системой на RADIUS-сервер при запуске (перезапуске) системы, с целью принудительного завершения всех сессий

Стандарты

Определён в

RFC 2865 Remote Authentication Dial In User Service (RADIUS)
RFC 2866 RADIUS Accounting

Также имеет отношение к

RFC 2548 Microsoft Vendor-specific RADIUS Attributes
RFC 2607 Proxy Chaining and Policy Implementation in Roaming
RFC 2618 RADIUS Authentication Client MIB
RFC 2619 RADIUS Authentication Server MIB
RFC 2620 RADIUS Accounting Client MIB
RFC 2621 RADIUS Accounting Server MIB
RFC 2809 Implementation of L2TP Compulsory Tunneling via RADIUS
RFC 2867 RADIUS Accounting Modifications for Tunnel Protocol Support
RFC 2868 RADIUS Attributes for Tunnel Protocol Support
RFC 2869 RADIUS Extensions
RFC 2882 Network Access Servers Requirements: Extended RADIUS Practices
RFC 3162 RADIUS and IPv6
RFC 3575 IANA Considerations for RADIUS
RFC 3576 Dynamic Authorization Extensions to RADIUS
RFC 4672 RADIUS Dynamic Authorization Client MIB
RFC 4673 RADIUS Dynamic Authorization Server MIB
RFC 3579 RADIUS Support for EAP
RFC 3580 IEEE 802.1X RADIUS Usage Guidelines
RFC 4014 RADIUS Attributes Suboption for the DHCP Relay Agent Information Option

См. также

Примечания

dic.academic.ru

6. Администрирование доступа

Итак, после того как компания разработала политику безопасности, а также поддерживающие ее процедуры, стандарты и руководства,она должна выбрать тип модели управления доступом: DAC, MAC или ролевое.

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

матрицы контроля доступа,
ограниченные интерфейсы,
контекстно- или контентно-зависимое управление,
управление на основе правил.

Если среда не требует высокого уровня безопасности, компании следует выбрать дискреционную или ролевую модель.

Модель DAC позволяет владельцам данных управлять доступом пользователей к своим ресурсам, поэтому компания должна полностью осознавать возможные последствия, выбирая эту модель.

Если в компании большая «текучесть» кадров и/или требуется более централизованный метод управления доступом, целесообразно выбрать ролевую модель.

Если среда требует более высокого уровня безопасности, и в ней только администратор должен иметь возможность предоставления доступа к ресурсам, тогда наилучшим выбором будет модель МАС.

Теперь осталось определить, как компания будет администрировать выбранную модель управления доступом.

Существует два основных варианта администрирования управления доступом: централизованный и децентрализованный.

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

6.1. Централизованное администрирование управления доступом

При централизованном администрировании доступа (centralized access control administration) один субъект (человек или подразделение) следит за доступом ко всем корпоративным ресурсам.

Этот субъект (администратор безопасности) настраивает механизмы, которые реализуют управление доступом:

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

Этот тип администрирования предоставляет последовательные и унифицированные методы управления правами доступа пользователей.

Он обеспечивает строгий контроль данных, т.к. только один человек (или подразделение) имеет необходимые права для изменения профилей доступа и разрешений.

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

Традиционные протоколы аутентификации:

PAP (password authentication protocol),
CHAP (challenge handshake authentication protocol)
EAP (extensible authentication protocol).

6.1.1. Radius

Для подключения удаленных пользователей, в сети должны быть установлены серверы доступа и средства для удаленного подключения:

(например, модемный пул, DSL, ISDN или линия Т1).

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

Сервер доступа и программное обеспечение клиента «договариваются» о протоколе аутентификации, который они будут использовать (PAP, CHAP или EAP), посредством процедуры «рукопожатия» (handshake), после чего клиент передает серверу доступа свое имя пользователя и пароль. Это взаимодействие происходит через соединение PPP.

Взаимодействие сервера доступа с RADIUS-сервером осуществляется по протоколу RADIUS.

Сервер доступа уведомляет RADIUS-сервер о фактах начала и окончания сеанса в целях предоставленных тарификации услуг (биллинга - расчётные операции, информационное обслуживание, финансовое обслуживание). RADIUS также используется в корпоративных средах, чтобы обеспечить доступ к корпоративной сети сотрудникам во время командировок или из дома. RADIUS позволяет компаниям хранить профили пользователей в централизованной базе данных. После успешной аутентификации, внешнему пользователю присваивается предварительно настроенный профиль, определяющий к каким ресурсам он может получить доступ, а к каким – нет. Эта технология позволяет компании иметь единую управляемую точку входа, что обеспечивает стандартизацию с точки зрения безопасности и предоставляет простой способ контроля использования удаленного доступа и сбора сетевой статистики. RADIUS был разработан компанией Livingston Enterprises для своей серии серверов доступа, но затем был опубликован в виде стандартов RFC 2865 и RFC 2866. Это открытый протокол, который может использовать любой производитель в своих продуктах. Конфигурации и учетные данные пользователей могут храниться на серверах LDAP, в различных базах данных или текстовых файлах. Рисунок 4 показывает некоторые примеры возможных реализаций RADIUS.

Рисунок 4. В различных средах инфраструктура RADIUS может быть реализована по-разному

studfiles.net

Информационные технологии - Лекция 4 Сервер политики сети: RADIUS-сервер, RADIUS-прокси и сервер политик защиты

Тема: Сервер политики сети: RADIUS-сервер, RADIUS-прокси и сервер политик защиты доступа к сети

Введение

Windows Server 2008 и Windows Server 2008 R2 —высокотехнологичные операционные системы Windows Server, разработанные, чтобы дать начало новому поколению сетей, приложений и веб-служб. С помощью этих операционных систем можно разрабатывать, доставлять и управлять гибким и всеобъемлющим взаимодействием с пользователями и приложениями, создавать сетевые инфраструктуры с высоким уровнем безопасности и увеличивать технологическую эффективность и организованность в своей организации.

Сервер сетевых политик

Сервер политики сети позволяет создавать и применять политики доступа к сети на уровне организации для обеспечения работоспособности клиентов, а также выполнения проверки подлинности и авторизации запросов на подключение. Кроме того, сервер политики сети можно использовать в качестве RADIUS-прокси для перенаправления запросов на подключение на сервер политики сети или другие RADIUS-серверы, настроенные в группах удаленных RADIUS-серверов.

Сервер политики сети позволяет централизованно настраивать политики проверки подлинности, авторизации и работоспособности клиента при предоставлении доступа к сети и управлять этими политиками с помощью следующих трех возможностей:

• RADIUS server. Сервер политики сети централизованно выполняет проверку подлинности, авторизацию и учет для беспроводных подключений, подключений по коммутаторам с проверкой подлинности, подключений удаленного доступа и подключений по виртуальной частной сети (VPN). При использовании сервера политики сети в качестве RADIUS-сервера, серверы доступа к сети, такие как точки беспроводного доступа и VPN-серверы, настраиваются как RADIUS-клиенты на сервере политики сети. Кроме того, настраиваются политики сети, используемые сервером политики сети для авторизации запросов на подключение. В дополнение к этому можно настроить RADIUS-учет, чтобы данные заносились сервером политики сети в файлы журнала, хранящиеся на локальном жестком диске или в базе данных Microsoft SQL Server.

• RADIUS proxy. Если сервер политики сети используется в качестве RADIUS-прокси, необходимо настроить политики запросов на подключение, которые определяют, какие запросы на подключение сервер политики сети будет перенаправлять на другие RADIUS-серверы, а также на какие конкретно RADIUS-серверы будут перенаправляться эти запросы. На сервере политики сети можно также настроить перенаправление учетных данных для их хранения на одном или нескольких компьютерах в группе удаленных RADIUS-серверов.

• Network Access Protection (NAP) policy server. Если сервер политики сети настроен в качестве сервера политик защиты доступа к сети, сервер политики сети оценивает состояния работоспособности, направляемые клиентскими компьютерами с поддержкой защиты доступа к сети, которые пытаются подключиться к сети. Сервер сетевых политик, на котором настроена защита доступа к сети, выступает в качестве RADIUS-сервера, выполняя проверку подлинности и авторизацию запросов на подключение. На сервере политики сети можно настроить политики и параметры защиты доступа к сети, в том числе устройства проверки работоспособности системы, политику работоспособности и группы серверов обновлений, которые обеспечивают обновление конфигурации клиентских компьютеров в соответствии с сетевой политикой организации.

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

RADIUS-сервер и RADIUS-прокси

Сервер политики сети может использоваться в качестве RADIUS-сервера, RADIUS-прокси или обоих этих устройств одновременно.

RADIUS-сервер

Сервер политики сети Майкрософт реализован в соответствии со стандартом RADIUS, описанным в документах IETF RFC 2865 и RFC 2866. В качестве RADIUS-сервера сервер политики сети централизованно выполняет проверку подлинности, авторизацию и учет подключений для разных типов доступа к сети, включая беспроводной доступ, коммутирование с проверкой подлинности, удаленный доступ и доступ к VPN, а также подключения между маршрутизаторами.

Сервер политики сети позволяет использовать разнородный набор оборудования для беспроводного доступа, удаленного доступа, сетей VPN и коммутирования. Сервер политики сети можно использовать со службой маршрутизации и удаленного доступа, которая доступны в операционных системах Microsoft Windows 2000 Windows Server 2003, Standard Edition, Windows Server 2003, Enterprise Edition и Windows Server 2003, Datacenter Edition.

Если компьютер с сервером политики сети является членом домена Active Directory®, сервер политики сети использует эту службу каталогов в качестве базы данных учетных записей пользователей и является частью решения для единого входа. Тот же набор учетных данных используется для управления доступом к сети (проверка подлинности и авторизация доступа к сети) и для входа в домен Active Directory.

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

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

RADIUS-прокси

В качестве RADIUS-прокси сервер политики сети перенаправляет сообщения проверки подлинности и учета на другие RADIUS-серверы.

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

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

• Беспроводной доступ

• Подключение удаленного доступа или виртуальной частной сети в организации.

• Удаленный доступ или беспроводной доступ, обеспечиваемый внешней организацией

• Доступ к Интернету

• Доступ с проверкой подлинности к ресурсам внешней сети для деловых партнеров

Примеры конфигураций RADIUS-сервера и RADIUS-прокси

В следующих примерах конфигурации демонстрируется настройка сервера политики сети в качестве RADIUS-сервера и RADIUS-прокси.

NPS as a RADIUS server. В этом примере сервер политики сети настроен как RADIUS-сервер, единственной настроенной политикой является установленная по умолчанию политика запросов на подключение, а все запросы на подключение обрабатываются локальным сервером политики сети. Сервер политики сети может выполнять проверку подлинности и авторизацию пользователей, учетные записи которых находятся в домене данного сервера или в доверенных доменах.

NPS as a RADIUS proxy. В этом примере сервер политики сети настроен как RADIUS-прокси, который перенаправляет запросы на подключение в группы удаленных RADIUS-серверов в двух разных доменах без доверия. Установленная по умолчанию политика запросов на подключение удаляется, а вместо нее создаются две новые политики запросов на подключение, предусматривающие перенаправление запросов в каждый из двух доменов без доверия. В этом примере сервер политики сети не обрабатывает запросы на подключение на локальном сервере.

NPS as both RADIUS server and RADIUS proxy. В дополнение к установленной по умолчанию политике запросов на подключение, которая предусматривает локальную обработку запросов, создается новая политика запросов на подключение, предусматривающая их перенаправление на сервер политики сети или другой RADIUS-сервер, находящийся в домене без доверия. Вторая политика имеет имя Прокси. В данном примере политика "Прокси" отображается первой в упорядоченном списке политик. Если запрос на подключение соответствует политике "Прокси", данный запрос на подключение перенаправляется на RADIUS-сервер в группе удаленных RADIUS-серверов. Если запрос на подключение не соответствует политике "Прокси", но соответствует установленной по умолчанию политике запросов на подключение, сервер политики сети обрабатывает данный запрос на подключение на локальном сервере. Если запрос на подключение не соответствует ни одной из этих политик, он отклоняется.

NPS as a RADIUS server with remote accounting servers. В этом примере локальный сервер политики сети не настроен на ведение учета, а установленная по умолчанию политика запросов на подключение изменена таким образом, чтобы RADIUS-сообщения учета перенаправлялись на сервер политики сети или иной RADIUS-сервер в группе удаленных RADIUS-серверов. Несмотря на то, что сообщения учета перенаправляются, сообщения проверки подлинности и авторизации не перенаправляются, а соответствующие функции для локального домена и всех доверенных доменов осуществляются локальным сервером политики сети.

NPS with remote RADIUS to Windows user mapping. В этом примере сервер политики сети выступает как в качестве RADIUS-сервера, так и в качестве RADIUS-прокси для каждого отдельного запроса на подключение, перенаправляя запрос на проверку подлинности на удаленный RADIUS-сервер и одновременно выполняя авторизацию с использованием локальной учетной записи пользователя Windows. Такая конфигурация реализуется путем установки атрибута Сопоставление удаленного сервера RADIUS пользователю Windows в качестве условия политики запросов на подключение. (Кроме того, на RADIUS-сервере необходимо создать локальную учетную запись пользователя с тем же именем, что и удаленная учетная запись, по которой будет выполняться проверка подлинности удаленным RADIUS-сервером.)

Сервер политики защиты доступа к сети

Компонент защиты доступа к сети включен в Windows Vista®, Windows® 7, Windows Server® 2008 и Windows Server® 2008 R2. Он помогает обеспечить защиту доступа к частным сетям, гарантируя соответствие параметров клиентских компьютеров действующим в сети организации политикам работоспособности при разрешении этим клиентам доступа к сетевым ресурсам. Кроме того, соответствие клиентского компьютера политике работоспособности, определяемой администратором, отслеживается компонентом защиты доступа к сети в период, когда этот компьютер подключен к сети. Благодаря возможности автоматического обновления защиты доступа к сети может выполняться автоматическое обновление несоответствующих компьютеров в соответствии с политикой работоспособности, что позволяет впоследствии предоставить им доступ к сети.

Системные администраторы определяют политики работоспособности сети и создают эти политики с использованием компонентов защиты доступа к сети, которые доступны на сервере политики сети или поставляются другими компаниями (в зависимости от реализации защиты доступа к сети).

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

seti.ucoz.ru