Коллектив Авторов - Цифровой журнал «Компьютерра» № 68
Жалоба
Напишите нам, и мы в срочном порядке примем меры.
Коллектив Авторов - Цифровой журнал «Компьютерра» № 68 краткое содержание
Цифровой журнал «Компьютерра» № 68 читать онлайн бесплатно
Компьютерра
09.05.2011 - 15.05.2011
Статьи
Звезда по имени Linux: почему «военные» ОС прочнее
Евгений Лебеденко, Mobi.ru
Опубликовано 10 мая 2011 года
Уж чем-чем, а планами российский народ не удивить. Попав между молотом плановой экономики СССР и наковальней скрупулёзного планирования экономики рыночной, россияне спокойно относятся к распоряжениям руководства страны, утверждающим какие-либо планы. Особенно долгосрочные.
Именно поэтому распоряжение Правительства Российской Федерации №2299-р от 17 декабря 2010 года, утверждающее План перехода федеральных органов исполнительной власти и федеральных бюджетных учреждений на использование свободного программного обеспечения, если и было замечено, то весьма узким кругом специалистов. Уж больно широк временной коридор перехода — целая пятилетка. Время есть, если учитывать, что народу не привыкать решать пятилетние планы за пару лет.
А между тем, если отбросить историческую иронию, это распоряжение отражает важнейшую тенденцию в формировании облика информационных технологий, работающих в системе управления государством. Кратко её суть можно выразить следующим образом: в России, в достаточно короткие сроки, должна быть сформирована программная платформа, с одной стороны, полностью покрывающая потребности информационных систем госсектора, а с другой — снижающая зависимость этих систем от программного обеспечения зарубежных производителей. Зависимость эта особенно сильно начинает ощущаться в связи с интенсивным развитием аренды программного обеспечения на набирающих силу облачных сервисах (модель SaaS — Software as a Service).
Разработчики отечественного софта выразили свою озабоченность такой зависимостью в письме Правительству РФ, где отразили своё видение российской программной платформы (РПП). Её обсуждение привело к формированию и утверждению на правительственном уровне концепции национальной программной платформы (НПП), а также к рассмотрению вопросов, связанных с использованием свободного программного обеспечения в информационных системах госструктур.
Если заглянуть в письмо российских софтостроителей и концепцию НПП, то первое, что бросается в глаза, — это настойчивый призыв к созданию «контролируемых Российским государством операционных систем с доступными исходными кодами» — программной базы любой информационно-телекоммуникационной системы.
Операционная система с открытыми исходниками? Первое, что приходит на ум при этом, — система Linux. Беспрецедентный по своим как технологическим, так и альтруистским масштабам проект, в рамках которого постоянно создаются и совершенствуются варианты POSIX-совместимой операционной системы, применение которой находится и в суперкомпьютерах, и в интернет-холодильниках.
Предвижу возражения: ну что же это за национальная операционная система? Взяли готовое ядро, дополнили готовыми утилитами и соответствующим прикладным софтом, всё это добро русифицировали, прилепили отечественный логотип — и вот она, отечественная ОС! Разве так делается? Наша система должна разрабатываться с нуля и в корне отличаться от имеющихся забугорных решений. Вот тогда она будет воистину нашей.
Здесь можно подискутировать. Во-первых, Linux не «забугорный», а международный проект, и российские программисты приложили к нему руку наравне с их зарубежными коллегами. Во-вторых, сама идеология свободного программного обеспечения, основанная на свободе изучения, распространения и совершенствования исходных кодов программ, даёт уникальную возможность посмотреть, как уже сделано, и сделать если не лучше, то по-своему.
Есть и третье соображение. Использование любого программного продукта в областях, где циркулирует информация различного уровня конфиденциальности (а управление государством — одна из таких областей), требует его обязательной и очень серьёзной сертификации. Которая предполагает наличие в сертифицируемой программе строго определённого набора функций и чёткого обоснования легитимности его применения при работе с конфиденциальными данными. Пройти такую сертификацию «наколенным» дистрибутивам просто невозможно. Чтобы получить свидетельство на применение своего продукта при работе с грифованными документами, его разработчикам придётся очень потрудиться, превратив, например, Linux — операционную систему «для всех» в Linux — систему специального назначения, прошедшую строгую проверку.
Вот тут был бы к месту показательный пример. И он есть. Это операционная система Astra Linux Special Edition, разработанная научно-производственным объединением РусБИТех и сертифицированная осенью прошлого года Системой сертификации средств защиты информации Министерства обороны Российской Федерации на использование в системах, обрабатывающих информацию с грифом «совершенно секретно» и ниже.
Согласитесь, отличный пример, чтобы понять, можно ли создать операционную систему для применения в таких серьёзных сферах, как защищённые автоматизированные системы и госуправление, используя в качестве основы готовый Linux-проект.
Сертификация. Азы и руководящие документыЧтобы понять, что по-своему сделано в Astra Linux, нужно знать, что подлежит сертификации.
Если операционная система (или другой программный продукт) используется при обработке множества документов, каждый из которых имеет свой гриф секретности, и с ней работает множество пользователей, имеющих разные права для разных документов, то основой такой ОС должна стать некоторая система, разграничивающая права множества пользователей ко множеству документов. Наличие подобной системы и правильное применение правил разграничения доступа должны исключить случайные или намеренные попытки несанкционированного доступа (НСД) к информации. Всё как в жизни. Если на складе висят надёжные замки, если сторожа чётко знают алгоритм своих действий, если сотрудники имеют должным образом оформленные пропуска, то хищения не то что в крупных размерах, но и по мелочёвке будут исключены.
Система разграничения доступа — чётко определённый перечень функций, соответствие которым и формирует защищённый вариант среды обработки информации.При одном условии. Если в подобной системе не будет внутренних изъянов, позволяющих организовать хищение, невыхода за рамки установленных правил. Если такой изъян — «засланный казачок» есть, то следует говорить о недекларируемых возможностях (НДВ) системы: закладках, логических бомбах и прочих вещах, подрывающих чётко определённый порядок изнутри.
Так вот, сертификация — это, по сути, оценка уровня реализации системы разграничения доступа, обеспечивающей качественное противостояние НСД, и проверка полного или частичного отсутствия в системе НДВ.
Концепция борьбы с НСД, требования, которым должны соответствовать системы, работающие с различной конфиденциальной информацией, а также уровни наличия в них недекларируемых возможностей детально определены в целом ряде ГОСТов и нормативных документов по защите информации. Используя их, уполномоченные организации проводят детальнейшую экспертизу, выставляя продукту «баллы» — уровни защиты от НСД и контроля за отсутствие НДВ. Именно эта оценка и определяет пригодность применения системы для обработки той или иной информации.
Наиболее известными организациями, осуществляющими сертификацию, являются ФСТЭК (Федеральная служба по техническому и экспертному контролю), упомянутая выше Система сертификации Министерства обороны и подобные системы других силовых ведомств.
Нормативные документы по НСД выделяют семь классов защищённости, объединённых в четыре группы. Системы, отнесённые к первой группе, в которую входит всего один класс номер 7, обладают самой низкой защищённостью. В противоположность им системы группы 1, отнесённые к классу номер 1, благодаря верифицированной защите имеют наивысший уровень защищённости. Группа 2, в состав которой входят классы номер 5 и 6, определяет системы с дискреционными методами защиты, а в третьей группе объединены классы номер 2, 3 и 4 для систем с мандатными методами защиты. В рамках каждого класса чётко определено, какие функции системы разграничения доступа должна поддерживать сертифицируемая система. Именно их наличие и определяет решение экспертов об отнесении её к тому или иному классу.
Семь классов защищённости от НСД собраны в четыре группы, характеризующиеся разными методами защиты.Аналогичным образом обстоят дела и с определением отсутствия в системе НДВ.