Компоненты структуры безопасности

Фундаментом системы безопасности SQL Server являются учетные записи (login), пользователи (user), роли (role) и группы (group). _t

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

· учетная запись Windows NT;

· группа Windows NT;

· учетная запись SQL Server.

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

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

 

Пользователи

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

При создании базы данных определяются два стандартных пользователя: dbо и guest.

Если учетная запись (login) не связывается явно с пользователем (user), по­следнему предоставляется неявный доступ с использованием гостевого имени guest. То есть все учетные записи, получившие доступ к SQL Server, авто­матически отображаются в пользователей guest во всех базах данных. Если вы удалите из базы данных пользователя guest, то учетные записи, не имеющие явного отображения учетной записи в имя пользователя, не смогут получить доступа к базе данных. Тем не менее, guest не имеет автоматического доступа к объектам. Владелец объекта должен сам решать, разрешать пользователю guest этот доступ или нет. Обычно пользователю guest предоставляется минималь­ный доступ в режиме «только чтение».

 

 

Рис. 1. Взаимосвязь атрибутов пользователя в SQL Server.

Роли сервера

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

Стандартные роли сервера (fixed Server roles) и их права:

Sysadmin – Может выполнять любые действия в SQL Server.
Serveradmin – Выполняет конфигурирование и выключение сервера.

Setupadmin – Управляет связанными серверами и процедурами, автоматически запускающимися при старте SQL Server.

Securityadmin – Управляет учетными записями и правами на создание базы данных, также может читать журнал ошибок.

Processadmin – Управляет процессами, запущенными в SQL Server.

Dbcreator – Может создавать и модифицировать базы данных.

Diskadmin – Управляет файлами SQL Server.

Bulkadmin – Члены роли Bulkadmin могут вставлять данные с использованием средств массивного копирования, не имея непосредственного доступа к таблицам.

Роли баз данных

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

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

· Пользователей SQL Server;

· Роли SQL Server;

· Пользователей Windows NT;

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

Режимы аутентификации

SQL Server может использовать два режима аутентификации пользователей:

· режим аутентификации средствами Windows NT/2000 (Windows NT Authentication);

· смешанный режим аутентификации (Windows NT Authentication and SQL Server Authentication).

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

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

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

Аутентификация Windows предоставляет решение Single Sign-On (SSO) для пользователей Windows, снижая количество паролей, которые требуется запомнить, что снижает вероятность записи их куда-либо. Вдобавок, аутентификация Windows может воспользоваться преимуществами групп Windows для безопасности. Интеграция с Windows означает, что SQL Server 2005 может воспользоваться политиками безопасности, применяемым к доменным учётным записям Windows, такими как сложность пароля и срок действия пароля. Так как та же парольная политика используется в домене Windows, имеются согласованные парольные политики в вычислительной среде. Аутентификация Windows также пользуется преимуществами защищенных протоколов аутентификации, которые используются пользуется в домене, что снижает вероятность записи их куда-либо.ли у организации нет процес Windows, таких как Kerberos и NT LAN Manager (NTLM), которые шифруют пароль при передаче по сети.

1.7 Преимущества режима аутентификации Windows NT

1. Пользователю достаточно помнить только один пароль - для входа в Windows.

2. Повышается уровень безопасности SQL Server. Это происходит, по крайней мере, из-за того что, пароль не будет передаваться открытым текстом по сети, как это происходит по умолчанию при использовании команд CREATE LOGIN и ALTER LOGIN. Тем более хэши Windows намного более защищенные, чем хэши в SQL Server, которые можно вскрыть достаточно быстро.

3. Проверка при входе пользователя производиться значительно быстрее.

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

5. Эти преимущества справедливы для любых логинов Windows: как для обычных учетных записей, так и для групп, но идеальный вариант использовать все-таки группы, причины просты:

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

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

1.8 Шифрование

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

1.9 Сетевое шифрование

SQL Server во всех редакциях может шифровать сетевой трафик при помощи множества средств, типа IP Security (IP SEC) и Secure Sockets Layer (SSL).В SQL Server поддерживаются два широко используемых сетевых стандарта в качестве альтернатив шифрованию данных, передаваемых по сети: SSL and IP SEC. Эти протоколы поддерживаются Windows. SSL поддерживается через интеграцию SQL Server с Internet Information Services (IIS) или через сервер сертификатов, входящий в состав SQL Server.

SQL Server поставляется со своей собственной службой сертификатов для настройки сетевого шифрования по SSL. Сертификаты создаются внутри SQL Server и соответствуют стандарту X.509v3. Сертификаты используются SQL Server для создания SSL соединений, а также они используются службой SQL Service Broker.

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

IP SEC также поддерживается Windows как шифрованный канал для сетевых соединений.

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

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

EncryptByCert

DecryptByCert

EncryptByKey

DecryptByKey

EncryptByAssym

DecryptByAssym

Эти функции позволяют использовать существующий сертификат для шифрования данных (наиболее безопасный метод), простой ключ (пароль) или ассиметричный ключ (пару открытый/закрытый ключ). SQL Server может создавать и управлять своими сертификатами для обеспечения очень мощного шифрования данных, хранимых в базе данных. Transact - SQL в SQL Server был улучшен для поддержки управления сертификатами:
Создание сертификата:

CREATE CERTIFICATE MyCert

WITH SUBJECT = ‘My Subject’,

ENCRYPTION PASSWORD = ‘jfdsij380fukanfjcxvDJEOD#$fksdwr’,

EXPIRY_DATE = ‘12/31/2009’;

После того, как сертификат создан, можно использовать функцию EncryptByCert для шифрования значения и сохранения результата в переменной:

DECLARE @VAL nvarchar(8000)

SELECT @VAL = EncryptByCert(Cert_ID(‘MyCert’), N’Some Message’)

Далее можно прочесть это значение из поля или переменной при помощи функции DecryptByCert:

SELECT CAST(DecryptByCert(Cert_ID(‘MyCert’), @VAL, N’ jfdsij380fukanfjcxvDJEOD#$fksdwr’) AS nvarchar)

1.11 Реализация доступа к серверу и базе данных

Итак, гораздо более удобным и эффективным является подход, когда доступ к SQL Server 2008 предоставляется целым группам пользователей. Как раз такой под­ход возможен при аутентификации средствами Windows NT/2000, когда на уровне домена создает­ся несколько групп, каждая из которых предназначена для решения специфических задач. На уровне SQL Server 2008 такой группе разрешается доступ к серверу, предоставляются необходимые права доступа к базам данных и их объектам. Достаточно включить учетную запись Windows NT в одну из групп, и пользователь получит все права доступа, предоставленные этой группе. Более того, одна и та же учетная запись может быть включена во множество групп Windows NT, что даст этой учет­ной записи возможность пользоваться правами доступа, предоставленными всем этим группам. Администратор SQL Server 2008 должен сам решить, как удобнее предоставлять доступ к серверу: персонально каждой учетной записи или группе в целом.

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

Приложение запускается на некотором компьютере пользователя сети университета, если этот пользователь входит в домен организованный администраторами сети университета, то он успешно аутентифицируется в Windows. Чтобы он мог получить доступ к SQL серверу необходимо при установке SQL Server, и с помощью SQL Server Management studio настроить режим аутентификации – режим аутентификации средствами Windows NT\2000.

Теперь нужно завести в SQL Server учетные записи (логины) для пользователей которым необходимо получать доступ SQL Server, но сначала удобнее на уровне Windows средствами администрирования Active Directory объединить пользователей нуждающихся в доступе к SQL Server в группы, в зависимости от того какие цели преследуют данные пользователи. У нас будут три группы пользователей:

· Преподаватели

· Старосты

· Студенты

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

 

II. Практическая часть