Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485
Не четал. Линтер. Ф принципе сертификация госкомиссии о чём-то да говорит.
13 июн 06, 22:40    [2767795]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485
Почетал. Про Линтер уже писали. Юних даёт хорошую защиту файлов от того чтоб кто не попадя не читал. Сколько знаю последнюю дыру залепили года два назад.
13 июн 06, 22:42    [2767798]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
Sarin
Member

Откуда: Земля, Солнечная система.
Сообщений: 14485
Коль данные такие секретные то лучше пострадать параноей. А именно: не подключать компы вообще ни к какой сети. Поставить компы в отдельные комнаты без окон без дверей. Комнаты на одно рабочее место. Поставить у входа дядю с пистолетиком или автоматиком. Поставить средства борьбы с ПЭМИ, сенсорные клавиатуры, ЖК-мониторы. И тогда страшно только вооружонное нападение.
13 июн 06, 22:45    [2767802]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Guest
pavelvp
ну я
* На случай рестарта сервера по сбою питания ключ доступен для автоматического поднятия СУБД?
Ключ либо вводится с консоли при старте сервера, либо берётся из файла
Т.е. он один для всех БД на сервере ?
14 июн 06, 00:03    [2767890]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
ASCRUS
Member

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

Не обязательно - в ASA к примеру в строке запуска сервера/сервиса при перечислении подключаемых к серверу БД так же идут параметры БД, в том числе и ключи на каждую из БД.
14 июн 06, 06:27    [2768027]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Guest
ASCRUS
hvlad
pavelvp
Ключ либо вводится с консоли при старте сервера, либо берётся из файла
Т.е. он один для всех БД на сервере ?

Не обязательно - в ASA к примеру в строке запуска сервера/сервиса при перечислении подключаемых к серверу БД так же идут параметры БД, в том числе и ключи на каждую из БД.
Т.е. для того, чтобы создать новую шифрованную БД, я должен перезапустить весь сервер ?
14 июн 06, 11:01    [2768697]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
hvlad
Т.е. для того, чтобы создать новую шифрованную БД, я должен перезапустить весь сервер ?

Это еще зачем ? Кто мешает на WatcomSQL c помощью команд CREATE DATABASE, START DATABASE и STOP DATABASE спокойно создавать, запускать и останавливать конкретные БД на сервере, опять же указывая ключ криптографии БД ?
14 июн 06, 11:03    [2768715]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Guest
ASCRUS
hvlad
Т.е. для того, чтобы создать новую шифрованную БД, я должен перезапустить весь сервер ?

Это еще зачем ? Кто мешает на WatcomSQL c помощью команд CREATE DATABASE, START DATABASE и STOP DATABASE спокойно создавать, запускать и останавливать конкретные БД на сервере, опять же указывая ключ криптографии БД ?
А зачем тогда "Ключ либо вводится с консоли при старте сервера, либо берётся из файла" ???
14 июн 06, 11:32    [2768895]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Ну если при старте сервера ему сразу указываются БД, которые нужно поднимать ... надо же как то ключ при запуске указать.
14 июн 06, 12:20    [2769165]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Александр Гoлдун
Т.е. не мудрствуя лукаво не стали изобретать велосипеды с новыми модными
названиями для маркетинга, а сделали просто и понятно как в ASA?
Правильный подход :)
Да собственно ASA здесь как бы ни при чём :-)
Пошли простым логическим путём, просто и со вкусом :-)
14 июн 06, 12:26    [2769201]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Guest
pavelvp
Александр Гoлдун
Т.е. не мудрствуя лукаво не стали изобретать велосипеды с новыми модными
названиями для маркетинга, а сделали просто и понятно как в ASA?
Правильный подход :)
Да собственно ASA здесь как бы ни при чём :-)
Пошли простым логическим путём, просто и со вкусом :-)
Просто - да, со вкусом - не обнаружил :)
На мой предыдущий вопрос ответ будет ? Или опять как в ASA (которая не при чём :) ?
14 июн 06, 12:31    [2769236]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
2 hvlad
Не понял вопросов. Достаточно ясно было сказано, что для ЛИНТЕР (как я понял из слов ASCRUS, в ASA сделано так же) ключ указывается для базы. Т.е. у каждой БД свой ключ. Чтобы базу стартовать - нужно указать ключ, любым из доступных способов.
14 июн 06, 12:32    [2769241]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Guest
ASCRUS
Ну если при старте сервера ему сразу указываются БД, которые нужно поднимать ... надо же как то ключ при запуске указать.
Ok. Итого - в ASA имеем два способа сообщить серверу ключ шифрования :
- ком строка
- START DATABASE

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

Во втором случае - сначала (после старта сервера) БД не доступна никому, затем, после передачи ключа в START DATABASE одним из "знающих" приложений, доступна - кому ? Только этому приложению или всем, подключающимся после него ?
14 июн 06, 12:39    [2769279]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Guest
pavelvp
2 hvlad
Не понял вопросов. Достаточно ясно было сказано, что для ЛИНТЕР (как я понял из слов ASCRUS, в ASA сделано так же) ключ указывается для базы. Т.е. у каждой БД свой ключ. Чтобы базу стартовать - нужно указать ключ, любым из доступных способов.
Какие способы доступны в Линтере, кроме передачи ключа через ком. строку при запуске сервера ?

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

Неужели это сложные вопросы ?
14 июн 06, 12:42    [2769301]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Guest
pavelvp
2 hvlad
Не понял вопросов. Достаточно ясно было сказано, что для ЛИНТЕР (как я понял из слов ASCRUS, в ASA сделано так же) ключ указывается для базы. Т.е. у каждой БД свой ключ. Чтобы базу стартовать - нужно указать ключ, любым из доступных способов.
Я не вижу в ваших постах "достаточно ясную фразу" о том, что "ключ указывается для базы"
Или у вас один серверный процесс обслуживает одну БД ?
14 июн 06, 12:45    [2769320]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
hvlad
Я не вижу в ваших постах "достаточно ясную фразу" о том, что "ключ указывается для базы"
При создании/старте БД...
Или у вас один серверный процесс обслуживает одну БД ?
Да.
14 июн 06, 12:58    [2769416]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Guest
pavelvp
hvlad
Я не вижу в ваших постах "достаточно ясную фразу" о том, что "ключ указывается для базы"
При создании/старте БД...
Или у вас один серверный процесс обслуживает одну БД ?
Да.
Это совершенно не очевидно для тех, кто не знаком с Линтером.
Ладно - проехали.

Итак, в Линтере только один способ задать ключ шифрования БД - при старте экземпляра процесса, обслуживающего БД, так ?
О какой защите тогда идёт речь ? Только от физической кражи самой БД ?
Что мешает украсть и ком. строку запуска, если уж БД украдена ? (не будем рассматривать сейчас как она оказалась украдена - если её невозможно украсть, то и шифрование не нужно)
14 июн 06, 13:18    [2769523]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290


hvlad пишет:

> Ok. Итого - в ASA имеем два способа сообщить серверу ключ шифрования :
> - ком строка

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

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

Всем подключающимся после него.

Posted via ActualForum NNTP Server 1.3

14 июн 06, 14:31    [2769962]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
2 hvlad

Эта тема "обсасывалась" здесь уже много раз. Если бы, да кабы... Можно ещё вспомнить про терморектальный криптоанализатор... 100% гарантии защиты не даст никто.
Если нужно защить секретные данные от кражи - ИМХО гораздо эффективнее реализовать это посредством физического уничтожения данных на носителе информации. Такие устройства сейчас свободно доступны.

Нужно сначала нужно определить что есть кража. При физическом наличии носителя у злоумышленника, и при наличии достаточного количества времени - взломать можно что угодно.
Для начала нужно проанализировать возможные угрозы и правильно определить периметр безопасности. А разговаривать об абстрактной краже абстрактных данных можно сколько угодно.

не будем рассматривать сейчас как она оказалась украдена

Это почему? В нашем случае наличие доступа к файлам БД не означает наличие доступа к скриптам. И здесь всё зависит от возможностей ОС. Если злоумышленник имеет рутовый логин, доступ к консоли, возможность перехватить процедуру старта... то извините - о какой тогда защите идёт речь?

Методов то, фактически всего три:
1) разграничение доступа
2) криптозащита
3) административные меры

В зависимости от поставленных целей - выбирайте любые два :-) Применение только одного не даст никаких гарантий.
Почти всегда достаточно 1) и 3).
В некоторых случаях :-) достаточно 3).
И никогда недостаточно только 2) !!!
14 июн 06, 15:23    [2770278]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Guest
pavelvp
Эта тема "обсасывалась" здесь уже много раз. Если бы, да кабы... Можно ещё вспомнить про терморектальный криптоанализатор...
Я никого за язык не тяну, однако. Не хочешь говорить на эту тему - не говори...
Если поддержка шифрования в Линтере появилась недавно (как я понял из предыдущих "достаточно ясных фраз"), то о каком "обсасывалась" речь ?
Вдруг вы что-то радикально новое родили ?

pavelvp
100% гарантии защиты не даст никто.
А накуа вы тогда это воообще делали ? Маркетинговые бла-бла-бла развести ?
14 июн 06, 19:01    [2771779]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
hvlad
А накуа вы тогда это воообще делали ? Маркетинговые бла-бла-бла развести ?
Возможно кому-то будет достаточно 90%-ой гарантии :-)
Вопросы безопасности требуют комплексного подхода. ЛИНТЕР обеспечивает высочайший уровень разграничения доступа для СЗИ. Есть ещё КСЗИ. Т.е. если кто-то хочет ещё и шифровать данные - пожалуйста. Теперь можно ещё щифровать. Но средствами только СУБД проблемы безопасности не решить - это очевидно. Можно сделать и в FB шифрацию - ну и что, кому это нужно...
Вопросы типа, а что же делать, если есть доступ к скриптам, ключам и т.п. некорректны. Это не проблема СУБД. Тебе предоставляются определённые возможности. Как ты ими воспользуешься - другой вопрос. Главное, что такая возможность есть, и её можно использовать.
14 июн 06, 19:57    [2771897]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Guest
pavelvp
hvlad
А накуа вы тогда это воообще делали ? Маркетинговые бла-бла-бла развести ?
Возможно кому-то будет достаточно 90%-ой гарантии :-)
Вопросы безопасности требуют комплексного подхода. ЛИНТЕР обеспечивает высочайший уровень разграничения доступа для СЗИ.
Не знаю, не пробовал

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

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

pavelvp
Вопросы типа, а что же делать, если есть доступ к скриптам, ключам и т.п. некорректны. Это не проблема СУБД. Тебе предоставляются определённые возможности. Как ты ими воспользуешься - другой вопрос. Главное, что такая возможность есть, и её можно использовать.
Тут ты не прав. Вопросы эти не некорректны, а неудобны - для того, кому их задают. Ибо в конце сводятся к одному, извечному, - "а на куа ?" - я его уже задал и ответа, извини, не получил :)
Насчёт "Это не проблема СУБД" - по большому счёту - да. Но. Если в СУБД ввели какую-то ф-цию, то нужно сделать так, чтобы можно было извлечь из неё максимум пользы.
14 июн 06, 21:56    [2772186]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Мне кажется рассматривать критерий безопасности нужно на реальных примерах, где и чем это может помочь, только так можно понять действенность тех или иных принятых мер. К примеру криптография в ASA в моей практике здорово пригодилась:
1. В конторах, куда неожиданно нагрядывали "люди в черном" и изымали парк техники на определенное время - в итоге основным уловом оказывались офисные документы сотрудников, но не базы фирм, из за которой они и приезжали. Ключик был только у нескольких лиц и при старте сервер обращался к дискете, откуда должен был его считать.
2. На удаленных точках и у удаленных клиентов, где владелец базы должен отдать ее на удаленную экплуатацию, но очень не хочет, чтобы она пошла куда нибудь дальше. Здесь в основном ASA оформлялся как встроенный сетевой сервер, где его локально запускало и останавливало собственное приложение с вшитым ключом (здесь удобно, что драйверы доступа ASA при указанной опции и имени файла БД автоматически стартуют сервер при первом к нему локальном обращении и он автоматически выгружается при отсутствии у него любых соединений).
3. Против недобросовестных сотрудников различных коммерческих структур, которые побоятся на рабочем месте попытаться выгрузить данные в CSV или отчетные формы или Excel (естественно тут можно выгрузить только те, что доступны данным лицам, однако частенько по ходу специфики работ именно таким лицам доступна наиболее полная аналитическая и финансовая информация). Поэтому они предпочтут попытаться забрать бакуп и уже в спокойной обстановке найти специалистов, которые вытащат данные из БД.
4. Против захвата клиентов, особенно тех, кто принадлежит к госслужбам. Здесь достаточно частенько бакуп БД "перекорчевывает" к конкурирующей софтверной компании, быстренько оценивается структура БД и когда "сверху" дело идет на лад, снизу уже готов конветор, позволяющий быстро перезапустить у клиентов уже свое ПО.

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

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

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

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase
15 июн 06, 06:31    [2772639]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
hvlad
Member

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

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

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

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

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

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

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

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

ASCRUS
Так что ... если есть кувалда с наковальней рядом с сервером, бронированная дверь и админ с автоматом - это хорошо, но не во всех случаях применимо и приемлимо. Для таких случаев криптография БД совсем неплохой плюс для производителя ПО в глазах его клиентов.
Да
Но хотелось бы поточнее определить область её применимости и степень гарантий
15 июн 06, 11:00    [2773304]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД. Основной критерий – безопасность.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
hvlad
Возможен ли коннект к серверу другого приложения пока запущено "основное" ?

Конечно возможен ... но при условии, что БД это разрешит. В ASA реализована событийная модель перехвата различных событий, происходящих с БД на сервере, где на WatcomSQL мы можем по расписанию или событию выполнить свой код. Таким образом спокойно можно на подключение новой сессии к БД написать свой код в виде хранимки, который будет решать - разрешить ли подключение сессии к БД или дать отлуп.

hvlad
Намекаешь на зашифрованный бекап ?
Проще купить АБД который сделает незашифрованный бекап

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

hvlad
при правильной реализации в СУБД, пока не уверен что это так и есть в ASA\Линтере

Могу создать тестовую криптованную БД и выслать, гарантировав ящик пива в случае получения информации из таблиц.

hvlad
Ключи редко ломают - их чаще крадут \ перехватывают \ перекупают

Согласен, однако для того чтобы красть, перехватывать и перекупать ключи нужны специалисты и деньги, а для того, чтобы взять бакуп без криптографии и развернуть его на свежеинсталированный сервер нужен студент, знающий просто как это сделать (не для Oracle конечно, где не все так просто для студента).

hvlad
Но хотелось бы поточнее определить область её применимости и степень гарантий

Насколько я понимаю, для ASA производитель гарантирует, что при использовании 128-разрядного ключа (для 10-ой новой версии 256-разрядного) файлы БД, лог-файлы и временные файлы, используемые при работе сервера будут шифроваться по алгоритмам AES или AES_FIPS на всех поддерживаемых платформах (это Windows, Linux, Unix, Solaris, Novell, Mac, IBM, PocketPC, PalmOS). С учетом того, что наиболее ценную информацию в центральных офисах клиенты все таки предпочитают хорошо защищать, основное применение данной опции - защита данных на удаленных филиалах, ноутбуках и КПК, где физическая кража сервера или информации с него может быть достаточно легко организована. Кстати опять же на моей памяти именно с удаленных филиалов прекрасно удавалось забирать информацию, которую нельзя было бы никакими судьбами взять с защищенного физически и программно центрального сервера.
15 июн 06, 12:15    [2773896]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить