Comments 32
Термин «обфускация» не очень подходит к варианту, когда реальные данные заменяются случайными или псевдослучайными, в общем не зависящими от исходных.
«Обфускация базы MySQL» — таблицу users понятно, но всю базу зачем так крыжить?
Интересная тема для тех, кто в теме :-) И выйгрыш в скорости впечатляющий. Еще было бы не плохо primary key захэшировать, так чтобы имея данные из других таблиц тестовой базы, нельзя было бы достать персональные данные из продакшн. При этом конечно эту колонку придется обновить во всех связанных таблицах.
как раз 5 минут назад деперсонализировал свою базу, но она пока маленькая — скриптом на руби за 3 мин.
как вырастет и станет большой — думаю воспользуюсь вашим методом, только оберну его в ruby+faker
как вырастет и станет большой — думаю воспользуюсь вашим методом, только оберну его в ruby+faker
Так и не понял о чем статья. Про синтаксис запросов MySQL?
В чем интересность техники деперсонализации, разве можно еще как-то внести изменения в БД, если не использовать SQL? По-моему это самое очевидное и простое решение.
В чем интересность техники деперсонализации, разве можно еще как-то внести изменения в БД, если не использовать SQL? По-моему это самое очевидное и простое решение.
Техника в том, — наверное из статьи не видно, — что это делается одним оператором. При этом можно вставлять уникальные значения в определенный столбец или выбирать из списка значений. При этом к бд идет один оператор, а не десятки тысяч, или даже сотен…
Естественно, статья обращает внимание на пользу изучения редких конструкций, которые позволяют делать подобное. Это еще один способ, делать нетривиальные вещи простым способом.
Естественно, статья обращает внимание на пользу изучения редких конструкций, которые позволяют делать подобное. Это еще один способ, делать нетривиальные вещи простым способом.
Статья о том, что прежде чем задействовать арсенал свистелок на все случаи жизни, таки полезно ознакомиться с азами предметной области и таки решить тривиальную задачу тривиальным способом.
А то, что тривиальное решение преподносится как экстраординарное — да: c одной стороны умиляет, но с другой — заставляет недоумевать.
А то, что тривиальное решение преподносится как экстраординарное — да: c одной стороны умиляет, но с другой — заставляет недоумевать.
Статья, к сожалению, не вызывает ничего кроме улыбки. Ого автор узнал что одна SQL комманда, при отсутствии других внешних факторов, работает быстрее 1mln SQL комманд… круто :)
Любая деперсонализация — это набор SQL комманд. Лучше бы автор расписал, каким образом необходимо выставить параметры MySQL и сессионные настройки для того, чтобы подобные комманды создавали манимальные нагрузки на дисковую подсистему, CPU, какие движки для таблиц лучше использовать при миграции данных, как ускорить индексацию данных, как быстро заливать ненужные но большие таблицы и т.д. а так статья, сугубо ИМХО, ниочем… я бы постыдился такое выкладывать
Любая деперсонализация — это набор SQL комманд. Лучше бы автор расписал, каким образом необходимо выставить параметры MySQL и сессионные настройки для того, чтобы подобные комманды создавали манимальные нагрузки на дисковую подсистему, CPU, какие движки для таблиц лучше использовать при миграции данных, как ускорить индексацию данных, как быстро заливать ненужные но большие таблицы и т.д. а так статья, сугубо ИМХО, ниочем… я бы постыдился такое выкладывать
Не врублюсь, а зачем это, деперсонализировать бд?
Например, при переносе продакшн базы на тестовый сервер, чтобы можно было работать с реальными данными, но, во имя безопасности, без личных данных пользователей.
ФЗ-152 в действии
Из уважения к своему проекту, к своему работодателю, и самое главное — к пользователям.
По-моему автор хотел сказать следующее: «Смотрите, я освоил CASE!!»
sql-ex.ru/ вам в учении поможет.
Господи, у вас для деперсонализации скрипт БАЗУ ДЁРГАЕТ?!
Вы что, делаете копию базы (дамп-рестор), потом дрочите базу, и только потом еще один дамп чтоб получить деперсонализованную?!
Не проще ли деперсонализовать дамп?! Дамп-деперсонал — готов дамп, который можно влить куда-то или юзать разработчикам локально.
Вы там что курили?!
Вы что, делаете копию базы (дамп-рестор), потом дрочите базу, и только потом еще один дамп чтоб получить деперсонализованную?!
Не проще ли деперсонализовать дамп?! Дамп-деперсонал — готов дамп, который можно влить куда-то или юзать разработчикам локально.
Вы там что курили?!
Вы парсер SQL пишете, чтобы дамп прошуршать?
согл
быстрее и надежнее
и не всего SQL а только одного INSERT с определенной структурой
выйдет всего лишь одна регулярка
быстрее и надежнее
и не всего SQL а только одного INSERT с определенной структурой
выйдет всего лишь одна регулярка
А что там сложного?!
if(/^INSERT INTO `([^`]+)` VALUES/) {
/^([^(]+)/;
print $1;
$q = 0;
while(/[^()]++[(]((?:[^'()]*+(?:'(?:[^'\\]*+(?:(?:\\')++|(?:\\.)++)?+)*+')?)*+)[)]/g) {
$el = $1;
print( ($q++?",":"") . "(" );
$k=0;
while($el =~ /^((?:['](?:[^'\\]*+(?:[\\].)?)*+[']|[^',]++))/) {
$val = $1;
print( ($k++?",":"") . $val );
}
print ")";
}
print ";\n";
}Я думаю вы лукавите. Допишите сюда правила из статьи и ваш регексп будет больше sql-ного кода (который вдобавок можно править).
Кроме того деперсонализация может касаться связанных таблиц. В sql с этим проблем нет — подзапрос с select-ом — а как вы будете это решать с помощью регекса? Наверное он тоже в разы вырастет?
Мне интересно знать ваше мнение. Заранее, спасибо.
Кроме того деперсонализация может касаться связанных таблиц. В sql с этим проблем нет — подзапрос с select-ом — а как вы будете это решать с помощью регекса? Наверное он тоже в разы вырастет?
Мне интересно знать ваше мнение. Заранее, спасибо.
внути внутреннего цикла $val модифицируется в зависимости от таблички правил модификации — где для каждой таблицы задаётся ключ модификации. текущее поле есть — $k, я добавил еще выдёргивание имён полей в момент парзинга CREATE TABLE, таким образом, внутри цикла у меня есть имя таблицы, имя поля, значение поля, и значение ID записи.
на базе этих данных я и генерирую обфусцированное значение.
То есть модификация значения вообще не регулярка, а простой такой if:
$replace = $config->{$table}->{$field};
if(!$replace) {
$replace = autodetect_replace($field); // автоматическое конвертирование полей типа *name*, *email*, итд.
}
if($replace ==1) {
$val=randgen_name($table, $id, $field);
}
elif($replace ==1) {
$val=randgen_email($table, $id, $field);
}
…
Для исправления связанных таблиц есть три момента:
1. Нормализованная база не содержит дублирающихся элементов, а потому НЕТ необходимости обновлять каскадом — можно спокойно деперсоналить каждую конкретную таблицу независимо
2. Для исправления, например, ID, полей — легко строится односторонний хеш на базе id исходной таблицы и её имени — таким образом, мы легко можем поменять foreing key в других местах, так как мы знаем на какую таблицу и какой id ссылаемся без проблем
Единственная проблема, с которой я столкнулся — это использование рандомных данных на базе только id исходной таблицы не даёт должного раскидывания результатов если меняемая строка короткая. Поэтому для строк < 6 символов я увеличиваю строки до 8.
На наших базах (~300 метров в sql.bz2) конфликтов больше небыло.
И, в отличие от sql конструкции, править пачку ифов на перле проще, чем вложенные case/elt/самопальный rnd
на базе этих данных я и генерирую обфусцированное значение.
То есть модификация значения вообще не регулярка, а простой такой if:
$replace = $config->{$table}->{$field};
if(!$replace) {
$replace = autodetect_replace($field); // автоматическое конвертирование полей типа *name*, *email*, итд.
}
if($replace ==1) {
$val=randgen_name($table, $id, $field);
}
elif($replace ==1) {
$val=randgen_email($table, $id, $field);
}
…
Для исправления связанных таблиц есть три момента:
1. Нормализованная база не содержит дублирающихся элементов, а потому НЕТ необходимости обновлять каскадом — можно спокойно деперсоналить каждую конкретную таблицу независимо
2. Для исправления, например, ID, полей — легко строится односторонний хеш на базе id исходной таблицы и её имени — таким образом, мы легко можем поменять foreing key в других местах, так как мы знаем на какую таблицу и какой id ссылаемся без проблем
Единственная проблема, с которой я столкнулся — это использование рандомных данных на базе только id исходной таблицы не даёт должного раскидывания результатов если меняемая строка короткая. Поэтому для строк < 6 символов я увеличиваю строки до 8.
На наших базах (~300 метров в sql.bz2) конфликтов больше небыло.
И, в отличие от sql конструкции, править пачку ифов на перле проще, чем вложенные case/elt/самопальный rnd
а мне кажется, что деперсонализировать надо: /имя/фамилия/день рожд (год можно оставить)/tel/address
login/ passw — всем установить в user_id/12345
как правило это все хранится в одной тбл. Другие табл — это набор уже деперсонализированных данных цифр
ну по большому счету — есть скрипты генерации таких таблиц данных: генерим случайным образом таблицу users, с темеже идишниками, что и табл с основной бд.
или генерим влучайным образом все или почти все — если так боимся за безопастность данных. Я бы так и сделал.
login/ passw — всем установить в user_id/12345
как правило это все хранится в одной тбл. Другие табл — это набор уже деперсонализированных данных цифр
ну по большому счету — есть скрипты генерации таких таблиц данных: генерим случайным образом таблицу users, с темеже идишниками, что и табл с основной бд.
или генерим влучайным образом все или почти все — если так боимся за безопастность данных. Я бы так и сделал.
Sign up to leave a comment.
Деперсонализация базы MySQL. Интересная техника