Тема 9 Роли и защита данных.
Цель: Изучить назначение ролей и приложений. Познакомится с различными видами
разрешений.
Вопросы лекции:
1. Роли и приложения
2.
Защита данных.Шифрование данных
3.
Управление правами доступа к объектам базы данных.
4.
Разрешения для объектов
5.
Разрешения для команд Transact
SQL
6.
Неявные разрешения
7.
Предоставление доступа. Запрещение доступа.
8.
Резервное копирование файлов и групп файлов.
1. Система
безопасности сервер реализована на самом низком уровне базы данных. Это
наилучший, наиболее действенный метод контроля деятельности пользователей
независимо от приложения используемых ими для подключения к серверу. Тем не
менее, встречаются ситуации, когда
необходимо использовать постоянный набор прав для доступа к базе данных из
приложения. Особенно это касается работы с большими базами данных, имеющими множество сложных взаимосвязанных
таблиц с тысячами или миллионами
записей. Чаще всего для работы с такими базами данных создаются специальные приложения
, не давая возможности напрямую обращаться к данным. Например, мобильные
пользователи могут использовать специальную клиентскую программу, посредством
которой они оперируют данными, устанавливая связь с сервером через незащищенные
глобальные коммуникации.
Сервер решает
перечисленные проблемы путем использования роли приложения, создаваемой на
уровне базы данных. Отличия между стандартными ролями и ролью приложения не
имеет членов. Пользователи сервер или Windows
не могут быть добавлены в эту роль. Роль активизируется, когда приложение
устанавливает соединение. Пользователь, работающий в это время с приложением не
является членом роли. Он лишь использует установленное приложением соединение.
Перед использованием роли приложения необходимо
сначала создать ее. При создании роли укажите ее имя и пароль для доступа.
Приложение может быть спроектировано так, чтобы пользователь, работающий с ним,
должен вводить пароль для активизации роли приложения. Однако чаще всего пароль
вводится самим приложением незаметно для пользователя. Дополнительно, для
обеспечения максимальной безопасности, пароль может быть зашифрован перед своей
отправкой в сервер по сети.
В процессе подключения приложение должно
активизировать роль, передав пароль, ассоциированный с данной ролью. Когда роль
приложения активизируется, все права доступа, установленные в пределах сеанса
для пользователя, групп и ролей, теряются до окончания работы приложения.
Соединение получает права, установленные для роли приложения в базе данных, в
которой эта роль существует. Временное забывание прав доступа, присвоенных
установившему соединение пользователю, используется для избежания конфликтов
доступа. В противном случае, если пользователь имеет запрещение на чтение
данных, а приложению необходимо считать
данные, доступ был бы отклонен, так как запрещение доступа имеет преимущества
на предоставлением доступа.
Поскольку роль приложения имеет права только к той
базе данных, в которой она создается, а все разрешения для учетных записей,
групп и ролей, к которым принадлежит пользователь, теряются, то доступ к другим
базам данных возможнее только под гостевым именем guest. Следовательно, если имя guest в базе данных не существует, то соединение сможет
получить доступ к объектам базы только в том, случае, если разрешения явно
выданы для пользователя guest
Перед установлением соединения с использованием роли
приложения пользователю сначала нужно получить доступ к серверу. Для этого
можно использовать оба режима аутентификации пользователей.
Если приложение спроектировано для выполнения
различных задач с использованием разных прав доступа, необходимо создать
отдельную роль для каждой выполняемой задачи. Приложение должно само
позаботиться о переключении ролей.
2. Как бы хорошо не была спланирована система
безопасности сервера, остается возможность скопировать файлы с данными и
просмотреть их на другом компьютере. Также данные могут быть с использованием
специальных устройств перехвачены при передаче их по сети. Необходимо продумать
средства физической защиты данных. Данные в файлах хранятся в открытой форме,
т.е. их можно просмотреть в текстовом редакторе.
Шифрование – метод, используемый в SQL Server для изменения данных до
нечитаемой формы. Использование шифрования гарантирует , что ценная
конфиденциальная информация не будет просмотрена не кем бы то ни было. Вы
можете скопировать данные, но ничего не сможете сделать. Для просмотра данных
авторизированными пользователями используется дешифрование. Сервер позволяет
шифровать следующие данные:
· Любые данные, передаваемые между сервером и клиентом
по сети
· Пароли учетных записей сервера или ролей приложения
· Код хранимых процедур
· Код представлений
· Код триггеров.
Пароли учетных записей и ролей приложения всегда
сохраняются в системных таблицах сервера в зашифрованной форме. Это
предохраняет их от просмотра любым пользователем, включая администратора. Кроме
того, пароль роли приложения может быть зашифрован перед отправкой его на
сервер.
Если код триггера, представления или хранимой
процедуры содержит данные или алгоритм, которые необходимо сохранить в тайне,
используется шифрование этих данных.
Использование шифрования данных при передаче их по
сети гарантирует, что никакое приложении или устройство не сможет их
просчитать, даже если и перехватит.
Ограничение доступа к файлам сервера
В своей работе сервер создает и использует множество файлов- базы данных,
журналы ошибок, резервные копии, файлы для экспорта и импорта данных и многое
другое. Процесс, исполняющий сервер, должен иметь полный доступ к этим файлам.
Для этого необходимо предоставить соответствующие права учетным записям,
которые используются для старта сервера. Лучше всего управлять правами доступа
непосредственно на уровне файлов и каталогов. Для этого сервер должен работать
под управлением операционной системы Windows NT и иметь
файловую систему NTFS.
Если сервер стартует как служба, необходимо
предоставить полные права доступа
учетной записи пользователя, выполнившего запуск. Если для запуска сервера
используется учетная запись локальной системы, то доступ должен предоставляться
пользователю SYSTEM. С целью ограничения возможностей неавторизированного
доступа для файлов сервер необходимо установить запрет на чтение, удаление,
модификацию и исполнение всем пользователям, кроме непосредственного SQL Server.
3. Когда пользователи подключаются к SQL Server,
действия, которые они могут выполнять, определяются правами, выданными их
учетной записи, группе или роли, в которой они состоят. Пользователь должен
иметь соответствующие разрешения для
выполнения тех или иных действий. Выполнение некоторых действий не требует
явного разрешения и доступно по умолчанию. Права SQL Server можно разделить на три категории:
· Разрешения для объектов
· Разрешения для команд Transact Sql
· Неявные разрешения
Для предоставления пользователю определенного набора
прав можно использовать роли. Создав несколько ролей и предоставив им,
необходимые права доступа, администратор базы данных может просто включать
пользователей в соответствующие роли. Пользователь автоматически получает все
права доступа, определенные для роли. Стандартные роли базы данных уже имеют
определенный набор прав.
4. Работа с данными и выполнение хранимых процедур требуют наличия класса
доступа, называемого разрешениями для объектов. Разрешения для объектов
контролируют возможность выполнения команд Select, Insert, update, delete для
таблиц и представлений.
Действия
с хранимыми процедурами контролируется разрешением либо запрещением их
выполнения, предоставлением или запрещением права доступа EXECUTE. Например если пользователю необходимо добавить новые
данные в таблицу, ему следует предоставить право доступа Insert (вставка записей в таблицу)
Для
различных объектов предоставляются разные наборы разрешений.
SELECT, INSERT, UPDATE, DELETE эти разрешения могут быть применены для таблицы или
представления.
SELECT, UPDATE
эти разрешения могут применены к конкретной колонке таблицы или представления.
INSERT, DELETE
эти разрешения для таблицы или представления применимы.
EXECUTE
это разрешение применяется только к хранимым процедурам.
5. Этот класс разрешений контролирует возможность создания объектов в базе
данных и выполнения процедуры резервного копирования. Например, если
пользователю необходимо создать представление, администратор базы данных должен
предоставить пользователю право на выполнение команды Create View
Команды
Transact
Sql |
Назначение |
CREATE DATABASE |
Создание баз данных.
Разрешение применяется к самой команде |
CREATE TABLE |
Создание таблиц |
CREATE VIEW |
Создание представлений |
CREATE RULE |
Создание правил |
CREATE DEFAULT |
Создание умолчаний |
CREATE PROCEDURE |
Создание хранимых процедур |
Команд
Transact
SQL |
назначение |
BACKUP DATABASE |
Резервное копирование базы
данных |
BACKUP LOG |
Резервное копирование
журнала транзакций |
6. Третий класс разрешений контролирует действия, которые
могут быть выполнены только членами ролей сервера или владельца объектов в базе
данных. Неявные разрешения не предоставляются пользователю напрямую он получает
лишь при определенных обстоятельствах. Например, пользователь может стать
владельцем объекта базы данных, только если он сам создаст объект либо если
другой владелец передаст ему права владения своим объектом. Владелец объекта
имеет права на выполнение любых действий с объектом, а также право
предоставлять доступ к объекту другим пользователям. Эти права нигде явно не
указываются, и только факт владения объектом позволяет пользователю выполнять
любые действия.
Аналогична ситуация получается с ролями сервера.
Например, вы не можете дать конкретному пользователю права на контроль
процессов SQL SERVER. Только включив его в
роль Processadmin, можно предоставить ему эти права.
Перед тем как пользователь сможет выполнить любые
действия, администратор должен предоставить ему соответствующие права (allowing access). После создания пользователь не имеет никаких прав
доступа кроме тех, которые разрешены для специальной роли базы данных Public. Права, предоставленные этой роли, доступны для всех
пользователей в базе данных. Важно быть осторожным с предоставлением разрешений
на доступ к данным. Необходимо внимательно контролировать права доступа,
выдаваемые пользователю непосредственно, так и через членство в группах Windows NT и ролях SQL server . Особенно это касается больших систем безопасности с
тысячами пользователями и десятками групп. Вы должны быть уверены, что
существующая система безопасности позволяет пользователю выполнять любые
необходимые действия, но ограничивает доступ к информации, которая не требуется
ему для выполнения своих обязанностей.
Используйте все
возможности SQL server, контролируя права
доступа не только на уровне таблицы, но и на уровне колонке. Указывая права
доступа к конкретной колонке, вы можете более гибко управлять системой
безопасности.
Аналогичны рекомендации касаются разрешений на
выполнение команд Transact SQL. Можно спроектировать
базу данных таким образом, что определенные пользователи будут выполнять конкретные действия: создание
таблиц, представлений, правил, резервных копий и т.д.
7. Система безопасности SQL server имеет иерархическую структуру. Это позволяет ролям
базы данных включать в себя учетные записи и группы Windows NT, пользователей и роли SQL server. Пользователь же, в свою очередь, может участвовать в
нескольких ролях. Следствием, иерархической структуры системы безопасности
является то, что пользователь может одновременно иметь разные права доступа для разных ролей. Если одна из
ролей, в которых состоит пользователь, имеет разрешение на доступ к данным, то
пользователь автоматически имеет аналогичные права. Тем не менее, может
потребовать запретить возможность доступа к данным. Когда вы запрещаете
пользователю доступ к данным или командам Transact SQL, тем самым аннулируются все разрешения на доступ,
полученные пользователем на любом уровне иерархии. При этом гарантируется, что доступ останется
запрещенным независимо от разрешений, предоставленных на более высоком уровне.
Пусть,
например, вы создаете в базе данных
таблицу, доступ к которой по умолчанию предоставлен всем пользователям. Но вам
иногда необходимо временно ограничивать доступ определенных пользователей к
этой таблице. Вместо того, чтобы убирать разрешения на доступ, можно создать
роль, которой будет запрещен доступ к этой таблице, и включать пользователей в
эту роль. Проще контролировать несколько записей в роли, которая запрещает
доступ, чем манипулировать множеством разрозненных учетных записей, пытаясь
вспомнить, вернули ли вы права доступа пользователю обратно. При большом
количестве пользователей такой подход позволяет упростить администрирование
системы безопасности.
Неявное отклонение доступа.
Неявное отклонение доступа подобно запрещению доступа
с тем отличием, что оно действует только на том уровне, на котором
определено. Если пользователю на
определенном уровне неявно отклонен доступ, он все же может получить его на другом уровне иерархии через членство в роли,
имеющей право просмотра. По умолчанию
доступ пользователя к данным неявно отклонен. Это можно рассматривать как
среднее состояние между предоставлением и запрещением доступа или как
отсутствие каких-либо разрешений.
Разрешения, предоставленные роли или группе,
наследуются членами. Хотя пользователю может быть предоставлен доступ через
членство одной роли, роль другого уровня
может иметь запрещение на действия с объектом. В таком случае возникает
конфликт доступа.
При разрешении конфликта доступа сервер
руководствуется принципом, состоящим в том, что разрешение на предоставление
доступа имеет самый низкий приоритет , а запрещение доступа самый высокий. Это
значит, что доступ к данным может быть получен только явным его предоставлением при отсутствии запрещения
доступа на любом другом уровне иерархии системы безопасности. Если доступ явно
не предоставлен, пользователь не сможет работать с данными .
Выбор
стратегии резервного копирования определяется множеством факторов. Определяющие
положения:
· Чем больше объем базы данных, тем больше времени
займет процесс создания ее полной резервной копии.
· Если вы ограничены во времени, то возможно, придется
создавать копию в течение нескольких дней.
· Чем интенсивнее происходят изменения в базе данных,
тем чаще приходится выполнять резервное копирование.
· Если база
данных доступна только для чтения, будет
достаточно единственной резервной копии. В системах оперативной обработки
транзакций. (OLTP,ONLINE Transaction Processing) изменения
происходят непрерывно, поэтому резервное
копирование необходимо выполнять практически ежечасно.
8. При этом перечисленные типы определяют способ создания
копий для двух взаимосвязанных
компонентов, лежащих в основе функционирования сервер. Речь идет о самой
базе данных, хранящей объекты и данные, и о журнале транзакций, в котором
фиксируются все транзакции. Это необходимо иметь в виду при выборе стратегии
резервного копирования.
Полная копия базы данных
Создание полной копии базы данных является необходимым
условием при реализации плана резервного копирования . Полная копия
используется как отправная точка при возвращении базы данных в состояние,
непосредственного предшествующее сбою. Поэтому независимо от того, какие стратегии резервного копирования вы будете
использовать для обеспечения целостности
данных, без полной копии не обойтись
Можно прибегнуть к созданию полной копии базы данных и
в случае, когда изменения в базе не часты и их возможная потеря не имеет
особого значения. В этом случае вы получаете наиболее простой способ резервного
копирования и восстановления, который не требует от вас особых навыков.
Единственное, что необходимо принимать во внимание, в зависимости от
объема базы данных процесс копирования может потребовать много времени. Это самый
долгий из типов резервного копирования, поэтому не рекомендуется выполнять его
слишком часто. Оптимальным будет еженедельное выполнение полного резервного
копирования базы данных, хотя все, разумеется, определяется степенью активности
вашей системы.
Обратите внимание на то, что полная копия содержит все
данные, содержащиеся в базе данных на момент окончания операции резервного
копирования. Это означает, что если в
процессе копирования пользователь Marcus
произвел изменение в одной из таблиц копируемой базы данных, это изменение будет
непременно отражено в создаваемой копии.
Однако при создании полной копии не происходит
усечение журнала транзакций, и со временем это может привести к его
перевыполнению. Чтобы избежать этого, необходимо регулярно проводить усечение
журнала вручную, либо позволить серверу делать это автоматически. Для этого,
используя Enterprise Manager , установите
флажок Truncate
Log on checkpoint в окне свойств
определенной базы данных. Это приведет к тому, что лишняя часть журнала транзакций будет отбрасываться
, а все «грязные» страницы сливаться в базу данных При включенной опции Truncate Log on
checkpoint становится бесполезным
выполнение резервной копии журнала транзакций, поскольку информация о
производимых изменениях постоянно уничтожается. С другой стороны, операция
резервного копирования журнала транзакций также приводит к его усечению, и
потому при условии регулярного выполнения может рассматриваться как разумная
альтернатива автоматическому усечению.
Копия журнала транзакций Transaction Log Backup
В резервной копии журнала транзакций фиксируются все модификации данных,
произошедшие в системе с момента проведения последнего резервного копирования.
При этом не имеет значения, какой именно тип копирования имел место- копирование
базы данных или журнала транзакций. В случае последовательного выполнения
резервного копирования журнала транзакций вы получаете неразрывную
последовательность копий, содержащих историю всех модификаций данных. Копия
журнала транзакций сама по себе не представляет никакой ценности, поскольку
содержит исключительно сведения о транзакциях. Однако в сочетании с копией базы
данных она позволяет вернуть базу данных в состояние, непосредственно
предшествующее сбою. Для этого необходимо иметь неразрывную последовательность
копий журнала транзакций, которые создавались после последнего копирования базы
данных. Совместное использование двух перечисленных типов копирования нашло
широкое применение в системах оперативной обработки транзакций, где изменения
происходят очень часто и потеря даже одной транзакции неприемлема.
В отличие от полной копии базы данных, резервное
копирование журнала транзакций необходимо выполнять регулярно. В зависимости от
активности системы может потребоваться создавать несколько копий журнала в
течении рабочего дня.
Примерный график выполнения резервного копирования.
· Каждый день выполняется полное резервное копирование.
· В течении дня производится создание резервной копии
журнала транзакции каждые два часа.
Дифференциальная копия.
Дифференциальная копия базы данных содержит изменения
данных, происшедшие с момента последнего создания полной копии этой базы
данных. Благодаря этому дифференциальная
копия занимает меньше объема и требует
меньше времени для создания. Это позволяет выполнять регулярное резервное
копирование. Разных данных очень больших объемов наиболее оптимальным образом.
При дифференциальном
резервном копировании целиком
сохраняются все страницы базы данных, подвергшиеся изменениям. Однако поскольку
копия содержит исключительно изменения базы данных, в ней фиксируется только
результат этих изменений. Иначе говоря, если пользователи присваивают значения
определенным полям в таблице, а впоследствии многократно изменяют значения в
этих полях, в дифференциальную копию будут помещены значения, которые таблица
имеет на момент проведения транзакций, которая
используется для хранения всей
истории изменений.
Сочетание всех трех типов резервного копирования дает
вам практически неограниченные возможности
сохранения информации, хранящейся на сервере баз данных. Для очень
больших баз данных можно использовать следующий график резервного копирования.
· 1 раз в неделю
производить полное копирование базы данных
· каждую ночь
выполнять создание дифференциальной копии базы данных
· каждые два часа
осуществлять резервное копирование журнала транзакций
При этом дифференциальная копия содержит все
изменения, которые потерпела база данных с момента создания ее полной резервной
копии. Таким образом, для восстановления
базы данных вам достаточно всего лишь одной, самой последней дифференциальной
копии.
Резервное копирование файлов и файловых групп имеет
смысл в следующих ситуациях:
1.
с целью
уменьшения времени резервного копирования. Процесс полного резервного
копирования базы данных может занять больше времени, чем у вас имеется в распоряжении.
В этом случае можно осуществить резервное копирование в несколько этапов.
Определенная часть файлов или файловых групп, принадлежащих базе данных,
копируется в первый день, оставшаяся часть – в другой день. Таким образом, вы
получаете полную копию содержимого базы данных.
2.
В ситуации, когда
файлы и файловые группы находятся на разных физических носителях, гораздо
удобнее осуществлять их раздельное резервирование. В этом случае создаются
резервные копии для каждого физического диска. Если один из дисков, содержащих
части базы данных, будет поврежден, вам потребуется восстановить только те
файлы ил файловые группы, которые располагались на этом диске. Это может
заметно уменьшить время, необходимое для восстановления базы данных при сбое
системы.
После создания резервной копии файлов и групп файлов
обязательно требуется выполнить резервное копирование журнала транзакций. В
противном случае при сбое будет потеряна целостность данных.
Планируя частичное копирование базы данных, необходимо
иметь в виду: что в некоторых ситуациях, например при создании индекса,
необходимо выполнять одновременное копирование всех файлов, содержащих таблицы,
которые были вовлечены в процесс создания индекса. В ситуации, когда таблица и
индекс находятся в двух разных файловых группах, требуется выполнить
одновременное резервное копирование обеих файловых групп.
Литература:
1 Е. Мамаев
«Microsoft
SQL Server 2000», БХВ-Петербург, 2004г.
Контрольные вопросы:
1 Что такое роль?
2 Что такое приложение?
3 Как организовывается защита данных?
4 Опишите алгоритм шифрование данных.
5 Что такое управление правами доступа
к объектам базы данных?
6 Как организовывается
резервное копирование файлов и групп файлов?