Кибериммунный подход предъявляет требования к организации базовой архитектуры системы. Мы предлагаем использовать проверенные архитектурные шаблоны безопасности, которые значительно упрощают разработку по-настоящему безопасных и надежных систем. Такая разработка ведется быстрее и эффективнее, а результат вызывает больше доверия.
Базовых требований к архитектуре и дизайну системы несколько:
В этой части поговорим о двух первых требованиях.
Базовые архитектурные паттерны, которым предлагает следовать кибериммунный подход, представлены в архитектурной концепции MILS 1 и архитектуре FLASK [3]2. В российских стандартах MILS-системы соответствуют системам с разделением доменов, и в дальнейшем мы будем использовать этот термин. 3 4
Система с разделением доменов — это система, разделенная на строго изолированные модули, называемые доменами безопасности, коммуникации между которыми определяются архитектурой политики и контролируются ядром разделения системы. Все остальные функции безопасности реализуются внутри изолированных доменов безопасности.
Данный архитектурный подход основан на выводе исследователей в области ИБ о том, что безопасность системы зависит от двух факторов: насколько хорошо изолированы компоненты системы друг от друга и от качества собственных функций безопасности этих компонентов. 5 6
Преимущество подхода в том, что в системе с разделением доменов можно сделать доказательные выводы об уровне защищённости всей системы в целом за конечное время. В тех случаях, когда система нетривиальна и состоит из гетерогенных компонентов, разработанных, возможно, разными поставщиками, это свойство становится не просто желательным, а необходимым.
В системе с разделением доменов каждый домен безопасности полагается на собственные функции безопасности и не доверяет никому, кроме ядра разделения — самого доверенного компонента всей системы. Эта концепция идейно соответствует Zero Trust архитектуре (архитектуре нулевого доверия), доказавшей свою эффективность в обеспечении безопасности корпоративных сетей 7 8 Концепция MILS также соответствует известному шаблону безопасности Distrustful Decomposition.9
У разработчиков архитектуры FLASK в ее изначальном варианте была цель, близкая той, которую преследовали разработчики концепции систем с разделением доменов. Обе концепции отвергают идею монолитного ядра безопасности, ответственного за всю безопасность системы. Разработчики FLASK тоже стремились к надежному контролю взаимодействий модулей системы, но главное внимание уделили гибкости политик безопасности. Для этого важны возможность управлять уже выданными разрешениями на доступ и отсутствие централизованных шаблонных правил, заданных ядром безопасности системы.
Понятие безопасности расширилось, ни одно общее для всех случаев определение не будет неизменным и достаточным. Но любое понятие выражается в политике безопасности, поэтому общеприемлемая система определения и вычисления политик должна допускать произвольное расширение как множества политик, так и их типов.
Задача управления разрешениями на доступ включает контроль за гранулированностью прав, контроль распространения и отзыв прав. Все эти функции не являются тривиальными. Например, UNIX-подобные операционные системы закрепляют права доступа за дескриптором каждого открытого файла, поэтому отзыв прав не подействует на уже открытые файлы. В случае использования популярного механизма контроля доступа Object Capabilities серьезной проблемой является контроль распространения прав. Как и в любой другой системе дискреционного типа, субъект может передавать права (Capabilities) другому субъекту, и система «миграционного контроля» может быть чрезвычайно изощренной. Разработчики FLASK предложили архитектуру, которая стала ещё одним широко известным шаблоном безопасности: разделение компонентов, ответственных за предоставление доступа на основании готовых разрешений доступа (Policy Enforcement Point), и компонентов, ответственных за вычисление этих разрешений (Policy Decision Point, он же монитор или сервер безопасности), см. рисунок ниже.
Кибериммунный подход в части требований к архитектуре системы обязывает на системном уровне следовать шаблонам безопасности «декомпозиция с утратой доверия» (DD — Distrustful Decomposition) и «разделение точек принятия и исполнения решений безопасности» (PDP/PEP — Policy Decision Point & Policy Enforcement Point), в соответствии с двумя архитектурными концепциями — системами с разделением на домены и FLASK (в изначальном микроядерном варианте).
В следующей части продолжим рассказ о требованиях к архитектуре и дизайну и затронем тему кибериммунной модели целостности системы.
Кибериммунный подход предъявляет требования к организации базовой архитектуры системы. Мы предлагаем использовать проверенные архитектурные шаблоны безопасности, которые значительно упрощают разработку по-настоящему безопасных и надежных систем. Такая разработка ведется быстрее и эффективнее, а результат вызывает больше доверия.
Базовых требований к архитектуре и дизайну системы несколько:
В этой части поговорим о двух первых требованиях.
Базовые архитектурные паттерны, которым предлагает следовать кибериммунный подход, представлены в архитектурной концепции MILS 1 и архитектуре FLASK [3]2. В российских стандартах MILS-системы соответствуют системам с разделением доменов, и в дальнейшем мы будем использовать этот термин. 3 4
Система с разделением доменов — это система, разделенная на строго изолированные модули, называемые доменами безопасности, коммуникации между которыми определяются архитектурой политики и контролируются ядром разделения системы. Все остальные функции безопасности реализуются внутри изолированных доменов безопасности.
Данный архитектурный подход основан на выводе исследователей в области ИБ о том, что безопасность системы зависит от двух факторов: насколько хорошо изолированы компоненты системы друг от друга и от качества собственных функций безопасности этих компонентов. 5 6
Преимущество подхода в том, что в системе с разделением доменов можно сделать доказательные выводы об уровне защищённости всей системы в целом за конечное время. В тех случаях, когда система нетривиальна и состоит из гетерогенных компонентов, разработанных, возможно, разными поставщиками, это свойство становится не просто желательным, а необходимым.
В системе с разделением доменов каждый домен безопасности полагается на собственные функции безопасности и не доверяет никому, кроме ядра разделения — самого доверенного компонента всей системы. Эта концепция идейно соответствует Zero Trust архитектуре (архитектуре нулевого доверия), доказавшей свою эффективность в обеспечении безопасности корпоративных сетей 7 8 Концепция MILS также соответствует известному шаблону безопасности Distrustful Decomposition.9
У разработчиков архитектуры FLASK в ее изначальном варианте была цель, близкая той, которую преследовали разработчики концепции систем с разделением доменов. Обе концепции отвергают идею монолитного ядра безопасности, ответственного за всю безопасность системы. Разработчики FLASK тоже стремились к надежному контролю взаимодействий модулей системы, но главное внимание уделили гибкости политик безопасности. Для этого важны возможность управлять уже выданными разрешениями на доступ и отсутствие централизованных шаблонных правил, заданных ядром безопасности системы.
Понятие безопасности расширилось, ни одно общее для всех случаев определение не будет неизменным и достаточным. Но любое понятие выражается в политике безопасности, поэтому общеприемлемая система определения и вычисления политик должна допускать произвольное расширение как множества политик, так и их типов.
Задача управления разрешениями на доступ включает контроль за гранулированностью прав, контроль распространения и отзыв прав. Все эти функции не являются тривиальными. Например, UNIX-подобные операционные системы закрепляют права доступа за дескриптором каждого открытого файла, поэтому отзыв прав не подействует на уже открытые файлы. В случае использования популярного механизма контроля доступа Object Capabilities серьезной проблемой является контроль распространения прав. Как и в любой другой системе дискреционного типа, субъект может передавать права (Capabilities) другому субъекту, и система «миграционного контроля» может быть чрезвычайно изощренной. Разработчики FLASK предложили архитектуру, которая стала ещё одним широко известным шаблоном безопасности: разделение компонентов, ответственных за предоставление доступа на основании готовых разрешений доступа (Policy Enforcement Point), и компонентов, ответственных за вычисление этих разрешений (Policy Decision Point, он же монитор или сервер безопасности), см. рисунок ниже.
Кибериммунный подход в части требований к архитектуре системы обязывает на системном уровне следовать шаблонам безопасности «декомпозиция с утратой доверия» (DD — Distrustful Decomposition) и «разделение точек принятия и исполнения решений безопасности» (PDP/PEP — Policy Decision Point & Policy Enforcement Point), в соответствии с двумя архитектурными концепциями — системами с разделением на домены и FLASK (в изначальном микроядерном варианте).
В следующей части продолжим рассказ о требованиях к архитектуре и дизайну и затронем тему кибериммунной модели целостности системы.
