При подключении SAP Business One к SQL Server 2005, что

у нас есть SAP Business One - Fourth Shift Edition, работающий здесь, в небольшой производственной компании. Консультационная компания, которая пришла для установки/внедрения, использует идентификатор/пароль "sa" для первоначального подключения к базе данных для получения списка компаний. С этого момента я должен предположить, что это идентификатор/пароль sa, который используется для подключения клиентского программного обеспечения к базе данных. Это уместно? Я не знаю, где хранятся эти данные... как соединение ODBC? прямо в реестре где-то? Это безопасно? Было бы лучше установить сетевой идентификатор пользователя в безопасности базы данных, а затем вместо этого использовать параметр «доверенное соединение»? Или большинство людей создают отдельный логин в базе данных для каждого пользователя и используют его в настройках клиента?

кажется, что самым простым способом было бы добавить сетевой логин пользователей к безопасности сервера sql, чтобы они могли использовать «доверенное соединение» ... но тогда разве это не позволит ЛЮБОМУ программному обеспечению подключаться к базе данных с этой машины?

Итак, в любом случае: каковы наилучшие методы настройки?


sql-server database-connection sql-server-2005 sapb1
person Community    schedule 11.12.2008    source источник

Ответы (4)


arrow_upward
1
arrow_downward

Использование sa звучит как рецепт катастрофы.

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

Не зная больше об ограничениях SAP, я не могу быть уверен, но мы всегда склонны использовать аутентификацию Windows и группы Windows Active Directory. Эти группы разрешены в ролях SQL Server. Таким образом, все администрирование осуществляется на уровне AD. БД заблокирована в соответствии с этими ролями — даже если приложение имеет логин SQL Server или логин домена, оно будет находиться в одной из ролей базы данных, которые мы создали, назвали и предоставили права соответствующим образом.

person Cade Roux    schedule 17.12.2008

arrow_upward
0
arrow_downward

Это очень неправильно, учетную запись sa нельзя использовать для общего пользования.

Должна использоваться отдельная («специфичная» для приложения) учетная запись пользователя, чтобы:

  • Безопасность может применяться на уровне каждого пользователя (приложения).
  • Если что-то пойдет не так с приложением (например, оно заблокирует учетную запись пользователя), будет затронута только одна учетная запись, и проблемы легко диагностировать.

Я также согласен с комментариями Кейда Ру.

person Techboy    schedule 18.12.2008

arrow_upward
0
arrow_downward

Кейд... Я не верю, что ты можешь назначать роли "приложениям" в Windows...

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

Итак, вы говорите, что если бы у меня был идентификатор пользователя «МОЙ ДОМЕН / ник» ... тогда в AD вы бы назначили MYDOMAIN / ник группе с другими людьми, которые используют это же приложение, а затем в SQL Server вы бы добавить эту группу в безопасность и назначить ей роль?

Правильный.

Меня беспокоит то, что если я войду в свою машину с помощью MYDOMAIN/nick... это активирует всю мою машину как "доверенную" серверу sql (через аутентификацию Windows)... так что это означает, что я могу запустить Visual Studio и начать сборку любого приложение, которое я хочу, и потенциально подключаюсь напрямую к базе данных и делаю с ним все, что захочу... что также означает, что любое другое приложение, которое я могу загрузить/установить, потенциально будет иметь доступ к этой базе данных... верно?

Да, это правильно. Потому что вам (МОЙ ДОМЕН/ник) доверяют. SQL Server не знает, что вы используете на своем ПК.

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

Затем у вас может быть вторая программа на вашем ПК, которая затем должна использовать второе имя пользователя для аутентификации на сервере SQL, например. МОЙ ДОМЕН/моя пользовательская программа2

Итак, на том же ПК у вас будет:

  • МОЙ ДОМЕН/ник (AD)
  • MYDOMAIN/mycustomprogram (пользователь SQL или AD)
  • MYDOMAIN/mycustomprogram2 (пользователь SQL или AD)

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

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

Я узнал, что клиент SAP шифрует информацию о своем соединении и сохраняет ее в реестре.

О какой части связи вы говорите? Я не знаю, чтобы что-то хранилось таким образом.

Это отвечает на ваши вопросы?

Пожалуйста, проголосуйте за полезные ответы ;-)

person Techboy    schedule 19.12.2008

arrow_upward
0
arrow_downward

Я думаю, что это действительно зависит от уровня безопасности, который вы готовы предложить/поддерживать. В SAP Business One для создания нового входа в систему необходимо добавить определенные привилегии, такие как предоставление разрешения db_creator для базы данных и SBO-Common, или доступ к таблицам для чтения/записи и специальный доступ к хранимым процедурам, что довольно хлопотно.

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

person ianix    schedule 28.12.2008