Защищенные операционные системы. Какая мобильная ос самая защищенная

Основные определения

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

Если операционная система предусматривает защиту не от всех основных классов угроз, а только от некоторых, такую операционную систему будем называть частично защищенной . Например, операционная система MS-DOS с установленным антивирусным пакетом является частично защищенной системой - она защищена от компьютерных вирусов.

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

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

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

Существуют два основных подхода к созданию защищенных операционных систем - фрагментарный и комплексный.

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

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

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

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

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

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

Основные административные меры защиты.

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

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

3. Инструктирование пользователей операционной системы о необходимости соблюдения мер безопасности при работе с операционной системой и контроль за соблюдением этих мер.

4. Регулярное создание и обновление резервных копий программ и данных операционной системы.

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

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

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

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

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

2. Любая система, в которой предусмотрены функции защиты информации, требует от администраторов определенных усилий, направленных на поддержание адекватной политики безопасности. Чем больше в операционной системе защитных функций, тем больше времени и средств нужно тратить на поддержание защиты.

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

4 Поддержание слишком жесткой политики безопасности может негативно сказаться на надежности функционирования операционной системы. Один из примеров такой политики безопасности описан в Windows NТ FAQ. Windows NT позволяет администраторам ограничивать права системных процессов на доступ к объектам операционной системы. Если запретить псевдопользователю SISTEM, от имени которого выполняются системные процессы, доступ к исполняемым файлам системных процессов, операционная система, как и следовало ожидать, не сможет загрузиться. В данном случае чрезмерно жесткая политика безопасности приводит к моментальному краху операционной системы, в других случая подобная политика безопасности может приводить к трудновыявляемым ошибкам и сбоям в процессе функционирования операционной системы, что еще более опасно.

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

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

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

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

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

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

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

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

Cтандарты защищенности операционных систем

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

Наиболее известным стандартом безопасности компьютерных систем является документ под названием "Критерии безопасности компьютерных систем" (Trusted computer system evaluatii criteria), разработанный Министерством обороны США в 1983 г. Этот документ более известен под неформальным названием "Оранжевая книга». Согласно "Оранжевой книге" все защищенные компьютерные системы делятся на семь классов от D1 (минимальная защита, фактически отсутствие всякой защиты) до А1 (максимальная защита). Основные требования "Оранжевой книги" в применении к операционным системам можно сформулировать следующим образом (очень упрощенно).

Класс D1. Никаких требований. К этому классу относятся все операционные системы, не удовлетворяющие требованиям высших классов

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

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

Класс В1. Выполняются все требования класса С2. Поддерживается полномочное (мандатное) разграничение доступа к объектам операционной системы. Поддерживается маркировка экспортируемой информации.

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

Требованиям класса С2 удовлетворяют многие известные операционные системы: ряд версий UNIX, Wndows NT, OS/400, VAX/VMS и IBM MVS с пакетом RACF. Операционных систем для персональных компьютеров, удовлетворяющих требованиям более высоких классов защиты, очень мало. Это объясняется, с одной стороны, большой "ресурсоемкостью" подсистем защиты, соответствующих требованиям класса В1 и выше, и, с другой стороны, трудностями обеспечения нормального функционирования распространенного программного обеспечения в таких операционных системах. Если требования класса С2 позволяют применять в защищенной операционной системе программное обеспечение, разработанное для дру­гих программных сред (например, в Windows NT можно запускать Microsoft Office для Windows 95), то требования более высоких классов защиты настолько жестки, что заметно мешают функционированию прикладных программ, разработанных без учета этих требований. Например, текстовый редактор Microsoft Word, будучи запущен в операционной системе, удовлетворяющей требованиям класса В1, будет некорректно функционировать при одновременном открытии документов с различным грифом секретности.

К основным недостаткам "Оранжевой книги" относятся следующие:

Совершенно не рассматриваются криптографические средства защиты информации;

Практически не рассматриваются вопросы обеспечения защиты системы от атак, направленных на временный вывод системы из строя (атаки класса "отказ в обслуживании");

Не уделяется должного внимания вопросам защиты защищаемой системы от негативных воздействий программных закладок и компьютерных вирусов;

Недостаточно подробно рассматриваются вопросы взаимодействия нескольких экземпляров защищенных систем в локальной или глобальной вычислительной сети;

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

Стандарты защищенности и адекватная политика безопасности

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

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

Для примера рассмотрим некоторые требования к конфигурации операционной системы Windows NT, которые должны выполняться для соответствия защищенности операционной системы классу С2 "Оранжевой книги":

На жестких дисках используется только файловая система NTFS;

Запрещено использование паролей короче шести символов;

Запрещена эмуляция OS/2 и POS1X;

Запрещен анонимный и гостевой доступ;

Запрещен запуск любых отладчиков;

Тумблер питания и кнопка RESET недоступны пользователям;

Запрещено завершение работы операционной системы без входа пользователя в систему;

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

Запрещено разделение между пользователями ресурсов сменных носителей информации (флоппи-дисков, CD-ROM и т.д.);

Запись в системную директорию и файлы инициализации операционной системы разрешена только администраторам и системным процессам.

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

Введение

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

Из табл. 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. Наименование и версии общего ПО дистрибтива ОССН.

доступ к информации через сервер гипертекстовой обработки данных (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.

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

ВВЕДЕНИЕ

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

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

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

ПОНЯТИЕ ЗАЩИЩЕННОЙ ОПЕРАЦИОННОЙ СИСТЕМЫ. SELINUX

Понятие защищенной операционной системы

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

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

– осуществляется ли проверка качества исходного кода ОС;

– какие заданы стандартные настройки безопасности;

– насколько быстро и качественно выпускаются исправления;

– как устроена система распределения полномочий и многое другое.

При выборе безопасной ОС определенно должна рассматриваться операционная система Linux.

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

Во-вторых, технология Live CD -- Linux «умеет» очень быстро запускаться и развертываться без установки на жесткий диск. Такую безопасную ОС можно записать на оптический диск или usb-накопитель и всегда иметь при себе. «По мгновению ока» возможно получить операционную систему с готовым рабочим столом и сопутствующими приложениями для работы в интернете, в независимости от установленной основной операционной системе в компьютере, которым предстоит пользоваться.

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

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

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 требуется наличие формальной спецификации проектирования и соответствующих методов верификации. В данном классе не зарегистрировано ни одной ОС.

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

Tails позволяет добиться высокой степени безопасности при работе в интернете. Благодаря тому, что весь трафик заворачивается в анонимную сеть TOR, получается высокий уровень защищённости. Но на сети TOR дело не заканчивается, по умолчанию система подменяет мак-адреса сетевых механизмов чтобы было невозможно идентифицировать само устройство, с которого выполняется выход в сеть.

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

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

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

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

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

Софт и безопасность ОС

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

В Tails есть набор нестандартных для большинства операционных систем программ, например утилита для работы с шифрованием PGP. С её помощью можно управлять ключами, шифровать и расшифровывать текст и файлы. Также присутствуют биткоин, кошелёк Electrum, менеджер паролей KeePass. Ещё, в Tails существует плеер для , обычный браузер Firefox, который подписан как "небезопасный браузер", мессенджер Pidgin и многое другое.

Давайте подытожим, что мы имеем с операционной системой Tails. Также какими основными плюсами обладает данная ОС:

• Когда загрузочная флешка при себе можно загрузиться на любом ПК, будь то в гостях, на работе или интернет-кафе, где требуется , а уровень безопасности оставляет желать лучшего.
• Благодаря шифрованию трафика через сеть TOR, провайдер не видит, чем занимается человек, а сайт не может идентифицировать пользователя.
• Подмена мак-адреса не даёт распознать устройство при подключении к общественному WI-FI.
• Переписка посредством данной ОС может быть зашифрованной, доступные транзакции через биткоин, кошелёк с фальшивым мак-адресом выполняются из сети TOR.
• Если есть постоянное хранилище — оно зашифровано.
• Операционная система работает из оперативной памяти и после работы она обнуляется, не оставляя следов на ПК.

Работая с Tails можно быть спокойным за свою анонимность и безопасность, если она действительно нужна. Вот ссылка на официальный сайт дистрибутива Tails https://tails.boum.org/ . Ваши вопросы можно задать в комментариях, либо перейдите на страницу "Контакты" заполните и пошлите мне форму.