Sql политика безопасности


Содержание

УПРАВЛЕНИЕ ДОСТУПОМ В СУБД SQL SERVER

Приобретение практических навыков настройки разрешений на доступ к объектам баз данных в среде СУБД Microsoft SQL Server 2008/2012.

Используемые программные средства.

Компьютер или виртуальная машина с установленной ОС семейства Windows и СУБД SQL Server. При работе в сети возможно совместное использование одного экземпляра SQL Server. В этом случае на остальных компьютерах должны быть установлены только клиентские компоненты и SQL Server Management Studio. Для выпол- 202

нения работы необходимы права, позволяющие создавать новую базу данных на экземпляре SQL Server.

Управление разрешениями на объекты реляционной базы данных несколько отличается от аналогичных операций в отношении объектов файловой системы. В данной лабораторной работе на примере СУБД SQL Server эти отличия будут показаны.

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

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

Необходимо отметить, что SQL Server разделяет понятие учетной записи (login) и пользователя (user). Сервер может быть сконфигурирован на использование только аутентификации Windows (англ. Windows Authentication Mode, используется по умолчанию) или на использование смешанного режима аутентификации (англ. SQL Server and Windows Authentication mode), см. рис. 5.3. В первом случае login можно создать только для пользователя или группы Windows. Во втором случае также возможно использовать собственные учетные записи SQL Server — логин и пароль хранятся самой СУБД, и ее же средствами выполняется проверка подлинности. При использовании смешанной аутентификации егановится доступной административная учетная запись sa, которую рекомендуется переименовать и назначить ей надежный пароль. Учетная запись авторизуется на выполнение одной из серверных ролей (табл. 5.1).

Рис. 5.3. Окно редактирования настроек безопасности экземпляра SQL Server

Роли уровня сервера

Разрешено выполнять любые действия на сервере.

Разрешено создавать базы данных.

Могут выполнять инс трукцию BULK INSERT.

Позволяет управлять файлами на диске.

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

Создание и управление учетными записями, право «сбросить» пароль учетной записи. Управление разрешениями на уровне сервера и на уровне базы данных (при наличии доступа к базе данных).

Включает возможности ролей diskadmin и processadmin, позволяет изменять параметры конфигурации на уровне сервера и выключать сервер.

Добавление и удаление связанных серверов.

Каждая учетная запись принадлежит этой роли, членство в роли public изменить нельзя.

На уровне базы данных учетной записи сопоставляется пользователь (user). Для одной и той же учетной записи в различных базах данных сервера могут создаваться пользователи с разными именами.

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

Рис. 5.4. Учетные записи и соответствующие им пользователи и роли в базах данных

Список ролей уровня сервера предопределен, и новые создавать нельзя (табл. 5.1). Также есть предопределенный набор ролей уровня базы данных (табл. 5.2), но в этом случае имеется возможность создавать новые роли.

Роли уровня базы данных

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

Управление составом ролей (кроме роли db_owner) и связанными с ними разрешениями.

Добавление и удаление пользователей базы данных.

Возможность создавать резервные копии базы данных.

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

Чтение данных (SELECT) из всех пользовательских таблиц, представлений и функций.

Запрет на чтение данных (SELECT) из всех пользовательских таблиц, представлений и функций.

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

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

Роль по умолчанию, имеющаяся в каждой базе данных. Каждый пользователь БД авторизован на эту роль.

Болес подробную информацию об организации системы безопасности СУБД SQL Server можно получить из справочной системы TechNet: http://technet.microsoft.com/ru-ru/library/bb510589.aspx.

  • 1. Используя указанную преподавателем доменную или локальную учетную запись Windows, с помощью SQL Server Management Studio подключитесь к используемому экземпляру SQL Server. Проверьте установленный на сервере режим аутентификации.
  • 2. В окне Object Explorer (по умолчанию — левая часть окна Management Studio) откройте список учетных записей (logins). На выполнение каких серверных ролей авторизована используемая вами учетная запись?
  • 3. В каких базах данных сервера вашей учетной записи сопоставлены пользователи? На выполнение каких ролей они авторизованы?
  • 4. В среде Management Studio создайте новую базу данных. Откройте список пользователей и ролей. Убедитесь, что учетная запись, под которой вы работаете, сопоставлена пользователю dbo, авторизованному на роль db owner.
  • 5. Используя приведенный ниже скрипт, создайте в базе данных таблицы. Перед гем как запустить скрипт, уберите символы комментария («—») из первой строки и после ключевого слова use укажите имя вашей базы данных.
  • —use MyTestl GO

CREATE TABLE dbo.Book (

book_id int IDENTITY (1, 1) primary key,

Title varchar(50) NOT NULL, —название книги Author varchar(50), — автор Publisher varchar(50), — издательство [Year] smallint) — год издания GO

CREATE TABLE dbo.Status (

Status_id int IDENTITY (1, 1) primary key, Status_name varchar(50) NOT NULL ) — статус: выдана, в библиотеке и т.д.

CREATE SCHEMA libr GO

CREATE TABLE libr.Book_in_lib (

lib_id int primary key , —номер экземпляра book_id int references dbo.Book , status_id int references dbo.[Status])

Обратите внимание, что приведенный скрипт создает не только три таблицы, но и схему libr. В SQL Server схема является контейнером логического уровня, к которому относятся объекты базы данных. Во вновь созданной БД уже будет несколько схем: dbo, sys, information_schema и т. д. Схема dbo — это схема по умолчанию для новых пользовательских объектов, sys и infor- mation schema используются системными объектами. Оператором CREATE SCHEMA в БД можно создавать новые схемы.

Защищаемым объектом, на действия с которым пользователю предоставляются разрешения, может быть база данных, схема или объект базы данных. Определенное для схемы разрешение неявным образом распространяется на все объекты схемы, разрешение для базы данных — на все схемы и объекты этих схем.

6. Для указанной преподавателем учетной записи SQL Server (при самостоятельном выполнении работы создайте учётную запись Windows и учётную запись SQL Server для нее) создайте пользователя в вашей базе данных, в качестве схемы по умолчанию выберите dbo. В Management Studio это можно сделать из графического интерфейса (контекстное меню узла Security для выбранной БД, там New. -> User) или выполнив оператор CREATE USER. Например (если схема не указана, подразумевается dbo):

CREATE USER ns FOR LOGIN [HOME s]

Добавьте этого пользователя в роль db_datareader. Это можно сделать или через графический интерфейс или с помощью системной хранимой процедуры sp_addrolemember, первым параметром которой будет имя роли, а вторым — имя пользователя.

EXEC sp_addrolemember ‘db_datareader’, ‘ns 1 Введите в таблицы тестовый набор данных.

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

7. Создадим новую роль уровня базы данных и добавим ей разрешение на удаление (DELETE), изменение (UPDATE) и добавление данных (INSERT) в объектах схемы libr. Добавим нашего пользователя к этой роли. Указанные действия надо выполнять с правами администратора или владельца базы данных. Как и в предыдущем случае, все это можно сделать в графическом интерфейсе или запуском скрипта.

CREATE ROLE libr_writer GO

GRANT INSERT, UPDATE, DELETE ON SCHEMA :: libr TO

EXEC sp_addrolemember ‘libr_writer’, ‘ns’

Используемый в приведенном скрипте оператор GRANT позволяет предоставить разрешения. Оператор DENY позволяет запретить выполнение каких-то действий, а оператор REVOKE отменяет установленные оператором GRANT или DENY настройки разрешений. Таким образом, у разрешения может быть три состояния: «разрешено», «запрещено», «не задано». Действие можно выполнить, только если оно разрешено непосредственно пользователю или одной из ролей, на которые он авторизован. Запрещение более приоритетно, чем разрешение: если пользователь авторизован на выполнение двух ролей, одной из них действие разрешено, а другой — запрещено, то пользователь это действие выполнить нс сможет. В SQL Server Management Studio можно просмотреть эффективные разрешения для пользователя (рис. 5.5).

Конкретный набор возможных разрешений зависит от тина объекта, с полным списком разрешений рекомендуется ознакомиться по справке или приведенной ниже статье TechNet: http://technet.microsoft.coin/ru-ru/library/ms 191291 .aspx.


Рис. 5.5. Эффективные разрешения пользователя

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

8. Иногда нужно предоставить пользователю права на изменение отдельных столбцов. Как отмечается в документации SQL Server, на столбец могут быть предоставлены только разрешения SELECT, REFERENCES и UPDATE. Например:

GRANT UPDATE ON dbo.Book(Title) TO libr_writer

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

9. Самостоятельно по справке ознакомьтесь с форматом оператора CREATE VIEW, особое внимание обратите на задаваемые дополнительные параметры. Создайте представление, выбирающее из таблицы Book книги, изданные нс ранее 2000 года. Предоставьте пользователю с ограниченными правами возможность изменять и добавлять подобные книги. Возможности изменять прочие записи таблицы и добавлять книги, изданные до 2000 года, он иметь не должен.

Безопасность в Microsoft SQL Server 2005

Как, возможно, уже известно многим нашим читателям, в начале ноября состоялся официальный выход Microsoft SQL Server 2005. Событие это, на наш взгляд, немаловажное, ибо системы управления базами данных традиционно относятся к категории продуктов, новые версии которых выпускаются не очень часто, поскольку повышенные требования к надежности программного обеспечения подобного класса являются причиной очень тщательного подхода к его проектированию, разработке и тестированию. Выпуск новой версии СУБД через пять лет после предыдущей, как это произошло с SQL Server, — явление вполне обычное. И, поскольку вопросы безопасности за эти пять лет стали едва ли не самыми актуальными во всех областях человеческой деятельности (вспомним ежедневные сообщения о взломах сетей и утечках конфиденциальных и корпоративных данных), представляется логичным выяснить, что нового с этой точки зрения данная СУБД предлагает IT-менеджерам, администраторам и разработчикам приложений. Тем более что по сравнению с SQL Server 2000 (очень хорошим, по нашему мнению, продуктом даже по современным меркам) в модель безопасности SQL Server 2005 внесены существенные улучшения.

Авторизация и аутентификация

Аутентификация — это процесс проверки права пользователя на доступ к тому или иному ресурсу, который чаще всего (хотя и не всегда) осуществляется с помощью ввода имени и пароля.

Как и предыдущие версии, SQL Server 2005 поддерживает два режима аутентификации: аутентификация с помощью Windows и аутентификация с помощью SQL Server.

Первый из режимов является рекомендуемым: именно он позволяет реализовать решение, основанное на однократной регистрации пользователя и на едином пароле доступа к различным приложениям (Single Sign-On solution, SSO), что упрощает работу пользователей, избавляя их от запоминания множества паролей и снижая риск хранения. Кроме того, данный режим позволяет использовать доступные администраторам Windows механизмы формирования групп, применения политик безопасности для доменов, таких как управление сложностью пароля и временем его существования, блокировка учетных записей, а также применение защищенных протоколов аутентификации с помощью шифрования паролей, например Kerberos или NT LAN Manager (NTLM).

Аутентификация с помощью SQL Server предназначена для клиентских приложений, функционирующих на платформах, отличных от Windows. Хотя этот способ и предпочитают многие разработчики приложений, он считается менее безопасным, однако в новой версии SQL Server данный способ аутентификации поддерживает шифрование с помощью сертификатов, сгенерированных сервером. Воспользоваться им можно, если клиентские приложения применяют новую версию MDAC (Microsoft Data Access Components) 2.8. Шифрование всех сообщений, которыми обмениваются клиент и сервер, также повышает надежность этого способа аутентификации.

Для учетной записи SQL Server можно указать такие параметры команды CREATE/ALTER LOGIN, как необходимость сменить пароль при первом соединении с сервером, необходимость проверки срока действия пароля, необходимость применения локальной парольной политики Windows (рис. 1). Последние два параметра можно полноценно использовать, если SQL Server 2005 выполняется под управлением Windows Server 2003.

Рис. 1. Установка правил поведения пароля пользователя

Наконец, теперь обязательно требуется непустой пароль пользователя sa — как ни банальна ошибка, связанная с сохранением пустого пароля, ее слишком часто совершают администраторы баз данных (и, понятно, используют разного рода злоумышленники).

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

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

SQL Server 2005 содержит встроенные средства шифрования, цифровой подписи и верификации данных с помощью симметричных ключей (поддерживаются алгоритмы шифрования RC4, RC2, DES, AES) и асимметричных ключей (алгоритм RSA).

Как уже было сказано, весь трафик между клиентом и сервером по умолчанию шифруется с применением протоколов IP Security (IP SEC) и Secure Sockets Layer (SSL), и подобная функциональность доступна во всех редакциях продукта. Протокол SSL поддерживается с помощью интеграции со службами Internet Information Services (IIS) или с помощью сервера сертификатов, поддерживающего стандарт X.509v3 и входящего в состав SQL Server 2005. Сгенерированные сертификаты не только используются для создания SSL-соединений — их применяет и SQL Service Broker.

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

SQL Server 2005 также поддерживает шифрование самих хранимых данных, полностью интегрированное с инфраструктурой управления ключами. Для этого он содержит шесть встроенных функций: EncryptByCert, DecryptByCert, EncryptByKey, DecryptByKey, EncryptByAssym и DecryptByAssym, позволяющих использовать шифрование с помощью сертификата, симметричного и асимметричного ключей в коде Transact-SQL.

Изоляция учетных записей от объектов базы данных

В большинстве современных серверных СУБД у каждого объекта базы данных имеется пользователь-владелец, который может предоставлять другим пользователям права доступа к объектам базы данных. Набор объектов, принадлежащих одному и тому же пользователю, называется схемой. При этом для серверных СУБД сегодня стандартным является механизм ролей — наборов прав доступа к объектам базы данных, присваиваемых в совокупности тому или иному пользователю. Данный способ владения объектами создавал определенные неудобства администраторам и разработчикам приложений: с одной стороны, после увольнения сотрудника, создавшего объекты, используемые многими пользователями, при удалении соответствующей учетной записи приходилось вносить изменения в серверный код (а нередко и в код клиентского приложения), а с другой — далеко не всем пользователям нужны собственные схемы. Зная о потенциальных проблемах сопровождения схем и учетных записей, многие заказчики решений, использующих базы данных, стали в последнее время настаивать на «наколенных» (не побоимся этого слова!) реализациях способов управления учетными записями пользователей, вплоть до хранения их имен и паролей в обычных таблицах, что резко повышало угрозу несанкционированного доступа к данным и приложениям.

В SQL Server 2005 концепция ролей расширена — эта СУБД позволяет полностью отделить пользователя от схем и объектов базы данных. Теперь объекты базы данных принадлежат не пользователю, а схеме, не имеющей отношения к учетной записи пользователя (рис. 2), тогда как пользователь может быть ассоциирован со схемой. Таким образом, схема становится не более чем механизмом группировки объектов в соответствии с решаемой задачей, упрощающим предоставление пользователям и ролям прав на доступ к объектам. Кроме того, подобный механизм упрощает разрешение имен и позволяет хранить объекты общего пользования в схеме, не имеющей никакого отношения к административным привилегиям.

Рис. 2. Установка прав для схем данных

Выполнение кода с минимальными привилегиями

Одним из базовых принципов создания безопасных приложений является принцип предоставления минимальных привилегий, необходимых для решения поставленной задачи. Этот принцип реализован в более строгих, по сравнению с предыдущими версиями, настройках по умолчанию. Так, в новой версии SQL Server по умолчанию отключено значительное количество функций, например применение Microsoft .NET Framework в ядре СУБД, функции SQL Service Broker Network Connectivity, доступ к аналитическим службам с помощью протокола HTTP. Такие службы, как SQL Server Agent, Data Transformation Services, средства полнотекстового поиска, после установки сервера находятся в режиме ручного запуска.

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

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

Выполнение .NET-кода в ядре СУБД требует при загрузке сборки указания одного из трех уровней безопасности: SAFE (доступ ко внешним ресурсам не допускается), EXTERNAL_ACCESS (доступ к файлам, сетевым ресурсам, реестру, переменным окружения) или UNSAFE (доступ ко всем ресурсам, в том числе к неуправляемому коду). Если сборка в процессе работы выйдет за указанные при ее загрузке параметры безопасности, то Common Language Runtime сгенерирует исключение и выполнение кода сборки прекратится.

Аудит

Аудит — довольно распространенный способ выявления некорректных или неавторизованных действий пользователей, особенно тех, кто имеет избыточные привилегии.

SQL Server 2005 поддерживает несколько способов поддержки аудита (рис. 3). В частности, можно использовать Windows Security EventLog (механизм отслеживания обращений к объектам, применения прав, попыток аутентификации) и SQL Profiler (средство осуществления детального аудита попыток доступа к объектам БД).

Рис. 3. Выбор событий базы данных для аудита

Для осуществления аудита полезным может оказаться еще один новый механизм, появившийся в SQL Server 2005, — это триггеры, связанные с изменением метаданных (DDL-триггеры). Создание таких триггеров позволяет отслеживать попытки изменения метаданных пользователями или полностью запрещать их.

Сокрытие метаданных

В SQL Server 2005 cистемные объекты находятся в скрытой базе mssqlsystemresource, а пользователям доступны представления Catalog Views для обращения к системным таблицам, причем данные из этих представлений фильтруются в зависимости от того, кто делает запрос. Имеется и специальное разрешение VIEW DEFINITION, позволяющее обойти сокрытие метаданных всей БД, схемы или конкретного объекта.

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

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

Сравнение с другими СУБД

Конечно, SQL Server — не единственная хорошая серверная СУБД на рынке программного обеспечения. Так, СУБД масштаба предприятия выпускают IBM, Oracle, Sybase. Средства обеспечения безопасности в SQL Server 2005 тоже не уникальны, что иллюстрируется таблицей, в которой представлено наличие средств обеспечения безопасности в SQL Server 2005 и в различных редакциях Oracle 10g.

Средства обеспечения безопасности Oracle и SQL Server

Отметим, однако, что перечисленные механизмы безопасности и средства их администрирования доступны во всех редакциях SQL Server 2005, включая бесплатную редакцию Express Edition и относительно недорогие версии Workgroup Edition и Standard Edition, которые вполне под силу приобрести даже небольшим предприятиям, тогда как аналогичные механизмы и утилиты Oracle 10g присутствуют только в наиболее дорогостоящей редакции этой СУБД.

Немного общих рассуждений

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

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

  • отказ от динамически формируемых запросов в пользу хранимых процедур или параметризованных запросов;
  • применение регулярных выражений в клиентских приложениях для проверки пользовательского ввода до того, как он будет отправлен в СУБД;
  • применение экранирования специальных символов;
  • проверка пользовательского ввода средствами сервера;
  • проверка соответствия типов вводимых данных типам в СУБД;
  • отказ от генерации команд, выполняемых на сервере, непосредственно из введенных пользователем данных.

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

Выявление уязвимостей с помощью Microsoft Baseline Security Analyzer. Настройка локальной политики паролей

Microsoft Baseline Security analyzerпрограмма, позволяющая проверить уровень безопасности установленной конфигурации операционной системы (ОС) Windows 2000, XP, Server 2003, Vista Server 2008. Также проверяется и ряд других приложений разработки Microsoft. Данное средство можно отнести к разряду систем анализа защищенности. Оно распространяется бесплатно и доступно для скачивания с web-сервера Microsoft (адрес страницы данной утилиты на момент подготовки описания был: http://technet.microsoft.com/ru-ru/security/cc184924(en-us).aspx).

В процессе работы BSA проверяет наличие обновлений безопасности операционной системы, офисного пакета Microsoft Office (для версий XP и более поздних), серверных приложений, таких как MS SQL Server, MS Exchange Server, Internet Information Server и т.д. Кроме того, проверяется ряд настроек, касающихся безопасности, например, действующая политика паролей.

Перейдем к знакомству с программным продуктом. Надо отметить, что при подготовке описания данной лабораторной работы использовалась версия BSA 2.1. К сожалению, продукт не локализован, поэтому использовалась англоязычная версия.

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

Рис. 3.1. Выбор проверяемого компьютера

Рис. 3.2. Задание параметров проверки

Можно задать перечень проверяемых параметров. На рис. 3.2 представлен выбор вариантов проверки:

· проверка на наличие уязвимостей Windows, вызванных некорректным администрированием;

· проверка на «слабые» пароли (пустые пароли, отсутствие ограничений на срок действия паролей и т.д.);


· проверка на наличие уязвимостей web-сервера IIS, вызванных некорректным администрированием;

· аналогичная проверка в отношении СУБД MS SQL Server;

· проверка на наличие обновлений безопасности.

Перед началом работы программа обращается на сервер Microsoft для получения перечня обновлений для ОС и известных уязвимостей. Если на момент проведения проверки компьютер не подключен к Интернет, база уязвимостей не будет обновлена, программа об этом сообщит и дальнейшие проверки выполняться не будут. В подобных случаях нужно отключать проверку обновлении безопасности (сбросив соответствующую галочку на экране рис. 3.2 или с помощью ключа при использовании утилиты командной строки, о чем речь пойдет ниже).

Для успешной проверки локальной системы необходимо, чтобы программа выполнялась от имени учетной записи с правами локального администратора. Иначе проверка не может быть проведена и о чем будет выдано сообщение: «You do not have sufficient permissions toperform this command. Make sure that you are running as the local administrator or have opened the command prompt using the ‘Run asadministratoroption«.

По результатам сканирования формируется отчет, вначале которого дается общая оценка уровня безопасности конфигурации проверяемого компьютера. В приведенном на рис. 3.3 примере уровень риска оценивается как «серьезный» (Severe risk).

Далее приводится перечень обнаруженных уязвимостей, разбитый на группы: результаты проверки установки обновлений, результаты проверки Windows и т.д. Надо отметить, что выпускаемые Microsoft обновления бывают различных типов:

Security updates – собственно обновления безопасности, как правило, посвященные исправлению одной уязвимости программного продукта;

Update rollups – набор исправлений безопасности, который позволяет одновременно исправить несколько уязвимостей. Это упрощает обслуживание процесса обновления программного обеспечения (ПО);

Рис. 3.3. Заголовок отчета

Service packs – набор исправлений, как связанных, так и несвязанных с безопасностью. Установка Service pack, как правило, исправляет все уязвимости, обнаруженные с момента выхода предыдущего Service pack, таким образом устанавливать промежуточные обновления уже не надо.

В описании рассматриваемого результата проверки (рис. 3.4) можно выбрать ссылку Result details и получить более подробное описание найденных проблем данной группы. При наличии подключения к Интернет, перейдя по приводимой в отчете ссылке, можно получить информацию об отсутствующем обновлении безопасности и скачать его из сети.

Нужно отметить, что установка обновлений для систем с высокими требованиями в области непрерывности работы, требует предварительной тщательной проверки совместимости обновлений с использующимися приложениями. Подобная проверка обычно производится на тестовых системах с близкой конфигурацией ПО. В то же время, для небольших организаций и пользователей домашних компьютеров такая проверка зачастую неосуществима. Поэтому надо быть готовым к тому, чтобы восстановить систему после неудачного обновления. Для современных ОС семейства Windows это можно сделать, например, используя специальные режимы загрузки ОС – безопасный режим или режим загрузки последней удачной конфигурации.

Также надо отметить еще одну особенность. На данный момент baseline security analyzer не существует в локализованной русскоязычной версии. И содержащиеся там ссылки на пакеты обновлений могут указывать на иные языковые версии, что может создать проблемы при обновлении локализованных продуктов.

Рис. 3.4. Перечень неустановленных обновлений (по группам)

Рис. 3.5. Уязвимости, связанные с администрированием операционной системы

Аналогичным образом проводится работа по анализу других групп уязвимостей (рис. 3.5). Описывается уязвимость, указывается ее уровень критичности, даются рекомендации по исправлению. На рис. 3.6 представлено подробное описание результатов (ссылка result details) проверки паролей. Указывается, что 3 учетные записи имеют пароли, неограниченные по сроку действия.

Рис. 3.6. Результаты проверки паролей

Кроме версии программы с графическим интерфейсом, существует также утилита с интерфейсом командной строки. Называется она mbsacli.exe и находится в том же каталоге, куда устанавливался Baseline security analyzer, например, «C:\Program Files\Microsoft Baseline Security Analyzer 2». У утилиты есть достаточно много ключей, получить информацию, о которых можно запустив ее с ключом «/?».

Запуск без ключей приведет к сканированию локального компьютера с выводом результатов на консоль. Чтобы сохранить результаты сканирования, можно перенаправить вывод в какой-либо файл. Например: mbsacli > mylog.txt. Хотелось бы еще раз обратить внимание на то, что при настройках по умолчанию сначала утилита обращается на сайт Майкрософт за информацией об обновлениях. Если соединение с Интернет отсутствует, то утилиту надо запускать или с ключом /nd (указание «не надо скачивать файлы с сайта Майкрософт») или с ключом /n Updates (указание «не надо проводить проверку обновлений»).

Запуск с ключом /xmlout приводит к запуску утилиты в режиме проверки обновлений (т.е. проверка на уязвимости, явившиеся результатом неудачного администрирования, проводиться не будет), при этом, отчет формируется в формате xml. Например:

mbsacli /xmlout > c:\myxmlog.xml

Задания

1. Выполните проверку Вашего компьютера с помощью Microsoft Baseline security analyzer. В отчете о выполнении работы укажите:

o как оценен уровень уязвимости Вашего компьютера;

o какие проверки проводились, в какой области обнаружено наибольшее количество уязвимостей;

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

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

2. Выполните удаленную проверку соседнего компьютера из сети лаборатории. Опишите наиболее серьезные уязвимости.

3. Теперь выполните проверку нескольких компьютеров с помощью утилиты mbsacli. Для этого предварительно создайте текстовый файл с перечнем имен компьютеров или IP-адресов и запускайте mbsacli с ключом /listfile, после которого указывается имя файла с перечнем компьютеров. В результате Вы получите сообщение примерно следующего содержания:

4. Computer Name, IP Address, Assessment, Report Name

HOME\MYNBOOK, 127.0.0.1, Severe Risk, HOME — MYNBOOK (06.12.2008 13-51)

Для того чтобы увидеть подробные результаты проверки, надо повторно запустить mbsacli с ключом /ld, после которого указывается имя отчета. Вывод можно перенаправить в текстовый файл для дальнейшей обработки. Например:

mbsacli /ld «HOME — MYNBOOK (06.12.2008 13-51)» > c:\test\report1.txt

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

Локальная политика паролей

Рассмотрим теперь, какие настройки необходимо сделать, чтобы пароли пользователей компьютера были достаточно надежны. В теоретической части курса мы рассматривали рекомендации по администрированию парольной системы. Потребовать их выполнения можно с помощью политики безопасности. Настройка делается через Панель управления Windows.

Откройте Панель управления Администрирование Локальная политика безопасности. Выберите в списке Политика учетных записей и Политика паролей. Для Windows Vista экран консоли управления будет выглядеть так, как представлено на рис. 3.7.

Рис. 3.7. Настройка политики паролей

Значения выбранного параметра можно изменить (рис. 3.8).

Надо понимать, что не все требования политики паролей автоматически подействуют в отношении всех учетных записей. Например, если в свойствах учетной записи стоит «Срок действия пароля не ограничен», установленное политикой требование максимального срока действия пароля будет игнорироваться. Для обычной пользовательской учетной записи эту настройку лучше не устанавливать. Но в некоторых случаях она рекомендуется. Например, если в учебном классе нужна «групповая» учетная запись, параметры которой известны всем студентам, лучше поставить для нее «Срок действия пароля не ограничен» и «Запретить смену пароля пользователем».

Илон Маск рекомендует:  Что такое код asp cpuenablepagefaults

Свойства учетной записи можно посмотреть в Панель управления Администрирование Управление компьютером, там выберите Локальные пользователи и группы и Пользователи (или запустив эту же оснастку через Пуск Выполнить lusrmgr.msc ).

Рис. 3.8. Установка требования ведения журнала паролей

1. Опишите действующую на вашем компьютере политику паролей.

2. Измените ее в соответствии с рассмотренными в теоретической части курса рекомендациями по администрированию парольной системы.

3. Если в ходе проверки утилитой bsa были выявлены уязвимости, связанные с управлением паролями пользователей, опишите пути их устранения или обоснуйте необходимость использования действующих настроек.

Лабораторная работа 4

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

Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов (88‰).

Общие принципы безопасности SQL Server

Программа IT Audit: Enterprise использует Microsoft SQL Server для хранения данных пользователя. Эта система управления базами данных (СУБД) является профессиональным инструментом управления данными с широкими возможностями по настройке безопасности как доступа к данным, так и их обработки, создания и удаления.

Данная статья посвящена различиям в способах авторизации на SQL-сервере, так как большинство рядовых пользователей не понимают принципиальных различий, что в итоге приводит к невозможности подключения к базе данных, и, как следствие, к неработоспособности программы IT Audit: Enterprise.

Варианты безопасности SQL Server

1. Соединение с использованием проверки подлинности Windows

Данный метод в программе IT Audit: Enterprise называется учетные сведения Windows NT.

В этом случае SQL-сервер не требует предоставления логина и пароля пользователя, а доверяет информации об авторизации в операционной системе Microsoft Windows. Для использования данного метода SQL-серверу требуется доступ к идентификационным данным операционной системы – Active Directory для сетей на основе контроллера домена и учетные записи в одноранговых сетях на основе рабочих групп. Это означает, что в SQL-сервере должны присутствовать сведения о пользователях и группах пользователей Windows, которые имеют право авторизоваться.

При установке SQL-сервера в него добавляется группа Пользователи Windows и текущий пользователь (в качестве администратора). Это значит, что любой пользователь, включенный в группу «Пользователи» может установить подключение к SQL-серверу — получить к нему доступ. А пользователь, который установил SQL-сервер, не только установить подключение, но и совершать действия по управлению сервером:

  • получать доступ к базам данных
  • создавать и удалять базы данных и объекты в них


Для того, чтобы пользователь из группы «Пользователи» мог совершать те же действия, требуется настройка прав для этой группы, так как «установить подключение» не означает возможность совершать иные действия.

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

Таким образом, использование данного метода авторизации делает программу IT Audit Enterprise неработоспособной в следующих случаях:

  • в однопользовательском режиме, при установке под администратором, но работой под пользователем с ограниченными правами (простым пользователем);
  • в одноранговой сети при работе на других компьютерах сети (не «серверном»);
  • в сетевом режиме установки, так как служба ITAudit Service по умолчанию запускается под пользователем «Система».

2. Соединение с использованием проверки подлинности SQL Server

Для использования этого метода необходимо при установке SQL-сервера включить Установка SQL Server 2012 проверки подлинности. Придумать, ввести и запомнить сложный пароль для встроенного пользователя sa.

При использовании данного метода, для подключения к SQL-серверу, требуется предоставить имя пользователя и пароль, заведенные на самом SQL-сервере. По умолчанию в программе IT Audit: Enterprise предлагается использовать встроенного в SQL-сервер пользователя sa.

Этот пользователь обладает правами администратора SQL-сервера, а значит – может подключаться к SQL-серверу, имеет полный доступ ко всем базам данных, имеет право создавать и удалять базы данных и объекты в них – то есть может выполнять все функции по управлению данными, которые требуются для корректной работы программы ITAudit Enterprise.

Организация защиты MS SQL SERVER

В критических для бизнеса приложениях, когда сервер СУБД должен быть постоянно доступен для клиентов, большинство профилактических работ по поддержке базы данных приходится выполнять фактически в режиме on — line. MS SQL Server обладает возможностями динамического резервного копирования данных, т. е. даже когда эти данные используются и изменяются клиентами. В случае сбоя оборудования, отключения питания и т. д. механизм автоматического восстановления MS SQL Server восстанавливает все базы данных до их последнего целостного состояния без вмешательства администратора. Все завершенные, но не отраженные в базе транзакции из журнала транзакций применяются к базе данных (это фактически то, что происходит при событии chekpoint), а незавершенные транзакции, т. е. те, которые были активными на момент сбоя, вычищаются из журнала.

Говоря о симметричной архитектуре, операции резервного копирования и восстановления могут распараллеливаться на несколько потоков и выполняться одновременно, используя преимущества асинхронного ввода/вывода. На каждое резервное устройство отводится свой поток. Параллельное резервное копирование поддерживает до 32 одновременных резервных устройств (backup devices), что позволяет быстро создавать страховочные копии баз данных даже очень большой емкости. Возможность резервного копирования и восстановления отдельных таблиц, о чем мы упоминали, рассматривая Transact-SQL, позволяет экономить место и время, не выполняя копирование всей базы ради только некоторых ее объектов. Однако резервное копирование отдельной таблицы требует наложения на нее блокировки exclusive в отличие от резервного копирования всей базы или журнала транзакций, которые могут выполняться независимо от степени активности пользователей. Резервным копиям может быть назначен предельный срок хранения или дата утраты актуальности, до наступления которой место, занятое на устройстве этими копиями, не может использоваться для размещения других резервных копий при инициализации устройства.

Для небольшой базы данных ее журнал транзакций обычно хранится на том же устройстве, что и сама база, и архивируется вместе с ней. Журналирование транзакций ведется по принципу write-ahead, что означает, что любое изменение сначала отражается в журнале транзакций и лишь потом попадает собственно в базу. В случае нахождения журнала транзакций на отдельном устройстве существует возможность отдельного резервного копирования журнала транзакций. Как правило, резервное копирование базы данных организуется с меньшей частотой, чем журнала транзакций. Например, сохранение журнала транзакций выполняется ежедневно, а страховая копия всей базы может делаться раз в неделю, так как архивирование журнала транзакций происходит значительно быстрее по времени и занимает меньше места, чем дамп целой базы. В отличие от резервирования базы данных дамп журнала транзакций очищает его неактивную часть, т. е. все завершившиеся (зафиксированные или абортированные) с момента последнего дампа транзакции, если только не использована опция NO_TRUNCATE. Команда DUMP TRANSACTION TRUNCATE_ONLY, очищающая журнал транзакций, полезна в случае его переполнения, которое можно контролировать, например, оператором DBCC SQLPERF (LOGSPACE). Если степень переполнения журнала очень высока, можно при его очистке отказаться от журналирования факта самого этого события: DUMP TRANSACTION NO_LOG. Если резервное копирование транзакций не представляет интереса, можно включить опцию очистки последних завершенных транзакций в базе по наступлению события checkpoint. Cмысл механизма checkpoint состоит в периодической записи данных из кэша на диск, чтобы не допускать грязных данных. Такого рода события постоянно генерируются MS SQL Server или возникают по инициативе пользователя. Включенная опция truncate log on checkpoint гарантирует выполнение с определенной частотой обработчиком события действий, приблизительно эквивалентных команде DUMP TRANSACTION TRUNCATE_ONLY.

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

Говоря о преимуществах интеграции с операционной системой, MS SQL Server использует в своей работе сервисы безопасности Windows NT. Напомним, что Windows NT на сегодня сертифицирована по классам безопасности С2/Е3. MS SQL Server может быть настроен на работу в одном из трех режимах безопасности. Интегрированный режим предусматривает использование механизмов аутентификации Windows NT для обеспечения безопасности всех пользовательских соединений. В этом случае к серверу разрешаются только трастовые, или аутентифицирующие, соединения (named pipes и multiprotocol). Администратор имеет возможность отобразить группы пользователей Windows NT на соответствующие значения login id MS SQL Server при помощи утилиты SQL Security Manager. В этом случае при входе на MS SQL Server login name и пароль, переданные через DB-Library или ODBC, игнорируются. Стандартный режим безопасности предполагает, что на MS SQL Server будут заводиться самостоятельные login id и соответствующие им пароли. Смешанный режим использует интегрированную модель при установлении соединений по поименованным каналам или мультипротоколу и стандартную модель во всех остальных случаях.

MS SQL Server обеспечивает многоуровневую проверку привилегий при загрузке на сервер. Сначала идентифицируются права пользователя на установление соединения с выбранным сервером (login name и пароль) и выполнение административных функций: создание устройств и баз данных, назначение прав другим пользователям, изменение параметров настройки сервера и т.д. Максимальными правами обладает системный администратор. На уровне базы данных каждый пользователь, загрузившийся на сервер, может иметь имя пользователя (username) базы и права на доступ к объектам внутри нее. Имеется возможность отобразить нескольких login id на одного пользователя базы данных, а также объединять пользователей в группы для удобства администрирования и назначения сходных привилегий. По отношению к объектам базы данных пользователю могут быть назначены права на выполнение различных операций над ними: чтение, добавление, удаление, изменение, декларативная ссылочная целостность (DRI), выполнение хранимых процедур, а также права на доступ к отдельным полям. Если этого недостаточно, можно прибегнуть к представлениям (views), для которых сказанное остается справедливым. Наконец, можно вообще запретить пользователю непосредственный доступ к данным, оставив за ним лишь права на выполнение хранимых процедур, в которых будет прописан весь сценарий его доступа к базе. Хранимые процедуры могут создаваться с опцией WITH ENCRYPTION, которая шифрует непосредственный текст процедуры, хранящийся обычно в syscomments. Права на выполнение некоторых команд (создание баз, таблиц, умолчаний, правил, представлений, процедур, резервное копирование баз и журналов транзакций) не являются объектно-специфичными, поэтому они назначаются системным администратором сервера или владельцем (создателем) базы данных при редактировании базы данных. Администрирование пользовательских привилегий обычно ведется в SQL Enterprise Manager, тем не менее в Transact-SQL имеются хранимые процедуры (sp_addlogin, sp_password, sp_revokelogin, sp_addalias, sp_adduser) и операторы (GRANT, REVOKE), которые позволяют осуществлять действия по созданию пользователей, назначению и отмене прав при выполнении скриптов. Дополнительную возможность администрирования привилегий предоставляют рассмотренные нами выше SQL-DMO

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

• объект базы данных.

С другой стороны механизм безопасности предполагает существование четырех типов пользователей:

• системный администратор, имеющий неограниченный доступ;

• владелец БД, имеющий полный доступ ко всем объектам БД;

• владелец объектов БД;

• другие пользователи, которые должны получать разрешение на доступ к объектам БД.

Модель безопасности SQL Server включает следующие компоненты:

• тип подключения к SQL Server;

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

Тип подключения к SQL Server

При подключении (и в зависимости от типа подключения) SQL Server поддерживает два режима безопасности:

• режим аутентификации Windows NT;

• смешанный режим аутентификации.

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

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

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

• роли уровня сервера;

• роли уровня базы данных.

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

В SQL Server существуют следующие типы ролей уровня сервера:

Sysadmin — дает право выполнить любое действие в SQL Server;

Serveradmin — дает право изменить параметры SQL Server и завершить его работу;

Setupadmin — дает право инсталлировать систему репликации и управлять выполнением расширенных хранимых процедур;

Securityadmin — дает право контролировать параметры учетных записей для подключения к серверу и предоставлять права доступа к базам данных;

Processadmin — дает право управлять ходом выполнения процессов в SQL Server;

Dbcreator — дает право создавать и модифицировать базы данных;

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

Роли уровня базы данных

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

В SQL Server существует три типа ролей:

• заранее определенные роли;

• определяемые пользователем роли;

Заранее определенными являются стандартные роли уровня БД. Эти роли имеет каждая база данных SQL Server. Они позволяют легко и просто передавать обязанности.

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

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

db_accessadmin — осуществляет контроль за доступом к базе данных путем добавления или удаления пользователей в режимах аутентификации;

db_datareader — определяет полный доступ к выборке данных (с помощью оператора SELECT) из любой таблицы базы данных. Запрещает выполнение операторов INSERT, DELETE и UPDATE для любой таблицы БД;

db_datawriter — разрешает выполнять операторы INSERT, DELETE и UPDATE для любой таблицы базы данных. Запрещает выполнение оператора SELECT для любой таблицы базы данных;

db_ddladmin — дает возможность создавать, модифицировать и удалять объекты базы данных;

db_securityadmin — управляет системой безопасности базы данных, а также назначением объектных и командных разрешений и ролей для базы данных;

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

db_denydatareader — отказ в разрешении на выполнение оператора SELECT для всех таблиц базы данных. Позволяет пользователям изменять существующие структуры таблиц, но не позволяет создавать или удалять существующие таблицы;

db_denydatawriter — отказ в разрешении на выполнение операторов модификации данных (INSERT, DELETE и UPDATE) для любых таблиц базы данных;


public — автоматически назначаемая роль сразу после предоставления права доступа пользователя к БД.

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

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

• роль уровня приложения.

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

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

Экспорт данных о ролевой политике безопасности из Системы управления базами данных ORACLE

Рубрика: Технические науки

Дата публикации: 11.12.2020 2020-12-11

Статья просмотрена: 179 раз

Библиографическое описание:

Омаров М. Б. Экспорт данных о ролевой политике безопасности из Системы управления базами данных ORACLE // Молодой ученый. — 2020. — №49. — С. 76-78. — URL https://moluch.ru/archive/183/46997/ (дата обращения: 12.11.2020).

В данной статье рассмотрен алгоритм экспорта ролевой политики безопасности из СУБД для последующего анализа.

Ключевые слова: БД, СУБД, ролевая политика безопасности, ORACLE, экспорт данных.

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

Часто возникает необходимость проанализировать модель, построенную средствами СУБД с теоретической точки зрения, так как для больших систем управление огромным количеством ролей, пользователей и разрешений является сложной задачей, которую трудно выполнять малой группой администраторов безопасности.

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

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

Общая информация о ролевой политике безопасности.

Основные элементы базовой модели ролевого разграничения доступа [1]:

  1. U — множество пользователей, зарегистрированных в системе.
  2. R — множество ролей, введённых в системе.
  3. P — множество привилегий системы.
  4. — отображение, определяющее множество привилегий для заданной роли.
  5. — отображение, определяющее множество ролей, на которые пользователь может быть авторизован.

Роль — введённая в систему абстрактная сущность, которая наделена набором полномочий. В ролевой политике безопасности управление доступом основывается на разрешающих и запрещающих правилах. Управление доступом происходит в два этапа:

  1. Каждой роли назначается набор полномочий.
  2. Каждому пользователю устанавливается множество доступных ему ролей.

Ролевая политика безопасности достаточно разнообразна, поэтому в ней можно выделить различные ролевые модели [2]:

– С иерархической организацией ролей в системе.

– Статическая модель распределения обязанностей (наличие взаимоисключающих ролей на все сеансы системы).

– Динамическая модель распределения обязанностей (наличие взаимоисключающих ролей на один сеанс).

– С количественными ограничениями по ролям.

– С группировкой ролей и полномочий.

Ролевая политика безопасности в ORACLE.

В СУБД ORACLE существует два типа привилегий: системные и объектные. Системные позволяют осуществлять различные задачи для администрирования БД, объектные позволяют совершать действия над конкретным объектом (выборка, обновление, удаление и т. д.).

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

Роли являются очень действенным и практичным механизмом для выдачи прав пользователям. СУБД ORACLE обеспечивает ряд предопределенных ролей для помощи в администрировании, например: CONNECT, RESOURCE, DBA и т. д. Но, разумеется, для реализации собственной политики безопасности предпочтительнее создать набор ролей, специфичных для конкретных бизнес-процессов, протекающих в системе.

Основные сведения о ролях:

– Роли могут быть предоставлены системные и объектные привилегии.

– Любая роль может быть предоставлена любому пользователю.

– Роль может быть предоставлена другим ролям. За исключением предоставления роли самой себе или из-за появления циклической зависимости.

– Роль может требовать прохождение аутентификации.

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

  1. Пользователь, предоставляющий права на объект, должен являться его владельцем.
  2. Пользователь имеет системную привилегию GRANT ANY OBJECT PRIVILEGE, которая даёт ему возможность предоставлять и отзывать привилегии от имени владельца.
  3. При выдаче права доступа от владельца объекта была указана опция WITH GRANT OPTION.

Основные источники информации.

Таблица DBA_ROLES содержит информацию обо всех ролях, которые имеются в базе данных, включая системные предопределённые роли.

В данной работе производилась выборка одного столбца из данной таблицы — ROLE.

Таблица ROLE_TAB_PRIVS включает в себя информацию обо всех привилегиях, выданных ролям, имеющимся в системе. Выборка производится для каждой роли с условием WHERE ROLE = ROLE_NAME. Необходимые для работы столбцы таблицы: TABLE_NAME, PRIVILEGE, OWNER.

Форматы представления данных.

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

В связи с этим появляется необходимость в экспорте ролевой политики безопасности из базы данных в каком-либо формате для последующего анализа. Форматы для хранения ролевого графа GraphML и GraphSon.

GraphML содержит представление графа в XML-подобном синтаксисе. Он широко используется библиотеками и различными инструментами для обработки и визуализации графов.

GraphSon содержит представление графа в JSON-подобном синтаксисе. Этот формат появился в ранних версиях TinkerPop, его использование может быть полезным, если граф должен обрабатываться кодом языков, не использующих Java Virtual Machine (JVM). Например, JavaScript,.NET, Python.

Экспорт данных.

Информация будет храниться в графе, где субъекты — роли, а объекты — таблицы, представления и т. д. Если у субъекта есть хоть одна привилегия на объект, то между ними строится ребро, которое содержит строковое представление битового массива, отвечающего за наличие привилегий данного субъекта на данный объект. Соответствие номеров ячеек битового массива и объектных привилегий в СУБД:

  1. «ALTER» — 0
  2. «DELETE» — 1
  3. «EXECUTE» — 2
  4. «DEBUG» — 3
  5. «FLASHBACK» — 4
  6. «INDEX» — 5
  7. «INSERT» — 6
  8. «ON COMMIT REFRESH» — 7
  9. «QUERY REWRITE» — 8
  10. «READ» — 9
  11. «REFERENCES» — 10
  12. «SELECT» — 11
  13. «UNDER» — 12
  14. «UPDATE» — 13

Данный список, впоследствии, можно при необходимости расширить путём внесения нового соответствия. При записи данных в формат (GraphML или GraphSon) битовый массив конвертируется в битовую строку.

Пример: роль TEST_ROLE имеет права на удаление записей, добавление записей, обновление записей и выборку из объекта TEST_TABLE. Поэтому битовая строка прав TEST_ROLE на TEST_TABLE будет выглядеть следующим образом: 01000010000101.

Основные этапы при экспорте:


  1. Поиск всех ролей в базе данных.
  2. Для каждой роли запуск процедуры поиска выданных привилегий на объекты системы.
  3. Сохранение роли и списка её привилегий на объекты.
  4. Заполнение графа с помощью Graph API от Apache TinkerPop (фрэймворк для работы с графами).
  5. Запись графа в выбранном формате.

Заключение

Описанный алгоритм извлечения данных о ролевой политике безопасности из СУБД ORACLE позволяет осуществлять ряд задач по анализу построенной системным администратором политике безопасности. Программа, реализующая данный алгоритм, представляет интерес для оптимизации ролевой политики безопасности, а также поиска потенциальных уязвимостей. Также возможно осуществление импорта данных в СУБД, если совершить какие-либо преобразования над экспортированным графом.

  1. Девянин П. Н. Модели безопасности компьютерных систем. М.: Издательский центр «Академия» — 2005г, 144 с.
  2. Гайдамакин H. A. Теоретические основы компьютерной безопасности. Учебное пособие. Екатеринбург: изд-во Урал. Ун-та — 2008, 212 с.

Безопасность в SQL Server 2008

Written on 28 Ноября 2008 . Posted in MS SQL Server

ОГЛАВЛЕНИЕ

В данной статье мы вкратце рассмотрим самые важные изменения, произошедшие в системе безопасности SQL Server® с выходом версии 2008. Первое, на что обращаешь внимание, — это отсутствие средства «Настройка контактной зоны», которое присутствовало в SQL Server 2005. Параметры протокола, которые раньше были доступны в этом средстве, теперь перенесены в диспетчер конфигураций. Включение и выключение функций теперь выполняется через новую среду управления на основе политик, реализованную в SQL Server 2008.

Усовершенствования в области шифрования

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

Первое нововведение стало возможным благодаря функции расширенного управления ключами (EKM) — она имеется в SQL Server 2008 Enterprise, Developer и Evaluation. EKM зарегистрировать в SQL Server системы управления корпоративными ключами и аппаратные модули безопасности (HSM), разработанные сторонними компаниями. После регистрации устройства пользователь может хранить ключи на этом модуле.

Кроме того, производитель модуля может добавить дополнительные возможности шифрования (например, задать правила устаревания и замены ключей). В некоторых конфигурациях это позволяет закрыть доступ к данным тем администраторам, которые не являются членами группы администраторов системы. Криптографические инструкции T-SQL выполняют шифрование и расшифровку данных с применением ключей, хранящихся на внешнем EKM-устройстве.

Еще одна новая функция, прозрачное шифрование, позволяет шифровать файлы баз данных, не меняя код приложений. Шифрование и расшифровка входных и выходных данных и журналов происходит в режиме реального времени. При этом используется ключ шифрования баз данных (DEK), хранящийся в загрузочной записи базы данных: так его можно использовать при восстановлении. Ключ DEK защищен сертификатом, которых находится в основной базе данных сервера. Схема на рис. 1 демонстрирует архитектуру, обеспечивающую прозрачное шифрование данных.

Рис 1 Архитектура прозрачного шифрования данных

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

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

Функции прозрачного шифрования данных позволяют применять алгоритмы AES и 3DES. Шифрование файла базы данных выполняется на уровне страницы, причем страница шифруется перед записью на диск, а потом расшифровывается во время считывания в память. Для шифрования резервных файлов тоже используется ключ шифрования базы данных.

Для расшифровки базы данных необходимо иметь доступ к сертификату или асимметричному ключу, использованному при шифровании. В противном случает базу данных восстановить не удастся. Ключи следует хранить, пока резервная копия не перестанет использоваться.

Усовершенствования в области проверки подлинности

Kerberos — это сетевой протокол, предоставляющий высоконадежное средство взаимной проверки подлинности между клиентом и сервером (или двумя участниками системы безопасности). Kerberos помогает снизить число уязвимостей в случае атак с приманкой и попыток перехвата «посредником». Этот протокол имеет отношение к проверке подлинности Windows® NTLM, но он надежнее и производительнее.

Чтобы использовать Kerberos для взаимной проверки подлинности, необходимо, чтобы экземпляр SPN, относящийся к SQL Server, был зарегистрирован в Active Directory®, а драйвер клиента при подключении должен предоставить зарегистрированный SPN. В SQL Server 2008 проверка подлинности Kerberos была распространена на все сетевые протоколы, включая TCP, именованные каналы, общую память и адаптеры VIA. По умолчанию драйвер клиента выводит нужный SPN из экземпляра SQL Server, к которому он подключается. SPN можно также указать явным образом в параметрах строки подключения: это повышает уровень безопасности и контроля, упрощает поиск и устранение неполадок.

Службы IIS перестали использоваться для доступа к веб-службам ASP.NET, диспетчеру отчетов и серверу отчетов. В SQL Server 2008 службы отчетов обрабатывают все запросы на проверку подлинности, проводя их через новую специальную подсистему, поддерживающую как проверку подлинности Windows, так и нестандартные варианты проверки.

Службы отчетов теперь размещают Microsoft® .NET Framework и технологии ASP.NET, встроенные в среду CLR SQL Server, кроме того, они используют возможности HTTP.SYS, предлагаемые в операционной системе. Сервер отчетов включает в себя прослушиватель HTTP, который принимает запросы, направленные на URL-адрес и порт, указанные во время настройки сервера. Резервированием и регистрацией URL теперь управляет непосредственно сервер отчетов (через HTTP.SYS).

Аудит системы безопасности

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

Подсистема аудита SQL Server работает быстрее, чем функция трассировки, а среда SQL Server Management Studio упрощает создание и контроль журналов аудита. Теперь можно проводить более подробные проверки: отслеживать инструкции SELECT, INSERT, UPDATE, DELETE, REFERENCES и EXECUTE для отдельных пользователей. Более того, подсистема аудита польностью поддерживает инструкции T-SQL CREATE SERVER AUDIT и CREATE SERVER AUDIT SPECIFICATION, а также связанные с ними инструкции ALTER и DROP.

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

Следующий этап — создание спецификаций аудита. В спецификации аудита сервера собирается информация об экземпляре SQL Server; в нее включаются объекты, относящиеся к серверу: данные учетных записей, членство в серверных ролях. Там же имеется информация о базе данных, контролируемая в основной базе данных, например сведения о правах доступа к базе. При создании спецификации аудита вы указываете, в какой аудит будут поступать наблюдаемые события. Вы можете создать несколько аудитов сервера и несколько спецификаций аудита, но аудит может иметь только одну активную спецификацию в каждый конкретный момент времени.

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

События подсистемы аудита SQL Server, используемые в спецификациях аудита сервера, объединяются в коллекции связанных событий. Они предоставляются в виде групп действий аудита. Если такую группу добавить в спецификацию аудита, можно будет отслеживать события, включенные в группу. К примеру, существует группа действий аудита DBCC_GROUP, предоставляющая доступ к командам DBCC. Отдельно же команды DBCC включаться в аудит не могут.

Всего существует 35 групп действий аудита сервера, причем некоторые из них тесно связаны друг с другом. Например, группы SUCCESSFUL_LOGIN_GROUP, FAILED_LOGIN_GROUP и LOGOUT_GROUP. Также есть тип действий аудита AUDIT_ CHANGE_GROUP, который можно использовать для проверки самого процесса аудита.

Илон Маск рекомендует:  Проиндексированные страницы в Яндексе

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

Скажем, действие SELECT можно использовать для проверки запросов SELECT, обращенных к отдельной таблице, источником которых является пользователь Mary, или роль FINANCE_DEPT, или роль базы данных Public. Нельзя не отметить, что все это предоставляет широчайшие возможности контроля и дает большой запас гибкости при настройке аудита.

Отчеты о зависимостях

В модуле составления отчетов о зависимостях появилось новое представление каталогов и новые системные функции. Если использовать sys.sql_expression_dependencies, sys.dm_sql_referencing_entities и sys.dm_sql_referenced_entities, можно создавать отчеты по зависимостям между серверами, зависимостям между базами данных и SQL-зависимостями в пределах базы данных как для привязанных к схеме объектов, так и для непривязанных.

Новые роли баз данных

В роли баз данных, включенные в базу данных msdb, был внесен ряд изменений. Роль db_dtsadmin была переименована в db_ssisadmin, db_dtsltduser — в db_ssisltduser, db_dtsoperator — в db_ssisoperator. Для поддержки обратной совместимости старые роли при обновлении серверов добавляются как члены новых ролей.

Кроме этого, были добавлены новые роли для поддержки новых функций SQL Server 2008. В частности, появились новые роли для групп серверов (ServerGroupAdministratorRole и ServerGroupReaderRole), управления на основе политик (PolicyAdministratorRole), сборщика данных (dc_admin, dc_operator, and dc_proxy). В базе данных хранилища данных управления также появились новые роли для сборщика данных (mdw_admin, mdw_writer, and mdw_reader).

Безопасность файловых потоков

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

Данные файловых потоков должны храниться в файловых группах типа FILESTREAM — это специальные файловые группы, содержащие не сами файлы, а системные каталоги. Эти каталоги, так называемые контейнеры данных, формируют интерфейс между хранилищем ядра базы данных и хранилищем файловой системы.

Что касается безопасности, то данные файловых потоков защищаются точно так же, как и любые другие данные: на уровне таблиц или столбцов предоставляются разрешения. Единственная учетная запись, получающая разрешения NTFS для контейнера файловых потоков, — это учетная запись, под которой работает учетная запись службы SQL Server. При открытии базы данных SQL Server ограничивает доступ к контейнерам данных файловых потоков. Исключение делается только в том случае, если доступ осуществляется при помощи транзакций T-SQL и OpenSqlFilestream API.

Управление на основе политик

Управление на основе политик — это новая система управления SQL Server, появившаяся в SQL Server 2008. Она позволяет создавать политики для тестирования и создания отчетов по различным аспектам SQL Server. Политики можно применять к отдельным базам данных, отдельным экземплярам SQL Server или ко всем управляемым экземплярам SQL Servers.

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

В SQL Server 2008 некоторые не самые важные функции отключены по умолчанию для сокращения возможностей атаки. Управление на основе политик позволяет выборочно включать и отключать функции. После этого можно по расписанию проверять конфигурацию и получать уведомления в случае несоответствия параметров конфигурации установленной политике.

Управление на базе политик объединяет связанные свойства и предоставляет их в пользование в виде компонентов, называемых аспектами. Например, аспект под названием Surface Area Configuration включает такие свойства как Ad Hoc Remote Queries, CLR Integration, Database Mail, OLE Automation, Remote DAC, SQL Mail, Web Assistant и xp_cmdshell. Можно создать политику, которая будет включать свойство CLR Integration, а все остальные — отключать. В политике могут задаваться сложные условия, например можно отключить свойство Database Mail на всех экземплярах SQL Server, кроме Customer_Response.

После создания политики можно ее проверить на свех серверах и создать отчет о том, какие серверы не соответствуют требованиям. Чтобы согласовать параметры серверов с требованиями политики, нужно нажать кнопку «Настроить». Политику следует проверять регулярно, чтобы контролировать состояние серверов. Аспекты Surface Area Configuration доступны для ядра базы данных, служб аналитики и служб отчетов.

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

Разные аспекты различаются способностью принудительно изменять параметры. Это зависит от того, могут ли связанные инструкции DDL работать в режиме, отличном от режима автофиксации. В некоторых случаях аспект настраивает параметры экземпляра ядра базы данных, но администратор после этого может вернуть прежние значения. Некоторые аспекты могут вызываться серверным триггером. В таком случае пользователи с низкими привилегиями не смогут изменить параметры, да и вероятность случайного изменения параметров администратором снижается. Здесь администратору приходится временно отключать политику, чтобы изменить значения. Другая группа аспектов только создает отчеты о состоянии свойства, но менять его не может. Так работает политика, проверяющая длину симметричного и асимметичного ключа (см. рис. 2).

Рис 2 Аспекты для асимметричных ключей

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

Windows Server 2008

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

В заключение

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

Автор: Рик Бихэм
Иcточник: TechNet Magazine
Опубликована — 14.04.2008

Лабораторная работа №11. Система безопасности SQL Server


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

Общая схема системы безопасности SQL Server

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

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

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

Разрешения к объектам назначаются с помощью инструкций GRANT (предоставить), REVOKE (отозвать) и DENY (запретить). Запрет привилегии замещает собой ее предоставление, а предоставление привилегии замещает собой ее отзыв. Пользователю может быть предоставлено множество разрешений к объекту (индивидуальных, наследованных от роли, обеспеченных принадлежностью к роли public). Если какая-либо из этих привилегий запрещена, для пользователя блокируется доступ к объекту. В противном случае, если какая-либо из привилегий предоставляет разрешение, пользователь получает доступ к объекту.

Разрешения объекта достаточно детализированы. Существуют отдельные разрешения для каждого из возможных действий (SELECT, INSERT, UPDATE, RUN и т.д.) над объектом.

Выбор типа логина и настройка режима аутентификации

SQL Server поддерживает два типа логинов (имен входа):

логин Windows (логин для локальной учетной записи Windows, логин для доменной учетной записи Windows, логин для группы Windows);

логин SQL Server.

При использовании логинов Windows в системные таблицы базы данных master записывается информация об идентификаторе учетной записи или группы Windows (но не пароль). Аутентификация (т. е. проверка имени пользователя и пароля) производится обычными средствами Windows при входе пользователя на свой компьютер.

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

Предпочтительный вариант логина для пользователя — это логин Windows, при этом не для учетной записи, а для группы (лучше всего для локальной доменной группы). Преимуществ у такого решения множество:

пользователю достаточно помнить один пароль — для входа на свой компьютер;

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

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

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

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

значительно упрощается предоставление разрешений для новых учетных записей.

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

на предприятии вполне может не оказаться домена Windows (если, например, сеть построена на основе NetWare или UNIX);

пользователи SQL Server могут не входить в домен (например, если они подключаются к SQL Server из филиалов или через Web-интерфейс с домашнего компьютера).

Таким образом, выбор используемых типов логинов зависит от многих факторов и в каждом конкретном случае решение принимается индивидуально. Логины Windows — это удобство и защищенность, логины SQL Server- это большая гибкость и независимость от администратора сети.

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

В режиме аутентификации Windows SQL Server полностью доверяет (делегирует) аутентификацию операционной системе.

В смешанном режиме аутентификация Windows и самого сервера сосуществуют независимо друг от друга.

Третьего варианта, в котором использование логинов Windows было бы запрещено, не предусмотрено: логины этого типа доступны всегда.

Установленный при инсталляции режим аутентификации можно изменить в утилите Management Studio выбрав нужный переключатель в группе «Серверная проверка подлинности» на странице «Безопасность» диалогового окна «Свойства сервера».

Установите переключатель в положение «Проверка подлинности SQL Server и Windows». Таким образом, вы включите смешанный режим аутентификации, в котором и будут выполняться остальные упражнения. Для того чтобы изменение режима аутентификации вступило в силу сервер нужно перезапустить.

Создание логина и настройка его параметров

Логины любого типа создаются одинаково:

при помощи графического интерфейса — из окна «Создание имени входа». Это окно открывается с помощью команды «Создать имя входа…» контекстного меню узла «Безопасность | Имена входа» дерева обозревателя объектов в SQL Server Management Studio;

из скрипта — при помощи команды CREATE LOGIN.

Например, команда на создание логина SQL Server с именем User1 и паролем P@sswOrd (для всех остальных параметров будут приняты значения по умолчанию) может выглядеть так:

CREATE LOGIN User1 WITH PASSWORD = ‘P@sswOrd’;

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

Если вы создаете логин SQL Server, вам придется ввести его имя и пароль. Пароль всегда чувствителен к регистру, а логин — только тогда, когда чувствительность к регистру была определена при установке SQL Server. Конечно, кроме имени и пароля для логинов можно определить множество других параметров. Некоторые из них перечислены ниже.

База данных по умолчанию, к которой по умолчанию будет подключаться пользователь при входе на SQL Server. По умолчанию используется база данных master. Как правило, менять этот параметр не следует: код для перехода к нужной базе данных при подключении обеспечивает клиентское приложение.

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

На вкладке «Состояние» свойств логина можно настроить для этого логина дополнительные параметры:

Разрешение на подключение к ядру СУБД — по умолчанию для всех логинов устанавливается значение «Предоставить», т. е. подключаться к SQL Server разрешено. Значение «Запретить», как правило, используется только в одном случае — когда вы предоставляете доступ на SQL Server логину для группы Windows, а одному или нескольким членам этой группы доступ нужно запретить. Поскольку явный запрет всегда имеет приоритет перед разрешением, то достаточно будет создать свои собственные логины Windows для этих пользователей и установить для них значение «Запретить».

Имя входа (Включено/Отключено) — конечно, все логины по умолчанию включены. Обычно отключать их приходится только в ситуации, когда какой-то пользователь увольняется или переходит на другую работу. Чтобы сэкономить время, достаточно просто отключить данный логин, а при появлении пользователя со схожими рабочими обязанностями переименовать этот логин, поменять пароль и включить. Заниматься предоставлением разрешений заново в этом случае не придется.

Имя входа заблокировано — установить этот флажок вы не можете (только снять его). Учетная запись пользователя блокируется автоматически после нескольких попыток неверного ввода пароля для логина SQL Server, если такая блокировка настроена на уровне операционной системы, а для логина установлен флажок «Требовать использование политики паролей».

Разрешения на уровне сервера. Фиксированные серверные роли

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

На графическом экране работа с ролями сервера производится или из свойств логина (вкладка «Роли сервера»), или из свойств самой серверной роли (узел «Роли сервера» дерева обозревателя объектов Management Studio).

Отметим несколько моментов, связанных с серверными ролями:

набор серверных ролей является фиксированным. Вы не можете создавать свои серверные роли (в отличие от ролей базы данных);

для предоставления прав на уровне всего сервера необязательно использовать серверные роли. Вы вполне можете предоставить эти права напрямую логину (при помощи вкладки «Разрешения» окна свойств сервера). По умолчанию каждый логин обладает на уровне всего сервера двумя правами: CONNECT SQL (т. е. подключаться к серверу, это право предоставляется логину напрямую) и VIEW ANY DATABASE (т. е. просматривать список баз данных, это право пользователь получает через серверную роль public);

серверные роли используются только в специальных случаях. Для большинства пользователей настраивать их не нужно.

Серверных ролей не так много, поэтому приведем их полный список с комментариями:

public — права этой роли автоматически получают все, кто подключился к SQL Server, и лишить пользователя членства в этой роли нельзя. Обычно эта роль используется для предоставления разрешений всем пользователям данного сервера;

sysadmin — логин, которому назначена эта роль, получает полные права на весь SQL Server (и возможность передавать эти права другим пользователям);

serveradmin — эта роль для оператора, который обслуживает сервер. Можно изменять любые настройки работы сервера и отключать сервер, но получать доступ к данным и изменять разрешения нельзя;

securityadmin — эта роль для того, кто выдает разрешения пользователям, не вмешиваясь в работу сервера. Он может создавать логины для обычных пользователей, изменять их пароли, предоставлять разрешения в базах данных. Однако предоставить кому-либо административные права или изменять учетную запись администратора эта роль не позволяет;

bulkadmin — роль для сотрудников, которые выполняют массовые загрузки данных в таблицы SQL Server;

dbcreator — эта роль позволяет создавать базы данных на SQL. Server (а тот, кто создал базу данных, автоматически становится ее владельцем);

diskadmin — эта роль позволяет выполнять любые операции с файлами баз данных на диске;


processadmin — эта роль предназначена для выполнения единственной обязанности: закрытия пользовательских подключений к серверу (например, зависших);

setupadmin — права этой роли позволяют подключать внешние серверы SQL Server.

Пользователи баз данных. Схемы

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

Логины и пользователи баз данных — это совершенно разные объекты. Разделение логинов и пользователей баз данных обеспечивает большую гибкость. Например, пользователь, который входит от имени одного и того же логина, сможет работать в разных базах данных от имени разных пользователей.

Создать пользователя базы данных можно:

В среде Management Studio вызвав команду «Создать пользователя…» в контекстном меню подузла «Безопасность | Пользователи» узла конкретной базы данных дерева обозревателя объектов. В открывшемся окне «Пользователь базы данных — Создать», снимок экрана с которым приведен ниже, необходимо указать два обязательных параметра: имя нового пользователя и выбрать соответствующий ему логин (Windows или SQL Server).

При помощи команды CREATE USER.

Изменение свойств пользователя и его удаление производится из того же контейнера в Management Studio, что и создание пользователя, а также при помощи команд ALTER USER/DROP USER.

В SQL Server 2000 и в более старых версиях объект пользователя базы данных нес на себе двойную нагрузку: во-первых, он использовался для предоставления разрешений в базе данных, а во-вторых, имя пользователя базы данных использовалось для идентификации объектов. Например, обращение к таблице по полному ее имени могло выглядеть так: SELECT * FROM MyServer.MyDatabase.User1.Table1;

Если разработчик использовал в коде приложения просто имя объекта (например, SELECT * FROM Table1), то при подключении к серверу из этого приложения от имени другого пользователя могли возникнуть проблемы, поскольку вместо User1 подставлялось текущее имя пользователя (а если объект с таким полным именем не был обнаружен, то имя специального пользователя dbo).

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

SELECT * FROM MyServer.MyDatabase.Schema1.Table1;

Схема формально определяется как набор объектов в базе данных, объединенных общим пространством имен. Проще всего представить себе схему как некий логический контейнер в базе данных, которому могут принадлежать таблицы, представления, хранимые процедуры, пользовательские функции, ограничения целостности, пользовательские типы данных и другие объекты базы данных. Этот контейнер удобно использовать как для именования объектов и их логической группировки, так и для предоставления разрешений. Например, если в базе данных есть набор таблиц со связанными данными, удобно поместить их в одну схему и предоставлять пользователям разрешения на эту схему (т. е. на этот набор таблиц).

Пользователю можно назначить схему по умолчанию. В эту схему SQL Server будет по умолчанию помещать объекты, которые создает этот пользователь. Кроме того, искать объекты, к которым обращается пользователь (например, в случае запроса вида SELECT * FROM Table1), SQL Server также будет в первую очередь в его схеме по умолчанию.

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

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

несколько пользователей (через группы Windows или роли баз данных) могут владеть одной и той же схемой. При этом один пользователь может являться владельцем сразу нескольких схем;

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

упрощается предоставление разрешений для наборов объектов в базе данных.

Список схем можно увидеть в подузле «Безопасность | Схемы» узла конкретной базы данных дерева обозревателя объектов Management Studio.

При создании любой базы данных в ней автоматически создаются четыре специальных пользователя:

dbo (от database owner) — пользователь-владелец базы данных. Он автоматически создается для того логина, от имени которого была создана эта база данных. Конечно же, как владелец, он получает полные права на свою базу данных (при помощи встроенной роли базы данных db_owner);

guest (гость) — этот специальный пользователь предназначен для предоставления разрешений всем логинам, которым не соответствует ни один пользователь в базе данных. По умолчанию у этого пользователя нет права login для базы данных, и, следовательно, работать он не будет. Этот пользователь используется чаще всего для предоставления разрешений логинам на какие-то учебные/тестовые базы данных или на базы данных-справочники, доступные только на чтение;

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

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

Управление безопасностью SQL сервера средствами Microsoft Access (документация)

Эта статья рассказывает о том, как управлять безопасностью SQL сервера, используя Access совместно с библиотекой SQL Distributed Management Objects (SQL-DMO) в Visual Basic for Applications (VBA)

Вступление

Эта статья в основном ориентирована на разработчиков ADP проектов. Возможно, Вы знакомы с 2-мя вещами относительно безопасности SQL сервера. Во-первых, безопасность — это не опция, как это было в Jet. Во-вторых, модель безопасности SQL сервера отличается от модели безопасности Access. Даже если у Вас имеются приблизительные понятия о безопасности SQL сервера, эта статья научит Вас, как настроить ее для защиты ресурсов вашего проекта.

Эта статья также может быть полезна администраторам SQL серверов. Решения, предлагаемые здесь, могут помочь им в управлении безопасностью сервера средствами Access. Из содержания этой статьи администраторы могут узнать об управлении безопасностью сервера без использования графических средств Enterprise Manager или запуска Transact SQL (T-SQL) скриптов из Query Analyzer. Изучив, как управлять безопасностью сервера, используя Access, администраторы получат альтернативу создания более быстрого по исполнению решения.

Cтатью можно условно разделить на две части о безопасности SQL Server 7.0 и SQL Server 2000. В начале рассматривается концепция безопасности SQL сервера, акцентируя внимание на том, как управлять безопасностью, используя Access. Этих сведений достаточно для разработки многопользовательских приложений с разными группами пользователей, имеющих четко определенные права на использование объектов сервера. Вторая часть статьи демонстрирует программные решения, основанные на управлении объектами SQL-DMO (SQL Distributed Management Objects) средствами Microsoft Visual Basic® for Applications (VBA). Поскольку SQL-DMO имеет иерархическую модель построения объектов, очень похожую на модель построения объектов Microsoft Office, то все, что необходимо, это больше узнать об объектах, свойствах, методах, и событиях SQL-DMO относительно безопасности. Ко всему прочему, программистам Access 2002 не обойтись без программирования функций настройки безопасности в VBA, поскольку они недоступны из меню Безопасность базы данных (Database Security).

Концепция безопасности SQL сервера

Этот раздел состоит из 4-х основных частей. Ознакомление начинается с описания аутентификации — процесса проверки пользователя на право доступа к базе данных сервера. Используя Enterprise Manager, SQL сервер предоставляет два вида аутентификации. Первая часть раздела показывает различия и сходства между ними.

Далее говорится о понятии авторизованного пользователя, служащего для осуществления соединения с сервером. Авторизованные пользователи называются логинами (logins). Два типа логинов соответствуют двум моделям аутентификации SQL сервера. Логины отвечают за права доступа к серверу.

Третья часть знакомит с понятием пользователей (users). SQL сервер резервирует понятие users, как понятие, характеризующее пользователей баз данных. Обычно на сервере существует несколько логинов, каждый логин ассоциируется с несколькими пользователями — одним на каждую базу данных, доступ к которой разрешен для данного логина. Логины и пользователи могут принадлежать фиксированным ролям, которые описывают набор разрешений. Вы можете управлять поведением логинов и пользователей, управляя их принадлежностью фиксированным ролям сервера и фиксированным ролям базы данных соответственно.

В четвертой части говорится об определяемых пользователем (user-defined) ролях баз данных.

Аутентификация

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

SQL сервер поддерживает два вида аутентификации: SQL Server и Microsoft Windows® (или Windows NT® с SQL Server 7.0). Эти два вида определяют, кто осуществляет проверку логина: SQL сервер или Windows. При Windows аутентификации пользователи имеют доверительные учетные записи для доступа к SQL серверу. Эти учетные записи проверяет Windows, но SQL сервер «знает» имя учетной записи. Windows аутентификация дает пользователям возможность авторизоваться в Windows и на SQL сервере вводом только одного пароля. При аутентификации SQL Server SQL сервер сам осуществляет авторизацию. При любом типе аутентификации SQL сервер должен знать авторизованные логины.

Есть плюсы и минусы и у первого и у второго типа, однако предпочтительней Windows аутентификация. В Windows осуществляется более сложная процедура авторизации, и она освобождает администратора SQL сервера от необходимости управлять учетными записями. С другой стороны, не все операционные системы, поддерживающие SQL сервер, поддерживают Windows авторизацию. Например, Microsoft Data Engine (MSDE), установленный с Microsoft Office 2000 и Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) установленный с Office XP: и тот и другой вариант могут работать в системе Windows 98, которая не поддерживает Windows аутентификацию. Или SQL Server 7.0 и MSDE, работающие в системе Windows 95. Некоторые организации могут предпочесть возможность контролировать доступ к ресурсам базы данных на уровне администратора БД вместо более глобального уровня администратора Windows.

Любой экземпляр SQL сервера может иметь любой из двух типов аутентификации, которые можно установить в Enterprise Manager (я расскажу о третьем типе далее в этой статье). Документация SQL сервера определяет термин смешанного (mixed) режима подключения к SQL серверу, который поддерживает и Windows, и SQL Server аутентификацию. Если сервер поддерживает только Windows аутентификацию, тогда сервер имеет Windows (или Windows NT) тип аутентификации. По умолчанию MSDE устанавливается со смешанным типом аутентификации. MSDE 2000, напротив, по умолчанию устанавливается с Windows аутентификацией. Разработчики и администраторы, использующие Enterprise Manager, могут изменять тип аутентификации, используя графические средства. Так же любое приложение может использовать библиотеку SQL-DMO для изменения типа аутентификации сервера.

Логины и фиксированные серверные роли

Проект ADP содержит окно базы данных (Database window) похожее на традиционное для Jet решений. Однако проект ADP соединяется с сервером через OLE DB соединение в отличие от базы данных Jet. В проекте ADP тип логина указывается в диалоговом окне Параметры соединения (Data Link Properties). Для вызова этого диалога: из окна базы данных выберите меню Файл (File), в меню выберите Соединение (Connection).

Диалоговое окно Параметры соединения позволяет выбрать сервер баз данных, логин, и базу данных, с которой проект соединится через OLE DB. Подключаться к серверу можно двумя способами. При первом выбирается использование внутренней проверки безопасности Windows NT (use Windows NT integrated security). Это называется Windows аутентификацией. Выбрав эту опцию, не нужно указывать логин и пароль. Это потому, что Windows авторизует пользователя во время запуска Windows. Когда выбрана опция использования внутренней безопасности, проект ADP посылает логин Windows на SQL сервер при попытке создать с ним OLE DB соединение. Выбрав вторую опцию (use a specific user name and password), необходимо указать логин SQL сервера. В поле имени пользователя (user name) должно быть введено стандартное имя логина SQL сервера — логина, поддерживаемого данным SQL сервером. Пароль опционален, однако строго рекомендуется использовать пароль, поскольку совместно с логином, пароль предоставляет дополнительный уровень безопасности.

Хотя ввод логина является ключевым моментом при создании OLE DB соединения в проекте ADP, логин сам по себе не является достаточным для предоставления прав на выполнение каких-либо задач на сервере или с базой данных. Существует понятие членства логина в фиксированных серверных ролях, которое позволяет проекту ADP выполнять некоторые серверные функции, такие как, создание новых баз данных и управление логинами. В зависимости от версии SQL сервера, к которому подключается ADP проект, существует семь или восемь фиксированных серверных ролей. SQL Server 7.0 и MSDE предоставляют семь фиксированных серверных ролей, а SQL Server 2000 и MSDE 2000 — восемь. SQL Server Books Online (BOL) содержит исчерпывающую документацию о фиксированных серверных ролях, включая T-SQL выражения для назначения и удаления логинов из членства в ролях. К примеру, раздел Roles в BOL, рассказывает о фиксированных серверных полях и соответствующем наборе разрешений для доступа к базам данных, таких как просмотр и запись в таблицы.

Илон Маск рекомендует:  Фиксированный дизайн. Основы

Следующая таблица содержит краткий обзор имен фиксированных серверных ролей и краткое их описание. Выполнив системную хранимую процедуру sp_helpsrvrole можно получить список имен фиксированных серверных ролей. Исполнение системной хранимой процедуры sp_srvrolepermission выводит подробный перечень функций для каждой фиксированной серверной роли. Есть различия между фиксированными серверными ролями в 7.0 и 2000 версиях SQL сервера. Например, bulkadmin является новой ролью в SQL Server 2000. Дополнительно, выражение DROP DATABASE было доступно только для роли sysadmin в SQL Server 7.0, а SQL Server 2000 дает право на выполнение этой процедуры также и членам роли dbcreator.

Имя фиксированной серверной роли

Описание фиксированной серверной роли

sysadmin Выполнение любого выражения сервера или базы данных serveradmin Администрирование сервера, конфигурация, запуск, остановка. setupadmin Администрирование присоединенных (linked) серверов и право запуска хранимых процедур на этапе запуска сервера. securityadmin Управление логинами, паролями. Может давать право на создание новых баз данных. processadmin Выполнение команды KILL. dbcreator Создание, изменение, переименование и удаление баз данных. diskadmin Управление файлами на диске. bulkadmin Выполнение выражений BULK INSERT.

Логин sa является специальным логином SQL сервера. Этот логин входит в группу sysadmin и предоставляет право на выполнение любых функций на сервере. SQL сервер создает этот логин на этапе установки и его нельзя удалить. Сразу после окончания установки логин sa не имеет пароля. Необходимо задать пароль для sa для обеспечения безопасности Вашего сервера баз данных, особенно для серверов со смешанным типом аутентификации. Помните: сервера с Windows аутентификацией не принимают и не обрабатывают логины SQL сервера.

При установке SQL сервера на Windows 98 или Windows ME сервер всегда устанавливается со смешанным типом аутентификации, потому он может принимать логины SQL сервера. Типы аутентификации по умолчанию различаются для SQL Server 7.0 и MSDE от SQL Server 2000 и MSDE 2000, устанавливаемых на Windows 2000 и Windows NT. Для SQL Server 7.0 и MSDE процесс установки по умолчанию устанавливает сервер со смешанным типом аутентификации. Напротив, SQL Server 2000 и MSDE 2000 по умолчанию устанавливаются с Windows аутентификацией. Кроме того, процесс установки версии 2000 назначает членов группы администраторов Windows членами фиксированной серверной роли sysadmin. Потому эти логины подобны логину sa, который имеет полный контроль над сервером.

Пользователи и фиксированные роли баз данных

Обычно пользователи получают доступ к SQL Server, чтобы работать с одной или несколькими базами данных. Для этой цели SQL сервер имеет механизм приведения в соответствие логинов с базами данных. Так же как SQL сервер может иметь один или больше логинов, каждый логин может иметь одну или больше учетных записей, с ним ассоциированных. Однако одна учетная запись соответствует только одному логину (за двумя исключениями). Документация SQL сервера определяет учетные записи как пользователей баз данных (или пользователей — users). Каждый пользователь базы данных имеет доступ к этой базе данных.

SQL сервер может предоставить пользователям баз данных право владения базой данных и разрешения на использование объектов базы данных. SQL сервер обеспечивает назначение разрешений внутри базы данных на двух независимых уровнях. На первом уровне Вы можете назначить один или несколько кластеров разрешений пользователю. Документация SQL сервера определяет эти кластеры как фиксированные роли базы данных. Я назвал их кластерами разрешений, поскольку они могут объединять в себе разрешения на многие объекты базы данных. Например, одна фиксированная роль (db_datareader) позволяет Вам читать данные из любой таблицы базы данных-не только из какой-то одной или двух определенных таблиц. На втором уровне Вы можете назначать разрешения на уровне конкретных объектов базы данных. SQL сервер позволяет сочетать оба способа: пользователь может быть членом одной или нескольких фиксированных ролей базы данных а также иметь специфические разрешения на конкретные объекты базы данных. Я расскажу об управлении разрешениями на конкретные объекты базы данных в следующем разделе.

Два специальных пользователя могут ассоциироваться с более чем одним логином. Это пользователи dbo и guest. Пользователь dbo является членом фиксированной серверной роли sysadmin, и может создавать объекты на сервере, такие как базы данных или таблицы базы данных. Пользователь, логин которого не принадлежит фиксированной серверной роли sysadmin, также может создавать объекты баз данных, такие, как таблицы.

Видимость объектов в Окне базы данных проекта ADP зависит от того, принадлежит ли логин проекта фиксированной серверной роли sysadmin. Если логин проекта ADP является членом роли sysadmin, в Окне базы данных показываются все объекты, владельцем которых является пользователь dbo, без круглых скобок после их имен. Для пользователей dbo все объекты, владельцами которых являются другие пользователи, кроме dbo, показываются с именем пользователя, заключенного в круглые скобки после имени объекта базы данных. В случае если логин проекта ADP не принадлежит роли sysadmin, имена объектов, владельцем которых является этот пользователь, показываются в окне базы данных без круглых скобок. Имена объектов, владелец которых пользователь dbo показываются с суффиксом (dbo). Объекты, владельцы которых не являются пользователями логина проекта ADP или пользователя dbo, не показываются в Окне базы данных.

Большинство логинов имеют пользователей для каждой базы данных, к которой они имеют доступ. Однако логин может получить доступ к базе данных даже без пользователя в этой базе данных, если база данных имеет специального пользователя. Имя этого пользователя — guest, это пользователь для логинов без учетных записей в базе данных. Пользователь guest не ассоциирован ни с каким логином. Вы можете назначать разрешения для пользователя guest так же как и для любого другого пользователя базы данных. Это позволяет настраивать права для логинов не имеющих специфических пользователей в конкретной базе данных.

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

Один из наиболее быстрых и простых способов предоставления пользователю прав на выполнение функций в базе данных это назначение пользователя членом фиксированных ролей баз данных. Существует девять фиксированных ролей баз данных на SQL сервере, они одинаковы для SQL Server 7.0 и SQL Server 2000. Имена и краткое описание фиксированных ролей баз данных приведены в следующей таблице. Выполнив системную хранимую процедуру sp_helpdbfixedrole можно получить список имен фиксированных ролей баз данных. Вызов системной хранимой процедуры sp_dbfixedrolepermission вернет табличный набор со специфическими разрешениями для каждой фиксированной роли базы данных.


Имя фиксированной роли базы данных

Описание фиксированной роли базы данных

db_owner Неограниченные полномочия в базе данных. db_accessadmin Для добавления и удаления пользователей базы данных. db_datareader Для чтения из таблиц и представлений (views) базы данных. db_datawriter Для добавления (insert), редактирования (update) и удаления (delete) записей таблиц и представлений базы данных. db_ddladmin Для выполнения любого оператора SQL Data Definition Language (или выполнения этих функций с помощью графического интерфейса) в базе данных. db_securityadmin Для управления членством пользователей в ролях, разрешением доступа к объектам и владением базой данных. db_backupoperator Для создания резервных копий (backing) и восстановления из них (restoring) базы данных. db_denydatareader Для запрета (или отмены) разрешения на любую выборку (SELECT) из конкретного объекта базы данных. db_denydatawriter Для запрета (или отмены) разрешения на любой оператор INSERT, UPDATE или DELETE, выполняемый с конкретным объектом базы данных.

Назначение пользователям фиксированных ролей базы данных сказывается на функциях, которые пользователи смогут выполнять. Есть возможность изменять влияние членства пользователя в фиксированной роли баз данных назначением разрешений пользователю на конкретные объекты базы данных. Для простоты, в этом разделе об этом не говорится, однако следующий раздел посвящен назначению разрешений на конкретные объекты и определенным пользователем (user-defined) ролям базы данных. В Окне базы данных не показываются никакие таблицы, пока пользователь для логина проекта ADP не является членом фиксированной роли базы данных db_datareader. Пользователь без членства в роли db_backupoperator не может выполнять команды меню: Архивировать (Backup) или Восстановить (Restore) (меню Сервис (Tools), подменю Служебные программы (Database Utilities)). Соответственно, не могут создавать таблицы или другие объекты в базе данных пользователи без членства в фиксированной роли базы данных db_ddladmin. Средствами Окна базы данных, пользователь без членства в роли db_ddladmin может редактировать объекты сервера, такие как таблицы и представления, или создавать новые, однако, отредактированные и созданные объекты не будут сохранены в базе данных.

Члены фиксированной роли db_owner базы данных могут выполнять все функции предоставляемые членством в любой другой роли базы данных. Так как логины этой роли могут создавать базы данных без членства в фиксированной серверной роли sysadmin, члены группы db_owner не обязаны быть пользователями dbo. В дальнейшем, члены фиксированной серверной роли sysadmin могут выполнять любые функции в базе данных, которые может выполнить член группы db_owner. Дополнительно, таблицы и представления, созданные пользователем dbo, обладают улучшенной видимостью по сравнению с таблицами и представлениями, созданным членами роли db_owner, которые в то же время не являются членами фиксированной серверной роли sysadmin.

Определяемые пользователем (User-defined) роли базы данных и назначение разрешений

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

Шесть имен разрешений на объекты и их описание показано в следующей таблице. Вы можете назначать эти разрешения конкретным объектам базы данных. Если Вы хотите раздать разрешения на все объекты, Вам придется назначать разрешение для каждого объекта базы данных. Однако Вам лучше использовать фиксированные роли базы данных в случае, если необходимо дать разрешение на все объекты базы данных. Например, если Вы хотите дать разрешение на SELECT для всех таблиц и представлений (включая те, что еще не созданы), проще включить пользователя в фиксированную роль базы данных db_datareader. Если Ваша цель — ограничить разрешение на SELECT только для одного или двух существующих представлений, тогда создайте определяемую пользователем роль базы данных, дайте разрешение на SELECT для этих представлений, и включите в эту роль тех пользователей, которым нужно дать специальные разрешения.

SELECT Просмотр записей в таблице или представлении. INSERT Добавление новых записей в таблицу или представление. UPDATE Изменение содержимого записей таблицы или представления. DELETE Удаление записей из таблиц или представлений. REFERENCES Позволяет создавать внешние ключи к первичному ключу или уникальному индексу таблицы или определяемой пользователем табличной функции (row-returning user-defined function). EXECUTE Выполнение хранимой процедуры или определяемой пользователем функции.

Разрешения на конкретные объекты базы данных могут иметь три состояния (статуса): разрешено (granted), запрещено (denied), и отменено (revoked). Если Вы даете доступ к объекту, значение разрешения будет иметь статус granted. Соответственно, если Вы запрещаете доступ, разрешение будет denied. Если вы отменяете разрешение, поменяйте разрешения с granted или denied на revoked. Отмененные разрешения не разрешают и не запрещают доступ к объекту.

Поскольку допускается включать пользователя в несколько фиксированных и определяемых пользователем ролей базы данных, возможен конфликт разрешений между ролями. Вы можете использовать эти конфликты для тонкой настройки Вашей системы безопасности. Например, пользователь включен в фиксированную роль базы данных db_datareader, дающую ему право выполнять запросы SELECT из всех таблиц и представлений базы данных. Однако Вы можете запретить чтение из таблицы продаж пользователю, имеющему разрешение чтения данных из всех таблиц, чтобы скрыть от него конфиденциальную информацию в таблице продаж. Соответственно, члены фиксированной роли базы данных db_denydatareader не могут адресовать запросы SELECT к любой таблицы базы данных, даже если пользователи включены в определяемую пользователем роль базы данных, которая дает разрешение на чтение из некоторых конкретных таблиц. Разрешение denied всегда переопределяет разрешение granted.

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

Программирование безопасности SQL Server

SQL-DMO является контейнерным приложением (Automation application), назначение которого — администрирование SQL Server. Поскольку SQL-DMO является API для SQL Server Enterprise Manager, Вы можете программировать на SQL-DMO все, что могут предоставить Вам графические средства Enterprise Manager, включая управление всеми аспектами безопасности SQL Server. Этот аспект SQL-DMO особенно полезен для проектов, использующих MSDE и MSDE 2000, потому что в их состав не входит Enterprise Manager. Дополнительно, программистам Access 2002 необходимо изучить некоторые программные решения по управлению безопасностью, поскольку Access 2002 не имеет возможности управлять безопасностью с помощью меню (как это было в Access 2000).

В Access Вы можете программировать, используя SQL-DMO так же, как используются любые другие COM объекты. Ваш VBA проект должен при этом использовать библиотеку SQL-DMO. Microsoft SQLDMO Object Library — имя этой объектной библиотеки. Добавьте ссылку на библиотеку с помощью команды References (меню Tools). Файл DLL с библиотекой включен в MSDE и MSDE 2000. Другие версии SQL Server содержат DLL и файл справки, который Вы можете открыть прямо из окна Visual Basic Editor (VBE). Использующие Microsoft Office XP Developer Edition, могут установить версию SQL сервера, которая включает в себя файл справки по SQL-DMO.

На рисунке представлен фрагмент иерархической модели SQL-DMO с объектами для примеров кода, расположенных далее по тексту. Обратите внимание, что объект SQLServer расположен во главе иерархии. Многие приложения могут соединяться с SQL Server посредством объекта SQLServer. Наследники объекта SQLServer являются коллекциями объектов для логинов и баз данных, а также для индивидуальных объектов, таких как, IntegratedSecurity, которые предоставляют возможность управления безопасностью SQL Server. Последующий пример использует свойство SecurityMode объекта IntegratedSecurity для демонстрации того, как установить режим аутентификации SQL Server. Членами коллекции Databases являются индивидуальные базы данных, каждая из которых имеет собственные коллекции и объекты. Одна из этих коллекций — коллекция Users. Другая коллекция используется для фиксированных и определяемых пользователем ролей базы данных (DatabaseRoles). Членство отдельных пользователей в коллекции DatabaseRoles определяет способность пользователей читать и модифицировать объекты коллекций Tables и Views.

Перед началом рассказа об SQL-DMO важно знать, что DLL для SQL-DMO отличается для SQL Server 7 и SQL Server 2000. Две версии SQL-DMO различаются как минимум в двух аспектах. Во-первых, версия для SQL Server 2000 включает в себя новые объекты, появившиеся в SQL Server 2000, а также улучшенные традиционные. Также версия SQL-DMO для SQL Server 2000 дополнительно содержит традиционные объекты для управления SQL Server 7.0. Имена объектов для 2000 обычно оканчиваются 2 (например, SQLServer2 для новых объектов, вместо SQLServer для традиционных). Во-вторых, программами, использующими SQL-DMO для SQL Server 2000 нельзя управлять SQL Server 7.0 (даже если программы используют традиционные имена объектов SQL-DMO). Однако, используя библиотеку SQL-DMO для SQL Server 7.0 можно управлять SQL Server 2000. Это ограничение является результатом изменения файловых форматов библиотек при переходе к новой версии; синтаксис скрипта SQL-DMO не претерпел изменений.

Различие между версиями SQL-DMO требует внимательного отношения к тому, какую версию библиотеки Вы будете использовать в Вашем проекте. Если необходимо, чтобы приложение SQL-DMO работало с серверами SQL Server 7.0 и SQL Server 2000, необходимо писать программы, используя SQL-DMO для SQL Server 7.0. С другой стороны, если необходимо использовать преимущество SQL Server 2000, тогда Вам необходимо разрабатывать Ваше приложение, используя библиотеку для SQL Server 2000. Поскольку статья демонстрирует технику программирования безопасности, используя SQL-DMO, я использовал версию SQL-DMO для SQL Server 7.0. В любом случае, код выглядит одинаковым для разных версий, кроме случаев, когда Вы используете новые объекты, представленные в SQL Server 2000.

Подключение к SQL серверу

Подобно тому, как вы можете подключиться к SQL Server двумя способами, используя диалог Свойства соединения в проекте ADP, Вы можете подключиться к SQL Server двумя способами через SQL-DMO. Один способ соответствует аутентификации средствами SQL Server. Используя этот способ, Ваш код должен посылать имя сервера, логин, и пароль через SQL-DMO на сервер. Вы можете использовать параметр «имя сервера» для указания различных экземпляров SQL Server на локальной рабочей станции или на другой рабочей станции в сети. SQL-DMO также позволяет Вам соединяться, указав только имя сервера. В этом случае, SQL-DMO посылает идентификатор авторизованного в Windows пользователя на экземпляр SQL сервера. Для того чтобы использовать этот способ, следует установить свойство LoginSecure сервера в значение True.

На следующем листинге показана пара процедур, демонстрирующих синтаксис подключения к экземпляру SQL Server, используя логин SQL Server. Первая процедура определяет три строковых параметра для имени сервера (srvname), логина (suid) и пароля (pwd). Далее она посылает их второй процедуре, которая начинается инициализацией объекта SQLServer. Этот объект представляет экземпляр сервера. Затем вторая процедура вызывает метод Connect объекта SQLServer. Этот метод принимает на вход три параметра. Демонстрируется синтаксис передачи переменных имени сервера, логина и пароля.

Изменение режима аутентификации

Одним из основных преимуществ, которое дает SQL-DMO программистам, работающим с MSDE и MSDE 2000, является реализация этой возможности, которая иначе была бы им недоступна. Вызвано это тем, что Enterprise Manager не включен в установочный пакет MSDE или MSDE 2000. К примеру, клиентский компонент SQL Server Enterprise Manager дает возможность администраторам графическими средствами изменить режим аутентификации сервера:Windows аутентификация или смешанный режим. Проект ADP не предоставляет такой возможности. Однако следующая пара процедур позволит Вам изменить режим аутентификации сервера, даже не имея возможности использовать Enterprise Manager.

Первая процедура определяет значение одного параметра и посылает его второй процедуре. Этот параметр определяет один из двух режимов аутентификации. В комментариях к процедуре показаны имена двух предопределенных констант в соответствии с режимом аутентификации. Смешанный режим аутентификации является режимом по умолчанию. SQL-DMO позволяет установить режим аутентификации, который недоступен даже в Enterprise Manager. Другими словами, Вы можете использовать SQL-DMO для указания серверу принимать только логины SQL Server.

Вторая процедура выполняет подключение к серверу с использованием идентификатора пользователя Windows. Затем она устанавливает свойство SecurityMode объекта IntegratedSecurity для сервера в значение параметра, переданного ей из первой процедуры. Если значение этого свойства меняет режим аутентификации, режим не сменится, пока Вы не остановите и не перезапустите сервер. Однако вызов метода Stop объекта сервера не может моментально остановить сервер. Вы должны подождать, пока сервер не остановится. При помощи свойства Status объекта сервера Ваша программа может следить за сообщением, что сервер остановился. Процедура использует цикл, ожидая смены значения Status на SQLDMOSvc_Stopped. Далее процедура выполняет метод Start объекта SQLServer. Вызов этого метода установит новый режим аутентификации для сервера.

Открытие проекта ADP

Иногда бывает необходимо из Вашего приложения SQL-DMO программно открыть проект ADP. Технология открытия проекта ADP не требует использования SQL-DMO, однако, Ваше приложение SQL-DMO может использовать преимущество такой возможности. В последнем примере кода этой статьи (прямо перед заключительным разделом) демонстрируется процедура создания нового пользователя. Необходимость открытия ADP проекта основана на генерации строки соединения при установке приложения, основанного на ADP проекте.

Следующий пример кода демонстрирует, как открыть существующий ADP проект. В коде, представленном ниже, именем проекта ADP является msdn_test_security.adp. Пример кода позволяет открыть проект ADP в режиме аутентификации Windows или в режиме аутентификации SQL Server. Снова используется две процедуры. Список параметров в первой процедуре — CallOpenADPWindowsOrSQLServer — относительно большой, что связано с необходимостью указать имя сервера, базу данных, путь и название файла ADP проекта, логин SQL Server и пароль, а также логическую переменную. Логическая переменная определяет открытие проекта с Windows или с SQL Server аутентификацией. При указании Windows аутентификации нет необходимости в логине и пароле, поскольку проект ADP автоматически ссылается на идентификатор пользователя Windows. Вторая процедура использует эти параметры для открытия ADP проекта.

Перед описанием второй процедуры было бы полезным объяснить некоторые особенности кода. Во-первых, процедура, открывающая проект ADP уже работает в сессии Access. Поэтому необходимо создать новый экземпляр Access для проекта, который мы намерены открыть. Для создания сессии Access используется OLE класс.

Во-вторых, любой существующий проект ADP всегда открывается с сохраненными во время предыдущего открытия параметрами соединения с сервером. Поэтому программа должна открыть проект, используя старые параметры подключения, а потом эти параметры сменить. Новые параметры подключения можно назначить только открытому проекту. После закрытия проекта новые параметры соединения сохраняются, пока пользователь не изменит их в диалоге Параметры соединения. (Однако объектная модель офиса позволяет Вам скрыть и сделать недоступной команду меню Соединение в меню Файл).

В-третьих, сессия с открытым проектом ADP будет жить, пока живет переменная, представляющая эту сессию. Используйте описание Public в определении сессии для открываемого проекта. Объявляется переменная в разделе описаний модуля. Это позволит сессии жить, пока живет открывающий ее проект, то есть наш код. Для переменной сессии Access в примере используется имя appAccess, и следующее объявление в разделе описаний стандартного модуля. Поскольку объявление должно быть в верхней части модуля, Вы его не увидите в коде ни для первой, ни для второй процедуры.

Public appAccess as Access.Application

Вторая процедура — OpenADPWindowsOrSQLServer — начинается выводом сообщения, спрашивающим оставить ли сессию открытой после завершения процедуры. Если пользователь ответит «нет», процедура установит параметры соединения для проекта, а затем закроет сессию без шанса посмотреть изменения. Далее проект запускает новую сессию Access при помощи функции CreateObject. Аргументы этой функции различаются в зависимости от версии Access, которую Вы используете (в коде описаны особенности использования версий Access 2000 или Access 2002). После создания сессии для проекта процедура вызывает метод OpenAccessProject для добавления проекта ADP в сессию. Аргументом для этого метода служит путь вместе с именем файла проекта. Расширение .adp опционально. После открытия проекта процедура переопределяет его параметры соединения при помощи метода OpenConnection объекта CurrentProject. Процедура переопределяет соединения, используя две различные строки соединения в зависимости от значения переменной bolWindowsLogin. Эта Логическая переменная устанавливается первой процедурой для указания того, какой тип авторизации требуется установить для проекта. На последнем шаге процедуры сессия закрывается, если пользователь ответил положительно на вопрос в окне сообщения перед открытием сессии.

Добавление и удаление логинов

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

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

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

Вторая процедура после соединения с сервером инициализирует объект login. Этот объект — член коллекции Logins, показанной на рисунке. Далее процедура устанавливает три параметра для логина: его имя (login_name), базу данных по умолчанию (defaulf_db_name) и пароль (password). Операции по простому присвоению работают с двумя первыми аргументами. Для установки пароля для логина SQL сервера вызывается метод SetPassword объекта login. При установке пароля для нового логина используйте пустую строку в качестве первого аргумента метода; укажите пароль для нового логина вторым аргументом. В нашем примере пароль для логина login_name определен как «password» (без кавычек). Добавление логина login_name завершается вызовом метода Add коллекции Logins.

Также Вы можете использовать метод SetPassword для переопределения пароля существующего логина. Первый аргумент метода SetPassword в этом случае — текущий пароль. Однако если Вы не знаете текущего пароля, Вы можете указывать первым аргументом пустую строку-так же, как при создании пароля для нового логина. Создание или изменение логина возможно в том случае, если Ваш текущий логин (под которым Вы осуществили соединение с сервером) входит в одну из фиксированных ролей сервера: sysadmin или securityadmin. Неважно, каким способом Вы меняете пароль: программно или другими средствами. В примере используется логин sa, входящий в фиксированную роль сервера sysadmin.

В нескольких следующих строках второй процедуры создается логин для группы Windows group с именем msdn_OS_users. В моем случае эта группа Windows из трех идентификаторов пользователей Windows, в действительности группа Windows могла быть как группой пользователей локального компьютера, так и домена сервера Windows. Процесс создания логина начинается с инициализации нового объекта login (lgn1). При попытке повторного использования lgn1 без переинициализации (обнуления), возникнет ошибка выполнения, напоминающая о том, что требуется новый объект. Процедура использует название группы Windows, состоящее из двух частей. Первая часть — имя сервера Windows, вторая — имя группы сервера Windows. Обратный слэш служит разделителем. Базой данных по умолчанию для второго логина снова указывается база данных your_db_name. Поскольку второй логин создается для аутентификации Windows, нет необходимости устанавливать пароль. Однако необходимо установить свойство Type в SQLDMOLogin_NTGroup. Это значение соответствует внутренней константе, соответствующей логину группы Windows. При добавлении логина SQL Server не нужно устанавливать значение свойства Type, поскольку оно задано по умолчанию для логинов SQL сервера. Заканчивается создание второго логина вызовом метода Add коллекции Logins.

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

После печати членов коллекции Logins процедура удаляет два вновь созданных логина поименно: login_name и YOUR_SERVER_NAME\msdn_OS_users. Этот пример демонстрирует использование коллекции Logins ее метода Remove и свойства Name логина, которого Вы хотите удалить. Для подтверждения удаления двух логинов процедура выводит список логинов повторно из коллекции Logins. Откройте окно Immediate и сравните два списка логинов: после добавления и удаления двух логинов.

Создание логина с пользователем — участником роли db_datareader

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

Пример кода заключительной части статьи демонстрирует процедуру добавления нового логина для аутентификации SQL Server, а также создает пользователя для этого логина в базе данных your_db_name. В этом примере новый пользователь также включается в фиксированную роль базы данных db_datareader. Наконец, открывается проект ADP, основываясь на новом логине и пользователе.

После соединения с сервером и создания нового логина login_name, код создает нового пользователя. Далее назначаются свойства Name и Login для пользователя. Свойство Login означает логин, под которым пользователь соединяется — login_name в нашем примере. После этого пользователь готов к добавлению в коллекцию Users базы данных. Отметим, что синтаксис добавления нового пользователя соответствует синтаксису иерархии объектов. Метод Add для нового пользователя применяется к коллекции Users принадлежащей в свою очередь объекту database. Database — член коллекции Databases принадлежащей объекту сервера (SQLserver). После создания пользователя требуется одна или несколько строчек для внесения пользователя в фиксированную роль базы данных db_datareader. Метод по добавлению пользователя в роль называется AddMember. В нашем случае метод AddMember элемента коллекции DatabaseRoles добавляет пользователя в роль базы данных. Этот метод берет в качестве параметра строковое выражение свойства Name объекта нового пользователя.

Как только настройка безопасности нового логина и пользователя завершены, вызывается процедура OpenADPWindowsOrSQLServer. В предыдущих листингах есть пример использования этой процедуры. В нашем случае открывается файл msdn_test_security.adp, основываясь на логине login_name. Для проверки работоспособности логина откройте таблицы базы данных your_db_name. Дополнительно, работоспособность нового логина можно проверить в диалоговом окне Параметры соединения, указав логин your_login.

Если попытаться повторно запустить процедуру MakeLoginWithDatareaderUser попытка закончится ошибкой. Это потому, что логин your_login уже существует. Ошибка возникнет при попытке повторно его добавить. Попытка запустить процедуру может закончиться неудачей и по другой причине: Вы не закрыли проект, подключенный к БД с этим логином. Вы можете написать стандартную обработку ошибок VBA для обработки ошибок времени выполнения. Подобные ошибки могут сопровождать выполнение предыдущих примеров. Я предпочел не углубляться в обсуждение обнаружения ошибок времени выполнения, акцентируя внимание на вопросах безопасности SQL сервера.

Заключение

Безопасность SQL Server построена на принципах, отличных от тех, что использовали программисты в базах данных Jet. Тем не менее, SQL Server Books Online тщательно документирует правила по безопасности SQL Server. Эта статья переводит основные правила BOL в специфические правила, цель которых использовать проект Access с SQL Server. Примеры кода, приведенные в этой статье, демонстрируют, как управлять безопасностью SQL Server с помощью Access.

Enable disable a security policy in SQL Server

I have created a Security Policy to implement Row Level Security (RLS) in SQL Server 2020. There is some specific time in a month when the security policy will be applicable. I am planning to write a job which will enable or disable the Security Policy, but I am not getting the SQL command to disable or enable it.

I know that I need to set the check_policy to OFF

Visually I am able to do it using Sql Server Management Studio by right clicking on the Security Policy.

2 Answers 2

Using TheGameiswar’s answer works I wanted to add that if you get an error saying

Cannot find the object «[security filter name]» because it does not exist or you do not have permissions.

Append [security] before the filter name

For example if your filter name is «ProfilesFilter»

This is probably a given for some but I am less fluent with SQL/SQL Server

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL