Регистрация в системе Axapta

[raz]

Хочется вспомнить о Axapta 2.5, там на уровне самой аксапты можно было урезать доступ и это правильный вариант.

Конечно если работать в 2-х уровневой конфигурации, то все внутренние ограничения самой аксапты уже не помогут, но через АОС это очень даже работает.

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

А на уровне SQL урезать доступ к этим таблицам не правильно, т.к. пользователи должны иметь возможность менять свои пароли и настройки. А Аксапта должна иметь возможность проверить лицензии.

ИМХО, разработчикам надо вернуть возможность ограничивать доступ к системным таблицам на уровне Аксапты, т.е. через ключи безопасности и п.р. Но на уровне с этим, надо еще переделать механизм прямых запросов к SQL, т.к. это большая дыра в моей схеме, в него надо ввести авторизацию.

[Антон Солдатов]

Цитата:

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


А если Вася сначала зашифрованный пароль скопирует, обнулит пароль, что надо в Axapt-а сделает, затем зашифрованный пароль обратно вставит? Сузим ли мы круг подозреваемых?

Можно журналировать все изменения таблицы userinfo, как средствами СУБД, так и Аксапты

Цитата:

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

не надо всю безопасность валить на средства СУБД.

не валите

Цитата:

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

Особенно если СУБД часто валит её на средства операционки (MS SQL аутентификация пользователя Операционной Системы).

Поправка. Валит не СУБД, а администратор СУБД - все претензии к нему. Никто не заставляет пользоваться средствами ОС для аутентификации. Кстати, возможность свалить аутентификацию на ОС есть и в Аксапте.

[Vadik]

Ок, покажите мне, как пользователь без доступа к таблицам SQL сервера, средствам разработки и "Администрированию" "копирует" или "обнуляет" чужой пароль, и будем думать над тем, как бы ужесточить ту систему безопасности, что есть сейчас. Если это сделать не удается, придется признать, что проблемы в основном - надуманные и можно потратить время на что-нибудь другое.

Так или иначе, IMHO администратор любой БД или разработчик (некто, имеющий доступ к средствам разработки) при желании из нее Вам вытащит все, что ему надо, и это проблема совсем не Аксапты и не только Аксапты. Не согласны - приведите пример

[raz]

2 vadik

Если пользователь работает в 2-х уровневой конфигурации, то он работает с SQL напрямую, таким образом он имеет доступ ко всем таблицам.
Ему можно заблокировать возможность что то менять, но он наверняка может много чего читать... например лицензионный ключи (что, ИМХО, есть плохо, т.к. это десятки или сотни тысяч $).

При работе через АОС все впорядке.
Но если у пользователя при этом есть право на разработку, то он может все, т.к. АОС работает наверняка с максимальным доступом к SQL.

[SlavaK]

Цитата:

Ок, покажите мне, как пользователь без доступа к таблицам SQL сервера, средствам разработки и "Администрированию" "копирует" или "обнуляет" чужой пароль

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

Конечно можно сказать, что админ БД и из таблиц нужную информацию вытащит, но думаю через Axapt-у быстрее. Т.к. в таблицах инфо в нормализованном виде и ещё надо попарится, прежде чем нужную информацию в денормализованном виде получить - надо немного понимать бизнесс логику.

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

А так, по вашему варианту, и в самом деле ни от разработчиков ни от админа что прятаться - всё равно что захотят поимеют через таблицу userinfo.

[Vadik]

Цитата:

Если пользователь работает в 2-х уровневой конфигурации, то он работает с SQL напрямую, таким образом он имеет доступ ко всем таблицам. Ему можно заблокировать возможность что то менять, но он наверняка может много чего читать... например лицензионный ключи (что, ИМХО, есть плохо, т.к. это десятки или сотни тысяч $).

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

Что касается администратора БД, ему положено иметь доступ ко всему, ничего с этим не поделаешь, сольет ли он информацию на сторону или нет - дело мотивации, внутренней и внешней Ну и порядочности конечно, если такая присутствует

[raz]

2 Vadik
Согласен полностью, но остаются разработчики, как от них защититься?

[Vadik]

Цитата:

но остаются разработчики, как от них защититься?

Вы можете представить себе разработчиков, не имеющих прямого доступа (isql, QA, profiler, sqlplus etc..) к БД? Я - нет, вернее, я бы не стал работать в таких условиях. Видимо поэтому закрыть от разработчиков никакие данные (в т.ч. лицензионные коды) не получится

[raz]

2 Vadik
С одной стороны вы правы, но с другой...
Я могу представить таких разработчиков, не всем же вторую Аксапту писать, можно и формы поправить и отчеты поделать.

[Антон Солдатов]

Цитата:

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

Вы можете представить себе разработчиков, не имеющих прямого доступа (isql, QA, profiler, sqlplus etc..) к БД? Я - нет, вернее, я бы не стал работать в таких условиях. Видимо поэтому закрыть от разработчиков никакие данные (в т.ч. лицензионные коды) не получится

в оракле есть object priveleges, с помощью которых можно разрешить определенные операции определенным пользователям на определенные объекты(в данном случае tables, indexes). создаем для разработчиков отдельного пользователя(ей) и не мучаемся.

[SlavaK]

Цитата:

в оракле есть object priveleges, с помощью которых можно разрешить определенные операции определенным пользователям на определенные объекты(в данном случае tables, indexes). создаем для разработчиков отдельного пользователя(ей) и не мучаемся.

Вот и я про них же . В MS SQL кстати объектные привилегии тоже есть.

Цитата:

Вы можете представить себе разработчиков, не имеющих прямого доступа (isql, QA, profiler, sqlplus etc..) к БД? Я - нет, вернее, я бы не стал работать в таких условиях. Видимо поэтому закрыть от разработчиков никакие данные (в т.ч. лицензионные коды) не получится

Я при разработке под Oracle и MS SQL, по крайней мере при закрытых не моих таблицах никогда не страдал. По крайней мере ну если не пишу я зарплату - ну зачем права мне на все таблицы зарплаты? - по крайней мере на рабочей БД?

[raz]

2 SlavaK

Речь идет не о Вас, о возможности злоупотребления, которая в нормальных системах сводится к минимуму. Даже в 2.5 версии еще можно было не давать доступ к системным таблицам на уровне аксапты.

[SlavaK]

Цитата:

Речь идет не о Вас, о возможности злоупотребления, которая в нормальных системах сводится к минимуму. Даже в 2.5 версии еще можно было не давать доступ к системным таблицам на уровне аксапты.

Так о том и речь - что когда разрабатываешь сам самописную систему на такие вещи обращаешь внимание. А в системах предлагаемых за более чем 500 тыс. $ тебе говорят оно тебе надо, - это по меньшей степени и раздражает. Наверно надо - а за что тогда деньги платить? - за долатывание дыр, присутсвующих в покупаемой системе?

Я конечно понимаю впервую очередь Axapt-у покупают не из-за технических возможностей, а за функционал, но думаю о технических возможностях и тем более защите от НСД входа в систему нужно думать прежде всего разработчикам Axapta, а не клиентам, которые её покупают.

В общем дискуссия у нас пошла на уровне эмоций. Большое спасибо всем за информацию по регистрации пользователей. То что меня интересовало я узнал.
Я заканчиваю участие в данной дискусии.

[Vadik]

Цитата:

в оракле есть object priveleges, с помощью которых можно разрешить определенные операции определенным пользователям на определенные объекты(в данном случае tables, indexes). создаем для разработчиков отдельного пользователя(ей) и не мучаемся.

Попробовал запретить SELECT на таблицу с лицензионными кодами - получил на старте системы select permission denied on <ну вы знаете какая таблица>, потом "объект Application не создан", работать в системе нельзя
Так что как минимум с ключами не все так просто

[Антон Солдатов]

Цитата:

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

Попробовал запретить SELECT на таблицу с лицензионными кодами - получил на старте системы select permission denied on <ну вы знаете какая таблица>, потом "объект Application не создан", работать в системе нельзя
Так что как минимум с ключами не все так просто

права нужно запрещать не для юзера bmssa(или под каким там аксапта работает), а для пользователя специально созданного для целей low-level тестирования и разработки.
у пользователя bmssa смените пароль по умолчанию и никому кроме конфигурации AOS его не сообщайте.

[Vadik]

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

Цитата:

права нужно запрещать не для юзера bmssa(или под каким там аксапта работает), а для пользователя специально созданного для целей low-level тестирования и разработки

Ну вот собственно он-то и посылается. Грубо говоря "нет ног - нет варенья", или "нет прав на select * from <лицензионные коды> - клиент Аксапты не запускается". Антон, если у Вас описываемая Вами конфигурация работает - готов обсудить ее по почте, если нет - попытайтесь ее воспроизвести, чтобы была уверенность, что мы говорим об одном и том же

[Антон Солдатов]

Цитата:

Изначально опубликовано Vadik
Я снова чего-то не понял.

Вы действительно чего-то не поняли. Нужно разделять пользователей БД и пользователей Axapta. Когда я говорил, что создадим отдельного пользователя для разработчиков и обрежем ему привелегии, то я имел в виду пользователя СУБД, а не Аксапты.

Вот пример который работает. sqlplus. Oracle.

Цитата:

CONNECT bmssa/bmssa_pwd
SELECT * FROM BMSSA.ADDRESS
>>ОК
SELECT * FROM BMSSA.SYSCONFIG;
>>OK

CREATE ROLE "AX_DEV" NOT IDENTIFIED;
GRANT SELECT ON BMSSA.ADDRESS TO "AX_DEV";
GRANT "CONNECT" TO "AX_DEV";

CREATE USER "AX_DEVELOPER" PROFILE "DEFAULT"
IDENTIFIED BY "test" DEFAULT TABLESPACE "AXTAB"
ACCOUNT UNLOCK;

GRANT "AX_DEV" TO "AX_DEVELOPER";

CONNECT AX_DEVELOPER/test

SELECT * FROM BMSSA.ADDRESS;
>>ОК
SELECT * FROM BMSSA.SYSCONFIG;
>>TABLE OR VIEW DOES NOT EXIST

И после этого, аксапта вполне запускается(да иного и не могло быть)

[Vadik]

Цитата:

Нужно разделять пользователей БД и пользователей Axapta. Когда я говорил, что создадим отдельного пользователя для разработчиков и обрежем ему привелегии, то я имел в виду пользователя СУБД, а не Аксапты.

Ага. Начинаю понимать. Т.е. в аксапте он все равно работает с "полноценным" (полноправным) логином?

[Антон Солдатов]

Цитата:

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

Ага. Начинаю понимать. Т.е. в аксапте он все равно работает с "полноценным" (полноправным) логином? А как быть с UserConnection?

теперь я Вас понял даже без прямого sql-я можно получить доступ к проблемной таблице. Такой Job вполне работает:

PHP код:

static void toha_Job11(Args _args)
{
    SysConfig test;
    ;
    while select * from test{
        info(test.value);
    }
} 


[Vadik]

Отлично. Предлагаю сэкономить время модераторам и подчистить сообщения

Резюме: проблемы есть, и непонятно, кому их адресовать. Думаю, российский MSBS нам тут не помощник