Изоляция данных

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

Контролирование информационного потока

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

Обработка циклов

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

Ограничение ущерба

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

Система взаимодействия разделов

Этот метод, как я уже говорил, создан для отдельных процессоров. Но когда приложение должно работать через сеть, вам все же нужно, чтобы приложение было настолько безопасным, как если бы оно работало на одном процессоре. Архитектура MILS может это поддерживать. Это достигается путем сквозного (end-to-end) внедрения политик ядра MILS. Система взаимодействия разделов (Partition Communication System, или PCS) – это то, что обеспечит данную политику.

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

• Идентификация узлов: защита против спуфинга
• Разделение данных
• Шифрование
• Стабильное управление политикой

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

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

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

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

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

Рисунок 1: Схема сети высокой готовности (предоставлено сайтом http://www.dell.com/)

Активный/Активный

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

Активный/Пассивный

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

N + 1

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

N + M

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

N to N

N to N конфигурация представляет собой сочетание конфигураций активный/активный и N + M. В этой конфигурации каждый узел активен, но способен перенастраиваться, чтобы принимать на себя роли любого другого узла. Такая конфигурация исключает необходимость в резервных узлах, но требует больше места на активных узлах.

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