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

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

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

Так или иначе: каковы лучшие методы для того, чтобы настроить это?

4 ОТВЕТА

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

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

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

1
17.12.2008 03:10:14

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

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

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

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

0
18.12.2008 12:53:05

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

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

Итак, что вы говорите, если бы у меня был userId "MYDOMAIN / nick" ... тогда в AD вы бы назначили MYDOMAIN / nick группе с другими людьми, которые используют это же приложение, а затем в SQL Server вы бы добавить эту группу в безопасность и назначить ей роль?

Правильный.

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

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

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

Затем вы можете иметь вторую программу на вашем ПК, которая затем будет использовать второе имя пользователя для аутентификации на сервере SQL, например, MYDOMAIN / mycustomprogram2

Таким образом, на том же ПК у вас будет:

  • MYDOMAIN / ник (AD)
  • MYDOMAIN / mycustomprogram (пользователь SQL или AD)
  • MYDOMAIN / mycustomprogram2 (пользователь SQL или AD)

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

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

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

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

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

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

0
19.12.2008 10:14:31

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

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

0
28.12.2008 17:07:17