freepascal.ru

Пишу нечто вроде сервера БД под свой проект (пока правда собираю информацию, для того что бы изначально начать правильно писать проект). Пока остановился на варианте SQLite+Cipher+моя обертка для SQLite (Это и будет сервером). Есть 2 вопроса (или 1, если по первому есть стандартные решения).

1. Поясню выбор SQLite+Cipher, возможно, вы меня поправите в этом выборе:
Мне нужна БД для хранения информации. При этом данные не должны быть легко доступны и кроме того желательно скрыть саму структуру БД (обеспечивается Cipher-ом, поскольку в БД будут хранится в том числе и персональная информация), т.е. доступ к данным будет только из моего Сервера (можно было бы конечно изобрести свой формат БД, но ума наверное не хватит ), а уж он будет следить за пользователями (хранить их тоже в этой же БД буду, и поэтому еще хочу использовать Cipher). Может и изобретаю велосипед, но дело в том, что используемые в моем проекте компоненты помимо прочего должны быть лицензионно чистыми (вдруг я когда ни будь захочу продавать свою программу , если доведу ее до ума). Поэтому Cipher видимо придется собирать из исходников (в этом случае, насколько я понял, я могу использовать его в любых целях?), а SQLite я и так могу использовать в любых целях (поправте меня, если это не так).
2. Этот вопрос возникает, если всеже придется писать свой сервер, соответственно изобретать методы логина клиентов, "держания" сессий "залогинившихся" клиентов и др. Поскольку пока смотрю в сторону simpleipc (кроссплатформенность). Естественно буду шифровать передаваемую информацию.
И вовсем этом нужна кроссплатформенность (хотя бы Win+Lin).

Есть какие нибудь мысли по поводу?

Фууув.... Вроде ничего не забыл

Может чем-нибудь поможет: viewtopic.php?f=10&t=7133

Сам я этот проект пока (?) забросил. Изначальная задумка сильно трансформировалась и SQLite уже не устраивает, а дорабатывать просто интереса ради - нет времени. Если нужно, могу дать доступ к управлению кодом на Google Code.

Если буду делать так, как написано в первом посте - то обязательно поможет! Спасибо!
Просто думал может есть у кого какие мысли, как сделать попроще или может вообще саму логику пересмотреть? Может некоторые готовые решения уже есть? Самое главное наверное - не хочется свою БД писать - при больших объемах данных придется углубляться и в математику (вышку) и во многое другое... А мне оно надо?... Времени и так не хватает...

Скрыть структуру базы можно обфуксацией кода клиента и передачей через ssh , все это умеет , кажется встраиваемая версия mysql

и вам не надо ничего городить

http://dev.mysql.com/doc/refman/5.1/en/libmysqld.html

http://dev.mysql.com/doc/refman/5.5/en/ssl-options.html

Ism писал(а):Скрыть структуру базы можно обфуксацией кода клиента и передачей через ssh , все это умеет , кажется встраиваемая версия mysql

и вам не надо ничего городить

Встраиваемая версия не подходит... Нужна именно сетевая СУБД, будет несколько клиентов. Обфускация? Чем она поможет, если на сервере с бд элементарно открыть базу сторонними средствами, зная пароль админа, конечно. А его знать будут в случае с известными системами (кто-то же будет устанавливать сервер СУБД (MySQL или что либо другое - неважно). А так обфускацию по любому я бы использовал в своем сервере, чтобы усложнить взлом своей бд.
Вообще мне очень нравиться работать с MySQL, но по вышеназванным причинам он не подходит к сожалению.
В принципе можно было бы обойтись и шифрованием данных в таблицах, но тогда нужно забыть о инкрементном поиске...

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

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

Повторюсь

Можно было бы обойтись просто шифрованием данных в таблицах, но тогда можно забыть об инкрементном поиске. А так я бы с удовольствием работал с MySQL.
Хотя наверное, осмыслив и перечитав посты, придется отказаться от шифрования.....

Или смотреть в сторону веб-приложений...

Не пойму куда деваются мои сообщения пишу второй раз:

Все таки, по некоторым причинам в моей ситуации, буду писать свой сервер на основе SQLite. Спасибо Nik-у, за то что будет с чего начать. Пойду ковырять его исходники.

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

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

Есть какие нибудь мысли по поводу?
============
Делаю похожий проект. Именно SQlite3Cypher - для чего собрал из исходников обе (вынь- и линь-) версии. И диспетчер сетевого доступа к SQLITE тоже - потому что НЕ ИСКЛЮЧЕН удаленный режим. Ессно, если бы такой режим был не исключением, а нормой - то ессно бы выбрал готовый многоподльзовательский БД-сервер. Диспетчер не стал заморачиваться сам писать - Мартин для этих представил MSEgui IFI DB-bindings (использует SSL-каналы).

То есть вы хотите от клиентов скрыть структуру базы , с которой работают эти клиенты ? Это что , паранойя ?
================
Обычная защита от утаскивания (ремонтником, любопытным админом, сетевым хакером) файлов БД с дальнейшим их изучением - номера кредиток,,.

Не вижу логики, проще шифровать складываемые в базу данные любым способом и пусть кто хочет смотрит ее структуру, взлом бесполезен
================
Это спасет от просмотра и добавления "левых" записей , но не защитит от удаления имеющихся записей. Шифровать придется весь файл БД. Минус этого варианта - сбой одного байта в этом файле может сделать недступной всю БД. Хотя SQLITE3 в новом WAL-режиме завалить трудно, даже шифрованный - уменя получилось где-то с 10-го раза выдергивания сетевого 220 Вольт шнура в момент массовой вставки 10тыч записей.

OberonAR
На sourceforge.net есть уже готовая штука: DBNetProcessor. Как то, о чём Вы пишете: клиент-серверная технология, сервер БД от клиента скрыт. Есть демка с использованием именно SQLite. Для доступа к данным используются компоненты Zeos, так что выбор типа БД довольно широк. Сетевые компоненты для связи клиента и сервера - Synapse.
http://sourceforge.net/projects/laz-n-tier/files/

to: Vadim

А что у нее с лицензией? Я могу использовать ее в любых целях с указанием в окне about? Или как то по другому? Не хочется потратить время на нее, что бы потом выяснилось - я немогу ее использовать в своих целях...

OberonAR писал(а):Дело еще просто в идее нестандартного подхода, нестандартной бд и т.п. - это уже само по себе оч. сильно затрудняет безконтрольный доступ к данным

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

Я выше говорил про клиент банки. Так вот их проблема состоит в том, что во многих конторах (как минимум небольших) админы ставят системы типа RAdmin, LiteManager и т.п. Иногда ставят различные системы для протоколирования ввода с клавиатуры и т.п. Это все очень удобно для администрирования. Не нужно никуда бежать, все администрирование делается удаленно. Тем более часто админ выступает в роли консультанта юзеров по работе с компом.
Здесь все отлично, кроме того, что админ фактически имеет беспрепятственную возможность сделать себе копию банковской дискеты (флешки), знает логин и пароль доступа к банк-клиенту.
Воровать деньги не каждый будет. Но знаю случай, когда админ из-за конфликта с бухгалтером периодически повторял платежи. Создавалось впечатление, что бухгалтер тормоз, и по тупости делает одинаковые платежки несколько раз. Деньги не терялись, но гемора было много, приходилось рассылать письма с просьбой о возврате. В итоге уволили и бухгалтера и админа.

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