Bazaprogram.ru

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

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

Защита информации в базах данных

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

Эти два подхода отличаются следующими свойствами:

  • В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью.
  • В случае неизбирательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. При таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска.
  • Для реализации избирательного принципа предусмотрены следующие методы. В базу данных вводится новый тип объектов БД — это пользователи. Каждому пользователю в БД присваивается уникальный идентификатор. Для дополнительной защиты каждый пользователь кроме уникального идентификатора снабжается уникальным паролем, причем если идентификаторы пользователей в системе доступны системному администратору, то пароли пользователей хранятся чаще всего в специальном кодированном виде и известны только самим пользователям.
  • Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы PUBLIC , для которой должен быть определен минимальный стандартный набор прав. По умолчанию предполагается, что каждый вновь создаваемый пользователь, если специально не указано иное, относится к группе PUBLIC .
  • Привилегии или полномочия пользователей или групп — это набор действий (операций), которые они могут выполнять над объектами БД.
  • В последних версиях ряда коммерческих СУБД появилось понятие «роли». Роль — это поименованный набор полномочий. Существует ряд стандартных ролей, которые определены в момент установки сервера баз данных. И имеется возможность создавать новые роли, группируя в них произвольные полномочия. Введение ролей позволяет упростить управление привилегиями пользователей, структурировать этот процесс. Кроме того, введение ролей не связано с конкретными пользователями, поэтому роли могут быть определены и сконфигурированы до того, как определены пользователи системы.
  • Пользователю может быть назначена одна или несколько ролей.
  • Объектами БД, которые подлежат защите, являются все объекты, хранимые в БД: таблицы, представления, хранимые процедуры и триггеры. Для каждого типа объектов есть свои действия, поэтому для каждого типа объектов могут быть определены разные права доступа.

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

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

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

СУБД в своих системных каталогах хранит как описание самих пользователей, так и описание их привилегий по отношению ко всем объектам.

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

В ряде СУБД вводится следующий уровень иерархии пользователей — это администратор БД . В этих СУБД один сервер может управлять множеством СУБД (например, MS SQL Server , Sybase).

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

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

В стандарте SQL определены два оператора: GRANT и REVOKE соответственно предоставления и отмены привилегий .

Оператор предоставления привилегий имеет следующий формат:

Здесь список действий определяет набор действий из общедопустимого перечня действий над объектом данного типа.

Параметр ALL PRIVILEGES указывает, что разрешены все действия из допустимых для объектов данного типа.

Читать еще:  Топ 5 лучших антивирусов

— задает имя конкретного объекта: таблицы, представления, хранимой процедуры, триггера.

или PUBLIC определяет, кому предоставляются данные привилегии.

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

Рассмотрим пример, пусть у нас существуют три пользователя с абсолютно уникальными именами user1, user2 и user3 . Все они являются пользователями одной БД .

User1 создал объект Tab1 , он является владельцем этого объекта и может передать права на работу с эти объектом другим пользователям. Допустим, что пользователь user2 является оператором, который должен вводить данные в Tab1 (например, таблицу новых заказов), а пользователь user 3 является большим начальником (например, менеджером отдела), который должен регулярно просматривать введенные данные.

Для объекта типа таблица полным допустимым перечнем действий является набор из четырех операций: SELECT, INSERT, DELETE, UPDATE . При этом операция обновление может быть ограничена несколькими столбцами.

Общий формат оператора назначения привилегий для объекта типа таблица будет иметь следующий синтаксис :

Тогда резонно будет выполнить следующие назначения:

Эти назначения означают, что пользователь user2 имеет право только вводить новые строки в отношение Tab1 , а пользователь user3 имеет право просматривать все строки в таблице Tab1 .

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

Если наш пользователь user1 предполагает, что пользователь user4 может его замещать в случае его отсутствия, то он может предоставить этому пользователю все права по работе с созданной таблицей Tab1 .

В этом случае пользователь user4 может сам назначать привилегии по работе с таблицей Tab1 в отсутствие владельца объекта пользователя user1 . Поэтому в случае появления нового оператора пользователя user5 он может назначить ему права на ввод новых строк в таблицу командой

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

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

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

Так как представления могут соответствовать итоговым запросам, то для этих представлений недопустимы операции изменения, и, следовательно, для таких представлений набор допустимых действий ограничивается операцией SELECT . Если же представления соответствуют выборке из базовой таблицы, то для такого представления допустимыми будут все 4 операции : SELECT , INSERT , UPDATE и DELETE .

Для отмены ранее назначенных привилегий в стандарте SQL определен оператор REVOKE . Оператор отмены привилегий имеет следующий синтаксис :

Параметры CASCADE или RESTRICT определяют, каким образом должна производиться отмена привилегий . Параметр CASCADE отменяет привилегии не только пользователя, который непосредственно упоминался в операторе GRANT при предоставлении ему привилегий, но и всем пользователям, которым этот пользователь присвоил привилегии, воспользовавшись параметром WITH GRANT OPTION .

Например, при использовании операции :

будут отменены привилегии и пользователя user5 , которому пользователь user4 успел присвоить привилегии.

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

не будет выполнена, потому что пользователь user4 передал часть cвоих полномочий пользователю user5 .

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

Поэтому корректным будет следующее использование оператора REVOKE :

При работе с другими объектами изменяется список операций , которые используются в операторах GRANT и REVOKE .

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

Если вы хотите изменить это условие, то после создания хранимой процедуры необходимо записать оператор REVOKE .

И теперь мы можем назначить новые права пользователю user4 .

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

Читать еще:  Защита от несанкционированного доступа

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

В некоторых СУБД пользователь может получить права создавать БД . Например, в MS SQL Server системный администратор может предоставить пользователю main_user право на создание своей БД на данном сервере. Это может быть сделано следующей командой:

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

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

Для того чтобы разрешить пользователю создавать объекты внутри этой БД , используется понятие системной привилегии, которая может быть назначена одному или нескольким пользователям. Они выдаются только на действия и конкретный тип объекта . Поэтому если вы, как системный администратор , предоставили пользователю право создания таблиц ( CREATE TABLE ), то для того чтобы он мог создать триггер для таблицы, ему необходимо предоставить еще одну системную привилегию CREATE TRIGGER . Система защиты в Oracle считается одной из самых мощных, но это имеет и обратную сторону — она весьма сложная. Поэтому задача администрирования в Oracle требует хорошего знания как семантики принципов поддержки прав доступа, так и физической реализации этих возможностей.

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

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

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

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

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

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

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

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

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

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

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

Читать еще:  Xlsx снять защиту листа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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