1. Режимы функционирования СЗИ
Каждый разумный владелец или пользователь информационной системы (IT-инфраструктуры) хотел бы, чтобы она работала устойчиво, была удобна, обрабатываемые в ней данные были доступны только тем, кому они предназначены, их нельзя было несанкционированно удалить, подменить и т.д. В той или иной степени это желание присуще пользователям всех информационных систем, больших или маленьких, государственных или частных. И совершенно не обязательно только тех систем, для которых требования по защите информации закреплены нормативно и нужны сертификаты, таких как критическая информационная инфраструктура или тех, что обрабатывают государственную тайну.
Т.е. фактически всем владельцам или пользователям информационных систем важно обеспечить их защиту от трех классических угроз: конфиденциальности, целостности и доступности. Самой исследованной и обсуждаемой из них является первая угроза. Защита от нее необходима, начиная с обеспечения безопасности личных данных, далее к коммерческой тайне и вплоть до государственной тайны. На втором месте по важности, как правило, угроза целостности. И дело здесь не только в целостности или отсутствии искажений самой информации (какого-либо контента, документа, медиа). Защита от вирусов и закладок нужна всем – они тоже проявление угрозы целостности. Третья из классических угроз – угроза доступности – не всегда по важности на последнем месте, а в ряде случаев, например, для интернет-ресурсов она выходит на передний план. Но во многих информационных системах, в особенности операционных системах (ОС), защита от нее обеспечивается средствами, изначально предназначенными для защиты от угроз целостности и конфиденциальности информации.
В этой связи в настоящей статье мы поговорим об угрозах конфиденциальности и целостности информации и о том, как им можно успешно противостоять средствами защиты информации (СЗИ) ОС Astra Linux Special Edition.
Для начала заметим, что подавляющее большинство пользователей отечественных информационных систем много лет работало с иностранными решениями, например, ОС Microsoft Windows, в которых используются СЗИ часто более развитые по сравнению с имеющимися в ОС семейства Linux. Пользователи даже не осознавали и не замечали того, что каждый день используют инструменты мандатного контроля целостности или замкнутой программной среды (о которых речь пойдет дальше). Это было само собой разумеющимся – работать в системе, в которой за ее безопасностью следят соответствующие СЗИ.
Вот почему важно, что ОС Astra Linux Special Edition (в отличие от других ОС семейства Linux) реализует СЗИ, где-то повторяющие, а чаще улучшающие функции безопасности привычных им иностранных систем. Иными словами, грамотное применение этой ОС позволяет достичь писанных или неписаных, но давно используемых стандартов качества и безопасности информационных систем.
Как известно, начиная с релиза 2021 г., в ОС Astra Linux Special Edition в зависимости от приобретенной лицензии СЗИ заказчики могут работать в одном из трех режимов (рис. 1): «Базовый» («Орел»), «Усиленный» («Воронеж») и «Максимальный» («Смоленск»). Режим «Усиленный» включает и дополняет СЗИ, реализованные в режиме «Базовый». Аналогично режим «Максимальный» включает и дополняет СЗИ режима «Усиленный». Рассмотрим их подробнее.
![Рис. 1. Компоненты и режимы функционирования СЗИ в ОС Astra Linux Special Edition Рис. 1. Компоненты и режимы функционирования СЗИ в ОС Astra Linux Special Edition](https://habrastorage.org/getpro/habr/upload_files/73e/afc/5a6/73eafc5a674c7c196b05992db147b14a.png)
Уже начиная с режима функционирования СЗИ «Базовый» в ОС Astra Linux Special Edition доступны такие функции безопасности, как изоляция процессов, защита памяти, регистрация событий безопасности и др. Однако в части используемого механизма управления доступом этот режим функционирования СЗИ мало чем отличается от того, что можно увидеть в большинстве ОС семейства Linux, в том числе отечественных. Как говорят, это режим, в котором работает только дискреционное управление доступом. Т.е. когда администраторы или даже обычные пользователи сами, без каких-то общих правил, решают кому и к каким файлам или каталогам предоставить права доступа на чтение, запись или выполнение. Это очень просто для реализации и использования, но лишает возможности определить корректность установки этих прав. При этом сложность архитектуры ОС, неочевидные зависимости её компонент друг от друга, или просто ошибки при администрировании ОС могут привести к тому, что к некоторым важным для её безопасности файлам или каталогам будут установлены неверные права доступа. Причем это не будет явно сказываться на функционировании ОС и, как следствие, не будет оперативно выявлено. Кроме того, ОС только с дискреционным управлением доступом, как правило, уязвима для типовых атак, которые разрабатывают хакеры по всему миру, так как нет того, что могло бы ее дополнительно защитить.
Поэтому часто в ОС семейства Linux используют дополнительные механизмы, позволяющие задавать сложные политики управления доступом, учитывающие особенности функционирования компонент ОС, их взаимодействия между собой. Примерами таких механизмов являются AppArmor и Security Enhanced Linux (SELinux). Первый из них расширяет дискреционное управление за счет возможности задания политик, ограничивающих доступ к компонентам ОС. Второй механизм помимо этого включает элементы типизированного, ролевого и мандатного управления доступом.
Казалось бы, всё уже есть, и не надо делать ничего своего. Так в чем проблема? А она, как обычно, кроется в фундаменте этих технологий и упирается в математику. Во-первых, несмотря на существующие исходные тексты программного кода AppArmor и SELinux, ввиду его значительного объема и сложности, это не оказывает значительного влияния на возможность проверки эффективности данных механизмов, их доработки, сопровождения, т. е. обеспечения доверия к ним. Во-вторых, собственно доверие к механизмам управления доступом, как правило, основывается на наличии для них формальной (выраженной на математическом языке) модели управления доступом. Без такой модели невозможна верификация как самих AppArmor и SELinux, так и всей системы защиты ОС.
Дело в том, что с одной стороны, формальная модель задает четкие правила игры для ОС, а именно: как назначать права доступа процессам к файлам и каталогам, как их помечать метками конфиденциальности или целостности, управлять доступом на основе этих меток в самых разных ситуациях, например, создания нового файла, учетной записи пользователя или запуска процесса. С другой стороны, модель позволяет на своем уровне абстракции сформулировать условия безопасности ОС и математически доказать, что при их выполнении защиту ОС невозможно взломать.
Однако о существовании развитой модели управления доступом для AppArmor или SELinux авторам настоящей статьи ничего неизвестно. Разработанные в 70-е годы прошлого столетия модели Белла-ЛаПадулы или Биба, иногда упоминаемые в этом контексте, не заслуживают серьезного обсуждения как безнадежно устаревшие. В результате, использовать SELinux или AppArmor для управления доступом в ОС – это сродни созданию отечественного самолета с иностранными двигателями без тщательного тестирования, возможности технической поддержки и развития: летать будет, но долго ли или высоко ли – большой вопрос.
В связи с этим даже в «Базовом» режиме разработчики ГК «Астра» отказались от использования заимствованных механизмов защиты SELinux и AppArmor, чтобы в последующих режимах заместить их собственными СЗИ.
Следующий режим функционирования СЗИ в ОС Astra Linux Special Edition – это «Усиленный». Он самый интересный, т. к. с него начинают действовать СЗИ собственной разработки, входящие в подсистему безопасности PARSEC. В первую очередь это противостоящие угрозе целостности информации механизмы мандатного контроля целостности (МКЦ) и замкнутой программной среды (ЗПС). Самое главное, что делают эти СЗИ — существенно повышают защищенность ОС от взлома, заражения вирусами, внедрения закладок, захвата повышенных привилегий и т. д. Ведь для любой защищенной системы важно, чтобы ее механизмы защиты работали корректно. А если система взломана, нарушена целостность ее программной среды или ее контролирует нарушитель, то не имеет смысла говорить о каких-то еще защитных функциях такой системы, например, позволяющих предотвратить утечку конфиденциальных данных. При этом по сравнению с SELinux или AppArmor подсистема безопасности PARSEC разработана на основе адаптированной для ОС семейства Linux современной верифицированной формальной модели безопасности управления доступом и информационными потоками (МРОСЛ ДП-модели), значительную часть описания которой и необходимую для этого теорию можно увидеть в учебном пособии.
Таким образом, режим «Усиленный» либо непосредственно, либо как входящий в режим «Максимальный», желателен для применения большинством пользователей ОС Astra Linux Special Edition. Именно он позволяет значительно усилить защиту от многих типовых атак.
Полный комплект СЗИ в ОС Astra Linux Special Edition доступен в режиме функционирования «Максимальный». В первую очередь здесь идет речь о возможности использования мандатного управления доступом (МРД) для защиты от угрозы конфиденциальности информации. Самое главное в МРД то, что оно необходимо гораздо в более широком спектре случаев, чем может показаться на первый взгляд. Не только в случаях, когда речь идет о защите государственной тайны.
В целом СЗИ в ОС Astra Linux Special Edition, начиная с режима «Усиленный», формируют, как это говорится в нормативных документах ФСТЭК России, поверхность атаки (рис. 1) – основной рубеж обороны от нарушителя. При этом, в отличие от других российских ОС семейства Linux, в ОС Astra Linux Special Edition этот рубеж обороны реализуется СЗИ собственной разработки (не на базе заимствованных SELinux или AppArmor), построенных на основе развиваемых в ГК «Астра» научных подходов и применении технологий обеспечения доверия. Основные принципы этих подходов изложены в недавно опубликованной в журнале «Труды ИСП РАН» статье «Формирование методологии разработки безопасного системного программного обеспечения на примере операционных систем» .
2. Мандатный контроль целостности
Первое, на что надо обратить внимание, говоря о МКЦ, это часто неверная трактовка термина «мандатный». Большинство не только обычных пользователей СЗИ, но даже специалистов в области защиты информации, когда слышат термин «мандатный», понимают его как МРД, т. е. только как защиту от утечки конфиденциальных данных. Это не так, термин указывает на то, что информация в системе или ее компоненты распределяются по некоторым явно заданным уровням, и права доступа к ним назначаются исходя из этого. Например, в ОС Astra Linux Special Edition, начиная с режима «Усиленный», при включенном МКЦ обычные недоверенные пользователи работают на уровне целостности 0, а доверенный привилегированный «красный» администратор на уровне 63.
Явно заданные уровни целостности, в отличие от раздаваемых без четких правил прав доступа при штатном дискреционном управлении доступом ОС семейства Linux, вносят больше ясности в администрирование и настройку защиты системы. К слову, в прошлом году ГК «Астра» совместно с ИСП РАН удалось разработать и утвердить ГОСТ Р 59453.1-2021 «Защита информации. Формальная модель управления доступом. Часть 1. Общие положения», в котором впервые в отечественной практике стандартизации было дано официальное определение МКЦ.
Стоит отметить, что большинство пользователей информационных систем давно используют МКЦ. Связано это с тем, что данный вид управления доступом с 2007 г. был внедрен в ОС семейства Microsoft Windows на основе реализации двух механизмов MIC – Mandatory Integrity Control и UAC – User Account Control. 15 лет, прошедшие с того времени, показали высокую эффективность МКЦ для обеспечения контроля целостности программной среды ОС семейства Microsoft Windows, предотвращения заражения вирусами и внедрения программных закладок.
Основное удобство МКЦ с точки зрения обеспечения защиты достигается за счет возможности разложить все компоненты ОС Astra Linux Special Edition (файлы, процессы, учетные записи пользователей и т. д.) по уровням целостности. Далее средствами подсистемы безопасности PARSEC защищать компоненты более высокого уровня целостности от несанкционированной записи из компонент с меньшим уровнем целостности. Даже суперпользователь root, который в обычных ОС семейства Linux, практически не ограничен в правах, в ОС Astra Linux Special Edition по умолчанию работает на минимальном уровне целостности 0. А значит, захват его полномочий с использованием типовых атак на ОС семейства Linux не позволит получить контроль над всей системой, и безопасность ОС Astra Linux Special Edition в целом не пострадает.
Рассмотрим пример использования МКЦ в ОС Astra Linux Special Edition. Для обеспечения безопасности системы очень важно, чтобы доверенные, обладающие высоким уровнем целостности процессы (например, работающие от имени «красного» администратора), стартовали из высокоцелостных исполняемых файлов. Эти файлы защищены от записи (или «заражения») низкоцелостными процессами нарушителя (рис. 2). Поэтому запуская процессы, «красный» администратор ОС Astra Linux Special Edition может быть всегда уверен, что используемые им для этого исполняемые файлы не модифицированы и не подменены.
![Рис. 2. Безопасный запуск процессов в ОС Astra Linux Special Edition Рис. 2. Безопасный запуск процессов в ОС Astra Linux Special Edition](https://habrastorage.org/getpro/habr/upload_files/704/a9b/593/704a9b5939c4d68d133e0d35e253a086.png)
3. Замкнутая программная среда
Еще одним важным СЗИ, который в ОС Astra Linux Special Edition целесообразно активировать, начиная с режима «Усиленный», является замкнутая программная среда (ЗПС). При включенной ЗПС запуск исполняемых файлов и загрузка исполняемых библиотек возможна только в том случае, если они подписаны электронной цифровой подписью (ЭЦП) на доверительном ключе. Следовательно, ЗПС обеспечивает защиту от загрузки произвольного исполняемого файла или библиотеки, не обладающих корректной ЭЦП. Это значительно усложняет эксплуатацию уязвимостей, а в большинстве случаев делает ее невозможной (неэффективной).
Остающиеся у нарушителя некоторые незначительные возможности обойти защиту ЗПС практически полностью перекрываются включенным МКЦ. Это объясняется тем, что, во-первых, осуществить внедрение ЭЦП может только «красный» администратор, обладающий высоким уровнем целостности. Во-вторых, даже если «зараженный» файл с легальной ЭЦП был как-то ранее подписан и размещен в системе, а нарушителю удалось проэксплуатировать заложенную в этом файле уязвимость и получить привилегии, например, суперпользователя root, то все равно он продолжит работу на низком уровне целостности. Безусловно, это не позволит нарушителю оказать воздействие на системные процессы, сервисы и высокоцелостные компоненты системы.
4. Изоляция приложений
Наличие МКЦ в ОС Astra Linux Special Edition дает возможность разрабатывать и внедрять новые уникальные технологии защиты. Например, адаптированную контейнерную виртуализацию (рис. 1), которая в сочетании с МКЦ позволяет создавать для недоверенного, можно сказать «опасного», программного обеспечения своеобразные «песочницы» (рис. 3), где эти приложения изолируются от остальных доверенных приложений. В таких «песочницах», работающих на пониженном уровне целостности, недоверенное программное обеспечение (например, браузер, который обрабатывает самые разные непроверенные данные из интернета), даже если подвергнется атаке нарушителя или заражению вирусом, не будет представлять опасности для всей остальной системы.
![Рис. 3. Безопасный запуск браузера в контейнере («песочнице») в ОС Astra Linux Special Edition Рис. 3. Безопасный запуск браузера в контейнере («песочнице») в ОС Astra Linux Special Edition](https://habrastorage.org/getpro/habr/upload_files/50c/bfe/e60/50cbfee604143ac3267714d7f823a037.png)
Помимо этого, в ОС Astra Linux Special Edition имеются еще дополнительные СЗИ, включая запрет запуска интерпретаторов, а также ограничение прав непривилегированных пользователей — режим Киоск-2, в сочетании с МКЦ и ЗПС играющие не последнюю роль в предотвращении типовых угроз, связанных с эксплуатацией уязвимостей.
В том числе в Киоск-2 предусмотрена возможность задания для каждого пользователя ОС Astra Linux Special Edition собственных профилей безопасности. Каждый такой профиль содержит перечень имен каталогов или файлов, права доступа к которым надо дополнительно ограничить. У пользователя может вовсе не быть профиля. С другой стороны, ему может быть назначено сразу несколько профилей. Эти возможности обеспечивают гибкость назначения ему прав доступа в зависимости от выполняемых им в каждый конкретный момент времени функций или используемых им приложений.
5. Мандатное управление доступом
Когда говорим о МРД, следует понимать, что это принцип управления доступом, а не в коем случае не следствие наличия в системе информации, отнесенной к государственной тайне. Суть этого принципа заключается в распределении информации по явно заданным уровням (часто их называют уровнями конфиденциальности) и выполнении следующих трех основных условий. Первое – чтение данных (как правило, из файла или каталога) может осуществлять процесс (пользователь), обладающий не меньшим, чем у запрашиваемых данных уровнем конфиденциальности. Второе – запись данных в файл (каталог) может осуществлять процесс, обладающий не большим (а чаще равным), чем у файла, уровнем конфиденциальности. Третье (самое сложное) – действия процессов в системе не приводят к явной или неявной утечке конфиденциальных данных «сверху-вниз» – с высокого уровня конфиденциальности на низкий (т. е. к созданию так называемых скрытых каналов). Таким образом, непосредственно здесь речи о защите государственной тайны не идет. Эти ясные и четкие правила управления доступом позволяют пользователям и администраторам систем учитывать человеческий фактор, что однозначно способствует повышению информационной безопасности таких систем.
В связи с чем, распределение информации по некоторым условным уровням конфиденциальности (например, «открытая», «служебная», «важная», «очень важная») может быть полезным в деятельности компаний даже небольшого размера. При этом реализация в МРД еще и категорий информации (их называют неиерархическими), позволяет более тонко настроить доступ к ней в зависимости от принадлежности информации к структурным подразделениям компании (например, «отдел персонала», «бухгалтерия», «отдел продаж», «руководство компании» и т. д.). Кроме того, сочетание МКЦ, МРД и ЗПС полностью обеспечивает комплексную защиту системы.
Вывод:
Безопасность ОС Astra Linux Special Edition базируется на применении отечественных доверенных технологий разработки входящих в ее состав СЗИ, в основе которых лежат в целом простые и понятные правила управления доступом. При этом комплексное применение этих СЗИ (особенно в режимах их функционирования «Усиленный» или «Максимальный») обеспечивает реальную защищенность от основных угроз безопасности информации.