| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Технология организации удалённого доступа к IB базам [D6, IB6.x]
DeepSky © (2004-09-17 17:39:00)Уважаемые Мастера, нужен совет по сабжу.
Идея такова - на серваке стоит InterBase'овая БД. Необходимо организовывать к ней удалённый доступ по I-net'у. Кол-во удалённых клиентов - 30. Используемый WEB-cервер - Apache 2.0.49.
Клиентские формы хочеться сделать автономными (т.е. не в броузере), скорее всего используя IBExpress.
Как организовать связь клиентских форм с IB сервером?Никогда не работал по удалённому доступу с базами данных, потому с особой благодарностью будут встречены советы с указанием на документацию по этому вопросу.
Sergey_Masloff (2004-09-19 13:01:00) [1]Роман Снегирев (19.09.04 12:46) [27]
Ну, на 90% я работаю действительно с другим сервером... Но с IB стаж работы у меня лет 10 ;-) Там тоже много можно сделать и довольно гибко.
Причем пойми - я тебя не критикую. В случае с ASP твой подход вполне нормальный.
Роман Снегирев (2004-09-19 12:46:00) [2]ну ладно, ты вот сам какой сервак БД в работе используешь? думаю что не FB (уверен даже). если бы мне дали работать с к-л другим серваком, я бы возможно и перешел на встроенные средства безопасности сервера. а здесь вопрос то кстати был именно про FB
Sergey_Masloff (2004-09-19 11:09:00) [3]Роман, ну почему ты опять не хочешь читать. Ты привел другой пример, на другую тему. Поясню еще раз.
В твоем примере у юзера НЕТ клиента. Защита на сервере (в твоем случае сервере приложения). Поэтому твоя защита работает. Но если у тебя появится необходимость работы не через ASP то тебе придется твою безопасность реализовать второй раз. Потом третий и так далее причем реализуя третий ты придумаешь новую фичу которую забудешь добавить в первые два.
Роман Снегирев (2004-09-19 11:02:00) [4]я не буду спорить, я же привел пример, где там дыры?
Sergey_Masloff (2004-09-19 10:51:00) [5]О том что человек хочет клиент-серверной работы через Инет. Ему пояснили что это есть нехорошо. Ты сообщил что нет-хорошо. В доказательство привел пример в котором работа с базой организована СОВЕРШЕННО по другому. Вот и все.
При работе в клиент-серверной архитектуре пароль юзера к базе известен ВСЕГДА. Если безопасность обеспечивается ВНЕ базы это уже дыра. Потому что я с паролем юзера подключусь через isql и буду делать с базой очень много чего нехорошего.
Роман Снегирев (2004-09-19 10:42:00) [6]да читать то умеем, мы вообще о чем говорим? мне казалось что о безопасности. вообщем в чем проблема-то?
Sergey_Masloff (2004-09-19 09:46:00) [7]Роман Снегирев (19.09.04 07:01) [19]
Читать умеем?
>Клиентские формы хочеться сделать автономными (т.е. не в броузере),
При чем здесь ASP? У тебя клиент (БД) на сервере же ж ;-) Да и 3050 порт вовне закрыт наверное (если не закрыт лучше все ж закрой)
Теперь читаем
Sergey_Masloff (18.09.04 23:40) [17]
последнее предложение первого абзаца ;-) до полного прояснения.
Роман Снегирев (2004-09-19 09:36:00) [8]я повторяю, что вся безопасность реализоавана н ауровне бизнес-логики
http://www.maslograd.ru/
логин roman
пароль q
Sergey_Masloff (2004-09-19 07:55:00) [9]Роман Снегирев (18.09.04 23:54) [18]
Давай клиента, валидный логин с паролем к базе (как будто я юзер). Можно будет в свободное время попробовать. Только все письмом с цифровой подписью на мой адрес с указанием цели с которой ты мне это предоставляешь.
Роман Снегирев (2004-09-19 07:01:00) [10]www.it-studio.ru там их до ж... (штук 50 в смысле)
Роман Снегирев (2004-09-18 23:54:00) [11]to Sergey_Masloff
Ну давай, достучись до моей БД (сервера конечно)...
Sergey_Masloff (2004-09-18 23:40:00) [12]Роман Снегирев (18.09.04 23:30) [16]
>что не надо использовать встроенные возможности сервера БД
Как раз надо. Защита которая не у тебя под боком это не защита. Потому что всегда в твою базу можно коннектнуться не твоим клиентом. Поэтому защита - ТОЛЬКО на сервере, с СУБД или сервере приложений (лучше и там и там).
А бизнес-логика это понятие абстрактное. Может быть вся логика в СУБД. Может быть логика на сервере приложений. Конечно (самый худший вариант) логика может быть и на клиенте.
Роман Снегирев (2004-09-18 23:30:00) [13]короче, ребята, лично я всегда безопасность (роли/права/юзеры) реализую на уровне бизнес логики приложения. ИМХО так более удобно и гибго. вообщем я к тому что не надо использовать встроенные возможности сервера БД
Sergey_Masloff (2004-09-18 21:05:00) [14]kaif © (18.09.04 20:52) [14]
Ты прав насчет безопасности. Но это не все. Работа в клиент-серверной идеологии на медленных каналах это ужас. Во всех отношениях. Так работать НЕЛЬЗЯ.
kaif © (18.09.04 01:10) [7]
>Говорят, что такой способ не очень безопасен. Кстати, правильно >ли говорят? Я не знаю (слышал об атаках типа заходит юзер и >создает внешнюю таблицу от своего имени.
Не обязательно так. Можно еще создать временную таблицу из одного поля типа CHAR(1). А в качестве имени файла указать имя файла бд (.gdb). После этого селектом из этой таблицы можно вытащить на клиента ВСЮ базу. Нет, в FB можно запретить в конфиге создание временных таблиц в определенных папках. Но кто-то это делает? ;-)
DeepSky © (17.09.04 17:39)
Извини, но ты несешь пургу. Если у тебя Web-сервер то при чем здесь "формочки". Если ты хочешь с работать с IB просто как с сервером это одно. Если ты хочешь обеспечить работу клиента через WEB - интерфейс то это другое. Если ты хочешь написать свой аналог WEB SNAP то (судя по уровню вопроса) рановато.
Кстати и про временные таблицы... для IB это одно из самых плохих решений.
kaif (2004-09-18 20:52:00) [15]OK
А теперь представим себе юзера, еоторый имеет права инсертить только в эту вьюху (это-то прекрасно). Но юзер подключается с помощью своего ISQL или IBExpert и выполняет всего три команды:
CREATE TABLE FUCKALL(FUCKSTRING VARCHAR(20));
SET TERM ^;
CREATE PROCEDURE INSERT_INTO_FUCKALL_LIKE_HELL
AS
BEGIN
WHILE (1=1) DO
BEGIN
INSERT INTO FUCKALL(FUCKSTRING) VALUES ('FuckAll');
END
END
SET TERM ;^
EXECUTE PROCEDURE INSERT_INTO_FUCKALL_LIKE_HELL;
И дальше (я так думаю) сервер висит.
А можно сделать по миллиону записей с коммитом, если в WHILE счетчик поставить до миллиона и коммиттить после каждого вызова процедуры. От юзеров защищаться смысла нет даже вьюхами. А вот от хакеров чтобы защититься, нужно чтобы IB не позволял создавать новые таблицы. А это он вроде как раз позволяет. Любому юзеру. Я специально не проверял, но мне кажется, что это именно так. Создавший таблицу становится ее OWNER и делает с ней, что хочет. В том числе и инсертит в нее все, что хочет и сколько хочет. А если SYSDBA решит, не останавливая сервер, удалить эту таблицу, то он получит сообщение 'table is in use'. Так что придется останавливать сервер и удалять руками, потом бакапить и ресторить и писать письма хакеру с просьбой больше так не делать.
Я об этом говорю...
-SeM- (2004-09-18 16:43:00) [16]Роман Снегирев (18.09.04 15:46) [12]
Откуда такое умозаключение?
DeepSky © (18.09.04 14:04) [11]
Берем простой вариант: у нас есть две таблицы, на основе которых построен просмотр, который является редактируемым (с пом. триггеров). Есть пользователи SYSDBA(куда нам без него :)), CREATOR (который создает базу), USER1 (который работает с базой), USER2 (он только смотрит).
Первым делом создаем домен SYSDBA - пользователю с таким именем хватит и isc4. В нашей базе ему делать нечего.
Потом убираем ВСЕ права со ВСЕХ таблиц и просмотров (не забываем про "виртуального" пользователя PUBLIC).
Далее раздаем необходимые права свои людям :) : в нашем случае ВСЕ права для USER1 на вьюху, только селект для USER2 на вьюху и ОБЯЗАТЕЛЬНО триггерам вьюхи (с учетом назначения) на таблицы, с которыми они работают.
И что мы после этого имеем? SYSDBA не подключится, CREATOR - имеет полные права, USER1 - все права на работу ТОЛЬКО с вьюхой, USER2 - права ТОЛЬКО на просмотр данных из вьюхи.
Остается базу записать на сервер, который закрыть в сейф, который закопать глубоко в землю. В таком случае бекап сможет сделать только CREATOR.
Роман Снегирев (2004-09-18 15:46:00) [17]вообщем сейчас в интербесе права/роли сделаны через ж..., жди выхода Firebird 2
DeepSky (2004-09-18 14:04:00) [18]Кстати, родился ещё один вопрос. Я раньше работал с Ораклом так там была возможность дать доступ юзеру только к Вьюхе с правом Инсерта в таблицы, из к-рых эта Вьюха собираеться. Попробовал в Интербейсе - а, он, подлый выдаёт сообщение, типа: у этого юзверя нет права Инсертать в эту таблицу.
Вожможно ли всё же сделать вышеописаное, и, если возможно, то как.
DeepSky (2004-09-18 13:55:00) [19]На счёт безопасности не стоит беспокоиться. Организовум работу юзеров только через временные таблицы и сторед процедуры. И даём юзерам доступ только к ним.
kaif (2004-09-18 13:48:00) [20]Я не знаю и потому спрашиваю. Я много раз в инете сталкивался с разговорами на этот счет. Юзер даже с малыми правами все равно имеет право создавать таблицы. А это в принципе дырка для атаки.
| |
Страницы: 