Доклады, выступления, видео и электронные публикации

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

А.К. Расщепкин, Россия, Москва, Московский государственный инженерно-физический институт

Введение

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

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

1. Отсутствие применимых средств реализации мандатного механизма разграничения доступа

При реализации механизмов мандатного доступа разработчики наталкиваются на отсутствие программных средств защиты информации, способных адекватно реализовывать требование "контроля потоков информации" (классы 2А, 1А-1В по РД). Существующие cредства защиты информации, формально поддерживающие эту функцию, не могут обеспечить приемлемый уровень удобства работы пользователя и администратора. На рынке в принципе отсутствуют средства защиты, обеспечивающие управление потоками информации на основе меток конфиденциальности для файловых объектов распределенной системы. И это притом, что современные автоматизированные системы в большинстве своем являются распределенными. Не существует средств, которые способны были бы распространять политику на основе мандатного принципа разграничения доступа дальше объектов файловой системы. Хотя файловая система, безусловно, важнейший компонент современной операционной системы, многие информационные сервисы базируются на других типах объектов, не проецируемых на файловую систему.

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

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

2. Отсутствие средств защиты СУБД

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

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

Если минимальная логическая единица защищаемых ресурсов какой-либо системы меньше базы данных в целом, то на нее распространяется требование классов 2А, 1А-1Г РД, которые говорят о том, что "должна осуществляться идентификация программ, томов, каталогов, файлов, записей, полей записей по именам" и "осуществляться регистрация попыток доступа программных средств к следующим дополнительным защищаемым объектам доступа: терминалам, ЭВМ, узлам сети ЭВМ, линиям (каналам) связи, внешним устройствам ЭВМ, программам, томам, каталогам, файлам, записей". Таким образом, если информационная технология этой конкретной системы не использует какие-либо специально разработанные программные надстройки над СУБД, реализующие функциональность, способную закрыть упомянутое требование, отсутствие функций защиты в СУБД вообще ставит под сомнение возможность аттестации автоматизированной системы. Однако на рынке СУБД наблюдается cледующая картина. Импортные СУБД, обладая высоким уровнем надежности и масштабируемости, позволяющими использовать их в задачах промышленного уровня, хотя и оснащены развитыми механизмами защиты хранимой информации, не являются средствами защиты, сертифицированными Гостехкомиссией России, и потому не могут использоваться при построении автоматизированных систем, требующих высокого класса защищенности. Ситуация с СУБД отечественной разработки выглядит следующим образом. Некоторые из них, будучи наделенными функциями защиты, не обладают необходимыми сертификатами. Внедрению других, обладающих и функциями защиты, и сертификатами, мешает ограниченное распространение платформы, на базе которой они функционируют. Здесь первым, но неглавным обстоятельством является недоверие к ним разработчиков прикладных подсистем как к программному обеспечению промышленного уровня> которого зачастую требуют масштабы задач> автоматизируемых в защищенных системах Вторым обстоятельством, стоящим на пути внедрения сертифицированных отечественных СУБД; является укоренившаяся на правах наиболее ЭКОНомичной практика разработки защищенных прикладных подсистем, заключающаяся в переносе и адаптации решения т открытой системы. Поскольку в открытой системе нет места платформе, на которой способны функционировать те самые легитимные отечественные СУБД> решение для защищенной системы при описанном подходе разработки наследует платформу, средства разработки и несертифицированную СУБД открытой системы Все это делает проблематичным программную разработку, внедрение и сопровождение решений на основе сертифицированных по требованиям безопасности отечественных субд.

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

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

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

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

В любых других сферах использования программного обеспечения, продаваемого, что называется, "с полки", эта проблема решается с помощью прикладных программных интерфейсов (API), позволяющих использовать уникальные функции одних программ другими. Наличие таких возможностей наблюдается практически для всех пакетов коммерческого характера. Однако, за редким исключением, не существует программных средств защиты информации, предоставляющих такого рода интерфейсы, нет тенденции к их разработке и использованию и не урегулированы нормативные вопросы их применения. Хорошим примером прикладного программного интерфейса, схожего по функционалу со средствами защиты от НСД, является JAAS (Java Authentication and Authorization Service)' ВTЩИЙ в Java SDK v 1А Об отечественных средствах защиты, являющихся исключениями из этого правила, можно сказать, что их интерфейсы носят очень ограниченный характер и практика их использования бедна примерами. Путь в направлении выхода из этой проблемы очевиден необходима разработка описанных выше программных интерфейсов, тем более что для существующих продуктов умозрительная оценка усилий на такую работу не высока в рыночных условиях для воплощения этой идеи в жизнь прежде должна возникнуть заинтересованность потребителей - разработчиков прикладных информационных систем, которая в организационном плане может быть поддержана введением соответствующих нормативных требований; публикацией оценок выигрыша в трудозатратах за счет описанной технологии; политикой снижения цен на сертификацию приложений, использующих такого рода хранение и обработка журнала др.) может быть реализован во внешней по отношению к СУБД.

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

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

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

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

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

5. Отсутствие средств идентификации вычислительной техники

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

Если в отношении пары "клиент - сервер безопасности системы" это требование можно считать реализованным в ряде продуктов, то для остальных элементов перечисления удовлетворить ему очень сложно.

Рассмотрим каждый вариант отдельно.

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

Заключение

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

Автор: Расщепкин А. К.

Дата публикации: 01.01.2004

Библиографическая ссылка: Расщепкин А. К. Проблемы обеспечения информационной безопасности при создании защищенных автоматизированных систем // Управление защитой информации. Минск-Москва, 2004. Т. 8. № 3. С. 274–277.


Метки документа:
другое  

Scientia potestas est
Кнопка связи