Многие владельцы Android девайсов от Samsung жалуются, что у них возникают...
Атаки на хранилища и БД являются одними из самых опасных для предприятий и организаций. Согласно статистике компании 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 с.
С увеличением использования баз данных, частота нападения на базы данных также возросла. В наши дни атаки на базы данных являются растущей тенденцией. В чём причина нападения на БД? Одна из причин — это увеличение доступа к данным, хранящимся в базе данных. Когда данные использовались многими людьми, шансы кражи данных увеличиваются. Отсюда следует, что безопасность баз данных — это диапазон методов, которые используют для защиты информации, хранящейся в базе данных. Так как попытки взлома БД являются наиболее частыми, вам необходимо будет подумать о безопасности информационной базы, так как существует множество и других опасностей.
Физическое повреждение компьютера, неправильная кодировка или коррупция, и перезагрузка данных, вот практически все потенциальные угрозы для базы данных. А это означает, что есть много мер безопасности - от брандмауэров до аудита и резервного копирования дисков - свести любой возможный ущерб к минимуму и предотвратить потерю всей базы данных. Большинство предприятий имеют собственные протоколы безопасности данных для защиты от определенных атак и возможного ущерба.
Установка межсетевого экрана для базы данных , своеобразный защитный барьер, который запрещает все неизвестные соединения, это является самой основной формой защиты баз данных. Межсетевые экраны установлены на большинстве компьютеров и сделаны таким образом, что хакеры будут иметь трудности с подключением к компьютеру жертвы. Брандмауэры работают путем фильтрации подключений к сети и только доверенные компьютеры или пользователи могут получить доступ к базе данных. В то время как опытные хакеры могут обойти это, брандмауэр обеспечивает высокий уровень безопасности.
Шифрование — это другая мера безопасности для базы данных, в которой данные шифруются, или были сделаны неразборчивыми для всех, кто обращается к базе данных. При использовании шифрования, алгоритм кодирует символы в бред, поэтому он не может быть прочитан. Это означает, что если хакер имеет определенные знания о ключах шифрования, информацию, которая вам нужна для изменения зашифрованных данных из неразборчивых символов обратно в понятную форму, нет никакого способа, чтобы он или она могли прочитать базу данных.
Аудит — это, когда руководитель или менеджер, проверяет базу данных, чтобы убедиться, что в ней ничего не изменилось. Этот тип защиты БД обычно выполняют физически, кем-то, кто может читать базу данных, или для больших баз данных с помощью программы, чтобы увидеть, что целостность БД осталась такая же. Кроме того, аудит может включать проверку доступа к базе данных и, увидеть, что человек сделал, когда он получил доступ к базе данных. Это предотвращает кражи данных или, по крайней мере, позволяет администраторам, чтобы выяснить, кто совершил кражу данных.
Регулярное резервное копирование БД — это мера безопасности баз данных, которая может защищать БД от различных угроз. Когда резервное копирование базы данных выполняется регулярно, то это означает, что данные будут храниться на другом жёстком диске или сервере. Если база данных теряет любую или всю информацию, она может быть быстро перезапущена с минимальными потерями, используя резервную копию. Делая резервное копирование базы данных, администраторы могут предотвратить физическое повреждение компьютера, например от пожара, повреждения базы данных или базы данных выключением от перегрузки.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Министерство образования и науки Российской Федерации
Частное учреждение образовательная организация высшего образования
"Омская гуманитарная академия"
Кафедра Информатики, математики и естественнонаучных дисциплин
КУРСОВАЯ РАБОТА
на тему: Безопасность базы данных
по учебной дисциплине: Базы данных
Выполнила: Нургалиева Шынар Алтайбековна
Введение
1. Хищение информации из базы данных
1.1 Управление доступом в базах данных
1.2 Управление целостностью данных
1.3 Управление параллелизмом
1.4 Восстановление данных
1.5 Транзакция и восстановление
1.6 Откат и раскрутка транзакции
2. Безопасность баз данных
2.1 Планирование баз данных
2.2 Подключение к базе данных
2.3 Хранилище зашифрованных данных
2.4 Внедрение в SQL
2.5 Техника защиты
Заключение
Список использованных источников
Приложения
Введение
Постоянные предложения приобрести различные (в большинстве своем ведомственные) базы данных свидетельствуют о том, что продажа конфиденциальных сведений о гражданах и юридических лицах стала отдельным видом бизнеса. Если появление очередной опубликованной базы для граждан является просто еще одним малоприятным фактом обнародования сведений об их частной жизни, то на некоторых предприятиях это может отрицательно повлиять на бизнес. Например, для оператора сотовой связи распространение базы биллинга может обернуться существенным оттоком абонентов к более «надежному» оператору-конкуренту. Поэтому оператору подчас экономически более выгодно найти «производителя», подготовившего украденную базу к продаже, и выкупить весь тираж. Но проблема перекрытия возможных утечек при этом остается весьма актуальной.
Защита баз данных является одной из самых сложных задач, стоящих перед подразделениями, отвечающими за обеспечение информационной безопасности. С одной стороны, для работы с базой необходимо предоставлять доступ к данным всем сотрудникам, кто по долгу службы должен осуществлять сбор, обработку, хранение и передачу конфиденциальных данных. С другой стороны, укрупнение баз данных далеко не всегда имеет централизованную архитектуру, в связи с чем действия нарушителей становятся все более изощренными. При этом четкой и ясной методики комплексного решения задачи защиты баз данных, которую можно было бы применять во всех случаях, не существует, в каждой конкретной ситуации приходится находить индивидуальный подход.
Классический взгляд на решение данной задачи включает обследование предприятия с целью выявления таких угроз, как хищения, утрата, уничтожение, модификация, отказ от подлинности. На втором этапе следует составление математических моделей основных информационных потоков и возможных нарушений, моделирование типовых действий злоумышленников; на третьем - выработка комплексных мер по пресечению и предупреждению возможных угроз с помощью правовых, организационно-административных и технических мер защиты. Однако разнообразие деятельности предприятий, структуры бизнеса, информационных сетей и потоков информации, прикладных систем и способов организации доступа к ним и т. д. не позволяет создать универсальную методику решения.
Долгое время защита баз данных ассоциировалась с защитой локальной сети предприятия от внешних атак хакеров, борьбой с вирусами и т. п. Последние аналитические отчеты консалтинговых компаний выявили другие, более важные направления защиты информационных ресурсов компаний. Исследования убедительно показали, что от утечки информации со стороны персонала и злонамеренных действий «всесильных» администраторов баз данных не спасают ни межсетевые экраны, ни VPN, ни даже «навороченные» системы обнаружения атак и анализа защищенности. Неавторизованный доступ к данным и кража конфиденциальной информации являются главными составляющими потерь предприятий после ущерба, наносимого вирусами.
Один из основных выводов отчета CSI/FBI - значительно возросший ущерб от такой угрозы, как кража конфиденциальных данных. Каждая американская компания в среднем потеряла 355,5 тыс. долл. только из-за утечек конфиденциальных данных за прошедшие 12 месяцев. Средний размер потерь от действий инсайдеров составил 300 тыс. долл. (максимальный - 1,5 млн долл.). Решение вопросов персонифицированного доступа к конфиденциальным данным позволяет выявлять злоумышленника с помощью информации, неопровержимо доказывающей его вину. Это, в свою очередь, невозможно без применения самых современных способов аутентификации и управления доступом.
Целью данной курсовой работы является рассмотрения вопроса о безопасности баз данных.
Для решения поставленной цели необходимо решить следующие задачи:
1. Возможность избежания несанкционированного доступа к базе данных.
2. Хранение зашифрованных данных.
3. Техника защиты баз данных.
информационный база управление безопасность
1 . Хищение информации из баз данных
1.1 Управление доступом в базах данных
Сформулировать основные причины несанкционированного доступа к данным и поставленного в ряде случаев на промышленные рельсы сбыта баз данных, содержащих персональные данные абонентов, партнеров или сотрудников и коммерческие тайны компаний.
Итак, имеются следующие исходные данные:
Многие не догадываются о том, что их базы данных крадут;
Кража и причиненный ущерб имеют латентный характер;
Если факт кражи данных установлен, большинство компаний замалчивают причиненный ущерб. Одна из причин этого - отсутствие реальных механизмов сбора доказательной базы по факту кражи конкретным пользователем ресурсов;
Технологии, позволяющие строго персонифицировать действия пользователей и разграничить их права, неизвестны большинству руководителей;
Возможность защиты данных от системных администраторов также малоизвестна, руководители предпочитают считать их наиболее лояльными сотрудниками;
Бюджеты на информационную безопасность, как правило, невелики. Это не позволяет решить проблему комплексно (введение штатных единиц, отвечающих за информационную безопасность.
Основные требования по безопасности данных, предъявляемые к БД и СУБД, во многом совпадают с требованиями, предъявляемыми к безопасности данных в компьютерных системах - контроль доступа, криптозащита, проверка целостности, протоколирование и т.д.
Под управлением целостностью в БД понимается защита данных в БД от неверных (в отличие от несанкционированных) изменений и разрушений. Поддержание целостности БД состоит в том, чтобы обеспечить в каждый момент времени корректность (правильность) как самих значений всех элементов данных, так и взаимосвязей между элементами данных в БД. С поддержанием целостности связаны следующие основные требования .
Обеспечение достоверности.В каждый элемент данных информация заносится точно в соответствии с описанием этого элемента.Должны быть предусмотрены механизмы обеспечения устойчивости элементов данных и их логических взаимосвязей к ошибкам или неквалифицированным действиям пользователей.
Управление параллелизмом.Нарушение целостности БД может возникнуть при одновременном выполнении операций над данными, каждая из которых в отдельности не нарушает целостности БД. Поэтому должны быть предусмотрены механизмы управления данными, обеспечивающие поддержание целостности БД при одновременном выполнении нескольких операций.
Восстановление. Хранимые в БД данные должны быть устойчивы по отношению к неблагоприятным физическим воздействиям (аппаратные ошибки, сбои питания и т.п.) и ошибкам в программном обеспечении. Поэтому должны быть предусмотрены механизмы восстановления за предельно короткое время того состояния БД, которое было перед появлением неисправности .
Вопросы управления доступом и поддержания целостности БД тесно соприкасаются между собой, и во многих случаях для их решения используются одни и те же механизмы. Различие между этими аспектами обеспечения безопасности данных в БД состоит в том, что управление доступом связано с предотвращением преднамеренного разрушения БД, а управление целостностью - с предотвращением непреднамеренного внесения ошибки.
Большинство систем БД представляют собой средство единого централизованного хранения данных. Это значительно сокращает избыточность данных, упрощает доступ к данным и позволяет более эффективно защищать данные. Однако, в технологии БД возникает ряд проблем, связанных, например, с тем, что различные пользователи должны иметь доступ к одним данным и не иметь доступа к другим. Поэтому, не используя специальные средства и методы, обеспечить надежное разделение доступа в БД практически невозможно.
Большинство современных СУБД имеют встроенные средства, позволяющие администратору системы определять права пользователей по доступу к различным частям БД, вплоть до конкретного элемента. При этом имеется возможность не только предоставить доступ тому или иному пользователю, но и указать разрешенный тип доступа: что именно может делать конкретный пользователь с конкретными данными (читать, модифицировать, удалять и т. п.), вплоть до реорганизации всей БД Таблицы (списки) управления доступом широко используются в компьютерных системах, например, в ОС для управления доступом к файлам.Особенность использования этого средства для защиты БД состоит в том, что в качестве объектов защиты выступают не только отдельные файлы (области в сетевых БД, отношения в реляционных БД), но и другие структурные элементы БД: элемент, поле, запись, набор данных .
1.2 Управление целостностью данных
Нарушение целостности данных может быть вызвано рядом причин:
Сбои оборудования, физические воздействия или стихийные бедствия;
Ошибки санкционированных пользователей или умышленные действия несанкционированных пользователей;
Программные ошибки СУБД или ОС;
Ошибки в прикладных программах;
Совместное выполнение конфликтных запросов пользователей и др.
Нарушение целостности данных возможно и в хорошо отлаженных системах. Поэтому важно не только не допустить нарушения целостности, но и своевременно обнаружить факт нарушения целостности и оперативно восстановить целостность после нарушения.
1.3 Управление параллелизмом
Поддержание целостности на основе приведенных выше ограничений целостности представляет собой достаточно сложную проблему в системе БД даже с одним пользователем. В системах, ориентированных на многопользовательский режим работы, возникает целый ряд новых проблем, связанных с параллельным выполнением конфликтующих запросов пользователей. Прежде, чем рассмотреть механизмы защиты БД от ошибок, возникающих в случае конфликта пользовательских запросов, раскроем ряд понятий, связанных с управлением параллелизмом.
Важнейшим средством механизма защиты целостности БД выступает объединение совокупности операций, в результате которых БД из одного целостного состояния переходит в другое целостное состояние, в один логический элемент работы, называемый транзакцией. Суть механизма транзакций состоит в том, что до завершения транзакции все манипуляции с данными проводятся вне БД, а занесение реальных изменений в БД производится лишь после нормального завершения транзакции.
С точки зрения безопасности данных такой механизм отображения изменений в БД очень существенен. Если транзакция была прервана, то специальные встроенные средства СУБД осуществляют так называемый откат - возврат БД в состояние, предшествующее началу выполнения транзакции (на самом деле откат обычно заключается просто в невыполнении изменений, обусловленных ходом транзакции, в физической БД) . Если выполнение одной транзакции не нарушает целостности БД, то в результате одновременного выполнения нескольких транзакций целостность БД может быть нарушена. Чтобы избежать подобного рода ошибок, СУБД должна поддерживать механизмы, обеспечивающие захват транзакциями модифицируемых элементов данных до момента завершения модификации так называемые блокировки. При этом гарантируется, что никто не получит доступа к модифицируемому элементу данных, пока транзакция не освободит его. Применение механизма блокировок приводит к новым проблемам управления параллелизмом, в частности, к возникновению ситуаций клинча двух транзакций. Причем, если некоторая транзакция пытается блокировать объект, который уже блокирован другой транзакцией, то ей придется ждать, пока не будет снята блокировка объекта транзакцией, установившей эту блокировку. Иными словами, блокировку объекта может выполнять только одна транзакция .
1.4 Восстановление данных
Восстановление данных - процесс получения доступа к файлам, записанным на том или ином носителе информации, которые стали недоступными вследствие программного сбоя, выхода носителя из строя или ошибочных действий пользователя. Возможность восстановления данных при помощи специальных программ существует в том случае, если они не были перезаписаны другой информацией. Также во многом успех зависит от сохранности структуры файловой системы и работоспособности носителя вообще.
Как известно, данные на любом современном носителе информации на самом низком уровне хранятся в виде битовых последовательности нулей и единичек. То есть, в виде намагниченных/заряженных секторов (1) или их отсутствия (0).
Однако, Windows и прочие операционные системы для ускорения и упрощения доступа к данным работают на более высоких уровнях с использованием различных файловых систем. Файловая система представляет собой программную прослойку для эффективного взаимодействия ОС с информацией на физическом носителе. Она состоит из двух частей: системной области и области данных. Системная область хранит в себе загрузочный сектор (отвечает за возможность загрузки с носителя и его корректное распознавание), а также ряд секторов, хранящих индексные таблицы файлов и иную служебную информацию.
Вся информация физически хранится в области данных, однако, ведомости о файлах находятся в системной области. Механизм такой организации работы выглядит следующим образом: при подключении носителя к компьютеру система не сканирует весь диск на наличие файлов, а быстро считывает данные о них из системной области. Так же ОС взаимодействует с носителем, например, при удалении данных: физически файлы не уничтожаются, а удаляются лишь ссылки на них в файловой таблице. Это даёт системе основания считать "освободившиеся" кластеры носителя пустыми и пригодными для дальнейшей перезаписи. Таким образом, первый случай, когда восстановление данных возможно - исчезновение ссылки на файл в файловой таблице при условии, что файл не был перезаписан иными данными. Второй распространённый случай - форматирование носителя. Существует три типа форматирования:
Быстрое форматирование - стирается только файловая таблица, но не затрагивается область данных. При таком форматировании шансы на восстановления весьма высоки (при условии, что на отформатированную флешку ничего больше не записывалось).
Полное форматирование - стирается и системная область, и область данных. Этот тип форматирования предусматривает полную очистку носителя, однако, для ускорения процесса стирается область данных не полностью, а фрагментами. Это даёт (пусть и небольшой) шанс на восстановление нужных файлов.
Низкоуровневое форматирование - все секторы носителя информации заполняются нулями. После такого форматирования восстановить что-либо практически нереально, поскольку все данные уничтожаются полностью. В Windows штатно отсутствует возможность низкоуровневого форматирования, поэтому даже после полной очистки диска её средствами восстановление данных теоретически возможно! Аналогично можно попробовать восстановить информацию при сбоях файловых систем, которыми часто "грешат" флешки. При таких сбоях обычно частично или полностью уничтожается системная область и флешка требует форматирования:
Как уже отмечалось, возникновение сбоев в аппаратном или программном обеспечении может вызвать необходимость восстановления и быстрого возвращения в состояние, по возможности близкое к тому, которое было перед возникновением сбоя (ошибки). К числу причин, вызывающих необходимость восстановления, зачастую относится и возникновение тупиковой ситуации.
Можно выделить три основных уровня восстановления:
Оперативное восстановление, которое характеризуется возможностью восстановления на уровне отдельных транзакций при ненормальном окончании ситуации манипулирования данными (например, при ошибке в программе).
Промежуточное восстановление.Если возникают аномалии в работе системы (системно-программные ошибки, сбои программного обеспечения, не связанные с разрушением БД), то требуется восстановить состояние всех выполняемых на момент возникновения сбоя транзакций.
Длительное восстановление. При разрушении БД в результате дефекта на диске восстановление осуществляется с помощью копии БД. Затем воспроизводят результаты выполненных с момента снятия копии транзакций и возвращают систему в состояние на момент разрушения .
1.5 Транзакция и восстановление
Прекращение выполнения транзакции вследствие появления сбоя нарушает целостность БД. Если результаты такого выполнения транзакции потеряны, то имеется возможность их воспроизведения на момент возникновения сбоя. Таким образом, понятие транзакции играет важную роль при восстановлении. Для восстановления целостности БД транзакции должны удовлетворять следующим требованиям:
Необходимо, чтобы транзакция или выполнялась полностью, или не выполнялась совсем;
Необходимо, чтобы транзакция допускала возможность возврата в первоначальное состояние, причем, для обеспечения независимого возврата транзакции в начальное состояние монопольную блокировку необходимо осуществлять до момента завершения изменения всех объектов;
Необходимо иметь возможность воспроизведения процесса выполнения транзакции, причем, для обеспечения этого требования, совместную блокировку необходимо осуществлять до момента завершения просмотра данных всеми транзакциями.
В процессе выполнения любой транзакции наступает момент ее завершения. При этом все вычисления, сделанные транзакцией в ее рабочей области, должны быть закончены, копия результатов ее выполнения должна быть записана в системный журнал. Подобные действия называют операцией фиксации. При появлении сбоя целесообразнее осуществлять возврат не в начало транзакции, а в некоторое промежуточное положение. Точку, куда происходит такой возврат, называют точкой фиксации (контрольной точкой). Пользователь может установить в процессе выполнения транзакции произвольное количество таких точек. Если в ходе выполнения транзакции достигается точка фиксации, то СУБД автоматически осуществляет указанную выше операцию .
1.6 Откат и раскрутка транзакции
Основным средством, используемым при восстановлении, является системный журнал, в котором регистрируются все изменения, вносимые в БД каждой транзакцией. Возврат транзакции в начальное состояние состоит в аннулировании всех изменений, которые осуществлены в процессе выполнения транзакции. Такую операцию называют откатом. Для воспроизведения результатов выполнения транзакции можно, используя системный журнал, восстановить значения проведенных изменений в порядке их возникновения, либо выполнить транзакцию повторно. Воспроизведение результатов выполнения транзакции с использованием системного журнала называется раскруткой. Раскрутка является достаточно сложной, но необходимой операцией механизмов восстановления современных БД
2 . Безопасность баз данных
2.1 Планирование баз данных
Сегодня базы данных - основная составляющая практически любых приложений, основанных на Web, которая дает возможность предоставления разнообразного динамического содержимого. Поскольку в таких базах данным может храниться весьма важная и секретная информация, нужно позаботиться и об их защите. Архитектура, используемая при создании Web-страниц с помощью PL/SQL WebToolkit, на удивление проста, как показано на рис.1 (см. Приложение А).
Для получения или сохранения информации в базе данных, к ней нужно подключиться, послать запрос, обработать ответ и закрыть подключение. Сегодня для всего этого обычно используется структурированный язык запросов (Structured Query Language, SQL). Давайте посмотрим, как злоумышленник может поступить с SQL-запросом .
Как известно, PHP не может сам защитить базу данных. Следующие разделы являются введением в основы доступа и использования баз данных в скриптах на PHP.
Помните простое правило: защита строится "вглубь". Чем больше мест вы защитите и чем больше действий предпримете для защиты базы данных, тем меньше вероятность успеха у злоумышленника на извлечение и использование хранимой в ней секретной информации. Все опасные места устраняются правильной разработкой структуры базы данных и использующего ее приложения.
Первый шаг всегда - собственно создание базы данных, за исключением случаев использования чужих баз. Когда создается база данных, ей назначается владелец, который и вызвал команду создания. Обычно только один владелец ("суперпользователь") может делать что угодно с объектами внутри этой базы данных и для того, чтобы позволить другим пользователям использовать ее, им должны быть назначены права доступа.
Приложения никогда не должны подключаться к базе данных в роли ее владельца или "суперпользователя", поскольку в этом случае пользователи могут произвести любые действия вроде модификации схемы (к примеру, удаления таблиц) или удаления всего ее содержимого.
Можно создать различных пользователей баз данных для каждого необходимого действия приложений, очень сильно ограничивая доступ последних к объектам базы данных. Требуемые права должны назначаться однократно, их использования в других местах приложения нужно избегать. Это значит, что если злоумышленник получит доступ с использованием той или иной учетной записи, он сможет получить лишь тот доступ, которым обладала использованная часть программы.
В приложения лучше не вводить всю логику работы с базами данных. Это можно сделать и в самой базе данных с использованием флагов, представлений, правил и встроенных процедур. В случае развития и расширения системы встроенные процедуры могут быть изменены для автоматической обработки новых полей, а флаги предоставят дополнительные возможности для отладки транзакций.
2.2 Подключение к базе данных
Можно устанавливать подключения с помощью SSL для шифрования соединений клиент-сервер, что дает повышенную безопасность. А можно использовать ssh для шифрования сетевых соединений между клиентами и сервером баз данных. Любой из этих способов сильно усложняет отслеживание и получение информации из сетевого траффика.
2.3 Хранение зашифрованных данных
SSL/SSH защищает данные только по пути от клиента к серверу, но не данные, хранимые в базе данных. SSL - лишь сетевой протокол.
Когда злоумышленник получает доступ к вашей базе данных в обход Web-сервера, хранимые важные данные могут быть получены и использованы, за исключением случая, когда информация защищена в самой базе данных. Шифрование - весьма хороший прием в этом случае, но такой способ поддерживают ныне лишь очень немногие системы управления базами данных.
Самый легкий путь в этом случае - создать свою собственную систему шифрования, а затем использовать ее в скриптах на PHP. PHP способствует такому подходу благодаря наличию специфичных раширений, таких, как Mcrypt и Mhash, охватывающих большой ряд алгоритмов шифрования. Программа шифрует сохраняемые данные и расшифровывает получаемые. Для детального описания схем шифрования смотрите ссылки .
В случае скрытых данных, где не требуется их исходный вид (к примеру, для отображения), можно использовать хеширование. Известным примером хеширования является сохранение в базе данных хеша MD5 от пароля вместо самого пароля. Для подробного описания смотрите crypt() и md5().
Пример: Использование хешированных паролей
// сохраняем хеш от пароля
$query = sprintf("INSERT INTO users(name,pwd) VALUES("%s","%s");",
// проверяем корректность введенного пользователем пароля
$query = sprintf("SELECT 1 FROM users WHERE name="%s" AND pwd="%s";",
addslashes($username), md5($password));
$result = pg_exec($connection, $query);
if (pg_numrows($result) > 0) {
echo "Добро пожаловать, $username!";
echo "Введен неверный пароль для $username.";
2.4 Внедрение в SQL
Многие разработчики Web-приложений считают запросы SQL не стоящими, внимания не зная о том, что их может использовать злоумышленник. Это означает, что запросы SQL могут быть использованы для обхода систем защиты, аутентификации и авторизации, а также иногда могут быть использованы для получения доступа к командам уровня операционной системы.
Внедрение в команды SQL - техника, при которой злоумышленник создает или изменяет команды SQL для получения доступа к скрытым данным, для изменения существующих и даже для выполнения команд уровня операционной системы. Это достигается в том случае, если программа использует введенные данные в комбинации со статическими параметрами для создания запроса SQL. Следующие примеры, к сожалению, основаны на реально произошедших случаях:
При недостаточной проверке вводимых данных и соединении с базой данных на правах суперпользователя злоумышленник может создать нового суперпользователя в базе данных.
Пример: Разделение результата запроса по страницам и... создание суперпользователей (PostgreSQL и MySQL)
$offset = argv; // внимание! нет проверки данных!
// в PostgreSQL
$result = pg_exec($conn, $query);
$result = mysql_query($query);
Обычно пользователи используют кнопочки "следующая" и "предыдущая", где $offset внедрен в URL. Программа считает, что $offset - число. Однако, кто-нибудь может попытаться внедриться путем добавления urlencode()-кодированных данных в URL
// в случае PostgreSQL
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
select "crack", usesysid, "t","t","crack"
from pg_shadow where usename="postgres";
// в случае MySQL
UPDATE user SET Password=PASSWORD("crack") WHERE user="root";
FLUSH PRIVILEGES;
Если это случится, программа предоставит ему доступ суперпользователя. Заметим, что 0; служит для того, чтобы задать корректное смещение для исходного запроса и завершить его.
Обычная практика - заставить транслятор SQL проигнорировать остаток запроса разработчика с помощью обозначения начала коментария SQL --.
Существует путь получения паролей через ваши страницы поиска. Все, что нужно злоумышленнику - это одна не обработанная должным образом переменная, используемая в SQL-запросе. Использоваться могут команды WHERE, ORDER BY, LIMIT и OFFSET запроса SELECT. Если ваша база данных поддерживает конструкцию UNION, злоумышленник может добавить к исходному запросу еще один - для получения паролей. В этом случае поможет хранение зашифрованных паролей .
Пример: Вывод статей... и паролей (любой сервер баз данных)
$query = "SELECT id, name, inserted, size FROM products
WHERE size = "$size"
ORDER BY $order LIMIT $limit, $offset;";
$result = odbc_exec($conn, $query);
Статическая часть запроса может быть совмещена с другим запросом SELECT, который выведет все пароли:
union select "1", concat(uname||"-"||passwd) as name, "1971-01-01", "0" from usertable;
Если подобный запрос (использующий " и --) будет задан в одной из переменных, используемых $query, то атака будет успешной.
Запросы SQL "UPDATE" также могут быть использованы для атаки на базу данных. Эти запросы также подвержены опасности "обрезки" и добавления новых запросов. Но здесь злоумышленник работает с командой SET. В этом случае необходимо знание некоторой информации о структуре базы данных для удачной модификации запроса. Такая информация может быть получена путем изучения названий переменных форм или просто подбором. В конце концов, не так уж и много имен придумано для полей пользователей и паролей.
Пример: От сброса пароля до получения привилегий... (любой сервер баз данных)
$query = "UPDATE usertable SET pwd="$pwd" WHERE uid="$uid";";
Злоумышленник посылает значение " or uid like"%admin%"; --, в переменную $uid для изменения пароля администратора или просто устанавливает $pwd в "hehehe", admin="yes", trusted=100 " (с завершающим пробелом) для получения прав. Запрос будет искажен так:
// $uid == " or uid like"%admin%"; --
$query = "UPDATE usertable SET pwd="..." WHERE uid="" or uid like "%admin%"; --";
// $pwd == "hehehe", admin="yes", trusted=100 "
$query = "UPDATE usertable SET pwd="hehehe", admin="yes", trusted=100 WHERE ...;"
А вот пример того, как на некоторых серверах баз данных могут быть выполнены команды уровня операционной системы:
Пример: Атака на операционную систему сервера баз данных (сервер MSSQL)
$query = "SELECT * FROM products WHERE id LIKE "%$prod%"";
Если злоумышленник пошлет значение 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 выполняет все команды SQL, включая команду добавления нового пользователя в локальную базу данных пользователей. Если это приложение было запущено, как sa и служба MSSQLSERVER имеет достаточно прав, злоумышленник будет иметь учетную запись для доступа к этой машине.
Некоторые из вышеперечисленных примеров привязаны к конкретному серверу баз данных. Но это вовсе не означает, что подобная атака невозможна на другое программное обеспечение. Ваш сервер баз данных тоже так или иначе будет уязвим для непредвиденных атак .
2.5 Техника защиты
В большинстве примеров видно, что для атаки злоумышленник должен обладать некоторой информацией. Все верно, но никогда заранее не известно, какими путями уйдет данная информация. Если это все-таки случится, база данных становится незащищенной. Если вы используете свободно распространяемый пакет управления базами данных, который принадлежит какой-нибудь системе управления содержимым или форуму, злоумышленник легко получит копию данной части вашей программы. Это также может представлять "дыру" в безопасности.
Большинство атак построены на использовании кода, который писался без учета соображений безопасности. Никогда не доверяйте введенным данным, особенно если они идут с клиентской стороны, пусть даже и из поля отметки, скрытого поля или записи cookie. Первый пример показывает, к чему может привести подмена этих данных.
Никогда не соединяйтесь с базой данных в роли суперпользователя или владельца. Всегда используйте специальных пользователей с минимумом прав.
Проверяйте ввод на совпадение типа данных с требуемым. PHP включает в себя большое количество проверочных функций, от самых простейших из разделов "Функции для работы с переменными" и "Функции обработки символьного типа", (к примеру is_numeric() и ctype_digit() соответственно) до регулярных выражений Perl ("Регулярные выражения, совместимые с Perl").
Если программа ожидает число, проверяйте данные с помощью is_numeric(), или просто изменяйте тип с помощью settype(), или даже используйте численное представление, выданное sprintf().
Пример: Более безопасная разбивка на страницы
settype($offset, "integer");
$query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
// отметим %d в строке форматирования, использование %s бесполезно
$query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",
Необходимо предварять любой нечисловой ввод, передаваемый в базу данных, функциями addslashes() или addcslashes(). В первом примере показано, что кавычек в статической части запроса недостаточно.
Нельзя выводить никакой информации о структуре базы данных ни коим образом.
Можно использовать хранимые процедуры и заданные расположения для того, чтобы отвязать обращение к данным от программы так, чтобы пользователи не имели прямого доступа к таблицам и представлениям, но этот вариант имеет собственные проблемы.
Кроме того, необходимо вести журнал операций в программе или собственно в базе данных, если это поддерживается. Ведение журнала не предотвратит внедрения, но оно поможет определить, какая часть программы была поставлена под удар. Сам журнал бесполезен - полезна хранимая в нем информация. Чем ее больше - тем лучше.
Заключение
На сегодняшний день базы данных являются ключевыми компонентами большинства веб-приложений, позволяя предоставлять на сайтах динамический контент. Поскольку в таких БД может храниться очень точная или конфиденциальная информация, вы должны обеспечить хорошую защиту данных.
Для извлечения или сохранения любых данных вам необходимо открыть соединение с базой данных, отправить верный запрос, извлечь результат и закрыть соединение. В настоящее время наиболее распространенный стандарт общения - структурированный язык запросов (SQL). Всегда следует помнить о возможности атаки посредством SQL-запроса.
Очевидно, что сам по себе PHP не может защитить вашу базу данных. Этот раздел документации рассказывает об основах безопасного доступа и управления данными в PHP-скриптах.
Запомните простое правило: максимальная защита. Чем больше потенциально опасных участков системы вы проработаете, тем сложнее будет потенциальному взломщику получить доступ к базе данных или повредить ее. Хороший дизайн базы данных и программных приложений поможет вам справиться с вашими страхами.
Первый шаг - это всегда создание БД, исключая тот случай, когда вы хотите использовать готовую базу, предоставляемую третьим лицом. После того, как база данных создана, она назначается пользователю, который выполнил создавший БД запрос. Как правило, только владелец (или суперпользователь) может выполнять различные действия с различными объектами, хранимыми в базе данных. Для того, чтобы и другие пользователи имели к ней доступ, их необходимо наделить соответствующими привелегиями.
Приложения не должны соединяться с базой данных, используя учетную запись владельца или суперпользователя, иначе они смогут модифицировать структуру таблиц (например, удалить некоторые таблицы) или даже удалить все содержимое БД целиком.
Вы можете создать различные учетные записи пользователей БД для каждой индивидуальной потребности приложения с соответствующими функциональными ограничениями. Рекомендуется назначать только самые необходимые привилегии, также вы должны избегать ситуаций, когда один и тот же пользователь может взаимодействовать с базой данных в нескольких режимах. Вы должны понимать, что если злоумышленник сможет воспользоваться какой-либо учетной записью вашей БД, он сможет вносить в базу все те изменения, что и программа, которая использует текущую учетную запись.
Не обязательно реализовывать всю бизнес-логику в веб-приложении (т.е. в скриптах), для этого также можно использовать возможности, предоставляемые базой данных: триггеры, представления, правила. В случае роста системы вам понадобятся новые соединения с БД, и логику работы понадобиться дублировать для каждого нового интерфейса доступа. Исходя из вышесказанного, триггеры могут использоваться для прозрачной и автоматической обработки записей, что часто необходимо при отладке приложений или при трассировке отката транзакций.
В зависимости от используемой операционной системы необходимо предусматривать возможность атаки на разнообразные файлы, включая системные файлы устройств (/dev/ или COM1), конфигурационные файлы (например /etc/ или файлы с расширением.ini), хорошо известные области хранения данных (/home/, My Documents), и так далее. Исходя из этого, как правило, легче реализовать такую политику безопасности, в которой запрещено все, исключая то, что явно разрешено.
Поскольку администраторы корпоративных БД не всегда могут уделять безопасности необходимое время, некоторые компании принимают более активные меры. Они освобождают этих сотрудников от исполнения их обычных обязанностей и включают в состав группы, занимающейся ИТ-безопасностью.
Учреждение такой должности решает сразу две проблемы: специалисты по ИТ-безопасности, не обладающие большими познания в области баз данных, могут воспользоваться помощью профессионалов, а администраторы БД получают возможность сфокусировать свою деятельность на вопросах защиты иформации и получить подготовку, необходимую для обеспечения сохранности корпоративных БД.
Список использованных источников
1.Бойченко И. А. Проектирование компонентов доверенной среды реляционной СУБД на основе CASE-технологий [Текст] / И. А. Бойченко - Воронеж, 2014. - 251с.
2.Борри Х. Firebird: руководство работника баз данных [Текст]: пер. с англ. / Х. Бори. - СПб.: БХВ - Петербург, 2012. - 1104с.
3.Броневщук Е. С. Система управления базами данных [Текст] / Е.С. Броневщук, В. И. Бурдаков, Л. И. Гуков. - М.: Финансы и статистика, 2013. - 634с.
4.Гончаров А. Ю. Access 2007. Справочник с примерами [Текст] / А. Ю. Гончаров. - М.: КУДИЦ - ПРЕСС, 2011. - 296с.
5.Дейт К. Введение в системы баз данных [Текст] / К. Дейт 7-е изд. - М.: СПб.: Вильямс, 2013. - 325с.
6. Каленик А. Использование новых возможностей MS SQL Server 2005 [Текст] / А. Каленик. - СПб.: Питер, 2013. - 334с.
7. Конноли Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика [Текст] / Т. Конноли, Л Бегг, А. Страган 2-е изд. - М.: Вильямс, 2012. - 476с.
8. Мотев, А. А. Уроки My SQL. Самоучитель [Текст] / А. А. Мотев. - СПб.: БХВ - Петербург, 2013. - 208с.
9. Оппель Э. Раскрытие тайны SQL [Текст]: пер. с англ. / Э. Опель, Джим Киу, Д. А. Терентьева. - М.: НТ Пресс, 2012. - 320с.
10. Промахина И. М.Интерфейсы сетевой СУБД (ПЭВМ) с языками высокого уровня [Текст] / И. М. Промахина - М.: ВЦ РАН, 2011.- 874с.
11. Фуфаев Э. В., Базы данных; [Текст] / Э. В. Фуфаев, Д. Э. Фуфаев - Академия - Москва, 2013. - 320 c.
12. Фрост, Р. Базы данных. Проектирование и разработка [Текст]: пер. с англ. / Р. Фрост, Д. Дей, К. Ван Слайк, А. Ю. Кухаренко. - М.: НТ Пресс, 2007. - 592с.
Приложение А
Рисунок А.1 - Архитектура, используемая при создании Web-страниц
Приложение Б
Рисунок Б.1 - Схема защиты информации
Размещено на Allbest.ru
...Подобные документы
Основы безопасности персональных данных. Классификация угроз информационной безопасности персональных данных, характеристика их источников. Базы персональных данных. Контроль и управление доступом. Разработка мер защиты персональных данных в банке.
дипломная работа , добавлен 23.03.2018
Рассмотрение проблемы обеспечения санкционированности использования информации в базах данных (защита данных от нежелательной модификации, уничтожения, заражения программами-вирусами) и юридического регулирования безопасности на примере СУБД Ms SQL.
курсовая работа , добавлен 30.03.2010
Что такое базы данных, визуализация информации базы. Структура и свойства простейшей базы данных. Характеристика определений, типов данных, безопасность, специфика формирования баз данных. Подходы к проектированию технического задания. Работа с таблицами.
презентация , добавлен 12.11.2010
Формы представляемой информации. Основные типы используемой модели данных. Уровни информационных процессов. Поиск информации и поиск данных. Сетевое хранилище данных. Проблемы разработки и сопровождения хранилищ данных. Технологии обработки данных.
лекция , добавлен 19.08.2013
Сущности и функциональные зависимости базы данных. Атрибуты и связи. Таблицы базы данных. Построение ER-диаграммы. Организация ввода и корректировки данных. Реляционная схема базы данных. Реализация запросов, получение отчетов. Защита базы данных.
курсовая работа , добавлен 06.02.2016
Основные виды баз данных. Система управления базами данных. Анализ деятельности и информации, обрабатываемой в поликлинике. Состав таблиц в базе данных и их взаимосвязи. Методика наполнения базы данных информацией. Алгоритм создания базы данных.
курсовая работа , добавлен 17.12.2014
Эволюция концепций баз данных. Требования, которым должна удовлетворять организация базы данных. Модели представления данных. Язык SQL как стандартный язык баз данных. Архитектуры баз данных. Среда Delphi как средство для разработки СУБД.
дипломная работа , добавлен 26.11.2004
Понятие базы данных, модели данных. Классификация баз данных. Системы управления базами данных. Этапы, подходы к проектированию базы данных. Разработка базы данных, которая позволит автоматизировать ведение документации, необходимой для деятельности ДЮСШ.
курсовая работа , добавлен 04.06.2015
Процессы обработки информации. Эффективность автоматизированной информационной системы. Система управления базой данных. Локальная и распределенная система банков и баз данных. Этапы проектирования базы данных. Различие уровней представления данных.
контрольная работа , добавлен 07.07.2015
Проектирование базы данных Access. Система управления базами данных. Создание и обслуживание базы данных, обеспечение доступа к данным и их обработка. Постановка задач и целей, основных функций, выполняемых базой данных. Основные виды баз данных.
Тема: Проблемы безопасности баз данных. Обеспечение безопасности в СУБ
Тип: Курсовая работа | Размер: 46.53K | Скачано: 76 | Добавлен 15.10.16 в 05:44 | Рейтинг: 0 | Еще Курсовые работы
ВВЕДЕНИЕ... 3
Глава 1.Определение защиты информации.... 7
1.1.Основные определения и понятия .. 7
1.2. Защита информации в базах данных .. 10
Глава 2.Ключевые подходы защиты базы данных 15
2.1.Политика прав доступа к данным ... 15
2.2. Система защиты СУБД Access . 16
2.3. Организация системы защиты СУБД MS SQL Server .. 21
ЗАКЛЮЧЕНИЕ... 33
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ..... 37
ВВЕДЕНИЕ
Доступ к ресурсам информационной системы - это, фактически, доступ к данным, находящимся в хранилище под управлением СУБД. В таком контексте нарушением безопасности является несанкционированный доступ, который тем или иным способом может получить потенциальный злоумышленник. Поэтому обеспечение надёжной и безопасной аутентификации - важнейшая задача как для разработчиков, так и для администраторов систем. Существует несколько основных методов аутентификации, которые обеспечивают разную степень безопасности. Выбор метода должен основываться на следующих факторах:
Надёжность, достоверность и неотказуемость;
Стоимость решения, стоимость администрирования;
Соответствие общепринятым стандартам;
Простота интеграции в готовые решения и в новые разработки.
Как правило, более надёжные методы являются более дорогостоящими как для разработки, так и для администрирования. Наиболее надёжным методом аутентификации на сегодняшний день является двухфакторная аутентификация с использованием цифровых сертификатов X.509, которые хранятся в защищённой памяти смарт-карт или USB-ключей. Оба этих устройства обеспечивают одинаковую степень надёжности аутентификации, но смарт-карты требуют дополнительного оборудования, что, естественно, увеличивает стоимость решения.
Также необходимо обратить внимание на следующие аспекты:
Интеграцию с внешними системами аутентификации;
Безопасность соединений;
Защиту данных на любом уровне;
Выборочное шифрование данных;
Подробный аудит действий пользователей;
Централизованное управление аутентификацией и авторизацией пользователей.
Обычно разработчики программного обеспечения не уделяют должного внимания вопросам защиты данных, стараясь по максимуму удовлетворить пожелания заказчиков по функциональности системы. В результате подобные проблемы решаются зачастую в процессе внедрения системы, и это приводит к ситуациям, когда «защищённое» приложение содержит «секретные» коды, прошитые в исходных текстах программ или в файлах настройки.
Определённые трудности для разработчиков представляют ситуации, когда заказчик системы сам толком не представляет, от кого и что собственно следует защищать.
Интеграторы при внедрении систем на предприятии заказчика уделяют большое внимание защите, но здесь акценты смещены в сторону внешних атак - троянов, вирусов, хакеров.
Вопросы «внутренней» безопасности и в этом случае остаются открытыми. В такой ситуации усилия системных администраторов, неосведомлённых в полной мере о бизнес-процессах предприятия, направлены на «урезание» прав пользователей, что существенно осложняет работу системы в целом, а иногда приводит к её полной остановке.
Мероприятия по защите информации должны включать решение следующих вопросов:
Определение угроз безопасности и групп потенциальных нарушителей;
Определение групп приложений, обеспечивающих бизнес-процессы предприятия;
Определение групп пользователей системы;
Определение объектов, хранящих данные и подлежащих защите;
Определение политик безопасности;
Определение методов хранения связей пользователь - права доступа - данные;
Выбор метода аутентификации и способов её реализации;
Подготовка методики по обеспечению безопасности инфраструктуры сети, СУБД, серверов приложений, клиентских приложений.
Также весьма популярным способом получения несанкционированного доступа к содержимому базы данных является попытка прочитать файлы БД на уровне ОС (как обычные файлы). Если администратором БД не были предприняты дополнительные меры по шифрованию содержащейся в ней информации (а чаще всего это именно так), то простое копирование файлов БД по сети и последующий прямой просмотр их содержимого позволят злоумышленнику получить доступ к хранящейся в БД информации.
Именно поэтому защищённая система должна быть спроектирована и построена так, чтобы:
Файлы программного обеспечения СУБД не были доступны по сети;
К файлам БД на сервере не было доступа по сети — пользователи получают доступ
к информации, хранящейся в БД, только посредством СУБД;
Сами файлы БД были зашифрованы. Шифрование файлов БД используется как
простой и эффективный способ защиты данных от несанкционированного доступа
в случае физического обращения злоумышленника к носителю информации;
Сервер БД не выполнял функции файлового сервера. Актуальность данной темы обусловлена тем, что на сегодняшний день использование баз данных встречается практически в любой сфере деятельности, начиная от библиотеки и заканчивая организацией занимающейся транспортировкой.
Целью данной работы является рассмотрение основных задач и проблем, при разработке оптимальной системы защиты и безопасности, поставленных перед управляющим баз данных. В данной работе будут рассмотрены в основе своей, проблемы, связанные с обеспечением безопасности, а так же сохранением целостности базы данных.
Объект исследования в данной работе это база данных. Мы будем рассматривать как понятие базы данных в целом, так и будем рассматривать конкретные примеры некоторых основных баз данных, таких как MS SQL Server, Oracle, Microsoft Access.
Большая часть терминов и основных понятий была взята из книги авторов Голицына О.Л., Максимов Н.В. и др. «Базы данных», это позволило дать вначале своего рода введение в основную часть курсовой работы.
Таким образом, в данной работе мы рассмотрим как обобщённые понятия и задачи базы данных, так и конкретные примеры и проблемы встречающиеся в частных случаях.
Основная часть данной работы будет направлена на рассмотрение основных аспектов защиты баз данных, а так же их реализация на нескольких примерах существующих СУБД.
СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ
- Артёмов.Д.К., «Microsoft SQL Server 2000: профессионалы для профессионалов» - Ростов на Дону: Русская Редакция, 2005, С. 88-112
- Голицына О.Л., Максимов Н.В. и др. «Базы данных» - Москва: ИНФРА-М,2007,С. 10-135.
- Гольев Ю.И., Ларин Д.А., Тришин А.Е., Шанкин Г.П. Криптографическая деятельность в США XVIII-XIX веков. // Защита информации. Конфидент. №6, 2004, С. 68-74
- Гринвальд Р., Стаковьяк Р., Стерн Дж.« Oraclee 11g. Основы. 4-е изд.» - Москва: Символ, 2009 - С. 65-97
- ГашковС. Б. У., Э. А. Применко, М. А. Черепнев «Криптографические методы защиты информации» - Москва: Академия, 2010, С 40-45
- Дунаев В. И. «Базы данных. Язык SQL для студента» - Санкт Петербург: СПб:Питер, 2007, С. 91-95
- Ищейнов В. Я., М. В. Мецатунян «Защита конфиденциальной информации» - Челябинск:Форум, 2009,С.114-145
- Корнеев И. К., Е. А. «Защита информации в офисе» - Казань: ТК Велби, 2008, С.38-56
- Кошелев В.Е., «Базы данных в Access 2007» - Москва: Бином, 2009, С. 47 - 98
- Кригель А. К., Борис Трухнов «SQL. Библия пользователя»- Москва: Вильям, 2010, С. 68 - 71
- Кумскова И. А. «Базы Данных».-Москва:КноРус, 2011, С. 140-142
- Партыка Т.Л., Попов И.И. «Информационная безопасность» - Москва: Форум: инфра, 2004, С. 45-87
- Северин В. А. «Комплексная защита информации на предприятии» - Москва:Городец,2008, С 92
- Сергеева Ю. С. «Защита информации. Конспект лекций» - Санкт Петербург: А-Приор, 2011, С. 150-176
- Смирнов.С. Н. «Безопасность систем баз данных» - Москва: Гелиос АРВ,2007, 224 с.
- Безопасность баз данных на примере Oraclee [Электронный ресурс].URL: http://www.flenov.info/favorite.php?artid=32
