Защита информации в субд. Обеспечение защиты персональных данных в субд oracle. Аутентификация в многоуровневых приложениях

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

Неразрывный пробел: горячие клавиши и их назначение

Как говорилось выше, чтобы избавить себя от проблемы, когда при печати текста в "Ворде" вводятся длинные пробелы, нужно пользоваться специальным пробелом. О том, как в "Ворде" сделать мы сейчас и поговорим.

Чтобы не ходить вокруг да около, стоит сразу же сказать, что для ввода такого пробела существует специальная комбинация клавиш - CTRL+SHIFT+ПРОБЕЛ. Можете самостоятельно попробовать ее нажать. Конечно, если проблемы с длинными пробелами у вас не было, то разницу (между обычным и неразрывным пробелами) вы не заметите. Однако можете пользоваться таким способом повсеместно, чтобы уберечь себя от неправильного форматирования документа.

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

Вам нужно попасть в меню "Специальные знаки". Чтобы это сделать, перейдите во вкладку "Вставить", выберите "Символы" и нажмите "Другие". Теперь в окне перейдите в нужную нам вкладку - "Специальные знаки". Теперь в списке отыщите строку "Неразрывный пробел". Нажмите два раза на поле и введите удобную вам комбинацию.

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

Установка автозамены

Если вы все равно испытываете дискомфорт при нажатии сочетания заданных клавиш, то есть еще один способ того, как в "Ворде" сделать неразрывный пробел. Он заключается в назначении автозамены. Это очень полезная опция не только для печати неразрывного пробела.

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

Теперь перед вами окно автозамены. Вам нужно в поле "Заменить" вписать те символы, которые будут заменяться на неразрывный пробел, а в поле "На" вставить тот самый пробел. Обязательно не забудьте поставить отметку "Обычный текст". После этого нажмите кнопку "Добавить".

Вот вы и узнали, как сделать неразрывный пробел в "Ворде", каким способом пользоваться, решать только вам. Теперь поговорим о специальном пробеле.

Специальный пробел

Принцип того, как в "Ворде" сделать неразрывный пробел, очень похож на создание специального символа. По крайней мере суть практически одна и та же. Используйте специальный символ в том случае, если вы хотите задать определенное расстояние между буквами или словами. Этот символ, кстати, называется Narrow non-break space.

Итак, чтобы установить данный символ, вам нужно открыть таблицу всех символов. Теперь в выпадающем списке "Шрифт" выберите "Обычный текст", а в списке "Набор" - "Знаки пунктуации". Теперь среди всего множества различных символов найдите необходимый - Narrow non-break space. Если что, то его название отображается над кнопкой "Автозамена".

Отыскав символ, нажмите кнопку "Вставить", после этого символ вставится в указанное вами место. Если вы задаетесь вопросом о том, для чего эта функция может пригодиться, то она отлично подходит для вписывания дат. Таким образом, цифры "2017" будут написаны рядом со словом "Год", и отодвинуть их никак не получится.

Просмотр непечатаемых символов

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

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

Кстати, в статье приводились примеры для версии "Ворда" 2007 года, однако если вы задаетесь вопросом о том, как сделать неразрывный пробел в "Ворде" 2010 года, то эта инструкция вам также должна подойти.

Средства защиты БД в различных СУБД несколько отличаются друг от друга. На основе анализа современных СУБД Borland и Microsoft можно утверждать, что средства защиты БД условно делятся на две группы, основные и дополнительные.

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

Парольная защита;

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

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

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

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

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

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

По отношению к таблицам в общем случае могут предусматриваться следующие права доступа.

Просмотр (чтение) данных;

Изменение (редактирование) данных;

Добавление новых записей;

Добавление и удаление данных;

Все операции, в том числе изменение структуры таблицы.

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

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

Полный запрет доступа;

Только чтение;

Разрешение всех операций (просмотр, ввод новых значений, удаление и изменение).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью.
• В случае неизбирательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. При таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска.
• Для реализации избирательного принципа предусмотрены следующие методы. В базу данных вводится новый тип объектов БД - это пользователи. Каждому пользователю в БД присваивается уникальный идентификатор. Для дополнительной защиты каждый пользователь кроме уникального идентификатора снабжается уникальным паролем, причем если идентификаторы пользователей в системе доступны системному администратору, то пароли пользователей хранятся чаще всего в специальном кодированном виде и известны только самим пользователям.
• Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы 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 .

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

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

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

Некоторые термины

онфиденциальная информация (sensitive information) - информация, которая требует защиты.

Доступ к информации (access to information) - ознакомление с информацией, ее обработка (в частности, копирование), модификация, уничтожение.

Субъект доступа (access subject) - лицо или процесс, действия которого регламентируются правилами разграничения доступа.

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

Правила разграничения доступа (security policy) - совокупность правил, регламентирующих права субъектов доступа к объектам доступа.

Санкционированный доступ (authorized access to information) - доступ к информации, который не нарушает правил разграничения доступа.

Несанкционированный доступ (unauthorized access to information) - доступ к информации, который нарушает правила разграничения доступа с использованием штатных средств, предоставляемых средствами вычислительной техники или автоматизированными системами.

Идентификатор доступа (access identifier) - уникальный признак объекта или субъекта доступа.

Идентификация (identification) - присвоение объектам и субъектам доступа идентификатора и (или) сравнение предъявляемого идентификатора с перечнем присвоенных идентификаторов.

Пароль (password) - идентификатор субъекта, который является его секретом.

Аутентификация (authentification) - проверка принадлежности субъекту доступа предъявленного им идентификатора, подтверждение подлинности.

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

Уровень полномочий субъекта доступа (subject privilege) - совокупность прав доступа субъекта доступа (для краткости в дальнейшем мы будем использовать термин «привилегия»).

Нарушитель правил разграничения доступа (security policy violator) - субъект доступа, который осуществляет несанкционированный доступ к информации.

Модель нарушителя правил разграничения доступа (security policy violator model) - абстрактное (формализованное или неформализованное) описание нарушителя правил разграничения доступа.

Целостность информации (information integrity) - способность средства вычислительной техники (в рассматриваемом случае - информационной системы в целом) обеспечить неизменность информации в условиях случайного и (или) преднамеренного искажения (разрушения).

Метка конфиденциальности (sensitivity label) - элемент информации, характеризующий конфиденциальность объекта.

Многоуровневая защита (multilevel secure) - защита, обеспечивающая разграничение доступа субъектов с различными правами доступа к объектам различных уровней конфиденциальности.

Пользователи СУБД

ользователей СУБД можно разделить на три группы:

1. Прикладные программисты - отвечают за создание программ, использующих базу данных.

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

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

Дискреционная защита

Современных СУБД достаточно развиты средства дискреционной защиты.

Дискреционное управление доступам (discretionary access control) - разграничение доступа между поименованными субъектами и поименованными объектами. Субъект с определенным правом доступа может передать это право любому другому субъекту.

Дискреционная защита является многоуровневой логической защитой.

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

Информация о зарегистрированных пользователях базы данных хранится в ее системном каталоге. Современные СУБД не имеют общего синтаксиса SQL-предложения соединения с базой данных, так как их собственный синтаксис сложился раньше, чем стандарт ISO. Тем не менее часто таким ключевым предложением является CONNECT. Ниже приведен синтаксис данного предложения для Oracle и IBM DB2 соответственно:

CONNECT [ ] пользователь/пароль[@база_данных] CONNECT TO база_данных USER пользователь USING пароль

В данных предложениях отражен необходимый набор атрибутов, а также показано различие синтаксиса. Формат атрибута база_данных, как правило, определяется производителем СУБД, так же как и имя пользователя, имеющего по умолчанию системные привилегии (SYSDBA/SYSOPER в случае Oracle).

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

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

Все субъекты контроля системы хранятся в таблице полномочий системы и разделены для системы на ряд категорий, например CONNECT, RESOURCE и DBA. Набор таких категорий определяется производителем СУБД. Мы не случайно предлагаем указанный порядок рассмотрения - именно так происходит нарастание возможностей (полномочий) для каждого отдельного вида подключения:

• CONNECT - конечные пользователи. По умолчанию им разрешено только соединение с базой данных и выполнение запросов к данным, все их действия регламентированы выданными им привилегиями;
• RESOURCE - привилегированные пользователи, обладающие правом создания собственных объектов в базе данных (таблиц, представлений, синонимов, хранимых процедур). Пользователь - владелец объекта обладает полным набором привилегий для управления данным объектом;
• DBA - категория администраторов базы данных. Включает возможности обеих предыдущих категорий, а также возможность вводить (удалять) в систему (из системы) субъекты защиты или изменять их категорию.

Следует особо отметить, что в некоторых реализациях административные действия также разделены, что обусловливает наличие дополнительных категорий. Так, в Oracle пользователь с именем DBA является администратором сервера баз данных, а не одной-единственной базы данных. В СУБД «Линтер» компании РЕЛЭКС понятие администратора сервера баз данных отсутствует, а наличествует только понятие администратора конкретной базы данных. В IBM DB2 существует ряд категорий администраторов: SYSADM (наивысший уровень; системный администратор, обладающий всеми привилегиями); DBADM (администратор базы данных, обладающий всем набором привилегий в рамках конкретной базы данных). Привилегии управления сервером баз данных имеются у пользователей с именами SYSCTRL (наивысший уровень полномочий управления системой, который применяется только к операциям, влияющим на системные ресурсы; непосредственный доступ к данным запрещен, разрешены операции создания, модификации, удаления базы данных, перевод базы данных или экземпляра (instance) в пассивное состояние (quiesce), создание и удаление табличных пространств), SYSMAINT (второй уровень полномочий управления системой, включающий все операции поддержки работоспособности экземпляра (instance); непосредственный доступ к данным этому пользователю запрещен, разрешены операции изменения конфигурационных файлов базы данных, резервное копирование базы данных и табличных пространств, зеркалирование базы данных). Для каждой административной операции в IBM DB2 определен необходимый набор административных категорий, к которым должен принадлежать пользователь, выполняющий тот или иной запрос администрирования. Так, выполнять операции назначения привилегий пользователям может SYSADM или DBADM, а для того чтобы создать объект данных, пользователь должен обладать привилегией CREATETAB.

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

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

CREATE USER IDENTIFIED пользователь BY пароль

Подсистема безопасности IBM DB2 может использовать идентификаторы пользователей операционной системы; ее синтаксис SQL не содержит предложения, аналогичного предложению CREATE USER. Microsoft SQL Server может использовать аутентификацию как базы данных, так и операционной системы. Но мы не станем здесь обсуждать достоинства и недостатки выбранных производителями способов аутентификации - все они позволяют строить корректные схемы определения подлинности пользователей. Использование дополнительных средств аутентификации в рамках информационной системы не запрещается.

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

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

При использовании хранимых процедур следует обращать особое внимание на то, от имени какого пользователя выполняется данная хранимая процедура в каждом конкретном случае. Так, в Oracle до недавнего времени хранимые процедуры выполнялись от имени владельца хранимой процедуры, а не от имени пользователя, выполнившего ее вызов. Текущая версия Oracle предоставляет возможность указать, под чьим именем будет выполняться вызванная хранимая процедура, пользователь же должен иметь только привилегию EXECUTE для данной процедуры. В «Линтер», например, выполнение хранимых процедур всегда происходит от имени пользователя, вызвавшего процедуру.

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

Предложения управления привилегиями:

• назначение привилегии: GRANT привилегия TO субъект
• отмена привилегии: REVOKE привилегия FROM субъект

Если субъект=пользователь, то привилегия назначается ему явно. Если субъект=роль, то для управления привилегиями используются соответственно:

GRANT ROLE имя_роли TO субъект REVOKE ROLE имя_роли FROM субъект

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

GRANT привилегия TO PUBLIC

В этом случае каждый новый созданный пользователь автоматически получит такую привилегию. Отмена привилегии осуществляется так:

REVOKE привилегия FROM PUBLIC

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

CREATE ROLE имя_роли DROP ROLE имя_роли

При управлении доступом к таблицам и представлениям набор привилегий в реализации СУБД определяется производителем.

Привилегии выборки и модификации данных:

SELECT - привилегия на выборку данных;

INSERT - привилегия на добавление данных;

DELETE - привилегия на удаление данных;

UPDATE - привилегия на обновление данных (можно указать определенные столбцы, разрешенные для обновления).

Привилегии изменения структуры таблиц:

ALTER - изменение физической/логической структуры базовой таблицы (изменение размеров и числа файлов таблицы, введение дополнительного столбца и т.п.);

INDEX - создание/удаление индексов на столбцы базовой таблицы;

ALL - все возможные действия над таблицей.

В реализациях могут присутствовать другие разновидности привилегий, например: CONTROL (IBM DB2) - комплексная привилегия управления структурой таблицы, REFERENCES - привилегия создания внешних ключей, RUNSTAT - выполнение сбора статистической информации по таблице и другие.

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

Представление (view) - это сформированная выборка кортежей, хранящихся в таблице (таблицах). К представлению можно обращаться точно так же, как и к таблицам, за исключением операций модификации данных, поскольку некоторые типы представлений являются немодифицируемыми. Часто в реализациях view хранится как текст, описывающий запрос выборки, а не собственно выборка данных; выборка же создается динамически на момент выполнения предложения SQL, использующего view. Но разграничить доступ, например, к двум документам, которые удовлетворяют одному и тому же условию выборки, уже нельзя. Это связано с тем, что даже если ввести отдельный атрибут, который будет хранить информацию о метке конфиденциальности документа, то средствами SQL можно будет получить выборку данных без учета атрибута данной метки. Фактически это означает, что либо сам сервер баз данных должен предоставить более высокий уровень защиты информации, либо придется реализовать данный уровень защиты информации с помощью жесткого ограничения операций, которые пользователь может выполнить посредством SQL. На некотором уровне такое разграничение можно реализовать с помощью хранимых процедур, но не полностью - в том смысле, что само ядро СУБД позволяет разорвать связь «защищаемый объект Ц метка конфиденциальности».

Мандатная защита

редства мандатной защиты предоставляются специальными (trusted) версиями СУБД.

Мандатное управление доступом (mandatory access control) - это разграничение доступа субъектов к объектам данных, основанное на характеризуемой меткой конфиденциальности информации, которая содержится в объектах, и на официальном разрешении (допуске) субъектов обращаться к информации такого уровня конфиденциальности.

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

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

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

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

За исключением атрибута собственности (логическая защита), разбивающего данные (таблицы) на собственные (принадлежащие данному субъекту) и чужие, физическая защита разбивает данные более тонко. Но можно ли обойтись без физической защиты или, по крайней мере, попытаться, реализовав, например, сложный набор хранимых процедур. В общем-то некоторое подобие такой защиты реализуемо в случае, когда метки добавляются в таблицу в качестве дополнительного атрибута, доступ к таблицам запрещается вообще и ни одно приложение не может выполнить интерактивный SQL-запрос, а только хранимую процедуру и т.п. Ряд реализаций подобного уровня защиты использует вызов набора хранимых процедур с весьма абстрактными (что очень желательно) именами. Система реализации защиты информации в данном случае достаточно сложна и предполагает определенный уровень доверия к администратору безопасности, так как он имеет право изменять структуру базы данных, а значит, и хранимые процедуры, представления. Физически же администратор безопасности в данном случае не изолирован от управления секретными данными.

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

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

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

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

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

Метка объекта включает следующее:

1. Группа субъекта, который внес данный объект.
2. Уровень доступа на чтение - RAL (Read Access Level).
3. Уровень доступа на запись - WAL (Write Access Level).

Метка субъекта выглядит аналогично:

1. Группа, к которой принадлежит субъект.
2. RAL-уровень субъекта, который представляет собой максимальный RAL-уровень доступной субъекту информации.
3. WAL-уровень субъекта, то есть минимальный RAL-уровень объекта, который может быть создан этим субъектом.

Все пользователи базы данных считаются разбитыми на непересекающиеся группы. Группа описывает область доступных пользователю данных. Для каждой группы существует администратор группы (уровень DBA для группы), созданный администратором системы. При этом пользователи одной группы не видят данных, принадлежащих пользователям другой группы. В этом плане у СУБД «Линтер» имеется особенность: в системе реализовано такое понятие, как «уровень доверия между группами». При этом уровни доверия не могут быть вложенными. Группа представляет собой числовое значение в диапазоне . Группа 0 - группа администратора системы. Только администратор системы может создать пользователя в группе, отличной от своей. Все данные, созданные от имени пользователя, помечаются его группой.

Уровни доступа вводятся для проверки прав на осуществление чтения-записи информации. Вводятся следующие уровни доступа:

1. Для пользователя (субъекта):

• RAL - уровень доступа; пользователь может получать (читать) информацию, RAL-уровень которой не выше его собственного уровня доступа;
• WAL - уровень доверия на понижение уровня конфиденциальности; пользователь не может вносить информацию с уровнем доступа (RAL-уровнем) более низким, чем данный WAL-уровень пользователя. Иными словами, пользователь не может сделать доступную ему информацию менее конфиденциальной, чем указано в данном параметре.

1. Для информации:

• RAL - уровень чтения; пользователь может получать (читать) информацию, RAL-уровень которой не выше его собственного RAL-уровня (может читать менее конфиденциальные данные);
• WAL - уровень ценности или уровень доступа на запись (модификацию, удаление); пользователь может модифицировать (удалять) информацию, WAL-уровень которой не выше его RAL-уровня.

Создать пользователя с произвольными уровнями может только администратор системы. Остальные администраторы (DBA) могут создавать пользователей (или изменять уровень пользователям) лишь в пределах отведенных им уровней. Пользователь может принудительно пометить вводимые данные, указав в списке атрибутов уровни доступа для соответствующих записей и полей (при выполнении операторов INSERT или UPDATE). По умолчанию вносимые данные наследуют уровни пользователя, вносящего/изменяющего данные. Защищаемые объекты: пользователи, таблицы, столбцы, записи (вносится при выполнении INSERT), поля записей (изменяются при выполнении UPDATE). Уровни, как и группы, нельзя использовать в случае, если они не созданы специальными запросами.

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

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

КомпьютерПресс 3"2002

Но пока наши законодатели спорят о проектах законов о коммерческой тайне и электронной торговле, в общественных местах - в переходах метро и даже на автостоянках, не говоря уж об Интернете, продолжают продаваться компакт-диски с разнообразными базами данных (БД). Выбор необычайно широк: за 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. - Прим. ред.