Green-sell.info

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

Безопасность баз данных это

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать еще:  Система программирования состоит из

Об авторе

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

VII Международная студенческая научная конференция Студенческий научный форум — 2015

ЗАЩИТА И БЕЗОПАСНОСТЬ БАЗ ДАННЫХ

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

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

К основным средствам защиты информации относят следующие:

защита полей и записей таблиц БД.

установление прав доступа к объектам БД;

шифрование данных и программ;

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

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

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

обеспечения целостности связей таблиц;

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

По мнению экспертов компании Application Security, существует 10 основных угроз БД, которые наиболее часто игнорируются ИТ-персоналом:

Используемые по умолчанию, пустые или слабые пароли и логины;

Расширенные пользовательские и групповые права;

Активизация неиспользуемых функций БД;

Нарушение в управлении конфигурациями;

Несвоевременное обновление ПО;

Отказ от шифрования данных на стационарных и мобильных устройствах.

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

McAfee Database Security;

Secret Disk Server NG;

Крипто БД: защита баз данных (Oracle);

DataSecure и другие.

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

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

Список использованных источников

Студенческий научный форум — 2015
VII Международная студенческая научная конференция

В рамках реализации «Государственной молодежной политики Российской Федерации на период до 2025 года» и направления «Вовлечение молодежи в инновационную деятельность и научно-техническое творчество» коллективами преподавателей различных вузов России в 2009 году было предложено совместное проведение электронной научной конференции «Международный студенческий научный форум».

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

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

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

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

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

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

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

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

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

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

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

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

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

Читать еще:  В интегрированную систему программирования входят

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Записки ИТ-многостоночника

Архитектурный и технический консалтинг во внедрении и разработке ПО. Системный бизнес анализ и дизайн

Информационная безопасность баз данных

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

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

Даже последние нормативные документы от российских законотворцев в области ИБ показывают, что коллеги в Министерствах и Федеральных агентствах и службах постепенно отошли от ГБ-шной модели «все зашифровать, поставить гриф, трехметровый забор и расстреливать каждого, кто не назовет пароль» и стали под объектами защиты больше понимать не средства обработки информации, но саму информацию (в виде данных) и технологии ее обработки. Например, в требованиях к защите информации в Государственных информационных системах (утвержденных приказом ФСТЭК России №17) появился такой раздел, как защита потоков информации.

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

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

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

Частично эти свойства обеспечивается такими традиционно не ИБ-шными средствами «защиты» как например резервной копирование и восстановление после сбоев (о чем я писал, например, здесь, а здесь описывал требования, предъявляемые к этим процессам для автоматизированных банковских систем Банком России). Здесь подробно останавливаться на этом не буду, отмечу только, что традиционно требования к этому, а также соответствующие решения являются «вотчинной» специалистов по инфраструктуре.

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

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

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

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

Основными угрозами/уязвимостями для данных, обрабатываемых в БД, являются:

  • Завышенные или неиспользуемые привилегии. Как правило, являются следствием лени или нежелания сформировать ролевую матрицу для пользователей в соответствии с широко известным принципом минимального знания. Может привести к тому, что в системе появляются учетные записи, доступ к данным которых неоправданно широкий, при этом защите этих учетных записей не уделяется достаточное внимание. В случае применение второго метода аутентификации и контроля доступа эта угроза будет относится не только к данным, обрабатываемым в базе, но на этом уровне она наиболее опасна.
  • Злоупотребление полномочиями. Является следствием предыдущей угрозы/уязвимости, а также следствием особенности большинства промышленных ИТ-систем — наличия суперпользователя. Данный неконтролируемый пользователь должен быть максимально ограничен, а полномочия его и ему подобных пользователей должны анализироваться и отслеживаться. Например, в большинстве рекомендаций по политикам безопасности для Microsoft говорится, что следует внимательнее относиться к пользователям группы «Продвинутые пользователи», так как это не пользователи с расширенными правами, а скорее администраторы с урезанными.
  • SQL-инъекции. Самая «популярная» угроза для RDBMS. Описывать ее не имеет смысла, гугл в помощь.
  • Вредоносное ПО, которое поможет злоумышленнику получить доступа непосредственно к СУБД. Основная «фишка» данной угрозы заключается в том, что системы, особенно построенные по n-Tier-принципам, как правило, не предусматривают прямого доступа кого-либо извне к СУБД как к СУБД, т.е. не через уровни (Tier), реализующие соответствующие архитектурные слои, лежащие над слоем данных. Даже при построения простейших систем на базе одной только СУБД (например, Oracle DB) рекомендуется использовать простейший слой сервисов и хотя бы презентационной логики (например, Oracle APEX). Однако, соответствующее вредоносное ПО может обеспечить доступ к СУБД как к ПО в составе ПО и КТС системы и, соответственно, неконтролируемый прикладной логикой доступ к данным. Это особенно опасно при реализации аутентификации и разграничения доступа первым методом.
  • Выводимые из эксплуатации носители данных. Есть старая ГБ-шная шутка, что самым лучшим источником информации для шпиона является мусорная корзина. По аналогии, выводимые из эксплуатации носители данных, которые раньше использовались БД, могут содержать защищаемую информацию с незначительными преобразованиями и потерей актуальности.
  • DoS и DDoS-атаки. Про этот тип угроз также можно найти любую информацию в открытом доступа.
  • Недостаток информации аудита («слабые» политики аудита). Регистрация событий безопасности (а в базе данных большинство событий можно отнести к таковым) является головной болью администраторов, так как логи занимают много места, как правило, негативно сказываются на производительности, и вообще «кто там будет что-то копать?». При проектировании системы следует избегать таких мыслей. При этом стоит стараться учитывать наличие привилегированных пользователей, которые могут отключать аудит определенных событий. В идеале система должна быть настроена таким образом, чтобы не позволять неконтролируемо совершать каких-либо действий любому пользователю.

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

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

Безопасность баз данных.

в Базы данных 12.01.2018 0 357 Просмотров

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

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

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

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

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

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

Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector
×
×