Многоуровневая безопасность: почему идеальная модель редко работает в реальном мире

Многоуровневая безопасность (Multilevel Security, MLS) — одна из наиболее фундаментальных концепций в истории информационной безопасности. Именно здесь появились строгие математические модели управления информационными потоками, многие идеи которых продолжают использоваться и сегодня.
MLS как подход «ежа» (hedgehog approach) — системы, построенной вокруг одной большой универсальной идеи, которая должна объяснить и решить все проблемы безопасности. Однако реальный мир редко укладывается в рамки одной концепции. Поэтому история MLS — это одновременно история блестящих теоретических достижений и болезненных практических компромиссов.

Зачем появилась MLS

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

• Unclassified — несекретно;
• Confidential — конфиденциально;
• Secret — секретно;
• Top Secret — совершенно секретно.

Основная задача заключалась не только в том, чтобы пользователь с низким уровнем допуска не смог прочитать секретную информацию. Не менее важно было предотвратить обратную проблему: исключить любые способы передачи секретных данных в менее защищенные области системы.
Для решения этой задачи была создана модель Bell–LaPadula (BLP), ставшая фундаментом мандатного контроля доступа.

Bell–LaPadula: защита конфиденциальности через контроль потоков информации

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

1. Уровень классификации:

-- Unclassified;
-- Confidential;
-- Secret;
-- Top Secret.

1. Категории или компартменты:

-- {CRYPTO};
-- {NUCLEAR};
-- {FOREIGN};
-- и другие специализированные области доступа.

Правило доминирования

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

• уровень классификации не ниже;
• набор категорий включает все категории более низкой метки.

Например:

Top Secret {CRYPTO, NUCLEAR}

доминирует над:

Secret {CRYPTO}

но не доминирует над:

Secret {FOREIGN}

если категория {FOREIGN} отсутствует.

Два фундаментальных правила BLP

Свойство	Правило	Назначение
Simple Security Property	No Read Up — субъект не может читать данные более высокого уровня	Предотвращение несанкционированного раскрытия информации
*-Property	No Write Down — субъект не может записывать данные на более низкий уровень	Предотвращение утечек информации

Принцип No Read Up интуитивно понятен: сотрудник с допуском Confidential не должен иметь возможность просматривать документы уровня Secret.
Гораздо важнее правило No Write Down. Именно оно защищает систему от скрытого распространения информации. Даже если вредоносное ПО получит доступ к данным уровня Secret, оно не сможет сохранить их в объекте уровня Unclassified.
Это превращает BLP не просто в механизм разграничения доступа, а в модель контроля информационных потоков.

Именно правило No Write Down отличает многоуровневую безопасность от большинства традиционных систем разграничения доступа.

Модель Biba: зеркальное отражение Bell–LaPadula

Если Bell–LaPadula защищает конфиденциальность, то модель Biba, предложенная Кеном Бибой в 1975 году, предназначена для защиты целостности информации.
Логика модели полностью противоположна BLP.

Свойство	Правило	Назначение
Simple Integrity Property	No Read Down	Высокоуровневые процессы не должны использовать потенциально недостоверные данные
*-Integrity Property	No Write Up	Низкоуровневые процессы не могут изменять критически важные объекты

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

• Bell–LaPadula: грязная вода не должна попасть в чистую емкость.
• Biba: чистая вода не должна смешиваться с грязной.

Практическое применение модели Biba

Хотя Bell–LaPadula редко реализуется в полном объеме, идеи Biba нашли применение в современных операционных системах.
Хорошим примером является механизм Mandatory Integrity Control, появившийся в Windows Vista.
Приложения получают различные уровни целостности:

• Low;
• Medium;
• High;
• System.

Например, Internet Explorer запускался с уровнем Low Integrity. Даже если злоумышленнику удавалось выполнить вредоносный код через браузер, этот процесс не мог изменить объекты с более высоким уровнем доверия.
Фактически система применяла принцип:

No Write Up — процессы с низкой целостностью не могут изменять высокоцелостные объекты.

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

Красота теории и сложность практики

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

Когда теория сталкивается с практикой: фундаментальные проблемы MLS

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

Проблема спокойствия (Tranquility Property)

Модели Bell–LaPadula исходно предполагали, что метки безопасности объектов и субъектов остаются неизменными. Однако реальные системы постоянно изменяются:

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

Для описания допустимого поведения была сформулирована концепция свойства спокойствия (Tranquility Property).

Выделяют две формы этого свойства.

Сильное спокойствие (Strong Tranquility)

Метки безопасности никогда не изменяются после назначения.
Такой подход обеспечивает простоту анализа и формальную строгость модели, но практически неприменим. В реальной среде невозможно заранее предусмотреть все сценарии обработки информации.
Например, как создать новый документ уровня Secret, если классификация объектов не может изменяться?

Слабое спокойствие (Weak Tranquility)

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

Принцип High Water Mark

Для реализации слабого спокойствия была предложена концепция High Water Mark — принципа «высокой отметки воды».
Его суть заключается в следующем: если процесс получает доступ к информации более высокого уровня секретности, его собственный уровень автоматически повышается.
Например:

1. Процесс работает с данными уровня Secret.
2. Затем он открывает документ уровня Top Secret.
3. После этого сам процесс становится Top Secret.

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

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

В результате возникают два негативных сценария:

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

Все больше объектов получают высокие уровни секретности.
Со временем значительная часть системы оказывается помеченной как Top Secret, что резко снижает возможность совместной работы и обмена информацией.

Фрагментация системы

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

Полиинстанцирование: когда секретность ломает базы данных

Одной из наиболее необычных проблем MLS стало полиинстанцирование (Polyinstantiation).
Рассмотрим простой пример.
Пользователь уровня Secret создает запись:

Агент_Х

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

Вариант 1: отказать в создании

Система сообщает:

Запись уже существует.

Но тогда пользователь низкого уровня узнает о существовании секретного объекта.
Фактически происходит нарушение правила No Read Up.
Даже отсутствие доступа становится каналом утечки информации.

Вариант 2: разрешить создание

В этом случае в системе появляются две записи:

Уровень	Объект
Secret	Агент_Х
Unclassified	Агент_Х

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

Подходы к решению проблемы

Различные страны использовали разные стратегии.

Подход США: легенды (Cover Stories)

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

Например:

Уровень доступа	Отображаемая информация
Secret	Сведения о реальном агенте
Unclassified	«Запись отсутствует» или фиктивные данные

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

Подход Великобритании

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

Classified

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

Скрытые каналы: фундаментальная проблема MLS

Наиболее серьезным ограничением многоуровневой безопасности стали скрытые каналы передачи информации (Covert Channels).
Модель Bell–LaPadula контролирует только явные информационные потоки:

• операции чтения;
• операции записи;
• обращения к объектам системы.

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

Каналы хранения (Storage Channels)

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

1. Процесс уровня High создает файл — это означает бит 1.
2. Файл не создается — это означает бит 0.
3. Процесс уровня Low периодически проверяет наличие файла.
4. Последовательность действий преобразуется в сообщение.

Формально правила Bell–LaPadula не нарушаются.
Фактически происходит утечка информации.

Временные каналы (Timing Channels)

Еще более опасны каналы времени.
Вместо изменения состояния объектов злоумышленник использует характеристики производительности системы.
Например:

• высокая загрузка процессора означает 1;
• отсутствие нагрузки означает 0.

Низкоуровневый процесс измеряет:

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

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

Можно ли полностью устранить скрытые каналы?

Теоретически — да.
Практически — почти никогда.
Для полного устранения скрытых каналов необходимо обеспечить абсолютную изоляцию ресурсов:

• отдельных процессоров;
• памяти;
• устройств ввода-вывода;
• дисковых подсистем;
• сетевых интерфейсов;
• механизмов планирования.

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

допустимая пропускная способность скрытого канала не должна превышать 1 бит в секунду.

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

• криптографические ключи;
• пароли;
• идентификаторы агентов;
• другую критически важную информацию.

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

Проблема каскадирования: почему безопасные системы не всегда безопасны вместе

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

Как возникает проблема

Представим две сертифицированные MLS-системы.
Система A поддерживает уровни:

• Unclassified (U);
• Confidential (C);
• Secret (S).

Система B поддерживает уровни:

• Secret (S);
• Top Secret (TS).

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

1. В системе B пользователь уровня Top Secret записывает данные в объект уровня Secret.
2. Эти данные становятся доступны системе A через общий уровень Secret.
3. В системе A субъект уровня Secret может передать информацию дальше — например, в область Confidential или Unclassified, если политика системы допускает подобные преобразования.

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

Главный вывод проблемы каскадирования

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

Это один из важнейших уроков всей инженерии безопасности.
Формальное доказательство безопасности системы редко сохраняется после:

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

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

Современные подходы: как индустрия адаптировала идеи MLS

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

Type Enforcement: от уровней секретности к типам

Одним из наиболее успешных наследников MLS стала модель Type Enforcement (TE).
Вместо сложной системы уровней допуска и компартментов используются два понятия:

• домены (domains) — контексты выполнения процессов;
• типы (types) — категории объектов системы.

Политика безопасности задается явной матрицей взаимодействий:

• какие домены могут читать определенные типы объектов;
• какие домены могут изменять определенные типы;
• какие операции полностью запрещены.

Например:

Процесс	Разрешенный доступ
Веб-сервер	Только к веб-контенту
DNS-сервер	Только к DNS-конфигурации
Почтовый сервер	Только к почтовым очередям

Даже если злоумышленник скомпрометирует веб-сервер, он не сможет получить доступ к данным DNS-сервера.

SELinux: практическая реализация Type Enforcement

Одной из наиболее известных реализаций этой концепции стал SELinux (Security-Enhanced Linux), разработанный АНБ США.
В SELinux основным механизмом защиты является именно Type Enforcement, а не классическая MLS-модель.
Такой подход обладает рядом преимуществ:

Более понятная модель безопасности

Права привязываются к функциям компонентов, а не к абстрактным уровням секретности.

Отсутствие проблемы High Water Mark

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

Улучшенная изоляция сервисов

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

Виртуализация: разделение вместо усложнения

Еще одним важным направлением развития стала виртуализация.
Вместо создания одной чрезвычайно сложной MLS-системы организации начали использовать несколько изолированных вычислительных сред.
Например:

Виртуальная машина	Назначение
High VM	Работа с секретными данными
Low VM	Интернет и общедоступные сервисы
Management VM	Администрирование

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

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

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

Однонаправленные шлюзы: Data Diodes

В некоторых критически важных системах используется еще более радикальный подход — однонаправленные шлюзы (Data Diodes).
Идея проста:

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

Например:

Открытая сеть  ─────────►  Закрытая сеть

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

• в военной инфраструктуре;
• на промышленных объектах;
• в энергетических системах;
• на объектах критической инфраструктуры.

MLS как философия безопасности: «еж» против «лисы»

Обратимся к известной мысли философа Исайи Берлина:

«Лиса знает много вещей, а еж знает одну большую вещь».

MLS является примером подхода «ежа».
Его фундаментальная идея проста и элегантна:

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

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

• бизнес-процессы;
• человеческий фактор;
• потребности совместной работы;
• обмен информацией между подразделениями;
• удобство эксплуатации систем.

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

Когда чрезмерная секретность становится угрозой безопасности

Парадоксально, но чрезмерное следование принципам MLS иногда приводит к противоположному результату.

Гиперклассификация информации

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

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

Изолированные информационные острова

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

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

Уроки 11 сентября

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

отсутствие обмена информацией также представляет собой риск безопасности.

Человеческий фактор и сложность политик безопасности

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

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

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

Итоги

Многоуровневая безопасность стала одним из важнейших этапов развития информационной безопасности.
Именно MLS подарила отрасли:

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

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

• скрытыми каналами передачи информации;
• проблемами полиинстанцирования;
• эффектом гиперклассификации;
• сложностями композиции безопасных систем;
• человеческим фактором и организационными ограничениями.

Современные решения — SELinux, виртуализация, Type Enforcement и однонаправленные шлюзы — не заменяют идеи MLS, а адаптируют их к реальным условиям эксплуатации.
Главный урок заключается в том, что безопасность — это не только математика и формальные модели.
Это поиск баланса между:

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

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

Вопросы для дальнейших исследований

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

1. Как сделать политики мандатного контроля доступа более понятными и удобными для администраторов?
2. Возможно ли эффективно ограничивать скрытые каналы в современных облачных и виртуализированных средах?
3. Каким образом сочетать строгий контроль информационных потоков с потребностью организаций в быстром обмене знаниями?
4. Как применять идеи MLS в системах, критичных к безопасности (safety-critical systems), где ошибки могут приводить не только к утечкам данных, но и к угрозе жизни людей?
5. Какие модели безопасности способны обеспечить баланс между формальной строгостью и практической применимостью?

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

Многосторонняя безопасность: защита интересов в мире пересекающихся доверительных отношений

Если многоуровневая безопасность (MLS) отвечает на вопрос «Как предотвратить утечку информации между различными уровнями секретности?», то многосторонняя безопасность (Multilateral Security) решает совершенно иную задачу:

Как организовать совместную работу множества независимых участников, интересы которых могут конфликтовать, но которым всё равно необходимо взаимодействовать в рамках одной системы?

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

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

Именно поэтому рассмотрим эту область не только как техническую, но и как социально-техническую проблему.

Модель Китайской стены: управление конфликтами интересов

Одной из наиболее известных моделей многосторонней безопасности является модель Китайской стены (Chinese Wall Model), предложенная Брюэром и Нэшем в 1989 году.
Первоначально она создавалась для консалтинговых компаний, инвестиционных банков и юридических фирм, где сотрудники работают одновременно с несколькими клиентами, которые могут быть прямыми конкурентами.
Основная задача модели:

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

Основные элементы модели

Модель опирается на два ключевых понятия.

Классы конфликта интересов (Conflict of Interest Classes)

COI-класс объединяет организации, конкурирующие между собой.
Например:

COI-класс	Компании
Нефтегазовый сектор	BP, Shell, ExxonMobil
Банковский сектор	HSBC, Barclays, Deutsche Bank
Аудиторские услуги	PwC, Deloitte, EY

Наборы данных компании (Company Datasets)

Каждая организация внутри COI-класса имеет собственный набор данных.
Например:

Нефтегазовый сектор
├── BP Dataset
├── Shell Dataset
└── ExxonMobil Dataset

Правила модели Китайской стены

В основе модели лежит динамическое изменение прав доступа.

Правило свободного выбора

Пользователь может получить доступ к данным любой организации, если ранее не обращался к данным конкурирующих компаний из того же COI-класса.
Например:
* Консультант впервые получает доступ к документам компании Shell.

На этом этапе ограничений нет.

Правило Китайской стены

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

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

Например:

Получен доступ к Shell
        ↓
Разрешено:
✓ Shell
✓ Компании из других отраслей

Запрещено:
✗ BP
✗ ExxonMobil

Таким образом, система предотвращает возникновение конфликта интересов.

Практические ограничения модели

Несмотря на элегантность идеи, на практике возникают серьезные сложности.

Накопление знаний

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

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

Полностью исключить подобные утечки невозможно.

Проблемы масштабируемости

Поддержка актуальных COI-классов требует постоянного участия:

• юристов;
• специалистов по compliance;
• подразделений информационной безопасности.

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

• чрезмерной изоляцией сотрудников;
• ослаблением политики безопасности.

Медицинские информационные системы и модель BMA

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

как обеспечить доступность медицинской информации для лечения пациентов, одновременно сохраняя их приватность?

Именно этой проблеме посвящена модель British Medical Association (BMA).

Подчернем важный момент:

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

К ним относятся:

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

Основные угрозы медицинских систем

Внутренние нарушения

Наиболее распространенные инциденты включают:

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

Централизация данных

Создание единого национального хранилища медицинских записей значительно упрощает:

• администрирование;
• обмен информацией;
• проведение исследований.

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

Экстренные ситуации

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

• в реанимации;
• при отсутствии сознания;
• во время экстренной операции.

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

Принципы модели BMA

Модель BMA строится вокруг нескольких ключевых принципов.

Владение информацией

Пациент рассматривается как основной владелец медицинской информации о себе.

Осознанное согласие

Доступ к данным допускается только при наличии:

• явного согласия;
• подразумеваемого клинического согласия.

Полный аудит

Все обращения к данным фиксируются.
Пациент должен иметь возможность узнать:

• кто просматривал записи;
• когда это происходило;
• с какой целью осуществлялся доступ.

Изоляция чувствительных данных

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

• психиатрические записи;
• ВИЧ-статус;
• генетическая информация;
• сведения о репродуктивном здоровье.

Break-the-Glass

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

• обязательно журналируется;
• подлежит последующему расследованию.

Это позволяет сохранить баланс между приватностью и безопасностью пациента.

Контроль вывода: когда статистика разрушает анонимность

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

Tracker-атаки

Злоумышленник формирует серию связанных запросов.
Например:

COUNT(пациенты с заболеванием X)

COUNT(пациенты с заболеванием X, исключая пациента Y)

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

Differencing Attacks

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

Методы защиты статистических баз данных

Ограничение размера выборки

Система запрещает выполнение запросов, возвращающих слишком малое число записей.
Например:

Минимальный размер группы ≥ 5

Проблема заключается в том, что редкие заболевания автоматически становятся уязвимыми.

Подавление ячеек

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

Рандомизация

В данные вводится контролируемый шум:

• округление;
• перестановка записей;
• методы дифференциальной приватности.

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

чем выше приватность, тем ниже точность аналитики.

Идеального решения не существует.

Активные атаки и пределы анонимизации

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

Активные атаки

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

Урок проекта deCODE

Особое внимание уделяется исландскому проекту deCODE, целью которого было объединение:

• медицинских данных;
• генетической информации;
• генеалогических записей.

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

техническая деидентификация не всегда способна преодолеть социальное недоверие и сложность реальных данных.

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

Ценность несовершенной защиты

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

• значительное время;
• специализированные знания;
• существенные финансовые ресурсы,

то массовое злоупотребление данными становится экономически невыгодным.
Таким образом:

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

Она выступает своеобразной профилактикой против неконтролируемого использования информации.

Остаточная проблема: где заканчивается техника и начинается политика

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

Он называет это остаточной проблемой (Residual Problem).

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

Интерфейс между медициной и финансами

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

• строгий контроль доступа;
• детальный аудит;
• разделение полномочий;
• защита статистических выборок;
• механизмы экстренного доступа.

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

Почему возникает проблема

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

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

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

Конфликт интересов

Интересы различных участников существенно различаются.

Медицинские организации стремятся:

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

Финансовые организации стремятся:

• предотвращать мошенничество;
• проводить аудит расходов;
• рассчитывать страховые риски;
• сохранять данные в течение длительных периодов.

Эти цели зачастую противоречат друг другу.

Почему технические меры оказываются недостаточными

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

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

После передачи данных основным механизмом защиты становятся:

• законодательство;
• договорные обязательства;
• регуляторный контроль;
• профессиональная этика.

Расползание миссии (Mission Creep)

Феномен Mission Creep — постепенного расширения первоначального назначения информационной системы.
Этот процесс обычно происходит незаметно.

Как развивается Mission Creep

Система создается для решения конкретной задачи.
Например:

хранение медицинских данных для лечения пациентов.

Со временем появляются новые заинтересованные стороны.
Информация начинает использоваться:

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

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

Почему это опасно

Основная проблема заключается не в злонамеренности участников.
Чаще всего расширение происходит под благовидными предлогами:

• повышения эффективности;
• снижения затрат;
• улучшения качества услуг;
• борьбы с мошенничеством.

Но в результате:

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

Парадокс централизации

Есть еще одна важная закономерность.
Централизация одновременно улучшает управление и увеличивает риски.

Преимущества централизации

Единые базы данных позволяют:

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

Недостатки централизации

Однако централизованные системы обладают серьезными уязвимостями.
Они создают:

Единую точку компрометации

Успешная атака предоставляет доступ сразу к огромному объему информации.

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

Чем больше данных хранится в одном месте, тем выше мотивация атакующих.

Усиление инсайдерских угроз

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

Упрощение Mission Creep

Централизованные базы значительно облегчают повторное использование данных для новых целей.

Экономика как фактор приватности

Одним из наиболее интересных выводов, является следующее наблюдение:

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

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

Государственно-центричные модели

При централизованном государственном финансировании возникает естественное стремление к консолидации информации.
Аргументы обычно включают:

• повышение эффективности;
• снижение расходов;
• улучшение планирования.

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

Страховые модели

При доминировании частных страховщиков медицинские данные концентрируются в корпоративных системах.
Это приводит к новым угрозам:

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

Децентрализованные модели

Системы с высокой степенью персональной ответственности за финансирование медицинских услуг уменьшают стимулы к массовому накоплению данных.
Следовательно:

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

Почему технологии не могут решить все проблемы

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

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

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

Главные уроки

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

«Кто может получить доступ к информации?»

то многосторонняя безопасность задает гораздо более сложный вопрос:

«Как обеспечить справедливый баланс между интересами множества участников, каждый из которых обладает законными, но потенциально конфликтующими целями?»

Именно поэтому технические механизмы оказываются лишь частью решения.

Итоги

В рамках статьи были рассмотрены несколько фундаментальных концепций.

1. Модель Китайской стены

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

2. Модель BMA

Продемонстрировала, что медицинские информационные системы требуют особого баланса между:

• доступностью данных;
• приватностью пациентов;
• необходимостью экстренного вмешательства.

3. Контроль вывода

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

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

4. Активные атаки и ограничения анонимизации

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

5. Остаточная проблема

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

Исследовательские вопросы

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

1. Как проектировать системы, учитывающие коллективную природу некоторых данных, например генетической информации, затрагивающей интересы родственников?
2. Возможно ли создать механизмы адаптивной приватности, автоматически подстраивающиеся под контекст использования информации?
3. Как обеспечить прозрачность вторичного использования данных без чрезмерного усложнения пользовательского опыта?
4. Какие экономические модели стимулируют организации защищать данные пользователей, а не извлекать максимальную выгоду из их повторного использования?
5. Можно ли разработать архитектуры, минимизирующие негативные последствия централизации без потери преимуществ совместного использования информации?

Заключение

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

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

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