Каморка

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

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

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

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

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

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

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

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

-Maxim

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

Это вы о чем?

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

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

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

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

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

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

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

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

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

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

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

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

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