---

**1. Проблема скрытых каналов. Почему классы группы C (C1, C2) принципиально не способны эффективно противодействовать скрытым каналам?**

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

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

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

**2. Эволюция ТСВ. Изменение требований к архитектуре ТСВ от класса C2 к классу B3 и связь компактности с непрерывностью защиты.**

При переходе от класса C2 к классу B3 требования к архитектуре Доверенной вычислительной базы (ТСВ) кардинально меняются:
*   **Класс C2:** ТСВ не предъявляются строгие требования к архитектуре, структуре или изоляции. Основной упор делается на функции управления доступом и аудит.
*   **Класс B1:** ТСВ должна поддерживать неформальную модель безопасности, маркировку данных и нормативное управление доступом. Требуется устранение недостатков, выявленных при тестировании.
*   **Класс B2:** ТСВ должна быть четко структурирована, выделены элементы, критичные с точки зрения безопасности. Архитектура и реализация должны быть выполнены с учетом возможности проведения тестовых испытаний. Вводится контроль скрытых каналов.
*   **Класс B3:** ТСВ должна быть структурирована с целью **исключения из нее подсистем, не отвечающих за реализацию функций защиты**. Она должна быть **достаточно компактной** для эффективного тестирования и анализа. Кроме того, требования ужесточаются до контроля всех типов доступа и невозможности обхода монитора взаимодействий.

**Связь компактности (минимизации сложности) и непрерывности защиты:**
Требование минимизации сложности (компактности) ТСВ в классе B3 напрямую связано с требованием непрерывности защиты. Если ТСВ содержит множество избыточных, не связанных с безопасностью функций, сложность ее кода и архитектуры возрастает. Это делает невозможным проведение полного и эффективного тестирования и анализа. Невозможность проанализировать всю систему означает наличие потенциальных уязвимостей и «лазеек», через которые злоумышленник может обойти монитор взаимодействий (нарушить непрерывность защиты). Только компактная, минималистичная ТСВ, содержащая только функции защиты, позволяет гарантировать, что она не может быть обойдена, и обеспечивает непрерывный контроль всех потоков данных.

**3. Иерархия верификации. Фундаментальное отличие систем класса A1 от B3.**

Фундаментальное отличие систем класса A1 от функционально эквивалентных им систем класса B3 заключается в **методе подтверждения корректности** их архитектуры и реализации.
*   **Класс B3:** Требует применения методов и средств, направленных на минимизацию сложности, и проведения тестовых испытаний. Однако доказательство безопасности здесь базируется на тестировании и практическом анализе, а не на строгих математических выкладках. Модель безопасности может быть формально определена, но ее соответствие реализации доказывается не полностью формально.
*   **Класс A1 (из раздела 1.3):** Это высший уровень безопасности, который характеризуется **формально доказанной** защитой. Это означает, что корректность архитектуры и реализации ТСВ должна быть подтверждена с помощью строгих математических (формальных) методов верификации.

**Почему класс A1 практически неосуществим для массовых коммерческих ОС?**
Формальные методы доказательства корректности требуют колоссальных затрат времени, ресурсов и высокой квалификации специалистов. Они предполагают создание математической модели всей системы и доказательство теорем, подтверждающих отсутствие уязвимостей. Для массовых коммерческих операционных систем, которые постоянно обновляются, имеют огромный объем кода и должны быстро выходить на рынок, такие методы являются экономически нецелесообразными и технически труднореализуемыми. Кроме того, в разделе 1.4 указано, что даже сама «Оранжевая книга» устарела из-за стремительного развития технологий (переход от мейнфреймов к ПК и сетям), что еще больше затрудняет применение жестких формальных требований класса A1 к современным динамичным системам.