Как расшифровывается ааа протокол

Обновлено: 30.06.2024

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

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


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

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



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

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.


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

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), мониторинг событий.

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

        RADIUS
        Communications protocol
        Purpose Обеспечивает централизованную аутентификацию, авторизацию и учёт пользователей, подключающихся к различным сетевым службам
        Developer(s) Carl Rigney, Livingston Enterprises
        Introduced 1991 ; 30 years ago ( 1991 )
        Based on TCP, UDP
        OSI layer Application layer
        Port(s) 1812, 1813
        RFC(s) RFC 2548, RFC 2809, RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869, RFC 2882, RFC 3162

        RADIUS — сетевой протокол, предназначенный для обеспечения централизованной аутентификации, авторизации и учёта пользователей, подключающихся к различным сетевым службам. Используется, например, при аутентификации пользователей WiFi, VPN, в прошлом, dialup-подключений, и других подобных случаях. [Источник 1]

        Содержание

        Создание RADIUS

        Протокол RADIUS был разработан Карлом Ригни (Carl Rigney) в фирме Livingston Enterprises для их серверов доступа (Network Access Server) серии PortMaster к сети интернет. На данный момент существует несколько коммерческих и свободно распространяемых RADIUS-серверов. Они несколько отличаются друг от друга по своим возможностям, но большинство поддерживает списки пользователей в текстовых файлах и различных базах данных. Учётные записи пользователей могут храниться в текстовых файлах, различных базах данных, или на внешних серверах. Существуют прокси-серверы для RADIUS, упрощающие централизованное администрирование и/или поз-воляющие реализовать концепцию интернет-роуминга. Популярность RADIUS-протокола, во многом объясняется: открытостью к наполнению новой функциональностью при сохранении работоспособности с устаревающим оборудованием, чрезвычайно высокой реактивностью при обработке запросов ввиду использования UDP в качестве транспорта пакетов, а также хорошо параллелизуемым алгоритмом обработки запросов; способностью функционировать в кластерных, архитектурах и мультипроцессорных платформах — как с целью повышения производительности, так и для реализации отказоустойчивости. [Источник 2]

        Назначение

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

        Аутентификация (Authentication) — процесс, позволяющий аутентифицировать (проверить подлинность) субъекта по его идентификационным данным, например, по логину (имя пользователя, номер телефона и т. д.) и паролю;

        Авторизация

        Авторизация (Authorization)— процесс, определяющий полномочия идентифицированного субъекта, конкретного пользователя на доступ к определённым объектам или сервисам.

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

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

        Свойства RADIUS

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

        1. Создание и хранение учётных записей пользователей или абонентов;
        2. Управление учётной записью пользователя из персонального интерфейса, например, веб-кабинета;
        3. Создание карточек доступа (логин/PIN-код) для предоставления услуг, с некоторым лимитом действия (Dial-Up доступа в Интернет и карточной IP-телефонии);
        4. Ручная и автоматическая блокировка учётной записи абонента по достижению заданного критерия или лимита;
        5. Сбор и анализ статистической информации о сессиях пользователя и всей обслуживаемой системы;
        6. Создание отчётов по различным статистическим параметрам;
        7. Создание, печать и отправка счетов к оплате;
        8. Аутентификация всех запросов в RADIUS-сервер из обслуживаемой системы;

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

        Ограничения RADIUS

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

        Механизм работы

        Как уже упоминалось, RADIUS — прикладной протокол. На транспортном уровне используется протокол UDP, порты: 1812 и 1813.

        Общая структура сети

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


        Структура пакета

        Общая структура RADIUS-пакета имеет вид:


        Код показывает тип операции, к которой принадлежит данный код. Так, выделяют следующие коды:

        Код Операция
        1 Access-Request
        2 Access-Accept
        3 Access-Reject
        4 Accounting-Request
        5 Accounting-Response
        11 Access-Challenge
        12 Status-Server (экспериментальная возможность)
        13 Status-Client (экспериментальная возможность)
        255 Зарезервировано

        Тип (8 бит) Длина (8 бит) Значение

        Поле типа служит для указания атрибута, содержащегося в пакете. Выделяют 63 атрибута, в числе которых: имя пользователя и пароль (коды 1 и 2, соответственно), тип сервиса (6), ответ сервера (18), состояние RADIUS-прокси (33), состояние учета (40) и задержка учета (41) и т.д.
        Длина указывает размер значения атрибута, которое непосредственно содержится в последнем поле.

        Аутентификация и авторизация

        Правильность аутентификационных данных может проверяться с по-мощью разных схем аутентификации: PAP, EAP или CHAP. Процедура обмена в рамках операций учета описана в RFC 2086. При подключении клиент посылает серверу запрос обслуживания (Accounting-Request), содержащий параметр acct_type=start. Это является сигналом к началу оказания услуг учета и контроля. В ответ на этот запрос клиенту высылается его уникальный идентификатор в сети, идентификатор сессии и сетевой адрес.
        В ходе работы клиент периодически отправляет серверу запрос со значением acct_type=interim_update , что является сигналом к тому, что клиент все еще использует ресурс и операции учета необходимо продолжать. Данный запрос обычно содержит текущую продолжительность сессии и объем переданных данных. По окончании работы в сети, после отключения клиента от NAS, на сервер посылается запрос с параметром acct_type=stop, что означает прекращение работы и окончание предоставления услуг учета. Этот пакет запроса может содержать в себе такие данные, как продолжительность сессии, количество переданных пакетов и объем пересланных данных. В ответ на каждый запрос подобного рода сервер высылает подтвер-ждение (Accounting-Response), гарантирующее дальнейший доступ клиента к ресурсу. Если запрос не получит подтверждения с первого раза, через некоторое время будет произведена попытка повторного запроса — и так, вплоть до получения отклика или принятия решения о недоступности сервера.

        Защищенность

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

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

        Этот недостаток устранен в протоколе RadSec, который, будучи основан на RADIUS содержит ряд улучшений безопасности.

        Пример настройки Radius

        Начнём с того, что создадим в домене две локальных группы безопасности с ограниченными и полными правами Radius.

        Создание группы с полными правами

        В первую группу включим пользователей которым нужно предоставить полный административный доступ на управление коммутаторами, во вторую соответственно, — доступ только на чтение текущей конфигурации и состояния устройств. При этом, стоит помнить, что для пользователей, которые будут включаться в эти группы должно быть установлено разрешение в домене, дающее право удалённого доступа (значение настройки Network Access Permission на закладке Dial-In свойств учетной записи пользователя) [Источник 4]


        В первую очередь стоит знать, что все эти А-ААА-АААА! — буквы чисто экономические. Когда геймдев только набирал обороты, а в студиях сидело по дюжине сотрудников, в финансовых отчётах цена разработки оценивалась тремя категориями — A, B или C.


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

        ААА!


        — A lot of time (много времени);

        — A lot of resources (много ресурсов);

        — A lot of money (много денег).

        Получившийся Много-Много-Много ни в коем случае не является расшифровкой triple-A, однако хорошо выражает его суть. ААА-игра предполагает гигантские затраты на производство и маркетинг. Например, бюджет Grand Theft Auto V оценивается в 265 миллионов долларов. Естественно, подобные суммы связаны с экономическими рисками, и чтобы проект отбил хотя бы себестоимость, распродать нужно огромное количество копий. Схожая история происходит с блокбастерами в киноиндустрии.


        Стандарты ААА менялись со временем. Современный triple-A и triple-A времён Playstation 1 — это абсолютно разные проекты, с абсолютно разными бюджетами и временем производства. Сегодня разработка ААА в среднем занимает от 30 месяцев, над ним работает около сотни сотрудников, а бюджет составляет примерно 50 миллионов долларов.

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

        Triple-A проект, это, по сути, игра высоких ожиданий. В нёе были вложены большие средства, про неё хорошо отозвался ваш любимый блогер, а от трейлера с E3 у вас потекли слюнки. На всё это у игры хватило денег, и теперь вы ожидаете от неё качества. Но оно не обязательно случается. Иногда в релиз выходит Fallout 76.

        АААА!


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

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

        О моральной стороне вопроса рассуждать не буду, там уже всё разжевали, когда поднялась буча после выхода Star Wars Battlefront II, однако именно такой подход — стоимость AAA проекта и его поддержка различными дополнениями и обновлениями и является AAA+ или AAAA (quad-A).


        Однако, некоторые смотрят на термин quad-A с другой стороны. Как уже было упомянуто, у многих игроков в голове сложилось уравнение, где triple-A = качество, и некоторые разработчики решили этим воспользоваться. Они использовали термин AAA+, чтобы показать, что выпускаемые ими игры чем-либо выделяются среди других AAA-игр.

        АА!


        И сложно сказать, чтобы Блезински наврал. Как много вы сейчас можете вспомнить double-A игр? Как много игр вы вообще сможете идентифицировать как double-A? AA пытаются достичь того же уровня игрового дизайна, что и игры ААА, но, как правило, терпят неудачу в каком-нибудь балансе, графике, или дизайне уровней. Так и получается, что double-A игры с самым высоким рейтингом сопоставимы с играми с самым низким рейтингом triple-A. И частенько выходит так, что по непонятным обстоятельствам эти игры являются клонами франшиз ААА, которые просто не достигли потенциала, установленного его прародителем.

        iii


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

        Заключение


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

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

        RADIUS
        Communications protocol
        Purpose Обеспечивает централизованную аутентификацию, авторизацию и учёт пользователей, подключающихся к различным сетевым службам
        Developer(s) Carl Rigney, Livingston Enterprises
        Introduced 1991 ; 30 years ago ( 1991 )
        Based on TCP, UDP
        OSI layer Application layer
        Port(s) 1812, 1813
        RFC(s) RFC 2548, RFC 2809, RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869, RFC 2882, RFC 3162

        RADIUS — сетевой протокол, предназначенный для обеспечения централизованной аутентификации, авторизации и учёта пользователей, подключающихся к различным сетевым службам. Используется, например, при аутентификации пользователей WiFi, VPN, в прошлом, dialup-подключений, и других подобных случаях. [Источник 1]

        Содержание

        Создание RADIUS

        Протокол RADIUS был разработан Карлом Ригни (Carl Rigney) в фирме Livingston Enterprises для их серверов доступа (Network Access Server) серии PortMaster к сети интернет. На данный момент существует несколько коммерческих и свободно распространяемых RADIUS-серверов. Они несколько отличаются друг от друга по своим возможностям, но большинство поддерживает списки пользователей в текстовых файлах и различных базах данных. Учётные записи пользователей могут храниться в текстовых файлах, различных базах данных, или на внешних серверах. Существуют прокси-серверы для RADIUS, упрощающие централизованное администрирование и/или поз-воляющие реализовать концепцию интернет-роуминга. Популярность RADIUS-протокола, во многом объясняется: открытостью к наполнению новой функциональностью при сохранении работоспособности с устаревающим оборудованием, чрезвычайно высокой реактивностью при обработке запросов ввиду использования UDP в качестве транспорта пакетов, а также хорошо параллелизуемым алгоритмом обработки запросов; способностью функционировать в кластерных, архитектурах и мультипроцессорных платформах — как с целью повышения производительности, так и для реализации отказоустойчивости. [Источник 2]

        Назначение

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

        Аутентификация (Authentication) — процесс, позволяющий аутентифицировать (проверить подлинность) субъекта по его идентификационным данным, например, по логину (имя пользователя, номер телефона и т. д.) и паролю;

        Авторизация

        Авторизация (Authorization)— процесс, определяющий полномочия идентифицированного субъекта, конкретного пользователя на доступ к определённым объектам или сервисам.

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

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

        Свойства RADIUS

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

        1. Создание и хранение учётных записей пользователей или абонентов;
        2. Управление учётной записью пользователя из персонального интерфейса, например, веб-кабинета;
        3. Создание карточек доступа (логин/PIN-код) для предоставления услуг, с некоторым лимитом действия (Dial-Up доступа в Интернет и карточной IP-телефонии);
        4. Ручная и автоматическая блокировка учётной записи абонента по достижению заданного критерия или лимита;
        5. Сбор и анализ статистической информации о сессиях пользователя и всей обслуживаемой системы;
        6. Создание отчётов по различным статистическим параметрам;
        7. Создание, печать и отправка счетов к оплате;
        8. Аутентификация всех запросов в RADIUS-сервер из обслуживаемой системы;

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

        Ограничения RADIUS

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

        Механизм работы

        Как уже упоминалось, RADIUS — прикладной протокол. На транспортном уровне используется протокол UDP, порты: 1812 и 1813.

        Общая структура сети

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


        Структура пакета

        Общая структура RADIUS-пакета имеет вид:


        Код показывает тип операции, к которой принадлежит данный код. Так, выделяют следующие коды:

        Код Операция
        1 Access-Request
        2 Access-Accept
        3 Access-Reject
        4 Accounting-Request
        5 Accounting-Response
        11 Access-Challenge
        12 Status-Server (экспериментальная возможность)
        13 Status-Client (экспериментальная возможность)
        255 Зарезервировано

        Тип (8 бит) Длина (8 бит) Значение

        Поле типа служит для указания атрибута, содержащегося в пакете. Выделяют 63 атрибута, в числе которых: имя пользователя и пароль (коды 1 и 2, соответственно), тип сервиса (6), ответ сервера (18), состояние RADIUS-прокси (33), состояние учета (40) и задержка учета (41) и т.д.
        Длина указывает размер значения атрибута, которое непосредственно содержится в последнем поле.

        Аутентификация и авторизация

        Правильность аутентификационных данных может проверяться с по-мощью разных схем аутентификации: PAP, EAP или CHAP. Процедура обмена в рамках операций учета описана в RFC 2086. При подключении клиент посылает серверу запрос обслуживания (Accounting-Request), содержащий параметр acct_type=start. Это является сигналом к началу оказания услуг учета и контроля. В ответ на этот запрос клиенту высылается его уникальный идентификатор в сети, идентификатор сессии и сетевой адрес.
        В ходе работы клиент периодически отправляет серверу запрос со значением acct_type=interim_update , что является сигналом к тому, что клиент все еще использует ресурс и операции учета необходимо продолжать. Данный запрос обычно содержит текущую продолжительность сессии и объем переданных данных. По окончании работы в сети, после отключения клиента от NAS, на сервер посылается запрос с параметром acct_type=stop, что означает прекращение работы и окончание предоставления услуг учета. Этот пакет запроса может содержать в себе такие данные, как продолжительность сессии, количество переданных пакетов и объем пересланных данных. В ответ на каждый запрос подобного рода сервер высылает подтвер-ждение (Accounting-Response), гарантирующее дальнейший доступ клиента к ресурсу. Если запрос не получит подтверждения с первого раза, через некоторое время будет произведена попытка повторного запроса — и так, вплоть до получения отклика или принятия решения о недоступности сервера.

        Защищенность

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

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

        Этот недостаток устранен в протоколе RadSec, который, будучи основан на RADIUS содержит ряд улучшений безопасности.

        Пример настройки Radius

        Начнём с того, что создадим в домене две локальных группы безопасности с ограниченными и полными правами Radius.

        Создание группы с полными правами

        В первую группу включим пользователей которым нужно предоставить полный административный доступ на управление коммутаторами, во вторую соответственно, — доступ только на чтение текущей конфигурации и состояния устройств. При этом, стоит помнить, что для пользователей, которые будут включаться в эти группы должно быть установлено разрешение в домене, дающее право удалённого доступа (значение настройки Network Access Permission на закладке Dial-In свойств учетной записи пользователя) [Источник 4]

        Читайте также: