Защищённая и анонимная операционная система Tails. Понятие защищенной ос

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

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

Подходы к построению защищенных ОС

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

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

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

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

Административные меры защиты

Программно-аппаратные средства защиты ОС обязательно должны дополняться административными мерами защиты. Без постоянной квалифицированной поддержки со стороны администратора даже надежная программно-аппаратная защита может давать сбои. Перечислим основные административные меры защиты.

  • 1. Постоянный контроль корректности функционирования ОС, особенно ее подсистемы защиты. Такой контроль удобно организовать, если ОС поддерживает автоматическую регистрацию наиболее важных событий (event logging) в специальном журнале.
  • 2. Организация и поддержание адекватной политики безопасности. Политика безопасности ОС должна постоянно корректироваться, оперативно реагируя на попытки злоумышленников преодолеть защиту ОС, а также на изменения в конфигурации ОС, установку и удаление прикладных программ.
  • 3. Инструктирование пользователей операционной системы о необходимости соблюдения мер безопасности при работе с ОС и контроль за соблюдением этих мер.
  • 4. Регулярное создание и обновление резервных копий программ и данных ОС.
  • 5. Постоянный контроль изменений в конфигурационных данных и политике безопасности ОС. Информацию об этих изменениях целесообразно хранить на неэлектронных носителях информации, для того чтобы злоумышленнику, преодолевшему защиту ОС, было труднее замаскировать свои несанкционированные действия.

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

Адекватная политика безопасности

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

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

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

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

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

  • 1. Анализ угроз. Администратор ОС рассматривает возможные угрозы безопасности данного экземпляра ОС. Среди возможных угроз выделяются наиболее опасные, защите от которых нужно уделять максимум средств.
  • 2. Формирование требований к политике безопасности. Администратор определяет, какие средства и методы будут применяться для защиты от тех или иных угроз. Например, защиту от НСД к некоторому объекту ОС можно решать либо средствами разграничения доступа, либо криптографическими средствами, либо используя некоторую комбинацию этих средств.
  • 3. Формальное определение политики безопасности. Администратор определяет, как конкретно должны выполняться требования, сформулированные на предыдущем этапе. Формулируются необходимые требования к конфигурации ОС, а также требования к конфигурации дополнительных пакетов защиты, если установка таких пакетов необходима. Результатом данного этапа является развернутый перечень настроек конфигурации ОС и дополнительных пакетов защиты с указанием того, в каких ситуациях, какие настройки должны быть установлены.
  • 4. Претворение в жизнь политики безопасности. Задачей данного этапа является приведение конфигурации ОС и дополнительных пакетов защиты в соответствие с политикой безопасности, формально определенной на предыдущем этапе.
  • 5. Поддержание и коррекция политики безопасности. В задачу администратора на данном этапе входит контроль соблюдения политики безопасности и внесение в нее необходимых изменений по мере появления изменений в функционировании ос.

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

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

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

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

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

Дистрибутив на базе Ubuntu, разработанный для тестирования вторжений. За счет использования XFCE в качестве стандартного оконного менеджера, работает очень быстро.

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

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

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

Kali

Вероятно, самый популярный дистрибутив для тестирования на проникновения, основанный на Debian Wheezy. разработан компанией Offensive Security Ltd и является продолжением более раннего проекта BackTrack Linux.

Kali доступ в виде 32-битных и 64-битных ISO-образов, которые можно записать на USB-носитель или CD диск, или даже установить на жесткий диск или твердотельный накопитель. Проект также поддерживает архитектуру ARM и может запускаться даже на одноплатном компьютере Raspberry Pi, а также включает огромное количество инструментов анализа и тестирования. Основным рабочим столом является Gnome, но Kali позволяет создать персонализированный ISO-образ с другой средой рабочего стола. Этот гибко настраиваемый дистрибутив позволяет пользователям даже изменять и пересобирать ядро Linux, чтобы соответствовать конкретным требованиям.

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

Доступный для 32-битных и 64-битных машин, является дистрибутивом для тестирования вторжений, который основан на Gentoo Linux. Пользователи Gentoo могут дополнительно устанавливать Pentoo, который будет инсталлироваться поверх основной системы. Дистрибутив основан на XFCE и поддерживает сохранение изменений, поэтому при отключении USB-носителя, все примененные изменения будут сохранены для будущих сессий.

Встроенные инструменты делятся на 15 различных категорий, например, Exploit, Fingerprint, Cracker, Database, Scanner и т.д. Будучи основанным на Gentoo, дистрибутив унаследовал набор защитных функций Gentoo, которые позволяют выполнять дополнительные настройки безопасности и более детально управлять дистрибутивом. Вы можете использовать утилиту Application Finder для быстрого обнаружения приложений, расположенных в различных категориях.

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

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

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

Security Onion построен вокруг XFCE и включает все самые необходимые приложения, имеющиеся в Xubuntu. Security Onion не предназначен для любителей, а скорее подойдет опытным специалистам, которые имеют определенный уровень знаний в области мониторинга сети и предотвращения вторжений. К счастью проект постоянно сопровождается подробными руководствами и видеоуроками, чтобы помочь в работе с сложным встроенным ПО.

Caine

Учетная запись по умолчанию: root:blackarch. BlackArch имеет размер более 4 гигабайт и поставляется с несколькими различными оконными менеджерами, включая Fluxbox, Openbox, Awesome.

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

Разработанный итальянской сетью Frozenbox, посвященной IT-безопасности и программированию, основанный на Debian, может использоваться для тестирования вторжений и поддержания конфиденциальности. Также как BlackArch, Parrot Security OS является дистрибутивом плавающего релиза. Логин по умолчанию для Live-сессии: root:toor.

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

Персонализируемая среда рабочего стола Mate предлагает привлекательный интерфейс, а сам Parrot Security OS работает очень шустро даже на машинах с 2 гигабайтами ОЗУ. В систему встроено несколько нишевых утилит, например, apktool - инструмент изменения APK файлов.

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

JonDo

Нашли опечатку? Нажмите Ctrl + Enter


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

Чарлз Калко - большой поклонник защищенных операционных систем (trusted operating system). При помощи инструментария PitBull компании Argus Systems Group он заботится об изоляции жизненно важных компонентов, составляющих основу функционирования своего сайта, где встречаются компании, заинтересованные в разного рода бартере. В результате ему удается добиться большей защищенности и большей стабильности работы системы, хотя бы потому, что администраторы получают меньше возможностей совершить какие-либо неразумные действия в ее отношении.

Но защищенные операционные системы, как заметил Калко, старший инженер по вопросам безопасности компании Bigvine.com, это своего рода нейтронные бомбы, - «они способны очень быстро решить множество проблем, но также и породить новые. Совершая необдуманные поступки, можно здорово испортить себе жизнь». Другими словами, ИТ-менеджеры должны использовать защищенные ОС лишь тогда, когда даваемые ими преимущества оправдывают затраты на обучение и время, которое приходится тратить на их сопровождение.

Защищенные операционные системы представляют собой особые разновидности «коробочных» ОС, таких как Windows NT и Unix, с усовершенствованной защитой. Защищенную версию NT разумно установить на Web-сервере, который содержит сам или имеет доступ к критически важной корпоративной информации. Однако следует помнить: защищенные ОС обычно намного сложнее в изучении и обслуживании, чем их стандартные аналоги.

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

Новый порядок


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

«Следует определить, какие системы критически важны для вас, - отметил Чак Райан, директор по защите информации компании Molex. - Все защитить просто невозможно».

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

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

Истинная защищенная операционная система изначально строится с учетом требований безопасности. Как заметил Пол Макнабб, директор по технологиям компании Argus Systems, защищенную ОС отличает наличие трех следующих «рычагов».

  • Политика принудительного контроля доступа (mandatory access control). Рассмотрим простую задачу совместного использования файла - тривиальную, если вы легитимный пользователь, и, возможно, опасную, если вы хакер. «При работе с NT или Unix операционная система не сообщает, можно ли совместно использовать данный файл или послать его по почте, - заметил Макнабб. - Но при реализации контроля уполномоченного доступа, такого, к примеру, какой применяется в PitBull, можно конфигурировать систему заранее, определив, что данный пользователь никогда не сможет получить доступ к определенным ресурсам или передать свое право доступа к ним кому-либо другому».
  • Администрирование привилегий, которые можно использовать для управления и ограничений возможностей пользователя или приложения, управляющих системой или ее частью. «В защищенной ОС можно устанавливать программу, которая никогда не сможет изменить назначение привилегий, даже в том случае, если каким-то образом эта программа попадет в полную власть хакера», - заметил Макнабб. Такое решение не позволит хакеру проникнуть в систему через какое-то приложение, если, скажем, ему удастся отключить пароль, защищающий другие приложения.
  • Независимая экспертиза, проводимая, например, в Национальном институте стандартов и технологии или Агентством национальной безопасности США.

Если исходить из этих критериев, то самые распространенные ОС - Microsoft Windows NT и Windows 2000, а также различные версии Unix - не являются защищенными системами, хотя Windows 2000 - это заметный шаг вперед благодаря предусмотренной в ней «защите системных файлов», позволяющей обеспечить безопасность некоторых критически важных компонентов.

Защищенные операционные системы крупнейших производителей Unix-систем, таких как Sun Microsystems и Hewlett-Packard, существуют уже давно, но они не пользовались особой популярностью из-за сложности управления и отсутствия ряда важных функций, которые есть у их коммерческих аналогов. Кроме того, как подчеркнул Джон Пескаторе, аналитик GartnerGroup, они были не полностью совместимы с приложениями, работавшими с их менее защищенными вариантами.

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

Более новые версии таких программных средств, как HP Virtual Vault (защищенная версия HP-UX) и PitBull (которая улучшает функции защиты Sun Solaris, IBM AIX и NT), использовать намного проще, но, как подчеркнул Пескаторе, они по-прежнему значительно дороже, чем их стандартные аналоги. Таким образом, потребность в достаточно недорогих и надежных операционных системах растет по мере того, как все больше корпоративных систем устанавливают связи с внешним миром.

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

Многоуровневая защита


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

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

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

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

Существующие системы


Программное обеспечение QSecure компании Qiave Technologies (недавно приобретена корпорацией WatchGuard Technologies) блокирует доступ к тем разделам серверов, которые находятся в рабочем режиме, и предлагает консоль для управления защитой в сети. Как подчеркнул Джек Донахью, директор компании, в рабочем режиме даже правомочный системный администратор не может предпринять действий, способных нарушить функционирование системы.

Кроме того, QSecure использует средства шифрования «по 239-разрядной эллиптической кривой» для передачи запросов к ядру операционной системы.

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

Аналогичным образом, как подчеркнул Гарри Севаунтс, директор по маркетингу подразделения Hewlett-Packard Internet Security Division, «современная версия HP Virtual Vault разделяет функции ОС всего на четыре блока, а не помещает каждый процесс в свой отдельный блок, из-за чего работа существенно усложнилась бы».

Новый программный продукт HP Web Proxy еще проще в работе. Он содержит меньше возможностей для конфигурирования, но намного проще в использовании в качестве внешнего средства защиты для популярных Web-серверов.

Подобная простота в работе имеет огромное значение для некоторых ИТ-менеджеров.

«Мы международная компания, поэтому нам необходимо иметь возможность управлять своим программным обеспечением централизованно», - подчеркнул Райан. Он хотел бы получать отчеты, из которых было бы ясно, какие из уязвимых мест самые важные, а не просто иметь список из 500 возможных источников опасности. «Мы же не можем передать такой список службам поддержки и попросить все это устранить», - заметил он. Наконец, Райан хотел бы получить инструментарий, который работает в NT, Unix и, возможно, даже в NetWare, чтобы не привлекать отдельных специалистов для мониторинга каждой из платформ.

Карл Тианен, директор по защите информационных систем корпорации Halliburton, заметил, что его весьма беспокоят затраты на поддержку защищенных ОС: «Посмотрите на Windows NT и оцените усилия, которые необходимы для ее администрирования. При добавлении уровней защищенности к ней система может стать очень сложной».

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

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

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

Защищенные операционные системы и их стоимость


Argus Systems Group


Продукт: Защищенные операционные системы семейства PitBull, которые улучшают защиту Sun Solaris, IBM AIX и Linux
Цена: от 5 тыс. долл. за ОС, работающую на однопроцессорном Web-сервере, до 50 тыс. долл. за развертывание в рамках всей корпоративной информационной системы


Продукт: Virtual Vault (защищенная версия HP-UX), которая работает только на аппаратных платформах HP, и HP Praesidium WebEnforcer, который представляет собой инструментарий для непрерывного мониторинга и исправления изъянов в защите Windows NT
Цена: Virtual Vault стоит от 15 тыс. долл.; WebEnforcer - 3 тыс. долл. на сервер

Computer Associates


Продукт: eTrust Access Control, который может применяться для укрепления защиты Windows NT и различных вариантов Unix. Управляет доступом к файлам, выполнением критически важных приложений и доступом к сетевым службам
Цена: от 4 тыс. долл.

Qiave Technologies (недавно приобретенная WatchGuard Technologies)


Продукт: QSecure Enterprise Suite для Windows NT, Windows 2000 и Sun Solaris. Блокирует любые изменения, когда ОС находится в рабочем режиме; внесение изменений в систему в режиме администрирования разрешается только после тщательной аутентификации
Цена: от 1295 долл.

Сертифицированные защищенные ОС в России


Список сертифицированных продуктов на 1 декабря 2000 года

SecretNet NT 4.0


Класс защищенности: третий
Подан на сертификацию: НИП «Информзащита»

Операционная система NetWare 5.1 с подсистемой Trusted NetWare Unit


Класс защищенности: четвертый
Подан на сертификацию: представительство Novell

Комплекс «АккордСеть-NDS» для операционных систем NetWare


Класс защищенности: четвертый
Подан на сертификацию: ОКБ САПР, ТОО «Фирма ИнфоКрипт ЛТД»

Операционная система «Мобильная Система Вооруженных Сил»


Класс защищенности: версия 1.5 - третий, версия 2.0 - второй
Подан на сертификацию: ВНИИ автоматизации управления в непромышленной сфере

Cистема защиты информации «Снег» для компьютеров под управлением MS DOS 5.0, 6.0


Класс защищенности: версия 1.0 - третий, версия 2.0 - второй
Подан на сертификацию: ЦНИИАтоминформ Минатома России

Виды защищенных систем


Защищенная операционная система отличается от обычной тем, что соответствует большему классу безопасности. К примеру, по принятой в США классификации к группе C относятся операционные системы с менее изощренной защитой, чем отвечающие требованиям одного из классов B. Эти классы отличаются тем, что в них предусмотрено принудительное управление доступом, в то время как при произвольном управлении владелец ресурса устанавливает для него права доступа других пользователей. В России классы защищенности определены Руководящим документом Гостехкомиссии при Президенте РФ. Однако и в этих документах есть классы - со второго по четвертый, - в которых используется «мандатная защита», или принудительное управление доступом. Защищенная операционная система должна иметь сертификат соответствия одному из этих классов.

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

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

Валерий Коржов

Атаки хакеров…


…защищенных ОС

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

Введение

Существуют два основных подхода к трактовке понятия защищённой автоматизированной системы, применимых к операционным системам (ОС). Первый подход подразумевает, что защищённость ОС обеспечивается при реализации некоторых заданных изначально требований по безопасности, включая наличие некоторого набора механизмов защиты, проверку отсутствия предопределённого перечня уязвимостей и т. п. При втором подходе рассматривается возможность использования ОС в составе автоматизированной системы (АС), которые считаются их владельцами (пользователями) критическими, в связи с чем в ОС должен обеспечиваться комплекс средств защиты, адекватный угрозам безопасности именно этих систем. На первый взгляд, эти два подхода не противоречат друг другу, так как вряд ли в критических АС будут применяться решения, не реализующие хотя бы минимальные требования по безопасности. Вместе с тем ОС при выполнении всех требований по безопасности может быть контролируема извне, например её разработчиком. В указанных условиях второй подход подразумевает, что под защищёнными подразумеваются решения, которые в англоязычной литературе обозначаются термином trusted или, в отечественной интерпретации, - доверенные.

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

Это требование становится все более актуальным в последние годы. Автоматическое обновление, автоматическое оповещение разработников о программных ошибках, разнообразные онлайн-сервисы существенно повышают потребительские качества прикладного и системного программного обеспечения ОС, но, с другой стороны, создают все больше возможностей для производителей программного обеспечения и, в том числе, ОС, контролировать действия пользователей. Для целого ряда применений защищённых ОС вопрос доверия к её разработчику оказывается более значимым, чем вопрос об объёме и качестве реализации в данной ОС стандартных механизмов обеспечения безопасности.

Именно этими соображениями можно объяснить рост интереса к отечественным защищённым ОС, отмечающийся в последнее время в Российской Федерации со стороны органов государственной власти и предприятий промышленности. Дополнительным стимулом по данному направлению стало принятое Правительством Российской Федерации решение об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд. Высказываются прогнозы, что в случае утверждения и принятия Программы развития российского сегмента сети Интернет «к 2025 году все государственные учреждения и стратегические предприятия будут оснащены компьютерами на российской элементной базе с отечественной операционной системой на борту».

В современных условиях перспективная отечественная защищённая ОС должна отвечать следующим требованиям:

  • соответствовать требованиям обеспечения технологической независимости (импортозамещения) Российской Федерации в важнейших областях информатизации, телекоммуникации и связи;
  • быть пригодной к функционированию в компьютерных сетях, как изолированных, так и подключённых к сети Интернет (или иным телекоммуникационным сетям), в том числе ориентированных на обработку информации, отнесённой к государственной тайне, или персональных данных;
  • реализовывать современные механизмы обеспечения информационной безопасности, учитывающие возможность обработки в данной ОС информации, отнесённой к государственной тайне, как с точки зрения удовлетворения формальных требований соответствующих нормативных документов и стандартов, так и с точки зрения обеспечения реальной защиты от актуальных угроз безопасности.

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

Учебные вопросы (основная часть):

1.Обзор защищенных операционных систем семейства Linux

Принято считать, что ОС Linux (точнее, GNU/Linux) была создана в 1991 г. 21-летним финским программистом Линусом Торвальдсом. Фактически Л. Торвальдс переписал с нуля ядро ОС Minix, ничем не примечательного «клона» ОС семейства UNIX.

Долгое время единственным преимуществом ОС Linux по сравнению с другими UNIX-системами была лицензионная чистота программного кода ОС Linux, позволяющая разворачивать на её базе самые разнообразные информационные системы, не беспокоясь о потенциальных сложностях с лицензиями. Примерно до 2000 г. ОС Linux ничем не выделялась среди других ОС семейства UNIX, заметно уступая многим из них по производительности и надёжности.

Долгое время открытость программного кода ОС Linux оставалась единственным фактором, делавшим данную ОС привлекательной для разработчиков прикладного ПО. Однако со временем разнообразие ПО, адаптированного под ОС Linux, достигло некоторой «критической массы», и ситуация изменилась. По мере того как ОС Linux становилась де-факто стандартом в мире ОС семейства UNIX, все больше программистов разрабатывали прикладное и системное ПО, предназначенное для работы под управлением ОС Linux, а компоненты ОС подвергались все более тщательному тестированию и оптимизации. Начиная с какого-то момента, нарастание популярности ОС Linux стало самоподдерживающимся процессом, и в настоящее время эти ОС составляют более 90 % ОС семейства UNIX.

При сравнении ОС семейства Linux с более популярными ОС семейств Microsoft Windows или Mac OS бросается в глаза характерная особенность Lin ux-систем - они первоначально в большей мере были ориентированы на профессиональных высококвалифицированных пользователей. Заметная доля действий, необходимых для настройки системы, а в некоторых случаях и для приведения её в работоспособное состояние, выполняется путём ручного редактирования конфигурационных файлов, редактирования или написания с нуля различных скриптов и т. д. По этой причине ранние версии ОС семейства Linux были практически недоступны массовому пользователю, сейчас этот недостаток в основном преодолён, современные версии ОС семейства Linux требуют лишь минимального обучения.

Часто пользователи даже не знают, что работают именно с ОС этого семейства, так, например, популярная мобильная ОС Android фактически представляет собой пакет системного ПО, развёрнутого на платформе ОС семейства Linux.

Среди многих пользователей ОС семейства Linux бытует мнение, что данная ОС отличается необычайно мощной и практически неуязвимой подсистемой защиты. В качестве аргументов в поддержку этой точки зрения обычно приводят наличие в них базовых механизмов дискреционного управления доступом, аутентификации и аудита, которые аналогичны или даже уступают соответствующим механизмам других ОС. Также встречается аргументация, что практически полное отсутствие вредоносного программного обеспечения для ОС семейства Linux является следствием того, что эта система значительно лучше защищена против вирусных атак, чем, например, ОС семейства Microsoft Windows. Это совершенно неверно. Действительно, вирусы для ОС семейства Linux практически не встречаются «в дикой природе» хакерского сообщества, но это обусловлено отнюдь не высокой защищённостью этих ОС. Программисту средней квалификации несложно убедиться, что написание компьютерного вируса или иной вредоносной программы для ОС семейства Linux ничуть не сложнее (за исключением некоторых узких классов вредоносных программ), чем написание аналогичной программы, например, для ОС семейства Microsoft Windows. Незначительное количество Linux-вирусов объясняется в основном тем, что разработчики вредоносного ПО предпочитают ориентироваться на более популярные программные платформы, для которых нелегальная деятельность киберпреступников приносит наибольший доход.

Базовые средства безопасности ОС семейства Linux унаследованы от ранних версий ОС семейства UNIX, разрабатывавшихся в начале 70-х годов прошлого столетия. Исходя из требований обратной совместимости со старыми версиями, ОС семейства Linux продолжают поддерживать целый ряд устаревших защитных механизмов и концепций. В частности, в подсистемах защиты большинства этих ОС присутствуют следующие «анахронизмы»:

  • все объекты (сущности) доступа должны интерпретироваться как файловые объекты, атрибуты защиты других типов объектов не могут корректно описываться штатными средствами ОС;
  • не поддерживаются глобальные уникальные идентификаторы учётных записей пользователей, все идентификаторы пользователей и групп уникальны только в пределах одного экземпляра ОС:
  • набор прав доступа субъектов (процессов) к сущностям (файлам, каталогам) сильно ограничен, поддерживаются только три права доступа: чтение, запись и выполнение, а также задаётся владелец каждой сущности;
  • полномочия суперпользователя root практически неограниченны;
  • отсутствуют механизмы автоматического назначения атрибутов защиты вновь создаваемым сущностей на основе атрибутов защиты контейнеров (каталогов), где эти сущности создаются;
  • для динамического изменения полномочий субъектов доступа применяется неудобный и потенциально опасный механизм SUID/SGID;
  • не поддерживаются механизмы олицетворения субъектов доступа, осуществляющих клиентский доступ к процессу-серверу;
  • не поддерживается автоматическая генерация сообщений аудита при обращениях определённых субъектов к определенным сущностям;
  • поддерживаемые средства минимизации полномочий пользователей крайне примитивны;
  • не поддерживается мандатный контроль целостности;
  • не поддерживается изолированная программная среда, даже частично.

Отдельно стоит отметить проблемы безопасности графического интерфейса X Window System, используемого в современных версиях ОС семейства Linux для взаимодействия с процессами пользователей. Энтузиасты ОС семейства Linux любят критиковать ОС семейства Microsoft Windows за недостаточную защищённость её графической подсистемы, например: «В ОС Microsoft Windows NT любой процесс независимо от уровня своих привилегий может послать сообщение окну другого процесса (в том числе и более привилегированного!), причём нет никакой возможности установить отправителя сообщения!… Находим окно какого-нибудь привилегированного приложения (а такая возможность у нас есть), получаем дескриптор интересующего нас элемента управления (кнопки, пункта меню, строки редактирования) и… эмулируем ввод пользователя!!! Привилегированный процесс все сделает за нас, так ничего при этом и не заподозрив!».

На самом деле указанная проблема характерна не только для ОС семейства Microsoft Windows. Еще в 1994 г. Р. Браатен в нашумевшем в свое время сообщении в конференции comp.security. Unix сформулировал угрозу похищения графическим приложением X Window System конфиденциальной информации, адресованной другому графическому приложению. В ОС семейства Microsoft Windows, начиная с ОС Windows Vista, введён мандатный контроль целостности графических сущностей, значительно повысивший защищённость графической подсистемы, однако в X Window System ничего подобного не произошло.

Попытки построить на базе ОС семейства Linux защищённую ОС неоднократно предпринимались как в России, так и за рубежом. Исторически можно считать, что первым проектом в данном направлении является ОС Linux-Mandrake Russian Edition, разрабатывавшаяся группой энтузиастов в 1999-2000 гг. и в дальнейшем «выросшая» в проект ОС ALT Linux, поддерживаемый компанией «Альт Линукс». Начиная с 2005 г., дистрибутив ОС ALT Linux является полностью самостоятельным. Подсистема безопасности ОС ALT Linux имеет несколько интересных нововведений (раздельное хранение аутентификационных данных разных пользователей, минимизация количества SUID- и SGID-программ), которые, однако, не оказывают существенного влияния на общую защищённость ОС. Исходя из этого, можно предположить, что разработчики ОС ALT Linux ориентируются на применение данной ОС главным образом в тех организациях, где к безопасности хранимой и обрабатываемой информации не предъявляется высоких требований (например, в школах, университетах и т. д.).

Suid, setuid и setgid (сокращение от «set user ID upon execution» (установка ID пользователя во время выполнения) и «set group ID upon execution» (установка ID группы во время выполнения), соответственно) являются Unix флагами прав доступа, которые разрешают пользователям запускать исполняемые файлы соответственно с правами владельца или группы исполняемого файла.

В Unix-подобных системах приложение запускается с правами пользователя, вызвавшего указанное приложение. Это обеспечивает дополнительную безопасность, так как процесс с правами пользователя не сможет получить доступ на запись к важным системным файлам, например /etc/passwd, который принадлежит суперпользователю root. Если на исполняемый файл установлен бит suid, то при выполнении эта программа автоматически меняет «эффективный userID» на идентификатор того пользователя, который является владельцем этого файла. То есть, независимо от того - кто запускает эту программу, она при выполнении имеет права хозяина этого файла.

Бит suid был изобретен Деннисом Ритчи и запатентован в США компанией AT&T в 1979 году. Позже, патент 4135240 «Protection of data file contents» был выложен в свободный доступ.

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

Первой попыткой построить на базе ОС семейства Linux высокозащищённую ОС, по всей видимости, стала ОС «Феникс», разрабатывавшаяся в Санкт-Петербургском государственном политехническом университете начиная с 2001 г. Данная ОС ограниченно применялась в ЗАО «Инфосистемы Джет».

Какое-то время самой защищённой российской ОС семейства Linux являлась Мобильная система вооружённых сил (МСВС), разработанная по заказу Минобороны России Всероссийским научно-исследовательским институтом автоматизации управления в непромышленной сфере (ВНИИНС) на основе ОС Red Hat Enterprise Linux. ОС МСВС была принята на снабжение вооружённых сил в 2002 г. На протяжении многих лет она широко применялась в самых различных компьютерных системах военного и двойного назначения, существуют её настольные и серверные версии, предназначенные для функционирования на обычных бытовых компьютерах. Последняя на сегодняшний день версия МСВС 5.0, сертифицированная в 2011 г., содержит ядро Linux версии 2.6.32 и,библиотеку glibc версии 2.5 сборки 2006 г.

glibc - GNU C Library (GNU библиотека). Glibc является библиотекой Си, которая обеспечивает системные вызовы и основные функции, такие как open, malloc, printf и т. д. Библиотека C используется для всех динамически скомпонованых программ. Она написана Free Software Foundation для операционных систем GNU. glibc выпущена под лицензией GNU LGPL.

Установка дополнительного ПО в МСВС серьёзно затруднена.

В 2006 г. в Китае начались поставки в военные и государственные учреждения ОС Kylin, разработанной китайским Национальным университетом оборонных технологий на базе ОС FreeBSD. Название ОС означает мифическое животное, часто упоминающееся в китайском фольклоре наряду с драконом и фениксом. Дистрибутив ОС Kylin некоторое время был доступен для скачивания, по мнению экспертов, данная ОС не содержит каких-либо выдающихся защитных механизмов, никто не упоминает о поддержке в ней мандатного управления доступом, мандатного контроля целостности, изолированной программной среды и т. п. В 2013 г. официально стартовал проект ОС Ubuntu Kylin, по всей видимости, не имеющий ничего общего с ОС Kylin, кроме названия. ОС Ubuntu Kylin представляет собой версию ОС Ubuntu Linux с полнофункциональной поддержкой китайского языка и несколькими предустановленными приложениями, специфичными для Китая (лунный календарь, упрощённый доступ к китайским социальным сетям, поставщикам китайской музыки и т. п.).

Дистрибутив доступен на сайте www.ubuntukylin.com.

Есть сведения, что обычный дистрибутив Ubuntu легко превращается в ОС Ubuntu Kylin в результате установки нескольких дополнительных пакетов ПО. Нет никаких сведений, что подсистема безопасности данной ОС чем-либо отличается от подсистемы безопасности ОС Ubuntu Linux.

Семейство отечественных ОС «РОСА» производится с 2009 г. группой компаний «РОСА» на основе ОС Mandriva Linux, являясь в настоящее время последней поддерживаемой её ветвью. Семейство ОС «РОСА» включает в себя сертифицированные защищённые ОС «РОСА Хром» и «РОСА Никель», (заявлена поддержка мандатного управления доступом), «РОСА Кобальт», а также несколько свободно распространяемых дистрибутивов, потребительские качества которых оцениваются пользователями довольно высоко. Весной 2015 г. «НТЦ ИТ РОСА» вошла в число пяти российских компаний, подавших заявку на государственную поддержку отечественных программных продуктов.

В 2010 г. знаменитая польская исследовательница безопасности ОС Иоанна Рутковска объявила, что ведёт разработку защищённой ОС Qubes, основанной на ОС Fedora Linux. Дополнительные средства защиты данной ОС основаны на инкапсуляции прикладных и системных программ в отдельные виртуальные машины, взаимодействие которых реализуется посредством гипервизора Хеn.

Гипервизор (англ. Hypervisor; от др.-греч. ὑπέρ «над, выше, сверх» + лат. vīsio «зрение; видение») или монитор виртуаьных машин (в компьютерах) - программа или аппаратная схема, обеспечивающая или позволяющая одновременное, параллельное выполнение нескольких операционных систем на одном и том же хост-компьютере. Гипервизор также обеспечивает изоляцию операционных систем друг от друга, защиту и безопасность, разделение ресурсов между различными запущенными ОС и управление ресурсами.

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

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

Передача данных между виртуальными машинами в ОС Qubes осуществляется на основе общесистемной политики безопасности, потенциально способной поддерживать мандатное управление доступом, мандатный контроль целостности, изолированную программную среду и т. п. Для пользователя наличие этой политики становится заметным только в том случае, если он попытается её нарушить, иначе работа пользователя выполняется как в обычной ОС Fedora Linux. Окна программ, принадлежащих к разным виртуальным машинам, выполняются на общем рабочем столе, как при включённом seamless mode в ПО Virtual Box (в русскоязычной локализации этот режим называется «Режим интеграции дисплея»).

Позже похожая идея была реализована отечественной компанией «НеоБИТ», изготовившей гибридную ОС «Linux over Febos», в которой прикладные программы выполняются в виртуальных машинах ОС Linux, выступающих, в свою очередь, в роли прикладных программ ОС «Фебос» - собственной разработки «НеоБИТ», не имеющей отношения к семейству ОС Linux. Фактически, ОС «Фебос», насколько можно судить по доступным описаниям, не содержит в себе ничего, кроме микроядра, гипервизора и монитора безопасности, все прикладные интерфейсы вынесены в виртуальные машины ОС Linux.

ОС «Заря» разработана АО «Центральный научно-исследовательский институт экономики информатики и систем управления» (ЦНИИ ЭИСУ) по заказу Минобороны России в 2013 г. Данная ОС основана на ОС CentOS Linux, доступные в сети Интернет схемы её архитектуры не содержат никаких уникальных особенностей, существенно отличающих её от других ОС семейства Linux. Некоторые источники позиционируют ОС «Заря» как следующее поколение ОС МСВС. ОС «Заря» совместима с пакетами ПО Libre Office, GIMP и Chromium, существуют версии ОС для настольных, серверных и встраиваемых систем.

В 2013-2014 гг. компанией «Ред Софт» по заказу Федеральной службы судебных приставов России разработана ОС «ГосЛинукс», также основанная на ОС CentOS, которая позиционируется как защищённая ОС с функциями позволяющими «приставу обрабатывать персональные данные должников и взыскателей без дополнительных средств защиты информации, а также применять электронную подпись для издания документов в электронном виде». На официальном сайте ФССП России утверждается, что «основные доработки, выполненные подрядчиком, касались криптографической подсистемы и предконфигурации встроенных средств защиты информации»

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

2.Архитектура, назначение и области применения Операционной Системы Специального Назначения Astra Linux Special Edition

2.1. Назначение ОССН

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

Дополнительным аспектом, актуальным для современных условий, являются вопросы ограничения применения в рамках АС (в первую очередь функционирующих в интересах органов государственной власти) продукции иностранного производства, для которой существуют отечественные аналоги. В частности, изменения, внесённые в Федеральные законы «Об информации, информационных технологиях и о защите информации» и «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд», имеют прямое отношение к курсу на импортозамещение, базирующемуся на тенденциях развития рынка российского ПО.

При этом в ходе решения этой задачи важным фактором является строгое соответствие подобных разработок национальным стандартам в области информационной безопасности, например, для АСЗИ - это ГОСТ 51583-2014 «Защита информации. Порядок создания автоматизированных систем в защищённом исполнении. Общие положения», и требованиям отечественных систем сертификации средств защиты информации по требованиям безопасности информации.

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

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

Указанные возможности ОССН подтверждаются следующими сертификатами соответствия участников отечественных систем сертификации средств защиты информации по требованиям безопасности информации (табл. 2.1).

Таблица 2.1.

Эти сертификаты дают основания для использования ОССН в составе АС различных классов защищённости от несанкционированного доступа к информации (НСД) и уровней контроля отсутствия недекларируемых возможностей (НДВ) в составе компонентов системы (табл. 2.2).

Группа АС Однопользовательская АС (группа 3) Многопользовательская АС с равными полномочиями (группа 2) Многопользовательская АС с разными полномочиями (группа 1)
Класс АС ЗБ ЗА
Класс СВТ 5 3 2 1 5 3 2 1 5 5 4 3
Уровень контроля отсутствия НДВ 4 3 2 1 4 3 2 1 4 4 3 2

Из табл. 2.2 следует, что ОССН в предельном случае сертифицирована для использования в многопользовательских АС, пользователи которых имеют разные полномочия по доступу к обрабатываемой информации (класс 1Б), по классу 3 защиты от НСД и уровню 2 контроля отсутствия НДВ.

Таким образом, в настоящее время ОССН является операционной системой, сертифицированной во всех трех системах сертификации средств защиты информации по требованиям безопасности информации.

2.2. Архитектура ОССН

Архитектурной основой ОССН является проект Debian GNU/ Linux - ассоциация разработчиков свободного ПО, основой которого являются ОС семейства GNU /Linux на базе ядра Linux Kernel.

В связи с этим, в общем случае, архитектура ОССН соответствует архитектурным решениям GNU/Linux (рис. 2.1).

При этом особенности реализации соответствуют особенностям реализации ОС проекта Debian GNU/Linux, в частности:

  • активная поддержка последних версий стандартов в рамках проектов Linux FSH и LSB;
  • наличие более одиннадцати официальных переносов (портов) на различные процессорные архитектуры;
  • наличие системы управления пакетами программ APT (Advanced Packaging Tool) с жёсткой политикой по отношению к разрабатываемому ПО, поддержкой разветвлённой сети репозиториев и стандарта механизм выбора предпочтительного ПО среди нескольких вариантов (alternatives);
  • большое количество (более 40 тысяч) пакетов совместимого прикладного ПО;
  • развитая система устранения ошибок, обеспечивающая высокое качество кода драйверов, системных сервисов и поддерживающая высокую стабильность функционирования ОС на базе проекта Debian GNU/Linux.

Благодаря тому, что дистрибутив проекта Debian GNU/Linux перенесён на различные процессорные архитектуры, ОССН также оддерживает переносы на следующие архитектуры:

  • amd64 - процессоры Intel и AMD с микропроцессорной архитектурой а;86-64;
  • armel/armhf- 32 и 64-разрядные процессорные ядра разработки ARM Limited;
  • s390.r - 64-разрядное пространство пользователя для мэйнфреймов IBM System z.

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

В установленном дистрибутиве ОССН полное обозначение релиза дистрибутива в файле /etc/astra-veision хранится в следующем формате:

EDITION V.U.Y (name)

где использованы следующие обозначения:

EDITION - редакция релиза дистрибутива (для ОССН имеет значение «SE»);

V — первая цифра номера релиза, связанная с его именем;

U — номер версии релиза;

Y — номер обновления в пределах версии релиза (если таких обновлений не было, то номер обновления отсутствует);

(name) - имя релиза дистрибутива на латинице (связано с его редакцией и первой цифрой номера версии), как правило, для этого используются названия городов-героев Российской Федерации.

Релизы дистрибутива ОССН и их обозначения для версии 1.4 представлены в табл. 2.3.

Текущий релиз – 1.5.

Релиз «Смоленск» операционной системы специального назначения Astra Linux Special Edition предназначен для функционирования на средствах вычислительной техники с процессорной архитектурой х86-64.

Релиз «Новороссийск» предназначен для функционирования на мобильных и встраиваемых компьютерах с процессорной архитектурой ARM.

Архитектура ARM (от англ. Advanced RISC Machine - усовершенствованная RISC-машина; иногда - Acorn RISC Machine) - семейство лицензируемых 32-битных и 64-битных микропроцессорных ядер разработки компании ARM Limited.

RISC (англ. reduced instruction set computer - «компьютер с сокращённым набором команд») - архитектура процессора, в котором быстродействие увеличивается за счёт упрощения инструкций, чтобы их декодирование было более простым, а время выполнения - меньшим. Первые RISC-процессоры даже не имели инструкций умножения и деления. Это также облегчает повышение тактовой частоты и делает более эффективной суперскалярность (распараллеливание инструкций между несколькими исполнительными блоками).

Релиз «Мурманск» разработан для функционирования на мэйнфреймах IBM System Z.

IBM System z (более раннее название - IBM eServer zSeries) - бренд, созданный компанией IBM для обозначения линейки мейнфреймов.

Буква Z происходит от «zero down time», которое означает «ноль времени недоступности», позволяющее непрерывно поддерживать работу сервера 24 часа в сутки, 7 дней в неделю 365 дней в году.

Релиз «Севастополь» — дистрибутив Astra Linux Special Edition, предназначенный для функционирования на настольных, мобильных и встраиваемых компьютерах с процессорной архитектурой MIPS.

MIPS (англ. Microprocessor without Interlocked Pipeline Stages, микропроцессор без состояний задержки конвейера) - микропроцессор, разработанный компанией MIPS Computer Systems (в настоящее время MIPS Technologies) в соответствии с концепцией проектирования процессоров RISC (то есть для процессоров с упрощенным набором команд). Ранние модели процессора имели 32-битную структуру, позднее появились его 64-битные версии.

Релиз «Керчь» — дистрибутив Astra Linux Special Edition, предназначенный для функционирования на высокопроизводительных серверах, базирующихся на платформах с процессорной архитектурой POWER.

POWER - микропроцессорная архитектура с ограниченным набором команд (RISC), разработанная и развиваемая компанией IBM. Название позже было расшифровано как Performance Optimization With Enhanced RISC (оптимизация производительности на базе расширенной архитектуры RISC). Этим словом также называется серия микропроцессоров, использующая указанный набор команд. Они применяются в качестве центрального процессора во многих микрокомпьютерах, встраиваемых системах, рабочих станциях, мейнфреймах и суперкомпьютерах.

В дальнейшем (если это специально не оговорено по тексту) при рассмотрении ОССН в качестве релиза дистрибутива используется релиз «Смоленск» версии 1.4. Этот релиз основан на дистрибутиве Debian GNU /Linux 7.0 (Wheezy). Детализация его архитектуры относительно обобщённой архитектуры GNU /Linux (рис. 2.1) показана на рис. 2.2.

Представленные на рис. 2.2 базовые компоненты, библиотеки и средства разработки в составе дистрибутива ОССН реализуют следующие базовые функции:

  • запуск программ, их загрузка в оперативную память и управление их выполнением;
  • поддержка вытесняющей многозадачности;
  • диспетчеризация аппаратных ресурсов компьютера между выполняющимися программами;
  • межпроцессное взаимодействие;
  • организация механизма виртуальной памяти;
  • поддержка операций ввода/вывода и логической организации запоминающих устройства (жёсткие диски, SSD-диски, оптические диски, USB-диски);
  • поддержка файловых систем;
  • поддержка ввода/вывода к периферийным устройствам;
  • поддержка стеков сетевых протоколов;
  • обеспечение многопользовательского режима работы;
  • обеспечение CLI (Command Line Interface) пользовательского интерфейса командной строки;
  • обеспечение GUI (Graphical User Interface) пользовательского графического интерфейса, в том числе и для компьютеров, обо рудованных сенсорными экранами, поддерживающими многоточечный ввод;
  • поддержку разработки и отладки прикладного ПО с CLI и GUI пользовательским интерфейсом.

Для организации доменной сетевой инфраструктуры, развёрнутой на базе ОССН, в состав её дистрибутива входит OpenLDAP - реализация протокола LDAP с открытым исходным кодом. Для формирования ключей шифрования, сертификатов открытых ключей и выполнения шифрования данных SSL/TLS соединений в состав дистрибутива ОССН входит криптографический пакет OpenSSL.

Поддержка OpenLDAP и OpenSSL обеспечивает реализацию функции единого пространства пользователей (ЕПП) в рамках доменной инфраструктуры Astra Linux Directory (ALD) с поддержкой резервирования контроллеров домена и установления между ними отношений доверия.

Кроме базовых компонентов, библиотек и средств разработки в состав дистрибутива ОССН входит общее ПО, реализующее следующие функции:

  • обработка документальной информации (текстовые, табличные редакторы и средства создания презентационных материалов и доступа к реляционным базам данных);
  • сканирование, печать и передача документальной информации;
  • доступ к информации, хранящейся в реляционных базах данных, включая поддержку программного обеспечения «1C» и программного обеспечения для работы с географическими объектами PostGIS;

Таблица 2.5. Наименование и версии общего ПО дистрибтива ОССН.

Защищенная система управления базами данных (СУБД)
PostgreSQL 9.2.14 и 9.4.5
Работа с документами. Пакет офисных программ.
LibreOffice (текстовый редактор, табличный редактор, программа подготовки презентаций, механизм подключения к внешним СУБД, векторный графический редактор, редактор формул) 5.0.2
Защищенный комплекс программ гипертекстовой обработки данных
Web-сервер Apache2 2.2.22
Браузер Firefox 44.0
Защищенные средства передачи электронной почты
Сервер электронной почты Exim4 4.82
Сервер электронной почты Dovecot 2.1.7
Почтовый клиент Thunderbird 38.5.0
Редактор растровой графики
GIMP 2.8.14

доступ к информации через сервер гипертекстовой обработки данных (HTTP-сервер и клиент);

  • обмен сообщениями электронной почты (SMTP/IMAP серверы и клиент);
  • работа с графикой и мультимедиа (звук, видео).

Наименование и версии перечисленных видов ПО представлены в табл. 2.5.

Ключевой особенностью дистрибутива ОССН является то, что в его состав входят СЗИ, обеспечивающие реализацию следующих функций:

  • аутентификация пользователей с использованием инфраструктуры РАМ (Pluggable Authentication Modules) локально и в рамках ЕПП, двухфакторная аутентификация на основе цифровой подписи и инфраструктуры открытых ключей, поддерживаемых внешним носителем аутентификационной информации «Рутокен»;
  • идентификация пользователей с использованием модульного окружения NSS (Name Service Switch) локально и в рамках ЕПП ;
  • дискреционное управление доступом процессов (субъект-сессий) к ресурсам (сущностям) с поддержкой стандартов Minimal ACL и Extended ACL (в последующих версиях ОССН дискреционное управление доступом будет заменено ролевым управлением доступом в сочетании с мандатными управлением доступом и контролем целостности, реализованными на основе мандатной сущностно-ролевой ДП- модели - МРОСЛ ДП-модели, базовые элементы которой будут рассмотрены в следующих лекциях);

Вместо системы принудительного контроля доступа SELinux, в Astra Linux Special Edition используется запатентованная мандатная сущностно-ролевая ДП-модель управления доступом и информационными потокам (МРОСЛ ДП-модель)

  • основанное на МРОСЛ ДП-модели мандатное управление доступом процессов к ресурсам, реализация которого в ОССН осуществляется на уровнях механизма межпроцессного взаимодействия, включая файловые системы ртос и tmpfs, стек протоколов TCP/IP {IPv4), на уровне виртуальной файловой системы (VFS) и в файловых системах семейства extfs {Ext2, Ext3, Ext4);
  • изоляция адресных пространств процессов;
  • регистрация (протоколирование) и аудит событий, реализованные в виде централизованной системы с функцией оповещения администратора безопасности о попытках НСД;
  • очистка оперативной памяти и освобождаемых областей данных на носителях с файловыми системами Ext2, Ext3, Ext4:
  • регламентный контроль целостности сущностей файловой системы, в том числе неизменности исполняемых файлов и соответствия эталонному дистрибутиву ОССН, на основе библиотеки libgost, в которой реализована функция хэширования в соответствии с ГОСТ Р 34.11-94 , и мандатный контроль целостности, препятствующий доступу к защищаемой информации скомпрометированными субъектами после перехвата управления и повышения привилегий (элементы мандатного контроля целостности также заданы в рамках МРОСЛ ДП-модели и рассмотрены в главе 2);
  • базирующаяся на мандатном контроле целостности замкнутая программная среда, позволяющая определить для каждой учётной записи пользователя индивидуальный перечень ПО, разрешённого для использования, с возможностью загрузки иерархических цепочек ключей для проверки цифровой подписи исполняемых файлов формата ELF (Executable and Linkable Format), реализованной в соответствии с ГОСТ Р 34.10-2001 ;
  • маркировка документов уровнями конфиденциальности при выводе их на печать;
  • обеспечение надёжного восстановления ОССН после сбоев;
  • реализация правил управления доступом к внешним носителям (для этого в рамках МРОСЛ ДП-модели заданы сущности с косвенными метками);
  • обеспечение доступа к реляционным базам данных в соответствии с требованиями для управления доступом к информации, содержащей сведения, составляющие государственную тайну с грифом не выше «совершенно секретно», совместимого с реализованными в ОССН мандатным управлением доступом и мандатным контролем целостности (с этой целью МРОСЛ ДП-модель была расширена для использования с штатной для ОССН СУБД PostgreSQL);
  • обеспечение доступа к информации через сервер гипертекстовой обработки данных, обмена сообщениями электронной почты в соответствии с требованиями для управления доступом к информации, содержащей сведения, составляющие государственную тайну с грифом не выше «совершенно секретно». Дополнительно в состав ядра дистрибутива ОССН добавлен пакет дополнений модуля РаХ (средство ограничения прав доступа к страницам памяти), обеспечивающий выполнение программного обеспечения в режиме наименьших привилегий и защиту от эксплуатации в нём различных уязвимостей путём:
  • запрета записи в область памяти, помеченную как исполняемая;
  • запрета создания исполняемых областей памяти;
  • запрета перемещения сегмента кода;
  • запрета создания исполняемого стека;
  • случайного распределение адресного пространства процесса. Важным компонентом ОССН является подсистема обеспечения безопасности PARSEC, расширяющая стандартную для ОС семейства Linux систему привилегий, предназначенную для передачи пользователям прав выполнения функций администратора ОССН с поддержкой мандатного управления доступом и мандатного контроля целостности. Подсистема PARSEC поддерживает следующие расширенные привилегии:
  • посылать сигналы процессам, игнорируя дискреционные и мандатные правила управления доступом;
  • изменять уровни доступа (мандатные метки) учётных записей пользователей и устанавливать другие привилегии;
  • менять уровни конфиденциальности (мандатные метки) конфиденциальности файлов;
  • управлять политикой аудита;
  • игнорировать правила мандатного управления доступом при чтении и поиске файлов (исключая функцию записи);
  • создавать привилегированный сокет и менять его уровень конфиденциальности;
  • изменять время доступа к файлу;
  • игнорировать мандатное управление доступом по уровням конфиденциальности и неиерархическим категориям;
  • устанавливать привилегии на файлы;
  • устанавливать любой непротиворечивый набор привилегий для выбранного процесса;
  • менять уровень конфиденциальности точки сетевого соединения.

Подсистема безопасности PARSEC реализует указанные расширенные привилегии с использованием механизма перехвата системных вызовов (hook), который перехватывает и анализирует аргументы запросов процессов и в соответствии с установленными правилами мандатного управления доступом разрешает или запрещает их. Таким образом, в ОССН мандатный контекст (используемые в запросе уровни конфиденциальности, доступа и целостности) считывается при выполнении каждого запроса локально или удалённо (в рамках ЕПП) запущенного процесса.

Уникальной особенностью подсистемы обеспечения безопасности PARSEC является её реализация в качестве модуля XPARSEC, расширяющего функциональность сервера X.Org и’менеджера окон Fly-wm. Благодаря этому модулю сервер X.Org получает возможность определения привилегий X.Org клиента (программы с GUI интерфейсом) и передачи их с использованием модифицированного Х-протокола менеджеру окон Fly-wm, который и выполняет привилегированные операции в ходе запуска X.Org клиента с различными мандатными контекстами. При этом на рабочем столе Fly выполняется отображение:

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

2.3. Области применения ОССН

Рассмотренные архитектурные особенности ОССН, как реализация ЕПП на основе доменной сетевой инфраструктуры ALD, и интегрированный в состав дистрибутива ОССН комплекс СЗИ определяют её основные области применения, которые в общим случае заданы разработчиком по следующим направлениям программно-технические комплексы и комплексы средств автоматизации;

  • локальные (корпоративные) компьютерные сети;
  • территориально-распределенные АС.

В настоящее время на базе дистрибутива ОССН реализован ряд проектов АСЗИ в министерствах и ведомствах: ФСБ России, ФСО России, Минобороны России, СВР России, ФСКН России, ФСИН России, ФТН России, ГУПС России, Минздрав России, Минобрнауки России, внутренних войсках МВД России; государственных корпорациях и агентствах: Росатом, Роскосмос, Ростехнологии, ряде предприятий военно-промышленного комплекса; в рамках межведомственной информационной системы государственной автоматизированной системы государственного оборонного заказа (ГАС ГОЗ).

На рис. 2.3 представлен вариант реализации корпоративной защищённой локальной вычислительной сети (ЗЛВС), поддерживающей мультисервисную систему связи, которая обеспечивает реализацию защищённых сервисов:

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

Указанные сервисы реализуются на базе серверных платформ, которые функционируют в серверном варианте установке ОССН релиза «Смоленск». В качестве клиентских компьютеров такой ЗЛВС выступают:

  • стационарные или мобильные компьютеры с процессорной архитектурой Intel х86-64, функционирующие в клиентском варианте установки ОССН релиза «Смоленск»;
  • планшетные компьютеры с процессорной архитектурой ARM, функционирующие в клиентском варианте установки ОССН релиза «Новороссийск».

На рис. 2.3 показано, что для абонентов корпоративной ЗЛВС организуется ЕПП на базе домена сетевой инфраструктуры ALD с выделенным контроллером домена, функционирующим в серверном варианте установки ОССН релиза «Смоленск». Дополнительно в рамках такой ЗЛВС может быть развернут частный облачный сервис (Private Cloud), реализуемый с использованием технологий виртуализации ОССН релиза «Смоленск» (рис. 2.4).

В условиях удалённого доступа к ресурсам рассмотренной на риc. 2.3 ЗЛВС через арендованные у провайдера телекоммуникационных услуг каналы связи, мобильные АРМ удалённых абонентов ЗЛВС могут подключаться к серверам ЗЛВС с использованием, например, механизмов VPN/MPLS . При этом на границе корпоративного сегмента ЗЛВС устанавливается граничный криптомаршрутизатор - межсетевой экран, который может функционировать на базе ОССН релиза «Тула». Пример схемы подобной реализации удалённого доступа к ЗЛВС представлен на рис. 2.5.

Таким образом, комплект релизов ОССН обеспечивает возможность создания как АСЗИ на различных программно-аппаратных платформах, так и различных конфигураций защищённых компьютерных сетей, включающих, в том числе облачные технологии и механизмы защищённого удалённого доступа.

15.04.2001 Руслан Богатырев

Еще никогда в истории реальный мир так не зависел от мира искусственного, придуманного и построенного самим человеком - Интернет не только навел мосты между странами и континентами, но и приблизил преступника к жертве. Как следствие, наметился интерес к достоверным (trusted) и защищенным (secure) операционным системам.

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

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

  • концентрацию вычислительных и информационных ресурсов (в эпоху мэйнфреймов);
  • обеспечение технической доступности компьютерных мощностей для массовой аудитории (в эпоху ПК);
  • ломку естественных границ пространства и времени в масштабах мировой экономики и политики (в эпоху Internet).

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

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

По данным годового отчета «2001 Computer Crime and Security Survey» Института компьютерной безопасности в Сан-Франциско и ФБР, финансовые потери от компьютерных преступлений в США за минувший год выросли на 43% с 265,6 млн. долл. до 377,8 млн. При этом 85% респондентов из 538, в основном из промышленных и государственных структур, заявили о фактах нарушения компьютерной безопасности, причем не только из-за атак злоумышленников. Почти 64% были озабочены понесенными убытками, но лишь 35% смогли оценить их в денежном выражении. Около 70% респондентов заявили, что чаще всего атакам подвергались Internet-каналы, а 31% показали, что атакам подвергались внутрикорпоративные системы. Случаи вторжения извне подтверждали 40% респондентов (в 2000 г. - 25%), а 38% фиксировали отказ в обслуживании (27% в 2000 г.). На нарушение привилегий из-за злоупотребления сотрудниками работой в Сети жаловались 91% респондентов, а 94% обнаружили в своих системах вирусы (в 2000 г. это отмечали 85%).

Даже из этих скупых цифр видна явно негативная тенденция - Internet не только возводит мосты между странами и континентами, но и приближает преступника к жертве. Перефразируя известное изречение, можно сказать, что если вы не интересуетесь киберкриминалом, очень скоро киберкриминал заинтересуется вами. Если оставить в стороне извечные вопросы разведки и промышленного шпионажа и сосредоточиться только на «бытовой» стороне дела, то одними из ведущих проблем в области информационной безопасности в минувшем году стали атаки на платежные системы, дискредитация компаний (отказ в обслуживании), производственный саботаж, вскрытие корпоративных секретов, нарушение прав интеллектуальной собственности. По оценкам отдела по науке и технологиям при Президенте США, ежегодный урон, наносимый американскому бизнесу компьютерными злоумышленниками в последние годы, достигал 100 млрд. долл. Потери от несанкционированного доступа к информации, связанной с деятельностью финансовых институтов США, составляли не менее 1 млрд. долл. в год. Таким образом, американский бизнес вплотную подошел к тому рубежу, когда своевременное и адекватное решение вопросов безопасности для него становится экономически целесообразным.

Unix в контексте безопасности

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

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

В работе сотрудников Агентства национальной безопасности США приводится подробный анализ проблем, стоящих перед существующим поколением операционных систем в плане компьютерной безопасности. Основной вывод: нужны новые специально спроектированные защищенные ОС. В частности, авторы говорят о том, что система Kerberos, протоколы SSL и IPSEC в значительной степени уязвимы в силу того, что при невозможности обеспечить наличие достоверного ПО на концах соединения защита становится иллюзорной.

Вот что сказал в своем недавнем интервью Элиас Леви (Aleph1), модератор известного списка рассылки BugTraq, посвященного проблемам компьютерной безопасности: «Я считаю, что модель безопасности в Unix чересчур упрощенная. Подход «все или ничего» оказывается никуда не годным по сравнению с принципом наименьших полномочий (least privilege)... Достоверная вычислительная база (Trusted Computing Base) никогда не предоставит всего того, что требовалось бы пользователю. С другой стороны, я нахожу, что большинство реализаций механизмов принудительного управления доступом (mandatory access control), привилегиями и т.д. слишком усложнены... В конечном итоге трудно предсказать те взаимодействия, которые приведут к появлению слабых мест. Вспомним хотя бы проблему sendmail, которая появилась в результате полномочий, внедренных в ядро Linux».

Леви призывает отказаться от практики «латания дыр» и начать строить новую ОС, изначально удовлетворяющую требованиям безопасности.

Это перекликается с наметившимся сегодня интересом к достоверным (trusted) и защищенным (secure) операционным системам. Требования к безопасности должны быть определяющими в проектировании ОС, а не вводиться как вспомогательные службы.

Критерии и ориентиры в области безопасности

Работы над критериями безопасности систем начались еще в 1967 г. и в 1970 г. появился первый отчет под названием «Security Controls for Computer Systems ». В 1983 г. Министерство обороны США выпустило «Orange Book » - книгу в оранжевой обложке под названием «Критерии оценки достоверных компьютерных систем» (Trusted Computer Systems Evaluation Criteria). Область компьютерных сетей в отношении безопасности определялась в так называемых рекомендациях X.800 - Security Architecture for Open Systems Interconnection for CCITT Applications. В «Оранжевой книге» достоверная система определяется как «система, использующая достаточные аппаратные и программные средства для обеспечения одновременной обработки информации разной степени секретности группой пользователей без нарушения прав доступа».

Выделяются два основных критерия оценивания достоверных систем:

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

В соответствии с «Оранжевой книгой» выделяются три роли: системный администратор, системный оператор и администратор безопасности. Согласно требованиям TCSEC документация производителя должна включать в себя четыре важных элемента: политику безопасности; интерфейсы достоверной вычислительной базы; механизмы TCB; руководство по эффективному использованию механизмов TCB.

Вообще говоря, в область защищенных компонентов входят не только операционные системы. Так, в частности, в дополнение к «Оранжевой книге» TCSEC, регламентирующей вопросы обеспечения безопасности в ОС, существуют аналогичные документы Национального центра компьютерной безопасности США для СУБД (TDI, «Пурпурная книга ») и сетей (TNI, «Красная книга »). Так что «Оранжевая книга» - не единственный, хотя и важный документ. В США давно уже появилась целая серия документов в разноцветных обложках, получившая название «Радуга» (Rainbow Series ; www.radium.ncsc.mil/tpep/library/ rainbow). При этом, как видно из врезки, иногда под обложкой одного и того же цвета выступал разный материал.

За пределами США также появились аналоги «Оранжевой книги»: это руководящие документы Гостехкомиссии (1992 г.), а также «Критерий оценки безопасности информационных технологий» (ITSEC - Information Technology Security Evaluation Criteria, 1991), действующий в Великобритании, Германии, Франции и Нидерландах.

Конечно же, в силу необходимости унификации подходов к информационной безопасности в конце концов возникла потребность снять двойственность регулирования, которая отдельно велась в США (TCSEC) и Европе (ITSEC). На рис. 1 показано «генеалогическое древо» принятия нового международного стандарта, получившего название «Единые критерии для оценки безопасности в области информационных технологий» . Чаще всего его называют просто «Common Criteria» («Единые критерии»), определяющие международный стандарт ISO/IEC 15408, в разработке которого приняли участие Агентство национальной безопасности и Национальный институт стандартов и технологий (США), Группа по безопасности в области электроники и передачи данных (Великобритания), Федеральное агентство в области информационных технологий (Германия), Центральная служба безопасности информационных систем (Франция), Агентство национальной безопасности Нидерландов в области передачи данных, Служба безопасности в области передачи данных (Канада).

Описание Common Criteria V2.1 содержится в трех книгах:

  1. Введение и общая модель (CCIMB-99-031).
  2. Функциональные требования к безопасности (CCIMB-99-032).
  3. Требования к гарантиям безопасности (CCIMB-99-033).

В «Единых критериях » выделяются 11 функциональных классов:

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

Внутри каждого их этих классов содержится несколько семейств, а в каждом семействе - от одного до нескольких компонентов.

Критерии, сформулированные в TCSEC, ITSEC и CCITSE, определяют разбиение компьютерных систем на 4 уровня безопасности (A, B, C, D) в зависимости от степени достоверности. Уровень A самый высокий. Далее идет уровень B (в порядке понижения безопасности здесь идут классы B3, B2, B1). Затем наиболее распространенный уровень C (классы C2 и C1). Самый нижний уровень - D (системы, которые не смогли получить аттестацию по заявленным выше классам).

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

Литература

1. П. Христов. Безопасность данных в ОС UNIX // «Открытые системы», 1993, № 3
2. В. Галатенко. Информационная безопасность // «Открытые системы», 1995, № 4, 1996, № 1
3. Р. Богатырев. Linux: истоки новой философии программирования // Мир ПК, 2001, No.1.
4. 2001 Computer Crime and Security Survey // Computer Security Institute, San Francisco, March 12, 2001; www.gocsi.com/prelea_000321.htm
5. Common Criteria for Information Technology Security Evaluation (CCITSE) V2.1 // 1998; www.radium.ncsc.mil/tpep/library/ccitse/ccitse.html
6 P. Loscocco et al. The Inevitability of Failure: The Flawed Assumptiom of Security in Modern Computing Environments // National Security Agency, 1998.

Руслан Богатырев

Тематика набора книг по компьютерной безопасности TCSEC в серии «Радуга»

  • TCSEC (1983, 1985, «Оранжевая книга», 5200.28-STD).
  • TNI, интерпретация достоверных компьютерных сетей (1987, 1990, «Красная книга», NCSC-TG-005, NCSC-TG-011).
  • TDI, интерпретация достоверных СУБД (1991, «Пурпурная книга», NCSC-TG-021).
  • Системы формальной верификации (1989, «Пурпурная книга», NCSC-TG-014).
  • Производство достоверных систем (1992-1994, «Пурпурные книги», NCSC-TG-024).
  • Защита доступа (1992, «Фиолетовая книга», NCSC-TG-028).
  • Доверительное распределение (1988, «Темнолиловая книга», NCSC-TG-008).
  • Создание документации (1988, «Рубиновая книга», NCSC-TG-007).
  • RAMP (1995, «Розовая книга», NCSC-TG-013).
  • Анализ тайных каналов (1993, «Светлорозовая книга», NCSC-TG-030).
  • Тестирование безопасности (1991, «Яркооранжевая книга», NCSC-TG-023).
  • Дискреционное управление доступом (1987, «Неоновая книга», NCSC-TG-003).
  • Правила создания руководств пользователя (1991, «Персиковая книга», NCSC-TG-026).
  • Управление конфигурациями (1988, «Янтарная книга», NCSC-TG-006).
  • Требования к компьютерной безопасности (1985, «Яркожелтая книга», CSC-STD-003-85).
  • Технические уточнения для требований к компьютерной безопасности (1985, «Желтая книга», CSC-STD-004-85).
  • Достоверное восстановление после сбоев (1991, «Желтая книга», NCSC-TG-022).
  • Написание руководств для управления достоверными средствами (1992, «Желто-зеленая книга», NCSC-TG-016).
  • Комплектование данных в автоматизированных информационных системах (1991, «Бледнозеленая книга», NCSC-TG-025).
  • Управление паролями (1985, «Зеленая книга», CSC-STD-002-85).
  • Терминологический словарь в области компьютерной безопасности (1988, «Темнозеленая книга», NCSC-TG-004).
  • Моделирование безопасности (1992, «Зеленовато-голубая книга», NCSC-TG-010).
  • Компетенция администратора безопасности (1992, «Бирюзовая книга», NCSC-TG-027).
  • Идентификация и аутентификация (1991, «Светлоголубая книга», NCSC-TG-017).
  • Многократное использование объектов (1992, «Светлоголубая книга», NCSC-TG-018).
  • Анкетирование при оценивании достоверных систем (1992, «Голубая книга», NCSC-TG-019).
  • Концепции сертификации и аккредитации (1994, «Голубая книга», NCSC-TG-029).
  • Оценивание достоверных продуктов (1990, «Яркоголубая книга», NCSC-TG-002).
  • Интерпретация подсистем компьютерной безопасности (1988, «Небесноголубая книга», NCSC-TG-009).
  • Управление достоверными средствами (1989, «Коричневая книга», NCSC-TG-015).
  • Аудит в достоверных системах (1988, «Светлокоричневая книга», NCSC-TG-001).
  • TRUSIX (1989, «Серебряная книга», NCSC-TG-020).

Классы безопасности компьютерных систем (TCSEC, Common Criteria)

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

Класс С1. Избирательная защита доступа. Предусматривает наличие достоверной вычислительной базы (TCB), выполнение требований к избирательной безопасности. Обеспечивается отделение пользователей от данных (меры по предотвращению считывания или разрушения данных, возможность защиты приватных данных). В настоящее время по этому классу сертификация не предусмотрена.

Класс C2. Управляемая защита доступа. Системы данного класса способны осуществлять более четко выделенный контроль в плане избирательной защиты доступа. Действия пользователя связываются с процедурами идентификации/аутентификации. Наделение и лишение пользователей привилегий доступа. Кроме этого, ведется аудит событий, критичных с точки зрения безопасности, выполняется изоляция ресурсов. По данному классу сертифицированы: AIX 4.3.1, OS/400 V4R4M0 with Feature Code 1920, AOS/VS II, Release 3.10, OpenVMS VAX and Alpha Version 6.1, CA-ACF2 MVS Release 6.1, NT Workstation и NT Server, Ver. 4.0, Guardian-90 w/Safeguard S00.01.

Класс B1. Маркированное обеспечение безопасности. В дополнение к требованиям класса C2 необходимо неформальное описание модели политики безопасности, маркировки данных, а также принудительного управления доступом к поименованным субъектам и объектам. По этому классу сертифицированы: CA-ACF2 MVS Release 6.1 в комплекте с CA-ACF2 MAC, UTS/MLS, Version 2.1.5+ (Amdahl), SEVMS VAX and Alpha Version 6.1, ULTRIX MLS+ Version 2.1 на платформе VAX Station 3100, CX/SX 6.2.1 (Harris Computer Systems), HP-UX BLS release 9.0.9+, Trusted IRIX/B release 4.0.5EPL, OS 1100/2200 Release SB4R7 (Unisys).

Класс B2. Структурированная защита. В этом классе систем TCB должна опираться на четко определенную и документированную формальную модель политики безопасности. Действие избирательного и принудительного управления доступом распространяется на все субъекты и объекты в системе. Выявляются тайные каналы (covert channel). TCB должна четко декомпозироваться на элементы, критичные и некритичные с точки зрения безопасности. Усиливаются механизмы аутентификации. Обеспечивается управление механизмами достоверности в виде поддержки функций системного администратора и оператора. Подразумевается наличие механизмов строгого управления конфигурацией. Система относительно устойчива к вторжению. По данному классу сертифицирована Trusted Xenix 4.0 (Trusted Information Systems).

Класс B3. Домены безопасности. TCB должна удовлетворять требованиям эталонного механизма мониторинга, который контролирует абсолютно весь доступ субъектов к объектам и при этом быть достаточно компактным, чтобы его можно было проанализировать и оттестировать. Требуется наличие администратора по безопасности. Механизмы аудита расширяются до возможностей оповещения о событиях, критичных по отношению к безопасности. Требуются процедуры восстановления системы. Система крайне устойчива к вторжению. По данному классу сертифицирована XTS-300 STOP 5.2.E (Wang Government Services).

Класс A1. Верифицированное проектирование. Данный класс систем функционально эквивалентен классу B3 в том смысле, что не требуется добавления дополнительных архитектурных особенностей или предъявления иных требований к политике безопасности. Существенное отличие состоит в том, что для гарантии корректной реализации TCB требуется наличие формальной спецификации проектирования и соответствующих методов верификации. В данном классе не зарегистрировано ни одной ОС.