On-Line Библиотека www.XServer.ru - учебники, книги, статьи, документация, нормативная литература.
       Главная         В избранное         Контакты        Карта сайта   
    Навигация XServer.ru






 

Создание гибкой системы безопасности MS SQL Server 7.0/2000

По материалам статьи Моррис Льюис /Morris Lewis/ на sqlmag.com “Creating a Manageable Security”

Ваша защита SQL Server должна быть простой для администрирования

В новых версиях SQL Server, появился целый набор гибких и мощных методов управления доступом пользователей к ресурсам SQL Server и базам данных. Эти нововведения вызвали некое замешательство администраторов серверов баз данных, поскольку они пробовали перенести на новую версию сервера модель защиты SQL Server 6.5. Не полное понимание отличий механизмов защиты SQL Server 7.0/2000 и SQL Server 6.5 привело к тому, что в бизнес приложениях появились «дыры» для не санкционированного доступа к данным. Прочитав эту статью, Вы сможете обеспечить такую систему безопасности SQL Server 7.0 (или SQL Server 2000) которая будет не только легко управляемой и гибкой, но и обеспечит Вам относительную безопасность доступа к данным.

Выбор схемы аутентификации

В этой статье, автор обращает внимание на принципиальное различие терминов «аутентификация» и «авторизация». Аутентификация – это подтверждение наличия прав у пользователя. Авторизация – это определение возможности допуска пользователя к операциям над объектами, к набору которых он прошёл аутентификацию. В нашем случае, аутентификация происходит тогда, когда пользователь подключается к SQL Server, а авторизация происходят всякий раз, когда пользователь пытается обращаться к данным или выполняет команды.
Первый шаг в формирование системы безопасности вы совершаете на этапе инсталляции сервера баз данных, когда выбираете механизм   аутентификации для доступа пользователей к SQL Server. Аутентификация SQL Server основана на проверке таких атрибут учётной записи пользователя, как account и password (пароль), которые хранятся в таблице Sysxlogins базы данных master. Механизм аутентификации Windows NT/2000 требует, чтобы санкционированность права доступы пользователя проверял контроллер домена. Вообще, автор рекомендует всегда использовать аутентификацию Windows NT /2000 для инсталляций, где сервер баз данных имеет сетевое подключение к контроллеру домена. Контроллер домена может быть, как Win2K, так и NT сервер, потому что в обоих случаях SQL Server анализирует специальный маркер доступа, который сопровождает список SID пользователя, сформированный в течение его аутентификации, и SID группы домена, в которую пользователь входит. Далее в статье автор показывает, как SID используется при доступе к базе данных SQL Server и при назначении разрешений к объектам сервера. Особое внимание автор обращает на то, что совершенно не важно, как ОС формирует маркер доступа. SQL Server использует SID только в маркере доступа, не обращая внимание на то, какой сервер ему эту информацию предоставляет. Вы можете использовать любые сочетания SQL Server, 2000, SQL Server 7.0, Win2K и NT. Результат будет - тот же самый.
Единственная выгода использования механизма собственной аутентификации SQL Server, это – простота её настройки через Enterprise Manager. Главный недостаток такого механизма в том, что аутентификация SQL сервера локальна для каждого сервера баз данных, что создаёт трудности в случае нескольких обслуживаемых SQL серверов. Меньший, но все еще существенный недостаток последнего механизма аутентификации в том, что Вы должны управлять разрешениями для каждой базы данных индивидуально. Если пользователь нуждается в одинаковых разрешениях для двух базах данных, Вы должны назначать эти   разрешения вручную или формировать специальный сценарий, чтобы назначать их автоматически. Если у Вас не много пользователей (меньшее 25-ти), и изменения происходят не часто, собственная аутентификация SQL Server может быть приемлема. Во всех других случаях (исключаются только случаи применения специальных прикладных программ, которые управляют защитой самостоятельно), значительные трудности администрирования и управления логинами полностью перекрывают выгоды собственной аутентификации SQL сервера.

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

Пожалуй самой большой опасностью не санкционированного доступа к данным является представление их в Web-страницах по запросу пользователей к SQL Server из интернет. Особую роль здесь приобретает организация правильной Web-аутентификации. К сожалению, типичным способом аутентификации из интернет состоит в том, чтобы внедрить логин к SQL Server и его пароль в Web-server-based программу, такую, как: Active Server Pages (ASP) или Common Gateway Interface сценарий (CGI). Сервер Web берет на себя ответственность за аутентификацию пользователя, тогда, как программа использует ее собственный логин (часто это или systems administrator или логин в Sysadmin роли сервера) чтобы обратиться к данным сервера для предоставления отчёта пользователю в интернет.
Такой подход имеет несколько уязвимостей, наиболее значительными из которых являются: полная невозможность ревизовать действия на сервере; зависимость безопасности от Web-программы; недостаточная персонализация прав пользователей при определении разрешений в SQL Server.
Если вы используете Microsoft IIS 5.0 или IIS 4.0, у Вас имеется четыре «рычага» для подтверждения прав пользователей. Первый, должен представлять собой специальную учётную запись NT сервера для анонимных пользователей, причём для каждого сайта и виртуального каталога. Все программы будут использовать этот контекст защиты при обращении к SQL серверу. Предоставляя учётной записи анонимного пользователя NT соответствующие разрешения, Вы обеспечить ревизию действий этой учётной записи средствами ОС и получите имеющиеся у NT функциональные возможности управления учётными записями.
Второй «рычаг» - это наличие у каждого сайта механизма основной аутентификации, когда пользователи из интернет должны вводить в диалоговое окно действительные имена и пароли, прежде чем IIS предоставит им доступ на чтение страницы. IIS проверяет соответствие прав доступы каждого такого логина правам в базе данных защиты NT сервера, которая может размещаться локально или на контроллере домена. Когда пользователь выполняет программу или сценарий, который обращается к SQL серверу, IIS передаёт серверу баз данных права доступу этого пользователя, допущенного к просмотру страницы. Если Вы используете такой механизм, помните, что передача имени пользователя и пароля между IIS и браузером не зашифрована и может быть перехвачена обыкновенны снифером. Поэтому, Вы должны обеспечить Secure Sockets Layer (SSL) на любом Web сайте, который использует основную аутентификацию.
Если Ваши пользователи используют Microsoft Internet Explorer 5.0/4.0 или 3.0, Вы имеете третий «рычаг»: аутентификация NT совместно с аутентификацией на Web-сайтах и виртуальных каталогах. IE передаёт IIS права доступу пользователя, зарегистрировавшегося на компьютере, а IIS использует эти права всякий раз, когда пользователь пробует обратиться к данным SQL сервера. Этим простым способом Вы можете аутентифицировать пользователей в домене удалённого сайта, если они зарегистрируются в домене, который имеет трастовые отношения с доменом Web сервера.
Наконец четвёртый «рычаг». Если ваши пользователи имеют персональные цифровые удостоверения, Вы можете отображать эти удостоверения на учётные записи NT в локальном домене. Базирующийся на той же самой технологии, что и сервер цифровых удостоверений, персональный сертификат проверяет достоверность прав пользователя и может заменить алгоритм аутентификации (Вызова/ответа) NT. В таком механизме, пользователь не должен обращаться к домену, который находится с ним в доверительных отношениях и даже может не знать ничего о домене, в котором находится IIS. Netscape navigator и IE автоматически посылают сертификаты к IIS с каждым запросом Web-страницы. В поставку IIS входит инструментарий, который позволяет администратору отображать на учётную запись NT цифровые сертификаты, заменяя обычный процесс регистрации с помощью имени и пароля.
Поскольку Вы имеете достаточно много возможностей подтверждения прав пользователей в NT, даже когда пользователи соединяются с SQL сервером из Internet и через IIS, лучше всего всегда планировать использование NT аутентификации, как основного средства подтверждения прав пользователей на доступ к серверу баз данных.

Пользователей собирайте в группы

Следующий шаг в формировании системы безопасности состоит в выделении групп, в которые будут помещены учётные записи пользователей, схожих по типу доступа к данным или объединённых использованием одного приложения. Обычно, прикладная программа имеет таких пользователей, как: операторы ввода данных, администраторы ввода данных, составители отчётов, бухгалтера, ревизоры, и администраторы доступа. Каждая группа нуждается в различных правах доступа к базе данных.
Самый простой путь администрирования разрешений доступа групп пользователей, это создание глобальной группы домена, в которую входят все группы пользователей. Вы можете создавать отдельные группы для каждой прикладной программы или создавать группы, охватывающие более широкие категории, которые у вас присутствуют. Автор предпочитает создавать группы, которые относятся к прикладным программам так, чтобы можно было точно знать, что могут делать их пользователи. Используя пример обычной бухгалтерии, Вы могли бы создать группы по именам: Accounting Data Entry Operators, Accounting Data Entry Managers, и так далее. Помните, что для простоты администрирования, длинные имена групп - это плата за понятность их назначения.
Помимо групп приложений, Вам понадобятся несколько основных, первичных групп, члены которых управляют вашими серверами. Как правило, рекомендуются следующие группы: SQL Server Administrators, SQL Server Users, SQL Server Denied Users, SQL Server DB Creators, SQL Server Security Operators, SQL Server Database Security Operators, SQL Server Developers, и DB_Name Users (где DB_Name - имя базы данных на сервере). Также, Вы можете создавать и любые другие группы, если Вы в них нуждаетесь.
После того, как Вы создали глобальные группы, Вы можете предоставлять им доступ к SQL серверу. Сначала, создайте NT логин для аутентификации группы SQL Server Users, и предоставьте необходимый минимум прав этому логину. Сделайте базой данных по умолчанию master, и не предоставляйте доступ к другим базам, или к добавлению нового логина членам других ролей сервера. Затем, повторите процесс с SQL Server Denied Users, но этой группе доступ к серверу должен быть запрещён. После того, как вы создали эти две группы, Вы получите простой способ разрешения и запрета доступа пользователей к серверу. SQL Server предоставляет доступ пользователям на уровне групп и при условии, что маркер доступа пользователя имеет соответствующее разрешение. Иначе, логину будет отказано в доступе, а также, если его лишили доступа через SQL Server Denied Users. В таком случае пользователь не сможет получить никакого доступа к серверу баз данных и к его NTFS.
Для предоставления права группам, которые не имеют явных логинов в системной таблице Sysxlogins, Вы не можете использовать Enterprise Manager, потому что он позволяет осуществлять выбор только из списка существующих логинов, а не из полного списка групп домена. Чтобы обращаться ко всем группам, используйте для предоставления необходимых привилегий Query Analyzer и хранимые процедуры sp_addsrvrolemember и sp_addrolemember. (подробности см. в SQL Server Books Online — BOL)
Для групп, объединяющих операторов серверов баз данных, используя sp_addsrvrolemember, добавьте каждый их логин соответствующей роли сервера. Логин группы SQL Server Administrators становится членом роли Sysadmins, SQL Server DB Creators становится членом роли Dbcreator, и SQL Server Security Operators становится членом роли Securityadmin. Помните, что второй параметр sp_addsrvrolemember требует полного наименования учётной записи. Например, JoeS в домене BigCo должен быть назван bigco\joes. (Если Вы используете локальные учётные записи, имя выглядело бы так: server_name\joes.).
Чтобы создавать пользователей, которые автоматически будут заводиться во всех новых базах данных, используйте базу Model. SQL Server автоматически копирует всё, что Вы создаёте для Model в новые базы данных. Это значительно упрощает работу администратора. Если Вы правильно используете Model, Вам не нужно будет настраивать каждую новую базу данных после ее создания. Далее, используя sp_addrolemember, добавьте SQL Server Security Operators к db_securityadmin, а SQL Server Developers к db_owner роли (ну, здесь можно с автором и поспорить…).
Обратите внимание, что Вы все еще не предоставили доступ ни одной группе или учётной записи к базам данных. Фактически, Вы не можете предоставить доступ к базе данных с помощью Enterprise Manager, поскольку он позволяет предоставить доступ к базам только действующим логинам. SQL Server не требует, чтобы учётная запись NT имела доступ к базе данных до включения её в одну из ролей этой базы или назначения ей объектных разрешений. К сожалению, Enterprise Manager таким ограничением обладает. В то же время, Вы можете назначать разрешения любой учётной записи в домене NT без предоставления непосредственного доступа к базе данных, используя sp_addrolemember, что не возможно с помощью Enterprise Manager.
Все описанные выше действия можно выполнить для базы Model, если ваши пользователи не относятся к общим категориям сотрудников организации в целом, которым в базе делать нечего. В таком случае, Вы можете обобщить основные задачи системы безопасности в базе Model, вместо того, что бы определять их заново для каждой новой базы данных.

Предоставление доступа к базам данных

Для баз данных процедура предоставления доступа отличается от аутентификации учётных записей. Разрешения предоставляются через роли, а не путём назначения прав непосредственно к глобальным группам. Это позволяет Вам добавлять логины для аутентификации на SQL сервере, в рамках планируемой системы безопасности, без особых усилий.
После того, как Вы создали базу данных, используйте хранимую процедуру sp_grantdbaccess для предоставления доступа группе DB_Name Users. Обратите внимание, что не существует обратной по смыслу процедуры sp_denydbaccess, так что Вы не можете запретить доступ к базе таким же образом, как это делалось по отношению к серверу. Если Вам необходимо запретить доступ к базе данных, создайте другую глобальную группу по имени DB_Name Denied Users, предоставьте ей доступ к базе данных, и сделайте её членом ролей db_denydatareader и db_denydatawriter. Будьте осторожны при назначении операторных разрешений, ввиду того, что эти роли ограничивают только доступ к объектам, а не к инструкциям Data Definition Language (DDL).
Как и в случае с логинами, SQL Server предоставляет пользователю доступ к базе данных, если его SID в маркере совпадает с записью в системной таблицы Sysusers. Таким образом, Вы можете предоставлять пользователям доступ к базе данных через их персональную учётную запись NT, имеющую свой SID, или через SID любой группы NT, членом которой он является. Для простоты управления, создайте одну глобальную группу по имени DB_Name Users, которая будет иметь доступ к базе данных, и не предоставляйте доступ к этой базе другим группам. Так Вы сможете очень просто добавлять и удалять пользователей базы данных, определяя их принадлежность к одной глобальной группе.

Назначение разрешений

Последний шаг в настройке системы безопасности вашего сервера баз данных состоит в создании пользовательских ролей баз данных и назначении им разрешений. Самый простой способ, это создать роли с названиями, которые соответствуют именам глобальных групп. Используя пример бухгалтерии, Вы создали бы роли по именам: Accounting Data Entry Operators, Accounting Data Entry Managers, и так далее. Здесь можно использовать сокращённые названия, потому что роли в бухгалтерской базе данных, вероятно, касаются только бухгалтерии. Однако если эти имена полностью соответствуют именам глобальных группы, у вас будет возникать меньше путаницы, и можно будет более легко определять принадлежность группы роли базы данных.
После того, как Вы создали роли, Вы можете назначать разрешения. На этом шаге допустимо использование только стандартных разрешений GRANT, REVOKE, и DENY. Будьте осторожны с DENY, потому что оно имеет наивысший приоритет перед всеми другими разрешениям. SQL Server запретит доступ пользователю к объектам базы, если он является членом любой роли или группы с установленным разрешением DENY. Также, если вы модернизируете используемую в SQL Server 6.5 систему безопасности, помните, что механизмы назначения и применения разрешений у SQL Server 7.0, и SQL Server 6.5 имеют существенные различия.
Теперь Вы можете добавлять логины для аутентификации ваших пользователей в SQL Server. Одна из наиболее ценных особенностей пользовательских ролей базы данных в том, что они могут содержать, как обычные логины SQL сервера, так и глобальные или локальные группы NT, а также индивидуальные учётные записи. Поскольку пользовательские роли являются универсальным контейнером для всех типов логинов, это является главной причиной использовать их вместо назначения разрешений глобальным группам.
Обратите внимание, что предлагается использовать только две встроенных роли базы данных (db_securityadmin и db_owner). Причина в том, что встроенные роли обращаются к базе данных в целом, а не к её объектам. Например, db_datareader предоставляет разрешение SELECT для каждого объекта базы данных. Вы могли использовать db_datareader для выборочно запрещения SELECT конкретным пользователям или группам, но этот метод чреват тем, что можете просто забыть установить необходимые разрешения для некоторых пользователей или объектов. Проще говоря, менее подверженным ошибкам методом является создание пользовательских ролей для определенных категорий пользователей и назначение им разрешений, через которые они получат доступ к тем объектам, в которых эти категории нуждается.

Простая система безопасности

Использование собственного механизма аутентификации SQL сервера проще чем аутентификация NT, особенно если она предоставляется через прикладную программу. Но ситуация резко ухудшается, если число пользователей превысит 25 или когда Вы имеете несколько сервера баз данных и каждый пользователь должен иметь доступ к нескольким база на разных серверах, администрируемых разными людьми. Даже в не больших организациях, в которых администратор базы данных выполняет и другие обязанности, простая схема безопасности позволяет легко запомнить систему предоставления разрешений каждому пользователю и то, как он их получил. Такой подход позволяет сгладить проблемы, вызванные отсутствием у SQL сервера инструментов, позволяющих определить действующие, эффективные разрешения пользователей. Лучшее решение должно использовать механизм аутентификации NT и предоставлять доступом к базе данных через тщательно продуманный набор ролей базы данных и глобальных групп.

Основные правила системы безопасности

1. Пользователи получают доступ сервера через группу SQL Server Users, а доступ к базе данных через группу DB_Name Users.
2. Пользователи получают разрешения через участие в глобальных группах, которые является членами ролей, имеющих соответствующие разрешения в базе данных.
3. Пользователи, нуждающиеся в нескольких наборах разрешений, могут быть члены нескольких глобальных групп.

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



Литература по SQL Server


 
Компьютеры |  Кулинария |  Медицина |  Нормативная литература |  Типовые договора |  Общие темы