Как защитить базу???

← →
Sirus (2003-06-17 06:57) [0]

Привет Мастера...
Есть вопрос: Как можно защитить базу Interbase/Firebird от нескромных пользователей и их друзей???
Проблема в том, что пользователи опируют файл данных на другой комп, где их друг (плохой человек)входит в базу с SYSDBA и masterkey. База изменяется и возвращается на комп где стоит прога...

← →
Alexandr (2003-06-17 07:07) [1]

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

← →
Sirus (2003-06-17 07:14) [2]

В базе хранятся расчеты с абонентами... т.е. сколько они должны организации ил наоборот, Сеть обычная локальная, Прога на Дельфи, База на Firebird, Юзеры обчные и злые (у них з/п маленькая :)) а их друзья - люди которые хотят приуменьшить свои долги и долги левых людей за деньги (наликом). В общей сложности по организации в месяц теряется подобным путем около 100 000 денежных единиц. А пользователи навариваются на 50 000...

← →
Zacho (2003-06-17 07:24) [3]

> Sirus © (17.06.03 07:14)

Самое простое и правильное - поставить IB на сервер снормальной операционкой (например, NT) и настроить секьюрити - в частности, права на доступ к файлу БД должны быть только у админа БД и учетной записи, под которой работает IB

← →
Sirus (2003-06-17 07:51) [4]

> Zacho © (17.06.03 07:24)
Такая защита оказывается не подходит... пользователям ничего не стоит подключить к делу Админа за определенную плату с левых...

← →
Alexandr (2003-06-17 08:20) [5]

аудит в NT есть.
ну вы блин даете...

← →
Zacho (2003-06-17 08:24) [6]

> Sirus © (17.06.03 07:51)

Все это решается административными мерами.
А вообще - еще можно попробовать всякие извращения типа создания роли с именем SYSDBA.

← →
Sirus (2003-06-17 08:41) [7]

А нельзя ли защитить файл базу от копирования во время работы программы. А по завершении работы программы испортить файл БД. прога при запуске будет его восстанавливать а потом работать...

← →
Zacho (2003-06-17 09:01) [8]

> Sirus © (17.06.03 08:41)

А не лучше ли тогда воспользоваться какой-либо криптосистемой ?

← →
Anatoly Podgoretsky (2003-06-17 09:01) [9]

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

А вообще у вас очень, очень большой бардак и при таких то потерях.

← →
KSergey (2003-06-17 09:34) [10]

И поверьте, что Anatoly Podgoretsky © (17.06.03 09:01) как минимум серьезен.
Вообще состояние дел оочень сильно удивляет, так мыгко скажем. И при чем тут техническая защита, если оказывается "админ может и сам поучаствовать"?!!! А работу потерять он не боится? А если не боится - тогда у вас все нормально, продолжайте в том же духе. Видимо, денежные потери весьма не велики для организации, раз присутствует такое положение вещей.

← →
Danilka (2003-06-17 09:53) [11]

Если "админ может и сам поучаствовать" то никакая защита, никакая криптография не спасет. Однозначно.

← →
gep (2003-06-17 10:14) [12]

Вопрос. А разве нельзя поменять пароль на SYSDBA. Потому как с masterkey любой придурок безовсякого ума разбереться, а вот ежели у SYSDBA будет другой пароль то его вырыть из базы - дело не тривиальное в общем случае. ИМХО. Или нет? Меня енто тожеть волнует. А то х.. его знает может и мои програмки когда-нить кто поиметь захатит.

← →
muzik (2003-06-17 10:21) [13]

gep Смена пароля не поможет. Базу можно скопировать на другую машину и посмотреть там. Единственный способ который реаль помог это создание роли SYSDBA.

← →
Alexandr (2003-06-17 10:26) [14]

если базу можно скопировать с сервера, то виноват не сервер БД, а операционная система, админ, директор...

Отсюда мораль: Не в ту конфу попал ты. тебе про администрирование виндов конфу надо.

← →
gep (2003-06-17 10:30) [15]

Вообще я базами почти не занимаюсь. Но интересуюсь - в связи с этим вопрос - пороли пользователей базы храняться не в самой базе 8-(

← →
Zacho (2003-06-17 10:36) [16]

> gep (17.06.03 10:30)

Пользователи и пароли хранятся в "системной" БД isc4.gdb
Так что если есть возможность подменить isc4.gdb или скопировать файл БД - то можно и получить к БД доступ SYSDBA

← →
Romkin (2003-06-17 11:06) [17]

Можно еще прошивать контрольную сумму записи в дополнительное поле, или шифровать все важные данные

← →
Borman (2003-06-17 11:27) [18]

Единственный вариант в этом случае завести в сетке комп к которому не было бы доступа у этого аДМИНА, установить на него IB сервер и положить базу. Весь замут в том, что для коннекта к базе необязательно расшаривать диск, к ней можно обращаться примерно так (если пользуеш стандартные компоненты) Server: IP компа, Protocol: TCP, Database: [путь к базе относительно компа где лежит база]. Единственный вариант сломать это дело это либо получить доступ к компу или править базу запросами по сетке.

← →
Borman (2003-06-17 11:28) [19]

Единственный вариант в этом случае завести в сетке комп к которому не было бы доступа у этого аДМИНА, установить на него IB сервер и положить базу. Весь замут в том, что для коннекта к базе необязательно расшаривать диск, к ней можно обращаться примерно так: Server: IP компа, Protocol: TCP, Database: [путь к базе относительно компа где лежит база]. Единственный вариант сломать это дело это либо получить доступ к компу или править базу запросами по сетке.

← →
stone (2003-06-17 11:34) [20]

> или править базу запросами по сетке.

Если есть такая возможность, то любое запрещение физического доступа к базе бессмысленно.

ИМХО, наиболее оптимальный вариант предложил Romkin © (17.06.03 11:06)

← →
Карелин Артем (2003-06-17 11:38) [21]

Значит так: тебя ничего не спасет, если врагу будет известно имя пользователя, под которым ты работаешь с базой.
Чтобы как-то скрыть сделай следующее:
1) Сделай базу используя свою учетную запись (не SYSDBA).
2) Сделай в базе роль SYSDBA.
3) Закрой доступ к всем таблицам для PUBLIC. Пусть только твой аккаунт будет иметь права к таблицам.
4) При всем этом доступ будет закрыть только пользователю SYSDBA. При подключении к базе под другим аккаунтом FireBird 908 сборки (под другими не проверял) добавит записи в таблицу RDB$USER_PRIVILEGES. Если повесить на добавление записей в таблицу некие злобные триггеры, то можно отловить вход под чужым аккаунтом. Удалить или изменить триггер уже не получится.
5) Надо будет очень хорошо подумать над isc4.gdb. Тут уже до меня часть мыслей высказали.
6) При всем этом я запросто могу вытащить имя пользователя из экзешника (шифр может не спасти от меня) и получить полный доступ к базе. Твой пароль при этом не нужен!

← →
Anatoly Podgoretsky (2003-06-17 11:40) [22]

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

← →
Карелин Артем (2003-06-17 11:51) [23]

http://www.volny.cz/iprenosil/interbase/ip_ib_isc4.htm#_ibisc4_hide

← →
Borman (2003-06-17 11:54) [24]

> запрещение физического доступа к базе

На сколько я понял, речь идет о том, что базу уносят с компа, а потом приносят!

← →
Borman (2003-06-17 12:03) [25]

> http://www.volny.cz/iprenosil/interbase/ip_ib_isc4.htm#_ibisc4_hide

Проблема в том что isc4.gdb на каждом компе своя и SYSDBA с masterkey могут на одном компе неработать, а на другом дать полный доступ это дырка IB сервера! В база.gdb хранятся только данные и описание таблиц и прочей лабуды для хранения и обработки данных НО ТОЛЬКО НЕ ЗАЩИТЫ!

← →
Карелин Артем (2003-06-17 12:06) [26]

Borman (17.06.03 12:03)
Читай про роли sysdba и триггеры к системной таблице с правами.

← →
Borman (2003-06-17 12:17) [27]

> Sirus © (17.06.03 06:57)

Если ты бдиш за происходящим, стяни мыло, там юнит от компании Borland. Единственный косяк, что база будет в два раза больше зато ни кто и не что кроме твоей проги не врубится ;)

← →
NickBat (2003-06-17 12:19) [28]

К чему давать советы по администрированию БД если в организации нет обычного администрирования?

Как спасет наличие ролей от копирования файла БД на другой компьютер?

Человеку надо сначала физический доступ к базе убрать, не расшаривать файл БД, а уж затем думать (если проблема останется, в чем я сомневаюсь) над администрированием БД средствами Ибейс.

← →
Borman (2003-06-17 12:27) [29]

Администрирование в IB есть если базу не довать копировать

← →
Карелин Артем (2003-06-17 12:28) [30]

NickBat © (17.06.03 12:19)
>Как спасет наличие ролей от копирования файла БД на другой компьютер?
Это чисто конкретная роль, наличие которой не даст пользователю sysdba приконнектиться к базе. Читай внимательнее.

Borman (17.06.03 12:03)
А подменить своей слабо?

← →
Alexandr (2003-06-17 12:32) [31]

1) Что это за упомянутый юнит от Борланд?
2) Доступ к файлу БД решается средствами ОС.
3) Доступ к железу сервера решается охраной
4) Доступ к СУБД решается средствами СУБД вполне нормально.

в каком месте утечка идет? Что вы там подменять хотите?
настроить просто все надо нормально.
И месячной суммы краж на хватит сполна.

← →
АлексейК (2003-06-17 12:38) [32]

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

← →
Alexandr (2003-06-17 12:48) [33]

> то можно составить отчет приложить распечатки и на стол
> начальнику

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

← →
АлексейК (2003-06-17 13:09) [34]

>Alexandr ©
Кому тогда это все надо? Если только одному программисту, тогда его начальник может и под зад пинком, что бы не мешался.

← →
NickBat (2003-06-17 14:00) [35]

> Карелин Артем © (17.06.03 12:28)
> Читай внимательнее.
Так и ты читай внимательнее. :)))
С тобой-то я согласен, просто в том бардаке, который описывает автор ветки, роли ему точно не помогут.

← →
Карелин Артем (2003-06-17 14:25) [36]

NickBat © (17.06.03 14:00)
Факт. Кстати комплексом мер можно защитить и "унесенную" базу, но долго это. Тут требуется еще и модификация клиента, потому как в нем есть дырка.
Хотя умельца это не остановит :(

← →
Soft (2003-06-17 14:50) [37]

Sybase ASA поможет, в самой базе хранятся пользователи права и пароли. Если ее унести, то все равно пароль в ней. Только она "официально" не бесплатная.

← →
petr_v_a (2003-06-17 14:56) [38]

А в Вашей организации еще админы не нужны? Умею NT администрировать, базы... :)

← →
Anatoly Podgoretsky (2003-06-17 15:06) [39]

Ну вот еще, за одним то уследить не могут.

← →
Danilka (2003-06-17 15:09) [40]

← →
Anatoly Podgoretsky (2003-06-17 16:06) [41]

Дык 100 000 придется на двоих делить

← →
nikkie (2003-06-17 17:13) [42]

>Дык 100 000 придется на двоих делить
нее... это сейчас 100000 делится на неизвестное количество юзеров. а при грамотном администрировании можно ни с кем не делиться. а чтобы начальство довольно было - можно даже сократить потери. райское место :)

а не эта ли цель стоит за самим вопросом? :)))

← →
Nerpa (2003-06-17 21:54) [43]

У меня был похожий случай.
В базе меняли поля записей или удаляли целые записи.
Что сделал:
1. Контрольная сумма записи. Посчитай, пошифруй.
При загрузке программы - сканируй записи и сверяй контрольную сумму.
2. Делать скрытый лог того, что записываешь в базу.
При загрузке сверяй есть ли записи в базе и логе.
Лог, естественно, прячь и шифруй (я делал 3 копии лога)
3. Если что, печатай себе отчёт (что было на самом дела и во что умники переделали) и прямо типа к директору, т.е.
к чуваку, который может всех уволить.

Результат: После первого такого случая (был представлен отчёт реальный и фактический) были уволены охраник и сисадмин.
История закончилась.

← →
KDS (2003-06-18 15:19) [44]

Перенесите ФБ и базу на Линукс машину.
Там логи красиво ведуться + производительность выше.
Чайники в Линух не полезут. :-))

← →
Wizard_Ex (2003-06-18 16:37) [45]

А что мешает запретить доступ на уровне ОС?
Сервер NT, а лучше 2000
завести юзера справами администратора (для себя)
и ограничить доступ к папке/файлу базы
вернее запретить доступ, запретить изменение прав, запретить чтение каталога, запретить чтение файлов, запись файлов в общем все запретить пользователям Everyone, Администратору и т.д..
Плюс к этому нужно быть владельцем этого каталога/файла
Разрешить/дать все права System, Services и себе конечно.
В итоге любые юзеры с файлом сделать ничего не смогут,
администратор тоже, а Interbase - это сервис, а ему мы разрешили доступ, и еще системе.
Должно сработать. Сам не пробовал

← →
Wizard_Ex (2003-06-18 16:46) [46]

Удалено модератором

← →
Zacho (2003-06-18 18:06) [47]

> Wizard_Ex © (18.06.03 16:46)
> Второй вариант:
> набить еб-ник админу и выгнать на...

И то же самое сделать с начальником, который допустил такой бардак.

← →
Soft (2003-06-18 18:21) [48]

А Oracle Lite не поможет разве. Он бесплатный.

← →
Sirus (2003-06-19 13:08) [49]

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

← →
NickBat (2003-06-19 13:13) [50]

> проблемка решена написанием маленькой проги, которая попросту форматирует все
Интересное решение проблемы! Не боитесь что-нибудь не то отформатировать? И что значит "незнакомые" диски. С кем не знакомые? Насколько диск должен быть "знакомым" чтобы выжить?

← →
Soft (2003-06-19 13:43) [51]

http://www.dca.narod.ru/

Там есть фришные програмки защиты(чтения, записи, форматирования...) дисков с исходниками на асме.

← →
Anatoly Podgoretsky (2003-06-19 13:53) [52]

Прощай база и сервер, долгая память.

← →
Sirus (2003-06-19 13:55) [53]

Прога периодически проверяет серийные номера дисков и наличие определенного файла на диске. Если номер незнаком или файл отсутствует или файл не тот который нужен то за проверкой следует форматирование...

← →
stone (2003-06-19 14:00) [54]

> Sirus © (19.06.03 13:55)

> Прога периодически проверяет серийные номера дисков

Если материнка имеет встроенный RAID, получить серийный номер диска, подключенного к RAID не всегда удается. ИМХО, защиты хуже просто не придумаешь. Да и какой в ней смысл? Копируют, как я понял, базу (*.gdb), а не какие-то программы.

← →
Danilka (2003-06-19 14:19) [55]

ну, блин, и защита :))

если с админом теперь все ок, то достаточно на сервере сделать доступ к файлу БД только фиребирду, а остальным нефиг доступ даже на чтение. вот и вся защита.

Как защитить базу??? Найти похожие ветки