Какие функции выполняет уровень mac

8.4. Функции мас-уровня и форматы кадров

В соответствии со стандартами IEEE 802 канальный уровень в локальных сетях состоит из двух подуровней — LLC и МАС. Стандарт FDDI не вводит свое определение подуровня LLC, а использует его сервисы, описанные в документе IEEE 802.2 LLC.

Подуровень МАС выполняет в технологии FDDI следующие функции:

Поддерживает сервисы для подуровня LLC.

Формирует кадр определенного формата.

Управляет процедурой передачи токена.

Управляет доступом станции к среде.

Адресует станции в сети.

Копирует кадры, предназначенные для данной станции, в буфер и уведомляет подуровень LLC и блок управления станцией SMT о прибытии кадра.

Генерирует контрольную последовательность кадра (CRC) и проверяет ее у всех кадров, циркулирующих по кольцу.

Удаляет из кольца все кадры, которые сгенерировала данная станция.

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

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

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

В данном разделе для иллюстрации работы МАС-уровня будет использоваться станция с двойным подключением и одним блоком МАС, то есть станция DA/SM. Ее внутренняя структура показана на рисунке 40.

Рис. 40. Внутренняя структура станции с двойным подключением и одним блоком МАС

В каждом блоке МАС параллельно работают два процесса: процесс передачи символов — MAC Transmit и процесс приема символов —MAC Receive.За счет этого МАС может одновременно передавать символы одного кадра и принимать символы другого кадра.

Форматы кадра и токена

По сети FDDI информация передается в форме двух блоков данных: кадра и токена. Формат кадра FDDI представлен на рисунке 41.

Рис. 41. Формат кадра FDDI

Рассмотрим назначение полей кадра:

Преамбула (Preamble, PA). Любой кадр должен предваряться преамбулой, состоящей как минимум из 16 символов Idle (I). Эта последовательность предназначена для вхождения в синхронизм генератора RCRCLK, обеспечивающего прием последующих символов кадра.

Начальный ограничитель (Starting Delimiter, SD). Состоит из пары символов JK, которые позволяют однозначно определить границы для остальных символов кадра.

Поле управления (Frame Control, FC). Идентифицирует тип кадра и детали работы с ним. Имеет 8-ми битовый формат и передается с помощью двух символов. Состоит из подполей, обозначаемых как CLFFZZZZ, которые имеют следующее назначение:

С — говорит о том, какой тип трафика переносит кадр — синхронный (значение 1) или асинхронный (значение 0).

L — определяет длину адреса кадра, который может состоять из 2-х байт или из 6-ти байт.

FF — тип кадра, может иметь значение 01 для обозначения кадра LLC (пользовательские данные) или 00 для обозначения служебного кадра MAC-уровня. Служебными кадрами МАС-уровня являются кадры трех типов — кадры процедуры инициализации кольца Claim Frame, кадры процедуры сигнализации о логической неисправности Beacon Frame и кадры процедуры управления кольцом SMT Frame.

ZZZZ — детализирует тип кадра.

Адрес назначения (Destination Address, DA) — идентифицирует станцию (уникальный адрес) или группу станций (групповой адрес), которой(ым) предназначен кадр. Может состоять из 2-х или 6-ти байт.

Адрес источника (Source Address, SA) — идентифицирует станцию, сгенерировавшую данный кадр. Поле должно быть той же длины, что и поле адреса назначения.

Информация (INFO) — содержит информацию, относящуюся к операции, указанной в поле управления. Поле может иметь длину от 0 до 4478 байт (от 0 до 8956 символов). Стандарт FDDI допускает размещение в этом поле маршрутной информации алгоритма Source Routing, определенной в стандарте 802.5. При этом в два старших бита поля адреса источника SA помещается комбинация 102 — групповой адрес, комбинация, не имеющая смысла для адреса источника, а обозначающая присутствие маршрутной информации в поле данных.

Контрольная последовательность (Frame Check Sequence, FCS) — содержит 32-х битную последовательность, вычисленную по стандартному методу CRC-32, принятому и для других протоколов IEEE 802. Контрольная последовательность охватывает поля FC, DA, SA, INFO и FCS.

Конечный ограничитель (Ending Delimiter, ED) — содержит единственный символ Terminate (T), обозначающий границу кадра. Однако за ним располагаются еще признаки статуса кадра.

Статус кадра (Frame Status, FS). Первые три признака в поле статуса должны быть индикаторами ошибки (Error, E), распознавания адреса (Address recognized, A) и копирования кадра (Frame Copied, C). Каждый из этих индикаторов кодируется одним символом, причем нулевое состояние индикатора обозначается символом Reset (R), а единичное — Set (S). Стандарт позволяет производителям оборудования добавлять свои индикаторы после трех обязательных.

На рисунке 42 показан формат токена.

Рис. 42. Формат токена

Токен состоит по существу из одного значащего поля — поля управления, которое содержит в этом случае 1 в поле С и 0000 в поле ZZZZ.

Операции МАС-уровня

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

Рассмотрим эти операции.

Захват токена.Если станция имеет право захватить токен, то она после ретрансляции на выходной порт символов PA и SD токена, удаляет из кольца символ FC, по которому она распознала токен, а также конечный ограничитель ED. Затем она передает вслед за уже переданным символом SD символы своего кадра, таким образом, формируя его из начальных символов токена (рис. 43).

Передача кадра.После удаления полей FC и ED токена станция начинает передавать символы кадров, которые ей предоставил для передачи уровень LLC. Станция может передавать кадры до тех пор, пока не истечет время удержания токена.

Для сетей FDDI предусмотрена передача кадров двух типов трафика — синхронного и асинхронного.

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

Рис. 43. Захват токена

Асинхронный трафик — это обычный трафик локальных сетей, не предъявляющий высоких требований к задержкам обслуживания. Станция может передавать асинхронные кадры только в том случае, если при последнем обороте токена по кольцу для этого осталась какая-либо часть неизрасходованной пропускной способности. Интервал времени, в течение которого станция может передавать асинхронные кадры, называется временем удержания токена(Token Holding Time, THT).Каждая станция самостоятельно вычисляет текущее значение этого параметра по алгоритму, рассмотренному ниже.

Рисунок 44 иллюстрирует процесс передачи кадра.

Рис. 44. Передача кадра

В ходе передачи символов собственного кадра станция удаляет из кольца все поступающие от предыдущей станции символы. Такой процесс называется МАС-заменой (MAC Overwriting). Первоначальный источник удаляемого из сети кадра не имеет значения — это может быть и данный МАС-узел, который ранее поместил этот кадр в кольцо, либо другой МАС-узел. Процесс удаления кадров во время передачи никогда не приводит к удалению еще необработанных кадров: если сеть работает корректно, то удаляются только усеченные кадры, которые образуются либо при захвате токена (этот вариант уже рассмотрен), либо при удалении своего кадра станцией-источником (этот вариант будет рассмотрен ниже). В любом случае, усеченный кадр (remnant frame) — это кадр, у которого есть начальный ограничитель, но отсутствует конечный ограничитель, а вместо него и, может быть, еще некоторых полей вставлены символы простоя Idle.

В случае, если удаляемые символы принадлежат кадру, ранее сгенерированному данным МАС-узлом, то одновременно с удалением кадра из кольца проверяются признаки статуса кадра из поля FS — распознавания адреса, копирования и ошибки. Если признак ошибки установлен, то МАС-уровень не занимается повторной передачей кадра, оставляя это уровню LLC или другим верхним уровням коммуникационного стека протоколов.

Станция прекращает передачу кадров в двух случаях: либо при истечении времени удержания токена THT, либо при передаче всех имеющихся у нее кадров до истечения этого срока. После передачи последнего своего кадра станция формирует токен и передает его следующей станции.

Повторение кадра.Если кадр не адресуется данному МАС-узлу, то последний должен просто повторить каждый символ кадра на выходном порту. Каждый МАС-узел должен подсчитывать количество полученных им полных кадров (усеченные не включаются в подсчет). Каждая станция проверяет повторяемый кадр на наличие ошибок с помощью контрольной последовательности. Если ошибка обнаружена, а признак ошибки в поле FS не установлен, то МАС-узел устанавливает этот признак в кадре, а также наращивает счетчик ошибочных кадров, распознанных данным МАС-узлом.

Обработка кадра станцией назначения.Станция назначения, распознав свой адрес в поле DA, начинает копировать символы кадра во внутренний буфер одновременно с повторением их на выходном порту. При этом станция назначения устанавливает признак распознавания адреса. Если же кадр скопирован во внутренний буфер, то устанавливается и признак копирования (невыполнение копирования может произойти, например, из-за переполнения внутреннего буфера). Устанавливается также и признак ошибки, если ее обнаружила проверка по контрольной последовательности.

Удаление кадра из кольца.Каждый МАС-узел ответственен за удаление из кольца кадров, которые он ранее в него поместил. Этот процесс известен под названиемFrame Stripping.Если МАС-узел при получении своего кадра занят передачей следующих кадров, то он удаляет все символы вернувшегося по кольцу кадра. Если же он уже освободил токен, то он повторяет на выходе несколько полей этого кадра прежде, чем распознает свой адрес в поле SA. В этом случае в кольце возникает усеченный кадр, у которого после поля SA следуют символы Idle и отсутствует конечный ограничитель. Этот усеченный кадр будет удален из кольца какой-нибудь станцией, принявшей его в состоянии собственной передачи.

Средний контроль доступа

В стандартах IEEE 802 LAN / MAN подуровень управления доступом к среде передачи ( MAC , также называемый управлением доступом к среде передачи ) — это уровень, который управляет оборудованием, отвечающим за взаимодействие с проводной, оптической или беспроводной средой передачи . Подуровень MAC и подуровень управления логическим каналом (LLC) вместе составляют уровень канала данных . На уровне канала данных LLC обеспечивает управление потоком и мультиплексирование для логического канала (например, EtherType , тег 802.1Q VLAN и т. Д.), В то время как MAC обеспечивает управление потоком и мультиплексирование для среды передачи.

Эти два подуровня вместе соответствуют уровню 2 модели OSI . По причинам совместимости LLC не является обязательным для реализаций IEEE 802.3 (тогда кадры являются «необработанными»), но обязательным для реализаций других стандартов физического уровня IEEE 802. В иерархии модели OSI и стандартов IEEE 802 подуровень MAC обеспечивает абстракцию управления физического уровня, так что сложности управления физическим каналом невидимы для LLC и верхних уровней сетевого стека. Таким образом, любой подуровень LLC (и более высокие уровни) может использоваться с любым MAC. В свою очередь, блок управления доступом к среде формально подключен к PHY через медиа-независимый интерфейс. . Хотя сегодня блок MAC обычно интегрируется с PHY в одном пакете устройства , исторически любой MAC мог использоваться с любым PHY, независимо от среды передачи.

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

Функции, выполняемые на подуровне MAC

Согласно IEEE Std 802-2001 раздел 6.2.3 «Подуровень MAC», основными функциями, выполняемыми уровнем MAC, являются: [1]

• Разграничение и распознавание кадров
• Адресация станций назначения (как отдельных станций, так и групп станций)
• Передача адресной информации станции-источника
• Прозрачная передача данных LLC PDU или эквивалентной информации на подуровне Ethernet.
• Защита от ошибок, как правило, путем создания и проверки последовательностей проверки кадров.
• Контроль доступа к физической среде передачи

В случае Ethernet от MAC требуются следующие функции: [2]

• принимать / передавать нормальные кадры
• полудуплексные функции повторной передачи и отсрочки передачи
• добавить / проверить FCS ( последовательность проверки кадра )
• обеспечение соблюдения межкадрового разрыва
• отбросить искаженные фреймы
• prepend (tx) / remove (rx) преамбула, SFD ( начальный разделитель кадров ) и заполнение
• полудуплексная совместимость: добавить (tx) / удалить (rx) MAC-адрес

Механизм адресации

Адреса локальной сети, используемые в сетях IEEE 802 и FDDI , называются адресами управления доступом к среде ; они основаны на схеме адресации, которая использовалась в ранних реализациях Ethernet . MAC-адрес представляет собой уникальный серийный номер. MAC-адреса обычно назначаются аппаратному обеспечению сетевого интерфейса во время производства. Наиболее значимая часть адреса идентифицирует производителя, который назначает оставшуюся часть адреса, таким образом обеспечивая потенциально уникальный адрес. Это позволяет доставлять кадры по сетевому каналу, который соединяет хосты с помощью некоторой комбинации повторителей , концентраторов , мостов и коммутаторы , но не маршрутизаторы сетевого уровня . Таким образом, например, когда IP- пакет достигает своей сети назначения (подсети), IP-адрес назначения (концепция уровня 3 или сетевого уровня) разрешается с помощью протокола разрешения адресов для IPv4 или протокола обнаружения соседей (IPv6) в MAC-адрес (концепция уровня 2) хоста назначения.

Примерами физических сетей являются сети Ethernet и сети Wi-Fi , обе из которых являются сетями IEEE 802 и используют 48-битные MAC-адреса IEEE 802.

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

Механизм контроля доступа к каналу

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

Самый распространенный метод множественного доступа — это CSMA / CD на основе конкуренции, используемый в сетях Ethernet. Этот механизм используется только в домене сетевых конфликтов, например, в сети с шиной Ethernet или в сети с топологией «звезда» на основе концентраторов. Сеть Ethernet может быть разделена на несколько конфликтных доменов, связанных между собой мостами и коммутаторами.

Метод множественного доступа не требуется в коммутируемой полнодуплексной сети, такой как современные коммутируемые сети Ethernet, но часто доступен в оборудовании по соображениям совместимости.

Механизм управления доступом к каналу для одновременной передачи

Использование направленных антенн и связи миллиметрового диапазона в беспроводной персональной сети увеличивает вероятность одновременного планирования передачи без помех в локальной области, что приводит к огромному увеличению пропускной способности сети. Однако оптимальное планирование одновременной передачи — это NP-трудная проблема . [3]

Сотовые сети

Сотовые сети , такие как сети GSM , UMTS или LTE , также используют уровень MAC. Протокол MAC в сотовых сетях разработан для максимального использования дорогостоящего лицензированного спектра. [4] радиоинтерфейс сотовой сети в слоях 1 и 2 модели OSI; на уровне 2 он разделен на несколько уровней протокола. В UMTS и LTE этими протоколами являются протокол конвергенции пакетных данных (PDCP), протокол управления радиоканалом (RLC) и протокол MAC. Базовая станция имеет абсолютный контроль над радиоинтерфейсом и планирует доступ по нисходящей линии связи, а также доступ по восходящей линии связи для всех устройств. Протокол MAC определяется 3GPP в TS 25.321 [5] для UMTS, TS 36.321 [6] для LTE и TS 38.321 [7] для нового радио 5G (NR).

Мандатная модель управления доступом (MAC): обзор и применение в прикладных системах

MAC, несмотря на то, что содержится во множестве статей и материалов, чаще всего упоминается вскользь и в виде пряного соуса к чему-нибудь вроде краткого упоминания MLS в SELinux. Так как многие ограничивают свою дружбу с SELinux применением рецепта «как отключить SELinux», то и MAC часто удостаивается той же чести. Поэтому сперва коротко о MAC.

Если вы хорошо знакомы с моделью, можете сразу перейти к следующему разделу.

Основная идея

Абстрактная модель безопасности, реализуемая в классическом MAC (каким его знают сотрудники силовых ведомств), выглядит следующим образом (классическая картинка, иллюстрирующая модель Белла — Лападулы):

Модель MAC по своей сути является «электронной» реализацией бумажного «секретного» документооборота. В MAC имеются следующие «действующие лица»:

• Иерархия уровней доступа, которые обрабатываются в системе (обычно регистрируются в ОС). Для удобства часто задается в виде беззнаковых чисел (от 0 до значения, ограниченного реализацией). В этом случае для сравнения уровней доступа (выше/ниже/равно) используются простейшие арифметические операции (равно, меньше, больше).
• Объект с уровнем секретности. Любой файл, каталог в файловой системе, ячейка или запись в таблице БД, таблица в БД, сама БД, сетевой пакет и т.д. Объекту присваивается любое значение из иерархии уровней доступа. Для объекта допускается повышение уровня секретности (изменение до большего значения уровня, чем текущий). Понижение уровня секретности категорически не допускается (хотя вполне реализуемо при помощи определенных уловок).
• Субъект с уровнем доступа. Процесс какого-либо приложения либо сеанс пользователя (по сути тоже процесс приложения). Метка уровня доступа наследуется от субъекта всеми создаваемыми данным субъектом объектами.

Проверка полномочий осуществляется при каждом факте доступа субъекта к объекту, защищаемому MAC. При этом мандатная модель управления доступом обычно используется совместно с другими механизмами контроля доступа, например, DAC (UNIX-моделью и POSIX ACL). При этом MAC проверяется в последнюю очередь. Сперва проверяется доступ по DAC (как наименее защищенный), а затем уже MAC.

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

1. Мандатная метка субъекта равна мандатной метке объекта. В этом случае субъекту разрешено читать и изменять объект.
2. Мандатная метка субъекта выше мандатной метки объекта. Субъекту разрешено только читать объект: он его видит, но не может изменить.
3. Мандатная метка субъекта ниже мандатной метки объекта. Субъекту формально разрешено создать объект с более высокой мандатной меткой (так называемое «повышение уровня секретности объекта»). На практике у субъекта нет технической возможности для выполнения данной операции (он просто «не видит» изменяемый объект, например, файл или каталог с файлами).

Ограничения и уязвимости

MAC обладает своими ограничениями и особенностями:

1. Пользователи системы не могут самостоятельно определять доступ субъектов к объектам. Из всего арсенала управления доступом к объекту в MAC имеется только мандатная метка и мандатная категория, которые привязаны к этому объекту. Управление доступом субъектов к объектам осуществляют только администраторы.
2. Если пользователь хочет изменить мандатную метку объекта, автором которого он является, то ему необходимо перейти в сеанс целевой метки. Связано с тем, что пользователь не может указать метку по своему желанию, а может лишь передать метку объекту «по наследству». Одновременно пользователь может работать только в сеансе одной мандатной метки.
3. Так как MAC используется совместно с другими моделями управления доступом, возникают коллизии: иногда не так просто выяснить, в каком «слое» системы безопасности произошёл отказ в предоставлении доступа. Требуется тонкий «тюнинг» всех слоёв защиты.
4. Помимо самой настройки доступа посредством инструментария MAC требуется наличие регламента безопасности. В нем должно быть описано, что значат конкретные значения мандатных меток (это находится за пределами MAC), какие объекты как защищаются, какие субъекты имеют право на доступ. Без наличия согласованного регламента MAC сама по себе не даст security enhancement.
5. Использование MAC в распределенной сетевой инфраструктуре. Традиционный подход к настройке MAC — локально, вручную, при помощи администратора в соответствии с инструкцией. Есть решения, позволяющие реализовать централизованно управляемое хранилище MAC (вроде ALD), но они имеют свои особенности и сложности построения.

Проектирование приложения с поддержкой MAC

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

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

Итак, что у нас есть в наборе:

Системное ПО	Описание
ОС Astra Linux Special Edition / SELinux	ОС с поддержкой MAC. Предоставляет хранилище информации о мандатных разрешениях пользователей, связанное с хранилищем пользователей операционной системы. Предоставляет механизмы контроля доступа к объектам, защищаемым MAC (объектам файловой системы, запуску приложений в режиме мандатной метки и т.д.).
СУБД PostgreSQL (PostgresPro)	Имеет интеграцию с хранилищем учетных записей и мандатных меток ОС. СУБД предоставляет функциональность присваивания мандатной метки к таким объектам, как кластер, база данных, таблица, столбец и запись.
Веб-сервер с поддержкой MAC (Apache Http Server)	Ретранслирует мандатную метку от запроса клиента с поддержкой MAC и запускает обработчик приложения (скрипт/службу) с идентичной меткой и передачей данных аутентификации пользователя.
Браузер с поддержкой MAC (Mozilla Firefox)	Считывает мандатную метку сеанса пользователя (графической оболочки пользователя) и добавляет ее в запросы к веб-приложениям.

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

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

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

1. Пользователь входит в ОС под своей личной УЗ в режиме требуемой ему метки. Запускает приложение. Процесс приложения наследует мандатную метку.
2. Приложение взаимодействует с БД на PostgreSQL, отображая пользователю, к примеру, только записи таблиц БД с текущей мандатной меткой.

1. Пользователь входит в ОС под своей личной УЗ в режиме требуемой ему метки. Запускает браузер с поддержкой MAC, в нашем примере — Mozilla Firefox («обычный» браузер для этих целей не подойдет). Процесс браузера наследует мандатную метку.
2. Пользователь запрашивает адрес ресурса приложения с поддержкой мандатных меток. Браузер формирует запрос, добавляя в него мандатную метку.
3. Запрос обрабатывает веб-сервер с поддержкой мандатных меток, в нашем примере — Apache Http Server. Веб-сервер (процесс которого работает в режиме минимальной мандатной метки) считывает мандатную метку запроса, находит приложение-обработчик запускает его процесс с переданной мандатной меткой.
4. Приложение взаимодействует с БД на PostgreSQL, ретранслируя в запросах мандатную метку.

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

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

Как избежать MAC, когда его уже не избежать

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

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

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

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

Рекомендации:

Добавить параметр включения/отключения поддержки мандатных меток в приложении.

Во всех местах, требующих взаимодействия с MAC, прежде всего проверять значение параметра.

При отладке и тестировании необходимо отлаживать (на стороне команды разработки) и тестировать (на стороне команды тестирования) оба режима работы приложения.

Разделяй и властвуй

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

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

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

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

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

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

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

Классификация модулей по режимам обработки MAC

«BRING IT ON»: работа модуля в режиме минимальной мандатной метки

Мотивация для реализации данного механизма в модуле:

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

Примеры практических кейсов, для которых подходит использование режима минимальной мандатной метки:

• Управление учетными записями пользователей в хранилище приложения. Например, если приложение ведет собственный учет УЗ в файле или БД. Все данные, касающиеся безопасности и управления доступом к приложению, обязательно должны храниться в режиме минимальной мандатной метки, иначе модель безопасности приложения будет попросту «рассыпаться» при выполнении приложения в режиме повышенной мандатной метки. Именно по этой причине все системные приложения запускаются строго под минимальной мандатной меткой.
• Управление правами доступа. Например, если в приложении реализована собственная модель разграничения доступа на уровне бизнес-логики.
• Управление параметрами конфигурации приложения, которые должны быть доступны под всеми мандатными метками.
• Управление учетными записями в ОС. Если приложению требуется управлять какими-либо атрибутами УЗ в ОС, все операции должны выполняться строго под минимальной мандатной меткой.

«HURT ME PLENTY»: работа модуля в режиме одной мандатной метки

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

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

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

• Была допущена ошибка в архитектуре при проектировании модуля (не были заложены особенности обработки записей в MAC), и нет ни времени, ни ресурсов все переписывать.
• Поддержка мандатной модели управления доступом вводится в уже функционирующее приложение, и в соответствии с требованиями необходимо обеспечить работу с меткой выше минимальной в ОС. Да, это тот самый случай, когда к вам приходит руководитель и сообщает с радостью, что мы выиграли конкурс и будем внедрять наше решение в «наименование секретного ведомства»!
• Нет целесообразности в реализации полной поддержки одновременной обработки записей нескольких мандатных меток. Нет необходимости в одновременной обработки записей сразу нескольких мандатных меток.
• Приложение функционирует в однопользовательском режиме.

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

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

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

Примеры практических кейсов, для которых подходит использование режима одной мандатной метки:

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

«NIGHTMARE!»: работа модуля в режиме нескольких мандатных меток

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

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

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

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

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

Для реализации такого режима необходимо заложить следующие функции:

• Функция получение мандатной метки текущего процесса приложения (сеанса пользователя).
• Функция получения мандатной метки записи (если речь идет о работе с записью в БД) или файла (если речь идет об обработке файлов).
• Функция получения мандатной метки записей БД/файлов в коллекции.

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

Взаимодействие приложения с окружающей средой

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

• Операционная система:
  • Параметры мандатной модели:
    • Иерархия мандатных меток ОС;
    • Мандатные разрешения (диапазоны меток, которые может использовать определенный пользователь) УЗ пользователей ОС.
    • СУБД (например, PostgreSQL):
      • Объекты БД (ячейки, строки, столбцы, схемы, таблицы, БД, кластеры, последовательности, функции и т.д.).

      Взаимодействие MAC-совместимого приложения с операционной системой

      

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

      Чего мы ожидаем от операционной системы в части MAC?

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

      Наиболее вероятные потоки взаимодействий ОС и приложения изображены на схеме:

      

      Взаимодействие MAC-совместимого приложения со сторонним ПО без поддержки MAC

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

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

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

      Взаимодействие MAC-совместимого приложения со сторонним ПО с поддержкой MAC

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

      Пример популярного приложения с полноценной поддержкой мандатных меток — СУБД PostgresSQL. В определенных вариантах поставки данной СУБД реализована полная поддержка MAC под некоторые ОС с механизмами MAC, например:

      • Astra Linux: PostgreSQL, идущий в поставке дистрибутива версии SE.
      • SELinux: расширение sepgsql.
      • На уровне кластера.
      • На уровне БД кластера.
      • На уровне схемы БД кластера.
      • На уровне таблицы схемы БД кластера.
      • На уровне столбца таблицы схемы БД кластера.
      • На уровне записи таблицы схемы БД кластера.

      Взаимодействие MAC-совместимого приложения с пользователем

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

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

      На примере распространенных сегодня веб-приложений чаще всего встречаются следующие кейсы:

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

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

      Здесь возможны следующие варианты:

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

      Выводы

      Мы рассмотрели несколько аспектов разработки приложения с поддержкой MAC. Все случаи предусмотреть, разумеется, сложно. Большая часть особенностей мандатной модели зависит от реализации, доступной для применения в выбранной ОС.

      Поддержка MAC приложением — это не дополнительная «фича» приложения. Это серьезное архитектурное решение, требующее планирования и проектирования. Наибольшая «боль» для проектировщика MAC-совместимого приложения:

      Media Access Control

      Media Access Control (MAC), уровень управления доступом к среде (передачи) — подуровень протокола передачи данных, также известен, как Medium Access Control. Является подуровнем канального (второго) уровня модели OSI. MAC обеспечивает адресацию и механизмы управления доступом к каналам, что позволяет нескольким терминалам или точкам доступа общаться между собой в многоточечной сети (например, в локальной или городской вычислительной сети).

      Подуровень MAC выступает в качестве интерфейса между подуровнем LLC (управления логической связью) и физическим (первым) уровнем модели OSI, и эмулирует полнодуплексный логический канал связи в многоточечной сети.

      Содержание

      Механизм адресации

      Механизм адресации уровня MAC называется физической адресацией или MAC-адресами. MAC-адрес представляет собой уникальный серийный номер (см. OUI), который присваивается каждому сетевому устройству (такому, как сетевая карта в компьютере или сетевой коммутатор) [1] во время изготовления, и позволяет однозначно определить его среди других сетевых устройств в мире. Это гарантирует, что все устройства в сети будут иметь различные MAC-адреса (по аналогии с почтовыми адресами), что делает возможным доставку пакетов данных в место назначения внутри подсети (англ.  Subnetwork ), т.е. физической сети, состоящей из нескольких сегментов, взаимосвязанных повторителями, хабами, мостами или свичами (но не IP-маршрутизаторами). IP-маршрутизаторы могут соединять несколько подсетей.

      Примером физической сети может служить Ethernet-сеть, которая может быть расширена точками доступа беспроводной локальной вычислительной сети (WLAN) и сетевыми адаптерами WLAN, так как они делят те же 48-битные MAC-адреса, что и Ethernet.

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

      Механизм контроля доступа к каналу

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

      Механизм множественного доступа основан на схеме мультиплексирования физического уровня.

      Наиболее широко используемый протокол множественного доступа основывается на протоколе CSMA/CD, используемом в Ethernet. Этот механизм используется только внутри сетевого домена коллизий, например, в шине Ethernet или в сетевом концентраторе (хабе). Сеть Ethernet может быть разделена на несколько доменов коллизий, соединённых мостами и маршрутизаторами.

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

      Общие протоколы множественного доступа

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

      (используется в Ethernet и IEEE 802.3)
      • Token bus (IEEE 802.4) (IEEE 802.5)
      • Token passing (используется в FDDI)

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

      (используется в IEEE 802.11/WiFiWLANs)
      • Slotted ALOHA
      • Dynamic TDMA
      • Reservation ALOHA (R-ALOHA)
      • OFDMA

      Для более подробных сведений см. List of channel access methods   (англ.) .

      Похожие публикации:

      1. Как настроить маршрут по умолчанию
      2. Как сжать фото на компьютере чтобы отправить по почте
      3. Как установить gimp в ubuntu
      4. Simply linux на чем основан