При подключении SAP Business One к SQL Server 2005 - PullRequest
1 голос
/ 12 декабря 2008

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

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

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

Ответы [ 4 ]

1 голос
/ 17 декабря 2008

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

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

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

0 голосов
/ 28 декабря 2008

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

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

0 голосов
/ 19 декабря 2008

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

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

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

Correct.

меня беспокоит то, что если я войду в свою машину с помощью 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.

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

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

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

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

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

0 голосов
/ 18 декабря 2008

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

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

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

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

...