Реализация системы защиты в MS SQL Server

Система управления базами данных Microsoft SQL Server 2000 имеет разнооб­разные средства защиты данных.

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

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

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

- аутентификация;

- учетная запись;

- встроенные роли сервера.

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

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

- фиксированная роль базы данных;

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

- роль приложения.

Компоненты структуры безопасности. Фундаментом системы безопасности SQL Server 2000 являются учетные записи, пользователи, роли и группы.

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

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

К средствам Transact-SQL, используемым для управления системой безопасно­сти, относится хранимая процедура sp_addlogin. С помощью этой процедуры можно создать новую учетную запись SQL Server.

Хранимая процедура sp_grantlogin позволяет разрешить доступ к SQL Server для пользователя или группы Windows NT.

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

При создании базы данных определяются два стандартных пользователя: dbo и guest. Если учетная запись пользователя явно не отображается в пользователя базы данных, пользователю предоставляется неявный доступ с использованием гостевого имени guest. Обычно пользователю guest предоставляется минимальный доступ в режиме «только чтение».

Для обеспечения максимальной безопасности можно удалить пользователя guest из всех        баз данных, кроме системных баз данных master и tempdb.

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

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

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

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

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

В SQL Server реализованы два вида стандартных ролей: на уровне сервера и на уровне баз данных. При установке SQL Server 2000 создается 9 фиксированных ролей сервера и 9 фиксированных ролей базы данных. Эти роли нельзя удалить. Кроме того, нельзя модифицировать права их доступа.

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

В роль базы данных можно включать:

- пользователей SQL Server;

- роли SQL Server;

- пользователей Windows NT;

- группы Windows NT, которым предварительно предоставлен доступ к нужной базе данных.

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

Кроме указанных выше ролей существует еще одна — public. Эта роль имеет спе­циальное назначение, поскольку ее членами являются все пользователи, имею­щие доступ к базе данных. Нельзя явноустановить членов этой роли, потому что все пользователи и так автоматически являются ее членами. Рекомендуется использовать эту роль для предоставления минимального доступа пользователям, для которых права доступа к объектам не определены явно. Если в базе данных разрешен пользова­тель guest, то установленный для роли public доступ будут иметь все пользовате­ли, получившие доступ к SQL Server. Роль public имеется во всех базах данных, включая системные базы данных master, tempdb, msdb, model, и не может быть удалена.

Роли приложения. Система безопасности SQL Server реализована на самом низком уровне — уров­не базы данных. Это наилучший, наиболее действенный метод контроля деятель­ности пользователей независимо от приложений, используемых ими для подклю­чения к SQL Server.

Отличия между стандартными ролями и ролями приложения фундаментальны. Роль при­ложения не имеет членов, то есть пользователи SQL Server или Windows NT не могут быть добавлены в эту роль. Роль активизируется, когда приложение уста­навливает соединение. Пользователь, работающий в это время с приложением, не является членом роли — только лишь его приложение использует установлен­ное соединение.

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

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

Перед установлением соединения с использованием роли приложения пользова­телю сначала нужно получить доступ к SQL Server.

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

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

Шифрование данных. Шифрование — это метод, используемый SQL Server для изменения данных до нечитабельной формы. Шифрование гарантирует, что ценная конфиденциальная информация не будет просмотрена кем бы то ни было. Можно скопировать данные, но нельзя будет с ними ничего сделать. Для просмотра данных авторизированными пользователями используется дешифрирование.

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

- любые данные, передаваемые между сервером и клиентом по сети;

- пароли учетных записей SQL Server или ролей приложения;

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

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

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

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

SQL Server обеспечивает ограничение доступа к файлам системы.

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

Права в базе данных SQL Server можно разделить на три категории:

- права на доступ к объектам баз данных;

- права на выполнение команд Transact-SQL;

- неявные права (разрешения).

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

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

Важно быть осторожным с предоставлением разрешений на доступ к данным. Необходимо внимательно контролировать права доступа, выдаваемые пользовате­лю как непосредственно, так и через членство в группах Windows NT и ролях SQL Server. Особенно это касается больших систем с тысячами пользователей и десятками групп.

Права на доступ к объектам баз данных. Работа с данными и выполнение хранимых процедур требуют наличия класса доступа, называемого правами на доступ к объектам баз данных. Под объектами подразумеваются таблицы, столбцы таблицы, представления, хранимые проце­дуры. Права на доступ к объектам баз данных контролируют возможность вы­полнения пользователями, например, команд SELECT, INSERT, UPDATE и DELETE для таблиц и представлений. Таким образом, если пользователю необходимо доба­вить новые данные в таблицу, ему следует предоставить право INSERT (вставка записей в таблицу). Предоставление же пользователю права EXECUTE разрешает ему выполнение каких-либо хранимых процедур и функций.

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

- SELECT, INSERT, UPDATE, DELETE, REFERENCES - эти права могут быть применены для таблицы или представления;

- SELECT и UPDATE — эти права могут быть применены к конкретному столбцу таб­лицы или представления;

- INSERT и DELETE — эти права применяются для таблицы или представления;

 - EXECUTE — это право применяется только к конкретным хранимым процедурам и функциям, разрешая пользователю их выполнение.

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

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

Для управления разрешениями пользователя на до­ступ к объектам базы данных используется команда GRANT, которую мы рассматривали ранее.

В дополнение к рассмотренному в команде указывается имя того объекта системы безопасности, который необходимо включить в роль. В качестве таких объектов могут выс­тупать как учетные записи SQL Server, так и пользователи и группы пользова­телей Windows NT, которым предоставлен доступ к серверу баз данных.

Права на исполнение команд Transact-SQL. Этот класс прав контролирует возможность создания объектов в базе данных, создания самой базы данных и выполнения процедуры резервного копирования.

Неявные права. Выполнение некоторых действий не требует явного разрешения и доступно по умолчанию. Третий класс прав как раз предоставляет такие действия. Эти действия могут быть выполнены только членами ролей сервера или владельцами объектов в базе данных.

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

Аналогичная ситуация получается и с ролями сервера.

Для конкретного действия, контролируемого разрешением, возможны три вари­анта состояния доступа: предоставление, запрещение и неявное отклонение.

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

Параметры данной команды аналогичны параметрам команды GRANT. Использо­вание параметра CASCADE позволяет отзывать права не только у данного пользо­вателя, но также и у всех тех пользователей, кому он предоставил данные права.

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

REVOKE [GRANT OPTION FOR]

{ALL | PRIVLEGES}

<колонки_таблицы>

…………….

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

Неявное отклонение доступа позволяет более гибко конфигурировать систему без­опасности.

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

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