Главная » Вебмани » Защита баз данных. Информационная безопасность в современных системах управления базами данных

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

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

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

Размещено на 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

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

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

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

PHP сам по себе не может защитить вашу БД. Последующие разделы являются введением в основы доступа и манипулирования БД в PHP-скриптах.

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

Дизайн БД

Первый шаг - это всегда создание БД, если только вы не хотите использовать готовую БД стороннего производителя. Когда БД создаётся, она назначается пользователю, который выполняет оператор создания. Обычно только владелец/owner (или superuser) может выполнять действия с объектами в БД, а чтобы и другие пользователи могли пользоваться этой БД, необходимо дать привилегии доступа.

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

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

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

Соединение с БД

Вы можете установить соединение через SSL с целью шифровки соединения клиент/сервер для повышения защиты или использовать ssh для шифровки сетевого соединения между клиентами и сервером БД. Если вы реализуете что-нибудь из этого, то мониторинг вашего трафика и получение информации значительно усложнится.

Модель шифровки при хранении/Encrypted Storage

SSL/SSH защищает передачу данных с клиента на сервер, SSL/SSH не защищает постоянные данные, хранимые в БД. SSL это протокол on-the-wire.

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

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

Инъекция SQL

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

Direct SQL Command Injection это такая техника, когда взломщик создаёт или изменяет текущие команды SQL для получения доступа к скрытым данным, их переопределения или даже для выполнения опасных команд системного уровня на хосте БД. Это выполняется с помощью приложения, принимающего пользовательский ввод, и сочетания его со static-параметрами для построения SQL-запроса. Следующие примеры (к сожалению...) основаны на реальных фактах.

Благодаря отсутствию проверки ввода и соединения с БД или поведению superuser"а или того, кто может создавать пользователей, взломщик может создать superuser"а в вашей БД.

Обычно пользователи щёлкают ссылки "next", "prev", где $offset кодируется в URL. Скрипт ожидает, что входящее $offset это 10-ричное число. Однако кто-нибудь может попытаться вломиться, присоединив urlencode() "ированную форму следующей информации к URL:

// в PostgreSQL 0; insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd) select "crack", usesysid, "t","t","crack" from pg_shadow where usename="postgres"; -- // в MySQL 0; UPDATE user SET Password=PASSWORD("crack") WHERE user="root"; FLUSH PRIVILEGES;

Если это произойдёт, то скрипт даст доступ superuser"а к нему. Заметьте, что 0; предоставлен для того, чтобы задать правильное смещение/offset для запроса-оригинала и прервать его.

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

Возможно получение паролей путём обмана ваших страниц с результатами поиска. Взломщику нужно лишь проверить, имеется ли отправленная переменная, используемая в SQL-операторе, которая не обрабатывается надлежащим образом. Эти фильтры могут быть установлены обычно в предыдущей форме для специализирования вариантов WHERE, ORDER BY, LIMIT и OFFSET в операторах SELECT . Если ваша БД поддерживает конструкцию UNION , взломщик может попытаться присоединить к оригинальному запросу целый запрос на список паролей из произвольной таблицы. Использование шифрованных полей password настоятельно рекомендуется.

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

" union select "1", concat(uname||"-"||passwd) as name, "1971-01-01", "0" from usertable; --

Если этот запрос (играя с " и --) присоединить к одной из переменных, используемых в $query , запрос чудовищно изменится.

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

Но пользователь-злоумышленник отправляет значение " or uid like"%admin%"; -- в $uid для изменения пароля admin"а или просто устанавливает в $pwd значение "hehehe", admin="yes", trusted=100 " (с ведомым пробелом) для получения дополнительных привилегий. Затем запрос скручивается:

Если взломщик отправляет значение a%" exec master..xp_cmdshell "net user test testpass /ADD" -- в $prod , то $query будет:

$query = "SELECT * FROM products WHERE id LIKE "%a%" exec master..xp_cmdshell "net user test testpass /ADD"--"; $result = mssql_query($query);

MSSQL Server выполняет операторы SQL в пакетном режиме, включая и команды добавления нового пользователя в локальную БД бюджетов. Если такое приложение запущено как sa и служба MSSQLSERVER запущена с достаточными привилегиями, хакер сможет получить бюджет для доступа к данной машине.

Примечание: некоторые из вышеприведённых примеров касаются определённых серверов БД. Это не означает, что аналогичные действия невозможны в отношении других продуктов. Работа вашего сервера БД может быть нарушена каким-нибудь другим способом.

Как этого избежать

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

Этим атакам в основном подвергается код, написанный без учёта требований безопасности. Никогда не доверяйте вводу любого рода, особенно тому, который поступает со стороны клиента, даже если он приходит от select-списка, скрытого/hidden поля или куки/cookie. Первый пример показывает, что такой небезупречный запрос может привести к тяжким последствиям.

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

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

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

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

В случае обязательного управления, каждому объекту присваивается некий квалификационный уровень, ну а каждому пользователю предоставляются права доступа к тому или иному уровню; и соответственно, если у вас есть права доступа на какой-то уровень — все, что на этот уровень записано, ко всему у вас имеется доступ. Считается, что такие системы жесткие, статичные, но они проще в управлении: легко всем объектам дать какой-либо номер (1,2,3,4…) и пользователю потом присвоить доступ кому до 5-го, кому до 6-го, кому до 7-го уровня и т.д. в порядке повышения приоритета.

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

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

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

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

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

В стандарте ANSI ISO вместо термина «идентификатор пользователя» (user ID) используется термин «идентификатор прав доступа» (authorization ID).

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

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

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

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

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

Более высокие требования по безопасности в настоящее время мы рассматривать не будем. Такие многоуровневые системы безопасности были разработаны еще в 70х годах ХХ века. Известные фамилии: Bella, Lapadula.

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

Как правило, для администраторов баз данных сделана первоначальная учетная запись, чтоб сделать первоначальный вход в систему. Например, в InterBase: SISDBA с masterkey. В SQL-server: SA и пустой пароль. В Oracle есть 3 изначальных учетных записи: SIS, SYSTEM и MANAGER.

Г) Виды привилегий
Фактически их две:
. привилегии безопасности: выделяются конкретному пользователю, создаются, как правило, команды типа create user. Но создать пользователя в базе данных – это не значит предоставить ему права на все. Просто он может войти в базу данных, но там ничего не увидеть. После создания ему еще надо дать права.
. привилегии доступа или права доступа (permissions): предоставляют созданному пользователю те или иные привилегии. Здесь используются другие 2 команды: Grant – предоставить право на что-то (чтение, добавление, удаление, изменение записи…), Revolce.

Каким образом реализуются или ограничиваются права доступа:
. есть операционные ограничения – право на выполнение тех или иных операторов. Чаше всего это select, insert, delete и update. Во многих СУБД (в том числе Oracle) порядка 25 разных операционных прав можно предоставлять.
. Ограничения по значениям, реализуемые с помощью механизма представлений (View).
. Ограничения на ресурсы, реализуемые за счет привилегий доступа к базам данных.
. Привилегии системного уровня (для Oracle). Когда пользователю разрешается выполнять до 80 различных операторов.

Совокупность всех привилегий, которыми можно обладать называется PUBLIC. Администратор базы данных по умолчанию имеет PUBLIC-права – права на все объекты и действия.

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

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

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

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

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

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

Базовые средства защиты баз данных

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

Например, сотруднику отдела “А” временно понадобился доступ к клиенту отдела “Б”. С большой вероятностью внесение изменений в матрицу доступа к данным не будет иметь обратного характера, что в конечном итоге приводит к наличию учетных записей с сильно расширенными привилегиями, за использованием которых стоит следить.

Штатный аудит баз данных

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

Ключевые недостатки штатного аудита как защиты баз данных:

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

Автоматизированные системы защиты баз данных

Более эффективный подход – использование специализированных систем информационной безопасности в области защиты бд – решений классов DAM и DBF.

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

Такие системы позволяют разбирать трафик взаимодействия пользователей с базами данных, классифицировать SQL-запросы по принадлежности к определенных группам. Вести полный аудит SQL-запросов и ответов на них. Кроме того, решения обладают глубокой системой фильтрации, позволяющей из сотен миллионов запросов выявить потенциальные инциденты и сохранять полный архив действий пользователей, как для удовлетворения требований регуляторов, так и для задач ретроспективного анализа при расследовании инцидентов. Кроме того, специализированные системы DAM позволяют синхронизоваться с защищаемыми базами данных с целью:
  • Классификации – определение местонахождения критичной для компании информации. Опция позволяет, просканировав СУБД, увидеть названия таблиц и полей, в которых могут содержаться персональные данные клиентов. Это крайне важно для упрощения последующей настройки политик безопасности.
  • Проверки на уязвимости – соответствие конфигурации и настройки СУБД лучшим практикам.
  • Получение матрицы доступа к данным – задача решается для выявления расширенных привилегий доступа, неиспользуемым правам, и наличие так называемых «мертвых» учетных записей, которые могли остаться после увольнения сотрудника из компании.

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

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

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

На российском рынке представлено решение класса DAM «Гарда БД» от компании "Гарда Технологии". Это программно-аппаратный комплекс, который проводит непрерывный мониторинг всех запросов к базам данных и веб-приложениям в реальном времени и хранит их в течение длительного срока. Система проводит сканирование и выявление уязвимостей СУБД, такие как незаблокированные учётные записи, простые пароли, неустановленные патчи. Реагирование на инциденты происходит мгновенно в виде оповещений на e-mail и в SIEM-систему.

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

В следующей статье мы более подробно рассмотрим задачи, которые часто стоят перед DAM-системами, расскажем, почему для DAM так важно умение работы с http/http’s трафиком и как обеспечить защиту от SQL инъекций.

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

Для баз данных предъявляются особые требования с точки зрения безопасности, поэтому в них реализован другой подход к сохранению данных.

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

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

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

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

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

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

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

        1. Режимы работы с базами данных

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

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

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



Просмотров

Как очистить внутреннюю память телефона от ненужных файлов Как соединить две внутренние памяти телефона
Как очистить внутреннюю память телефона от ненужных файлов Как соединить две внутренние памяти телефона
Как настроить мобильный интернет МТС без проблем
Как настроить мобильный интернет МТС без проблем
Что делать, если телефон HTC не включается Проблема разряженной батареи
Что делать, если телефон HTC не включается Проблема разряженной батареи
Как добавить ярлык на рабочий стол
Как добавить ярлык на рабочий стол
Обзор Huawei P10 – флагман с отличной камерой и странными недостатками
Обзор Huawei P10 – флагман с отличной камерой и странными недостатками
Блютуз мышь плохо работает
Блютуз мышь плохо работает