Сколько считает База данных

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

3
задан 5 May 2009 в 02:27
4 ответа

Я настроил бы:

  • учетная запись администрирования запаса, которая появляется OOB. Используйте это для вещей, которые не может сделать никакая другая учетная запись. Сохраните запертым и только буксируйте его, когда у Вас не будет выбора.
  • вторичная администраторская учетная запись, один для каждого администратора. Сделайте весь Ваш ежедневный администратор работает в этой учетной записи, но на этих администраторских учетных записях, опускает полномочия для действительно опасного материала (DROP DATABASE, ОТБРАСЫВАЕТ СХЕМУ, и т.д.), используйте администраторскую учетную запись из поля, упомянутую выше для этого. (Идея состоит в том, что, вынуждая Вас войти в систему, поскольку другая учетная запись должна быть умственным индикатором, что Вы собираетесь сделать что-то потенциально разрушительное, также что обыденный администратор считает, может иметь встроенный "предохранительный выключатель" в форме пропавших без вести privs для действий, которые могли нанести вред Вашей базе данных),
  • если Вы используете основанные на машине подключения (организация пула подключений, проксированные подключения, и т.д.) используют счет на это. Предоставьте необходимые полномочия абсолютного минимума, чтобы эта учетная запись функционировала (чтобы препятствовать тому, чтобы учетная запись причинила огромный вред через DROP DATABASE, и т.д.)
  • если у Вас есть прямые подключения от конечных пользователей, один счет на каждого конечного пользователя, ЕСЛИ Ваши конечные пользователи не являются широкой категорией, и у Вас нет потребности выделить privs для той категории. В этом случае, единственный счет на каждую группу пользователей.

03.07.2009 переиздают для ясности.

7
ответ дан 3 December 2019 в 04:41
  • 1
    Действительно как точка о Конечных пользователях... кто-либо еще ненавидит доступ? –  C. Ross 5 May 2009 в 14:59

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

  • Внутреннее приложение, соединяющееся от имени пользователя. В этом случае мы создаем сервисную учетную запись в домене и предоставляем ему доступ к домену. Приложение использует этот счет на весь доступ к базе данных.
  • Внешнее направление (Интернет) приложение. В этом случае мы создаем вход в систему SQL Server, потому что веб-серверы будут в демилитаризованной зоне и поэтому не будут на домене. Приложение использует этот счет на весь доступ к базе данных.
  • Приложение Interal передает учетные данные пользователя. Вы видите это с SQL Server Reporting Services и другими случаями, где передача фактических учетных данных важна (журнал аудита). В этом случае у Вас, вероятно, будут разные уровни полномочий. Каждый уровень должен иметь соответствующую группу безопасности домена Windows. Пользователи Windows должны быть членами тех групп. Те группы должны быть связаны с пользовательскими ролями базы данных в базе данных. Те роли базы данных должны иметь все полномочия.
  • Прямой доступ к базе данных. Вы будете видеть это больше с созданием отчетов о типе систем. В этом случае, группы безопасности Windows снова с доступом, предоставленным с помощью ролей базы данных.
5
ответ дан 3 December 2019 в 04:41

Вы собираетесь получить множество ответов на этом.

Я настроил отдельное приложение (читайте "на приложение"), учетные записи, которые используются в строках подключения. Ни у каких пользователей (кроме моей dev группы) нет прямого доступа к дб.

Я работаю, прежде всего, в корпоративной среде MS (.NET, SQL Server, Active Directory). Обычно аутентификация происходит через зарегистрированный пользовательский контекст тока и специализированные таблицы защиты. Код обрабатывает аутентификацию и затем получает разрешения приложения от базы данных. Это берет большую часть нагрузки обслуживания пользователей прочь меня и помещает его на наш отдел ИТ (политика паролей и сброс, истечение учетной записи, отключает, и т.д.).

3
ответ дан 3 December 2019 в 04:41
  • Я верю там потребностям быть по крайней мере достаточным количеством учетных записей так, чтобы, если один клиент дб начинает вызывать проблемы, можно было отключить ту учетную запись, не отключая весь доступ к серверу
  • Обычно я не буду использовать, устанавливают учетную запись для доступа больше затем к единой базе данных.
  • Я использую отдельный счет на веб-приложение по сравнению с внутренним клиентом.
1
ответ дан 3 December 2019 в 04:41

Теги

Похожие вопросы