Концепции защиты данных в бд. Защита информации в субд

02.04.2019

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

Введение

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

обеспечивать получение общих и/или детализированных отчетов по итогам работы;

позволять легко определять тенденции изменения важнейших показателей;

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

выполнять точный и полный анализ данных.

Современные СУБД в основном являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловил не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделал программное обеспечение ПК в целом и СУБД в частности менее критичными к аппаратным ресурсам ЭВМ. Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии «клиент-сервер».

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

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

Ограничение обновления определенных атрибутов с целью сохранения требуемых пропорций между их старыми и новыми значениями;

Ограничения, требующие сохранение значений поля показателя в некотором диапазоне;

Ограничения, связанные с заданными функциональными зависимостями.

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

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

Защита информации . Понятие защиты информации

защита информация несанкционированный доступ

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

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

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

Основными критериями оценки надежности являются: политика безопасности и гарантированность.

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

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

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

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

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

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

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

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

Защита ПК от несанкционированного доступа

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

1) подавляющая часть ПК располагается непосредственно в рабочих комнатах специалистов, что создает благоприятные условия для доступа к ним посторонних лиц;

2) многие ПК служат коллективным средством обработки информации, что обезличивает ответственность, в том числе и за защиту информации;

3) современные ПК оснащены несъемными накопителями на ЖМД очень большой емкости, причем информация на них сохраняется даже в обесточенном состоянии;

4) накопители на ГМД производятся в таком массовом количестве, что уже используются для распространения информации так же, как и бумажные носители;

5) первоначально ПК создавались именно как персональное средство автоматизации обработки информации, а потому и не оснащались специально средствами защиты от НСД.

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

Основные механизмы защиты ПК от НСД могут быть представлены следующим перечнем:

1) физическая защита ПК и носителей информации;

2) опознавание (аутентификация) пользователей и используемых компонентов обработки информации;

3) разграничение доступа к элементам защищаемой информации;

4) криптографическое закрытие защищаемой информации, хранимой на носителях (архивация данных);

5) криптографическое закрытие защищаемой информации в процессе непосредственной ее обработки;

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

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

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

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

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

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

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

Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы 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 требует хорошего знания как семантики принципов поддержки прав доступа, так и физической реализации этих возможностей.

Реализация защиты в некоторых СУБД

Архитектура защиты Access. Если у вас имеется опыт работы с защитой, используемой на сервере или большой ЭВМ, структура защиты в Access покажется вам знакомой. Вы можете указать пользователей, которым предоставляется или, наоборот, не разрешается доступ к объектам базы данных. Кроме того, вы можете определить группы пользователей и назначить разрешения на уровне группы, чтобы облегчить построение защиты для большого числа пользователей. Пользователю достаточно быть членом группы, чтобы получить права доступа, установленные для неё.

Access хранит информацию о защите в двух местах. Во время установки программа Setup создаст в папке \Program Files\Microsoft Ofice\0ffice стандартный файл рабочей группы (System.mdw), который впоследствии используется по умолчанию при запуске Access. Этот файл содержит информацию обо всех пользователях и группах. При создании базы данных Access сохраняет сведения о правах, предоставляемых конкретным пользователям и группам, в файле базы данных.

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

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

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

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

Организация защиты

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

Говоря о симметричной архитектуре, операции резервного копирования и восстановления могут распараллеливаться на несколько потоков и выполняться одновременно, используя преимущества асинхронного ввода/вывода. На каждое резервное устройство отводится свой поток. Параллельное резервное копирование поддерживает до 32 одновременных резервных устройств (backup devices), что позволяет быстро создавать страховочные копии баз данных даже очень большой емкости. Возможность резервного копирования и восстановления отдельных таблиц, о чем мы упоминали, рассматривая Transact-SQL, позволяет экономить место и время, не выполняя копирование всей базы ради только некоторых ее объектов. Однако резервное копирование отдельной таблицы требует наложения на нее блокировки exclusive в отличие от резервного копирования всей базы или журнала транзакций, которые могут выполняться независимо от степени активности пользователей. Резервным копиям может быть назначен предельный срок хранения или дата утраты актуальности, до наступления которой место, занятое на устройстве этими копиями, не может использоваться для размещения других резервных копий при инициализации устройства. В качестве резервных устройств могут также применяться временные устройства, не входящие в состав базы и не имеющие записей в системной таблице sysdevices:

DECLARE @tomorrow char(8)

SELECT @tomorrow = CONVERT(char(8), DATEADD(dd, 1, GETDATE()) , 1)

DUMP DATABASE pubs

TO DISK = "\\ntalexeysh\disk_d\sql_experiments\pubs.dmp"

WITH INIT, EXPIREDATE=@tomorrow, STATS

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

Как правило, резервное копирование базы данных организуется с меньшей частотой, чем журнала транзакций. Например, сохранение журнала транзакций выполняется ежедневно, а страховая копия всей базы может делаться раз в неделю, так как архивирование журнала транзакций происходит значительно быстрее по времени и занимает меньше места, чем дамп целой базы. В отличие от резервирования базы данных дамп журнала транзакций очищает его неактивную часть, т. е. все завершившиеся (зафиксированные или абортированные) с момента последнего дампа транзакции, если только не использована опция NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY, очищающая журнал транзакций, полезна в случае его переполнения, которое можно контролировать, например, оператором DBCC SQLPERF (LOGSPACE). Если степень переполнения журнала очень высока, можно при его очистке отказаться от журналирования факта самого этого события: DUMP TRANSACTION NO_LOG. Если резервное копирование транзакций не представляет интереса, можно включить опцию очистки последних завершенных транзакций в базе по наступлению события checkpoint. Cмысл механизма checkpoint состоит в периодической записи данных из кэша на диск, чтобы не допускать грязных данных. Такого рода события постоянно генерируются MS SQL Server или возникают по инициативе пользователя. Включенная опция truncate log on checkpoint гарантирует выполнение с определенной частотой обработчиком события действий, приблизительно эквивалентных команде DUMP TRANSACTION TRUNCATE_ONLY.

При восстановлении журнала транзакций соответствующие транзакции применяются к базе данных. Это означает, что если в начале недели была сделана резервная копия всей базы, а потом ежедневно архивировались транзакции за каждый день, то при необходимости восстановления поднимается состояние базы на начало недели и на него последовательно накатываются дампы журнала транзакций за все дни, предшествующие моменту восстановления. MS SQL Server 6.5 имеет возможность восстановления данных из журнала транзакций на произвольный момент времени (разумеется, отраженный в журнале) при помощи команды LOAD TRANSACTION STOPAT или в окне database backup and restore выбором опции until time. Все содержащиеся в этом дампе транзакции, отмеченные завершившимися после этого момента, будут откачены.

Возможность планирования задач резервного копирования во времени и отсылки сообщений по e-mail в случае успешного/неуспешного завершения рассматривалась нами при обсуждении SQL Executive.

MS SQL Server 6.5 предусматривает возможность зеркалирования устройств, переключения на зеркальные устройства в качестве основных, выключения зеркалирования и уничтожения зеркального устройства также "на лету", т. е. без остановки штатной работы сервера по обслуживанию пользовательских запросов. Зеркалирование и дуплексирование устройств для работы с MS SQL Server может быть также выполнено средствами Windows NT, а также на аппаратном уровне (поддержка различных RAID-систем и т. д.). По-видимому, следует предполагать, что реализация первого этапа кластерной технологии WolfPack будет поддерживать MS SQL Server 6.5 в отказоустойчивых кластерах из двух узлов. Появление следующей версии MS SQL Server должно обеспечить работу серверов в кластере как единого виртуального сервера.

Transfer Manager используется для экспорта/импорта объектов и данных БД на MS SQL Server между разными аппаратными платформами, например между процессорами Intel и Alpha, а также между разными версиями MS SQL Server, в частности из более ранних в более поздние или между равноценными (имеются в виду 4.х и 6.х). Очень часто проектирование объектов базы ведется с помощью различных графических средств, но проектная документация может требовать структуру объектов с точностью до операторов DDL. Для получения скриптов, описывающих создание отдельного объекта базы данных, можно использовать команду transfer из контекстного меню объекта или выбрать соответствующий класс и имя объекта в Transfer Manager. Кроме этого, содержимое данных может быть выгружено/загружено при помощи утилиты bcp (см. табл. 1).

Вопросы безопасности доступа

Говоря о преимуществах интеграции с операционной системой, MS SQL Server использует в своей работе сервисы безопасности Windows NT. Напомним, что Windows NT на сегодня сертифицирована по классам безопасности С2/Е3. MS SQL Server может быть настроен на работу в одном из трех режимах безопасности. Интегрированный режим предусматривает использование механизмов аутентификации Windows NT для обеспечения безопасности всех пользовательских соединений. В этом случае к серверу разрешаются только трастовые, или аутентифицирующие, соединения (named pipes и multiprotocol). Администратор имеет возможность отобразить группы пользователей Windows NT на соответствующие значения login id MS SQL Server при помощи утилиты SQL Security Manager. В этом случае при входе на MS SQL Server login name и пароль, переданные через DB-Library или ODBC, игнорируются. Стандартный режим безопасности предполагает, что на MS SQL Server будут заводиться самостоятельные login id и соответствующие им пароли. Смешанный режим использует интегрированную модель при установлении соединений по поименованным каналам или мультипротоколу и стандартную модель во всех остальных случаях.

MS SQL Server обеспечивает многоуровневую проверку привилегий при загрузке на сервер. Сначала идентифицируются права пользователя на установление соединения с выбранным сервером (login name и пароль) и выполнение административных функций: создание устройств и баз данных, назначение прав другим пользователям, изменение параметров настройки сервера и т.д. Максимальными правами обладает системный администратор. На уровне базы данных каждый пользователь, загрузившийся на сервер, может иметь имя пользователя (username) базы и права на доступ к объектам внутри нее. Имеется возможность отобразить нескольких login id на одного пользователя базы данных, а также объединять пользователей в группы для удобства администрирования и назначения сходных привилегий. По отношению к объектам базы данных пользователю могут быть назначены права на выполнение различных операций над ними: чтение, добавление, удаление, изменение, декларативная ссылочная целостность (DRI), выполнение хранимых процедур, а также права на доступ к отдельным полям. Если этого недостаточно, можно прибегнуть к представлениям (views), для которых сказанное остается справедливым. Наконец, можно вообще запретить пользователю непосредственный доступ к данным, оставив за ним лишь права на выполнение хранимых процедур, в которых будет прописан весь сценарий его доступа к базе. Хранимые процедуры могут создаваться с опцией WITH ENCRYPTION, которая шифрует непосредственный текст процедуры, хранящийся обычно в syscomments. Права на выполнение некоторых команд (создание баз, таблиц, умолчаний, правил, представлений, процедур, резервное копирование баз и журналов транзакций) не являются объектно-специфичными, поэтому они назначаются системным администратором сервера или владельцем (создателем) базы данных при редактировании базы данных. Администрирование пользовательских привилегий обычно ведется в SQL Enterprise Manager, тем не менее в Transact-SQL имеются хранимые процедуры (sp_addlogin, sp_password, sp_revokelogin, sp_addalias, sp_adduser) и операторы (GRANT, REVOKE), которые позволяют осуществлять действия по созданию пользователей, назначению и отмене прав при выполнении скриптов. Дополнительную возможность администрирования привилегий предоставляют рассмотренные нами выше SQL-DMO.

Управление доступом

Система безопасности SQL Server имеет несколько уровней безопасности:

* операционная система;

* база данных;

* объект базы данных.

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

* системный администратор, имеющий неограниченный доступ;

* владелец БД, имеющий полный доступ ко всем объектам БД;

* владелец объектов БД;

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

Модель безопасности SQL Server включает следующие компоненты:

* тип подключения к SQL Server;

* пользователь базы данных;

* пользователь (guest);

* роли (roles).

Тип подключения к SQL Server

При подключении (и в зависимости от типа подключения) SQL Server поддерживает два режима безопасности:

* режим аутентификации Windows NT;

* смешанный режим аутентификации.

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

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

Пользователи базы данных

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

Единственным исключением из этого правила является пользователь guest (гость). Особое имя пользователя guest разрешает любому подключившемуся к SQL Server пользователю получить доступ к этой базе данных. Пользователю с именем guest назначена роль public.

Права доступа

Для управления правами доступа в SQL Server используются следующие команды:

* GRANT. Позволяет выполнять действия с объектом или, для команды -- выполнять ее;

* REVOKE. Аннулирует права доступа для объекта или, для команды -- не позволяет выполнить ее;

* DENY. He разрешает выполнять действия с объектом (в то время, как команда REVOKE просто удаляет эти права доступа).

Объектные права доступа позволяют контролировать доступ к объектам в SQL Server, предоставляя и аннулируя права доступа для таблиц, столбцов, представлений и хранимых процедур. Чтобы выполнить по отношению к некоторому объекту некоторое действие, пользователь должен иметь соответствующее право доступа. Например, если пользователь хочет выполнить оператор SELECT * FROM table, то он должен и меть права выполнения оператора SELECT для таблицы table.

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

CREATE DATABASE -- право создения базы данных;

CREATE DEFAULT -- право создшия стандартного значения для столбца таблицы;

CREATE PROCEDURE -- право содания хранимой процедуры.

CREATE ROLE -- право создания гоавила для столбца таблицы;

CREATE TABLE -- право создания таблицы;

CREATE VIEW -- право создания представления;

BACKUP DATABASE -- право создшия резервной копии;

BACKUP TRANSACTION -- праве создания резервной копии журнала транзакций.

Роли

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

* роли уровня сервера;

* роли уровня базы данных.

Роли уровня сервера

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

В SQL Server существуют следующие типы ролей уровня сервера:

Sysadmin -- дает право выполнить любое действие в SQL Server;

Serveradmin -- дает право изменить параметры SQL Server и завершить его работу;

Setupadmin -- дает право инсталлировать систему репликации и управлять выполнением расширенных хранимых процедур;

Securityadmin -- дает право контролировать параметры учетных записей для подключения к серверу и предоставлять права доступа к базам данных;

Processadmin -- дает право управлять ходом выполнения процессов в SQL Server;

Dbcreator -- дает право создавать и модифицировать базы данных;

Diskadmin -- дает право управлять файлами баз данных на диске.

Роли уровня базы данных

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

В SQL Server существует три типа ролей:

* заранее определенные роли;

* определяемые пользователем роли;

* неявные роли.

Заранее определенными являются стандартные роли уровня БД. Эти роли имеет каждая база данных SQL Server. Они позволяют легко и просто передавать обязанности.

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

db_owner -- определяет полный доступ ко всем объектам базы данных, может удалять и воссоздавать объекты, а также присваивать объектные права другим пользователям. Охватывает все функции, перечисленные ниже для других стандартных ролей уровня базы данных;

db_accessadmin -- осуществляет контроль за доступом к базе данных путем добавления или удаления пользователей в режимах аутентификации;

db_datareader -- определяет полный доступ к выборке данных (с помощью оператора SELECT) из любой таблицы базы данных. Запрещает выполнение операторов INSERT, DELETE и UPDATE для любой таблицы БД;

db_datawriter -- разрешает выполнять операторы INSERT, DELETE и UPDATE для любой таблицы базы данных. Запрещает выполнение оператора SELECT для любой таблицы базы данных;

db_ddladmin -- дает возможность создавать, модифицировать и удалять объекты базы данных;

db_securityadmin -- управляет системой безопасности базы данных, а также назначением объектных и командных разрешений и ролей для базы данных;

db_backupoperator -- позволяет создавать резервные копии базы данных;

db_denydatareader -- отказ в разрешении на выполнение оператора SELECT для всех таблиц базы данных. Позволяет пользователям изменять существующие структуры таблиц, но не позволяет создавать или удалять существующие таблицы;

db_denydatawriter -- отказ в разрешении на выполнение операторов модификации данных (INSERT, DELETE и UPDATE) для любых таблиц базы данных;

public -- автоматически назначаемая роль сразу после предоставления права доступа пользователя к БД.

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

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

* стандартная роль;

* роль уровня приложения.

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

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

Системный анализ - это применение системного подхода при обработке конкретной информации и принятию решений. Рассмотренные принципы системного подхода являются и принципами системного анализа.

Их дополняют следующие специфические принципы:

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

* необходимо рассматривать лишь те цели, вероятность достижения которых р>р0 за время t

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

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

Безопасность данных в Oracle 7

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

Огромным шагом вперед в обеспечении безопасности данных стало введение ролей в Oracle7. До Oracle7 каждому пользователю приходилось явно предоставлять права доступа к каждому объекту базы данных, который ему разрешено было использовать. Этот процесс упрощается за счет того, что доступ к совокупности объектов предоставляется роли, а затем право на использование этой роли предоставляется соответствующим лицам. С помощью команды GRANT мы можем предоставить пользователям право выполнять над объектами БД (например, над таблицами) операции SELECT, INSERT, UPDATE и DELETE. Однако само по себе это не обеспечивает значительной гибкости. Мы можем ограничить доступ пользователей частями таблицы, разделив ее по горизонтали (ограничив пользователя определенными строками), по вертикали (ограничив его определенными столбцами) или и по горизонтали, и по вертикали. Как это сделать?

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

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

CREATE VIEW vjpayroll AS SELECT id

Payment_period FROM payroll WHERE dept = (SELECT dept

FROM mysys_users WHERE username = USER) WITH CHECK OPTION;

Столбец SALARY в этом примере не включен в представление, поэтому зарплату в нем увидеть нельзя, а фраза WHERE гарантирует, что пользователи смогут запрашивать данные из таблицы PAYROLL только по своему отделу.

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

Примечание

Вряд ли представление V_PAYROLL будет обновляемым, потому что к столбцу SALARY почти наверняка применено ограничение NOT NULL. Тем не менее, мы рекомендуем использовать опцию WITH CHECK OPTION во всех ограничивающих представлениях, так как в версии 7.3 значительно увеличилось число обновляемых представлений.

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

Использование пакетов

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

Наша первая попытка создать такой пакет представлена в примере 10.2. Пакетk_payroll гарантирует, что записи могут удаляться только начальником отдела и что устанавливать значение столбца SALARY может только начальник отдела.

Пример построения пакета для обеспечения безопасности доступа к данным

CREATE OR REPLACE PACKAGE k_payroll AS my_dept payroll.dept%TYPE; mgr BOOLEAN;

PROCEDURE del (p_emp_id INTEGER);

PROCEDURE ins (p_emp_id INTEGER, p_name VARCHAR2

P_dept INTEGER, p_payment_period VARCHAR2

P_salary INTEGER);

PROCEDURE upd (p_emp__id INTEGER, p_name VARCHAR2

P_payment_penod VARCHAR2 ,p_salary INTEGER);

/CREATE OR REPLACE PACKAGE BODY k_payroll AS

mgr_flag payroll.mgr_flag%TYPE;

FROM mysys_users

WHERE username = USER;

FUNCTION checkdept (p_emp_id INTEGER) RETURN BOOLEAN IS

dept payroll.dept%TYPE;

CURSOR cjpayroll IS

FROM payroll pay

WHERE id = p_emp_id;

OPEN c_payroll ;

FETCH cjpayroll INTO dept;

CLOSE c_payroll;

IF dept <> my_dept THEN

PROCEDURE del (p_emp_id INTEGER) IS

Удалять сотрудников могут только начальники их отделов

Записи таблицы Payroll

IF checkdept(p_emp_id) AND mgr THEN

WHERE id = p_emp_id;

raise_application_error (-20001, "Insufficient Privilege"); END IF;

Подобные документы

Необходимость и потребность в защите информации. Виды угроз безопасности информационных технологий и информации. Каналы утечки и несанкционированного доступа к информации. Принципы проектирования системы защиты. Внутренние и внешние нарушители АИТУ.

контрольная работа , добавлен 09.04.2011

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

презентация , добавлен 09.12.2015

Характеристика основных способов защиты от несанкционированного доступа. Разработка политики безопасности системы. Проектирование программного обеспечения применения некоторых средств защиты информации в ОС. Содержание основных разделов реестра.

лабораторная работа , добавлен 17.03.2017

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

реферат , добавлен 16.03.2014

Современное развитие АСУ и защита информации. Функция системы защиты с тремя регистрами. Выбор механизмов защиты и их особенности. Ответственность за нарушение безопасности методов. Методы защиты режима прямого доступа. Требования к защите информации.

реферат , добавлен 29.10.2010

Методы и средства защиты информационных данных. Защита от несанкционированного доступа к информации. Особенности защиты компьютерных систем методами криптографии. Критерии оценки безопасности информационных компьютерных технологий в европейских странах.

контрольная работа , добавлен 06.08.2010

Пути несанкционированного доступа, классификация способов и средств защиты информации. Каналы утечки информации. Основные направления защиты информации в СУП. Меры непосредственной защиты ПЭВМ. Анализ защищенности узлов локальной сети "Стройпроект".

дипломная работа , добавлен 05.06.2011

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

реферат , добавлен 23.10.2011

Пути несанкционированного доступа, классификация способов и средств защиты информации. Анализ методов защиты информации в ЛВС. Идентификация и аутентификация, протоколирование и аудит, управление доступом. Понятия безопасности компьютерных систем.

дипломная работа , добавлен 19.04.2011

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ТО user2 GRANT SELECT

GRANT SELECT. UPDATE (COST) ON Tab1 TO user3

GRANT ALL PRIVILEGES

TO user4 WITH GRANT OPTION

ON Tab1 TO user5

GRANT SELECT. UPDATE. DELETE

TO user4 WITH GRANT OPTION,

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

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

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

REVOKE ALL PRIVILEGES - ON Tab1 TO user4 CASCADE

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

REVOKE ALL PRIVILEGES ON Tab1 TO user4 RESTRICT

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

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

REVOKE INSERT ON Tab! TO user2.user4 CASCADE

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

Если вы хотите изменить это условие, то после создания хранимой процедуры необходимо записать оператор 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

GRANT CREATE DATABASE

ON SERVERJ) TO main user

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

Закон о защите персональных данных не выполняется. Почему?

Для начала, вспомним некоторые положения №152-Федерального Закона "О персональных данных" .

Согласно статье 3 закона "оператор - государственный орган, муниципальный орган, юридическое или физическое лицо, организующие и (или) осуществляющие обработку персональных данных, а также определяющие цели и содержание обработки персональных данных". Таким образом, мы приходим к выводу, от которого и будем отталкиваться: практически все юридические лица РФ являются потенциальными операторами ПД.

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

Кроме этого, в требованиях закона "О защите персональных данных" №152-ФЗ содержатся некоторые, мягко говоря, непривычные для российских организаций процедуры, такие как:

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

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

Стоит добавить, что по некоторым данным, упомянутая классификация и соответствующие каждому классу требования, согласно постановлению Правительства №781, уже разработаны ФСТЭК, ФСБ и Мининформсвязи России и в ближайшее время будут опубликованы. Этот долгожданный во многом документ прольет свет на эти и другие аспекты практического применения ФЗ-152. Но основные надежды, которые с ним связаны, заключаются в получении практических инструкции по реализации требований закона для государственных организаций, обрабатывающих ПД граждан.

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

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

Закон суров, но справедлив

Не менее интересно и то, какие возможности предусматривает закон для самих граждан - субъектов персональных данных. В дополнение к вышесказанному вспомним другие положения закона. Согласно части 4 статьи 14 ФЗ-152 субъект персональных данных имеет право на получение при обращении или при получении запроса информации, касающейся обработки его ПД, в том числе содержащей: подтверждение факта обработки персональных данных оператором, а также цель такой обработки; способы обработки ПД, применяемые оператором; сведения о лицах, которые имеют доступ к ПД; перечень обрабатываемых персональных данных и источник их получения; сроки обработки ПД, в том числе сроки их хранения; сведения о том, какие юридические последствия для субъекта персональных данных может повлечь за собой обработка его ПД. По сути, это тоже трудновыполнимая задача для оператора, ведь никто не отменял ст.137 УК РФ "Нарушение неприкосновенности частной жизни" от 13 июня 1996г. В статье, в частности, говорится, что уголовную ответственность влечет: незаконное собирание или распространение сведений о частной жизни лица, составляющих его личную или семейную тайну, без его согласия либо распространение этих сведений в публичном выступлении, публично демонстрирующемся произведении или средствах массовой информации, если эти деяния совершены из корыстной или иной личной заинтересованности и причинили вред правам и законным интересам граждан.

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

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

Вот основные составляющие системы госконтроля и надзора за обеспечением безопасности ПД при их обработке в ИС:

Россвязьохранкультура - уполномоченный орган по защите прав субъектов ПД;
ФСБ - Федеральный орган исполнительной власти, уполномоченный в области обеспечения государственной безопасности и применения средств шифрования;
ФСТЭК - федеральная служба по техническому и экспортному контролю и противодействия иностранным разведкам - уполномоченный орган в области контроля используемых технических средств защиты;
Министерство информационных технологий и связи РФ - порядок проведения классификации информационных систем, содержащих персональные данные.

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

Как правильно защищать базы данных?

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

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

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

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

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

Основные компоненты системы защиты баз данных

Классическая схема защиты баз данных (БД) подразделяется на следующие обязательные процедуры:

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

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

Разграничение доступа

Преследуя цель защиты БД от инсайдерских угроз, для обеспечения разграничения доступа в версии СУБД 10g Release 3 компания Oracle выпустила новый продукт Database Vault , предназначенный для предотвращения несанкционированного доступа к информации пользователей, в том числе наделенных особыми полномочиями, например, администраторов базы данных. Набор правил в Database Vault , разграничивающих доступ, достаточно широк. Например, руководство организации может определить правила, согласно которым для решения задач, предполагающих доступ к критичной информации, потребуется одновременное присутствие двух сотрудников. Таким образом, Database Vault решает следующие проблемы:

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

Защита доступа

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

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

Итак, рассмотрим подробнее способы аутентификации в СУБД Oracle .

Аутентификация средствами операционной системы

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

Аутентификация при помощи сетевых сервисов

Данный вид аутентификации обеспечивает опция сервера Oracle Advanced Security . Она предоставляет следующие службы:

1. SSL - аутентификация использует протокол SSL (Secure Socket Layer) - протокол уровня приложений. Он может использоваться для аутентификации в БД и в общем случае (если далее используется аутентификация пользователя средствами СУБД) не зависит от системы глобального управления пользователями, обеспечиваемой службой каталога Oracle - Oracle Internet Directory .

2. Аутентификация службами третьих сторон.

На основе Kerberos . Применение Kerberos как системы аутентификации с доверенной третьей стороной, основано на использовании, т.н. общего секрета. Это предопределяет безопасность и надежность доверенной стороны и дает возможность использования Single Sign - On , централизованного хранения паролей, прозрачной аутентификации через связи БД (database links), а также средств усиленной безопасности на рабочих станциях.

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

протокол SSL
набор OCI (Oracle Call Interface - прикладной интерфейс доступа к БД) и PL / SQL функций
доверенные сертификаты (trusted certificate), для проверки подлинности сертификатов, предъявляемых пользователями (приложениями)
Oracle wallets - ключевые контейнеры, содержащие личный ключ (private key) пользователя, его сертификат и цепочки доверенных сертификатов
Oracle AS Certificate Authority - компонента Oracle Application Server , предназначенная для издания сертификатов и дальнейшего управления ими
- Oracle Wallet Manager (OWM) - компонента СУБД для управления wallet "ами

На основе RADIUS . СУБД Oracle поддерживает протокол RADIUS (Remote Authentication Dial - In User Service) - стандартный протокол для аутентификации удаленных пользователей. При этом становятся доступны службы и устройства аутентификации третьих производителей, с которыми может взаимодействовать сервер RADIUS (например, устройства генерации одноразовых паролей, биометрические устройства и т.п.).

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

Oracle Internet Directory (OID) позволяет централизованно хранить и управлять информацией о пользователях (т.н. enterprise -пользователях). Позволяет иметь единственную учетную запись пользователя для многих баз данных. Возможна интеграция со службами каталогов третьих производителей, например, MS Active Directory или iPlanet . OID позволяет гибко управлять атрибутами безопасности и привилегиями каждого пользователя, включая тех, кто аутентифицируется по цифровым сертификатам. Для повышения безопасности во время процесса аутентификации возможно использование SSL -протокола.
Oracle Enterprise Security Manager - утилита управления пользователями, группами, ролями и привилегиями.

3. Аутентификация в многоуровневых приложениях

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

Шифрование данных

Для защиты данных, передаваемых в сети, в СУБД Oracle, начиная с версии 8i, используется возможности опции Oracle Advanced Security , в которой предусмотрена функция Network encryption , позволяющая шифровать весь поток данных. Безопасность информации обеспечивается секретностью ключа, которым шифруются данные.

Network encryption позволяет добиться высокого уровня безопасности. Поддерживаются следующие алгоритмы шифрования AES (только 10 g /11g). DES , 3 DES , RC 4(только 10 g /11g).

Защита передаваемых в сети данных в приложениях Oracle обеспечивается протоколом SSL по алгоритмам, которые поддерживается сервером приложений, как правило, это WEB -сервер Oracle.

Защиту данных на носителе обеспечивают два компонента СУБД Oracle - пакеты, реализующие алгоритмы шифрования и опция Transparen t Data Encryption (T DE). Начиная с версии 8i, СУБД Oracle предоставляет для разработчиков приложений пакеты хранимых процедур, реализующих алгоритмы: DES с длиной ключа 56 бит, Triple DES с длиной ключа 112 и 168 бит , A ES с длиной ключа 128, 192 и 256 бит RC 4 (только 10 g /11g).

Опция T DE появилась в версии СУБД Oracle 10g Release 2 как составная часть Advanced Security. Она позволяет выборочно шифровать колонки таблиц с применением алгоритмов Triple DES (c длиной ключа 168 бит), AES (c длиной ключа 128, 192 или 256 бит). Управление ключами шифрования берет на себя ядро БД, а применение такого шифрования не требует переделки клиентского и серверного прикладного ПО. В версии СУБД 11g и выше появилась возможность зашифрования табличного пространства целиком.

Аудит доступа к данным

СУБД Oracle имеет мощные средства аудита действий пользователей, включающих как доступ к данным, так и события регистрации/выхода и изменения структуры БД. Начиная с версии 9i, СУБД оснащается опцией подробного аудита (Fine Grained Audit Control), которая позволяет проводить аудит доступа по условиям, определяемым достаточно гибкими настраиваемыми правилами. Однако, данные средства аудита не позволяет проследить за действиями, которые совершаются администратором базы данных, а также не мешают ему изменять журнал аудита, удаляя любые строки и не оставляя следов подобных действий. Возникшая необходимость аудита деятельности и защиты данных аудита от привилегированных пользователей, включая администраторов БД, побудило Oracle разработать новую концепцию аудита. В её основу положена идея, на которой базируется функционал Database Vault : администратор БД изолирован от управления аудитом, что по поянтным причинам обеспечивает более высокий уровень безопасности БД. Как и в случае Database Vault правила назначения аудита в Audit Vault очень гибкие.

Достаточно ли встроенных средств защиты?

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

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

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

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

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

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

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

Доводы для такого подхода, примерно, следующие:встроенные средства защиты явно недостаточны и изобилуют уязвимостями;

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

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

Достаточно ли парольной аутентификации?

Действительно, простота использования парольной защиты не вызывает сомнений. Но простота и надёжность защиты в данном случае малосовместимы. В безопасности и удобстве эксплуатации такая технология себя изживает. Надежность пароля и, следовательно, безопасность его использования, напрямую зависит от его качества (применяемые символы, их регистр, отличие от осмысленных слов). А удобство использования стремительно падает даже при незначительном усилении "безопасности" пароля, ведь запомнить нечитаемую комбинацию символов довольно сложно. Обратимся к цифрам и фактам. Пароли пользователей хранятся в СУБД Oracle в виде хеш-значений и доступны для чтения привилегированным пользователям. Алгоритм вычисления хеша пароля давно известен. Наиболее полное исследование стойкости паролей в Oracle проведено компанией Red - Database - Security GmbH - ведущего мирового эксперта в области безопасности продуктов Oracle. Вот некоторые данные по стойкости паролей для версий СУБД 7-10g:

На компьютере с Pentium 4 3 GHz требуемое время составляет (атака простым перебором):

10 секунд все 5- символьные комбинации
5 минут все 6- символьные комбинации
2 часа все 7- символьные комбинации
2,1 дня все 8- символьные комбинации
57 дней все 9- символьные комбинации
4 года все 10- символьные комбинации

И это при использовании далеко не самого мощного компьютера. При наращивании производительности атака по словарю проводится ещё быстрее. Нельзя сказать, что Oracle не реагирует на подобное положение дел - в версии СУБД 11g положение значительно улучшилось. Был усилен алгоритм выработки хеша и качество формирования паролей. В результате приведенные выше цифры выросли в 2.5-3 раза. Но, несмотря на такие улучшения, Oracle рекомендует использовать средства усиленной аутентификации, которые также были доработаны в лучшую сторону, например, стало возможно использовать HSM (Hardware Security Module) для аутентификации и хранения ключей шифрования.

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

Низкая стоимость владения - миф?

Широко распространенное заблуждение. Статистика подтверждает факты значительных затрат на обслуживание, скажем, забытых паролей. Еще более ощутимые потери несут компании из-за низкой надежности и безопасности парольной защиты.

Уязвимы ли встроенные средства защиты?

И в этом вопросе мы вновь сталкиваемся с расхожим мнением о том, что штатные средства безопасности недостаточны. Как объяснить возникновение такого мнения, особенно при учёте того, что и встроенные средства защиты чаще всего используется далеко не на 100%. Т

Что же касается уязвимостей встроенных средств защиты в Oracle, то ситуация здесь ровно такая же как и в других сложных системах. Корпорация Oracle традиционно ответственно относится к обнаружению и устранению найденных уязвимостей. Регулярно (4 раза в год) выпускаются обновления CPU (Critical Patch Update), устраняющие бреши, обнаруженные как самой корпорацией Oracle, так и десятками других компаний, наиболее известная из которых - уже упоминавшаяся Red - Database - Security GmbH . Так, например, в CPU за октябрь 2007 г. были устранены 27 уязвимостей в СУБД, 11 - в сервере приложений, 13 - в различных приложениях. Учитывая число продуктов Oracle , их версий и программно-аппаратных платформ для них, это не так уж и много.

Своя разработка vs поддержка вендора

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

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

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

Возможности усиления функций защиты: когда это необходимо?

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

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

Алгоритмы российской криптографии (PKI, ЭЦП, шифрование в сети и на носителе)

Реализация шифрования при записи на носитель без использования TDE

Хранение ключевого материала.

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

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

Криптографические алгоритмы могут использоваться в процессе аутентификации, выработки ЭЦП (ГОСТ Р 34.10-2001), для защиты канала связи (ГОСТ 28147-89, ГОСТ Р 34.11-94) и шифрования данных (ГОСТ 28147-89). Встроенные средства Oracle не реализуют данные алгоритмы ни в СУБД, ни в сервере приложений, ни в приложениях. Реализацию криптографии в виде библиотек, стандартных поставщиков криптографии (CSP), комплектов разработчика (SDK) предлагают несколько российских производителей - КриптоПро, Сигнал-Ком, Инфотекс, Лисси, КриптоКом, КриптоЭкс и др. Однако, заставить продукты Oracle работать с предлагаемыми библиотеками достаточно проблематично. Дело даже не в том, что данные средства не совместимы на уровне программно-аппаратного обеспечения - встраивание криптографии в продукты Oracle не должно нарушать лицензионного соглашения вендора относительно целостности ПО. Если с ИС, построенными на основе сервера приложений Ora cle или всего множества приложений Oracle, проблем со встраиванием, как правило, не возникает, то с СУБД дело обстоит сложнее. Вследствие того, что ядро СУБД не имеет программного интерфейса к криптооперациям (аутентификация, шифрование), приходится применять обходные пути. Например, использовать протокол аутентификации Kerberos или генераторы одноразовых паролей с протоколом RADIUS, а защиту канала связи осуществлять с помощью сертифицированных программных средств.

Шифрование данных без использования TDE

Несмотря на чрезвычайную простоту опции Oracle TDE, от ее использования часто приходится отказываться. Основных причин две:

Не поддерживаются некоторые типы данных

Нет возможности штатно применить российские криптоалгоритмы

Нет реальной защиты от привилегированных пользователей.

Первая проблема в принципе решается с помощью продуктов сторонних разработчиков - DbEncrypt for Oracle (Application Security, Inc.), eToken SafeData (Aladdin Software Security R . D .), The Encryption Wizard for Oracle (Relational Database Consultants , Inc .). Вторая проблема принципиально решается таким же образом, но здесь вариантов меньше - eToken SafeData или The Encryption Wizard for Oracle . Причем для первого продукта требуется дополнительная сборка версии (в зависимости от применяемого производителя сертифицированной криптографии), а по второму продукту, просто не удалось найти нужную информацию. Третья проблема, в принципе, могла бы быть решена с помощью совместного использования опций TDE и Oracle Database Vault , но в этом случае полномочия администратора СУБД плавно перетекают к администратору Database Va u lt, т.е. проблема защиты от привилегированных пользователей сохраняется.

Хранение ключевого материала

Ключевой материал (сертификаты, закрытые ключи, ключи шифрования), используемые встроенными средствами обеспечения безопасности Oracle для аутентификации или шифрования данных, хранятся в ключевых контейнерах, (т.н. бумажниках - wallets) как обычные файлы. Для доступа к информации в бумажнике требуется пароль. Часто такой способ хранения не отвечает требования по безопасности, особенно на рабочих станциях клиентов. СУБД Oracle , начиная с версии 10g, позволяет хранить закрытые ключи на аппаратных устройствах, поддерживающих стандарт PKCS#11. В то же время Oracle никак не гарантирует работу аппаратных устройств, отличных от устройств производства nCipher (nCipher Corporation Ltd.). Это не всегда приемлемо, например, если предполагается использование только сертифицированных аппаратных средств. И в этом случае проблема хранения ключей и сертификатов может быть решена с помощью решений сторонних производителей. На российском рынке, пожалуй, единственным в своем классе продуктом является eToken SecurLogon для Oracle (Aladdin Software Security R.D.) .

Заключение

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

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

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

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

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

Разрушение и потеря данных в базе могут быть вызваны рядом причин:

· сбои оборудования;

· физические воздействия на аппаратные средства базы данных;

· стихийные бедствия;

· ошибки санкционированных пользователей;

· умышленные вредоносные действия несанкционированных пользователей или программ;

· программные ошибки СУБД или операционной системы;

· ошибки в прикладных программах;

· совместное выполнение конфликтных запросов пользователей и др.

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

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

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

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

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

Базы данных, также как и компьютерные программы, приравниваются к литературным произведениям и при соблюдении ряда условий могут являться объектами авторского права, что предусмотрено в статье 7 «Закона об авторском праве Республики Беларусь». Если база данных признается объектом авторского права, то это означает, что ей предоставляется охрана гражданским, административным и уголовным законодательством, как и любому другому объекту авторского права. Авторское право на базу данных не связано с авторским правом на компьютерную программу, с помощью которой осуществлялся доступ к данным и их обработка.

Меры администратпивно- организационного уровня. Администрация организации должна сознавать необходимость поддержания режима безопасности и выделения на эти цели соответствующих ресурсов. Основой мер защиты административно-организационного уровня является политика безопасности и комплекс организационных мер.

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

· управление персоналом;

· физическая защита;

· поддержание работоспособности;

· реагирование на нарушения режима безопасности;

· планирование восстановительных работ.

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

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

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

Для подтверждения подлинности пользователя существуют три последовательные процессы:

· Идентификация -это процесс распознавания пользователя по его идентификатору (логин и пароль).

· Аутентификация - это процесс подтверждения достоверности идентификатора пользователя. Процесс может быть, например, реализована секретным выражением.

· Авторизация - предоставление пользователю только тех данных, на которые он имеет право, т. е. разграничение прав доступа.

Главное достоинство защиты с помощью логина и пароля – простота и привычность. Надежность парольной защиты основывается на хранении их в тайне. При использовании пароля желательно соблюдать следующие требования:

· пароль должен состоять из комбинации букв и цифр или специальных знаков;

· длина пароля должна быть не менее шести символов, пароль не должен содержать пробелы

· пароли должны часто изменяться.

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

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

База данных может быть зашифрована и храниться на диске в зашифрованном виде.

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

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

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

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