А.Ю.Щеглов Учебное пособие

эффективность) реализации разделительной политики доступа к ресурсам. Рассмотрим лишь несколько примеров. Например, буфер обмена в ОС является принадлежностью «рабочего стола». При запуске приложения по правой кнопки мыши (утилита runas) под другой учетной записью, буфер обмена между соответствующими двумя учетными записями не разделяется. Данная задача должна быть решена добавочным средством защиты. Другой пример. Данная задача должна быть решена добавочным средством защиты.

Требование 6. Из разграничительной политики доступа к ресурсам должна быть исключена, как таковая, сущность владения объектом (напомним, что под «владельцем» объекта понимается пользователь, создавший этот объект). Все задачи реализации разграничительной политики доступа (настройки механизмов защиты) должны решаться администратором безопасности – пользователь должен быть исключен из схемы администрирования.

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

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

3.4. Контроль целостности и аудит

3.4.1. Контроль целостности

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

161

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

– системные файлы и объекты реестра ОС, и т.д.).

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

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

Примеры требований нормативных документов к механизмым контроля целостности в автоматизированных системах различных классов защищенности [1]:

*должна быть обеспечена целостность программных средств СЗИ НСД, обрабатываемой информации, а также неизменность программной cреды. При этом: целостность СЗИ НСД проверяется при загрузке системы по наличию имен (идентификаторов) компонент СЗИ;

*должна быть обеспечена целостность программных средств СЗИ НСД, обрабатываемой информации, а также неизменность программной cреды. При этом: целостность СЗИ НСД проверяется при загрузке системы по контрольным суммам компонент СЗИ.

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

162

Альтернативное решение – это асинхронный запуск процедуры контроля целостности, причем не всех защищаемых объектов, а выборочно. Эта задача защиты уже решается на системном уровне.

Примерами подобного контроля являются:

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

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

Констроль целостности системных ресурсов при загрузке ОС;

И т.д.

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

3.4.2. Аудит

Прежде всего, рассмотрим примеры требований нормативных документов к механизмам аудита (подсистема регистрации и учета) в автоматизированных системах, например, класса защищенности 1Г (защита конфиденциальной информации) [2]:

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

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

163

-результат попытки входа: успешная или неуспешная (при НСД);

-идентификатор (код или фамилия) субъекта, предъявленный при попытке доступа;

-код или пароль, предъявленный при неуспешной попытке.

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

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

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

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

- идентификатор субъекта доступа, запросившего программу (процесс, задание); - результат запуска (успешный, неуспешный - несанкционированный);

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

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

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

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

- спецификация защищаемого объекта [логическое имя (номер)].

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

164

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

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

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

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

165

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

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

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

3.5. Защита сети

3.5.1. Задача и способ защиты информации, обрабатываемой в составе ЛВС. Системный подход к проектированию системы защиты компьютерной информации в составе ЛВС

В части защиты компьютерной информации в составе ЛВС, кроме решения задачи защиты отдельного компьютера (которые нами

166

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

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

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

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

167

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

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

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

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

Итак, в основе системного подхода к проектированию системы защиты информации в ЛВС лежит реализация следующих принципов:

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

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

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

Основу применения системного подхода составляет решение следующей совокупности задач проектирования системы защиты:

1.Строится виртуальная система защиты информации, для чего:

Выделяются информационные потоки, защиту которых необходимо обеспечить;

168

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

Для разделения информационных потоков и защиты интерфейсов взаимодействия подсистем в местах их функционального объединения устанавливаются виртуальные системы разделения информационных потоков (ВСРИП);

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

2.Разрабатываются требования к ВСЗИП;

3.Разрабатываются требования к дополнительным системам защиты информации, устанавливаемым компьютеры в составе ЛВС;

4.Разрабатываются требования к ВСРИП, к которым могут быть

отнесены:

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

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

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

Проиллюстрируем сказанное.

Рассмотрим потоки информации, которые требуют защиты, циркулирующие в рамках некой типовой ЛВС корпорации:

1.Внутренний информационный поток взаимодействия рабочих станций (РС) с информационными серверами (ИС) баз данных;

2.Внутренний информационный поток взаимодействия РС с внутренними файл-серверами ЛВС корпорации;

3.Внутренний информационный поток взаимодействия внутренних

ивнешних файл-серверов между собой;

4.Внешний информационный поток взаимодействия внешних файл-серверов с удаленными рабочими станциями и серверами по

169

виртуальным каналам сети передачи данных общего пользования (СПД ОП).

Структура ЛВС корпорации с ВСЗИП и ВСРИП, характеризуемая наличием всех перечисленных информационных потоков, представлена на рис.3.46.

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

Четыре ВСЗИП предназначаются для защиты соответствующих информационных потоков:

1 – взаимодействия РС с серверами БД;

2– взаимодействия РС с внутренними файл-серверами;

3– взаимодействия внутренних файл-серверов с внешними файлсерверами;

4– взаимодействия внешних файл-серверов – с удаленными рабочими станциями и серверами.

Замечание. Схема, приведенная на рис.3.20 составлена в предположении, что все четыре потока характеризуются различными уровнями конфиденциальности. Например, если 2 и 3 потоки имеют равную конфиденциальность – они сольются, соответственно объединятся 2 и 3 ВСЗИП и не потребуется 2 ВСРИП.

170