IX Международная студенческая научная конференция Студенческий научный форум - 2017

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

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

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

За первое полугодие 2016 года аналитическим центром InfoWatch было зарегистрировано 840 случаев утечки конфиденциальной информации. Это на 16% больше, чем за тот же период 2015 года [4].

Рисунок 1 График утечек конфиденциальной информации

Таким образом, проблема обеспечения безопасности баз данных является чрезвычайно важной.

«Защита БД» ­­– это способ предотвращения несанкционированного доступа к информации, хранящейся в таблицах. Для комфорта и защиты баз данных, можно выделить основные и дополнительные.

Основные средства защиты информации включают в себя:

• защиту паролем;

• защиту полей и записей таблиц базы данных.

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

• шифрование данных и программ [3].

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

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

• повышения достоверности вводимых данных;

• обеспечения целостности связей между таблицами;

• организация совместного использования объектов БД в сети [3].

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

За первое полугодие 2016 года аналитическим центром InfoWatch было зарегистрировано 506 (67%) утечек, причиной которых был инсайдер. В 250 (33%) случаях, утечка произошла из-за внешних воздействий [4].

Рисунок 2 График утечек информации

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

Существует три большие группы пользователей СУБД, которые условно можно назвать операторами, аналитиками, администраторами [2].

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

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

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

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

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

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

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

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

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

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

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

Необходимо знать кто, когда и к каким данным получает доступ.

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

Поэтому надо использовать средства внешнего аудита.

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

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

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

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

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

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

Библиографический список

1. Средства защиты базы данных [Электронный ресурс]. – Режим доступа: http://life-prog.ru/1_13285_sredstva-zashchiti-bazi-dannih.html (дата обращения – 12.12.2016).

2. Савельев М. Безопасность СУБД. // Экспресс-электроника [Электронный ресурс]. – Режим доступа: http://citforum.ru/security/articles/db_security/ (дата обращения - 12.12.2016).

3. Увайсова З.М., Билалова И.М. Защита и безопасность баз данных // Студенческий научный форум 2015 [Электронный ресурс]. – Режим доступа: https://www.scienceforum.ru/2015/1121/14145

4. Официальный сайт аналитического центра InfoWatch [Электронный ресурс]. – Режим доступа: https://www.infowatch.ru (дата обращения – 14.12.2016).

5. Сафиуллина Д.М., Басыров А.Р. Криптографические методы защиты информации [Текст] / Д.М. Сафиуллина, А.Р. Басыров // Материалы республиканской студенческой научно-практической конференции. Министерство сельского хозяйства РФ; ФГБОУ ВПО БГАУ, Уфа, 2015. - с. 32-34.

Код для цитирования: Скопировать