Особенности построения защищенных автоматизированных систем на основе существующих компонентов Текст научной статьи по специальности «Компьютерные и информационные науки»

3. ГОСТ Р 51275-99. Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения. - М.: Изд-во стандартов. -1999.

4. Толстых Н.Н., Голод В.В., Марейченко И.В. Метод оценки безопасности информации в автоматизированных системах. // Программные продукты и системы. - 2003. - №3.

особенности построения защищенных

автоматизированных систем на основе существующих компонентов

А.Ю. Ефимов

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

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

Распространенным подходом при проектировании АС является применение в качестве базового компонента уже существующей ОС общего назначения, например, Microsoft Windows, Linux, QNX и т.п. Подобный подход порождает при проектировании средств защиты СВТ ряд проблем, таких как:

- недостаточная защищенность ОС;

- недоступность исходных текстов ОС;

- недоступность или скудность низкоуровневой документации;

- несоответствие базовых (атомарных) операций;

- неориентированность на защиту низкоуровневых механизмов;

- неориентированность на защиту высокоуровневых (прикладных) механизмов.

Далее рассмотрим перечисленные проблемы подробнее.

Руководящие документы Гостехкомиссии РФ [1,2], регламентирующие защиту информации от несанкционированного доступа (НСД), формализуют условия защищенности СВТ и АС. Они определяют необходимый набор подсистем и механизмов защиты и их характеристики. При этом многие из требуемых средств и механизмов редко реализованы в ОС общего назначения. Например, механизмы дискреционного разграничения доступа к файлам и каталогам, идентификации и аутентификации пользователей в том или ином виде существуют в большинстве современных ОС; в то

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

Другой важной проблемой при использовании ОС общего назначения является недоступность для разработчиков средств защиты исходных текстов ОС (типичный пример - ОС Microsoft Windows). В результате этого о внутренней структуре и механизмах ОС можно судить либо по косвенным признакам, либо осуществляя дизассембли-рование исполняемого кода. Как следствие, невозможно судить с достаточной уверенностью о корректности реализации различных алгоритмов и механизмов ОС, об отсутствии или наличии различного рода уязвимостей и программных закладок. Таким образом, мы не можем полагаться на уже имеющиеся в ОС средства защиты и вынуждены реализовывать свои механизмы максимально независимыми от встроенных в ОС.

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

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

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

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

Во-первых, ПВВ функционально является каналом связи ЭВМ с каким-либо устройством ввода/вывода (а возможно, с другой ЭВМ). Следовательно, должна осуществляться некая идентификация подключенного к порту устройства для сопоставления ему какого-либо уровня секретности и т.п. Однако далеко не все устройства можно идентифицировать, например, по причине элементарного отсутствия у них подобных функций, а также из-за того, что получение подобных данных может быть не предусмотрено протоколом взаимодействия через данный порт либо с данным типом устройства. Эта проблема актуальна в основном при работе со старой техникой, поскольку современная аппаратура обычно поддерживает технологию Plug&Play, частично этот вопрос решающую.

Другим аспектом защиты ПВВ является использование при работе с ними множества различных протоколов высокого (например прикладного) уровня. Например, LPT-порт может использоваться для подключения принтера, сканера, электронного ключа, другого компьютера; в каждом случае будет использоваться свой протокол

взаимодействия через порт. В таком случае возникает вопрос, на каком уровне (на уровне какого протокола) необходимо осуществлять разграничение доступа. Наиболее универсальным выглядит разграничение на самом нижнем уровне - уровне непосредственной передачи данных. Однако при этом следует учитывать двунаправленность потоков данных при использовании протоколов более высокого уровня («проблема удаленного чтения» - для чтения данных необходимо предварительно послать запрос на эти данные [3]). Разграничение же на более высоком уровне автоматически ограничивает доступные для использования протоколы набором, для которого это разграничение реализовано. Эти ограничения особенно актуальны для универсальных ПВВ типа COM, LPT, USB, IEEE1394.

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

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

Допустим, текстовым редактором Microsoft Word открыт документ A, на файл которого у пользователя отсутствует право записи (но при этом имеются права чтения, создания, удаления и т.п.). Пользователь, внеся некоторые изменения в файл, пытается сохранить его, и его попытка увенчивается успехом. Объясняется это кажущееся нарушение разграничения доступа следующим образом. Программа пытается осуществить запись в открытый файл. Это ей не удается, поскольку пользователь не имеет права на данную операцию. Поэтому программа действует следующим образом: она создает новый файл B, в котором сохраняет содержимое документа A, затем удаляет файл A и переименовывает файл B в файл A; в результате файл A, несмотря на запрет записи в него, содержит исправленную версию документа. Таким образом, формального нарушения политики безопасности не происходит, однако, с точки зрения пользователя, не имеющего представления

о данном алгоритме действия программы, такое нарушение налицо.

Более серьезные проблемы возникают при функционировании в условиях мандатного разграничения доступа. Часть своих настроек Microsoft Word хранит не в реестре, а в файлах, например, шаблон документа по умолчанию Normal.dot. Данный шаблон может исправляться пользователем. При этом запись в файл, согласно мандатному принципу разграничения, возможна только при совпадении текущих уровней безопасности (например секретности) пользователя и файла. То есть если файл имеет гриф «секретно», то и запись в него возможна только в режиме работы с секретными документами (сеанс «секретно»). Таким образом, если файл данного шаблона имеет гриф «секретно», изменение его в сеансе «совершенно секретно» невозможно. Однако большей проблемой в данном случае будет полная недоступность содержимого данного файла в сеансе «несекретно» (поскольку в противном случае будет иметь место поток с понижением уровня секретности). В результате создание новых документов, хотя и будет возможно, они будут создаваться с встроенными в программу настройками, и изменять данные настройки пользователю придется вручную для каждого несекретного документа.

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

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

- обеспечение взаимодействия и взаимозаменяемости разнородных компонентов защиты;

- организация администрирования безопасности в крупномасштабных АС.

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

личным классам защищенности. Поэтому является целесообразным применение этих готовых средств в качестве компонентов СЗИ АС. Однако при таком подходе возникают проблемы взаимодействия и управления неоднородными средствами защиты.

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

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

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

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

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

Таким образом, при проектировании защищенной АС, использующей подобный интерфейс, необходимо:

• определить типы средств защиты, используемых в АС;

• выделить общие операции управления всеми средствами защиты, используемыми в АС;

• выделить операции управления, характерные для отдельных типов средств защиты;

• выделить остальные операции, характерные для конкретных средств защиты.

Дальнейшая разработка такого интерфейса сведется, таким образом, к реализации средств трансляции операций интерфейса взаимодействия в операции конкретных средств защиты. Аналогом здесь может послужить Hardware Abstraction Layer (HAL) в DirectX и ОС Windows.

Большую роль при проектировании защищенных АС играет также организация администрирования средств защиты. Особенно актуальна данная проблема в крупномасштабных АС, охватывающих сотни или даже тысячи рабочих станций. Очевидно, что с таким количеством станций один администратор безопасности не справится просто физически. Более того, возможностей современных средств коммуникации вряд ли будет достаточно даже просто для получения регистрационной информации со всех станций [4]. Таким образом, возникает проблема построения такой схемы администрирования защиты, при которой:

- должно быть несколько администраторов безопасности;

- каждый администратор должен контролировать небольшое количество станций в пределах своих физических возможностей;

- должно обеспечиваться оперативное управление всеми защищаемыми ресурсами АС;

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

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

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

- организация междоменного сетевого взаимодействия (как для работы пользователей, так и для администрирования).

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

- доступ отсутствует (своя независимая БД для каждого домена);

- доступ по запросу (домен запрашивает нужные данные у другого домена, а тот в соответствии с текущей политикой безопасности предоставляет их или нет);

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

Организация управления данными защиты подразумевает выбор расположения средств администрирования (консоли администратора). При этом возможны следующие варианты:

- консоль администратора (одна на всю АС либо на домен) находится на специально выделенной для этого станции;

- консоль администратора доступна на нескольких (либо на всех) станциях.

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

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

Список литературы

1. РД. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели за-

щищенности от несанкционированного доступа к информации. Решение Председателя Гостехкомиссии России от 30.03.92 г.

2. РД. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. Решение Председателя Гостехкомиссии России от 30.03.92 г.

3. Баранов А.П., Борисенко Н.П., Зегжда П.Д., Корт С.С., Ростовцев А.Г. Математические основы информационной безопасности. - Орел, 1997.

4. Щеглов А.Ю. Защита компьютерной информации от несанкционированного доступа. - СПб.: Наука и техника, 2004.

создание математической модели информационных потоков в сети атм

М. Мальчерек

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

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

При моделировании потоков информации существуют два возможных подхода. При одном

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

Таблица

Параметр Непрерывный Дискретный

Функция распределения е А^) = Р{А < ^ = | а(^ 0 к А(к) = Р{А < к} = £ а, 1=0

Плотность распределения а(е) = аА(е) к а(к) = £ а, 8(к -1) 1=0

Распределение ак = Р{А = к 1 акаЕГ^) 1! dzk [ = z = 0

Математическое ожидание м I g(t)a(t)dt 0 £ 8(к)ак к=0

Средняя величина ^тОО 8 = 0 ааЕр^) z = 1 = 0'(1)

dz

Дисперсия С(1) + 0'(1) - [0'(1)]2

Стандартное отклонение Оа = V УАЩА]

Коэффициент вариации Оа с = —- са т1

Преобразования Лапласа-Стилтьеса м аь8т(э) = | е"^А(е) = 0 м = | е-8еа(е)ае 0 Порождающая функция м aEF(z) = £ ак^ к=0

А - случайная переменная для величины интервалов между поступлением данных; £ - время; в дискретном случае поступление данных может происходить только в определенное время, расстояние между поступлением данных становится базисной единицей; к - целочисленная величина, нормированная в базисных единицах; д(к-1) - импульс Дирака к позиции и