Организация управления правами доступа в современных субд oracle10g и ms sql server 2008

Вид материала

Содержание

Глава 2. Управление правами доступа в MS SQL Server 2008
2.1 Пользователь и пароль

Подобный материал:

1 2 3 4 5

Глава 2. Управление правами доступа в MS SQL Server 2008

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

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

2.1 Пользователь и пароль

2.1.1 Хранение информации о пользователе и пароле

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

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

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

- Сохранить имя и пароль в реестре и заставить ваше приложение извлекать его оттуда.

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

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

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

2.1.2 Настройки безопасности

При использовании встроенных средств, вам доступны только два варианта настройки безопасности под SQL Server. Ранее, до версии 7.0, вариантов выбора было три. Поэтому, исключительно из соображений совместимости, приведем все три разновидности механизма контроля безопасности, существовавших в SQL Server 6.x.

- Интегрированная система безопасности Win NT/2000 - пользователь регистрируется в самой NT-системе, а не в SQL Server, Аутентификация осуществляется через доверительное соединение NT.

- Стандартная система безопасности: пользователь подключается к SQL Server независимо от входа в ОС NT. Аутентификация производится самим SQL Server.

- Смешанная система безопасности: окружение, в котором часть пользователей использует интегрированную систему безопасности NT, а другие - стандартную систему безопасности.

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

- интегрированная система безопасности NT (или Win 2000);

- смешанная система безопасности NT и SQL Server.

Теперь вы не сможете воспользоваться старой системой безопасности опирающейся исключительно на SQL Server.

Давайте же рассмотрим две доступные опции безопасности для SQL Server версии 7.0 и выше.

2.1.3 Система безопасности SQL Server

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

Используя систему безопасности SQL Server, вы создаете регистрационное имя пользователя, абсолютно не связанное с вашим сетевым именем и паролем.

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

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

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

- в прошлом ее гораздо легче было поддерживать, чем смешанную систему безопасности или интегрированную систему безопасности NT.

Справедливости ради приведем некоторые контраргументы:

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

- два регистрационных имени требуют больших затрат на поддержку со стороны администратора;

- с паролями можно легко запутаться, что может привести к полному хаосу. (Не кажется ли вам знакомым вопрос: "Так, посмотрим, какой пароль нужен для этого

имени?").

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

Вы вряд ли пожелаете каждый день входить, используя регистрационное имя sa. Почему? Я думаю, вам хватит пары минут, чтобы представить, что вы в состоянии натворить, воспользовавшись абсолютными правами доступа бюджета sa. Абсолютный доступ означает, что вы можете делать что угодно, и случайно примененный операнд DROP TABLE немного не к той базе данных, сделает именно то, о чем вы его попросили - удалит таблицу!!! Вам останется только воскликнуть: "Ой, что я наделал!".

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

2.1.4 Создание нового регистрационного имени в SQL Server

Существующие способы создания нового регистрационного имени в SQL Server:

- при помощи хранимой процедуры sp_addlogin;

- при помощи Enterprise Manager;

- используя инструментальные средства управления средой Windows (Windows Management Instrumentation - WMI).

sp_addlogin

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

EXEC sp_addlogin [@loginame =] <'регистрационное имя'>

[,[@passwd =] <'пароль'>

[,[@defdb =] <'база_данных'>

[,[@deflanguage =] <'язык'>

[,[@sid =] 'sid'

[,[@encryptopt =] <'опция_шифрования'>

Параметр	Описание
@loginame	Здесь задается регистрационное имя, используемое впоследствии
@passwd	Пароль, который будет использоваться вместе с вышеупомянутым именем
@defdb	Назначаемая по умолчанию база данных. В данном параметре задается первая база данных, к которой получает доступ пользователь при подключении к системе. Обычно, в ее качестве выступает главная база данных, используемая приложением. Именно она назначается, если данная опция не определена явно (чаще всего вы не захотите, чтобы пользователь попадал непосредственно в главную базу данных, поэтому не забудьте указать значение опции)
@deflanguage	Язык пользователя по умолчанию. Данный параметр может применяться для переопределения стандартного языка системы, если ваше приложение поддерживает локализацию
@sid	Двоичное число, которое будет использоваться в качестве системного идентификатора (system identifier — SID) для данного имени пользователя. Если вы не зададите SID, SQL Server сгенерирует его для вас автоматически. Поскольку должна обеспечиваться уникальность SID, любой SID, задаваемый вами, не должен совпадать с уже имеющимся в системе. Иметь дело с собственноручно определенными SID может быть удобно при восстановлении базы данных с другого сервера или при ином переносе регистрационной информации
@encryptopt	Регистрационное имя пользователя и пароль хранятся в таблице sysusers главной базы данных приложения. Опция @encryptopt определяет в каком виде эта информация находится в главной базе данных - зашифрованном или нет. По умолчанию (или при задании значения NULL для этой опции) пароль хранится в зашифрованном виде. Другие возможные опции - skip_encryption, означающая, что пароль зашифрован не будет; и skip_encryption_old, которая используется исключительно для обеспечения совместимости при резервном копировании

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

sp_password

После создания учетной записи для пользователя вам может понадобиться механизм изменения пароля. Если вы хотите осуществлять смену пароля в T-SQL, то можете сделать это при помощи хранимой процедуры sp_password. Ее синтаксис очевиден:

sp_password [[@old =] <'старый пароль'>,]

[@new =] <'новый пароль'>

[, [@loginame =] < ' имя пользователя'>]

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

2.1.5 Интегрированная система безопасности Windows NT

Что такое система безопасности Windows NT?

Система безопасности NT представляет собой модель, в которой используются существующие в доменах NT бюджеты (учетные записи) пользователей или их групп и им предоставляются права непосредственного доступа к SQL Server, вместо того, чтобы заставлять их заводить отдельные пароли и имена для получения соответствующих прав. Рассмотрим несколько примеров как для T-SQL, так и для Enterprise Manager.

Предоставление доступа к пользовательским бюджетам NT.

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

sp_grantlogin [@loginame=] '<имя_домена>\<имя_пользователя_в_NT>'

Зачем использовать систему безопасности NT?

До версии 7,0 интегрированную систему безопасности NT воспринимали как какую-то запоздалую мысль. Она являлась изгнанником, которого никто не принимал всерьез. Начиная с версии 7.0, появилась возможность по-настоящему использовать эту систему. Корпорация Microsoft продолжала настаивать на переходе большего количества серверов к интегрированной системе безопасности NT. С приходом эры Windows 2000 точка зрения пользователей действительно переместилась в сторону безопасного интегрированного окружения. И это не лишено смысла - чем меньшее количество регистрационных имен используется, тем надежнее и проще обеспечивать безопасность, особенно при длительной работе.

Система безопасности NT позволяет:

- осуществлять контроль всех прав пользователя из одного места;

- предоставлять права доступа к SQL Server при помощи простого добавления пользователя к группе NT (это означает, что в большинстве случаев вам даже не придется заходить на SQL Server для присвоения прав пользователю);

- вашим клиентам достаточно будет помнить только одно имя и пароль.

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

Blog