Товарищи, что-то не вяжется. Вот сижу читаю статью:
http://www.oracle.com/global/ru/oramag/ … crypt.html
написаную вроде не глупым человеком (удостоенным наградой администратор года баз данных Oracle).

То что существует практика шифрования баз данных - это факт.
В каких случаях надо шифровать данные и как это делать в LAMP? - это хороший вопрос. И ответа на него я не знаю.

------------------
Продолжаю читать про Kerberos - очень интересно.
Так же думаю про:

diezel2005 писал(а):

мне нужны данные транзакций(попробуй их зашифруй).

Книжку тоже пойду куплю.

diezel2005 писал(а):

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

А что такое "инкрементальный", "разностный" и "полный" бэкап?

С инкрементальным бэкапом вроде разобрался. В MySQL есть Binary Log.
Что бы просмотреть запросы в Binary Log или выполнить его частично - можно воспользоваться утилитой mysqlbinlog.

Так что в мускуле есть инкрементальный бэкап. Журнал транзакций - это и есть Binary Log?

Осталось разобраться с терминами: "разностный" и "полный".

AlexShop писал(а):

Товарищи, что-то не вяжется. Вот сижу читаю статью: http://www.oracle.com/global/ru/oramag/ … crypt.html написаную вроде не глупым человеком (удостоенным наградой администратор года баз данных Oracle). То что существует практика шифрования баз данных - это факт.

Читать стоило внимательнее. Человек ничего не пишет о существующей практике шифрования данных. Он пишет учебную статью стартового уровня на тему "что такое шифрование и как вообще его можно применить в Oracle 10g". На примере выдуманного "Acme Bank".

Обрати внимание: работая в Starwood Hotels and Resorts, он не пишет "я в своей ежедневной практике забочусь о сохранности данных моих клиентов и вот как я это делаю".

А теперь тест на понимание статьи:

1. От какой именно атаки защищает предлагаемая автором методика?
2. Защищает ли эта методика "от нечестного админа БД"?

AlexShop, в пентагоне работаете?

AlexShop писал(а):

Так что в мускуле есть инкрементальный бэкап. Журнал транзакций - это и есть Binary Log?

Это очень хорошо. Я даже рад, что все так повернулось, мне нечего на это возразить. Я просто не подумал про Binary Log, конечно же - это и есть журнал транзакций и инкрементальный бэкап. Ну, и полный бэкап - тоже. Жаль, искренне жаль, что это не функции, процедуры и курсоры, для них предусмотрен отдельный функционал.
Сомненья прочь, с сегодняшнего дня для журнала транзакций у меня есть новое название - "Binary Log".
Только вот что странно:

ну да ладно, в разработке стратегии резервного копирования это неважно.

diezel2005,

там дальше написано:
Выходит что связанность между Binary Log и InnoDB сохраняется при помощи --innodb-safe-binlog опции.

AlexShop, как, кстати, эта опция влияет на скорость? Здравый смысл говорит, что таковое влиянее должно быть.

Crazy,
Binary Log замедляет на 1%. Насчет той опции незнаю.

Читаю книгу MySQL Pro. Кстати она свободно доступна в Google Books (за исключением отдельных страниц).
Там написано (стр. 82) что Transaction Log использует концепцию Write ahead logging (Изменения сначала пишутся лог, а потом в базу).

Я уже было подумал что это то, о чем diezel2005 писал:

Цитата:

At that point, mysqld writes the entire transaction to the binary log before the COMMIT is executed.

Не тут то было!
На странице 87 пишется что Binary Log не использует "Write ahead logging". И Binary Log не гарантирует атомарность (Atomicity) данных.

Но дальше (на той же странице) пишется что InnoDB имеет свою несколько иную "Write ahead logging" систему. А все мы знаем что InnoDB соответствует ACID.

Вообщем мне пока мало что понятно.
Но одно ясно: мешать транзактные (InnoDB) с нетранзактными (MyISAM) таблицами очень не рекомендуется.

-------
Я заметил что в Google Books одна и та же страница иногда доступна, а иногда нет.

Crazy писал(а):

посмотри, на каких принципах существует Kerberos.

Разбираюсь с Kerberos. Первый вопрос:

Kerberos подходит для клент-сервер приложений что бы передавать данные по незащищенным путям.
Броузер - это тоже клиент, но тонкий (сам не умеет шифровать).
Что бы зашифровать (или расшифровать) данные, их надо переслать серверу (или броузеру) в открытом виде - а это уже дыра.

Значит Kerberos не заменяет SSL (в случае с браузером)?

Очень интересный топик, хотелось бы его поднять.
Столкнулся с похожей задачей защиты важных данных в mysql бд.
Долго гуглил, русскоязычной инфы нет, разве что вот такая статья.
http://www.xakep.ru/post/48406/default.asp?page=1

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

san2012,
я думаю о такой схеме:

Если пользователи используют пароль что бы работать на вашем сайте то:
вы можете шифровать данные используя пароль пользователей (как ключ).

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

Плюсы, минусы и нюансы:

1. Разные данные зашифрованны под разными ключами (причем ключ известен только владельцам данных)
2. Вы не сможете читать данные. Если пользователь забыл пароль (ключ), то данные навсегда потеряны.
3. Пароли могут быть слишком короткие, поэтому не используйте его буквально как ключ, а на основе пароля создайте длинный ключ (например используя хэш функцию)
4. Если пользователи будут сохранять новые данные, то их придется постоянно шифровать, это значит что:
а) ключ должен быть где-то временно записан (пока пользователь залогинен) на сервере или в куках
б) альтернативный вариант: половина ключа в куках, половина на сервере.

5. Естественно пароли в базе не хранятся (а только их хэши).
6. Если пользователь сменил пароль, то придется зашифровать все данные заного (на резервных копиях тоже).

На практике я это не использовал, поэтому могут быть подводные камни.

AlexShop, не читай ксакеп, тоже козленочком станешь.

Crazy,
а что думаешь о моей схеме?

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

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

AlexShop, прежде всего я не вижу для этой схемы никаких применений.

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

В изложенной схеме ключа нет на сервере. Поэтому шифрование приобретает смысл: защита данных при взломе сервера.

Повторю очень коротко основу:
Пользовательские данные зашифрованы ключами которые генерируются от каждого индивидуального пароля.
Если полученый ключ расшифровал данные, значит пользователь авторизировался.
При этом часть ключа сохраняется временно на сервере, а другая часть в куках.

Плюсы очевидны:
Ключ никогда не хранится полностью на сервере. Поэтому злоумышленник взломав сервер не сможет прочитать данные.
Пользовательские данные можно сделать недоступными для админов.
Использование разных ключей препятствует не только чтению, но и подмене данных.

Конечно это только идея и для практики ее надо дорабатывать.

AlexShop, в вполне понимаю плюсы и минусы. Это как скалка из беррилиевой бронзы: очень прочная, не ломается и не истирается, сможет обслужить по крайней мере 20-30 поколений поваров. Но неясно одно: зачем?

Понятно что затраты на защиту не должны превышать стоимости самих данных.

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

AlexShop, ты не понял моего вопроса. Я не спрашиваю "насколько дорого?". Я спрашиваю "зачем?".

Crazy,
что бы защитить данные в случае несанкционированного доступа на сервер.
Зачем мне надо? Для совершенствования.

AlexShop писал(а):

что бы защитить данные в случае несанкционированного доступа на сервер.

Это опять таки не является осмысленной задачей. Тем более, что есть гораздо более эффективные способы:

1. Не передавать их на сервер (сюрприз, сюрприз)
2. Шифровать и дешифровать на клиенте

Crazy,
сюрприз удался. Защита эффективная для очень специфичных задач.

Не подходит для большинства сайтов в интернете, из-за этих недостатков:

1. Клиент должен работать только со своего компьютера
2. Либо носить данные с собой на флешке. Это попросту не удобно.
3. Клиент может потерять данные. На случай потери данных на сервере, компания имеет железный замок, резервные копии и страховку.
4. Клиент не может восстановить данные, потому что они находятся только у него (ведь по сценарию данных нет на сервере).
5. Клиент должен быть специалистом и знать что делать.

И самое главное: большинство информации должно централизованно находится на сервере, в виде базы данных.

Итак, мы получаем ровно одно осмысленное применение: делать бакапы.

Crazy писал(а):

Итак, мы получаем ровно одно осмысленное применение: делать бакапы.

Crazy,
не совсем понимаю контекст фразы: применение чему?

Применение концепции "хранение на сервере информации, зашифрованной ключом, который находится к клиента".

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

Я уже перечислил недостатки. Считаю что это задачи которые надо решить.

AlexShop, я утверждаю, что единственное известное лично мне разумное применение такой техники -- серверный бакап.

san2012 писал(а):

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

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