Безопасность и авторизация

[Andrew Besedin]

Добрый день!
Возможно ли, чтобы каждый пользователь Аксапты входил на SQL-сервер под своим логином/пассвордом с настроенными персонально для него правами чтения/записи на базу?

Спасибо,
Андрей

[mazzy]

Я не спец в SQL. Я пытался сделать так в тестовых целях. Вроде получалось.
Я прописывал пользователей и назначал им owner'а.
Использовал sp_change_users_login (см. BOL)

Интересно, есть ли противопоказания... Вроде не обнаружил. Правда права овнера, на мой взгляд, слишком большие.

[ViGo]

А зачем узверю лезть на SQL-сервер.
Какая задача/незадача?

[glibs]

Цитата:

Изначально опубликовано Andrew Besedin
Возможно ли, чтобы каждый пользователь Аксапты входил на SQL-сервер под своим логином/пассвордом с настроенными персонально для него правами чтения/записи на базу?

Вопрос требует конкретизации.

Пользователь Аксапты ходил Аксаптой или сторонней софтиной (типа Кристала)?

Если Аксаптой, то зависит от конфигурации (бывает двухуровневый клиент-сервер и трехуровневый, последняя делится на тонкого и толстого клиента). При трехуровневом тонком клиенте - нет. В остальных случаях - можно. Но только скажи зачем. С высокой вероятностью может возникнуть проблема. Oracle я не видел, но в MS SQL права настраиваются на уровне таблиц. Я настраивал руками и это было утомительно (можно ли это автоматизировать - не знаю. Не специалист). Подумай, сколько тебе нужно пользователей и чем это будет чревато, если в Аксапте появится новая таблица. А для того, чтобы это случилось в Аксапте достаточно сециально или случайно изменить настройку функциональных ключей. Если я не ошибаюсь, в MS SQL нет разграничения доступа на уровне полей. В случае с Аксаптой View тебе вряд ли поможет, а с тригерами - не знаю, но думаю, что тоже. Посоветуйся со специалистами.

Если сторонней софтиной - то можно. Но есть нюансы. См. конец предыдущего абзаца.

Что-то мне подсказывает, что если начнешь резать доступ не средствами Аксапты - получишь кучу проблем. Не такая уж она простая.

[mazzy]

ViGo, glibs

на самом деле вопрос предельно актуальный.

Аксапта пользуется ODBC. Этим же ODBC можно воспользоваться из Excel, Access и т.п. И унести любые данные.

Вопрос состоит в том, как пользователю, который имеет полный доступ к своей машине, ограничить доступ к данным на SQL-сервере.

Штатные средства предусматривают, что на SQL-сервере настраиваются различные учетные записи и им раздаются права.

Например, кладовщик должен входить под учетной записью для кладовщика и не должен видеть список сотрудников, оклады, клиентов, поставщиков и т.п.

[glibs]

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

А разграничение на уровне сервера БД - все равно не выход. Это тупиковый путь. Рядовой пользователь не должен иметь возможности лазить грязными руками в таблицах БД в принципе. Это грубое нарушение концепции безопасности, которое может привести к разрушению целостности данных в случае неумышленных действий пользователя и к неотраженным в журнале модификациям данных при умышленных его действиях.

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

Аксапта не предполагает использования штатных средств MS SQL. Я так понимаю. Разграничение доступа в ней реализовано на прикладном уровне. Так что вопрос как обезопасить двухуровневую конфигурацию действительно актуален. Но это не проблема Аксапты - это проблема двухуровневой конфигурации клиент-сервер как таковой.

[mazzy]

Цитата:

Изначально опубликовано glibs
А разграничение на уровне сервера БД - все равно не выход. Это тупиковый путь.

Почему? Только потому, что сложно администрить?
Но ведь можно не заводить на каждого аксаптовского пользователя свой СКЛ-логин.
Можно завести пять-десять СКЛ-логинов, которые представляют роль пользователя.
Например, кладовщиков в Аксапте - человек 10. Для них для всех дать один СКЛ логин. А для продавцов, например, другой?

Цитата:

Изначально опубликовано glibs
Рядовой пользователь не должен иметь возможности лазить грязными руками в таблицах БД в принципе. Это грубое нарушение концепции безопасности, которое может привести к разрушению целостности данных в случае неумышленных действий пользователя и к неотраженным в журнале модификациям данных при умышленных его действиях.

Аболютно согласен. А что делать с паролями доступа, которые храняться в конфигурационной утилите? Понятно, что можно положить их в файл и хранить на сервере... Это, конечно, затруднит "интересующимся" жизнь, но тоже... Таких файлов должно быть несколько для разных людей в файлах должны находится разные пароли.

Т.е. вопрос сводится к вопросу, который задал Andrew Besedin.

[Andrew Besedin]

Цитата:

Изначально опубликовано mazzy

Аксапта пользуется ODBC. Этим же ODBC можно воспользоваться из Excel, Access и т.п. И унести любые данные.

2 Сергей:
Вот это-то как раз и не актуально - SQL юзер/пароль не нужно хранить в ODBC - только в утилите конфигурирования AX. Так что все зависит от того, насколько "прочно" этот пароль зашифрован. Я задал этот вопрос на partnerguide.com - там они его отвечают.

2All:
А сделать можно (и нужно, очевидно) так: "простым" юзерам (или группам) Ax постаивть в соответствие SQL-юзеров с ролью db_datareader + несколько системных таблиц разрешить на Insert И Update. А разрешения на Select для "ненужных" таблиц запретить. Т.о. все получится просто классно - права юзера Ax дублируются на SQL.

[glibs]

Цитата:

Изначально опубликовано Andrew Besedin
[B]Вот это-то как раз и не актуально - SQL юзер/пароль не нужно хранить в ODBC - только в утилите конфигурирования AX. Так что все зависит от того, насколько "прочно" этот пароль зашифрован. Я задал этот вопрос на partnerguide.com - там они его отвечают.

Точно. Зашифрован. Спасибо. Не обратил внимания. Это хорошо... Наверное.

Если не сложно, можно для ленивых ссылочку на partnergide.com.

Но скажите мне теперь пожалуйста, для чего в таком случае клиентом Аксапты заходить под разными логинами (MS SQL серверными). Вас не устраивает разграничение доступа на уровне таблиц, реализованное на прикладном уровне?

[Andrew Besedin]

2glibs:
Конечно не устраивает, т.к. "прослушать" сеть нет никаких проблем. И если SQL-юзер, с которым простой пользователь ходит в Аксапту есть db_securityadmin (а остальные привилегии не важны!), то есть прямой смысл смастерить "приблуду", которая дешифрует пароль. А если это только db_datareader (да и то, без МНОГИХ таблиц), то смыл заморачиваться теряется.
Система безопасности Ах хороша, пока "ценность" данных невелика. В противном случае - пиши "пропало" :-)) (ИМХО).

По поводу partnergude.com: ссылку давать смыла нет, т.к. все равно нужна авторизация, а вот код моего реквеста RU-393-896-FBCX.

[glibs]

2 Andrew Besedin:

Ну, если у вас сеть можно прослушать без проблем (есть специалисты, которые это могут и будут делать), то наличие или отсутствие ограниченных логинов ничего не меняет, т.к. в этой сети можно слушать и трафик админа и ломать его пароли. Конечно, вы сможете предложить варианты, но как правило это так.

Если вопрос ставить таким образом, то нужно использовать тонкого клиента с надежным шифрованием трафика на участке клиент - АОС. Все остальное проблему не решит. А вообще сломать можно все.

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

За код запроса спасибо.

[macklakov]

IHMO двухслойка в принципе не может быть достаточно защищенной, если хотите безопасности, ставьте AOS. И чем тоньше клиент, тем безопаснее ;-)