Есть 2 другие волшебные галочки...
Первая - шифровать протокол
Вторая - отобрать права на доступ к серверу "у всех".

Для шифрования данных внутри базы нужно, чтобы ее аналитик и проектировщик разбирались хоть как-то в вопросах криптографии. А если говорить "в общем", то зашифровать реально только ту информацию, которая должна быть доступна одному-двум СТРОГО определенным людям.
Причем ОСТАЛЬНЫМ (включая программиста, директора и сисадмина) она не будет доступна НИКОГДА и НИКАК. Только в виде зашифрованного потока.
Все остальное - деццкий сад.

Кстати, спросите заказчика "для начала", что он подразумевает под "зашифровано"? :)
Кто конкретно должен видеть и в каких случаях, а кто - нет. И решайте уже эту задачу, а не абстрактное желание "Зашифровать все нифик".

ShtockНичем не грозит.Берете любую субд,которая это поддерживает и шифруете прозрачно для себя.Оракле 10-ке вроде бы появилась возможность устанавливать признак зашифрованности для соответствующего поля таблицы.И как Оракл узнает, кому расшифровывать, а кому - нет? ;)

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

Petr Chulkov DeColo®esНу да. Задача решена, вроде. "Все зашифровано".
Но когда простой бухгалтер смотрит проводки, он почему-то видит, сколько получает его сосед в абсолютно незашифрованном виде, хотя диреХтору этого совсем не хотелось бы. :)
ну так тогда это совершенно другая задача
не криптования а ограничения доступа
и решать её надо соотв. другими инструментами...ВО! Об этом и речь!
Сначала надо понять, что подразумевается под словом "зашифровать".
Ибо зашифровать можно:
1) Носители, на которых лежат данные СУБД.
Плюс - никаких трудозатрат по модификации софта, минус - либо пароль зашит в процесс загрузки, либо его нужно "вводить" каждый раз при запуске системы.

2) Сами файлы СУБД. (например, использовать EFS)
Плюс - система загружается "сама", минус - загрузившись под профилем, под которым запущена СУБД, получаем полный доступ к данным

3) (Гипотетически) СУБД сама шифрует данные перед сбросом на диск
Плюсы/минусы теже, что в методах 1,2.
Лично я о существовании таких СУБД не слышал.

4) Шифруются отдельные "ячейки" в БД.
Плюс - мы сами определяем, что зашифровано, что нет.
Минусы - зашифровать можно только те данные, которые не анализируются самой СУБД.
То есть поля, которые участвуют в агрегатных функциях, в условиях WHERE и т.д. либо не могут быть зашифрованы, либо пароль для расшифровки должен быть доступен самой СУБД, а это уже не шифрование, а непонятно что.
Еще минус в кроется в "плюсе" - в том, что нам самим придется определять стратегию шифровки/расшифровки для каждого конкретного столбца и записи. И менять для этого софт, обеспечивать хранение ключей и т.д.

Q DeColo®es под какой пункт попадает :
- ASA
- MS SQL Server
- OraclА вам по-барабану, на чем писать? :)
Я уже писал, что для реализации этого, нужно, чтобы Вы (исполнитель) РАЗБИРАЛИСЬ в этом вопросе. А судя по Вашему вопросу, вы и мой пост невнимательно прочитали, мне кажется, там достаточно прозрачно написано, какой способ к какой подсистеме компьютера относится.
Потом, опять же, что считать шифрованием - ведь действительно, XOR 1 - тоже симметричное шифрование с закрытым ключем. Больше того, данные в БД и так зашифрованы - для того, чтобы "прочитать текст", нужно иметь программу (алгоритм шифрования), которая умеет данные из файла СУБД превратить в поток осмысленных данных и таблицу символов, в которой определено, какая буква алфавита какому коду соответствует. :)

А "шифрование текстовых данных" можно реализовать миллионом способов, у каждого будет миллион же недостатков.

Qдумаю вы понимаете, что имеется ввиду поддержка криптозащиты на уровне БД а не самописками XORА если XOR-ить на сервере в ХР? ;)

Вопрос поставлен все-таки неправильно. Сначала нужно выяснить - ЧТО ШИФРУЕМ, КТО ШИФРУЕТ и КТО ЧИТАЕТ.

Например:
Данные пациента в его истории болезни должны быть "защищены". Как защищены? Допустим, зашифрованы. Это здорово! Ставим врачам всякие крипто-про (или реализуем поддержку шифрования тем же MSSQL) и - вперед. Но вот какое горе - врач в отпуске, на канарах, на яхте, без мобильника, а нам нужно срочно узнать его заключение о возможности применения конкретного препарата (пациент в операционной, у него осложнение, нужно наркоз срочно делать, а само "толо" говорить не может - кома у него).
И что делать? Можно шифровать ключами всех врачей сразу - но смысл? Да и может появиться новый врач....

Вывод: Данные истории болезни не только не могут быть зашифрованы, но должны быть ЛЕГКО доступны ЛЮБОМУ специалисту, который потенциально МОЖЕТ быть привлеченным к лечению этого пациента.

И так далее. По КАЖДОМУ полю нужно решать КОНКРЕТНО, кто будет туда вносить данные, как эти данные могут быть зашифрованы и в каких случаях, кому они должны быть доступны.

ЗЫ Администратор БД тоже человек, нужно определиться, к какой инфо у него есть доступ, а к какой - нет. :)