Обеспечение информационной безопасности баз данных. Базовые средства защиты баз данных. Штатный аудит баз данных

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Введение

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

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

Комплексное обеспечение информационной безопасности заключается в сочетании:

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

- целостности: защиты от модификации или подмены информации;

- доступности: гарантировании доступа к информации и информационным ресурсам, средствам информатизации авторизованным пользователям.

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

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

Новосибирское авиационное производственное объединение (НАПО), для нужд которого был разработан дипломный проект, сегодня является одним из крупнейших авиастроительных предприятий России и предлагает своим клиентам высококачественную продукцию и большой комплекс услуг. Объединение обеспечивает техническое сопровождение самолетов в течение всего жизненного цикла, в том числе поставку запасных частей, ремонт и модернизацию, обучение летного и технического персоналов. На предприятии выпускается большая номенклатура товаров народного потребления, инструментов и предлагается большой комплекс услуг. Также объединение включает авиакомпанию, которая занимается чартерной перевозкой пассажиров и грузов весом до 20т, в том числе скоропортящихся грузов, а также предоставляет любые услуги на вертолетах «Ми-8». Основная продукция НАПО - самолеты военного и гражданского назначения. Конструкторские разработки и вся информация НАПО обо всем жизненном цикле самолетов является государственной тайной и обсуждению в данной работе не подлежит.

С развитием информатизации и автоматизации деятельности ОАО «НАПО им. В.П.Чкалова», с увеличением объемов информации, обрабатываемой в информационной системе предприятия, одновременно, с увеличением степени важности информации и критичности выполнения информационно-вычислительных процессов требуется особое внимание к вопросам обеспечения информационной безопасности.

В соответствии с принятой на предприятии «Политикой информационной безопасности» и СТП 525.588-2004 «Система менеджмента качества» кроме информации, защите подлежат также средства информатизации -- средства вычислительной техники, коммуникационное оборудование, программное обеспечение, автоматизированные системы ведения баз данных, а также информационно-вычислительные процессы -- процессы передачи, обработки и хранения информации. Целью предпринимаемых мер по защите информации является обеспечение корректного и безопасного функционирования средств информатизации и установление ответственности за выполнение необходимых процедур.

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

Целью дипломного проекта является реализация эффективной защиты производственной базы данных ОАО «НАПО им. В.П.Чкалова».

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

В дипломном проекте рассмотрены следующие задачи:

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

выбор и обоснование проектных решений по устранению недостатков, проблем, нейтрализации угроз безопасности и удовлетворения потребностей;

внедрение средств защиты на уровне системы управления базами данных (далее СУБД);

разработка и введение в эксплуатацию защищенного клиент-серверного приложения;

рассмотрение применяемой на предприятии политики использования сетевых ресурсов;

раздел охраны труда;

организационно - экономическая часть проекта.

В данном дипломном проекте рассматриваемой СУБД является Microsoft SQL Server. Разработка приложения осуществляется с использованием технологий Microsoft (dot)NET, которая предполагает трехуровневую организацию: сервер данных (Microsoft SQL Server), сервер приложений (IIS 5.0 & .NET Framework 2.0) и web-клиент (IE 6.0). Кроме того, для формирования отчетов используется инструментальное программное обеспечение Crystal Reports 8.0.

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

1. Анализ вопроса защиты баз данных

1.1 Постановка задачи и ц елесообразность защиты баз данных

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

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

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

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

· многие даже не догадываются о том, что их базы данных крадут;

· кража и причиненный ущерб имеют латентный характер;

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

Причины такого положения следующие:

· Высокая латентность подобных преступлений (понесенные потери обнаруживаются спустя некоторое время) и достаточно редко раскрываются. Эксперты называют следующие цифры по сокрытию: США - 80%, Великобритания - до 85%, Германия - 75%, Россия - более 90%. Стремление руководства умолчать, с целью не дискредитировать свою организацию, усугубляет ситуацию.

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

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

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

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

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

1. 2 Р оссийское законодательство в области защиты баз данных

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

Законодательная база Российской Федерации в этой области строится на нескольких документах. Во-первых, сама базы данных является результатом творческой деятельности и защищается законами об авторском праве (закон 09.07.93 N 5351-1 "Об авторском праве и смежных правах"). Во-вторых, использование компьютерных базы данных и их распространение регламентируется законами о защите баз данных (закон от 23.09.92 N 3523-1 "О правовой охране программ для ЭВМ и баз данных"). В-третьих, федеральный закон от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и защите информации» ставит вне закона торговлю приватными базами данных, обеспечивает контроль над оборотом личных сведений граждан и требует от организаций обеспечить защиту персональных данных служащих и клиентов. И последнее, закон "О персональных данных» регулирует порядок обработки персональных данных и направлен на защиту баз данных. Отсюда следует вывод, что на государственном уровне вопрос защиты баз данных должным образом не проработан, не существует четкой методики защиты, поэтому только организация комплексной защиты на административном, процедурном, программно-техническом и законодательном уровнях смогут обеспечить необходимый уровень защищенности.

1. 3 Структурные уровни и этапы построения защищенной баз ы данных

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

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

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

Процесс построения защиты базы данных можно разделить на этапы

· анализ предметной области и проектирование базы данных;

· составление пользователей и разделение их обязанностей;

· ввод данных;

· анализ существующих угроз;

· выработка модели нарушителя;

· выработка подхода к построению защиты;

· организация защиты средствами СУБД;

· разработка защищенного приложения, работающего с базой данных;

· защита сетевых ресурсов предприятия;

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

· первый уровень - уровень СУБД;

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

· третий уровень - уровень сетевых ресурсов.

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

Рисунок 1.1 - Уровни взаимодействия пользователей с базой данных

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

· механизмах поиска запрашиваемых данных;

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

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

· поддержании баз данных в актуальном состоянии.

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

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

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

Выводы

2. Угрозы безопасности баз данных

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

2. 1 Особенности современных автоматизированных систем как объекта защ и ты

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

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

Перечислим основные из особенностей распределенных АС:

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

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

интеграция данных различного назначения, принадлежащих различным субъектам, в рамках единых баз данных и, наоборот, размещение необходимых некоторым субъектам данных в различных удаленных узлах сети;

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

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

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

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

высокая степень разнородности используемых средств вычислительной техники и связи, а также их программного обеспечения;

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

2. 2 Уязвимость основных структурно-функциональных элементов

В общем случае АС состоят из следующих основных структурно-функциональных элементов:

рабочих станций - отдельных ЭВМ или удаленных терминалов сети, на которых реализуются автоматизированные рабочие места пользователей;

серверов (служб файлов, баз данных) высокопроизводительных ЭВМ, предназначенных для реализации функций хранения, печати данных, обслуживания рабочих станций сети действий;

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

каналов связи (локальных, телефонных, с узлами коммутации и т.д.).

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

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

2. 3 Угрозы безопасности БД и субъектов информационных отнош е ний

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

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

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

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

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

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

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

1. человеческий фактор (пользователь);

2. тиражирование данных;

3. хищение базы данных, уничтожение базы данных;

4. перехват сетевого трафика;

5. съем информации с ленты принтера, плохо стертых дискет, устройствах, предназначенных для содержания резервных данных;

6. хищение носителей информации, предназначенных для содержания резервных данных;

7. программно-аппаратные закладки в ПЭВМ;

8. компьютерные вирусы, логические бомбы;

9. нарушение работоспособности сети предприятия;

10. производственные и технологические отходы;

11. обслуживающий персонал;

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

13. стихийные бедствия;

14. форс-мажорные обстоятельства.

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

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

Теперь рассмотрим угрозы, учитывая базовые задачи обеспечения защиты.

Распределим угрозы на угрозу конфиденциальности, целостности и доступности.

1. Угроза раскрытия конфиденциальности:

· перехват данных;

· хранение данных на резервных носителях;

· методы морально-психологического воздействия;

· злоупотребление полномочиями;

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

· утечка и преднамеренный сбор информации:

· об объекте и предприятии, к которому он принадлежит;

· о лицах, работающих или присутствующих на объекте;

· о хранимых ценностях и имуществе;

· о прочих предметах, являющихся потенциальными целями преступного посягательства.

· иные угрозы

2. Угроза нарушения целостности:

· нарушение статической целостности

· ввод неверных данных, программ;

· изменение данных, программ;

· нарушение целостности кабельного хозяйства;

· нарушение динамической целостности

· дублирование данных;

· переупорядочивание данных;

· нарушение последовательности операций.

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

3. Угроза отказа в доступности:

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

· внутренний отказ информационной системы:

· разрушение данных;

· разрушение или повреждение аппаратных средств;

· отказы программного обеспечения;

· отступление (случайное или умышленное) от установленных правил эксплуатации;

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

· ошибки при (пере) конфигурировании системы;

· технические неисправности/отказ аппаратуры.

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

· отказ пользователей:

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

· невозможность работать с системой в силу отсутствия соответствующей подготовки (недостаток «компьютерной грамотности», неумение работать с документацией);

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

· отказ поддерживающей инфраструктуры:

· нарушение работы (случайное или умышленное) систем связи, электропитания, водо- и/или теплоснабжения, кондиционирования;

· разрушение или повреждение помещений;

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

· "обиженные" сотрудники - нынешние и бывшие;

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

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

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

Следующим этапом будет выработка неформальной модели нарушителя, которая

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

2. 4 Неформальная модель нарушителя

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

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

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

При разработке модели нарушителя определяются:

· предположения о мотивах действий нарушителя (преследуемых нарушителем целях);

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

· ограничения и предположения о характере возможных действий нарушителей.

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

1) по принадлежности к системе:

· зарегистрированный пользователь, т.е. сотрудник фирмы

· незарегистрированный пользователь, т.е. лицо, не причастное к работе фирмы;

· обиженные" сотрудники - нынешние и бывшие знакомы с порядками в организации и способны нанести немалый ущерб;

· совместно, состоя в сговоре;

2) по степени случайности или наличию умысла:

· без умысла (халатность, неосторожность, небрежность или незнание);

· со злым умыслом, то есть продуманно;

3) по мотиву:

· безответственность: пользователь целенаправленно или случайно производит какие-либо разрушающие действия, не связанные со злым умыслом, в большинстве случаев это следствие некомпетентности или небрежности;

· самоутверждение: некоторые пользователи считают получение доступа к системным наборам данных крупным успехом, затевая своего рода игру "пользователь - против системы" ради самоутверждения либо в собственных глазах, либо в глазах коллег;

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

4) по задаче внедрения:

· изменение или разрушение программ, данных;

· внедрение другого вредоносного ПО;

· получение контроля над системой;

· агрессивное потребление ресурсов;

5) по уровню знаний:

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

· обладает высоким уровнем знаний и опытом работы с техническими средствами системы и их обслуживания;

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

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

6) по виду доступа:

· программный (н-р, закладки);

· физический (н-р, подсоединение к кабелю, подключение внешних устройств);

· совместный;

7) по уровню возможностей (используемым методам и средствам):

· применяющий чисто агентурные методы получения сведений;

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

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

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

8) по месту действия:

· без доступа на контролируемую территорию организации;

· с контролируемой территории без доступа в здания и сооружения;

· внутри помещений, но без доступа к техническим средствам АС;

· с рабочих мест конечных пользователей (операторов) АС;

· с доступом в зону данных (баз данных, архивов);

· с доступом в зону управления средствами обеспечения безопасности АС;

9) по последствиям:

· не серьезные, которые просто показали уязвимость;

· средние;

· серьезные;

· сверхсерьезные;

9). по компонентам информационной системы, на которые нацелены:

· информация

· программы и данные

· аппаратура;

· документация;

· поддерживающая инфраструктура;

10) . по времени действия:

· в процессе функционирования АС (во время работы компонентов системы);

· в период неактивности компонентов системы (в нерабочее время, во время плановых перерывов в ее работе, перерывов для обслуживания и ремонта);

· как в процессе функционирования АС, так и в период неактивности компонентов системы;

11). по характеру действий нарушителей:

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

· нарушитель, планируя попытки НСД, скрывает свои несанкционированные действия от других сотрудников;

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

Определение конкретных значений характеристик возможных нарушителей в значительной степени субъективно.

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

2. 5 Политика безопасности предприятия

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

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

Политика безопасности предприятия ОАО «НАПО им. В.П.Чкалова» прописана в одноименном документе «Политика информационной безопасности предприятия» и является обязательной для исполнения сотрудниками предприятия. Политика информационной безопасности разработана на основе требований законодательства Российской Федерации в области информационной безопасности и защиты информации, а также рекомендаций стандарта ISO/IEC 17799-2000.В документе определяется ответственность сотрудников за реализацию соответствующих положений и разделов политики.

Выводы

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

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

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

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

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

3. Защита со стороны СУБД

Одним из необходимых уровней реализации защиты базы данных является защита базы данных со стороны СУБД (рисунок 2), с помощью которого она организована. В данном дипломном проекте рассматриваемой СУБД является Microsoft SQL Server (сокращенно и далее MS SQL Server).

Рисунок 3.1 - Уровни защиты базы данных

3. 1 Проектирование базы данных

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

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

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

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

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

· функционирование в неоднородной среде на нескольких аппаратных платформах;

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

· существенная временная протяженность проекта, обусловленная, с одной стороны, ограниченными возможностями коллектива разработчиков организации-заказчика к внедрению ИС.

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

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

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

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

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

Предметная область.

Под данными понимается конкретное устройство ВТ и его характеристики. Для учета средств ВТ необходимо знать прежде всего единицу ВТ, которая в последствии будет подлежать учету. Единицей ВТ может быть: монитор, системный блок, клавиатура, принтер, сканер, копир и т.д.. В свою очередь системный блок может включать в себя материнскую плату, оперативную память, CD-ROM, DVD-ROM, ZIP, и т.д. Каждая из перечисленных единиц ВТ имеет уникальные атрибуты-характеристики, определяемые спецификой техники. Помимо единицы ВТ, в проекте должно быть использовано такое понятие как АРМ (автоматизированное рабочее место), к которому должно быть прикреплено СВТ (средство ВТ), если устройство находится в обращении. Устройство имеет свою модель, тип, характеристику и значение этой характеристики.

Рассмотрим на примере. Допустим, на крупном предприятие было принято решение о подключении одного из его подразделений к ЛВС. Прежде чем заниматься прокладкой кабелей, настройкой сети, и непосредственным подключением, нужно произвести учет СВТ. Так как часть оборудования пришлось модернизировать, часть оставить для использования, а часть списать, то это все необходимо отобразить в учете. 25 мая 2005 было закуплено 25 принтеров Color HP Laser Jet 2600n(A4,8 с/мин,ч/б/цв, USB,лоток на 250 листов, встроенный сервер печати Fast Ethernet, Win 2000/XP,Server 2003, до 35000 стр/мес.). В этом случае: тип оборудования - принтеров, модель-Color HP Laser Jet 2600n, характеристики и значения - формат(A4), скорость(8 с/мин), печать(ч/б/цв), разъем(USB), ОС(Win 2000/XP,Server 2003), дополнительная информация (все остальное).

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

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

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

Таблица 3.1 - Характеристики средств ВТ

Информация об устройстве ВТ
модель оборудования	фирма-поставщик
шифр оборудования	фирма-производитель
тип оборудования	№ счет-фактуры
серийный номер	бухгалтерский шифр
гарантия поставщика в месяцах	балансовый счет
гарантия производителя в месяцах	дополнительная информация
сумма приобретения	задействовано или списано
инвентарный номер	подключение к сети
	дата приобретения
Акты модернизации
номер акта	подразделение исполнителя
	ФИО исполнителя
устройство, которое подлежит записи в акт	подразделение принимающего
дата проведения операции	ФИО принимающего
Журнал учета перемещения выч.техники между АРМ и история АРМа
перемещаемое устройство	дата проведения операции
	ФИО исполнителя
конкретное действие: изъятие или добавление	подразделение исполнителя
	ФИО принимающего
специализация	подразделение принимающего
Фирма - производитель
название производителя	адрес в Интернете
эл. почта
Фирма-поставщик
название фирмы-поставщика
	адрес в Интернете
	эл. почта
Автоматизированное рабочее место
	ФИО ответственного лица
Окончание табл. 3.1
наименование подразделения	телефон(ы) отв. лица
местоположение, объект	местоположение, офис
Подразделение
шифр подразделения	название подразделения
ФИО начальника подразделения

Подобные документы

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

дипломная работа , добавлен 05.02.2017


Проектирование и создание информационной базы данных для управления предприятием "Завод металлоизделий". Данные для базы, предметная область, атрибуты объектов базы данных. Объектные отношения, их ключи, связи объектов и отношений базы данных предприятия.

реферат , добавлен 04.12.2009


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

курсовая работа , добавлен 07.10.2016


Законодательные основы защиты персональных данных. Классификация угроз информационной безопасности. База персональных данных. Устройство и угрозы ЛВС предприятия. Основные программные и аппаратные средства защиты ПЭВМ. Базовая политика безопасности.

дипломная работа , добавлен 10.06.2011


Разработка базы данных для информационной поддержки деятельности аптеки с целью автоматизированного ведения данных о лекарствах аптеки. Проектирование схемы базы данных с помощью средства разработки структуры базы данных Microsoft SQL Server 2008.

курсовая работа , добавлен 18.06.2012


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

курсовая работа , добавлен 14.01.2015


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

курсовая работа , добавлен 08.08.2012


Создание базы данных для небольшого предприятия, занимающегося ремонтом бытовой техники. Анализ и характеристика предметной области, входных и выходных данных. Разработка конфигурации в системе "1С:Предприятие 8.2" и функциональной части приложения.

контрольная работа , добавлен 26.05.2014


Описание предметной области разрабатываемой базы данных для теннисного клуба. Обоснование выбора CASE-средства Erwin 8 и MS Access для проектирования базы данных. Построение инфологической модели и логической структуры базы данных, разработка интерфейса.

курсовая работа , добавлен 02.02.2014


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

Атаки на хранилища и БД являются одними из самых опасных для предприятий и организаций. Согласно статистике компании infowatch , в последние годы количество утечек данных в мире неуклонно растет, при этом на 2015 год более тридцати процентов из них приходятся на внешних нарушителей и более шестидесяти выполнено с участием сотрудников организации. Даже если предположить, что в ряде случаев утечка включала данные, к которым сотрудник имеет легальный доступ, каждый третий случай приходился на внешнюю атаку. Также нужно отметить, что, согласно приведенным в данным, на внешние атаки приходятся семь из восьми утечек объемом более десяти миллионов записей.

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

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

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

Среди зарубежных работ, освещающих современные направления исследований, можно отметить . Работы российских исследователей в основном посвящены узким вопросам безопасности СУБД, например .

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

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

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

Эволюция систем безопасности БД

Исторически развитие систем безопасности БД происходило как реакция на действия злоумышленников в соответствии с этапами эволюции самих хранилищ (БД) и изменениями типа и вида возрастающих угроз. Эти изменения были обусловлены общим развитием БД от решений на мейнфреймах до облачных хранилищ.

В архитектурном плане можно выделить следующие подходы:

Полный доступ всех пользователей к серве- ру БД;

Разделение пользователей на доверенных и частично доверенных средствами СУБД (системы управления БД);

Введение системы аудита (логов действий пользователей) средствами СУБД;

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

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

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

Современные проблемы обеспечения безопасности БД

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

Проблемами безопасности серьезно занимаются только крупные производители прежде всего в ведущих продуктах линеек для хранения данных;

Программисты БД, прикладные программисты и администраторы БД не уделяют должного внимания вопросам безопасности;

Разные масштабы и виды хранимых данных требуют разных подходов к безопасности;

Различные СУБД используют разные языковые диалекты для доступа к данным, организованным на основе одной и той же модели;

Появляются новые виды и модели хранения данных.

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

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

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

Еще одна причина такой ситуации - разрозненность диалектов языка запросов к СУБД. Если рассматривать только известные реляционные СУБД, несмотря на наличие развивающегося стандарта SQL (SQL-92, SQL-99, SQL-2003, SQL-2008), даже крупные производители не только используют собственные расширения языка, но и не поддерживают до конца операции принятой версии стандарта. Этот факт осложняет разработку единых механизмов защиты БД уровня сервера.

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

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

Особенности систем БД как объекта защиты

В связи с появлением новых решений в области нереляционных хранилищ, размывающих границу традиционного представления о СУБД (например, система кэширования данных в памяти MemcasheDB или Hadoop HDFS), определим функции, отличающие СУБД от файлового хранилища и других типов программных продуктов. В этом ключе в выделено несколько признаков. Переформулировав первый признак - «поддержание логически согласованного набора файлов», в силу активного развития in memory СУБД, осуществляющих хранение и все операции над данными в оперативной памяти, приведем эти критерии в следующей редакции:

Поддержание логически согласованного набора данных;

Обеспечение языка манипулирования дан- ными;

Восстановление информации после разного рода сбоев;

Реальная параллельная работа нескольких пользователей (процессов).

Используя такой подход, можно отделить именно СУБД от файловых систем и ПО другого вида.

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

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

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

Зависимыми от данных (в той или иной степени) является большое число аспектов безопасности. В частности, зависимыми напрямую можно назвать механизмы логического вывода и агрегирования данных, называемые специфичными проблемами СУБД. В то же время многие уязвимости являются косвенно зависимыми от данных. Например, современные СУБД (считая и реляционные, и нереляционные решения) поддерживают запросы к данным с использованием некоторого языка запросов. В свою очередь, в этом качестве используются специализированные языки запросов (SQL, CQL, OQL и других), наборы доступных пользователю функций (которые, в свою очередь, тоже можно считать операторами запросного языка) или произвольные функции на языке программирования (чаще всего Java). Обобщенные интерфейсы работы с данными представлены на рисунке.

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

Требования к безопасности БД

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

· Функционирование в доверенной среде.

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

· Организация физической безопасности файлов данных.

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

· Организация безопасной и актуальной настройки СУБД.

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

Следующие требования можно назвать зависимыми от данных.

· Безопасность пользовательского слоя ПО.

· Безопасная организация данных и манипулирование ими.

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

Пути создания защищенных БД

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

1. Разработка комплексных методик обеспечения безопасности хранилищ данных на текущем этапе.

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

2. Оценка и классификация угроз и уязвимостей СУБД.

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

3. Разработка стандартных (применимых к различным СУБД без внесения изменений или с минимальными изменениями) механизмов обеспечения безопасности.

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

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

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

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

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

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

Литература

1. Исследование утечек информации за первое полугодие 2015 года. URL: http://www.infowatch.ru/analytics/reports/16340 (дата обращения: 26.02.2016).

2. Информационная безопасность бизнеса. Исследование текущих тенденций в области информационной безопасности бизнеса. 2014. URL: http://media.kaspersky.com/pdf/IT_risk_ report_Russia_2014.pdf (дата обращения: 26.02.2016).

3. Sandhu Ravi S., Jajodia Sushil. Data and database security and controls. Handbook of Information Security Management, Auerbach Publishers, 1993, pp. 181-199.

4. Qiu M., Davis S. Database security mechanisms and implementation. IACIS, Issues in Inform. Syst. 2002, vol. 03, pp. 529-534.

5. Lesov P. Database security: a historical perspectiv. 2010. URL: http://arxiv.org/ftp/arxiv/papers/1004/1004.4022.pdf (дата обращения: 26.02.2016).

6. Burtescu E. Database security - attacks and control me- thods. Journ. of Applied Quantitative Methods, 2009, vol. 4, no. 4, pp. 449-454.

7. Rohilla S., Mittal P.K. Database Security: Threads and Challenges. Intern. Journ. of Advanced Research in Computer Science and Software Engineering, 2013, vol. 3, iss. 5, pp. 810-813.

8. Потапов А.Е., Манухина Д.В., Соломатина А.С., Бадмаев А.И., Яковлев А.В., Нилова А.С. Безопасность локальных баз данных на примере SQL Server Compact // Вестн. Тамбов. ун-та. Серия: Естественные и технические науки. 2014. № 3. С. 915-917.

9. Бортовчук Ю.В., Крылова К.А., Ермолаева Л.В. Информационная безопасность в современных системах управления базами данных // Современные проблемы экономического и социального развития. 2010. № 6. С. 224-225.

10. Горбачевская Е.Н., Катьянов А.Ю., Краснов С.С. Информационная безопасность средствами СУБД Oracle // Вестн. ВУиТ. 2015. № 2 (24). С. 72-85.

11. Ткаченко Н.О. Реализация монитора безопасности СУБД MySQL в dbf/dam системах // ПДМ. Приложение. 2014. № 7. С. 99-101.

12. Полтавцева М.А. Задача хранения прав доступа к данным в РСУБД на примере Microsoft SQL Server // Актуальные направления фундаментальных и прикладных исследований: матер. V Междунар. науч.-практич. конф. 2015. С. 118-120.

13. Баранчиков А.И., Баранчиков П.А., Пылькин А.Н. Алгоритмы и модели доступа к записям БД. М.: Горячая линия-Телеком, 2011. 182 с.

14. Поляков А.М. Безопасность Oracle глазами аудитора: нападение и защита. М.: ДМК Пресс, 2014. 336 с.

15. Смирнов С.Н. Безопасность систем баз данных. М.: Гелиос АРВ, 2007. 352 с.

16. Murray M.C. Database security: what students need to know. JITE:IIP, vol. 9, 2010, pp. 61-77.

17. Database Security Technical Implementation Guide (STIG). US Department of Defense. Vers. 7. Release 1. 2004. URL: https://www.computer.org/ cms/s2esc/s2esc_excom/Minutes/2005-03/DISA%20STIGs/DATABASE-STIG-V7R1.pdf (дата обращения: 26.02.2016).

18. Зегжда П.Д. Обеспечение безопасности информации в условиях создания единого информационного пространства // Защита информации. Инсайд. 2007. № 4 (16). С. 28-33.

19. Top Ten Database Security Threats. URL: http://www.imperva.com/docs/wp_topten_database_threats.pdf IMPREVA 2015 (дата обращения: 26.02.2016).

20. Кузнецов С.Д. Базы данных: учебник для студ. М.: Академия, 2012. 496 с.

21. Зегжда Д.П., Калинин М.О. Обеспечение доверенности информационной среды на основе расширения понятия «целостность» и управления безопасностью // Проблемы информ. безопасности. Компьютерные системы. 2009. № 4. С. 7-16.

22. Полтавцева М.А., Зегжда Д.П., Супрун А.Ф. Безопасность баз данных: учеб. пособие. СПб: Изд-во СПбПУ, 2015. 125 с.

5.1. Методы обеспечения безопасности

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

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

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

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

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

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

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

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

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

Избирательная защита. Класс С делится на два подкласса – С1 и С2 (где подкласс С1 менее безопасен, чем подкласс С2), которые поддерживают избирательное управление доступом в том смысле, что управление доступом осуществляется по усмотрению владельца данных.

Согласно требованиям класса С1 необходимо разделение данных и пользователя, т.е. наряду с поддержкой концепции взаимного доступа к данным здесь возможно также организовать раздельное использование данных пользователями.

Согласно требованиям класса С2 необходимо дополнительно организовать учет на основе процедур входа в систему, аудита и изоляции ресурсов.

Обязательная защита. Класс В содержит требования к методам обязательного управления доступом и делится на три подкласса – В1, В2 и В3 (где В1 является наименее, а В3 – наиболее безопасным подклассом).

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

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

Согласно требованиям класса В3 необходимо дополнительно обеспечить поддержку аудита и восстановления данных, а также назначение администратора режима безопасности.

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

Хотя некоторые коммерческие СУБД обеспечивают обязательную защиту на уровне класса В1, обычно они обеспечивают избирательное управление на уровне класса С2.

5.2. Избирательное управление доступом

Избирательное управление доступом поддерживается многими СУБД. Избирательное управление доступом поддерживается в языке SQL.

В общем случае система безопасности таких СУБД базируется на трех компонентах:

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

2. Объекты БД. По стандарту SQL2 защищаемыми объектами в БД являются таблицы, представления, домены и определенные пользователем наборы символов. Большинство коммерческих СУБД расширяет список объектов, добавляя в него хранимые процедуры и др. объекты.

3. Привилегии. Привилегии показывают набор действий, которые возможно производить над тем или иным объектом. Например пользователь имеет привилегию для просмотра таблицы.

5.3. Обязательное управление доступом

Методы обязательного управления доступом применяются к базам данных, в которых данные имеют достаточно статичную или жесткую структуру, свойственную, например, правительственным или военным организациям. Как уже отмечалось, основная идея заключается в том, что каждый объект данных имеет некоторый уровень классификации, например: секретно, совершенно секретно, для служебного пользования и т.д., а каждый пользователь имеет уровень допуска с такими же градациями, что и в уровне классификации. Предполагается, что эти уровни образуют строгий иерархический порядок, например: совершенно секретно ® секретно ® для служебного пользования и т.д. Тогда на основе этих сведений можно сформулировать два очень простых правила безопасности:

1. пользователь имеет доступ к объекту, только если его уровень допуска больше или равен уровню классификации объекта.

2. пользователь может модифицировать объекту, только если его уровень допуска равен уровню классификации объекта.

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

В последнее время методы обязательного управления доступом получили широкое распространение. Требования к такому управлению доступом изложены в двух документах, которые неформально называются "оранжевой" книгой (Orange Book) и "розовой" книгой (Lavender Book). В "оранжевой" книге перечислен набор требований к безопасности для некой "надежной вычислительной базы" (Trusted Computing Base), а в "розовой" книге дается интерпретация этих требований для систем управления базами данных.

5.4. Шифрование данных

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

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

5.5. Контрольный след выполняемых операций

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

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

2. терминал, с которого была вызвана операция;

3. пользователь, задавший операцию;

4. дата и время запуска операции;

5. вовлеченные в процесс исполнения операции базовые отношения, кортежи и атрибуты;

6. старые значения;

7. новые значения.

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

5.6. Поддержка мер обеспечения безопасности в языке SQL

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

5.7. Директивы GRANT и REVOKE

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

Обратите внимание, что создателю любого объекта автоматически предоставляются все привилегии в отношении этого объекта.

Стандарт SQL1 определяет следующие привилегии для таблиц:

1. SELECT – позволяет считывать данные из таблицы или представления;

INSERT – позволяет вставлять новые записи в таблицу или представление;

UPDATE – позволяет модифицировать записи из таблицы или представления;

DELETE – позволяет удалять записи из таблицы или представления.

Стандарт SQL2 расширил список привилегий для таблиц и представлений:

1. INSERT для отдельных столбцов, подобно привилегии UPDATE;

2. REFERENCES – для поддержки внешнего ключа.

Помимо перечисленных выше добавлена привилегия USAGE – для других объектов базы данных.

Кроме того, большинство коммерческих СУБД поддерживает дополнительные привилегии, например:

1. ALTER – позволяет модифицировать структуру таблиц (DB2, Oracle);

2. EXECUTE – позволяет выполнять хранимые процедуры.

Создатель объекта также получает право предоставить привилегии доступа какому-нибудь другому пользователю с помощью оператора GRANT. Ниже приводится синтаксис утверждения GRANT:

GRANT {SELECT|INSERT|DELETE|(UPDATE столбец, …)}, …

ON таблица ТО {пользователь | PUBLIC}

Привилегии вставки (INSERT) и обновления (UPDATE) (но не привилегии выбора SELECT, что весьма странно) могут задаваться для специально заданных столбцов.

Если задана директива WITH GRANT OPTION, это значит, что указанные пользователи наделены особыми полномочиями для заданного объекта – правом предоставления полномочий. Это, в свою очередь, означает, что для работы с данным объектом они могут наделять полномочиями других пользователей

Например: предоставить пользователю Ivanov полномочия для осуществления выборки и модификации фамилий в таблице Students с правом предоставления полномочий.

GRANT SELECT, UPDATE StName

ON Students ТО Ivanov WITH GRANT OPTION

Если пользователь А наделяет некоторыми полномочиями другого пользователя В, то впоследствии он может отменить эти полномочия для пользователя В. Отмена полномочий выполняется с помощью директивы REVOKE с приведенным ниже синтаксисом.

REVOKE {{SELECT | INSERT | DELETE | UPDATE},…|ALL PRIVILEGES}

ON таблица,… FROM {пользователь | PUBLIC},… {CASCADE | RESTRICT}

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

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

ON Students FROM Ivanov CASCADE

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

5.8. Представления и безопасность

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

Заключение

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

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

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

• * похищение и фальсификация данных;
• * утрата конфиденциальности (нарушение тайны);
• * нарушение неприкосновенности личных данных;
• * утрата целостности;
• * потеря доступности.

Вопросы защиты данных часто рассматриваются вместе с вопросами

поддержки целостности данных (по крайней мере, в неформальном контексте),

хотя на самом деле это совершенно разные понятия. Термин защита

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

• · Под защитой данных подразумевается предотвращение доступа к ним со стороны несанкционированных пользователей.
• · Под поддержкой целостности данных подразумевается предотвращение

их разрушения при доступе со стороны санкционированных пользователей.

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

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

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

Ниже описаны многочисленные аспекты проблемы защиты данных.

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

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

В случае избирательного контроля каждому пользователю обычно предоставляются различные права доступа (иначе называемые привилегиями, или полномочиями) к разным объектам. Более того, разные пользователи, как правило, обладают разными правами доступа к одному и тому же объекту. (Например, пользователю U1 может быть разрешен доступ к объекту А, но запрещен доступ к объекту B, тогда как пользователю U2 может быть разрешен доступ к объекту B, но запрещен доступ к объекту А.) Поэтому избирательные схемы характеризуются значительной гибкостью.

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

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

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

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

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

Избирательная схема управления доступом

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

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

GRANT RETRIEVE { S#, SNAME, CITY }, DELETE

TO Jim, Fred, Mary ;

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

• 1. Имя (в данном примере SA3, "suppliers authority three" -- полномочия поставщика с номером 3). Устанавливаемые полномочия будут зарегистрированы в системном каталоге под этим именем.
• 2. Одна или несколько привилегий, задаваемых в конструкции GRANT.
• 3. Задаваемое в конструкции ON имя переменной отношения, к которой применяются полномочия.
• 4. Множество пользователей (точнее, идентификаторов пользователей), которым предоставляются указанные привилегии применительно к указанной переменной отношения, задаваемой с помощью фразы ТО.

Ниже приводится общий синтаксис оператора определения полномочий.

AUTHORITY

GRANT

ON

TO ;

Мандатная схема управления доступом

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

• 1. Пользователь i может выполнить выборку данных объекта j только в том случае, если его уровень допуска больше классификационного уровня объекта j или равен ему {простое свойство безопасности -- simple security property).
• 2. Пользователь i может модифицировать объект j только в том случае, если его уровень допуска равен классификационному уровню объекта j (звездное свойство -- star property).

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

"Секретно", в файл с меньшим уровнем классификации, что нарушит всю систему секретности.

Шифрование данных

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

Для изучения основных концепций шифрования данных следует ввести некоторые новые понятия. Исходные (незашифрованные) данные называются открытым текстом.

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

Пример 5.1. Пусть в качестве открытого текста дана следующая строка.

AS KINGFISHERS CATCH FIRE (Здесь для простоты изложения предполагается, что данные состоят только из пробелов и прописных символов.) Кроме того, допустим, что ключом шифрования является следующая строка.

Ниже описывается используемый алгоритм шифрования.

1. Разбить открытый текст на блоки, длина которых равна длине ключа шифрования.

AS+KI NGFIS HERS+ CATCH +FIRE

• (Здесь пробелы обозначены знаком "+".)
• 2. Заменить каждый символ открытого текста целым числом в диапазоне 00-26, используя для пробела число 00, для А -- число 01,..., для Z -- число 26. В результате получится следующая строка цифр.
• 0119001109 1407060919 0805181900 0301200308 0006091805
• 3. Повторить п. 2 для ключа шифрования, в результате чего получится следующая строка цифр.
• 0512091520
• 4. Теперь значения, помещенные вместо каждого символа в каждом блоке открытого текста, просуммировать с соответствующими значениями, подставленными вместо символов ключа шифрования, и для каждой суммы из указанных двух значений определить и записать остаток от деления на 27.
• 5. Заменить каждое число в нижней строке п. 4 соответствующим текстовым символом.

FDIZB SSOXL MQ+GT HMBRA ERRFY

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

Управление безопасностью обычно осуществляется на трех уровнях:

• * уровень базы данных;
• * уровень операционной системы;
• * сетевой уровень.

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

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

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

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

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

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

целостность (непротиворечивость информации, ее защищенность от разрушения и несанкционированного изменения);

конфиденциальность (защита от несанкционированного прочтения).

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

К основным программно-техническим мерам, применение которых позволит решить некоторые из вышеперечисленных проблем, относятся:

аутентификация пользователя и установление его идентичности;

управление доступом к базам данных;

поддержание целостности данных;

протоколирован ие и ау дит;

защита коммуникаций между клиентом и сервером;

отражение угроз, специфичных для СУБД.

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

Управление доступом к базам данных базируется на реализации следующего минимального набора действий:

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

обеспечение безопасности повторного использования объектов;

использование меток безопасности;

принудительное управление доступом.

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

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

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

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

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

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

Протоколирован ие и ау дит состоят в следующем:

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

оценка возможных последствий состоявшегося нарушения;

оказание помощи;

организация пассивной защиты информации от нелегальных действий пользователя.

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

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