Содержание к диссертации
Введение
Глава 1. Модель нарушителя, основная угроза и средства противодействия 12
1.1. Основные понятия 12
1.2. Уровни обеспечения целостности 16
1.3. Угроза нарушения целостности 17
1.4. Модель нарушителя 20
1.5. Средства СУБД, использование которых возможно для решения задачи 22
Выводы к главе 1 27
Глава 2. Обоснование возможности построения системы обеспечения целостности при заданных условиях 28
2.1. Изолированная программная среда и гарантировано защищенная система 28
2.2. Переход от изолированной программной среды к доверенной вычислительной среде 36
2.3. Особенности резидентного компонента безопасности 49
Выводы к главе 2 58
Глава 3. Компоненты системы обеспечения целостности и порядок их взаимодействия 59
3.1. Компоненты СОЦ и их функционирование 59
3.2. Порядок взаимодействия компонентов СОЦ 66
3.3. Обоснование устойчивости АИС с внедренной СОЦ к типовым атакам 70
Выводы к главе 3 77
Глава 4. Реализация компонентов СОЦ и анализ работы АИС с внедренной СОЦ 78
4.1. Монитор безопасности 78
4.2. Механизм распределения конфиденциальной информации 81
4.2.1. Общие положения 81
4.2.2. Описание решения 82
4.2.3. Считывание мастер-ключа 84
4.2.4. Работа со значениями контейнеров 85
4.3. Обеспечение доверенного запуска методов 88
4.4. Обеспечение целостности программных компонентов АИС 92
4.5. Механизм обеспечения горизонтальной целостности таблиц 93
4.5.1. Описатель правил контроля целостности 94
4.5.2. Код контроля целостности 96
4.5.3. Алгоритм работы методов расчета кода контроля целостности 101
4.5.4. Методы проверки целостности 102
4.5.5. Восстановление целостности 104
4.5.6. Анализ предлагаемого решения и временные характеристики 106
4.6. Функционирование АИС с СОЦ в условиях типовых атак 108
Выводы к главе 4 116
Заключение 118
Публикации по теме исследования 120
Список литературы 122
- Средства СУБД, использование которых возможно для решения задачи
- Переход от изолированной программной среды к доверенной вычислительной среде
- Обоснование устойчивости АИС с внедренной СОЦ к типовым атакам
- Механизм распределения конфиденциальной информации
Введение к работе
Неотъемлемой частью проблемы обеспечения информационной безопасности автоматизированных информационных систем (АИС) является задача обеспечения целостности информации, хранящейся в базах данных (БД) АИС, а также обеспечения целостности алгоритмов, обрабатывающих такую информацию. При несомненной важности аспектов обеспечения конфиденциальности и доступности информации, вопросы защиты информации от несанкционированного изменения для ряда информационных систем имеют приоритетный характер. При этом необходимо отметить, что условием обеспечения информационной безопасности АИС в целом, является уверенность в отсутствии несанкционированных изменений обрабатывающих информацию алгоритмов, а также гарантированная целостность технологий, обеспечивающих информационную безопасность системы.
В перечне проблем приоритетных научных исследований в области информационной безопасности Российской Федерации [32] констатировано, что «исследование проблем выбора архитектуры и расчета параметров защищенных информационно-телекоммуникационных систем, математических моделей и технологий управления, системного и прикладного программного обеспечения-с интеграцией-функций защиты, средств взаимодействия, устройств передачи и распределения информации», является одним из приоритетных направлений научных исследований, проводимых в Российской Федерации в области информационной безопасности1.
Таким образом, совершенствование известных и разработка новых методов и средств программного и аппаратного обеспечения целостности АИС является актуальной задачей, требующей научной разработки. Ее решение позволит повысить информационную безопасность
1 Утверждены Исполняющим обязанности Секретаря Совета Безопасности Российской Федерации, председателя научного совета при Совете Безопасности Российской Федерации 7 марта 2008 г.
существующих и проектируемых систем информационного обеспечения оперативной деятельности и защищенность компьютерных систем и сетей.
Крупный вклад в развитие теории и практики безопасности сложных технических систем, информационного взаимодействия, защиты технических, программных и информационных ресурсов внесли отечественные ученые [6-7,10-12,15-18,24,39-40]. Их усилиями сформирована научная и методическая база для дальнейшего углубления и обобщения теоретических и практических результатов на одном из актуальных направлений исследований — разработке теоретических положений и практического использования средств защиты информационных объектов и технологий хранения и обработки информации.
В настоящее время АИС двухзвенной и трехзвенной архитектуры достаточно широко используются для решения задач информационного обеспечения в государственных учреждениях, министерствах и федеральных агентствах. Так в 2007 году МЧС России ввело в опытную эксплуатацию автоматизированную информационную систему Государственной инспекции по маломерным судам МЧС России (АИС ГИМС); начата работа по созданию автоматизированной информационной системы Государственного пожарного надзора ГПН МЧС России (АИС ГПН).
Подобные АИС характеризуются следующими особенностями:
наличием жестко установленного регламента взаимодействия пользователей и обслуживающего персонала с АИС;
возможностью организации многоуровневого контроля действий пользователей, обладающих широкими полномочиями в системе;
данные, хранящиеся и обрабатываемые в АИС, предполагают повышенные требования к обеспечению их конфиденциальности и целостности.
В целом, элементы организационного управления таких АИС являются более жесткими по сравнению с АИС, применяемыми в коммерческом секторе экономики. Так, в Доктрине информационной безопасности Российской Федерации [14] определены основные угрозы АИС, используемых в органах государственного управления и специальных служб.
Вместе с тем, практически все существующие АИС имеют в своем составе системы управления базами данных (СУБД) стороннего (по отношению к создателям АИС) производителя. При этом разработчикам АИС в настоящее время недоступен исходный код СУБД промышленного уровня зарубежного производства.
Широкое использование в специализированных АИС СУБД зарубежного производства обусловлена объективно сложившейся ситуацией, когда разработка собственной СУБД с характеристиками, приближающимися к характеристикам СУБД промышленного уровня, таким как Oracle, Microsoft SOL Server и т. п., практически нереальна из-за отсутствия отечественных компаний, обладающих соответствующим кадровым и экономическим потенциалом. Вследствие этого, при создании АИС в качестве системы управления базами данных ядра АИС, как правило, выбирается подходящее и хорошо зарекомендовавшее себя на рынке решение. Для информационных систем сферы государственного управления в отечественной практике выбор СУБД в большинстве случаев — это СУБД Oracle.
Таким образом, конфиденциальная информация АИС хранится и обрабатывается при помощи алгоритмов, реализованных в программных модулях с закрытым кодом, потенциально обладающих недокументированными и скрытыми возможностями по отключению штатных средств разграничения доступа и защиты информации, оставленными разработчиками по ошибке. Такие «люки» могут
2 Утверждена Президентом Российской Федерации 9 сентября 2000 г., № Пр. — 1895.
предоставлять пользователям с ограниченными правами возможность после совершения определенных действий получать права администратора СУБД.
Основная идея решения заключается в дополнении АИС системой обеспечения целостности (СОЦ), разработке и обоснованию эффективности которой и посвящена диссертация. Ресурсами для обеспечения целостности являются как избыточность информации о защищаемом объекте, так и свойства объектов или процессов, связанных с информацией. При этом целесообразно сформулировать следующее целевое положение.
Целью построения СОЦ является обеспечение защиты информации, обрабатываемой в АИС, от угроз со стороны нарушителя с правами не меньшими, чем права администратора СУБД, на основе которой реализовано ядро защищаемой системы.
Разработка моделей и методов защиты алгоритмов обработки и баз данных от угроз нарушения целостности, является актуальной задачей и требует проведения научных исследований с целью создания и реализации конкретной технологии защиты.
Объектом исследования являются механизмы обеспечения целостности информации и алгоритмов в АИС, построенных на основе СУБД.
Предметом исследования являются методы построения программных и аппаратных средств обеспечения целостности программ и данных в АИС рассматриваемого типа.
Цель работы состоит в разработке и обосновании решения, устраняющего уязвимость АИС, функционирующих на основе СУБД, от угрозы несанкционированного изменения обрабатываемых данных и программных компонентов БД АИС со стороны нарушителя, в том числе, обладающего правами администратора СУБД.
Задачи исследования:
Формирование перечня угроз и модели нарушителя целостности АИС.
Определение условий, при выполнении которых возможно построение СОЦ АИС. Обоснование возможности построения такой системы в рассматриваемых условиях.
Исследование характеристик СОЦ, определение ее компонентов и порядка их взаимодействия.
Построение СОЦ на основе полученных теоретических результатов.
Методы исследования базируются на использовании теории защиты информации и математических моделей информационной безопасности, основанных на фундаментальных результатах теории множеств, математической логики и теории графов; на методах, процедурного и объектно-ориентированного проектирования.
Научная новизна работы заключается в следующем:
Разработан и обоснован новый метод обеспечения информационной безопасности в АИС, использующих в качестве программной основы промышленные СУБД с: закрытым кодом.
Предложена и обоснована новая архитектура СОЦ, ядром которой должен являться резидентный компонент безопасности (РКБ), состоящий из взаимодействующих модулей, размещенных на разных уровнях обеспечения целостности. Доказано, что, по крайней мере, один из модулей РКБ должен располагаться на уровне с гарантированной целостностью.
Разработана технология взаимодействия компонентов СОЦ с компонентами основной части АИС.
4. Доказано, что предложенный метод дополнения программных средств АИС системой обеспечения целостности обеспечивает устойчивость системы к атакам нарушителя, соответствующего предложенной модели.
Практическая значимость работы состоит в создании программных модулей, реализующих в АИС разработанные в ходе исследования алгоритмы. Важным достоинством решения является его универсальность — независимость от алгоритмов обработки, структуры и свойств таблиц защищаемой БД. Предложенная СОЦ может быть использована при проектировании и разработке АИС, функционирующих на основе СУБД стороннего (по отношению к создателям АИС) производителя. Кроме того, решение может быть внедрено в уже функционирующие АИС с внесением минимальных изменений в программный код.
На защиту выносится:
Метод защиты информации, обрабатываемой в АИС, построенной на основе СУБД стороннего (по отношению к создателям АИС) производителя, от угрозы несанкционированного изменения информации БД нарушителем, обладающим правами администратора СУБД.
Структура СОЦ, алгоритмы работы ее компонентов и порядок их взаимодействия.
Публикации. По теме диссертации опубликовано 6 печатных работ, в том числе 2 работы в научных изданиях, рекомендованных ВАК России для опубликования результатов диссертаций на соискание ученой степени кандидата наук.
Внедрение результатов исследований. Результаты диссертации
внедрены в образовательный процесс кафедры 731 факультета
информационной безопасности Института криптографии, связи и
информатики Академии ФСБ России путем подготовки лекционных
материалов по темам «Механизмы обеспечения целостности СУБД» и
«Проектирование безопасности БД» курса «Защита в СУБД» по
специальностям 090102 — «Компьютерная безопасность» и 090105 —
«Комплексное обеспечение информационной безопасности
автоматизированных систем».
Апробация работы. Результаты диссертационного исследования докладывались и были одобрены на следующих конференциях:
X международная научно-практическая конференция «Информационная безопасность». Таганрог, Таганрогский технологический институт южного федерального университета, 2008 год.
II Международная научно-практическая конференция. Москва, Всероссийский научно-исследовательский институт проблем вычислительной техники и информатизации, 2007 год.
Всероссийская научно-практическая конференция студентов, аспирантов и молодых ученых "Безопасность информационного пространства", Екатеринбург, 2005 год.
XIV Общероссийской научно технической конференции. Санкт-Петербург, Политехнический университет, 2005 год.
Объем и структура работы. Диссертация состоит из введения, четырех глав, заключения, списка публикаций по теме исследования и списка литературы. Основная часть работы изложена на 127 страницах машинописного текста, содержит 8 схем и 5 таблиц.
Средства СУБД, использование которых возможно для решения задачи
Для построения СОЦ необходимо найти и выделить ряд особенностей и свойств СУБД, используя которые можно либо ограничить, либо отслеживать в системе значимые действия нарушителя. Под «значимыми» здесь будем понимать действия нарушителя, ведущие к достижению его цели в рамках модели нарушителя. Например, значимым будут являться: внесение изменений в записи таблиц, хранящих защищаемые данные; внесение изменений в код программных компонентов АИС уровня БД предоставляющих данные пользователю; деактивация компонентов без внесения изменений в код (например, отключение триггеров).
Предложенная модель нарушителя накладывает серьезные ограничения на выбор средств, с помощью которых возможно построение СОЦ. Действительно, мы вынуждены исключить из рассмотрения все стандартные средства защиты, предлагаемые производителями СУБД — систему разграничения доступа к объектам БД, аудит, шифрование данных таблиц, так как данные средства настраиваются и управляются пользователями с правами администратора СУБД.
Некоторыми производителями осуществляются попытки разграничить полномочия администраторов СУБД и неких администраторов безопасности (например, решение Database Vault для СУБД Oracle [59]). При этом администраторы СУБД выполняют все свои обязанности за исключением управления системой защиты СУБД и средствами хранения секретных ключей. Администраторы безопасности осуществляют управление системой защиты СУБД, включая управление секретными ключами. Как следствие, в БД могут присутствовать столбцы таблиц с зашифрованными данными, не доступными администраторам СУБД.
Но в контексте нашей задачи подобные решения не являются действенными, поскольку, как следует из введения и разделов 1.3 и 1.4, защита строится от нарушителя с «полными» правами администратора СУБД, являющимися объединением прав администраторов всех типов уровня СУБД.
Единственное решение, предусмотренное производителями для защиты конфиденциальности кода программных компонентов БД от администраторов СУБД — применение утилиты, запутывающей исходный код программных компонентов. Но поскольку данное средство не основано на секретном ключе, оно является неэффективным (упомянутый выше пример со средством WRAP для СУБД Oracle).
Ко всему прочему, подобные средства не могут рассматриваться в качестве основы для построения СОЦ в силу того, что они являются продуктом производителя СУБД (см. введение, возможность наличия люков и закладок).
Одним из средств, использование которых возможно для построения системы защиты, является триггер. Триггер является объектом БД и представляет собой программный модуль, активация которого на выполнение происходит при наступлении некоторого события в СУБД либо, что равносильно, при определенном изменении состояния БД.
При этом активация триггера, как правило5, происходит для всех пользователей СУБД. Иными словами, при условии того, что: а) триггер включен; б) код триггера целостный; с) программные модули, вызываемые из триггера, целостны триггер отработает, даже если пользователем, выполнившим действие, приведшее к активации триггера, является администратор СУБД.
Следовательно, данное средство может быть использовано при построении СОЦ, но только в том случае, если будут гарантировано выполняться три приведенных выше условия.
Следующим механизмом, использование которого возможно при решении поставленной задачи, является механизм блокировок. Он предназначен для корректной обработки параллельно выполняющихся транзакций в БД с целью недопущения конфликтных ситуаций. Термин «параллельность» означает поддержку СУБД одновременной обработки нескольких транзакций, получающих доступ к одним и тем же данным в одно и то же время. Для корректной обработки параллельно выполняющихся транзакций в СУБД используется механизм управления параллельностью. При обработке транзакций в общем случае возможны три типа ситуаций, при которых параллельное выполнение транзакций, каждая из которых сама по себе является корректной, из-за взаимного воздействия способно привести к неправильному результату: потеря результатов обновления; зависимость от незафиксированных результатов; несогласованная обработка данных.
Основная идея механизма блокировок заключается в следующем: если при выполнении некоторой транзакции необходимо иметь гарантии, что определенный объект БД не будет изменен вне данной транзакции, требуемый объект блокируется. Результат выполнения блокировки состоит в том, что доступ к объекту со стороны других транзакций запрещается, а это позволяет предотвратить его неконтролируемое изменение. В результате установившая блокировку транзакция сможет выполнять всю необходимую обработку, имея полную гарантию, что обрабатываемый объект будет оставаться в неизменном состоянии настолько долго, насколько потребуется.
В любой СУБД поддерживается, по крайней мере, два типа блокировок: эксклюзивная блокировка, или Х-блокировка, не допускающая совместного доступа, и разделяемая блокировка, или S-блокировка, разрешающая совместный доступ. Х- и S-блокировки иногда называют блокировками для записи и чтения соответственно. Кроме того, для упрощения предположим, что единственным типом "блокируемого объекта" являются кортежи.
Переход от изолированной программной среды к доверенной вычислительной среде
Однако СО-модели присущ и ряд недостатков [24, 40]. Отметим, что генерация ИПС в рамках СО-модели возможна только на отрезке [to, L] рис. 2.1. При этом неизменность объектов, активизируемых на отрезке [0, t(J декларируется, но не обеспечивается. В этом проявляется принципиальная ограниченность понятия ИПС. В СО-модели, так же как в других известных моделях, накладываются ограничения на программно-аппаратный комплекс АИС. Проверка выполнения подобных ограничений в АИС крайне затруднительна. В главной своей части требования сводятся к обеспечению ИПС. Обобщая, можно сказать, что ИПС это совокупность (множество) совокупность (множество) программ, в которой: никакая активизированная программа не влияет на другую активизированную программу; никакая активизированная программа не влияет на данные, которые используются для создания (активизации) другой программы; каждая программа может использовать только те данные, которые ей разрешено использовать политикой безопасности; каждая программа может активизировать только те программы, целостность которых установлена и активизация которых ей разрешена политикой безопасности. В силу архитектуры рассматриваемой АИС и сформулированной модели нарушителя полное выполнение требований базовой теоремы о генерации ИПС является невыполнимым, поскольку в роли «программы» может выступать либо используемый нарушителем программный продукт, не являющийся частью АИС, либо модифицированный нарушителем компонент АИС.
Решение задачи исследования может быть достигнуто расширением ИПС до доверенной вычислительной среды. Основное требование к обеспечению целостности информации — сохранение упорядоченности знаков, символов. Основное требование к защите технологии обработки информации — сохранение отношения упорядоченности отдельных операций, её составляющих. Говорить об обеспечении целостности информации в отрыве от обеспечения целостности технологии не имеет смысла. В контексте рассматриваемой области (уровень представления информации СУБД и уровень хранимых программных компонентов АИС) такое утверждение тем более очевидно, поскольку код программных компонентов хранится в записях таблиц словаря данных СУБД. Возьмем за основу следующую модель, наиболее полно представленную в исследовании Конявского В. А. [24] в приложении к защите электронного документооборота. Введем следующие определения и обозначения: Г = {tk,k- \,К} — конечное дискретное множество моментов времени tb О = {оп, п = \,N} — конечное дискретное множество отдельных технологических операций (процессов) о„ информационного взаимодействия, где п — номер процесса. Будем говорить, что текущая технология OftiJ в момент tk задана, если известна последовательность нулей и единиц длины N, такая, что на л-м месте стоит 1, если в этот момент операция (процесс) о„ активизирована (выполняется), и стоит 0 — если нет. Технология О(Т) задана, если для всякого момента tk, k = l,K, известна текущая технология O(tk). В общем случае технологию О(Т) можно представить в виде матрицы О из нулей и единиц размера К х N, элемент о которой равен 1, если в момент времени tk, к - \,К , операция оп, п — \,N активизирована, и равен 0, если нет. U = {um,m = \,M} — конечное дискретное множество возможных угроз технологии 0(Т), где m — номер угрозы. Каждой угрозе ит ставится в соответствие неотрицательное число г,„, не превосходящее единицы, — вероятность реализации угрозы в виде атаки ат, и sm — как вероятность отсутствия атаки. Допущение 2.1.
Атаки ат попарно независимы: реализация любой угрозы не влияет на реализацию остальных. Данное допущение возможно, поскольку на практике пространство попарно независимых, но взаимно зависимых в совокупности событий практически не встречается [43]; как правило, можно «укрупнить» пространство атак, рассматривая набор атак как единую атаку. Допущение 2.2. Длительность атаки существенно превосходит время реализации как технологии взаимодействия компонентов АИС, так и взаимодействия пользователя с АИС. Из допущения 2.2 следует, что для каждой единичной операции над данными, условия можно считать фиксированными на момент начала операции. Тем самым, пространство атак можно считать постоянным в течение всего времени реализации конкретной технологии и описать подмножеством реализованных угроз в любой момент времени 4- В любой дискретный момент времени tk пространство атак можно описать последовательностью нулей и единиц длины М, где на т-м месте стоит 1, если в этот момент атака ат имеет место (угроза ит активизирована), и стоит 0 — если нет. гт — 1- sm — вероятность реализации угрозы um в виде атаки ат. Опираясь на допущение 2.1, на множестве угроз М строится вероятностное пространство атак, состоящее из 2 элементов. Технология О(Т) состоит из множества операций, поэтому, прежде чем оценивать характеристики безопасности технологии, рассмотрим таковые для отдельной операции.
Обоснование устойчивости АИС с внедренной СОЦ к типовым атакам
Покажем, что предлагаемое взаимодействие компонентов СОЦ делает систему с внедренной СОЦ устойчивой к атакам со стороны нарушителя, действующего согласно принятой модели. Введем следующие обозначения: val(TAB.d) или просто val(d) — значение поля d, хранящееся в таблице БД ТАВ в строке со значением первичного ключа pk. valJTAB.d) или просто valu(d) — значение, переданное пользователю АИС, как хранящееся в таблице ТАВ в строке со значением первичного ключа р к. null — не предоставление информации и/или не функционирование клиентской части АИС в целом и/или информирование ответственных лиц о нарушении целостности в системе. job — состояние, в котором находится АИС при работающем мониторе безопасности. "job — состояние, в котором находится АИС при неработающем мониторе безопасности. Тогда работу клиентской части АИС в плане передачи информации из БД пользователю АИС можно представить как преобразование: При внедрении СОЦ в АИС преобразование Client заменяется на преобразование, такое что: Аналогично, работу API серверной части АИС можно представить как преобразование: Функционирование подсистемы обеспечения горизонтальной целостности таблиц при защите таблицы TAB и включение столбца d в перечень защищенных может быть представлено как: Необходимость. Пусть в АИС не внедрена СОЦ. Тогда пользователь получает информацию как valu(d)=Client(val(d)) или как valu(d)=Client(API(val(d))). В случае использования метода передачи информации valu(d)—Client(val(d)), нарушитель, действующий в рамках модели, способен провести атаку A 1(d) : val(d) val (d).
При этом пользователь получит информацию Client(val (d)) = val u(d). Таким образом, атака А1 на хранящиеся данные будет успешной. В случае использования метода передачи информации valu(d)=Client(API(val(d))) помимо возможности успешного проведения атаки А1, нарушитель может провести атаку А2: A2(API) : АР1- АРГ, так, что API (val(d)) = val (d), то. есть изменить код некоторого пакета API так, чтобы его методы, получая корректное значение val(d), вместо него передавали измененное значение val (d). Атака А2 будет успешной. Достаточность. Пусть в систему внедрена СОЦ. Тогда пользователь получает информацию по принципу: valu(d) = ClientMB(APIMc( cil(d))). Пусть нарушитель проводит атаку А1(d) : val(d) - val (d). APIMc(val (d))=null , следовательно ClientMB(APIMc(val (d))) = null . Согласно утверждения 2 атака не успешна. Пусть нарушитель проводит атаку А2(АРІ) : АРІ АРГ, так, что API (val(d)) = val (d). Из свойства динамического аспекта монитора безопасности следует, что при своем запуске монитор безопасности производит проверку целостности каждого реР и блокирование/? в эксклюзивном режиме. В случае обнаружения нарушения целостности любого пакета монитор безопасности не запускается, следовательно, система переходит в состояние -yob. Изменение заблокированного монитором безопасности пакета р возможно только в случае уничтожения блокирующей его сессии. В этом случае система также перейдет в состояние -job. Из определения 3.1 следует, что АР1МС аР . Следовательно, в результате атаки А2 система перейдет в состояние -job, не зависимо от того, произошла атака А2 при включенном мониторе безопасности или при выключенном. Следовательно, ClientMB(APrMc(val(d)))=null . Согласно утверждения 2, атака не успешна. Не трудно видеть что комбинация атак А1 и А2 будет также не успешной: ClientMB(APrMC(val (d)))=null Доказательство завершено. Утверждение 3.2.
Атака нарушителя на СОЦ с целью расчета контролирующего кода горизонтальной целостности строки защищенной таблицы в рамках модели нарушителя сводится к атаке А2. Доказательство. В силу п. 3 модели, нарушитель может исследовать программные компоненты АИС уровня БД. Следовательно, ему известно, что целостность строк проверяется с помощью пакета, входящего в состав СОЦ. Изменение целостности данного пакета является атакой А2. Также нарушитель может исследовать данный пакет, следовательно ему известно, что целостность строк контролируется с помощью значения хеш-функции h() от конкатенации значений защищаемых столбцов таблицы TAB с добавлением значения ККИ. Далее нарушитель для реализации атаки должен: либо изменить код пакета, в котором реализована h() в серверной части АИС уровня СУБД, что является атакой А2; либо рассчитать правильный код контроля целостности, узнав значение ККИ по его названию, полученному при исследовании пакета. Нарушитель может исследовать пакет, входящий в состав СОЦ, в который передается название ККИ для получения его значения. Следовательно, ему известно, что значения контейнеров хранятся в зашифрованном виде в таблице на неком значении, которое пакет в процессе функционирования получает от монитора безопасности. Шифрование производится с помощью функций епс() и dec(). Изменение нарушителем кода пакета (пакетов), в котором реализованы епс() и dec() в серверной части АИС уровня СУБД является атакой А2. Нарушитель может исследовать программный пакет, входящий в состав СОЦ, в котором содержится код монитора безопасности. Следовательно, ему известно, что закрытое значение передается по протоколу Диффи-Хеллмана от библиотеки уровня ОС cpsjsm.so, разработанной на языке C/C++. Согласно п. 5 модели, нарушитель не может исследовать под отладчиком состояние серверной системы и узнать значение мастер-ключа. Доказательство завершено. Утверждение 3.3. Атака нарушителя на СОЦ с целью расчета контролирующего кода целостности критичных программных компонентов БД в рамках модели нарушителя сводится к атаке А2.
Механизм распределения конфиденциальной информации
Контроль и обеспечение целостности программных компонентов АИС (программных пакетов, процедур и функций) возлагается на Монитор безопасности.
Каждый программный компонент должен быть описан в защищенной таблице OBJECTS, которая помимо названия объекта содержит контролирующий код его целостности.
Контролирующий код объектов должен рассчитываться / проверяться по их программному коду, хранящемуся в представлении словаря данных user_source, с помощью хеш-функции h() с использованием значения определенного контейнера в качестве имито-вставки. Текст программного компонента можно получить следующим запросом:
Код, контролирующий целостность программного пакета, будет зависеть от всех символов тела пакета. Изменение любого символа в теле программного пакета, кроме константных выражений, не входящих в используемый интервал символов, приведет к изменению значения контролирующего кода. Таким образом, устраняется угроза подмены исходного кода защищаемого программного пакета.
При проведении эксперимента на стенде, среднее время работы данного механизма подсчета кода для программного пакета из 3000 строк составило 0.08 секунды.
Данный метод независим от таблицы символов, используемых в конкретном экземпляре АИС, поскольку отказ от включения в код символов.
Подобный алгоритм контроля целостности программных компонентов выполняется при каждом запуске монитора безопасности (см. раздел 3.2). После того, как монитор безопасности удостоверяется в целостности программного пакета, происходит его блокирование. Таким образом, обеспечивается целостность программных пакетов на период работы пакетного задания монитора безопасности.
Для контроля целостности в защищаемых таблицах для каждой записи предлагается рассчитывать значение хеш-функции h() от конкатенации значений защищаемых атрибутов с имитовставкой, а результат вычисления хранить в поле тс защищаемой таблицы.
Для каждой защищаемой таблицы создается и хранится в особой таблице строка-описатель правил контроля целостности. Описатель содержит информацию о том, какие столбцы таблицы защищаются от нарушения целостности, название контейнера, содержащего строку для имитовставки, состояние таблицы (произошел или нет первоначальный расчет кодов целостности для таблицы) и прочее.
В случае нарушения целостности каких-либо записей предусматривается процедура восстановления целостности.
Каждая запись таблицы CPS_REC_INTEGRJTY описывает правило контроля целостности, которое применялось или применяется по отношению к какой-либо защищаемой таблице. Каждое правило уникально идентифицируется значением CPSRECINTEGRITY.n.
При вычислении кода контроля целостности используется определенное правило контроля целостности. Получаемый при помощи правила код контроля целостности содержит информацию о том, с помощью какого именно правила он был вычислен. Это позволяет в последствии проверить соответствие кода контроля целостности защищаемой с помощью него записи с использованием тех же настроек, с помощью которых код контроля целостности изначально был вычислен.
Так как набор правил контроля целостности таблицы может изменяться (например, во множество защищаемых столбцов может быть включен новый столбец), то среди набора правил контроля целостности, относящихся к одной таблице, должен иметься способ получить текущее действующее правило. Текущее правило определяется как запись, удовлетворяющая условию:
Поле param описывает, какие атрибуты защищаемой таблицы участвуют в расчете кодов целостности. Поскольку описание набора атрибутов для защиты должно быть как можно более удобным для , использования методами расчета/проверки целостности, предлагается следующий формат: cast_to_char — функция преобразования защищаемого столбца к типу varchar2. В зависимости от типа защищаемого столбца это может быть преобразование to_char (numbе revalue, format ) — для числовых защищаемых столбцов, to_char (date_value, DDMMYYYYHH24MISS ) — для защищаемых столбцов типа даты, либо просто value —для защищаемых столбцов, уже имеющих ТИП varchar2; При расчете и проверке кода контроля целостности подписываемая строка дополняется разделителями. Поле table_name содержит имя таблицы, целостность которой защищается; Поле typ хранит битовую маску, определяющую режим пересчета и контроля кода целостности записей таблицы. Значения битов маски могут содержать следующие параметры: рассчитывать код контроля целостности в триггере или в методах; использовать поэтапный пересчет кодов контроля целостности; не пересчитывать код контроля целостности; не проверять код контроля целостности; нигде не контролировать целостность таблицы; проверять целостность таблицы в модулях клиентской части АИС; проверять целостность таблицы в модулях серверной части АИС; состояние таблицы (завершен либо нет первоначальный расчет кодов целостности записей таблицы). Поле quota_typ необходимо для применения к таблице режима частичной проверки целостности записей. Если quota_typ равна null или О, то контролируется целостность всех записей таблицы.
