|
Задавайте вопросы, мы ответим
Вы не зашли.
Можно ли создать MySQL сервер "токсичный" относительно несанкционированного копирования БД и его самого?
Сценарий: есть коммерческая (платная) клиент-серверная пара (MySQL сервер и клиентское приложение). Клиент коннектется через SSL. В случае перехвата ключей в памяти локального хоста, где крутится приложение - можно подключиться к серверу, скачать структуру БД, сами БД, понять какой версии сервер, его возможные настройки и развернуть бесплатный клон этой пары на другом железе.
Как сделать, так что бы этот клон работал с тихим случайным накоплением незначительных ошибок, которые через полгода приведут к искажению данных.
В руках имеем весь проект сходников клиентской части (т.е. можем внести в КЧасть любой дополнительный функционал), ну и сам MySQL сервер используем в простейшей Комьюнити версии.
Шифрование БД - всё таки нагружает сервер, особенно если там не один десяток изолированных контейнеров MySQL. А хорошее шифрование - хорошо нагружает..
Само шифрование - это следующий этап, но шифровать всё - не имеет смысла. Достаточно зашифровать некоторые таблицы.
Это не позволит сопоставить все данные относительно друг - друга, а частичные данные - не имеют большой ценности.
Ну и само шифрование, это не защита методом "социальной инженерии".
Был такой вот "подход" на заре IT цивилизации: для защиты микросхем с ультрофиолетовым стиранием, часть памяти писалась на пониженном напряжении и когда всю микруху считывали и копировали, то она оч "плохо себя вела", так как, там все части читались каждый раз одинаково, а алгоритм "ждал другого". Оно понятно, что можно поломать всё, это вопрос лишь времени и денег...
К серверу нет аппаратного доступа. Он у нас в "облаке VDS"- USB dongl keys или TPM - не поставишь..
Если, задача не решаема так, то решаемая ли она 100% на своём аппаратном сервере, куда можно воткнуть что-нибудь железное...
Неактивен
Мне кажется, нужно всё-таки уходить от MySQL торчащего наружу. Те сложности, которые мы в этом месте придумываем, будут сложны в реализации и при этом очень просто обходиться атакующим.
Единственное нормальное решение, которое я вижу, — делать API, через которое уже подключаться клиентом.
Ну и непосредственно по вопросу. Копирование данных работает по тому же протоколу, что и, собственно, доступ. Если у вас клиент в принципе может вытащить все данные, то и mysqldump сможет. В голову приходят какие-то такие усложнения, но опять же — все обходятся тривиально:
* Сделать какую-то хранимую процедуру, которая выдает нужные данные, но только в обмен на «секрет». Секрет можно посылать в открытом виде (легче узнать), можно в закрытом виде (aka подписанный timestamp) — узнать сложнее, но т.к. в приложении он есть, то тоже достается.
* Сделать какую-то таблицу, которая «не читается» — mysqldump на ней споткнется. Например, вот так:
Неактивен
Спасибо, за приговор.
Нужно было нам "не приходить" 20 лет назад к торчащему наружу MySQL, тогда бы и не искали сегодня такие глупые решения..
Перепись - дорогОво стоит.
Опять за старое..Если, я немного "отпрыгну в сторону", аки заяц:
MySQL есть в исходниках (есть же?) может быть не самые свежие версии, но вроде как должен быть.
И я изменю синтаксисы запросов (например SELECT) на некоторую случайную последовательность (suvy97htQW) и по-больше так знаков.
А потом скомпилирую сервер заново. Это, как-то испортит жись моим "партнёрам" в сети? Понятно, что клиентская часть тоже будет запрашивать и писать данные с новым систаксисом.
Один большой специалист сказал мягко, что "это не помещается в его голове", а почему не пояснил..
Неактивен
