Кратко

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

Решение принимал получатель

RFC 1457 был опубликован в мае 1993 года как Informational-документ Russell Housley. Несмотря на широкое название Security Label Framework for the Internet, он не предлагал единого всемирного формата и не требовал снабжать меткой каждый пакет. Документ помогал разработчику ответить на более ранние вопросы: нужна ли протоколу метка, какое решение она должна поддержать и на каком уровне она должна появиться, чтобы не опоздать к этому решению.

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

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

Атрибут обязан был следовать за своим объектом

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

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

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

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

Доверие к данным не равно праву их увидеть

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

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

Следовательно, единой шкалы «безопаснее» не существовало. Вопрос «следует ли верить этому сообщению?» и вопрос «какому субъекту позволено его читать?» запускали разные переходы состояния. Если журнал сохранял только слово «security», он мог скрыть, какой именно вывод был сделан.

Чужую форму нужно было превратить в местное обязательство

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

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

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

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

Когда перевод был неизбежен, его мог выполнять шлюз приложений. В Internet и OSI не существовало универсальной функции транспортного, сеансового или представительского уровня, способной согласовать любые локальные системы меток. Шлюз объединял в одной точке интерпретацию, эксплуатацию и доверие. Непрозрачная таблица соответствий превращала совместимость в зависимость от её владельца.

Маршрутизатору не требовалась вся политика

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

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

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

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

Явные, неявные, пакетные и соединительные метки

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

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

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

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

RFC 1108 показал, сколько решения оставалось на месте

RFC 1108 ранее определил конкретные параметры безопасности Министерства обороны США для IPv4. Basic Security Option содержал уровень классификации и флаги защитных органов. Это был пример явной пакетной метки сетевого уровня.

Однако существенная часть поведения задавалась локально. Параметры порта определяли, требовалась ли метка для исходящего трафика, принимался ли вход без неё и какая неявная метка назначалась данным с конкретного порта. Битовая строка не несла полного правила получателя и не доказывала его исполнение.

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

Слои обозначали точки власти

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

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

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

Более поздние документы уточнили границу контекста

В 2009 году RFC 5570 описал CALIPSO — явный IPv6-механизм для меток чувствительности — и ввёл заметный Domain of Interpretation. Слово “SECRET” само по себе не имело операционного значения. Получателю требовалось знать, какая организация и какая система уровней и compartments стоят за ним. Идентификатор области указывал на контекст политики, но не содержал всей политики и не исполнял её.

RFC 5570 также чётко ограничил область применения доверенными закрытыми multi-level secure сетями и назвал механизм непригодным для глобального публичного интернета. Историческое сопоставление не является советом по современному развёртыванию.

RFC 4301 даёт другой контраст. В архитектуре IPsec селекторы пакета сопоставляются с локальной Security Policy Database, выбирающей PROTECT, BYPASS или DISCARD; затем Security Associations хранят конкретное криптографическое состояние обработки. Метка может быть входом для политики, но она не является SA, алгоритмом, проверенной стороной или доказательством выполнения защиты.

Метаданные способны назвать требуемое обращение. Одним существованием они его не осуществляют.