Здравствуйте!

Прошу вашей критики по поводу "придуманной", но еще не реализованной системы защиты от несанкционированного доступа к данным в... файл-серверной БД Access. Да-да-да... Тема неоднократно обсуждалась, да и, вобщем-то, на своей шкуре вся утопичность подобного рода занятий уже прочувстована, но тем не менее... эээ-э-э-э-э... Тем не менее есть задача реализовать защиту сетевой mdb по следующим направлениям:

ТЗ
1. Разграничение прав Пользователей на доступ и изменение информации (стандартные фишки по раздаче прав);
2. Ведение жесткого и надежного лога действий Пользователей (вошел-ушел; изменил, удалил, добавил и т.п.);
3. Исключить возможность изменения информации (как по предметной области учета, так и служебной, например логов действий Пользователей) минуя специально созданный интерфейс (фронт-сайд).
То есть, основной задачей является предотвращение несанкционированного (без попадания в лог информации о пользователе или, что еще хуже, под видом другого пользователя) изменения данных в БД.

Уже имеем:
- Стандартную "защиту" файлом Рабочих групп (была взломана "мышкой" посредством соотв.утилиты нечистоплотным сотрудником с целью заметания следов хищения тов.мат. ценностей).
- Ведение лога программыми средствами (из форм). Изменение важной информации "логируется" вплоть до сохранения старого значения (бывшего до изменения), не говоря уже "постановке на карандаш" пользователя, внесшего онное.

Дополнительные предполагаемые (выставленные для критики) действия:
1. Специально выделенный Сервер с физическим ограничением к нему доступа лиц, потенциально жаждущих наживы;
2. Для решения задач поставленных в ТЗ, на сервере постоянно "крутится" аля MDBSQLServer v0.1 (c) Exquisite :) Данное творение выполнено на базе mde. Его функции станут понятны из ниже приведенного текста.
3. На сервере находится MDB с данными (стандартное решение). Находиться файл может в двух местах: в "расшаренной" папке и в "нерасшаренной", локальной папке. Перенос файла(ов) с данными из папки в папку и, таким образом, псевдо-контроль за доступом к данным через сеть, производит MDBSQLServer. При запуске MDBSQLServer'а данные переносятся в расшаренную папку, при закрытии MDBSQLServer'а - в локальную, что исключает бесконтрольный (без присутствия запущенного MDBSQLServer'а) доступ к данным через сеть.
4. Запущенный (постоянно работающий) MDBSQLServer обеспечивает:
- копирование файлов данных в расшаренную папку;
- переодическое (думаю раз в неск. секунд) определение количества подключенных пользователей и количество "официально" сообщивших о подключении "Интерфейсов" (которые обязаны самостоятельно вести лог своих подключений/отключений и изменения данных). Данный Лог пишится Интерфейсами в серверную БД, из которой MDBSQLServer незамедлительно (раз в неск секунд) перекидывает (при этом удаляя из общей БД) данную информацию в специальную БД (или файл), расположенную в локальной папке сервера, что исключает самовольное редактирование хронологии подключений/изменений (лога) пользователями сети.
- Несанкционированное подключение через запущенный с шифтом Интерфейс или из собственной БД с линками будет вычислен MDBSQLServer'ом по отсутствию "официального" сообщения о подключении со стороны Интерфейса, при том, что количество подключений увиличилось. Реакция MDBSQLServer'а может быть разной... От насильственного отключения всех пользователей (предотвращая тем самым нелегальный доступ) до дозвона в 02 (или куда там еще можно позвонить:).
- при закрытии MDBSQLServer'а он переносит (сжимает, делает резервные копии, протирает монитор и т.п.) рабочий файл в локальную папку, что исключает сетевое подключение к рабочей БД без ведома MDBSQLServer'а.
5. Клиентские Интерфейсы - конечно mde, конечно защита от Шифта, конечно "прятание" окна БД (как стандартными средствами, так и, думаю, субклассированием, "отнимающим" у окошка все "вредоносные" сообщения). Программное сообщение о подключении формируется Интерфейсом в автоматически стартующей форме, при этом как само сообщение, так и ID Пользователя шифруются по нескольким собственным (читать: "нестандартным") алгоритмам, выдающим каждый раз (каждый день) различный итоговый "текст", т.е. вчерашнее сообщение и ID сегодня уже не будут восприняты MDBSQLServer'ом как корректные.

Вроде всё... Еще раз повторю, что это всего лишь не реализованная идея , перед воплощением которой хотелось бы убедиться в ее "полезности". Т.е. цель сего топика - определиться, способна ли подобная защита устоять перед... нет, конечно не перед Сергеем Гавриловым или Андреем Митиным (извиняюсь, если не назвал кого-либо, кто иногда или когда-то "баловались" взломом в познавательных целях;) ...перед продвинутыми пользователями, знающими как пользоваться интернетом, гуглом и умеющие читать файлы "РиадМи" к разным ломальным утилиткам.

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

Заранее огромное спасибо!
...хотя бы за то, что дочитали до сего места :)

-------------
З.Ы. Переход на SQLServer (с) MS - невозможен по религиозным соображениям.

З.Ы.2. В перечне "ТЗ" еще присутствовала и защита от "Утечки информации", но после довольно продолжительного общения с "заказчиком" (в кавычках от того, что денег за это не беру... так... удовольствия ради... типа хобби...:) о бренности подобных усилий в заявленных условиях (mdb) - пункт был удален.

Здравствуйте еще раз.

Спасибо проявившим внимание!
Увидел примерно то, что и сам бы написал на подобную тему, исходи она не от меня. Но... Но надо дополнительно защитить MDB (не обсуждается по условиям ТЗ) от несанкционированного изменения данных.

Итак...


для aleks2:
Не буду спорить, ибо переход на SQL-Server по не обсуждаемым здесь причинам ближайшее время (да и не ближайшее тоже, видимо) не планируется. Конечно, клиент-сервер при грамотном подходе решил бы все задачи ТЗ.


для makar:
>А если просто скопировать MDB к себе отредактировать и записать обратно на сервер.
Остается как минимум одно подключение - наш MDBSQLServer. В большинстве случаев копирование БД на место открытой (используемой) БД либо завершится сообщением об ошибке, либо "навернет" БД, либо, как заметил ЛП, тихо-мирно-незаметно скопирует. Но подмена рабочей БД может быть довольно просто (и надежно) решена с помощью MDBSQLServer. Правда, для реализации подобной проверки необходимо использование самописного алгоритма шифрования, что, вроде бы, легко ломается, но об этом еще речь впереди...
Т.е. эту "дыру" в защите данная схема решить может.


для ЛП:
Ну, во-первых, сразу извиняюсь за орфографические ошибки :) Во-вторых...
>Человек может... ...внимательно изучить, написать мудрый скрипт, который все что нужно исправит за 0.5 секунды, и этот скрипт запустить уже на работе.
Нда... Действительно может, хотя речь здесь уже идет не о "продвинутом юзере, умеющим пользоваться Гуглом", а о программизде, но, всё же, действительно "дыра"... ...которая, кажется, рашаема 256-ю подключениями :) Спасибо! //надо подумать...

>Уж лучше подними Terminal Server...
Не... При таком раскладе лучше переходить на клиент-серверные решения (что в моем случае даже не может быть рассмотрено), ибо весь проект придется кардинальнейшим образом переделывать.

Еще раз спасибо за "сразу 256 подключений".


для Victosha:
>Показаось, что это скрещение ежа с ужом.
Ну от чего же "показалось"? Все правильно увидели :)

>И желание "поработать с линкованными таблицами".
Не очень хорошо понял смысл сказанного... Разве при разделении mdb проектов на "хранилище" и "интерфейс" не приводит к "поработать с линкованными таблицами"? Хм...

>Кажется, пратать-выкладывать придумано для того, чтобы исключить возможность прямого доступа к данным в момент, когда не поднят "Сервер".
Именно так...

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

Тут скорее каналы-сокеты-DCOM или COM+ на ум приходит.
Не... Вот это действительно слишком э-э-ээ-э-э... слишком "не по детски", а мы ведь не профи :)

Спасибо за критику.


для Alexey Sh:
И Вам спасибо...


для N_A:
Я (пока) не разбираюсь в MDBSQLServer и может глупость напишу...
Эээээ-э-э-э-э... Нет уж, нет уж! Глупости здесь пишу я! //типа, место уже забито :)
"MDBSQLServer" - не более чем плод фантазии (пока), поэтому здесь НИКТО не разбирается в MDBSQLServer'е :)

...создав свой МДБ с примерно таким кодом я получу легальное подключение через которое выполню нелогируемые действия
Т.е. откроете "интерфейсный" mde, который сразу попытается приконнектиться к серверной БД и тут то "MDBSQLServer" поймает нас за руку. Хотя, еще открывается старт-ап форма, которая должна выполнить "легальное" подключение, но для легального подключения она попросит логин и пароль, которые проверит все тот же MDBSQLServer. Если вы дадите свой логин и пароль, то и не стоило так извращаться - добро пожаловать к данным через предоставленный вам Интерфейс :)
Или я чего-то не допонял?


для marvan:
- не составит труда подменить SQL запрос в вашем mde на "SELECT t1.* INTO copy IN 'D:\db0.mdb' FROM t1" (стандартная защита mde обходится)
Это позволит нам "украсть" информацию, что, вобщем-то, и не ставится целью "защитить" (ввиду ЯВНОЙ бессмысленности сего). Кстати, добраться до окошка БД (там, где видно эти самые запросы) еще надо умудриться, ведь оно защищено. Я не питаю иллюзий по поводу невозможности до него добраться, но еще раз повторю - это способ украсть инфу, но не измени...
хм... мля... типа: Открываем наш интерфейс с кнопочкой Шифт (снять сию защиту помог Гугл), добавляем собственный запрос на изменение данных, затем запускаемся в обычном, "кошарном" режиме, умудряемся добраться до окна БД, запускаем запрос... Есть над чем подумать... но не "с ходу"...
Спасибо!


для Geo:
Я, пользователь, Geo, имеющий разрешение...
Нда... Файл рабочих групп ломать мы умеем, но... Есть обход, но он опять же упирается в "самопальный" алгоритм шифрования... Спасибо за критику... //и надо подумать :)

Но уже есть "Изменение важной информации "логируется" вплоть до..."
Есть то, оно, есть, но на данный момент его можно обойти. И лог-таблицу на данный момент можно (с помощью Гугла и мыши) подправить... А "триггеры для бедных" просто-напросто не сработают, если приконнектиться к сетевой БД из своей собственной БД (понатыкав линков в чистую базу). Эту "дырку" и призван закрыть "MDBSQLServer" - предотвратить (или максимально осложнить) подключения к сетевой БД в обход Интерфейса.

З.Ы. И тебе привет! Очень рад не только "читать", но и общаться :) //ностальжи, аднака... (вытирая слезу:)

----------------------------

В общем, добавилось несколько хороших идей и несколько поводов для "подзадуматься"... Что и не примену сделать. Огромное всем спасибо!!!

Но вот только... Если можно, то еще минутку внимания %)
Тут прозвучала мысль, что самопальные алгоритмы шифрования элементарно вскрываются... А откуда эта информация? Кто-нибудь реально пробовал вскрыть последовательность из 1024 байт, в которой за 7 (пока) "проходов" шифруется строчка из 16 символов? Нет, конечно я понимаю, что шифрование это вам не "MDBSQLServer", но какую сумму запросит хаккер и сколько времени потратит на дешифровку этих самых 16 символов по алгоритму, ломалку к которому в интернете не найдешь? Методом перебора? %) Единственный вариант вскрытия подобного шифрования, ИМХО, это пошаговое выполнение шифрующей функции. Но ведь и мы не дураки, можем и "петельки" делать, и ложные ходы, и дошифровывать в неких не вызываемых явно из кода процедурах... К чему я это... К тому, что чтобы лично меня заставить трассить машинные коды чей-то проги для выяснения алгоритма преобразования 1024 байт в 16 символов и обратно - даже не знаю что и сделать то надо :) Конечно, есть люди, которые и на это пойдут, но... но это не тот случай! В защищаемой БД нет государственных секретов :)

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

В любом случае огромное спасибо всем!

з.ы. Не радуйтесь... Я его (топик) может быть еще разок подниму :)

Забыл автоподпись...

Легких путей не ищу! Это слишком тяжело...

для Alexey Sh:
Спасибо еще раз...

для ЛП:
Контрольный не прокатил... Умная софтина умеет отличать файл "server.mdb" десяти(или N)секундной давности от файла на данный момент. Если после обрушения "server.mdb" умная софтина определила, что файл хотя бы "минутной давности", то делается предположение о попытке нелегального доступа. Остается всё тот же вариант со скриптом, который можно попытаться обойти полным блокированием подключений (с) ЛП.
Впрочем, умолкаю-умолкаю ))

для Shark (флэйм):
>Критиковать попытку самостоятельно сваять систему безопасности бессмысленно, так же как критиковать вечный двигатель.
Согласен... Так же, как критиковать во времена Икара саму мысль о том, что человек может летать с помощью искусственных крыльев или, к примеру, "посещать" космос. Что? Какой такой "космос"? :) //хотя про космос тогда уже знали...

>Много умных дяденек и тетенек долго трудились и наваяли кучу продуктов про это. Тебе просто надо взять готовое решение...
Много умных дяденек и тетенек долго трудились и наваяли много чего... Например, 1Сэ, Галактик, ПромФинБухУч и прочей срани... Так что? Программизды, которые не учавствовали в создании этих проектов и не используют (читать: "не ходят и не устанавливают эти готовые решения по клиентам") - дармоеды или мошенники, обдирающие бедных клиентов, навязывая им мысль, что готовых решений нет и надо всё писать с нуля, а значит дайте нам постоянную высокооплачиваемую работу?
Кстати, то, что Вы сейчас пишите (создаете) на работе (а я не знаю, что вы пишите) - уже написано до вас тысячи раз и именно в вашей предметной области (а я ее не знаю) и с функциональностью, надежностью и безопасностью (о которых в вашем случае я не имею никакого представления) превышающей создаваемую Вами! //не наезд...

>... и не парить голову себе, форумитам и заказчикам.
Парить голову себе - хорошо... Мне нравится парить себе голову "попытками программировать" ))) Хобби такое...
Парить голову форумитам... Хм... Ну, извиняюсь... Конечно, вопросы о том, "почему происходит ошибка Тайп мисматч при программной работе с рекордсетом после перехода на А2К" голову не парит... Все просто и легко... Думать не надо... Более того, могу сказать по секрету, что "парили" голову по данному топику совсем не много человек, которые реально критиковали, описывая возможные варианты "взлома", а не просто читали (если вообще читали или ДОчитали первый пост до конца) или высказывали ну никому абсолютно не нужное (ибо и так все это знают) мнение, что защита MDB - дело безнадежное. Я ЭТО ЗНАЮ! Но, всё же, рассматриваю возможность организовать ДОПОЛНИТЕЛЬНУЮ (для увеличения гемора взломщику и повышения шансов поймать его с поличным) и НЕСТАНДАРТНУЮ (с отсутствующей в инете ломалкой) защиту.
Парить голову заказчикам... Млин... Ну вот почему каждый уверен, что ничегошеньки не зная ни о "заказчике", ни о системе, которая в данный момент у него стоит, ни о "железе" и "софте", ни о сфере деятельности предприятия, ни о требованиях, предпочтениях и ограничениях, предъявляемых "заказчиком", ни о финансовых его возможностях, может просто взять да и сказать: "Да поставь ему Оракл с ОЛАПом на парочку и будет тебе счастье"... Ведь я же сказал, что ситуация уже была оценена на месте и было принято решение просто организовать ДОПОЛНИ... хм... повтор...

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


Действительно всё... Флеймить надоело...

Еще раз огромаднейшее спасибо тем, кто указал на возможные реальные способы взлома описанной схемы "защиты" НЕ ГОСУДАРСТВЕННОЙ ВАЖНОСТИ ИНФОРМАЦИИ от ПРОДВИНУТОГО ПОЛЬЗОВАТЕЛЯ , ёпть, УМЕЮЩЕГО ПОЛЬЗОВАТЬСЯ ГУГЛОМ .

На данный момент самой большой проблемой вижу "взлом" через изменение или создание собственных сохраненных запросов в "официальном" Интерфейсе.
Буду думать...

Всем спасибо! //Приятно было "посмеяться" :)

---------------
Нда... Опять "многовато получилось" (с) не помню чье //гы...