03. 802.1x – документация – nag wiki

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

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

  • авторизация;
  • проверка подлинности.

Основные концепции 802.1x:

Режим аутентификации:

  • На основе интерфейса
  • На основе MAC

метод проверки:

  • Завершение EAP
  • Прозрачная передача EAP

Режим управления портом:

  • Автоматическая идентификация (авто): указывает, что начальное состояние порта является неавторизованным, разрешая отправку и получение только сообщений EAPOL и не разрешая пользователям доступ к сетевым ресурсам; если аутентификация пройдена, порт переключится в авторизованное состояние, позволяя пользователям получать доступ к сетевым ресурсам. Это тоже самая распространенная ситуация.
  • Обязательная авторизация (authorized-force): Указывает, что порт всегда находится в авторизованном состоянии, что позволяет пользователям получать доступ к сетевым ресурсам без аутентификации и авторизации.
  • Обязательная неавторизация (unauthorized-force): Указывает, что порт всегда находится в неавторизованном состоянии, и пользователям не разрешена аутентификация. Устройство не предоставляет услуги аутентификации клиентам, которые получают доступ через этот порт.

1. Общие сведения о 802.1x

Стандарт IEEE 802.1xопределяет метод управления доступом к сети, он управляет аутентификацией и устройствами доступа на физическом уровне (порты коммутатора). Если пользовательские устройства, подключенные к этим портам, удается аутентифицировать, они получают доступ к ресурсам локальной сети, в противном случае доступ будет запрещен.

Стандарты IEEE 802.1x определяют протокол управления доступом к сети на основе портов. Протокол применим к соединению точка-точка между устройством доступа и портом доступа, при этом порт может быть логическим или физическим. В типичном случае один физический порт коммутатора присоединен только к одному терминирующему устройству (имеющему физические порты).

Похожее:  Личный кабинет пользователя на Wordpress

Архитектура IEEE 802.1x описана на рисунке ниже.

Рисунок 52.1 – Архитектура IEEE 802.1x

Надписи на рисунке:

  • Supplicant System – клиентская система;

  • Supplicant PAE – Порт клиентской системы;

  • Autenthicator system – система аутентификатора;

  • Autenthicator PAE – Порт аутентификатора;

  • Services offered by Autenthicator’s system – услуги, предоставляемые системой аутентификатора;

  • Controlled Port – управляемый порт;

  • Uncontrolled port – неуправляемый порт;

  • EAP protocol exchanges carried in higher layer protocol – обмен сообщениями протокола EAP происходит через протокол более высокого уровня;

  • Authentication Server system – система сервера аутентификации;

  • Authentication Server – сервер аутентификации.

802.1x имеет клиент-серверную архитектуру, которая имеет 3 составляющие: устройство, запрашивающее доступ, система аутентификации и сервер аутентификации.

  • Устройство, запрашивающее доступ представляет собой объект на одном конце сегмента сети, который должен быть аутентифицирован блоком управления доступом на другом конце сегмента сети. Пользователь запускает аутентификацию 802.1X через программное обеспечение запрашивающей системы. Система, запрашивающая доступ, должна поддерживать EAPOL;

  • Система аутентификации (в данном случае – коммутатор) представляет собой сетевое устройство, поддерживающее протокол 802.1X, к портам которого подключено устройство, запрашивающее доступ;

  • Сервер аутентификации используется для аутентификации и авторизации пользователей. Обычно это сервер RADIUS, который может хранить информацию о пользователях (имя, пароль, VLAN, порт и т.д).

Взаимодействие устройства, запрашивающего доступ, и устройства управления доступом (коммутатором доступа) происходит по протоколу EAPOL, определенного стандартами IEEE 802.1x. Взаимодействие сервера аутентификации с устройством управления доступом происходит по протоколу EAP.

Система аутентификации (коммутатор доступа) предоставляет порты для доступа к сети запрашивающим пользовательским системам. Эти порты логически можно разделить на два вида: контролируемые и неконтролируемые:

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

  • Контролируемый порт связан с состоянием аутентификации. При отсутствии аутентификации данные из запрашивающих доступ систем передаваться не могут. Данный коммутатор может осуществлять контроль только одного направления трафика.

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

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

Существует 2 режима пользовательском управлении доступом имеется два режима: стандартное управление и расширенное управление. При стандартном (standard) пользовательском управлении доступ к определенным ресурсам не ограничивается до аутентификации.

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

3.1. Гостевая VLAN

Рисунок 52.2 – Гостевая VLAN

Как показано на рисунке 52.2, для доступа в сеть коммутатор использует 802.1x и сервер RADIUS в качестве сервера аутентификации. Порт подключения пользователей на коммутаторе – Ethernet1/0/2. Сервер аутентификации находится в VLAN 2.

Сервер обновлений находится в VLAN 10, Ethernet1/0/6 – порт коммутатора, используемый для выхода в Интернет, принадлежит VLAN 5. VLAN 10 установлена как гостевая на порту Ethernet1/0/2, поэтому до аутентификации пользователя порт Ethernet1/0/2 добавлен во VLAN 10, разрешая пользователю доступ к серверу обновлений.

После того, как пользователь успешно прошел аутентификацию, коммутатор добавляет порт пользователя во VLAN5, разрешая доступ в Интернет.

Конфигурация выглядит следующим образом:

# Настроить коммутатор для работы с RADIUS:

# создать VLAN100:

# Включить функцию 802.1x

# Настроить порт Ethernet1/0/2

Архитектору безопасности на заметку

Задача данного исследования и подготовленного обзора заключается в том, чтобы предоставить Архитектору безопасности лучшие практики для реализации модели АА в разрабатываемом продукте и оставить его наедине с вопросом: «Что из этого лучше подходит к моему приложению?».

При этом, мы не исключаем, что на этот же вопрос «Что из этого лучше подходит к моему приложению?» Архитектор ответит: «Кажется, что ничего не подходит. Придется делать свою модель с блэк-джеком». И в итоге, разработанная им модель окажется в данном списке в качестве новой «best practice» — смело делай pull requests в соответствующую шпаргалку от OWASP.

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

Архитектурные модели реализации аа

Мы провели декомпозицию функций АА (если собираешься стать архитектором безопасности приложений, то добавляй сложные слова и термины в свою коллекцию – возможно, они пригодятся на совещаниях) на основе характеристик типовых микросервисных приложений и определили следующий список подфункций безопасности (Рисунок 1): пограничная авторизация (edge-level authorization), авторизация на уровне сервиса (service-level authorization), пробрасывание идентификатора внешнего субъекта (external entity identity propagation), межсервисная аутентификация (service-to-service authentication). Затем мы рассмотрели основные электронные базы данных и библиотеки, а также стандарты безопасности и презентации на основных конференциях по безопасности с целью выявления существующих архитектурных схем.
image
Рисунок 1. Подфункции аутентификации и авторизации в системах на базе микросервисов

Разберем основные модели и их схемы.

В простом сценарии авторизация может происходить только на пограничном уровне (при помощи шлюза API). Шлюз API можно использовать в качестве центра авторизации для всех последующих микросервисов, исключая необходимость обеспечения аутентификации и контроля доступа для каждого отдельного микросервиса.

Однако авторизация на пограничном уровне имеет следующие недостатки:

Децентрализованный шаблон

В этом шаблоне команда разработчиков реализует PDP и PEP непосредственно на уровне кода микросервиса (рис. 3). Все правила контроля доступа, а также атрибуты, необходимые для реализации этого правила, определяются и хранятся в каждом микросервисе (шаг 1). Когда микросервис получает (шаг 2) запрос на доступ вместе с некоторыми метаданными авторизации (например, контекст конечного пользователя), микросервис анализирует его (шаг 3) для того, чтобы сгенерировать решение политики контроля доступа, а затем реализует (enforce) авторизацию (шаг 4).
image
Рисунок 3. Высокоуровневая архитектура децентрализованного шаблона

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

Соответственно, данная модель несет в себе следующие ограничения:

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

Защищаем беспроводную сеть

В различных моделях названия меню и подменю могут отличаться. Для начала нужно зайти в меню роутера и выбрать настройку беспроводной сети Wi-Fi. Указываем имя сети. Его будут видеть все беспроводные устройства, которые необходимо подключить к прибору.

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

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

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

Какую сетевую идентификацию выбрать

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

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

  • WEP;
  • WPA-персональная;
  • WPA2-персональная.

Наиболее подходящий вариант можно установить на любом роутере.

Лекция 5. протоколы сетевой аутентификации. модели разграничения доступа. вредоносное программное обеспечение. | методы и средства защиты компьютерной информации

Локальная аутентификация Windows

Локальная аутентификация в операционных системах Windows выполняется в следующей последовательности:

  1. Пользователь вводит логин и пароль
  2. Данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш. В открытом виде пароли нигде не хранятся.
  3. Служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя
  4. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля)
  5. Затем LSA сравнивает хэши, в случае их совпадения аутентификация считается успешной, а хэш введенного пароля помещается в хранилище службы LSA и до окончания сеанса пользователя
    Схема работы локальной аутентификации Windows

Рис. 1. Схема работы локальной аутентификации Windows

Протоколы сетевой аутентификации

Существует несколько различных протоколов, описывающих процесс аутентификации субъектов в локальной сети. В рамках операционных систем Windows компании Микрософт использовались протоколы:

  • LAN Manager (LM),
  • NT LAN Manager (NTLM),
  • NT LAN Manager версии 2 (NTLM v2)

Рассмотрим актуальные на данный момент протоколы аутентификации – NTLM v2 и Kerberos.

Протокол NTLM v2.

Схема работы протокола NTLMv2 с контроллером домена

  1. Клиент при обращении к серверу сообщает ему имя пользователя и имя домена
  2. Сервер передает ему случайное число – запрос сервера
  3. Клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента
  4. Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш
  5. От данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу
  6. Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена (КД)
  7. КД извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом
  8. В случае совпадения серверу возвращается ответ об успешной аутентификации.
    Схема работы протокола NTLMv2 с контроллером домена

Рис. 2. Схема работы протокола NTLMv2 с контроллером домена

Протокол аутентификации Kerberos

Протокол Kerberos был специально разработан для обеспечения надежной аутентификации пользователей. Он может использовать централизованное хранение аутентификационных данных и является основой для построения механизмов Single Sign-On (возможность одноразовой аутентификации в нескольких приложениях). Протокол Kerberos предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними с учетом того, что начальный обмен информацией между клиентом и сервером может происходить в незащищённой среде, а передаваемые пакеты – перехвачены и модифицированы.

Протокол использует понятие Ticket (билет, удостоверение).

Ticket является зашифрованным пакетом данных, выданным выделенным доверенным центром аутентификации, в терминах протокола Kerberos – KDC (Key Distribution Center, центр распределения ключей).

KDC состоит из двух компонент:

  • сервер аутентификации (англ. Authentication Server, сокр. AS);
  • сервер выдачи разрешений (англ. Ticket Granting Server, сокр. TGS).

Когда пользователь выполняет первичную аутентификацию, после успешного подтверждения его подлинности KDC выдаёт первичное удостоверение пользователя для доступа к сетевым ресурсам – TGT (Ticket Granting Ticket). В дальнейшем при обращении к отдельным сетевым ресурсам пользователь, предъявляя TGT, получает от KDC удостоверение для доступа к конкретному сетевому ресурсу – Service Ticket.
Схема работы протокола Kerberos

Рис. 3.Схема работы протокола Kerberos

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

В качестве примера реализации протокола Kerberos следует отметить доменную аутентификацию пользователей в операционных системах компании Microsoft, начиная с Windows 2000.

Протоколы аутентификации для удалённого доступа

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

Такими протоколами являются:

В качестве примера кратко рассмотрим работу протокола RADIUS.

Протокол аутентификации RADIUS

Протокол аутентификации Remote Authentication Dial-in User Service (RADIUS)2 рассматривается как механизм аутентификации и авторизации удалённых пользователей в условиях распределённой сетевой инфраструктуры, предоставляющий централизованные услуги по проверке подлинности и учёту для служб удалённого доступа.

В рамках стандарта выделяются следующие роли:

Клиент RADIUS. Клиент RADIUS принимает от пользователей запросы на аутентификацию. Все принятые запросы переадресовываются серверу RADIUS для последующей аутентификации и авторизации. Как правило, в качестве клиента протокола RADIUS выступает сервер удалённого доступа.

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

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

Поддержка протокола RADIUS реализована на многих современных платформах, что позволяет использовать его в межплатформенных решениях.

В качестве примера сервера и посредника RADIUS можно привести реализованную в Windows Server 2003 службу проверки подлинности в Интернете (Internet Authentication Service, IAS). Эта служба позиционируется как механизм централизованной аутентификации и авторизации пользователей, использующих различные способы подключений к сети. Служба IAS интегрирована с другими сетевыми службами Windows Server 2003, такими, как служба маршрутизации и удалённого доступа и служба каталога Active Directory.

Авторизация – модели разграничения доступа

Для более подробного изучения механизмов авторизации рассмотрим следующие модели разграничения доступа:

  • Discretionary access control, DAC
  • Mandatory access control, MAC
  • Role-based access control, RBAC
  • Attribute-based access control, ABAC
  • Гибридные модели

Discretionary access control (дискреционная модель разграничения доступа)

  • Избирательное управление доступом
  • Для каждой пары субъект-объект задаётся перечисление допустимых разрешений (Например read, write, execute)
  • Часто объект имеет привязанного субъекта-владельца. Владелец может устанавливать разрешения для других субъектов.

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

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

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

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

Mandatory access control (мандатная модель разграничения доступа)

  • Мандатное управление доступом
  • Все субъекты и объекты ИС должны быть однозначно идентифицированы
  • Задан линейно упорядоченный набор меток секретности
  • Объекты несут метку секретности, определяя ценность содержащейся информации – уровень секретности
  • Каждому субъекту присвоена метка секретности, определяющая максимальное значение метки секретности объектов, к которым субъект имеет доступ; Метка секретности субъекта называется его уровнем доступа.

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

Так, для субъекта доступа метки, например, могут определяться в соответствии с уровнем доступа лица к информации, а для объекта доступа (собственно данные) – с уровнем секретности. Признаки конфиденциальности фиксируются в метке объекта.

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

Требования к мандатному механизму управления доступом:

  1. Каждому субъекту и объекту доступа должны сопоставляться классификационные метки, отражающие их место в соответствующей иерархии. Посредством этих меток субъектам и объектам должны назначаться классификационные уровни. Данные метки должны служить основой мандатного принципа разграничения доступа
  2. Система защиты должна реализовывать мандатный принцип контроля доступа применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов:

Рис. 4.Чтение информации в мандатной модели

Рис. 5.Запись информации в мандатной модели

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

Достоинства.

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

Недостатки.

  • Избыточности прав доступа для конкретных субъектов в пределах соответствующих уровней.

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

Role-based access control (ролевая модель разграничения доступа)

  • Управление доступом на основе ролей
  • Субъекту присваивается роль или роли
  • Выдаются разрешения заданным ролям
  • Реализует DAC и MAC
  • Может быть усложнен введением наследования ролей
  • Распространен в корпоративных приложениях
  • Пример: пользователь может подтвердить заказ, если его роль – менеджер

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

Если бизнес-правила одномерны и все действия можно распределить по ролям (бухгалтер, менеджер, администратор и т. п.), такого подхода будет достаточно. Тогда одному бизнес-правилу будет соответствовать одна роль.
Распределение ролей по бизнес правилам в ролевой моделиРаспределение ролей по бизнес правилам в ролевой модели

Рис. 6.Распределение ролей по бизнес правилам в ролевой модели

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

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

Рис. 7.Рост многомерности бизнес правил

После каждого добавления нового значения атрибута придется добавлять новые роли. То есть, если появится филиал «Г», то придется добавить новые роли, такие как «Администратор филиала «Г», «Менеджер филиала «Г», «Бухгалтер филиала «Г» и т. п., после чего присвоить всем требуемым сотрудникам новые роли. Это порождает много рутинного ручного труда.

Кроме этого, появляются и другие недостатки:

  • одно бизнес-правило «размазывается» среди множества ролей и становится неочевидным, что усложняет понимание такого правила и его поддержку;
  • начинается взрывной рост числа ролей, что значительно усложняет управление ими.

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

Рис. 8.Бизнес-правила с атрибутами, значения которых заранее не известны

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

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

Attribute-based access control (модель разграничения доступа на основе атрибутов)

  • Управление доступом на основе атрибутов
  • Субъекты и объекты наделяются атрибутами
  • Политики вычисляют условия, заданные через выражения атрибутов субъекта и объекта
  • Пример: Пользователь может подтвердить заказ, если подразделение пользователя равно подразделению, в котором создан заказ, и должность субъекта – менеджер

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

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

Можно явно выделить несколько категорий атрибутов:
Несколько категорий атрибутов

Рис. 10.Несколько категорий атрибутов

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

Простые правила описываются простыми условиями.
Пример простых бизнес правил

Рис. 11.Пример простых бизнес правил

Многомерные правила в этой модели не становятся более сложными
Пример многомерных бизнес правил

Рис. 12.Пример многомерных бизнес правил

ABAC позволяет избежать проблем, которые появляются в RBAC:

  • бизнес-правило не «размазывается» по системе, что делает его понимание и поддержку достаточно простыми;
  • не происходит взрывного роста числа условий, что упрощает их сопровождение.
  • ABAC позволяет решить проблемы, которые невозможно решить с помощью RBAC, поскольку в этом подходе нет ограничений на сложность бизнес-правил. Бизнес-правила любой сложности, в том числе с использованием заранее неизвестных атрибутов, не создают новых проблем и просты в сопровождении.

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

Рис. 13.Пример бизнес правил с применением фильтра

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


Таблица 1. Сравнение ABAC и RBAC

Сравнение ABAC и RBAC

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

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

Вредоносное программное обеспечение

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

Вредоносное ПО (malware – сокращение от malicious software) – это различные программы, которые могут наносить вред.

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

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

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

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

Признакивозможного заражения компьютера:

  • Компьютер работает медленнее, чем обычно
  • Компьютер перестает реагировать на действия пользователя или часто «зависает»
  • Компьютер «зависает» и перезагружается каждые несколько минут
  • Компьютер запускается самостоятельно, после чего отказывается работать надлежащим образом
  • Приложения на компьютере не работают корректно
  • Диски или дисководы недоступны
  • Печать не работает надлежащим образом
  • Отображаются необычные сообщения об ошибках
  • Меню или диалоговые окна отображаются искаженно

Категории угроз

Рекламные программы

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

Рекламное ПО/шпионское ПО

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

Приложение из неизвестного источника

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

Backdoor-программы

Для организации кражи данных или манипуляции с компьютером, backdoor-программа удаленного администрирования проникает в систему через черный ход, о чем пользователь, как правило, даже не догадывается. Через Интернет или ЛВС клиентская часть такой программы (Client) может управляться третьими лицами.

Файлы со скрытыми расширениями

Исполняемые файлы, скрывающие настоящие расширения файлов. Этот метод сокрытия часто используется вредоносным ПО.

Фишинг

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

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

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

Цель рассылки поддельных сообщений – обманным путем заставить потребителей предоставить указанные ниже личные сведения:

# Личное имя и имя пользователя.

# Адрес и номер телефона.

# Паспортные данные или PIN-код.

# Номер банковского счета.

# Номер дебетовой или кредитной карточки.

# Код проверки карточки (CVC) или контрольное число карточки (CVV).

# Номер социального страхования.

Программы-шутки

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

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

Обманная программа

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

Bot-сети

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

Эксплойт

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

Скрытый майнер (stealth miner, майнер-бот, ботнет)

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

Фарминг

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

Межсервисная аутентификация

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

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

Метод проверки:

Система аутентификации 802.1X использует протокол расширенной аутентификации (EAP) для реализации обмена информацией аутентификации между клиентом, устройством доступа и сервером аутентификации.Обмен сообщениями протокола EAP между объектами осуществляется следующим образом.

  1. Между клиентом и устройством доступа сообщение протокола EAP использует формат инкапсуляции EAPOL и напрямую передается в среду LAN.

  2. Между устройством доступа и сервером аутентификации (возьмем, к примеру, сервер RADIUS) сообщения протокола EAP могут взаимодействовать следующими двумя способами.

Устройство поддерживает следующие протоколы EAP: EAP-TLS, EAP-TTLS, EAP-PAP, EAP-CHAP (EAP-MD5) и EAP-PEAP.

Режим триггера аутентификации:

Процесс аутентификации 802.1X может быть инициирован клиентом или устройством доступа.. Устройство поддерживает следующие два режима триггера аутентификации.

  1. Активный режим триггера клиента: Пользователь берет на себя инициативу открыть клиент, ввести имя пользователя и пароль и отправить сообщение EAP на устройство доступа для активации аутентификации.Поддержка многоадресного режима и широковещательного режима.
  2. Активный триггерный режим устройства доступа: После того, как устройство доступа получает сообщение DHCP / ARP, отправленное пользовательским терминалом, оно активно запускает пользовательский терминал для автоматического открытия клиентского интерфейса, и пользователь вводит имя пользователя и пароль для запуска аутентификации.Поддержка многоадресного триггера и одноадресного триггера.

Результат аутентификации 802.1x:

Результатом аутентификации 802.1X является изменение статуса порта, которое не связано с согласованием и распределением IP-адресов. Это наиболее упрощенная схема реализации среди различных технологий аутентификации, но она требует, чтобы пользовательский терминал был установлен с клиентским программным обеспечением 802.1X.

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

  1. Если сервер домена AD был развернут, он может быть автоматически отправлен и установлен через AD, и пользователи об этом не знают.
  2. Если сервер домена AD не развернут, вам необходимо получить активный доступ к файловому серверу / веб-сайту, загрузить и установить его.

Цели исследования

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

На этапах разработки и внедрения программного продукта необходимо решить множество проблем безопасности. Основополагающими требованиями, над которыми ломает голову aрхитектор безопасности (Application Security Architect – роль в крупной продуктовой компании, которая еще не избавляет от технических задач Security Engineer’a, но которая уже добавляет высокоуровневые проблемы, связанные с архитектурой и процессами) и которые должны быть решены на этапе проектирования, являются аутентификация и авторизация (для краткости, АА).

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

Исследование проводится с учетом трех ключевых вопросов:

В ходе исследования мы провели обзор основных электронных библиотек научных статей, мы также просмотрели стандарты безопасности, презентации на крупных конференциях по безопасности и локальных тематических митапах (привет, OWASP Moscow Meetup).

Итогом стали следующие результаты:

Централизованная модель со встроенной точкой принятия решения

В этой модели правила контроля доступа определяются централизованно, но хранятся и оцениваются на уровне микросервисов (рисунок 5). Правила контроля доступа определяются с помощью PAP (шаг 1) и доставляются во встроенную PDP вместе с атрибутами субъектов и объектов доступа, которые необходимы для использования этих правил (шаг 2). Когда субъект вызывает микросервиса (шаг 3), код микросервиса вызывает PDP, а PDP генерирует решение политики контроля доступа, оценивая входной запрос по правилам и атрибутам контроля доступа (шаг 4). На основе решения PDP микросервис применяет авторизацию (шаг 5).
image
Рисунок 5 Высокоуровневая архитектура централизованной модели со встроенной PDP

PDP код в этом случае может быть реализован как встроенная библиотека микросервиса или «sidecar-прокси». Sidecar обрабатывают коммуникации между сервисами, производят мониторинг и устраняют проблемы безопасности, то есть все, что может быть абстрагировано от отдельных сервисов, подробнее можно почитать тут.

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

Основное отличие от “централизованного шаблона с единой точкой принятия решения” с подходом к кэшированию заключается в том, что решения по авторизации не хранятся на стороне микросервиса, вместо этого на стороне микросервиса хранится актуальная политика авторизации.

В выступлении “How Netflix Is Solving Authorization Across Their Cloud” представлен практический пример применения шаблона “Централизованную модель со встроенной PDP” для реализации авторизации на уровне микросервисов (рисунок 6):

Преимущества этих шаблонов такие же, как и для “Централизованных шаблонов с одним PDP”. Кроме того, шаблон не сильно влияет на задержки в обслуживании сетевых запросов из-за встраивания PDP на уровне микросервисов.

Существует несколько проблем, которые необходимо учитывать при применении этой модели:

  • этот шаблон опирается на ручные или полуручные правила политики доступа, разработанные командой безопасности, которые могут быть подвержены ошибкам — во избежание уязвимостей конфигурации необходимо применять методы тестирования и верификации безопасности;
  • архитекторы безопасности приложений должны комбинировать его с другими шаблонами (например, авторизация на пограничном уровне), чтобы избежать наличия единой точки принятия решений и обеспечить соблюдение принципа “эшелонированной обороны”;
  • может случиться так, что некоторые специфические для бизнеса правила контроля доступа не могут быть реализованы таким образом — архитекторы безопасности приложений должны комбинировать этот шаблон с “Децентрализованным шаблоном”;
  • архитекторы безопасности приложений должны выбрать подход, как получать обновления политик авторизации из централизованных PAP (например, опрос PAP или механизм публикации-подписки);
  • команда разработчиков должна безопасно использовать сторонние компоненты авторизации и описывать политику контроля доступа, используя некий формальный язык, который в некоторых случаях может быть накладным — “Децентрализованный шаблон” может быть достаточным для реализации некоторой простой политики контроля доступа.

Централизованный шаблон с единой точкой принятия решения

В этой модели правила контроля доступа определяются, хранятся и оцениваются централизованно (рисунок 4). Правила контроля доступа определяются с помощью PAP (шаг 1) и доставляются в централизованную PDP вместе с атрибутами субъектов и объектов доступа, которые необходимы для использования этих правил (шаг 2).

Когда субъект вызывает микросервис (шаг 3), код микросервиса вызывает централизованный PDP через сетевой вызов, а PDP генерирует решение политики контроля доступа, оценивая входной запрос по правилам и атрибутам контроля доступа (шаг 4). На основе решения PDP микросервис реализует авторизацию (шаг 5).

image
Рисунок 4. Высокоуровневая архитектура централизованного шаблона с единой PDP

Некоторыми преимуществами этой схемы являются:

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

Для определения правил контроля доступа команда разработчиков и DevOps-инженеров должна использовать язык или нотацию. Примером может служить язык разметки Extensible Access Control Markup Language (XACML) и Next Generation Access Control (NGAC), который является стандартом для реализации описания правил политики.

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

Следует отметить, что PDP должен работать в режиме высокой доступности из-за возможных проблем с отказоустойчивостью. Архитекторы безопасности приложений должны комбинировать его с другими шаблонами (например, авторизация на уровне шлюза API), чтобы избежать наличия единой точки принятия решений и обеспечить соблюдение принципа “эшелонированной обороны”.

Часть плана настройки коммутатора:

Часть переключателя: 
 Шаг 1. Определите службу радиуса и AAA
 Определить радиус
radius-server template dot1x_radius_server-------------Определить шаблон сервера радиуса
 radius-server shared-key simple Huawei@123------------Link server установка пароля
 radius-server authentication 192.168.1.1001812-----------Установите аутентифицированный порт
 radius-server accounting 192.168.1.1001813----------------Установить порт биллинга
radius-server authorization 192.168.1.100 shared-key simple Huawei@123------Авторизация необязательна 

aaa
 authentication-scheme dot1x_auth
  authentication-mode radius              
 accounting-scheme dot1x_acco
  accounting-mode radius
 domain default
  authentication-scheme dot1x_auth
  accounting-scheme dot1x_acco
  radius-server  dot1x_radius_server

 Шаг 2. Настройте dot1x
dot1x  enable ------------Включить функцию dot1x глобально

dot1x authentication-method eap  ---------dot1x метод аутентификации eap

int  xxx
dot1x enable  ----------Открыть dot1x

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *