|
|
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
Надеюсь я не сильно надоел здешней публике ;) Хотелось бы обсудить вопрос безопасности клиент-серверных приложений. Вопрос, конечно, надо перенести в другой раздел форума, но: 1) Подразумевается ASA, и ее особенности. 2) Боюсь, что в другом месте это обсуждение перейдет в пустой спор, типа "что круче - pascal или c++". А здесь пока отвечают по существу, без лишней философии. Пишем к-с приложение. Создаем на сервере логин с правами db_owner (это в MSSQL, как в ASA еще не знаю) для пользователя. Так проще программировать, но с другой стороны "грамотный" пользователь возьмет Sybase Central, приконнектится к базе и прощай все данные. Делай что хочешь, права полные. Второй подход. db_owner не давать, весь доступ к таблицам закрыть хранимыми процедурами и вьюшками. В каждой процедуре проверять полномочия пользователя. Такой подход позволяет построить действительно защищенное приложени, но разрабатывать его значительно дольше и сложнее. Может быть есть другие идеи, чтобы и овцы были сыты и волки целы? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2004, 20:13 |
|
||
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
Можно имя юзера предлагать вводить такое же как и в базе, а вот пароль, который он вводит перед тем как передавать базе - перекодировать приложением. Соотв. прийдется написать прогу, которая бы эти пароли создавала. Имя тоже можно кодировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2004, 20:32 |
|
||
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
А чем не устраивают стандартные GRANT средствами СУБД ? Через них спокойно можно прописать кому чего можно читать, куда писать и что запускать. Юзерам owner и created ролей не давать, так что изменить или добавить структуру они не смогут. Для тех таблиц, в которых права пользователей распостраняются на определенные записи, соотвествующе по любому придеться их закрывать и давать доступ юзерам через нужные представления, где можно возвращать только нужные записи, фильтруя их по UserID с опцией WITH CHECK OPTION. По поводу первого подхода: можно конечно запретить логинам с правами owner конектиться к БД не из клиентского приложения. Для этого можно установить собственную процедуру инициализации подключения в опции LOGIN_PROCEDURE, в ней проводить проверку подключаемого приложения и параметров подключения и соотвествующе при нежелательном подключении убивать сессию. Есть еще и третий подход - установить БД в режим криптования. Тогда пользователь чтобы подключиться к базе данных самостоятельно должен будет ввести логин, пароль и ключ шифрования. Ключ можно вшить в приложение и соответствующе пока его не знаешь к БД нельзя будет не только подключиться, но и вообще вскрыть ее файлы или лог. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2004, 21:54 |
|
||
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
Я эту проблему и немного другую решил другим путем .Програмлю на Delfi,С++ Бюильдере. 1 Работа юзверей с базой идет только через ХП. 2.Грантую права только на Execute для этих ХП, а так как процедура выполняется с правами ownera то проблем изменить удалить или selectitь нет. 3.Все юзеры входят в группы . права на выполнение ХП раздаются группам. 4.К этим группам приписывается так некое число целое.(Таg) 5. в момент загрузки программы определяю в какие группы входит юзер , таким образом знаю какие Таги доступны данному юзеру. 5. Визуальные компоненты у Buildera имеют свое свойство Tag .. в дизайнере приписываю этому свойству значение целое число. 6.Есть процедура с++ , которая в момент инициализации формы (при запуске)сканирует все компоненты которые входят в состав формы и проверяет значение Tag , Если Таг компоненты =0(по умолчанию) , или входит в состав тегов групп взятых из БД , тогда Enabled=true иначе Enabled || Visible = false .. Вот собственно и все ... Прав на изменение таблиц через SQL - запросы у ползователей нет ..Вся работа через процедуры ... Плюс еще отслеживается доступ к управляющим элементам клиентского интерфейса и управление им на основании прав юзера .. Конечно сложно немного .. но идея мне нравится и главное красиво .. ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2004, 11:57 |
|
||
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
PaulJB, не совсем понял идею. Геша, с хр. процедурами понятно, писать "лишнего" кода больше приходится. ASCRUS, я правильно понял, что ключевое слово "WITH CHECK OPTION" ? Т.е. над view можно выполнять insert, update, delete, причем они будут выполнены только при соблюдении условия WHERE, описанного во view? Если это так, тогда становится все просто и красиво. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2004, 19:05 |
|
||
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
Если ASA cтоит на контроллере домена Windows NT, то можно организовать авторизацию через систему безопасности домена, так называемый Integrated login, тогда в базе прописываешь пользователей базы, которым ставишь в соответствии пользователей домена NT, в результате для доступа к базе пользователю не надо знать ни имя ни пароль. В довершению к этому можно не ставить инструменты, для доступа к базе через ODBC хватает одной DLL, правда если добавлять DSN ручками то нужны еще 2-е А вообще, все надо делать через ХП. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2004, 21:53 |
|
||
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
авторТ.е. над view можно выполнять insert, update, delete, причем они будут выполнены только при соблюдении условия WHERE, описанного во view? Угу, именно все так и есть. Данная опция поддерживается в ASA, ASE и MSSQL. Как в других СУБД честно говоря не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2004, 22:27 |
|
||
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
С вьюшками конечно хорошо , но не во все из них можно инзертить апдейтить или удалять .. это тоже надо иметь в виду .. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2004, 08:57 |
|
||
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
авторС вьюшками конечно хорошо , но не во все из них можно инзертить апдейтить или удалять .. это тоже надо иметь в виду .. Гм. Дык представления в данном случае делаются как SELECT * FROM Table, и они всегда будут обновляемыми. Все дальнейшие запросы будут делать на их основе так, как будто бы они являются таблицами. Кстати производительность от этого совсем не пострадает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2004, 10:06 |
|
||
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
ASCRUS Если делать вьюшки как "Select * from Table" тогда смысл во вьюшках? практически тоже самое просто брать таблицы и все .. (... я просто совсем мало работал со вьюшками , может быть чтото не понимаю (с раздачей прав на них) ) Тут я насколько понял проблема в разграничении прав пользователей в зависимости от выполняемых ими фукций .. конечно можно раздавать права им на вставку или обновление и тп .. как для таблиц так и вьюшек .. но мое сугубо личное имхо все это гораздо легче (проще) делать грантуя права на Execute для конкретной ХП .. ХП делается с овнером DBA или DBO . Никаких прав на таблицы или вьюшки юзверям не дается а все действия юзеры выполняют через ХП . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2004, 10:30 |
|
||
|
Безопасность
|
|||
|---|---|---|---|
|
#18+
Геша, что вьюшка определяется, как Select * from Table WHERE some condition WITH CHECK OPTION. Таким образом убиваются два зайчика: 1) Юзер видит только те строки, которые ему положено видеть 2) Юзер не может изменить "чужие" строки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2004, 13:42 |
|
||
|
|
start [/forum/topic.php?fid=55&msg=32497636&tid=2014513]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
153ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
| others: | 277ms |
| total: | 523ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
