pavelvp ну я* На случай рестарта сервера по сбою питания ключ доступен для автоматического поднятия СУБД? Ключ либо вводится с консоли при старте сервера, либо берётся из файлаТ.е. он один для всех БД на сервере ?

ASCRUS hvlad pavelvpКлюч либо вводится с консоли при старте сервера, либо берётся из файлаТ.е. он один для всех БД на сервере ?
Не обязательно - в ASA к примеру в строке запуска сервера/сервиса при перечислении подключаемых к серверу БД так же идут параметры БД, в том числе и ключи на каждую из БД.Т.е. для того, чтобы создать новую шифрованную БД, я должен перезапустить весь сервер ?

ASCRUS hvladТ.е. для того, чтобы создать новую шифрованную БД, я должен перезапустить весь сервер ?
Это еще зачем ? Кто мешает на WatcomSQL c помощью команд CREATE DATABASE, START DATABASE и STOP DATABASE спокойно создавать, запускать и останавливать конкретные БД на сервере, опять же указывая ключ криптографии БД ?А зачем тогда "Ключ либо вводится с консоли при старте сервера, либо берётся из файла" ???

pavelvp Александр ГoлдунТ.е. не мудрствуя лукаво не стали изобретать велосипеды с новыми модными
названиями для маркетинга, а сделали просто и понятно как в ASA?
Правильный подход :) Да собственно ASA здесь как бы ни при чём :-)
Пошли простым логическим путём, просто и со вкусом :-)Просто - да, со вкусом - не обнаружил :)
На мой предыдущий вопрос ответ будет ? Или опять как в ASA (которая не при чём :) ?

ASCRUSНу если при старте сервера ему сразу указываются БД, которые нужно поднимать ... надо же как то ключ при запуске указать.Ok. Итого - в ASA имеем два способа сообщить серверу ключ шифрования :
- ком строка
- START DATABASE

В первом случае БД доступна всем идентифицированным клиентам.

Во втором случае - сначала (после старта сервера) БД не доступна никому, затем, после передачи ключа в START DATABASE одним из "знающих" приложений, доступна - кому ? Только этому приложению или всем, подключающимся после него ?

pavelvp2 hvlad
Не понял вопросов. Достаточно ясно было сказано, что для ЛИНТЕР (как я понял из слов ASCRUS, в ASA сделано так же) ключ указывается для базы. Т.е. у каждой БД свой ключ. Чтобы базу стартовать - нужно указать ключ, любым из доступных способов.Какие способы доступны в Линтере, кроме передачи ключа через ком. строку при запуске сервера ?

Можно ли иметь разные ключи для разных БД на одном сервере и как этого достичь ?

Неужели это сложные вопросы ?

pavelvp2 hvlad
Не понял вопросов. Достаточно ясно было сказано, что для ЛИНТЕР (как я понял из слов ASCRUS, в ASA сделано так же) ключ указывается для базы. Т.е. у каждой БД свой ключ. Чтобы базу стартовать - нужно указать ключ, любым из доступных способов.Я не вижу в ваших постах "достаточно ясную фразу" о том, что "ключ указывается для базы"
Или у вас один серверный процесс обслуживает одну БД ?

pavelvp hvladЯ не вижу в ваших постах "достаточно ясную фразу" о том, что "ключ указывается для базы"При создании/старте БД...
Или у вас один серверный процесс обслуживает одну БД ?Да.Это совершенно не очевидно для тех, кто не знаком с Линтером.
Ладно - проехали.

Итак, в Линтере только один способ задать ключ шифрования БД - при старте экземпляра процесса, обслуживающего БД, так ?
О какой защите тогда идёт речь ? Только от физической кражи самой БД ?
Что мешает украсть и ком. строку запуска, если уж БД украдена ? (не будем рассматривать сейчас как она оказалась украдена - если её невозможно украсть, то и шифрование не нужно)

pavelvpЭта тема "обсасывалась" здесь уже много раз. Если бы, да кабы... Можно ещё вспомнить про терморектальный криптоанализатор... Я никого за язык не тяну, однако. Не хочешь говорить на эту тему - не говори...
Если поддержка шифрования в Линтере появилась недавно (как я понял из предыдущих "достаточно ясных фраз"), то о каком "обсасывалась" речь ?
Вдруг вы что-то радикально новое родили ?

pavelvp100% гарантии защиты не даст никто.А накуа вы тогда это воообще делали ? Маркетинговые бла-бла-бла развести ?

pavelvp hvladА накуа вы тогда это воообще делали ? Маркетинговые бла-бла-бла развести ? Возможно кому-то будет достаточно 90%-ой гарантии :-)
Вопросы безопасности требуют комплексного подхода. ЛИНТЕР обеспечивает высочайший уровень разграничения доступа для СЗИ. Не знаю, не пробовал

pavelvpЕсть ещё КСЗИ. Т.е. если кто-то хочет ещё и шифровать данные - пожалуйста. Теперь можно ещё щифровать. Но средствами только СУБД проблемы безопасности не решить - это очевидно.Угу, только некоторые бла-бла-товарищи это почему-то не упоминают :)

pavelvpМожно сделать и в FB шифрацию - ну и что, кому это нужно...Да вот - оказывается нужно. Думаешь - чего я в эту тему влез ? :)

pavelvpВопросы типа, а что же делать, если есть доступ к скриптам, ключам и т.п. некорректны. Это не проблема СУБД. Тебе предоставляются определённые возможности. Как ты ими воспользуешься - другой вопрос. Главное, что такая возможность есть, и её можно использовать.Тут ты не прав. Вопросы эти не некорректны, а неудобны - для того, кому их задают. Ибо в конце сводятся к одному, извечному, - "а на куа ?" - я его уже задал и ответа, извини, не получил :)
Насчёт "Это не проблема СУБД" - по большому счёту - да. Но. Если в СУБД ввели какую-то ф-цию, то нужно сделать так, чтобы можно было извлечь из неё максимум пользы.

ASCRUSМне кажется рассматривать критерий безопасности нужно на реальных примерах, где и чем это может помочь, только так можно понять действенность тех или иных принятых мер. К примеру криптография в ASA в моей практике здорово пригодилась:
1. В конторах, куда неожиданно нагрядывали "люди в черном" и изымали парк техники на определенное время - в итоге основным уловом оказывались офисные документы сотрудников, но не базы фирм, из за которой они и приезжали. Ключик был только у нескольких лиц и при старте сервер обращался к дискете, откуда должен был его считать.Ok

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

ASCRUS3. Против недобросовестных сотрудников различных коммерческих структур, которые побоятся на рабочем месте попытаться выгрузить данные в CSV или отчетные формы или Excel (естественно тут можно выгрузить только те, что доступны данным лицам, однако частенько по ходу специфики работ именно таким лицам доступна наиболее полная аналитическая и финансовая информация). Поэтому они предпочтут попытаться забрать бакуп и уже в спокойной обстановке найти специалистов, которые вытащат данные из БД.Намекаешь на зашифрованный бекап ?
Проще купить АБД который сделает незашифрованный бекап

ASCRUS4. Против захвата клиентов, особенно тех, кто принадлежит к госслужбам. Здесь достаточно частенько бакуп БД "перекорчевывает" к конкурирующей софтверной компании, быстренько оценивается структура БД и когда "сверху" дело идет на лад, снизу уже готов конветор, позволяющий быстро перезапустить у клиентов уже свое ПО.Аналогично

ASCRUSТаким образом, можно сказать, что криптография БД:
1. Увеличивает время попыток получения доступа к информации сторонним лицам, что дает определенные преимущества (фору) владельцу БД для предпринятия мер по защите (и не только информации, но и себя самого).да

ASCRUS2. Увеличивает кол-во попыток кражи информации внутренним лицам, где им не достаточно просто унести резервную копию и необходимо добыть ключ, что увеличивает стоимость и риск работ по краже информации.не совсем так

ASCRUS3. Дает возможность организации защиты удаленных БД, которые лично не мог быть проконтролированны их владельцами.при правильной реализации в СУБД, пока не уверен что это так и есть в ASA\Линтере

ASCRUSЯ не спорю, что 128-разрядный ключ можно ломануть, однако даже узнав ключ, будет неплохо узнать логины и пароли для того, чтобы не только запустить БД с вычисленным ключом, но и подключится к ней.Ключи редко ломают - их чаще крадут\перехватывают\перекупают

ASCRUSТак что ... если есть кувалда с наковальней рядом с сервером, бронированная дверь и админ с автоматом - это хорошо, но не во всех случаях применимо и приемлимо. Для таких случаев криптография БД совсем неплохой плюс для производителя ПО в глазах его клиентов.Да
Но хотелось бы поточнее определить область её применимости и степень гарантий