Letysite.ru

IT Новости с интернет пространства
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Модели безопасности баз данных

Основные аспекты безопасности СУБД: что следует знать

    Статьи, 25 ноября 2016 в 19:35

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

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

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

История развития СУБД

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

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

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

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

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

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

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

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

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

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

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

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

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

Хранилища данных включает в себя два компонента: хранимые данные (собственно БД) и программы управления (СУБД).

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

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

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

Архитектура применяемых языков, по крайней мере, то, что касается специализированных языков и наборов функций, напрямую связана с моделью данных, применяемой для хранения информации. Таким образом, модель определяет особенности языка, и наличие в нем тех или иных уязвимостей. Причем такие уязвимости, например, как инъекция, выполняются по-разному (sql-инъекция, java-инъек­ция) в зависимости от синтаксиса языка.

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

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

Не зависящими от данных мож­но назвать следующие требования к безопасной системе БД:

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

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

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

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

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

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

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

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

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

  • Безопасная организация и работа с данными.

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

Основные аспекты создания защищенных БД

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

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

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

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

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

  • Разработка стандартных механизмов обеспечения безопасности.

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

Об авторе

Максим Советкин окончил механико-математический факультет Белорусского государственного университета, работает в Itransition уже более семи лет. Сегодня он — ведущий системный инженер, отвечает за проектирование, развитие и поддержку корпоративной ИТ-инфраструктуры.

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

Дата добавления: 2015-07-09 ; просмотров: 2274 ; Нарушение авторских прав

Сочетание средств проверки полномочий и проверки подлинности — мощное орудие борьбы за безопасность информационных систем и баз данных. Если все пользователи, работающие в интерактивном режиме или запускающие пакетные приложения, достаточно надежны и имеют доступ к максимально закрытой информации, хранимой в системе, то упомянутый подход к обеспечению безопасности может быть вполне достаточным. Например, если в системе хранится информация, классифицированная по уровням от полностью открытой до совершенно секретной (чуть ниже мы рассмотрим понятие уровней защиты данных), но все пользователи системы имеют доступ к самым секретным данным, то в такой системе достаточно иметь надежные механизмы проверки полномочий и проверки подлинности. Такая модель называется «работой на высшем уровне (секретности)» (running at system high).

Читать еще:  Обязанности службы безопасности банка

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

Многоуровневая защита баз данных строится обычно на основе модели Белл-ЛаПадула (Bell-LaPadula), которая предназначена для управления субъектами, т. е. активными процессами, запрашивающими доступ к информации, и объектами, т. е. файлами, представлениями, записями, полями или другими сущностями данной информационной модели.

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

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

Второй компонент может относиться, например, к набору категорий:

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

· недоступно для служащих по контракту.

В частной компании возможны такие уровни иерархии:

· для ограниченного распространения;

· для служебного пользования;

Второй компонент в такой компании мог бы принадлежать к набору категорий:

· недоступно для служащих по контракту;

· финансовая информация компании;

· информация об окладах.

Очевидно, что можно определить матрицу соотношений между иерархическими и неиерархическими компонентами. Например, если некоторый объект классифицирован как совершенно секретный, но ему не приписана ни одна из категорий неиерархического набора, то он может предоставляться иностранным правительствам, в то время как менее секретный объект может иметь категорию «недоступно для иностранных правительств» и, следовательно, не должен им предоставляться. Однако в модели Белл-ЛаПадула создается «решетка», где неирархические компоненты каждого уровня иерархии автоматически приписываются и всем более высоким уровням (так называемое «обратное наследование»). Эта модель отображена на рис. 21-3.

Рис. 21-3Решетка классов доступа в модели Белл-ЛаПадула

До сих пор наше обсуждение касалось вполне очевидных понятий. Из него следует, что субъект класса CL1 имеет доступ к объектам класса CL2, если CL2 не выше CL1. Например, пользователь класса «совершенно секретно», имеет доступ к информации классов «совершенно секретно», «секретно», «конфиденциально», «несекретно». В модели Белл-ЛаПадула этот принцип известен под названием простого свойства секретности (simple security property).

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

С учетом двух принятых в модели Белл-ЛаПадула ограничений (простое свойство секретности и *-свойство) можно представить себе базу данных с многоуровневой защитой так, как показано на рис. 21-4. Заметим, что субъект 1, пользователь или процесс, имеющий высший уровень благонадежности, может читать информацию всех кортежей, но в силу *-свойства он может записать данные только в кортеж наивысшей классификации (субъект может записывать информацию только «вверх по иерархии», но не «вниз по иерархии»). Субъект 2, принадлежащий к классу «секретно», не может прочитать «самую секретную» строку, но может прочитать две остальные. В то же время, субъекту 2 разрешена запись в строку класса «секретно» и в строку класса «совершенно секретно» (запись «вверх»).

Рис. 21-4Пример применения правил доступа Белл-ЛаПадула

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

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

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

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

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

Рис. 21-5Поэлементная классификация и возникающие в связи с этим проблемы

Механизмы защиты данных, реализованные в базе данных с универсальной моделью Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Грачев В.М., Есин В.И., Полухина Н.Г., Рассомахин С.Г.

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

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Грачев В.М., Есин В.И., Полухина Н.Г., Рассомахин С.Г.

Текст научной работы на тему «Механизмы защиты данных, реализованные в базе данных с универсальной моделью»

УДК 004.056: 004.652

МЕХАНИЗМЫ ЗАЩИТЫ ДАННЫХ, РЕАЛИЗОВАННЫЕ В БАЗЕ ДАННЫХ С УНИВЕРСАЛЬНОЙ МОДЕЛЬЮ

В. М. Грачев2, В. И. Есин1, Н. Г. Полухина3, С. Г. Рассомахин1

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

Ключевые слова: база ДАННЫХ. база данных с универсальной моделью данных? безопасность баз данныхj защита данных^ средства управления доступом.

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

Читать еще:  Законы обеспечивающие безопасные условия жизни

1 Харьковский национальный университет им. В. Н. Каразина, 61022, Харьков, пл. Свободы, 4.

2 Национальный исследовательский ядерный университет «МИФИ», 115409 Россия, Москва, Каширское шоссе, 31.

3 ФИАН, 119991 Россия, Москва, Ленинский пр-т, 53; e-mail: polukhina@sci.lebedev.ru.

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

Существующие подходы к решению проблемы. Рассмотрим методы и средства, обеспечивающие безопасность базы данных, построенной на основе универсальной модели данных (УМД) [2 4]. которую предполагается использовать в корпоративных И С для надежного, безопасного одновременного хранения больших объемов дшшых из разных существенно отличающихся предметных областей.

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

Безопасность базы данных (БД): проблемы, перспективы, решения

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

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

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

Взгляд в прошлое: история развития СУБД с эволюционной точки зрения

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

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

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

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

Проблемы безопасности БД

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

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

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

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

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

Каковы особенности защиты БД?

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

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

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

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

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

Уязвимости мы разделили (независящие и зависящие от данных). Теперь выделим независящие и зависящие от данных меры по обеспечения безопасности хранилищ.

Требования по безопасности к системе БД, не зависящей от данных: 1. Работа в доверенной среде. Доверенная среда — инфраструктура предприятия с её защитными механизмами, обусловленными политикой безопасности. 2. Обеспечение физической безопасности файлов данных. Здесь требования не отличаются от тех, которые применимы к любым другим файлам приложений и пользователей.

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

Аспекты создания защищённых БД

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

Читать еще:  Угрозы экономической безопасности в финансовой сфере

Материал подготовлен на основании статьи Максима Советкина «Безопасность баз данных: проблемы и перспективы».

Основные аспекты безопасности СУБД: что следует знать

    Статьи, 25 ноября 2016 в 19:35

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

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

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

История развития СУБД

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

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

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

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

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

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

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

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

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

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

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

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

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

Хранилища данных включает в себя два компонента: хранимые данные (собственно БД) и программы управления (СУБД).

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

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

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

Архитектура применяемых языков, по крайней мере, то, что касается специализированных языков и наборов функций, напрямую связана с моделью данных, применяемой для хранения информации. Таким образом, модель определяет особенности языка, и наличие в нем тех или иных уязвимостей. Причем такие уязвимости, например, как инъекция, выполняются по-разному (sql-инъекция, java-инъек­ция) в зависимости от синтаксиса языка.

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

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

Не зависящими от данных мож­но назвать следующие требования к безопасной системе БД:

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

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

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

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

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

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

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

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

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

  • Безопасная организация и работа с данными.

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

Основные аспекты создания защищенных БД

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

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

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

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

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

  • Разработка стандартных механизмов обеспечения безопасности.

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

Об авторе

Максим Советкин окончил механико-математический факультет Белорусского государственного университета, работает в Itransition уже более семи лет. Сегодня он — ведущий системный инженер, отвечает за проектирование, развитие и поддержку корпоративной ИТ-инфраструктуры.

Ссылка на основную публикацию
Adblock
detector