Шаблон предназначен для разделения потоков данных для ограничения доступа к ресурсам на уровне драйвера ресурсов с целью обеспечения конфиденциальности, целостности и взаимного невлияния потоков данных. Примером применения шаблона является уменьшение поверхности атаки на виртуальную файловую систему (ВФС), за счет разделения одной ВФС на несколько: например, отдельно для работы с внешней сетью и отдельно для работы с внутренней сетью и блочным устройством.
В ситуации, когда взаимодействие процессов регулируются только правилами, появляется возможность эти правила нарушить: случайно, злонамеренно или просто для удобства. Например, встречные полосы на автомобильных дорогах разделены разметкой. Некоторые водители нарушают правила и выезжают за пределы своей полосы. Иногда машины там оказываются ненамеренно, например, из-за аварии или гололеда. И в том и в другом случае выезд на встречную полосу опасен для всех участников движения. Для решения этой проблемы на трассах используются барьерные ограждения. Идея заключается в физическом разделении встречных полос, нарушить которое уже вряд ли получится.
Эта же идея заложена в шаблон: разделить потоки данных на низкоуровневой реализации, не позволяя одному субъекту вмешаться в работу другого. Данные и способы обращения к ним разделяются техническими средствами или базовыми механизмами, а не просто правилами, которые можно обойти.
Типовые цели безопасности при применении шаблона включают:
Предположения безопасности включают:
Предположения и условия, при которых шаблон не может быть применен:
Элементы системы, реализующей шаблон:
Взаимодействие элементов шаблона представлено на рисунке 1.
В качестве поясняющего примера рассмотрим виртуальные файловые системы (ВФС), работающие с сетью и с блочными устройствами, которые должны быть разделены и помещены в разные домены безопасности.
Сущности (субъекты, процессы), обрабатывающие данные из сетей, приходящие на разные контроллеры или адаптеры, должны использовать разные ВФС.
Компрометация сетевой ВФС не должна приводить к компрометации сущностей, с которыми она взаимодействует.
Рассмотрим угрозы безопасности на примере приложения с одной ВФС, которая обеспечивает сразу несколько типов взаимодействия:
Для выполнения первого требования нужно реализовать подход разделения одной ВФС на несколько, а точнее на 4 (ВФС для работы с публичной сетью для обеих сущностей, ВФС для работы с локальной сетью для обеих сущностей).
Чтение и запись данных из хранилища данных осуществляют два компонента:
Для каждого из них требуется отдельная ВФС.
Второе требование достигается автоматически при выполнении первого требования, поскольку разделение сети на несколько подсетей в данном примере не рассматривается.
Далее, для выполнения третьего требования должны быть реализованы независимые хранилища информации.
Для этого:
Для выполнения последнего требования необходимо убедиться, что доверенные компоненты, взаимодействующие с файловым хранилищем, не обращаются напрямую к сетевому драйверу, взаимодействующему с публичной сетью.
Пример показан на рисунке 2.
Необходимо реализовать разделение на разных уровнях драйверов: драйвер ВФС или драйвер раздела, чем ниже уровень, на котором проводится разделение, тем проще осуществить доказательство невлияния потоков данных.
Необходимо реализовать разделение пула ресурсов для привязки к ним раздельных драйверов доступа, что должно быть обеспечено технической возможностью адресации ресурсов определенного типа и невозможностью драйвера адресовать ресурсы того же типа вне заданного для него пула адресов.
Необходимо реализовать подходы к обеспечению корректности работы драйверов ресурсов и драйверов ниже этого уровня (если они доступны для контроля), в первую очередь методические и кооперационные подходы, обеспечивающие безопасность и корректность работы драйверов.
Ограничения на применение шаблона определяются ограничениями на производительность и требованиями доступности ресурсов, доступ к которым реализуется с использованием шаблона.
Допустимые модификации шаблона определяются через количество типов ресурсов и политики разграничения доступа к этим ресурсам.
Допустимость модификаций, не входящих в указанный перечень, должна быть обоснована при проектировании архитектуры и формировании требований, предъявляемых к системе на основе целей и предположений безопасности для этой системы.
