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

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

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

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

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

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

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

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

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

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

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

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

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

GRANT {<список действий> | ALL PRIVILEGES } ON <имя_объекта> TO {<имя_пользователя> | PUBLIC }

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

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

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

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

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

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

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

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

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

GRANT {[,INSERT][,DELETE][,UPDATE (<список столбцов>)]} ON <имя_таблицы> TO {<имя_пользователя> | PUBLIC }

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

GRANT INSERT ON Tab1 TO user2 GRANT SELECT ON Tab1 TO user3

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

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

GRANT SELECT, UPDATE (COST) ON Tab1 TO user3

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

GRANT ALL PRIVILEGES ON Tab1 TO user4 WITH GRANT OPTION

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

GRANT INSERT ON Tab1 TO user5

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

GRANT SELECT, UPDATE, DELETE ON Tab1 TO user4 WITH GRANT OPTION,

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

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

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

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

REVOKE {<список операций> | ALL PRIVILEGES} ON <имя_объекта> FROM {<список пользователей> | PUBLIC } {CASCADE | RESTRICT }

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

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

REVOKE ALL PRIVILEGES ON Tab1 FROM user4 CASCADE

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

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

REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Об авторе

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

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

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

В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью.

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

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

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

Привилегии или полномочия пользователей или групп -- это набор действий (операций), которые они могут выполнять над объектами БД.

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

Пользователю может быть назначена одна или несколько ролей.

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

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

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

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

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

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

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

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

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

GRANT {<список действий | ALL PRIVILEGES }

ON <имя_объекта> ТО (<имя_пользователя> ] PUBLIC }

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

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

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

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

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

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

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

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

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

GRANT {[.INSERT][,DELETED[.UPDATE (<список столбцов>)]} ON <имя таблицы>

ТО {<имя_пользователя> PUBLIC }

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

ТО user2 GRANT SELECT

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

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

GRANT SELECT. UPDATE (COST) ON Tab1 TO user3

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

GRANT ALL PRIVILEGES

TO user4 WITH GRANT OPTION

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

ON Tab1 TO user5

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

GRANT SELECT. UPDATE. DELETE

TO user4 WITH GRANT OPTION,

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

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

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

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

REVOKE {<список операций | ALL PRIVILEGES} ON <имя_объекта>

FROM {<список пользователей | PUBLIC } {CASCADE | RESTRICT }

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

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

REVOKE ALL PRIVILEGES - ON Tab1 TO user4 CASCADE

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

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

REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT

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

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

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

REVOKE INSERT ON Tab! TO user2.user4 CASCADE

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

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

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

REVOKE EXECUTE ON COUNT_EX TO PUBLIC CASCADE И теперь мы можем назначить новые права пользователю user4.

GRANT EXECUTE ON COUNT_EX TO user4

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

GRANT CREATE TABLE. ALTER TABLE, DROP TABLE ON OB_LIB TO user1

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

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

GRANT CREATE DATABASE

ON SERVERJ) TO main user

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

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

Защита на уровне СУБД

Сервер баз данных управляет секретностью базы данных, используя различные средства:

─ управление пользователями базы данных;

─ управление привилегиями и ролями;

─ аудит базы данных;

─ шифрование хранимых программных единиц.

Распознавание пользователя предполагает:

─ идентификацию пользователя – пользователь указывает свой идентификатор (не секретный – логин);

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

После распознавания пользователя система производит следующие действия:

─ выделяет соответствующие пользователю ресурсы (трафик, расписание доступа, выделение памяти и т.д.);

─ устанавливает права доступа пользователя.

─ выполняет мониторинг (оперативное наблюдение) и аудит (подведение итогов, определение статистики) за пользователем;

Основное средство защиты – контроль доступа – использует два основных подхода:

─ обязательный;

─ избирательный.

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

Привилегия – право на выполнение некоторой операции. Разделяются на системные и объектные привилегии.

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

Объектные привилегии – разрешают выполнять действия над заданным объектом базы данных (таблицей, представлением и т.д.). Стандартизированы в SQL системах.

Основные объектные привилегии для внешних пользователей:

ALTER – разрешает изменение определения заданных таблиц, представлений

DELETE – разрешает удаление строк из заданных таблиц, представлений

EXECUTE – разрешает выполнение заданных хранимых процедур, функций, пакетов

INSERT – разрешает вставка строк в заданные таблицы, представления

SELECT – разрешает чтение данных из заданных таблиц, представлений

UPDATE – разрешает изменение данных в заданных таблицах, представлениях

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

Для задания привилегий заполняется матрица доступа:

Привелегии (права) задаются с помощью команды:

GRANT <привилегия[, привилегия …] | ALL> ON <Объект> TO <Субъект>

("ALL" предоставляет все привилегии на объект)

Например, чтобы позволить пользователю Ivanov выполнять запросы к таблице Sotrudnik, нужно ввести команду

GRANT SELECT ON Sotrudnik TO Ivanov;

Привилегии, объекты и субъекты можно задавать списком.

Привилегии может назначать администратор, владелец объекта или уполномоченное (доверенное) лицо – тот, кому поручили перераспределение привилегий.

Доверенное лицо получает разрешение на выдачу привилегий добавлением GRANT опции:

GRANT <привилегия> ON <Объект> TO <Субъект> WITH GRANT OPTION

При этом конструкция "WITH ADMIN OPTION" разрешает предоставлять полученную привилегию другим пользователям

Напрмер, команда

“GRANT SELECT ON Sotrudnik TO Ivanov WITH GRANT OPTION”

предоставляет возможность пользователю Ivanov пере­давать право назначать привилегии работы с таблицей Sotrudnik другим пользователям.

Для отмены привилегии используется оператор

“REVOKE <привилегия> ON <объект> FROM <субъект>”.

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

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

Каждый пользователь в среде SQL имеет специальное идентифи­кационное имя (или номер).

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

─ SELECT - разрешение выполнять запросы в таблице.

─ INSERT - разрешение выполнять оператор INSERT (вставка но­вой строки) в таблице.

─ UPDATE - разрешение выполнять оператор UPDATE (обновле­ние значений полей) в таблице. Можно ограничить эту привилегию для определенных столбцов таблицы.

─ DELETE - разрешение выполнять оператор DELETE (удаление записей) в таблице.

─ REFERENCES - разрешение определить внешний ключ.

Недостатки избирательного подхода:

─ сложность назначения привилегий;

─ ошибки нарушения конфиденциальности из-за путаницы.

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

В первых системах создавались группы пользователей. При этом объявляются группы, пользователи причисляются к группам. Привилегии назначаются как отдельным пользователям, так и отдельным группам. Обычно существуют предопределенные группы (например, PUBLIC – в нее автоматически зачисляются все пользователи; этой группе определяют минимальные права).

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

Разница данных вариантов группирования в том, что назначение в группы является статическим. Создание ролей позволяет сделать динамически управление.

Но пока наши законодатели спорят о проектах законов о коммерческой тайне и электронной торговле, в общественных местах - в переходах метро и даже на автостоянках, не говоря уж об Интернете, продолжают продаваться компакт-диски с разнообразными базами данных (БД). Выбор необычайно широк: за 40-60 долл. вам предложат БД МГТС (актуализация - январь 2003 г.), Единой государственной регистрации предприятий (полная информация о предприятиях, зарегистрированных в России в 2003 г.), сведения о прописке в Москве и Московской области, а подороже, за 110 долл., можно купить БД ВЭД и т. д. Слегка "залежалый товар", например, немного устаревшие данные об абонентах МТС (по состоянию на ноябрь 2002 г.), идет всего за 40 "у. е".

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

Суть метода состоит в применении штатных механизмов инфраструктуры открытых ключей и организации доступа пользователей к информации по предъявлению цифровых сертификатов Х.509, поддерживаемых средствами Oracle Advanced Security, в двух уровнях: для аутентификации в корпоративной сети (например, под управлением Microsoft Windows Server 2000/2003) и для доступа к конфиденциальным данным, которые обрабатываются и хранятся на серверах Oracle. Оба сертификата хранятся в персональном идентификаторе в виде USB-ключа или смарт-карты eToken.

Этот метод позволяет значительно снизить риски от потерь, связанных с человеческим фактором, и однозначно персонифицировать действия пользователей информационной системы, работающих с СУБД Oracle 9i.

Основные вопросы

Почему кражи информации случаются в самых разных организациях, даже в силовых ведомствах? Каковы предпосылки утечки данных, и надо ли обладать обширными знаниями и умением взломщика, чтобы преодолеть существующую защиту? Существуют ли способы построения систем защиты информации (СЗИ), позволяющие свести к минимуму риски потери данных? Можно ли защитить корпоративные данные от собственного системного администратора?

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

Уровни защиты доступа к данным

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

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

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

Почему воруют информацию

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

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

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

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

Внешние угрозы неправомерного доступа к корпоративным данным также подразделяются на два подкласса, из которых на долю внешних хакеров приходится до 20%, а на долю легальных пользователей корпоративной сети - до 100%.

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

Самое неприятное, что такой подход зачастую применяется и в далеко не мелких организациях. А доступ к ресурсам системы нескольких разных пользователей под одной и той же учетной записью - весьма распространенная и прочно укоренившаяся практика. Например, если в организации работают пять системных администраторов, то все они могут иметь доступ по одному паролю. Хорошо иллюстрирует порочность такой организации доступа аналогия с ездой по улицам крупного города на автомобилях без номеров. Никакой сотрудник ГАИ не сможет четко идентифицировать автомобиль, превышающий дозволенную скорость, в потоке "анонимов", если все едут без номерных знаков.

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

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

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

Встроенные средства защиты

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

Virtual Private Database (VPD) - средства разграничения доступа к данным на уровне строк (в версии 10g - и на уровне колонок) и возможность организации работы пользователя только с виртуальной регламентированной частью данных, а не с реальной базой данных;

Oracle Advanced Security - комплекс средств аутентификации и обеспечения сетевой безопасности, включающий в себя поддержку защищенных протоколов передачи данных, в том числе SSL;

Oracle Label Security (OLS) - средства, аналогичные VPD, но с возможностью проверки уровня доступа пользователя;

Fine Grained Audit Control (FGAC) - инструмент подробного аудита.

Штатные средства Oracle + еToken

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

Прежде всего метод аутентификации пользователей по имени и паролю был заменен более надежной - двухфакторной аутентификацией с использованием цифровых сертификатов стандарта X.509. И хотя встроенные средства Oracle Advanced Security поддерживают аутентификацию по цифровым сертификатам, вопрос о хранении сертификатов и личных ключей остается открытым. Предлагаемые Oracle способы хранения сертификатов в виде файлов-контейнеров формата PKCS#12 или реестра ОС Windows имеют ряд существенных недостатков. Суть встроенных в Advanced Security возможностей иллюстрирует схема хранения сертификатов (рис. 1).

Рис. 1. Схема хранения цифровых сертификатов Oracle в архитектуре Oracle Advanced Security с использованием eToken.

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

Очевидно, что, помимо повышения надежности, аутентификация с использованием eToken дает ряд преимуществ по сравнению с традиционным (логин/пароль) методом. Прежде всего электронный ключ дает возможность пользователю различных приложений не хранить "где попало" и не запоминать необходимые имена и пароли. Зная один PIN-код и выбрав сертификат из предложенного списка, можно, имея соответствующие права и привилегии, обращаться к конкретной БД, причем c любой рабочей станции.

Администратор безопасности получает при этом дополнительные удобства в виде централизованного управления доступом и контроля работы системных администраторов. Все эти возможности управления обеспечивает единый инструмент - служба каталогов Oracle Internet Directory. Существующие приложения получают "в лице" службы каталогов единую точку входа - своего рода портал архитектуры клиент-сервер. При этом в большинстве случаев изменений в прикладном ПО не требуется.

Архитектурные особенности

Предложенное решение базируется на использовании цифровых сертификатов стандарта X.509 и протокола Secure Sockets Layer (SSL), поддерживающего строгую двухфакторную аутентификацию пользователей СУБД Oracle, а также шифрование информации, передаваемой по сети между сервером БД и клиентской рабочей станцией (рис. 2). При этом задействованы лишь штатные настройки СУБД и клиента Oracle, описанные в документации по Oracle Advanced Security . Установка на рабочей станции сервисов eToken дает возможность применять имеющиеся на ключе сертификаты для аутентификации в СУБД Oracle (cм. врезку "Процедура аутентификации в СУБД Oracle с использованием eToken").

Рис. 2. Архитектура предоставления доступа.

Сертификаты и связанные с ними закрытые ключи хранятся в защищенной памяти eToken (она доступна только встроенному в него криптопроцессору). Чтобы выполнить криптографические операции с закрытым ключом, пользователь должен ввести PIN-код. Такой подход позволяет на практике реализовать модель организации защищенного доступа пользователя к данным (СУБД) с использованием цифровых сертификатов Х.509, установленных в eToken, в двух уровнях. Легальные пользователи корпоративной сети (например, под управлением контроллера домена Windows 2000/2003) могут авторизоваться в сети (рис. 3) только после успешного завершения процесса аутентификации по смарт-карте, включающего предъявление соответствующего сертификата (первый уровень). На втором уровне защиты доступ авторизованных пользователей корпоративной сети к защищенным данным СУБД возможен только при предъявлении соответствующего сертификата Oracle.

Рис. 3. Двухуровневая модель доступа к защищенным данным с помощью цифровых сертификатов Х.509.

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

1 - Обычно промышленные СУБД класса DB2 и Oracle сертифицированы как минимум по классу защищенности С2.

2 - По данным ряда источников, в том числе IDC. - Прим. ред.