Основы системы безопасности SQL Server

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

Модель безопасности SQL Server 7.0 значительно изменилась по сравнению с предыдущими версиями продукта - она больше напоминает систему безопасности Windows 2000 и NT. Я рекомендую SQL Server 7.0 всем компаниям, которые используют SQL Server 6.5, но не имеют профессионального администратора DBA, потому что с ней работать гораздо проще. При подготовке статьи была использована СУБД SQL Server 7.0 на NT 4.0, но все рекомендации относятся и к Windows 2000. Этот материал актуален и для SQL Server 2000, и для SQL Server 7.0, поскольку между ними нет существенных различий, за исключением нескольких диалоговых окон с обозначением «Windows NT/2000» вместо «Windows NT».

Уровни и режимы защиты

В SQL Server предусмотрено три уровня безопасности. Во-первых, пользователи должны быть зарегистрированы в SQL Server или иметь действительную учетную запись в NT, с правом доступа SQL Server. Регистрация в SQL Server не дает пользователям права обращаться ни к одной из баз данных SQL Server. Разрешение на доступ к БД выдается пользователям на втором уровне защиты. На третьем уровне администратор может назначать права доступа к объектам в базе данных; например, можно указать, какие таблицы и представления данных открыты пользователю и какие хранимые процедуры могут выполнять члены группы. Те же три уровня безопасности предусмотрены в Windows 2000 и NT, поэтому знания о системе безопасности Windows применимы и к SQL Server.

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

Чтобы проверить или изменить режим безопасности для системы SQL Server, следует открыть оснастку SQL Server Enterprise Manager консоли Microsoft Management Console (MMC), щелкнуть правой кнопкой мыши на имени сервера и выбрать пункт Properties. Затем нужно выбрать закладку Security, как показано на Экране 1. Чтобы изменить режим безопасности, необходимо остановить и перезапустить SQL Server (заново перезагружать компьютер не требуется). В программной папке SQL Server есть утилита Service Manager, которой можно воспользоваться для остановки и перезапуска службы SQL Server, а также перезапуска службы SQL Server Agent (при остановке сервера останавливается и агент).

Экран 1. Выбор метода аутентификации в смешанном режиме.

Процедуры регистрации SQL Server Logins и роли Server Roles

В SQL Server 7.0 группе NT можно назначить соответствующую учетную запись SQL Server. Назначать учетную запись для каждого пользователя не нужно. Члены группы NT, которая имеет право обращаться к SQL Server, могут установить соединение, не вводя имя и пароль. SQL Server отслеживает пользователей по индивидуальным идентификаторам NT SID, а не по групповым SID, поэтому определить автора конкретного изменения в SQL Server можно, даже работая с группами, а не с отдельными пользователями. Новые пользователи группы NT автоматически получают доступ к SQL Server, а пользователи, удаленные из группы, теряют права доступа к базе данных.

Учитывая возможные связи между группами NT и SQL Server, для организации защиты SQL Server прежде всего необходимо продумать стратегию доступа групп и пользователей NT. Следует организовать глобальные группы и распределить пользователей по группам точно так же, как при назначении разрешений в NTFS. Затем, чтобы задать учетную запись SQL Server для группы, следует открыть оснастку SQL Server Enter-prise Manager. Если параметры безопасности SQL Server установлены по умолчанию, то администратор NT может зарегистрироваться в SQL Server как DBA.

В левой панели окна Enterprise Manager следует открыть папку Microsoft SQL Servers, развернуть группу SQL Server Group, потом элемент для сервера, в котором нужно задать учетную запись, и затем папку Security. Далее я расскажу, как с помощью элемента Logins установить соответствие между группами и пользователями NT и учетными записями SQL Server и как назначать имена и пароли пользователям ОС отличных от Windows.

Сразу же под Logins находится элемент Server Roles. Прежде чем добавлять учетные записи, следует щелкнуть на Server Roles и познакомиться с различными ролями (см. Экран 2). Эти роли похожи на специальные локальные группы NT (например, операторы сервера и операторы резервного копирования) тем, что подготовлены заранее и имеют заданные права и привилегии. Нельзя добавить новые серверные роли или изменить роли, определенные в SQL Server. Серверные роли можно рассматривать как локальные группы, в которых могут размещаться глобальные группы Windows.

Экран 2. Знакомство с серверными ролями SQL Server.

Открыв диалоговое окно с закладками двойным щелчком мыши на конкретной роли, можно просмотреть список имеющихся пользователей, дополнить его новыми именами и просмотреть полномочия роли. Роль System Administrators соответствует «суперпользователю», который имеет право выполнять любые операции с SQL Server. Эту роль следует отвести тому, кто действительно нуждается в административных полномочиях высшего уровня. Программистам нужно назначить роль Database Creators, чтобы они могли строить тестовые базы данных. Младшим администраторам можно отвести роли Security Administrators и Server Administ-rators, чтобы они могли управлять свойствами и безопасностью сервера, не имея всех прав системного администратора.

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

Чтобы назначить учетную запись группе или пользователю NT, нужно щелкнуть правой кнопкой мыши на Logins и выбрать New Login, открыв диалоговое окно SQL Server Login Properties - New Login, как показано на Экране 3. На закладке General требуется ввести с клавиатуры имя. Список, откуда можно было бы выбрать имена групп или пользователей NT, отсутствует. Это упущение исправлено в SQL Server 2000, но пока имя придется ввести вручную. Если указаны группа или пользователь NT, то из раскрывающегося списка следует выбрать имя домена, в который входит группа или пользователь. После этого имя домена также появится в поле Name, уточняя введенное имя группы или пользователя.

Экран 3. Назначение процедуры регистрации SQL Server.

Закладка General используется также для разрешения или запрета доступа к SQL Server. Если один из членов группы не должен иметь доступа к SQL Server, то можно предоставить право на доступ группе, отказав в нем одному лицу. Как и в NT, любой запрет доступа отменяет все полномочия, полученные пользователем индивидуально или в составе группы.

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

Доступ к базам данных

Второй уровень защиты SQL Server - управление доступом к базам данных. SQL Server позволяет работать с несколькими БД на сервере, поэтому, вероятно, администратор пожелает разрешить большинству пользователей доступ к одним базам данных, но запретить обращение к другим. Учетная запись в SQL Server не дает права на доступ к БД до тех пор, пока данной учетной записи не присвоено право доступа к этой базе данных. К решению этой задачи можно подойти со стороны пользователя или со стороны базы данных. С помощью диалогового окна Login Properties пользователя можно зарегистрировать в нескольких базах данных. Ими же можно обратиться к базе данных, открыть диалоговое окно New Database User и добавить учетные записи тех пользователей, которым необходим доступ к базе данных. На Экране 4 показано, как предоставить пользователю право на доступ к одной или нескольким базам данных с помощью закладки Database Access диалогового окна Login Properties.

Экран 4. Предоставление пользователю права доступа к базе данных.

Добавляя учетные записи пользователей базы данных, их можно помещать в роли БД - новая возможность, реализованная в SQL Server 7.0. Роли базы данных, подобно серверным ролям, можно рассматривать как аналог локальным группам, в которые помещаются учетные записи SQL Server, в свою очередь, похожие на глобальные группы Windows. Роль базы данных, как и серверная роль, наделена набором заранее определенных полномочий. Полномочия можно предоставить непосредственно пользователям, но во многих случаях простое назначение пользователю соответствующей роли дает ему все нужные права. Пользователь может быть членом нескольких групп и накапливать полномочия различных ролей. Запрет, полученный в любой роли, отменяет все полномочия остальных ролей. Как и серверные роли, заранее определенные роли базы данных изменить нельзя. Можно создавать роли баз данных с любыми полномочиями, но обычно администраторы стараются комбинировать существующие роли, чтобы обеспечить пользователю именно тот уровень доступа, который ему нужен. Принадлежность роли можно изменить в любой момент; задавая учетную запись в базе данных, нет необходимости назначать ей все роли.

Общая роль public базы данных похожа на Everyone в NT. SQL Server помещает в эту роль любую учетную запись, которой разрешен доступ к базе данных. Нельзя удалить пользователей из этой роли или уничтожить саму роль. По умолчанию, роль public не имеет прав доступа ни к одной из созданных администратором БД. Исключение составляет база данных Northwind, изображенная на Экране 4; это тестовая база данных, и предполагается, что информацию в ней могут просматривать все желающие.

Учетные записи пользователей, которым необходимо получать информацию из базы данных, помещаются в роль db_datareader. Учетные записи пользователей, которым требуется изменять данные, должны быть включены как в роль db_datareader, так и в роль db_datawriter. Если нужно предоставить право доступа к базе данных всей группе, кроме одного из ее членов, можно поместить учетную запись SQL Server для группы в роли db_datareader и db_datawriter, а учетную запись «отказника» - в роли db_denydatareader и db_denydatawriter.

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

Администратор может пожелать делегировать часть своих полномочий по управлению базой данных. Две роли базы данных передают ограниченные полномочия любому члену этих ролей. Член роли db_accessadmin может добавить существующую учетную запись SQL Server к базе данных в качестве пользователя. Затем член роли db_securityadmin может назначить любому пользователю базы данных конкретные полномочия по отношению к таким объектам, как таблицы и представления. Если нужно, чтобы один человек выполнял обе задачи, его можно зарегистрировать в обеих ролях.

Роль db_backupoperator концептуально не отличается от группы NT Backup Operator. Члены этой роли могут читать базу данных только для резервного копирования и не имеют других прав доступа к данным. Роль db_backupoperator дает право на создание резервной копии данных, но не на ее восстановление. Это задача для DBA или владельца базы данных.

Для работы с тестовой или проектируемой базой данных, а также в случае, если программисты вносят изменения в рабочую базу данных, следует использовать роль db_ddladmin. Члены этой роли могут создавать, изменять и удалять объекты базы данных. В роль db_owner никого включать не требуется. Каждый объект SQL Server имеет владельца, и по умолчанию владельцем базы данных становится пользователь, создавший ее.

С помощью оснастки SQL Server Enterprise Manager нельзя выяснить полномочия каждой роли базы данных. Объяснения ролей приведены в оперативном руководстве SQL Server Books Online (BOL). Доступ к BOL можно получить из программной папки SQL Server 7.0 или с помощью подсказок Help в Enterprise Manager. Если заранее определенных ролей недостаточно, администратор может либо назначить полномочия непосредственно пользователям, либо ввести собственные роли базы данных, наделить их необходимыми полномочиями и затем назначить пользователей для этих ролей. Чтобы добавить роль из Enterprise Manager, нужно развернуть базу данных, щелкнуть правой кнопкой мыши на Roles и выбрать пункт New Database Role. В диалоговом окне следует ввести имя новой роли, выбрать пункт Standard Role и перечислить пользователей, чьи учетные записи должны быть включены в эту роль. Прежде чем определять полномочия, необходимо выйти из диалогового окна и создать роль. Затем следует дважды щелкнуть на роли и назначить полномочия. Безусловно, к этой операции можно вернуться позднее и изменить как состав роли, так и назначенные ей права.

Задание полномочий

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

Чтобы назначить полномочия пользователю, следует раскрыть дерево в SQL Server Enterprise Manager и выбрать элемент Users для нужной базы данных. В правой панели требуется дважды щелкнуть на имени пользователя и открыть диалоговое окно Database User Properties. Чтобы вывести на экран пользовательские полномочия для объекта базы данных, нужно щелкнуть на кнопке Permissions. Диалоговое окно показано на Экране 5. Следует помнить, что в этом интерфейсе показаны лишь полномочия, предоставленные данному пользователю индивидуально. В окне не приводятся полномочия, которыми пользователь обладает как член одной или нескольких ролей или групп NT. В действительности, получить полный список полномочий пользователя в SQL Server непросто.

Чтобы предоставить пользователю право на чтение таблицы или представление данных, нужно установить флажок SELECT. Если пользователь должен изменять данные, то обычно следует отметить флажки INSERT, UPDATE и DELETE. Сотрудникам, ответственным за ввод данных, можно предоставить право вводить записи, но не изменять или удалять их. Удаление записей можно доверить более опытному сотруднику, который наделен соответствующими должностными полномочиями. Чтобы запретить пользователю удалять данные, нужно дважды щелкнуть на флажке DELETE, после чего в нем появляется красный значок X, как показано на Экране 5. Вопрос пользовательских полномочий стоит обсудить с программистами; если они встроили в приложения защитные механизмы, задействованные в процессе обновления базы данных, то, вероятно, администратору не нужно дублировать их усилия. Однако встроенные средства защиты базы данных надежнее, так как пользователь не может получить доступ к данным, обойдя или изменив приложения. Как видно из таблицы Permissions, пользователь Caesar может выбрать из таблицы Customer и добавить или обновить данные о потребителях, но не может удалить запись о потребителе. Кроме того, Caesar не в состоянии обновлять запись Employe Territories, но он может принадлежать к группе, обладающей таким правом.

Экран 5. Назначение полномочий пользователю.

В столбце EXEC таблицы Permissions указаны права на выполнение хранимых процедур. Хранимые процедуры - это составленные на языке T-SQL подпрограммы SQL Server, которые могут быть вызваны из приложений для выполнения операций в базе данных. Они весьма эффективны и обеспечивают дополнительный уровень безопасности. Если хранимые процедуры составлены, то некоторым пользователям следует предоставить право Execute для их запуска.

Как правило, столбец Declarative Referential Integrity (DRI - декларативная ссылочная целостность) можно игнорировать, если только программисты не дают иных рекомендаций. Иногда пользователь вводит данные в одну из таблиц, а SQL Server должен проверить данные в другой таблице. Например, если пользователь вводит номер элемента в таблицу заказов, то SQL Server должен обратиться к таблице продуктов для проверки введенного номера. Чтобы проверка была возможна, пользователь должен иметь полномочие Select в таблице продуктов и полномочие Insert в таблице заказов. В некоторых случаях пользователи могут нуждаться в полномочиях для ссылок на другую таблицу, чтобы проверить элемент данных, но не должны иметь права на чтение таблицы напрямую. В этих случаях пользователю необходимо вместо Select иметь полномочие DRI.

Надеюсь, что предлагаемый обзор системы безопасности SQL Server поможет читателям в разработке стратегии безопасности собственной базы данных. Следующим шагом может быть создание сценария SQL Server. Щелкнув правой кнопкой мыши на базе данных в оснастке SQL Server Enterprise Manager, следует выбрать элементы All Tasks и Generate SQL Scripts. Данная функция строит сценарий, которым можно воспользоваться для регенерации базы данных, в том числе и политики безопасности. Затем следует выяснить, как запускать сценарии в окне Query Analyzer. При необходимости можно выполнить лишь часть сценария, предназначенную для управления параметрами безопасности. С помощью сценария можно всего за несколько секунд завершить работу, выполнение которой в оснастке SQL Server Enterprise Manager заняло бы несколько часов.

Майкл Д. Рейли - внештатный редактор Windows 2000 Magazine и SQL Server Magazine, соучредитель и вице-президент компании Mount Vernon Data Systems. Его адрес: mdreilly@win2000mag.com.