схемы защиты информации

[Sheen]

А кто-нибудь знает (или имеет дело) где можно посмотреть типичные схемы защиты данных. Например, SQL Server 2005 (Oracle) имеет встроенные механизмы, но ключи там же в базе, что не есть secure.

А еще какие схемы бывают?

[ajkj3em]

сначала надо понять от чего информация защищается и плясать от этого

[папа Карло]

правильно говорят... подумай кто тебя будет ломать и как....

[Sheen]

Да я то уже подумал ... просто кто в курсе, тот сразу поймет о чем я ... (и тогда лучше в личку).

[sobomax]

Да я то уже подумал ... просто кто в курсе, тот сразу поймет о чем я ... .

Прямо телепатия какая-то получается!

А если серьезно то много книжек и прочего контента на эту тему есть - гуглите и будет щастие.

-Maxim

[не местный]

SQL Server 2005 (Oracle) имеет встроенные механизмы, но ключи там же в базе

Это вы о чем?

[vg]

А кто-нибудь знает (или имеет дело) где можно посмотреть типичные схемы защиты данных. Например, SQL Server 2005 (Oracle) имеет встроенные механизмы, но ключи там же в базе, что не есть secure.

А еще какие схемы бывают?

А где там ключи лежат? Например, в SQL 2005.

[aissp]

Сразу оговорюсь что не в курсе как решено кправление ключами в 2005 сиквеле, еслитебе нужно именно ето то ничем не могу помочь, но обычно стратегии следующие:
1. Ключи храняться в отдельной базе данных, база данных доступна полностью тока для спец пользователя, который не является пользователем основной базы данных. Пользователи образаются к етой базе данных посредством процедуры, на выполнение которой они имеют права, в процедуре делаются соотвествуюшие проверки, на выходе пользователь получает ключ.
2. Ключ к пользовательским данным хранит непосредственно пользователь, во время сеанса он его передает.
3. Ключи храняться отдельно от базы данных, возможно на другом сервере, так что администратор базы данных не имеет к ним доступа

[Garik]

оговорюсь сразу, я - не телепат. если носитель закрыть, то SecretDisk; если ААА, то ActiveDirectory+цифровые сертификаты в токене. про SSL уже и так вроде бы все разжoвано. Что еще можно закрыть - не знаю.

[Sheen]

Сразу оговорюсь что не в курсе как решено кправление ключами в 2005 сиквеле, еслитебе нужно именно ето то ничем не могу помочь, но обычно стратегии следующие:
1. Ключи храняться в отдельной базе данных, база данных доступна полностью тока для спец пользователя, который не является пользователем основной базы данных. Пользователи образаются к етой базе данных посредством процедуры, на выполнение которой они имеют права, в процедуре делаются соотвествуюшие проверки, на выходе пользователь получает ключ.
2. Ключ к пользовательским данным хранит непосредственно пользователь, во время сеанса он его передает.
3. Ключи храняться отдельно от базы данных, возможно на другом сервере, так что администратор базы данных не имеет к ним доступа

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

ps. Я уже целый день гууглю, прежде чем спросить, думал, может кто специально сталкивался или делал такие схемы. Возможно они не базируются на встроенных в базу средствах защиты или используют Key Management софт. Без понятия.

[aissp]

Для етого ключи можно хранить где то отдельно, например на другом компутере (3). открытые закрытые ключи ето схема номер два, как мне понимается. А вообще коли разговор зашел в ету стороны то присоседюсь к двум первым откликам - какие атаки ты пытаешься предотвратить? - плясать надо отсюда.

[Garik]

еще зависит откуда обращаешься к БД. Если из .Net, то там добавить только атрибут в конф-файле и будет шифровать прям в базу. я думаю, все делается на уровне интерфейса в любом случае, а не напрямую в БД.

[Sheen]

Кому интересно (а интересно по идее должно быть всем, кто работает в healthcare, financial, government и подобных компаниях) вот тут что-то есть обзорное, затрагивает всякие разные виды - http://www.databasesecurity.com/dbsec/c ... ttsson.pdf - иногда полезно знать, чтобы вставить свое веское слово, что неправильно бутерброд едите.

ps. Я тут придумал другой запрос и наткнулся на золотую жилу залежей всякой инфы.

[Garik]

спасибо за ссылку. не понял про бутеброд. задачу можно как-то конкретнее сформулировать или мы просто академически беседуем о методах зашиты информации?