Отправлено: 09.01.07 18:55. Заголовок: Как сделать чтоб базы не читались одинаковыми программами

Доброго времени суток всем.
Исходные данные:
Есть однотипная задача на несколько фирм. Соответственно у всех структура dbf одинакова.
Вопрос:
Как сделать чтоб базы одной программы при переносе в другую фирму не читались ?
А то можно скопировать базы в одной конторе приносишь в другую, а там какой-нибудь программер просто скопирует в подобную и вот весь приход-расход чужой фирмы видит.

Интересно а как в БЭСТе и у 1С предусматривается такая защита ?

 Отправлено: 09.01.07 20:14. Заголовок: Re:

Как вариант можно зашивать в EXE какой то специфический код , уникальный для конкретной фирмы..........думаю дальше все ясно.......
Или же можно шифровать базы , а ключ шифрования хранить в EXE , специфический для каждой фирмы.

ЗЫ
А вообще таких утечек быть не должно , это уже попахивает "промышленным шпионажем"......

 Отправлено: 10.01.07 01:54. Заголовок: Re:

Вопрос не стоит о хранение спецкода, я его могу в ключ засунуть 1024 байт достаточно.
Вопрос стоит как ограничить доступ к DBF файлам, без шифрации, т.к. потом с ними нельзя будет работать.
Драйвер базы CDX.
Какие есть идеи ?

 Отправлено: 10.01.07 14:18. Заголовок: Re:

Andrey

цитата:

Вопрос стоит как ограничить доступ к DBF файлам, без шифрации, т.к. потом с ними нельзя будет работать.

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

Каков уровень сисадминов в тех конторах? Им дадут команду ковырять чужие базы или это они (возможно) будут делать из любопытства?
Обрисуй ситуацию.

 Отправлено: 10.01.07 20:55. Заголовок: Re:

Определяюсь. Мне нужно для своей проги ограничить доступ к DBF-основным. Т.к. основные базы - это база связанная с кучей справочников. Какое поле от чего зависит, (помоему) даже сам не разберешься спустя год без исходников, а тем более посторонний будет копать даже если дадут им команду. Я понимаю что можно все взломать и получить списки клинтуры... но за какие деньги ? Если просто так, помоему никто особо не захочет разбираться в чужих данных. Шифровать базы помоему нет смысла, так как какие связки и что от чего зависит подбирать никто не захочет.

Вопрос стоит просто. Есть типовая задача, работающая в разных фирмах. Настройки все одинаковы, справочники типовые (адреса Москвы и другие), за исключением клиентуры (т.е. это малая часть). Ведется несколько основных баз договоров, заявок, начислений, прихода. На каждую задачу стоит ключ HASP HL (хотя можно сделать шифрацию баз через него, у него встроенные средства, но потом сам замучаешься разбирать базу если полетит она)
Задача стоит так - каким образом, можно ограничить простую ситуацию.
Если в конторе 1 списываются базы и приносятся в контору 2 и временно переписываются базы по таким же путям, то как запретить работу моей программы с "чужой" (т.е. не своей) базой ?
Как определить что базы не те ?
Я могу держать для каждой фирмы "свою" метку в ключе. А как сделать "метку" для dbf-баз ?

 Отправлено: 11.01.07 01:30. Заголовок: Re:

Ну заведи поле в "критичных" файлах dbf для идентификации фирмы. И храни в переменных где-нибудь этот идентификатор, можно зашифрованный. У меня, например, для каждого рабочего места есть набор переменных для хранения хотя бы тех же путей доступа. Дальше понятно. Каждая фирма будет этот свой идентификатор заносить при создании записи и анализировать при открытии файла. Не совпал - в аут.

 Отправлено: 11.01.07 08:08. Заголовок: Re:

Это слишком просто.
Добавить поле в базу и ламер сможет.
Нужно что-нибудь посерьезней.

 Отправлено: 11.01.07 08:22. Заголовок: Re:

Так это поле и шифруй. Для расшифровки нужно еще ключик иметь. И ключик этот нужно "спрятать" где-то там, где никто его искать не будет, т.е. не в твоем блоке программ и данных. Где-нибудь в С:\WINDOWS\system32, например.
Других вариантов я просто не вижу. Шифровать просто программой? А кто мешает "не ламеру" вместе с данными унести и программу?
Тогда нужна либо привязка программы к компьютеру, что наверное проблематичней, либо где-то ключик держать в потайном месте.

 Отправлено: 11.01.07 14:13. Заголовок: Re:

Мне кажется это вообще пустая затея! Любой желающий может просто с помощью DBU посмотреть те DBF-файлы, которые его интересуют. И даже вообще можно обойтись без DBU. Было бы желание!
Я вижу такой способ. Иметь где-то на диске хорошо запрятанный файл инициализации. Программа в начале работы проверяет существование этого файла именно там, где он прописан, проверяет его содержимое, в котором, допустим, указывается, где находится база данных. И лишь имея эту информацию, обращается к базе данных. Вот содержимое именно этого одного файла можно зашифровать. Сделать его двоичным, а не текстовым, каким является по существу DBF-файлы.

 Отправлено: 11.01.07 14:26. Заголовок: Re:

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

 Отправлено: 12.01.07 20:17. Заголовок: Re:

Григорий, нельзя прятать файл инициализации, так как задача может эксплуатироваться в других городах, куда сам не поедешь.
Есть лучшее решение ключ HASP HL в который можно засунуть все и даже с его помощью шифровать данные.
Только очень не хочется шифровать свои базы.
И тогда не нужен BIOS машины. А файл инициализации не нужно прятать, его можно всегда определить при запуске программы различными утилитами.

 Отправлено: 15.01.07 14:29. Заголовок: Re:

dbf надо шифровать (м.б., не все, а только критические). По-другому - детский сад.
Опасения на тему "а вдруг всё посыпется, как тогда собирать ?", имхо, лишены основания, если делать нормальный backup, при котором каждая копия критически важных dbf-файлов создаётся в НОВОМ каталоге, например, отражающем текущий день недели и внутри -- папка, отражающая часы-минуты. Таким образом, будет возможен откат на 7 дней тому назад с поиском "необсыпавшихся" данных.
Да и сыплются, по моей практике, не сами .dbf-ники, а индексы (иногда, правда, могут и memo-файлы). Если же поставить АДС и запитать сервак на нормальную UPS'у, то этот вопрос вообще можно забыть.

 Отправлено: 14.02.07 16:19. Заголовок: Re:

Вариант один - и он реализован у меня в программе -
Мы строим справочники по обычной схеме :
INDEX ON UPPER(TYPE) TO ...
вместо UPPER(TYPE) делаем QCTYPT(TYPE,SEC_CODE) : Тоесть функция криптования с определенным кодом
А когда просматриваем в TBROWSE - декрипт по такому-же алгоритму только с учетом SEC_CODE .

Фактически в БАЗУ мы должны записывать УЖЕ ШИФРОВАННЫЕ (Тоесть неразборчивые для прочтения умом) ДАННЫЕ . Индексация и ПРСМОТР самой программой - с использованием внутренних крипт/декрипт функций с параметрами . вроде и база есть - но АБРАКАДАБРА в ней .!

 Отправлено: 14.02.07 20:30. Заголовок: INDEX ON QCTYPT(TYPE,SEC_CODE) TO ...

Вопрос: шифруются ли поля, отвечающие за сортировку при просмотре в TBROWSE ?
Если "АБРАКАДАБРА" в базе и в файле индекса - то сортировка - по значению "АБРАКАДАБРы " ?

 Отправлено: 15.02.07 13:20. Заголовок: Re:

еще вариант:

0) допустим имеем: сеть на N машин, расшаренная база (пусть будет \\serv\data) с DBF и индексами к ним.

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

2) в сети есть одна (доверенная) машина (назовем ее "сторожем"), на локальном диске которой хранятся ключевые справочники и которая "следит" за рабочим каталогом \\serv\data. Как только от клиента появляется файл-запрос, проверяет его валидность, анализирует его и выполняет простейшие действия (выдать ключевой справочник, внести в него изменения и тп) Обмен между "сторожем" и клиентом можно криптовать ключом клиента - чтобы не было возможности в расшаренной базе "подцепить" чужую копию ключевых данных. Клиент после оформления запроса дожидается ответа от сторожа и копирует/расшифроввывает ключевой справочник себе на локальный диск.

3) т.о. без ключевого справочника(-ов) смысла база не имеет: допустим, контрагент 253 с контрагентом 4156 произвели операцию 004 на 15 единиц товара 1566 по цене 10,56 единиц валюты 002. А дальше - тупик.

4) процесс запроса/получения/криптования справочников можно "завернуть" в обертку одной-двух процедур, чтобы не переделывать весь код в программе. Админу - настроить либо круглосуточную работу "сторожа", либо его утренний запуск раньше всех. Можно гибко выбирать варианты "секьюрности" - сколько данных хранить расшаренными, сколько "прятать", в зависимости от запросов начальства. Обязательно предусмотреть бэкап обоих частей БД.

5) в качестве "командного языка" для сторожа можно использовать что-нибудь типа SQL (если есть свои наработки или библиотеки) или макро-язык Clipper в чистоми виде.

----------
Идея моя, пока теоретическая, решается программным способом - на чистом Клиппере без привлечения сторонних средств.

 Отправлено: 15.02.07 13:59. Заголовок: Re:

Сложновато ....
Вот немножко моего кода :

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

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

 Отправлено: 15.02.07 15:40. Заголовок: Re:

Вообще то идея классная. И реализовывать несложно и для чужих "геморой".
Только заместо CHARXOR() есть в Клипере CRYPT() с такими же параметрами.

----------------------------------------------------
Коллективный разум победить невозможно.

 Отправлено: 15.02.07 15:44. Заголовок: Re:

Причем я этот принцип увидел на НАСТОЯЩИХ ФИРМЕННЫХ ПРОГРАММАХ (БАЗЫ ДАННЫХ ПО АВТОЗАПЧАСТЯМ) .... смотрю - DBF - вот думаю - себе внедрю ! А влез в просмотр - понял что ЗАДНИЦА !

 Отправлено: 15.02.07 17:04. Заголовок: Re:

Шифровать поля в расшаренной таблице предлагалось в самом начале дискуссии.
Нужно решить вопрос как хранить/менять ключи шифрования. Если они будут "зашиты" внутрь EXE - то какой в этом смысл применительно к топику ?

 Отправлено: 15.02.07 20:05. Заголовок: Re:

Sergy пишет:

цитата:

Нужно решить вопрос как хранить/менять ключи шифрования.

Естественно не в EXE, а с помощью ключей типа HASP (стоимость простого ключа - 470 руб.)
или если нет желания связываться с ними то можно как советовал Филатов, через BIOS и другие прибамбахи.

 Отправлено: 16.02.07 09:59. Заголовок: Re:

цитата:

Естественно не в EXE, а с помощью ключей типа HASP (стоимость простого ключа - 470 руб.) или если нет желания связываться с ними то можно как советовал Филатов, через BIOS и другие прибамбахи.

цитата:

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

Тогда если у каждого юзера будет свой HASP/ключ - чего шифровать будем - у каждого будет своя АБРАКАДАБРА ?

А если этот HASP/ключ воткнут в сервер и расшарен - какой смысл в этой защите, если данные можно скопировать локально, расшифровав их "находу" при помощи доступного всем в сети ключа ?

Хотя, если ты уже "нащупал" подходящее для себя решение - оки, не буду приставать.