Форум » Clipper » Как сделать чтоб базы не читались одинаковыми программами » Ответить
Как сделать чтоб базы не читались одинаковыми программами
Andrey: Доброго времени суток всем. Исходные данные: Есть однотипная задача на несколько фирм. Соответственно у всех структура dbf одинакова. Вопрос: Как сделать чтоб базы одной программы при переносе в другую фирму не читались ? А то можно скопировать базы в одной конторе приносишь в другую, а там какой-нибудь программер просто скопирует в подобную и вот весь приход-расход чужой фирмы видит. Интересно а как в БЭСТе и у 1С предусматривается такая защита ?
Ответов - 25, стр:
1 2 All
Dima: Как вариант можно зашивать в EXE какой то специфический код , уникальный для конкретной фирмы..........думаю дальше все ясно....... Или же можно шифровать базы , а ключ шифрования хранить в EXE , специфический для каждой фирмы. ЗЫ А вообще таких утечек быть не должно , это уже попахивает "промышленным шпионажем"......
Andrey: Вопрос не стоит о хранение спецкода, я его могу в ключ засунуть 1024 байт достаточно. Вопрос стоит как ограничить доступ к DBF файлам, без шифрации, т.к. потом с ними нельзя будет работать. Драйвер базы CDX. Какие есть идеи ?
Sergy: Andrey Вопрос стоит как ограничить доступ к DBF файлам, без шифрации, т.к. потом с ними нельзя будет работать. Если нужна помощь - определись, что тебе нужно: ограничить доступ к DBF без шифрации невозможно - на то они и DBF... другой вопрос: что и как шифровать - доступ к исходникам программы есть ? вовсе не обязательно шифровать все подряд, достаточно обойтись ключевыми справочниками: клиенты, артикулы товара, системные настройки... Каков уровень сисадминов в тех конторах? Им дадут команду ковырять чужие базы или это они (возможно) будут делать из любопытства? Обрисуй ситуацию.
Andrey: Определяюсь. Мне нужно для своей проги ограничить доступ к DBF-основным. Т.к. основные базы - это база связанная с кучей справочников. Какое поле от чего зависит, (помоему) даже сам не разберешься спустя год без исходников, а тем более посторонний будет копать даже если дадут им команду. Я понимаю что можно все взломать и получить списки клинтуры... но за какие деньги ? Если просто так, помоему никто особо не захочет разбираться в чужих данных. Шифровать базы помоему нет смысла, так как какие связки и что от чего зависит подбирать никто не захочет. Вопрос стоит просто. Есть типовая задача, работающая в разных фирмах. Настройки все одинаковы, справочники типовые (адреса Москвы и другие), за исключением клиентуры (т.е. это малая часть). Ведется несколько основных баз договоров, заявок, начислений, прихода. На каждую задачу стоит ключ HASP HL (хотя можно сделать шифрацию баз через него, у него встроенные средства, но потом сам замучаешься разбирать базу если полетит она) Задача стоит так - каким образом, можно ограничить простую ситуацию. Если в конторе 1 списываются базы и приносятся в контору 2 и временно переписываются базы по таким же путям, то как запретить работу моей программы с "чужой" (т.е. не своей) базой ? Как определить что базы не те ? Я могу держать для каждой фирмы "свою" метку в ключе. А как сделать "метку" для dbf-баз ?
MikeP: Ну заведи поле в "критичных" файлах dbf для идентификации фирмы. И храни в переменных где-нибудь этот идентификатор, можно зашифрованный. У меня, например, для каждого рабочего места есть набор переменных для хранения хотя бы тех же путей доступа. Дальше понятно. Каждая фирма будет этот свой идентификатор заносить при создании записи и анализировать при открытии файла. Не совпал - в аут.
Andrey: Это слишком просто. Добавить поле в базу и ламер сможет. Нужно что-нибудь посерьезней.
MikeP: Так это поле и шифруй. Для расшифровки нужно еще ключик иметь. И ключик этот нужно "спрятать" где-то там, где никто его искать не будет, т.е. не в твоем блоке программ и данных. Где-нибудь в С:\WINDOWS\system32, например. Других вариантов я просто не вижу. Шифровать просто программой? А кто мешает "не ламеру" вместе с данными унести и программу? Тогда нужна либо привязка программы к компьютеру, что наверное проблематичней, либо где-то ключик держать в потайном месте.
Григорьев Владимир: Мне кажется это вообще пустая затея! Любой желающий может просто с помощью DBU посмотреть те DBF-файлы, которые его интересуют. И даже вообще можно обойтись без DBU. Было бы желание! Я вижу такой способ. Иметь где-то на диске хорошо запрятанный файл инициализации. Программа в начале работы проверяет существование этого файла именно там, где он прописан, проверяет его содержимое, в котором, допустим, указывается, где находится база данных. И лишь имея эту информацию, обращается к базе данных. Вот содержимое именно этого одного файла можно зашифровать. Сделать его двоичным, а не текстовым, каким является по существу DBF-файлы.
Григорьев Владимир: Есть конечно возможность перенести "сворованную" базу в тот же самый директорий, в котором находится "законная" база данных. Поэтому в секретном файле помимо пропсики пути к базе данных хранить еще, например, название организации. А ключ к шифоровке этого секретного файла строить на основе особенностей машины, например, по тексту из BIOS, который описывает марку (то есть производителя BIOS) BIOS.
Andrey: Григорий, нельзя прятать файл инициализации, так как задача может эксплуатироваться в других городах, куда сам не поедешь. Есть лучшее решение ключ HASP HL в который можно засунуть все и даже с его помощью шифровать данные. Только очень не хочется шифровать свои базы. И тогда не нужен BIOS машины. А файл инициализации не нужно прятать, его можно всегда определить при запуске программы различными утилитами.
p519446: dbf надо шифровать (м.б., не все, а только критические). По-другому - детский сад. Опасения на тему "а вдруг всё посыпется, как тогда собирать ?", имхо, лишены основания, если делать нормальный backup, при котором каждая копия критически важных dbf-файлов создаётся в НОВОМ каталоге, например, отражающем текущий день недели и внутри -- папка, отражающая часы-минуты. Таким образом, будет возможен откат на 7 дней тому назад с поиском "необсыпавшихся" данных. Да и сыплются, по моей практике, не сами .dbf-ники, а индексы (иногда, правда, могут и memo-файлы). Если же поставить АДС и запитать сервак на нормальную UPS'у, то этот вопрос вообще можно забыть.
Soflog86: Вариант один - и он реализован у меня в программе - Мы строим справочники по обычной схеме : INDEX ON UPPER(TYPE) TO ... вместо UPPER(TYPE) делаем QCTYPT(TYPE,SEC_CODE) : Тоесть функция криптования с определенным кодом А когда просматриваем в TBROWSE - декрипт по такому-же алгоритму только с учетом SEC_CODE . Фактически в БАЗУ мы должны записывать УЖЕ ШИФРОВАННЫЕ (Тоесть неразборчивые для прочтения умом) ДАННЫЕ . Индексация и ПРСМОТР самой программой - с использованием внутренних крипт/декрипт функций с параметрами . вроде и база есть - но АБРАКАДАБРА в ней .!
petr: Вопрос: шифруются ли поля, отвечающие за сортировку при просмотре в TBROWSE ? Если "АБРАКАДАБРА" в базе и в файле индекса - то сортировка - по значению "АБРАКАДАБРы " ?
Sergy: еще вариант: 0) допустим имеем: сеть на N машин, расшаренная база (пусть будет \\serv\data) с DBF и индексами к ним. 1) ключевого справочника (артикулы товара, коды операций, юзеры, клиенты и тп) не должно быть в расшаренной базе. Его получают через выделенную машину, к которой обращаются посредством файла-запроса в \\serv\data 2) в сети есть одна (доверенная) машина (назовем ее "сторожем"), на локальном диске которой хранятся ключевые справочники и которая "следит" за рабочим каталогом \\serv\data. Как только от клиента появляется файл-запрос, проверяет его валидность, анализирует его и выполняет простейшие действия (выдать ключевой справочник, внести в него изменения и тп) Обмен между "сторожем" и клиентом можно криптовать ключом клиента - чтобы не было возможности в расшаренной базе "подцепить" чужую копию ключевых данных. Клиент после оформления запроса дожидается ответа от сторожа и копирует/расшифроввывает ключевой справочник себе на локальный диск. 3) т.о. без ключевого справочника(-ов) смысла база не имеет: допустим, контрагент 253 с контрагентом 4156 произвели операцию 004 на 15 единиц товара 1566 по цене 10,56 единиц валюты 002. А дальше - тупик. 4) процесс запроса/получения/криптования справочников можно "завернуть" в обертку одной-двух процедур, чтобы не переделывать весь код в программе. Админу - настроить либо круглосуточную работу "сторожа", либо его утренний запуск раньше всех. Можно гибко выбирать варианты "секьюрности" - сколько данных хранить расшаренными, сколько "прятать", в зависимости от запросов начальства. Обязательно предусмотреть бэкап обоих частей БД. 5) в качестве "командного языка" для сторожа можно использовать что-нибудь типа SQL (если есть свои наработки или библиотеки) или макро-язык Clipper в чистоми виде. ---------- Идея моя, пока теоретическая, решается программным способом - на чистом Клиппере без привлечения сторонних средств.
Soflog86: Сложновато .... Вот немножко моего кода : Function QCRYPT(S1,P1) && Криптование строки S2:=CHARXOR(S1,P1) Return S2 А так мы открываем индекс , поле TYPE в базе уже зашифрованное - а в индексе в нормальном виде Не зная Password1 или путём подбора в индексе будет хрень всякая INDEX ON UPPER(QCRYPT(TYPE,Password1)) TAG TYPE TO (LAN+"SCROSS.CDX") Добавление записей в базу в зашифрованном виде: REPLACE TYPE WITH QCRYPT(NEW_DATA, Password1) По моему - проще некуда . Даже если украсть DBF и CDX то неудасться прочитать в другой программе c другим PASSWORD1 Я конечно использовал самый простой алгоритм кодирования данных ... можно любой другой ... Жду ваших комментов ....
Andrey: Вообще то идея классная. И реализовывать несложно и для чужих "геморой". Только заместо CHARXOR() есть в Клипере CRYPT() с такими же параметрами. ---------------------------------------------------- Коллективный разум победить невозможно.
Soflog86: Причем я этот принцип увидел на НАСТОЯЩИХ ФИРМЕННЫХ ПРОГРАММАХ (БАЗЫ ДАННЫХ ПО АВТОЗАПЧАСТЯМ) .... смотрю - DBF - вот думаю - себе внедрю ! А влез в просмотр - понял что ЗАДНИЦА !
Sergy: Шифровать поля в расшаренной таблице предлагалось в самом начале дискуссии. Нужно решить вопрос как хранить/менять ключи шифрования. Если они будут "зашиты" внутрь EXE - то какой в этом смысл применительно к топику ?
Andrey: Sergy пишет: Нужно решить вопрос как хранить/менять ключи шифрования. Естественно не в EXE, а с помощью ключей типа HASP (стоимость простого ключа - 470 руб.) или если нет желания связываться с ними то можно как советовал Филатов, через BIOS и другие прибамбахи.
Sergy: Естественно не в EXE, а с помощью ключей типа HASP (стоимость простого ключа - 470 руб.) или если нет желания связываться с ними то можно как советовал Филатов, через BIOS и другие прибамбахи. Есть лучшее решение ключ HASP HL в который можно засунуть все и даже с его помощью шифровать данные. Только очень не хочется шифровать свои базы. Тогда если у каждого юзера будет свой HASP/ключ - чего шифровать будем - у каждого будет своя АБРАКАДАБРА ? А если этот HASP/ключ воткнут в сервер и расшарен - какой смысл в этой защите, если данные можно скопировать локально, расшифровав их "находу" при помощи доступного всем в сети ключа ? Хотя, если ты уже "нащупал" подходящее для себя решение - оки, не буду приставать.
Soflog86: По поводу УНИКАЛЬНОГО КЛЮЧА для КАЖДОЙ РАБОЧЕЙ ГРУППЫ (тоесть доступ к ОДНОЙ БАЗЕ ДАННЫХ - т-е. группе файлов ) . Мой собственный подход - то как я сейчас защитил свой продукт ...) 1 . Нужно иметь ПРИВЯЗКУ EXE к компьютеру (либо где то хранить файл привязки НЕСКОЛЬКИХ КОМПОВ к EXE . Для этого нужно написать программу сбора данных о компьютерах , имеющих доступ к нашей БАЗЕ . Можно привязать к ОБЬЕМУ диска "С" либо к данным БИОСА - в общем уникальность компа можно вычислить любым способом - это мелочи ... 2 Полученные данные (с нескольких компов ) нужно записать в какое-то хранилище - но в таком виде чтоб эти данные можно было считать только нашей программой . Я использую простий - но достаточно эффективный на мой взгляд способ . Формирую HEAP-файл-("куча") - это просто ДАМП памяти - либо сгенерированный ХАОТИЧНО набор символов - для усложнения - где-нибудь 30КБ - в него будем записывать в ОПРЕДЕЛЕННЫЕ БАЙТЫ - значения ключей - тоесть можно по какому-то алгоритму . Желательно не подряд а например через байт через 50 байт - новый код и т д . Посимвольное сравнение HEAP-файла ничего ХАКЕРУ не даст - очень много будет расхождений- поэтому сказать где уникальные данные будет НЕВОЗМОЖНО - из 30КВ - 20КВ кардинально отличаются . Логика такова - при загрузке -EXE-шник dsxbckztn КОД_КОМПЬЮТЕРА , на котором запущен - данное значение ищем НА СЕВЕРЕ в HEAP-ФАЙЛЕ . используя алгоритм "выдёргивания по байтно, если нашли такой идентификатор - значит КОМПЬЮТЕР ПРАВИЛЬНЫЙ и РАЗРЕШЕН ДОСТУП . соответственно можно в HEAP-файл записать КОД для криптования БД - он тоже уникальный для КАЖДОГО ВАРИАНТА Б/Д. Какие плюсы ? 1 НЕТ СМЫСЛА КОПИРОВАТЬ EXE (они все-равно у всех одинаковы) 2 НЕТ СМЫСЛА КОПИРОВАТЬ HEAP-файл НЕ ЗНАЯ АЛГОРИТМА ЗАПИСИ И ЧТЕНИЯ КОДОВ . Подбор и сравнение содержимого 100% не даст информации о том ЧТО и ГДЕ записано Минусы : 1 При смене (добавлении компьютеров ) в сеть нужно будет ПРАВИТЬ (добавлять) данные в HEAP-файл 2 Нужна будет специальная программа (писть ручками) .... для ДОБЫЧИ ID-КОПЬЮТЕРА , ГЕНЕРАЦИИ HEAP-файла и записи в него ДАННЫХ . Ну и хранить её нужно будет как ЗЕНИЦУ-ОКО ! Ну ---кто - понял - молодец !
Andrey: Классно !!! А если у тебя задачи в других городах России и Зарубежья ? Как будешь выкручиваться ? А еще связь плохая и нет интернета ?
Soflog86: Нет ИНТЕРНЕТА ???? Ну извините - быстренько в Интернет-кафе . Да очень просто ! Клиенту я высылаю один EXEшник .... Его нужно запускать на КАЖДОМ компе, который предназначен для работы в сети . Он генерирует ID компа и шифрует в файл-пустышку .... Эти готовые файлы я получаю и выделяю из них ID . Затем генерирую им HEAP-файл (или изменяю данные на уже существующем) и отылаю назад .... Скажут - геморно - типа нужно каждого клиента так проработать .... ну ... дай Бог чтоб ОНИ БЫЛИ ПАЧКАМИ ... тогда уж напишу автоматизированную систему генерации и отсылки ....
Andrey: Проще ключ поставить, 470 рублей штука и не париться .....
Soflog86: Andrey - а можно для "не продвинутых" - пояснить с HASP ? Где что и как из Клиппера туда добраться
полная версия страницы