Хранение и использование учетных данных учетной записи Microsoft в базе данных SQL Server 2008

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

Часть моего программного обеспечения (приложение VB.NET) требует возможности доступа/чтения/записи в общую сетевую папку. У меня есть возможность для пользователя указать любые учетные данные, которые могут потребоваться для доступа к указанной папке.

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

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

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


sql sql-server password-protection user-accounts
person instantmusic    schedule 26.04.2010    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Сам SQL Server имеет средства для хранения учетных данных Windows, см. СОЗДАНИЕ УЧЕТНЫХ ДАННЫХ:

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

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

Единственными правильными сценариями доступа к ресурсам являются:

  • как пользователь, запускающий приложение, т.е. обычный заурядный вариант использования
  • в качестве службы, которая олицетворяет подключенного пользователя, что делается путем получения маркера удаленной идентификации из проверки подлинности SSPI, например NegotiateStream.RemoteIdentity
person Remus Rusanu    schedule 26.04.2010
comment
Спасибо всем за ваши ответы, я думаю, что проверка подлинности Windows подойдет. Если я могу попросить вас немного больше информации, конечная цель этого приложения состоит в том, чтобы иметь много пользователей с разными разрешениями (зависит от группы пользователей). Теперь я понимаю, что я должен разрешить приложению конечного пользователя доступ к указанному сетевому ресурсу и указать определенные разрешения для пользователя/группы в настройках их учетной записи Windows. Правильный? Кроме того, как вы думаете, где я должен хранить разрешения для конкретных приложений? Могу ли я каким-то образом указать эти разрешения так же, как и другие разрешения Windows? - person instantmusic; 27.04.2010
comment
Вы можете разрешить доступ к ресурсам для определенных пользователей/групп. Вы можете разрешить доступ к вашему приложению определенным пользователям/группам. Чего вы не можете сделать, так это разрешить доступ к ресурсам для определенного приложения. Просто не существует инфраструктуры, позволяющей аутентифицировать *приложения, в отличие от пользователей. Чтобы разрешить доступ к ресурсу для пользователя или группы, измените ACL ресурса (список управления доступом) либо из оболочки пользовательского интерфейса, либо с помощью такого инструмента, как cacls.exe. - person Remus Rusanu; 27.04.2010
comment
Ааа, извините, я думаю, что, возможно, немного неправильно выразился. Я хотел сказать, что приложение будет напрямую обращаться к папке, а то, что оно может/не может делать с папкой, будет определяться учетной записью пользователя, вошедшего в систему и использующего программу. Моя следующая проблема — это настраиваемые разрешения для приложений (у пользователя есть доступ для просмотра этой формы/сетки, пользователь может добавлять/редактировать/удалять записи из этой сетки и т. д.), но просто быстрое чтение выглядит так, как будто мне придется хранить разрешения для конкретных приложений. в моей БД и сопоставьте пользователей/группы с разрешениями для конкретных приложений вручную. Это верно? Я широко открыт для советов. - person instantmusic; 27.04.2010
comment
Я понимаю. К сожалению, нет готового модуля для выполнения этого требования. Вы в значительной степени должны свернуть свой собственный, с нуля. Для веб-приложений поставщик членства обрабатывает это за вас, см. msdn.microsoft.com/ en-us/library/tw292whz.aspx. Для форм нет встроенного механизма. Некоторые пытались перенести поставщика ASP в формы, см. msmvps.com. /blogs/theproblemsolver/archive/2006/01/12/80905.aspx. - person Remus Rusanu; 27.04.2010
comment
Основы реализации авторизации в приложении выглядят следующим образом: вы определяете ресурсы (например, экраны и операции) и идентифицируете их по некоторому идентификатору (например, имени). вы предоставляете средства для настройки и хранения доступа к ресурсам: домен\пользователь получает доступ к форме1, встроенный\всем предоставляется доступ к форме2, машина\группаА запрещается доступ к форме1 и т. д. Затем в приложении вы посмотрите на токен текущего пользователя WindowsIdentity.GetCurrent(), перечислите группы и проверьте, должен ли ему быть предоставлен доступ да/нет к форме/операции, которую вы собираетесь отображать/выполнять. - person Remus Rusanu; 27.04.2010
comment
Правила авторизации доступа выглядят так: один DENY превосходит все GRANTS. Поэтому вы должны проверить все группы, в которых состоит пользователь. Если какая-либо группа ЗАПРЕЩЕНА, то пользователь не авторизован. Если нет DENYies и есть хотя бы gRANT, пользователь авторизован. ЕСЛИ нет DENY и GRANT, пользователь не авторизован. Все становится более запутанным/запутанным/сложным, если у вас есть иерархия доступа (например, доступ к операции, потому что вы предоставили доступ к форме). - person Remus Rusanu; 27.04.2010
comment
Отлично, мне нужно немного почитать, но это именно то, что я ищу. Большое спасибо за ваше время! - person instantmusic; 27.04.2010
comment
Однако на практике существует более простая модель, с которой работает большинство приложений: модель role. Вы определяете несколько ролей, полученных из вариантов использования приложения (например, администратор, посетитель, пользователь, редактор). Затем вы добавляете/удаляете пользователей в роли. Доступ к формам/операциям контролируется этими фиксированными ролями. Вам по-прежнему необходимо проверять токен текущего пользователя на членство в группе в коде, но, по крайней мере, вам не нужно предоставлять собственный язык разрешений GRANT/DENY/REVOKE и иерархию, вы просто разрешаете фиксированный набор ролей. - person Remus Rusanu; 27.04.2010

arrow_upward
0
arrow_downward

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

person Thomas    schedule 26.04.2010

arrow_upward
0
arrow_downward

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

Ну, возможно, не настоящее слово, а что-то вроде случайного массива байтов или чего-то подобного.

person Jonas B    schedule 26.04.2010