Роли ms sql сервера: SQL Server 2005, PUBLIC, SYSADMIN, SERVERADMIN

Управление ролями с помощью программы SQL Server Enterprise Manager

Управление ролями с помощью программы SQL Server Enterprise Manager

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

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

Для добавления пользователя с серверной ролью в программе SQL Server Enterprise Manager выполните перечисленные ниже действия.

1. В окне Microsoft SQL Servers программы SQL Server Enterprise Manager откройте папку Security используемого сервера и выберите папку Server Roles для отображения фиксированного набора серверных ролей. 

РИС. 3.24. Новая учетная запись отображается в консольном окне Microsoft SQL Servers программы SQL Server Enterprise Manager

2. Щелкните правой кнопкой мыши на изменяемой роли и выберите команду Properties из контекстного меню или щелкните дважды на изменяемой роли. При этом на экране появится диалоговое окно Server Role Properties (Свойства серверной роли), показанное на рис. 3.25.

3. Чтобы указать учетную запись для данной роли, щелкните на кнопке Add и выберите учетную запись из списка доступных учетных записей.

4. Для удаления учетной записи из роли выберите нужную запись (или несколько записей) из списка учетных записей, которые в данный момент являются членами роли, а затем щелкните на кнопке Remove (Удалить).

5. Щелкните на кнопке OK, чтобы закрыть диалоговое окно Server Role Properties.

СОВЕТ

Для включения или удаления учетной записи из серверной роли можно использовать вкладку Server Roles (Серверные роли) диалогового окна SQL Server Login Properties, которое рассматривалось выше в главе. 

РИС. 3.25. Диалоговое окно Server Role Properties с примером использования учетной записи для роли Process Administrators (Администраторы процессов)

Дня создания учетной записи с ролью базы данных в программе SQL Server Enterprise Manager выполните ряд действий.

1. В окне Microsoft SQL Servers программы SQL Server Enterprise Manager откройте папку Roles (Роли) для той базы данных, в которой необходимо создать новую роль. После этого на экране будут показаны все имеющиеся роли базы данных.

2. Щелкните правой кнопкой мыши на нужной роли и выберите команду Properties в контекстном меню или щелкните дважды на изменяемой роли. При этом на экране появится диалоговое окно Database Role Properties (Свойства роли базы данных), показанное на рис. 3.26.

3. Для добавления новой роли к базе данных щелкните на кнопке Add и выберите одного или нескольких пользователей из списка всех пользователей этой базы данных.

4. Для удаления пользователя из роли выберите одного или нескольких пользователей из списка всех пользователей роли и щелкните на кнопке Remove.

5. Щелкните на кнопке OK, чтобы закрыть диалоговое окно Database Role Properties. 

РИС. 3.26. Диалоговое окно Database Role Properties с примером добавления роли db_accessadmin

СОВЕТ

В SQL Server 2000, помимо предварительно заданных ролей базы данных, предусмотрено использование определенных пользователем ролей базы данных. Эти роли позволяют настроить способ доступа к данным и выполняемым операциям с базой данных (на этом этапе станет активной кнопка Permissions). Более информацию о ролях базы данных можно найти в справочных руководствах SQL Server Books Online.

Администрирование инфраструктуры базы данных SQL

Модуль 1: Безопасность SQL Server

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

• Проверка подлинности подключений к SQL Server
• Разрешение имён входа для доступа к базам данных
• Авторизация на серверах
• Частично автономные базы данных

Лабораторная работа: Проверка подлинности пользователей
 

• Создание логинов
• Создание пользователей базы данных
• Исправление ошибок входа в систему
• Настройка безопасности для восстановленных баз данных

Модуль 2: Назначение ролей базы данных и сервера

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

• Работа с ролями сервера
• Работа с фиксированными ролями базы данных
• Создание пользовательских ролей базы данных

Лабораторная работа: Назначение ролей базы данных и сервера

• Назначение ролей сервера
• Назначение фиксированных ролей базы данных
• Назначение пользовательских ролей базы данных
• Проверка безопасности

Модуль 3: Авторизация пользователей для доступа к ресурсам

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

• Авторизация пользователей для доступа к объектам
• Авторизация пользователей для выполнения кода
• Настройка разрешений на уровне схемы

Лабораторная работа: Авторизация пользователей для доступа к ресурсам

• Предоставление, отказ и отмена прав на объекты
• Предоставление права EXECUTE на код
• Предоставление разрешений на уровне схемы

Модуль 4: Защита данных с помощью шифрования и аудита

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

• Аудит доступа к данным в SQL Server
• Осуществление аудита SQL Server
• Управление аудитом SQL Server
• Защита данных с помощью шифрования

Лабораторная работа: Использование аудита и шифрования

• Работа с аудитом SQL Server
• Шифрование столбца как «Всегда зашифрованно»
• Шифрование базы данных с помощью TDE

Модуль 5: Модели восстановления и стратегии резервного копирования

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

• Общие сведения о стратегиях резервного копирования
• Журналы транзакций SQL Server
• Планирование стратегий резервного копирования

Лабораторная работа: Понимание моделей восстановления SQL Server

• Планирование стратегии резервного копирования
• Настройка моделей восстановления базы данных

Модуль 6: Резервное копирование баз данных SQL Server

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

• Резервное копирование баз данных и журналов транзакций
• Управление резервными копиями базы данных
• Расширенные параметры баз данных

Лабораторная работа: Резервное копирование баз данных SQL Server

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

Модуль 7: Восстановление баз данных SQL Server

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

• Работа с SQL Server Agent
• Управление заданиями SQL Server Agent
• Управление несколькими серверами

Лабораторная работа: Автоматизация управления SQL Server

• Создание задания для SQL Server Agent
• Проверка работы
• Расписание задания
• Настройка основных и целевых серверов

Модуль 8: Настройка параметров безопасности для SQL Server Agent

Другие модули в этом курсе продемонстрировали необходимость минимизации разрешений, предоставляемых пользователям, в соответствии с принципом «наименьших привилегий». Это означает, что пользователи имеют только разрешения, которые им необходимы при выполнении их задач. Такая же логика применяется к предоставлению разрешений SQL Server Agent.. Хотя удобно выполнять все задания в контексте учетной записи службы SQL Server Agent и настраивать эту учетную запись как администратора, в этом случае могут возникнуть угрозы безопасности. Важно понять, как создать среду минимальных привилегий безопасности для заданий, выполняемых в SQL Server Agent.
 

• Понимание безопасности SQL Server Agent
• Настройка учетных данных
• Настройка учетных записей-посредников

Лабораторная работа: Настройка параметров безопасности для SQL Server Agent

• Анализ проблем с агентом SQL Server
• Настройка учетных записей
• Настройка учетной записи-посредника
• Настройка и тестирование контекста безопасности для работы

Модуль 9: Мониторинг SQL Server с помощью оповещений и уведомлений

Одним из ключевых аспектов управления Microsoft SQL Server является мониторинг, который позволяет убедиться, что есть сведения о проблемах и событиях, которые происходят на сервере и как они происходят. SQL Server регистрирует множество сведений о проблемах, и можно настроить его автоматически сообщать о возникновении этих проблем с помощью предупреждений и уведомлений. Наиболее распространенный способ — оповещение по электронной почте, с помощью которого администраторы баз данных SQL Server получают информацию о событиях, представляющих интерес. Этот модуль охватывает конфигурацию Database Mail, оповещений и уведомлений для экземпляра SQL Server и настройки уведомлений для Microsoft Azure SQL Database..
 

• Мониторинг ошибок SQL Server
• Настройка компонента Database Mail
• Настройка операторов, оповещений и уведомлений
• Оповещения в базе данных Azure SQL

Лабораторная работа: Мониторинг SQL Server с помощью оповещений и уведомлений
 

• Настройка компонента Database Mail
• Настройка операторов
• Настройка оповещений и уведомлений
• Тестирование оповещений и уведомлений

Модуль 10: Введение в управление SQL Server с помощью PowerShell

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

• Начало работы с Windows PowerShell
• Настройка SQL Server с помощью PowerShell
• Администрирование SQL Server с помощью PowerShell
• Управление базами данных Azure SQL Server с помощью PowerShell

Лабораторная работа: Администрирование SQL Server с помощью PowerShell
 

• Начало работы с PowerShell
• Использование PowerShell для изменения настроек SQL Server

Модуль 11: Отслеживание доступа к SQL Server с расширенными событиями

Мониторинг показателей производительности дает отличный способ оценить общую производительность решения для базы данных. Однако есть случаи, когда нужно выполнить более подробный анализ активности в экземпляре Microsoft SQL Server, для устранения неполадок и определения способов оптимизации производительности рабочей нагрузки. Расширенные события SQL Server — это гибкая и легкая система обработки событий, встроенная в Microsoft SQL Server Database Engine. В этом модуле рассматриваются архитектурные концепции, стратегии устранения неполадок и сценарии использования расширенных событий.
 

• Расширенные события Основные понятия
• Работа с расширенными событиями

Лабораторная работа: Расширенные события

• Использование сессии System_Health в расширенных событиях
• Отслеживание разбиение страниц с использованием расширенных событий

Модуль 12: Мониторинг SQL Server

Microsoft SQL Server Database Engine может работать в течение длительного времени без непосредственного наблюдения администратора. Однако, если регулярно контролировать активность на сервере базы данных, можно предсказать потенциальные проблемы до их возникновения. SQL Server предоставляет ряд инструментов, которые можно использовать для мониторинга текущей активности и записи сведений о предыдущей деятельности. Вам нужно ознакомиться с тем, что делает каждый из инструментов и как их использовать. Легко перегружать объем вывода, который могут обеспечить инструменты мониторинга, поэтому вам также необходимо изучить методы анализа их продукции.
 

• Мониторинг активности
• Захват и управление данными производительности
• Анализ собранных данных производительности
• SQL Server Utility

Лабораторная работа: Мониторинг SQL Server

• Мониторинг активности

По окончании этого модуля слушатели смогут:

• Вести мониторинг текущей активности.
• Собирать и управлять данными о производительности.
• Анализировать собранные данные о производительности.
• Настраивать SQL Server Utility.

Модуль 13: Устранение неполадок SQL Server

Администраторы базы данных в Microsoft SQL Server должны максимально быстро устранить неполадки базы, если она используется в работе критических бизнес-приложений. Для решения проблем должна быть реализована методология устранения неполадок в целом и перечислены наиболее распространенные проблемы, которые могут возникнуть при работе с системами SQL Server.
 

• Методология устранения неполадок SQL Server
• Разрешение проблем, связанных со службами
• Устранение общих неполадок

Лабораторная работа: Устранение неполадок общего характера

• Устранение неполадок с регистрацией SQL
• Устранение неполадок со службами
• Устранение неполадок со входом в Windows
• Устранение неполадок с выполнением задания
• Устранение неполадок с производительностью

Модуль 14: Импорт и экспорт данных

Хотя большое количество данных, находящихся в системе Microsoft SQL Server, вводится непосредственно пользователями, которые запускают прикладные программы, часто приходится перемещать данные из других источников и из SQL Server. SQL Server предоставляет набор инструментов, которые можно использовать для передачи и ввода данных, некоторые из этих инструментов, таких как утилита BCP (Bulk Copy Program) и SQL Server Integration Services, являются внешними по отношению к движку базы данных, другие инструменты, такие как оператор BULK INSERT и функция OPENROWSET, внедряются в механизм базы данных. С помощью SQL Server также можно создавать приложения уровня данных, которые пакуют все таблицы, представления и объекты экземпляра, связанные с пользовательской базой данных, в единицу развертывания. В этом модуле показаны инструменты и методы для импорта и экспорта данные в SQL Server и обратно.
 

• Передача данных от SQL Server
• Импорт и экспорт табличных данных
• Использование программы BCP и инструкции BULK INSERT для импорта данных
• Развертывание и обновление приложений уровня данных

Лабораторная работа: Импорт и экспорт данных

• Импорт данных в Excel с помощью мастера импорта
• Импорт текстового файла с разделителями с помощью BCP
• Импорт текстового файла с разделителем с помощью BULK INSERT
• Создание и тестирование пакета SSIS для извлечения данных
• Разверните приложение уровня данных

Шаг 5. Создание базы данных и настройка подключения программы к SQL-серверу



Шаг 5. Создание базы данных и настройка подключения программы к SQL-серверу


Пожалуйста, включите JavaScript в браузере!

Шаг 5. Создание базы данных и настройка подключения программы к SQL-серверу

Чтобы создать базу данных на SQL-сервере и настроить подключение к ней, выполните следующие действия:

1. В поле Имя SQL-сервера укажите имя компьютера (или его IP-адрес), на котором установлен SQL-сервер, и имя SQL-экземпляра, например, MYCOMPUTER\SQLEXPRESS.

   Нажав на кнопку Обзор, расположенную напротив поля Имя SQL-сервера, вы можете выбрать SQL-сервер в том сегменте сети, в котором расположен компьютер.

   В случае удаленного подключения к SQL-серверу необходимо убедиться, что на SQL-сервере включена поддержка TCP/IP в качестве клиентского протокола. Нужный вам SQL-сервер может отсутствовать в списке SQL-серверов, если на компьютере, на котором расположен SQL-сервер, не запущена служба браузера SQL-сервера.

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

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

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

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

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

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

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

   Описание параметров соединения с сервером базы данных вы можете найти на сайте Microsoft по ссылке: параметры строки соединения.

   Пример:

   • Connection Timeout=30;Integrated Security=SSPI;MultiSubnetFailover=true

   Не рекомендуется указывать в поле Дополнительные параметры соединения параметры Data Source и Database, так как они определяются в полях Имя SQL-сервера и Имя базы данных.

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

Kaspersky Security не обеспечивает канальное шифрование при передаче данных между сервером и базой данных SQL. В целях безопасности данных вам необходимо самостоятельно выполнить шифрование данных для передачи по каналам связи.

В начало

Не удается найти страницу | Autodesk Knowledge Network

(* {{l10n_strings.REQUIRED_FIELD}})

{{l10n_strings.CREATE_NEW_COLLECTION}}*

{{l10n_strings.ADD_COLLECTION_DESCRIPTION}}

{{l10n_strings.COLLECTION_DESCRIPTION}}
{{addToCollection.description.length}}/500

{{l10n_strings.TAGS}}
{{$item}}

{{l10n_strings. PRODUCTS}}

{{l10n_strings.DRAG_TEXT}}

{{l10n_strings.DRAG_TEXT_HELP}}

{{l10n_strings.LANGUAGE}}
{{$select.selected.display}}

{{article.content_lang.display}}

{{l10n_strings.AUTHOR}}

{{l10n_strings. AUTHOR_TOOLTIP_TEXT}}

{{$select.selected.display}}

{{l10n_strings.CREATE_AND_ADD_TO_COLLECTION_MODAL_BUTTON}}
{{l10n_strings.CREATE_A_COLLECTION_ERROR}}

Инструкция по настройке AlwaysOn MS SQL Server 2016

В данной статье мы изучим пошаговую настройку группы высокой доступности SQL Server 2016 Standart Edition AlwaysOn для двух узлов.

Для настройки мы возьмем стенд с двумя виртуальными машинами:

• PRD-1CSQL-01 – это будет основной экземпляр, где наши базы будут нормально работать.
• PRD-1CSQL-02 – это будет наш второстепенный, с меньшей мощностью.

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

Добавляем роль кластера

Группы доступности AlwaysON в SQL Server созданы на основе служб отказоустойчивой кластеризации Windows, необходимо объединить реплики AG в один кластер Windows.

Открываем Диспетчер серверов нажимаем «Управление», «Добавить роль и компоненты», выбираем свой сервер и в списке «Компоненты» устанавливаем флажок

Отказоустойчивая кластеризация:

Можно перейти к следующему этапу после установки данного компонента на всех серверах, которые будут включены в группу доступности.

Объединение серверов в отказоустойчивый кластер

Открываем Диспетчер серверов и нажимаем «Средства» — «Диспетчер отказоустойчивости кластеров».

Нажимаем «Создать кластер…» чтобы запустить мастер:

Вводим имена всех серверов, которые будут участвовать в группе доступности, и нажимаем «Далее».

В следующем окне вводим имя называемого кластера и его уникальный IP-адрес, нажимаем «Далее».

Подтверждаем введенные данные и переходим на этап «Создания нового кластера». После завершения создания, в сводке отразится информация о новом кластере:

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

Включаем группы доступности AlwaysOn на каждом сервере

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

На вкладке AlwaysOn High Aviliability устанавливаем флажок «Включить« и нажимаем «ОК«. Это не вступит в силу пока служба SQL Server не будет перезапущена. Повторяем это на всех серверах SQL.

Создание группы доступности

Запускаем SQL Server Management Studio и начинаем создавать группу доступности.

В нашем случае, мы сделали базу «Base_AlwaysON» её и будем копировать во вторичную реплику. База уже находится в режиме полного восстановления, и выполнена полное резервное копирование, поэтому база уже соответствует требованиям группы доступности AlwaysOn.

В обозревателе объекта нажимаем ПКМ «Высокий уровень доступности Always On» и выбираем «Мастер создания групп доступности».

Есть пару опций, которые требуют объяснения:

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

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

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

Добавляем вторичную реплику и устанавливаем режим доступности в зависимости от требований.

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

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

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

Выбираем синхронизацию данных.

После завершения работы мастера щелкаем ПКМ на группе доступности в обозревателе объектов и нажимаем «Показать панель мониторинга»:

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

В итоге мы видим что отработка происходит успешно и группа доступности между серверами MS SQL реплицируется.

Зеркалирование базы данных на MS SQL Server 2005/2008

Основной принцип, используемый в зеркалировании баз данных — это связь между двумя экземплярами MSSQL сервера (как правило, физически это два сервера, находящиеся в локальной сети либо в Интернет) и поддержание полной идентичности базы данных на обоих серверах. Один из серверов выступает как главный, к нему подключены пользователи базы данных. Второй сервер является зеркальным и не поддерживает в этом состоянии подключений к базе данных. Главный сервер при изменениях в базе данных доставляет зеркальному журнал с транзакциями, благодаря которому вторая база, зеркальная, всегда идентична основной, главной базе. Зеркалирование позволяет сохранить работоспособность базы данных при выходе из строя одного из сервера базы данных. Зеркалирование поддерживается 3 режимами работы: Асинхронный режим — изменения в базе данных главного сервера доставляются зеркальному не моментально, при этом главный сервер способен продолжать работу, не дожидаясь подтверждения о выполнении транзакции от зеркального. Минус такого решения очевиден — при внезапном сбое главного сервера и переходе зеркального сервера на роль главного возможна утрата части данных. Плюс — нет падения в производительности. Синхронный режим — изменения, происходящие в основной базе данных после каждой транзакции немедленно доставляются в журнале транзакций зеркальному серверу. Основной сервер готов продолжать работу после успешного внесения изменений в базу данных на обеих серверах. Минус решения — существенное падение быстродействия при связи между серверами через медленные каналы связи (Интернет), в локальных сетях и при небольших нагрузках падение быстродействия несущественно. Плюс такого решения — полная идентичность базы данных на обоих серверах в любой момент времени Защищенный синхронный режим — изменение ролей серверов при сбое главного может происходить автоматически, при использовании третьего сервера-наблюдателя. Минус решения — необходимо использовать дополнительно третий сервер, плюс — полная идентичность базы данных на главном и зеркальном серверах, а также автоматическое управление ее статусом на каждом из серверов. Изменение ролей можно проводить вручную в интерфейсе SQL Managemebt Studio либо при выполнении скрипта — см. далее. При изменении ролей зеркальный сервер становится главным и готов принимать подключения клиентов. Главный же сервер после восстановления работоспособности становится зеркальным. В статье описывается процесс настройки зеркалирования базы данных в асинхронном режиме, с ручным переключением ролей и восстановлением после сбоев. Имеем 2 сервера с установленными MSSQL Server 2008. Функция зеркалирования начала стабильно работать и в SQL Server 2005 после установки SP4, поэтому тем, у кого установлен SQL Server 2005 необходимо скачать с сайта производителя и установить данный сервис-пак. Автору статьи удавалось настроить зеркалирование на SQL Server 2005 SP4, однако при, казалось бы, абсолютно одинаковых условиях аналогичная настройка на других парах серверов не всегда приводила к успеху, венчая кропотливую работу ошибкой MSSQLServer_1418 (описание ниже). На SQL Server 2008 процент успеха повыше. Адрес главного сервера — 192.168.1.11, адрес зеркального - 192.168.1.12. Имя базы данных на главном сервере — TCU_DB Будем использовать проверку подлинности соединения по сертификатам, как наиболее простой способ аутентификации в среде Интернет. В локальной сети также можно настроить зеркалирование через интерфейс SQL Server Management Studio (Task -> Mirror) по Windows или SQL Server аутентификации. Прочтите Использование сертификатов для зеркального отображения базы данных Откройте в брандмауэре на обоих серверах входящий и исходящий TCP порт 5022. Также откройте порты TCP/UDP 1433-1434. Активируйте в SQL Server Configuration Manager протокол Named Pipes Выполняйте в SSMS (New Query для каждого блока скриптов) скрипты из таблицы по-порядку, в строгой последовательности. Для каждого сервера берите скрипты из соответсвующего столбца таблиц. Выполнение каждого блока скриптов должно заканчиваться примерно таким сообщением «Command(s) completed successfully». Если в результате выполнения скриптов вы видите сообщения красным текстом, значит, возникли ошибки. На главном сервере в SQL Server Management Studio щелчок правой кнопкой мышина базе TCU_DB -> Properties -> Options -> Recovery model:Full -> OK ГЛАВНЫЙ (PRINCIPAL). 192.168.1.11 ЗЕРКАЛО (MIRROR). 192.168.1.12 1. Создаем контрольные точки и сертификаты в папках C:\Certs на главном и на зеркальном серверах —> This is the setup of the PRINCIPAL (master) in a mirroring environment USE master GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘password’; GO —> Create a name not using «master» or «principal», remember: the roles can —  switch but the certificates remain the same. CREATE CERTIFICATE SQLSrv1_mirroring_cert   WITH SUBJECT = ‘SQLSrv1 certificate’,    START_DATE = ‘2011-01-01 00:00:00’,    EXPIRY_DATE = ‘2030-01-01 00:00:00’ GO CREATE ENDPOINT Mirroring_Endpoint   STATE = STARTED   AS TCP (    LISTENER_PORT = 5022,    LISTENER_IP = ALL)   FOR DATABASE_MIRRORING (    AUTHENTICATION = CERTIFICATE SQLSrv1_mirroring_cert,    ENCRYPTION = REQUIRED ALGORITHM AES,    ROLE = ALL) GO —> Backup certificate and transfer to SQLSrv2 BACKUP CERTIFICATE SQLSrv1_mirroring_cert TO FILE = ‘C:\Certs\SQLSrv1_mirroring_cert. cer’; GO —> This is the setup of the MIRROR (slave) in a mirroring environment USE master GO —> Make sure a master key is set CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘password’; GO —> CREATE CERTIFICATE SQLSrv2_mirroring_cert   WITH SUBJECT = ‘SQLSrv2 certificate’,    START_DATE = ‘2011-01-01 00:00:00’,    EXPIRY_DATE = ‘2030-01-01 00:00:00’ GO CREATE ENDPOINT Mirroring_Endpoint   STATE = STARTED   AS TCP (    LISTENER_PORT = 5022,    LISTENER_IP = ALL)   FOR DATABASE_MIRRORING (    AUTHENTICATION = CERTIFICATE SQLSrv2_mirroring_cert,    ENCRYPTION = REQUIRED ALGORITHM AES,    ROLE = ALL) GO —> Backup certificate and transfer to SQLSrv1 BACKUP CERTIFICATE SQLSrv2_mirroring_cert TO FILE = ‘C:\Certs\SQLSrv2_mirroring_cert. cer’; GO 2. Обмениваемся сертификатами между серверами. На каждом сервере должно быть по 2 сертификата в папке C:\Certs 3. Создаем пользователей, привязанных к сертификатам USE master GO —> Create a login for the other server process CREATE LOGIN SQLSrv2_mirroring_login WITH PASSWORD = ‘password’; GO —> Create a user for the new login CREATE USER SQLSrv2_mirroring_user FOR LOGIN SQLSrv2_mirroring_login; GO —> Associate the certificate with the user. CREATE CERTIFICATE SQLSrv2_cert   AUTHORIZATION SQLSrv2_mirroring_user   FROM FILE = ‘C:\Certs\SQLSrv2_mirroring_cert.cer’ GO —> Grant the user access to the endpoint GRANT CONNECT ON ENDPOINT::Mirroring_Endpoint TO [SQLSrv2_mirroring_login] GO USE master GO —> Create a login for the other server process CREATE LOGIN SQLSrv1_mirroring_login WITH PASSWORD = ‘password’ GO —> Create a user for the new login CREATE USER SQLSrv1_mirroring_user FOR LOGIN SQLSrv1_mirroring_login; GO —> Associate the certificate with the user. CREATE CERTIFICATE SQLSrv1_mirroring_cert   AUTHORIZATION SQLSrv1_mirroring_user   FROM FILE = ‘C:\Certs\SQLSrv1_mirroring_cert.cer’ GO —> Grant the user access to the endpoint GRANT CONNECT ON ENDPOINT::Mirroring_Endpoint TO [SQLSrv1_mirroring_login] GO 4. Создаем Full Backup базы данных в корневой папке диска C:\ —> Create a FULL BACKUP of each database to be mirrored BACKUP DATABASE TCU_DB TO DISK = ‘c:\TCU_DB_backup.bak’ 5. Переносим полученный бэкап базы данных с главного сервера на зеркальный, в корень диска C:\ 6. Восстанавливаем БД из бэкапа (Если положение файлов БД на зеркальном сервере отличается от расположения файлов БД на главном, то можно использовать интерфейс SSMS, в котором указать положение файлов БД либо использовать в скрипте «MOVE», например «RESTORE DATABASE [TCU_DB] FROM DISK = ‘C:\TCU_DB_backup. bak’ WITH NORECOVERY, MOVE N’TCU_DB’ TO N’D:\SQL\TCU_DB.mdf’, MOVE N’TCU_DB_log’ TO N’D:\SQL\TCU_DB_log.ldf'»): USE MASTER GO —> Copy a backup of the database(s) to be mirrored —> Restore them using NORECOVERY RESTORE DATABASE [TCU_DB]   FROM DISK = N’C:\TCU_DB_backup. bak’   WITH FILE = 1, NORECOVERY, NOUNLOAD, STATS = 10 GO 7. Запускаем зеркалирование на зеркале: USE MASTER GO —> Set up partnering between the mirror and the principal (use a fully qualified name or an IP address) ALTER DATABASE TCU_DB SET PARTNER =’tcp://192. 168.1.11:5022’ GO 8. Запускаем зеркалирование на главном: USE master GO —> Restore these databases to the MIRROR using NORECOVERY —> Set up partnering between the mirror and the principal (use a fully qualified name or an IP address) —> Set up partnering between the principal and the mirror (use a fully qualified name or an IP address) ALTER DATABASE TCU_DB SET PARTNER =’tcp://192. 168.1.12:5022’ GO Примечание 1: Если после выполнения пункта 8 вы получите сообщения «Msg 1416, Level 16, State 31, Line 1 Database «TCU_DB» is not configured for database mirroring.», то необходимо повторить выполнение пунктов 7 и 8, но с минимальным промежутком времени между ними. Примечание 2: Если после выполнения пункта 8 вы получите сообщения «Error: 1478. The mirror database has insufficient transaction log data to preserve the log backup chain of the principal database. This may happen if a log backup from the principal database has not been taken or has not been restored on the mirror database. « или «Msg 1412, Level 16, State 0, Line 4 The remote copy of database has not been rolled forward to a point in time that is encompassed in the local copy of the database log.», то необходимо сделать бэкап журнала базы данных на главном сервере с последующим его восстановлением на зеркальном: ГЛАВНЫЙ (PRINCIPAL). 192.168.1.11 ЗЕРКАЛО (MIRROR). 192.168.1.12 BACKUP LOG [TCU_DB] TO DISK = N’C:\TCU_DB_transaction_log_backup.trn’ WITH NOFORMAT, NOINIT, NAME = N’TCU_DB-Transaction Log Backup’, SKIP, NOREWIND, NOUNLOAD, STATS = 10 GO Переносим полученный бэкап журнала с главного сервера на зеркальный, в корень диска C:\ RESTORE LOG [TCU_DB] FROM DISK = N’C:\TCU_DB_transaction_log_backup. trn’ WITH FILE = 1,  NORECOVERY, NOUNLOAD, STATS = 10 GO После этого повторите выполнение пунктов 7 и 8 Примечание 3: Если после выполнения пункта 8 вы получите сообщение «The server network address «TCP://192.168.1.12:5022″ can not be reached or does not exist. Check the network address name and that the ports for the local and remote endpoints are operational.», то проверьте доступность зеркального сервера по этому адресу, открытость порта TCP 5022 в брандмауэре, прослушивание этого порта на зеркальном и главном серверах с помощью команды netstat -abn, а также попробуйте подключиться по этому порту с одного сервера на другой, используя команду telnet 192. 168.1.11 5022 и telnet 192.168.1.12 5022. Дополнительные ссылки для решения возможных проблем: Изменение ролей (Главный <-> Зеркало): Либо в SQL Server Management Studio на главном сервере правая кнопка мыши на базе данных TCU_DB -> Task -> Mirror -> Failover Либо скрипт: ALTER DATABASE TCU_DB SET PARTNER FAILOVER Восстановление базы на зеркальном сервере после отказа главного. При восстановлении допускается утеря данных, о которой шла речь в начале статьи, поэтому будьте внимательны и осторожны: При выполнении принудительного восстановления зеркальная база становится главной и сможет принимать подключения клиентов: ALTER DATABASE TCU_DB SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS Бывшая главная база после восстановления автоматически станет зеркальной, но будет ожидать команды на продолжение зеркалирования. Для этого необходимо выполнить скрипт в SSMS: ALTER DATABASE TCU_DB SET PARTNER RESUME При отказе зеркальной базы после ее восстановления предпринимать каких либо действий не нужно — база синхронизируется с главной в кратчайшее время Пример последовательности действий в типичной ситуации Ситуация: основной (главный) сервер обесточен либо вышел из строя. Требуется подключить клиентов базы данных к резервной (зеркальной) базе данных Действия по подключению к резервной базе: Подключаемся к серверу-зеркалу и чтобы восстановить зеркальную базу выполняем скрипт в SSMS: ALTER DATABASE TCU_DB SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS Рестарт служб SQL Server База должна иметь статус (Principal, Synchronized). Если же база имеет статус «In Recovery» и он не изменяется после перезапуска служб MSSQL, то следует перезагрузить компьютер. Если статус базы «Principal, Disconnected», то, возможно, могут быть трудности при последущем возврате к обычной схеме работы. Вопрос этот полностью не изучен, возможно, будут дополнения к статье. Пока приходилось полностью восстанавливать зеркалирование с самого начала. После этого клиенты могут работать с базой на зеркальном сервере, ставшего теперь основным После ремонта и(или) включения бывшего основного сервера: Подключаемся к нему и открываем SSMS: База имеет статус (Mirror, Suspended / Restoring…) Выполняем скрипт: ALTER DATABASE TCU_DB SET PARTNER RESUME Получаем результат — Command(s) completed successfully. Рестарт служб SQL Server База должна иметь статус (Mirror, Synchronized / Restoring…) Используйте в SSMS инструмент мониторинга за зеркалированием баз (как — описано ниже), чтобы убедиться, что данный экземпляр синхронизирован с главной базой. Требуется некоторое время, чтобы изменения в главной базе были перенесены в зеркальную. Переходим на зеркальный сервер (который в данный момент является главным): База имеет статус (Principal, Synchronized) Делаем бэкап базы на всякий случай (по желанию). Меняем роли серверов. Для этого выполняем скрипт: ALTER DATABASE TCU_DB SET PARTNER FAILOVER Статус базы становится (Mirror, Synchronized / Restoring. ..) Переходим на бывший основной, который опять стал основным, статус базы — (Principal, Synchronized) После этого клиенты могут работать с базой на главном сервере так же, как и до возникновения данной ситуации. SQL Server Management Studio предоставляет инструмент для мониторинга процесса зеркалирования и синхронизации баз на серверах. Для этого в SSMS зеркального сервера сделайте щелчок правой кнопкой мыши на базе данных TCU_DB -> Tasks -> Launch Database Mirroring Monitor -> Register mirrored database Если у вас возникла необходимость очистить базу данных от созданных сертификатов, пользователей и логинов, а также в тех случаях, когда необходимо начать настройку заново, выполните в SQL Server Management Studio следующий код: USE MASTER GO IF EXISTS (SELECT 1 FROM sys. certificates WHERE name = ‘SQLSrv2_cert’) DROP CERTIFICATE SQLSrv2_cert GO IF EXISTS (SELECT 1 FROM sys.sysusers WHERE name = ‘SQLSrv1_mirroring_user’) DROP USER SQLSrv1_mirroring_user GO IF EXISTS (SELECT 1 FROM sys. sysusers WHERE name = ‘SQLSrv2_mirroring_user’) DROP USER SQLSrv2_mirroring_user GO IF EXISTS (SELECT 1 FROM sys.syslogins WHERE name = ‘SQLSrv1_mirroring_login’) DROP LOGIN SQLSrv1_mirroring_login GO IF EXISTS (SELECT 1 FROM sys. syslogins WHERE name = ‘SQLSrv2_mirroring_login’) DROP LOGIN SQLSrv2_mirroring_login GO IF EXISTS (SELECT * FROM sys.endpoints WHERE name = ‘Mirroring_Endpoint’) DROP ENDPOINT Mirroring_Endpoint GO IF EXISTS (SELECT 1 FROM sys. certificates WHERE name = ‘SQLSrv1_mirroring_cert’) DROP CERTIFICATE SQLSrv1_mirroring_cert GO IF EXISTS (SELECT 1 FROM sys.certificates WHERE name = ‘SQLSrv2_mirroring_cert’) DROP CERTIFICATE SQLSrv2_mirroring_cert GO

Сервер

и роли базы данных в SQL Server — ADO.

NET

• 30.03.2017
• 3 минуты на чтение

В этой статье

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

Фиксированные роли сервера

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

Важно

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

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

Фиксированные роли базы данных

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

Для получения дополнительных сведений о предопределенных ролях SQL Server см. Следующие ресурсы.

Ресурс	Описание
Роли на уровне сервера	Описывает фиксированные роли сервера и связанные с ними разрешения в SQL Server.
Роли уровня базы данных	Описывает фиксированные роли базы данных и связанные с ними разрешения.

Роли и пользователи базы данных

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

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

Общественная роль

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

Учетная запись пользователя dbo

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

Учетную запись пользователя dbo часто путают с фиксированной ролью базы данных db_owner . Область действия db_owner - это база данных; область действия sysadmin - весь сервер. Членство в роли db_owner не предоставляет пользователю привилегий dbo .

Гостевая учетная запись пользователя

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

Гостевая учетная запись является встроенной учетной записью во всех версиях SQL Server. По умолчанию он отключен в новых базах данных. Если он включен, вы можете отключить его, отозвав его разрешение CONNECT, выполнив инструкцию Transact-SQL REVOKE CONNECT FROM GUEST.

Важно

Избегайте использования гостевой учетной записи ; все логины без собственных разрешений базы данных получают разрешения базы данных, предоставленные этой учетной записи. Если вам необходимо использовать гостевую учетную запись , предоставьте ей минимальные разрешения.

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

См. Также

Как проверить роли пользователей в SQL Server

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

Для обеспечения безопасности и соблюдения многих нормативных требований, включая PCI DSS и HIPAA, вам необходимо знать все роли сервера и базы данных, назначенные каждому пользователю. Это тяжелая работа, если у вас есть только собственные инструменты из-за всей сложности.

Начнем с того, что настройки уровня сервера, такие как роли сервера, разрешения, учетные данные и зависимости пользователей, хранятся в базе данных master.Используя системное представление server_principals , вы можете увидеть данные для всех типов участников сервера:

• S = логин SQL
• U = логин Windows
• G = группа Windows
• R = роль сервера
• C = логин сопоставлен с сертификатом
• K = Логин сопоставлен с асимметричным ключом
• Общедоступная роль устанавливает базовые разрешения по умолчанию для всех пользователей сервера; он присваивается каждому пользователю автоматически.
• Роль системного администратора предоставляет права администратора для всех серверных баз данных и активов.
• Любой пользователь с ролью db_owner может выполнять все действия по настройке и обслуживанию базы данных.

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

Хотя хранимые процедуры могут помочь вам в управлении областями сервера, для создания настраиваемых отчетов (например, тех, которые соответствуют нескольким таблицам по определенным именам столбцов), вам придется использовать запросы.Например, информация о членстве в ролях на уровне сервера хранится в системном представлении server_role_members базы данных master. Поскольку идентификаторы участников связаны, вы можете получить сводную информацию о ролях пользователей SQL Server с помощью запроса, присоединив sys.server_principals к master. sys.server_role_members на основе номера идентификатора. Хотя пользователи могут просматривать свое собственное членство в роли сервера и основной идентификатор каждого члена фиксированных ролей сервера, имейте в виду, что для просмотра членства всех ролей сервера требуются дополнительные разрешения или членство в фиксированной роли сервера securityadmin .

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

Короче говоря, получение исчерпывающей информации о текущих ролях пользователей с помощью собственных инструментов может быть чрезвычайно сложным и утомительным. С другой стороны, с помощью Netwrix Auditor вы можете получить подробную информацию о том, кто и какие роли сервера и базы данных выполняет в удобочитаемом формате, за несколько щелчков мышью. Связанные отчеты, включенные в продукт, позволяют вашим специалистам легко разбираться в сложностях, связанных с членством во вложенных ролях пользователей на всем сервере, упрощая расследования. Вы получаете все необходимые данные: список каждого объекта, к которому пользователь имеет доступ, с указанием пути и типа объекта, предоставленных разрешений, способа их предоставления (напрямую, через членство в ролях и т. Д.) И они явные или унаследованные. Вы можете анализировать разрешения с разных сторон, включая уровень учетной записи, уровень объекта и уровень сервера.Вся эта информация четко представлена ​​и доступна без необходимости писать сценарии, экспортировать информацию в Excel и вручную ее просеивать.

Роли SQL Server - фиксированные роли сервера

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

Членами роли базы данных могут быть любые из следующих:

• Группы Windows и учетные записи пользователей
• Имена входа в SQL Server
• Другие роли

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

• Фиксированные роли сервера
• Фиксированные роли базы данных

Помимо этих двух, в следующих разделах также описываются следующие типы ролей:

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

В следующих разделах подробно описаны эти типы ролей.

Фиксированные роли сервера

Фиксированные роли сервера определяются на уровне сервера и поэтому существуют вне баз данных, принадлежащих серверу баз данных.В Табл. 12-1 перечислены все существующие фиксированные роли сервера.

Таблица 12-1 Фиксированные роли сервера

Управление фиксированными ролями сервера

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

• Используя Management Studio
• Us Инструкции T-SQL

Чтобы добавить имя входа в фиксированную роль сервера с помощью SQL Server Management Studio, разверните сервер, разверните Безопасность и разверните Роли сервера. Щелкните правой кнопкой мыши роль, для которой вы хотите добавить логин, а затем щелкните Свойства. На странице «Члены» диалогового окна «Свойства роли сервера» (см. Рис. 12-4) нажмите «Добавить». Найдите логин, который хотите добавить. Такой логин становится членом роли и наследует все учетные данные, назначенные этой роли.

Рис. 12-4. Диалоговое окно «Свойства роли сервера».

Инструкции Transact-SQL CREATE SERVER ROLE и DROP SERVER ROLE используются, соответственно, для добавления и удаления членов фиксированной роли сервера.Оператор ALTER SERVER ROLE изменяет членство в роли сервера. Пример 12.9, в разделе «Пользовательские роли сервера», показывает использование операторов CREATE SERVER ROLE и ALTER SERVER ROLE.

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

Логин sa

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

Примечание - Используйте логин sa только тогда, когда нет другого способа войти в систему базы данных.

Фиксированные роли базы данных

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

Таблица 12-2 Фиксированные роли базы данных

Помимо фиксированных ролей базы данных, перечисленных в Таблице 12-2, существует специальная фиксированная база данных роль называется публичной, что объясняется далее.

общедоступная роль

Общедоступная роль - это особая фиксированная роль базы данных, к которой принадлежит каждый легитимный пользователь базы данных. Он фиксирует все разрешения по умолчанию для пользователей в базе данных. Это обеспечивает механизм предоставления всем пользователям без соответствующих разрешений набора (обычно ограниченных) разрешений. Общедоступная роль поддерживает все разрешения по умолчанию для пользователей в базе данных и не может быть удалена. Этой роли не могут быть назначены пользователи, группы или роли, поскольку они принадлежат этой роли по умолчанию.(Пример 12.19 в разделе «Авторизация» показывает использование публичной роли.)

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

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

Назначение пользователю фиксированной роли базы данных

Чтобы назначить пользователю фиксированную роль базы данных с помощью SQL Server Management Studio, разверните сервер, разверните Базы данных , разверните базу данных, разверните Безопасность, разверните Роли, а затем разверните Роли базы данных. Щелкните правой кнопкой мыши роль, к которой вы хотите добавить пользователя, а затем щелкните Свойства. В диалоговом окне «Свойства роли базы данных» нажмите «Добавить» и найдите пользователей, которых вы хотите добавить. Такая учетная запись становится членом роли и наследует все учетные данные, назначенные этой роли.

Фиксированная роль сервера - обзор

Фиксированные роли сервера

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

Фиксированная роль сервера bulkadmin является новейшей из фиксированных ролей сервера после добавления в SQL Server 2005. Эта фиксированная роль сервера предоставляет своим членам возможность массовой вставки данных с помощью BCP, SSIS или оператора BULK INSERT без предоставления им дополнительных прав. До SQL Server 2005 для массовой вставки данных в SQL Server с использованием любого метода, необходимого для участия в фиксированной серверной роли sysadmin. Фиксированная роль сервера bulkadmin - это единственная фиксированная роль сервера, которую Microsoft добавила в ядро ​​СУБД SQL Server с тех пор, как ядро ​​базы данных было изменено из базы кода Sybase в SQL Server 4.2.

Фиксированная роль сервера dbcreator дает своим участникам права создавать базы данных и восстанавливать базу данных в экземпляре базы данных.

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

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

Фиксированная роль сервера securityadmin дает своим членам возможность создавать и удалять учетные записи для экземпляра, создавать пользователей в базах данных, изменять членство фиксированной и определяемой пользователем роли базы данных и предоставлять права в любой базе данных в экземпляре. Администратор безопасности не имеет разрешений на изменение членов фиксированных ролей сервера.

Фиксированная роль сервера serveradmin дает своим участникам возможность изменять большинство общесистемных настроек и выключать экземпляр SQL Server с помощью команды SHUTDOWN.

Фиксированная роль сервера setupadmin дает своим участникам возможность создавать и удалять связанные серверы.

Добавление роли системного администратора Microsoft SQL Server - платформа Coveo 7

Учетная запись администратора CES должна быть членом системы Microsoft SQL Server.
роль сервера администраторов, если вы хотите установить веб-службу Coveo SharePoint
(см. Установка веб-службы Coveo, окна поиска и интерфейса поиска в SharePoint).

Процедура применима к Microsoft SQL Server 2008, 2005 и 2000, но различается в зависимости от
в версии SQL Server:

Microsoft SQL Server 2008 и 2005


1. Откройте SQL Server Management Studio (меню «Пуск» Windows> Все программы> Microsoft SQL Server 2008 или Microsoft SQL Server 2005).

2. На панели слева разверните localhost> Безопасность, а затем щелкните узел Логины.

3. Если логин для административной учетной записи CES уже существует, дважды щелкните его.В противном случае щелкните правой кнопкой мыши «Логины» и выберите «Новый вход».

4. В диалоговом окне «Вход - Новый»:

   1. В поле «Имя для входа» введите учетную запись администратора CES.

   2. На панели слева щелкните Роли сервера.

   3. На панели справа в списке ролей сервера выберите системный администратор.

   4. Нажмите ОК.

Microsoft SQL Server 2000


1. Откройте SQL Server Enterprise Manager (меню «Пуск» Windows> Все программы> Microsoft SQL Server).

2. На панели слева разверните Серверы Microsoft SQL> Группа SQL Server> [ваша группа серверов]> Безопасность.

3. Щелкните узел Логины.

4. Если логин для административной учетной записи CES уже существует, дважды щелкните его.
В противном случае щелкните правой кнопкой мыши «Логины» и выберите «Новый вход».

5. В диалоговом окне Свойства входа в SQL Server - Новый вход:

   1. В поле «Имя для входа» введите учетную запись администратора CES.

   2. Щелкните вкладку «Роли сервера».

   3. В списке «Роль сервера» выберите «Системные администраторы».

   4. Нажмите ОК.

Понимание ролей SQL Server - DatabaseJournal.

com

Введение

Роли сервера

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

Пользовательские роли

Роли приложения

Введение

 Роли - это новая функция SQL Server 7.0, которая не была доступна в
предыдущие версии.Роли SQL Server действуют как локальные в Windows NT
группы.

SQL Server 7.0 поддерживает несколько различных типов ролей. Есть: 

• серверных ролей
• ролей базы данных
• ролей приложений

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

Роли сервера

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

Существует семь фиксированных серверных ролей: 

• системный администратор
• серверадмин
• setupadmin
• администратор безопасности
• processadmin
• dbcreator
• diskadmin

Члены роли сервера  sysadmin  могут выполнять любые действия в
SQL Server 7.0 и имеет полный контроль над всеми функциями базы данных.Члены роли сервера  serveradmin  могут менять сервер
конфигурация
параметры и выключите сервер.

Члены роли сервера  setupadmin  могут управлять связанными серверами (добавить
или удалить связанные серверы), управлять репликацией, управлять расширенным хранилищем
процедуры и выполнить некоторые системные хранимые процедуры, такие как
sp_serveroption.

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

Члены роли сервера  processadmin  могут управлять процессами.
работает в SQL Server.Члены роли сервера  dbcreator  могут создавать, изменять и изменять размер
базы данных.

Члены роли сервера  diskadmin  могут управлять файлами на диске.


  Чтобы добавить логин в качестве члена фиксированной роли сервера, вы
можешь использовать
Системная хранимая процедура sp_addsrvrolemember.  Это синтаксис: 

sp_addsrvrolemember [@loginame =] 'login', [@rolename =] 'role'

 где @loginame - логин SQL Server или учетная запись пользователя Windows NT.@rolename - имя фиксированной роли сервера. См. Эту ссылку для получения дополнительной информации sp_addsrvrolemember (T-SQL)  Чтобы удалить имя входа SQL Server, пользователя или группу Windows NT из фиксированной роли сервера, можно использовать системную хранимую процедуру sp_dropsrvrolemember.   Это синтаксис: 

sp_dropsrvrolemember [@loginame =] 'login', [@rolename =] 'role'

 где @loginame - имя логина, который нужно удалить. @rolename - имя фиксированной роли сервера.См. Эту ссылку для получения дополнительной информации. Sp_dropsrvrolemember (T-SQL)  Чтобы вернуть список фиксированных ролей сервера SQL Server, можно использовать системную хранимую процедуру sp_helpsrvrole.  Это синтаксис: 

sp_helpsrvrole [[@srvrolename =] 'role']

 где @srvrolename - имя фиксированной роли сервера. См. Эту ссылку для получения дополнительной информации sp_helpsrvrole (T-SQL) 

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

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

• Фиксированные роли базы данных
• Публичная роль
• Роли базы данных, определяемые пользователем

Фиксированные роли базы данных

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

Существует девять фиксированных ролей базы данных: 

• db_owner
• db_accessadmin
• db_datareader
• db_datawriter
• db_ddladmin
• db_securityadmin
• db_backupoperator
• db_denydatareader
• db_denydatawriter

Члены роли базы данных  db_owner  могут выполнять любые действия в
база данных. Члены роли базы данных  db_accessadmin  могут добавлять или удалять Windows.
NT
группы, пользователи или пользователи SQL Server в базе данных.

Члены роли базы данных  db_datareader  могут видеть любые данные со всех
пользовательские таблицы в базе данных.

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

Члены роли базы данных  db_ddladmin  могут создавать любые определения данных.
языковые команды в базе данных.Члены роли базы данных  db_securityadmin  могут управлять оператором
и права доступа к объектам в базе данных.

Члены роли базы данных  db_backupoperator  могут создавать резервные копии
база данных.

Члены роли базы данных  db_denydatareader  могут отказать в разрешении
выберите данные в базе данных.

Члены роли базы данных  db_denydatawriter  могут отказать в разрешении
изменить данные в базе данных. 


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

sp_addrolemember [@rolename =] 'role', [@membername =] 'security_account'

 где @rolename - имя роли базы данных. @membername - имя учетной записи. Любой член фиксированной роли базы данных может добавлять других пользователей к этой роли. См. Эту ссылку для получения дополнительной информации. Sp_addrolemember (T-SQL)  Чтобы удалить учетную запись безопасности из роли SQL Server в текущей базе данных, можно использовать системную хранимую процедуру sp_droprolemember. Это синтаксис: 

sp_droprolemember [@rolename =] 'role', [@membername =] 'security_account'

 где @rolename - название роли.  @membername - имя учетной записи. См. Эту ссылку для получения дополнительной информации. Sp_droprolemember (T-SQL)  Для возврата информации об элементах роли в текущей базе данных можно использовать системную хранимую процедуру sp_helprolemember.  Это синтаксис: 

sp_helprolemember [[@rolename =] 'role']

 где @rolename - имя роли в текущей базе данных.См. Эту ссылку для получения дополнительной информации sp_helprolemember (T-SQL) 

Публичная роль

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

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

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

sp_addrole [@rolename =] 'role' [, [@ ownername =] 'owner']

 где @rolename - имя роли базы данных. @ownername - владелец новой роли. См. Эту ссылку для получения дополнительной информации sp_addrole (T-SQL)  Чтобы удалить роль SQL Server из текущей базы данных, вы можете использовать системную хранимую процедуру sp_droprole. Это синтаксис: 

sp_droprole [@rolename =] 'role'

 где @rolename - название роли. См. Эту ссылку для получения дополнительной информации sp_droprole (T-SQL) 

Роли приложений

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


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

sp_addapprole [@rolename =] 'role', [@password =] 'password'

 где @rolename - имя роли приложения. @password - пароль для новой роли приложения.См. Эту ссылку для получения дополнительной информации. Sp_addapprole (T-SQL)  Чтобы удалить роль приложения из текущей базы данных, можно использовать системную хранимую процедуру sp_dropapprole.   Это синтаксис: 

sp_dropapprole [@rolename =] 'role'

 где @rolename - имя роли приложения. Для получения дополнительной информации см. Эту ссылку sp_dropapprole (T-SQL)  Чтобы изменить пароль роли приложения в текущей базе данных, можно использовать системную хранимую процедуру sp_approlepassword. Это синтаксис: 

sp_approlepassword [@rolename =] 'роль', [@newpwd =] 'пароль'

 где @rolename - имя роли приложения. @newpwd - новый пароль для роли приложения. См. Эту ссылку для получения дополнительной информации sp_approlepassword (T-SQL) 

» Все статьи обозревателя Александр Чигрик

Безопасность SQL Server: роли сервера - SQLServerCentral

Чтобы упростить администрирование, начиная с SQL Server 7. 0 Microsoft разработала несколько предопределенных фиксированных серверных ролей. Эти роли имеют разные разрешения и предназначены для

для обеспечения возможности распределения административных обязанностей без

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

• bulkadmin
• dbcreator
• diskadmin
• processadmin
• администратор безопасности
• серверадмин
• setupadmin
• системный администратор

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

.

установка.

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

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

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

системная хранимая процедура sp_srvrolepermission, возвращающая права фиксированной роли сервера. Предупреждение с

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

В таблице spt_values ​​могут отсутствовать метаданные, соответствующие этим

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

хранимые процедуры sp_trace_ *, хотя присутствуют другие системные хранимые процедуры, такие как sp_grantlogin и sp_changedbowner.

Если сомневаетесь, проверьте электронную документацию. Однако sp_srvrolepermissions по-прежнему предоставляет довольно подробный список прав для конкретной роли сервера - более чем достаточно, чтобы быть полезным. Например:

 EXEC sp_srvrolepermission securityadmin 

возвращает следующее:

Таблица 1. Разрешения для роли администратора безопасности.

Роль сервера	Разрешения
администратор безопасности	Добавить участника в securityadmin
администратор безопасности	Предоставить / отклонить / отозвать CREATE DATABASE
администратор безопасности	Прочитать журнал ошибок
администратор безопасности	sp_addlinkedsrvlogin
администратор безопасности	sp_addlogin
администратор безопасности	sp_defaultdb
администратор безопасности	sp_defaultlanguage
администратор безопасности	sp_denylogin
администратор безопасности	sp_droplinkedsrvlogin
администратор безопасности	sp_droplogin
администратор безопасности	sp_dropremotelogin
администратор безопасности	sp_grantlogin
администратор безопасности	sp_helplogins
администратор безопасности	sp_password
администратор безопасности	sp_remoteoption (обновление)
администратор безопасности	sp_revokelogin

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

Роль bulkadmin

Microsoft добавила роль bulkadmin, чтобы пользователи без прав администратора могли использовать команду BULK INSERT. В SQL Server 7 только членам роли sysadmin было разрешено выполнять BULK INSERT. В SQL Server 20000 члены роли bulkadmin должны по-прежнему иметь соответствующие права на рассматриваемую таблицу (либо владелец объекта, либо член фиксированной роли базы данных db_owner).В противном случае они получат

Ошибка

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

Рисунок 1. Пользователь, которому назначена роль bulkadmin, без соответствующих прав на таблицу.

Ранее владельцы баз данных не могли использовать массовую вставку для загрузки своих таблиц. Когда выполняется команда BULK INSERT, данные загружаются прямо на сервер в виде набора строк OLE DB. Он не проходит через сетевые протоколы и Microsoft Open Data Services (ODS).Другими словами, набор строк создается в области памяти

самого SQL Server. Таким образом, сбой BULK INSERT теоретически может повлиять на SQL Server в целом. Вот почему Microsoft не разрешала никому, кроме системных администраторов, выполнять BULK INSERT в SQL Server 7.0.

В SQL Server 2000 Microsoft теперь дает возможность разрешить или запретить BULK INSERT для других учетных записей, которым не требуются права системного администратора.

Если имя входа добавлено к фиксированной роли сервера bulkadmin, оно может использовать BULK INSERT.Эта дополнительная роль дает администратору баз данных большую гибкость, поскольку теперь есть опция, отличная от роли системного администратора. Администратор базы данных может делегировать использование BULK INSERT. Пользователи по-прежнему должны быть владельцем объекта или базы данных, поэтому эта роль не дает карт-бланш для всех таблиц во всех базах данных.

Роль dbcreator

Фиксированная роль сервера dbcreator должна иметь возможность создавать, удалять и восстанавливать базы данных. Когда база данных создается, создатель автоматически принимает владение.Следовательно, логин с ролью dbcreator может изначально назначать разрешения, создавать объекты и все остальное, что пользователь с фиксированной ролью базы данных db_owner может делать для создаваемых им баз данных (по крайней мере, до тех пор, пока право собственности не будет изменено). Перечисленные разрешения процедурой sp_srvrolepermission

являются:

• Добавить участника в dbcreator
• ИЗМЕНЕНИЕ БАЗЫ ДАННЫХ
• СОЗДАТЬ БАЗУ ДАННЫХ
• УДАЛЕНИЕ БАЗЫ ДАННЫХ
• Расширить базу данных
• ВОССТАНОВЛЕНИЕ БАЗЫ ДАННЫХ
• ЖУРНАЛ ВОССТАНОВЛЕНИЯ
• sp_renamedb

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

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

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

Роль diskadmin

Фиксированная роль сервера diskadmin в основном позволяет добавлять и удалять устройства резервного копирования. Список прав невелик:

• Добавить участника в diskadmin
• ДИСК ИНИТ
• sp_addumpdevice
• sp_diskdefault
• sp_dropdevice

Два из этих прав, DISK INIT и sp_diskdefault, объявлены устаревшими в SQL Server 2000. Электронная документация утверждает, что поддержка в SQL Server 2000 ограничена и «рассмотреть возможность замены ссылок» на DISK INIT на CREATE DATABASE или ALTER DATABASE.Хранимая процедура sp_diskdefault имеет более строгий язык: «Удалено; больше недоступно. Удалите все ссылки на sp_diskdefault ».

Удаление DISK INIT и sp_diskdefault, остаются только процедуры sp_addumpdevice и sp_dropdevice. Роль diskadmin может создавать и удалять устройства для резервного копирования базы данных. Однако, если пользователь не получает разрешения на уровне базы данных, пользователь с правами роли diskadmin не имеет разрешений на резервное копирование базы данных по умолчанию.

Роль администратора процесса

Роль processadmin - это еще одна роль с довольно ограниченными, но мощными функциями.Пользователь, которому назначена эта роль, может подавать команду KILL, но не имеет других прав. Однако с помощью команды KILL пользователь с ролью processadmin имеет огромные возможности, поскольку он или она может остановить

запрос, выполняемый в SQL Server.

Есть несколько причин для выполнения команды KILL. Первый - это потеря связи. Осиротевшее соединение вполне может удерживать блокировку ресурса, не позволяя другим процессам получить доступ.Второй - если происходит неконтролируемый процесс. Администратор баз данных или пользователь с правами KILL через роль processadmin должен остановить процесс, чтобы восстановить ресурсы процессора и дискового ввода-вывода. Вот пример неконтролируемого процесса, который необходимо остановить:

СОЗДАТЬ ТАБЛИЦУ ATest (

ATestID int IDENTITY)

А НЕ (1 = 0)

ВСТАВИТЬ ЗНАЧЕНИЯ ПО УМОЛЧАНИЮ

Поскольку 1 никогда не будет равняться 0, процесс, выполняющий этот запрос, будет продолжать вставлять строки, пока на сервере не закончится свободное место (будь то в файле базы данных или на самом диске) или пока процесс не будет остановлен.Либо processadmin, либо sysadmin должны будут остановить процесс, чтобы предотвратить первое появление. Хотя маловероятно, что неконтролируемый процесс будет чем-то столь же простым, как этот тестовый запрос, суть в том, что это все, что нужно. Пользователь может использовать что-то вроде отказа в обслуживании SQL Server.

Роль администратора безопасности

Роль администратора безопасности используется для управления учетными записями пользователей в SQL Server. Как и группа «Диспетчер учетных записей» в Windows NT, роль администратора безопасности имеет возможность создавать (добавлять) и удалять учетные записи.Вот права, предоставленные роли администратора безопасности.

• Добавить участника в securityadmin
• Предоставить / отклонить / отозвать CREATE DATABASE
• Прочитать журнал ошибок
• sp_addlinkedsrvlogin
• sp_addlogin
• sp_defaultdb
• sp_defaultlanguage
• sp_denylogin
• sp_droplinkedsrvlogin
• sp_droplogin
• sp_dropremotelogin
• sp_grantlogin
• sp_helplogins
• sp_password
• sp_remoteoption (обновление)
• sp_revokelogin

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

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

логин должен соответствовать пользователю в фиксированной роли базы данных db_accessadmin для

база данных.

Роль serveradmin

Serveradmin может задавать параметры конфигурации с помощью процедуры sp_configure, а также отключать сервер.Используя sp_srvrolepermission, получаем следующий список прав:

• Добавить участника в serveradmin
• dbcc freeproccache
• ПЕРЕКОНФИГУРАЦИЯ
• ВЫКЛЮЧЕНИЕ
• sp_configure
• sp_fulltext_service
• sp_tableoption

На основе списка роль serveradmin также может изменять настройки полнотекстовой службы и параметры таблицы.

Об этом особо нечего сказать, потому что я могу себе представить эту роль

используется не очень часто.Если пользователю нужна возможность выключить SQL Server и

немного больше, этот пользователь обычно делает это через службу (например, член

серверной команды).

Роль setupadmin

Роль setupadmin - еще одна довольно ограниченная роль. Согласно электронной документации, setupadmin имеет возможность управлять связанными серверами, а также отмечать хранимые процедуры для запуска при запуске. Системная хранимая процедура sp_procoption может использоваться для пометки хранимой процедуры таким образом.Отмеченные процедуры должны существовать в базе данных master и принадлежать dbo. В этом скрипте я помечаю хранимую процедуру для запуска при запуске:

EXEC sp_procoption 'usp_myStartupProcedure', 'запуск', 'истина'

Этот код T-SQL настраивает хранимую процедуру usp_myStartupProcedure для выполнения при каждом запуске SQL Server. Чтобы выключить, мне нужно установить для запуска значение false:

EXEC sp_procoption 'usp_myStartupProcedure', 'запуск', 'ложь'

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

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

Согласно статье 277809 базы знаний Майкрософт, только члены фиксированной серверной роли sysadmin должны иметь возможность устанавливать хранимую процедуру для запуска. В статье указывается, что роль сервера setupadmin по-прежнему могла выполнять процедуру sp_procoption до SQL Server 7.0 Service Pack 3. Это было сочтено ошибкой, потому что оно открывает огромную дыру в безопасности (конечно, ни одна дыра в безопасности не должна считаться маленькой). Продолжайте читать, почему это брешь в безопасности и какова одна из возможностей. Это не вариант для кого-либо, кроме тех, кто играет роль системного администратора в SQL Server 2000.

Если выполняется процедура sp_srvrolepermission, чтобы узнать, какие права имеет setupadmin, в списке отображается процедура sp_procoption. Роль setupadmin действительно может выполнять эту системную хранимую процедуру, но хранимая процедура вернет ошибку.В SQL Server 2000 процедура sp_procoption имеет следующий код для предотвращения ее запуска пользователем, если у пользователя нет прав системного администратора:

- ДОЛЖЕН БЫТЬ системным администратором (процессы запуска запускаются как системный администратор) -

ЕСЛИ is_srvrolemember ('sysadmin') = 0

НАЧАТЬ

raiserror (15247, -1, -1)

ВОЗВРАТ @@ ОШИБКА

КОНЕЦ

Если вы посмотрите на запись в системных сообщениях, соответствующую ошибке 15247, вы увидите следующее описание: «У пользователя нет разрешения на выполнение этого действия.Таким образом, хотя в электронной документации (даже в обновленной версии от сентября 2001 г.) до версии, переизданной с выпуском SP3, говорится, что роль setupadmin имеет возможность выполнять процедуру sp_procoption, эта роль не может делать что-либо с хранимой процедурой. строками кода, приведенными выше. Если бы вы или я изменили системную хранимую процедуру для удаления этих строк, в хранимой процедуре есть две дополнительные команды, которые не входят в права роли setupadmin. Эти две команды - DBCC LockObjectSchema () и RECONFIGURE.Поскольку процедура sp_procoption недоступна для setupadmin, единственное реальное право этой роли - управлять связанными серверами.

Решение Microsoft не разрешать роли setupadmin устанавливать хранимую процедуру для запуска имеет большой смысл, потому что в противном случае пользователь, не являющийся системным администратором, мог бы включить хранимую процедуру, которая запускается с правами системного администратора при запуске SQL Server. Ясно, что это не лучшая практика. Однако исходная документация (и обновление за сентябрь 2001 г.) неверны.

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

Если вы не обновляли свою версию электронной документации, перейдите по ссылке, которую я включил.

в разделе «Дополнительные ресурсы».

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

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

СОЗДАТЬ ПРОЦЕСС dbo.usp_GrantAdministratorsAccess

КАК

EXEC sp_grantlogin 'BUILTIN \ Administrators'

EXEC sp_addsrvrolemember 'BUILTIN \ Administrators', 'sysadmin'

GO

Мой коллега, администратор баз данных, удалил группу BUILTIN \ Administrators из фиксированной роли сервера sysadmin. Я вошел в систему, используя учетную запись уровня администратора домена (на стороне ОС глобальная группа администраторов домена добавляется в локальную группу администраторов, когда компьютер присоединяется к домену) и попытался войти в SQL Server. Я не мог. Однако, поскольку я был локальным администратором, я мог останавливать и перезапускать службу SQL Server (MSSQLSERVER). Именно это я и сделал. После перезапуска SQL Server я попытался снова войти в систему. Поскольку моя хранимая процедура выполнялась при запуске, группа BUILTIN \ Administrators снова была членом роли sysadmin. Моя попытка входа в систему прошла успешно, и я снова получил разрешения уровня системного администратора. Все это стало возможным, потому что моя хранимая процедура запускалась при запуске с правами системного администратора. Microsoft ограничила выполнение процедуры sp_procoption членам роли sysadmin исключительно для предотвращения эксплойтов, как это было продемонстрировано мной.

Роль системного администратора

Роль системного администратора, как следует из названия, может делать что угодно в SQL Server. Это

имеет полные права на SQL Server. Это единственная роль, которая может добавлять других к роли sysadmin. В SQL Server нет ничего, что не мог бы сделать член роли системного администратора.

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

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

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

Это приводит меня к обсуждению того, как я видел нарушение безопасности

с участием роли системного администратора. По умолчанию группе NT BUILTIN \ Administrators предоставляются права sysadmin на SQL Server, поскольку она становится членом роли syadmin. Группа BUILTIN \ Administrators соответствует локальной группе администраторов для сервера.

Одно из главных запретов, которые я видел в среде разработки, - это результат сочетания трех вещей:

1. BUILTIN \ Администраторы остаются с правами системного администратора
2. Разработчикам предоставляются права локального администратора
3. Служба SQL Server работает под той же учетной записью домена, что и производственные системы.

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

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

И последнее, что касается роли системного администратора: она обходит проверки безопасности. Запрет разрешений не останавливает роль системного администратора, поскольку член этой роли полностью отменяет любые настройки безопасности. Роль системного администратора - это действительно роль суперпользователя.Выдавайте это очень осторожно.

Заключительные комментарии

Фиксированные серверные роли в SQL Server 2000 предоставляются для удобства

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

.
Установка

, чтобы администратор баз данных мог делегировать определенные обязанности, не передавая

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

возможность управлять логинами, давая другому возможность создавать и удалять

баз данных.Кроме того, роль bulkadmin дает пользователю возможность выполнить BULK INSERT, если

пользователь владеет таблицей или помечен как член роли db_owner для

база данных. Это еще один пример того, как Microsoft предоставила роль

.

делегировать обязанности.

С учетом сказанного, некоторые из ролей, как и следовало ожидать, мощные. Даже в

г.

среда разработки, роли должны тщательно контролироваться, особенно

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

указывает на производственный сервер, намеренно или нет.Как и все

относительно безопасности, разберитесь, какие есть варианты, рассмотрите, что лучше

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

эти роли в ваших интересах.

Дополнительные ресурсы

.

No related posts.