Зашифровать данные в базе данных

[shadow7256]

у MSSQL на 200% есть возможность шифрования базы налету.

так я же писал, что ихние DBA сидят в Индии и тупые как пробки (те технари и менеджры что в Англии сидят тоже дебилы еще те), они не желают учить это и просто говорят своему начальству что this is not secure enough.

[timeau]

Значения переменных можно подглядеть в /proc/..., так что они не более скрыты чем файл с доступом 600.

Да и фиг с ним! Если это VM или контейнер - постараться еще надо на этот хост (контейнер) зайти. Но тут-то речь об ином - как хранить, а не как вообще спрятать. Кстати, я не уверен, что можно прочитать /proc, если процесс работает от лица кастрированного юзера без shell'a типа "tomcat" или "mongo". Ну если ты не root, само собой.

[Flash-04]

у MSSQL на 200% есть возможность шифрования базы налету.

так я же писал, что ихние DBA сидят в Индии и тупые как пробки (те технари и менеджры что в Англии сидят тоже дебилы еще те), они не желают учить это и просто говорят своему начальству что this is not secure enough.

Это надо не DBA спрашивать, а secuiry architects, которые на этом специализируются.

У меня был интересный случай из практики: заказали secuiry audit "коробочного" коммерческого софта (кстати известная компания, её наверное каждый знает). Там в составе был Web Solution, где пользователи могли выкладывать свои фотки, видео, и в плане безопасности генерился уникальный ключ для каждого пользователя. Для того, что если упрут, то расшифровать невозможно. Я посмотрел в код, вроде все правильно. Сказал своему боссу. Тот сказал мне, чтобы я рассказал ему как у них ключи генерятся. Послушал меня, и говорит "бинго!". Чего говорю? А он мне отвечает: они берут в качестве сида ключа GUID пользователя Windows. Всё бы хорошо, но у этого ключа большая часть статичная, поэтому эффективная длина ключа маленькая и его можно сломать тупым перебором.

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

[shadow7256]

Бля... просто нет слов!!! Я уже теперь борюсь не этим гребаным барклаем, а со своим начальником (и менеджером, который тоже девелопер).

Я им говорю, что RSA НЕ предназначен для шифрования больших объемов данных. Просто физически это невозможно, для этого есть тот же AES например. У асимметричных и симметричных алгоритмов разные цели абсолютно и не надо пытаться применить один алгоритм, если у него другая цель. Мне в ответ "ну вот мы пообещали RSA и барклай согласился и надо делать RSA" Так может прежде, чем предлагать что то, надо сначала понять а подойдет ли это решение? Разумно ли его пользовать? я уже устал присылать им статьи в инете..

может кто подскажет ссылку на статью, которая ясно и четко покажет для чего нужен RSA и для чего AES...

[Flash-04]

А пожалуйста:


Совершенно серьёзно, эту книгу надо читать всем кто хочет разбираться в криптографии.
У меня есть раритет - российское издание с подписью автора

[shadow7256]

А пожалуйста:


Совершенно серьёзно, эту книгу надо читать всем кто хочет разбираться в криптографии.
У меня есть раритет - российское издание с подписью автора

спасибо, скачал почитаю для самообразования. Вообщем свое начальство я продавил насчет AES, теперь осталось убедить придурков в Барклаее

[Flash-04]

AES - правильный выбор

[Mark]

у MSSQL на 200% есть возможность шифрования базы налету.

так я же писал, что ихние DBA сидят в Индии и тупые как пробки (те технари и менеджры что в Англии сидят тоже дебилы еще те), они не желают учить это и просто говорят своему начальству что this is not secure enough.

А давайте предложим вашему клиенту контракт по внедрению TDE если интересно пишите в личку


Sent from my iPhone using Tapatalk

[shadow7256]

AES - правильный выбор

Кстати начал "читать" Вашу книгу ) почти пол книги пролистал - одни ссылки на Боба, Алису и других "участников" вообщем немного разочаровала она. Одна теория и никакого applied cryptography. Для спецов по безопасности наверное супер будет

[shadow7256]

у MSSQL на 200% есть возможность шифрования базы налету.

так я же писал, что ихние DBA сидят в Индии и тупые как пробки (те технари и менеджры что в Англии сидят тоже дебилы еще те), они не желают учить это и просто говорят своему начальству что this is not secure enough.

А давайте предложим вашему клиенту контракт по внедрению TDE если интересно пишите в личку


Sent from my iPhone using Tapatalk

А что конкретно этот контракт будет подразумевать?

[zVlad]

Вот хороший образчик того о чем я говорю в другой ветке. На дворе начало третьего десятилетия 21 века. Скоро будет столетие кибернетике, электронике и собственно компьютерам и програмированию. А мы демонстрируем худшие образчики не только решения стандартной, казалось бы, проблемы - защита данных, но и неумение строить отношения заказчик-исполнитель. У меня на работе тоже сплошь и рыдом повторяется: "клиент (заказчик) так хочет". И при этом никаких консультаций со спесиалистами исполнителя, все на уровне манагеров, которые научены говорить только "yes, sir".

У топик стартера проскочило что на самом деле Барклаю нужна хорошая защита сервера базы данных что не должно быть проблемой в наши дни и с чего вообще надо начинать защиту своей ИТ. Если они зашифруют колонку а сервер скоммуниздят, то скоммунизьмят и все ключи какие бы они ни были.

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

[Flash-04]

AES - правильный выбор

Кстати начал "читать" Вашу книгу ) почти пол книги пролистал - одни ссылки на Боба, Алису и других "участников" вообщем немного разочаровала она. Одна теория и никакого applied cryptography. Для спецов по безопасности наверное супер будет

вы видимо ожидали своего рода cookbook для написания кода. Это не так. Прежде чем переходить к кодописательству нужно изучить как вся эта кухня работает. И вот да, "Боб и Алиса" - это уже как бы устоявшийся мем у криптографов. Насчет того, что там нет "applied" - отнюдь. Там как раз разбираются все эти нюансы насчет стойкости алгоритмов, где слабые места и т.п. В конце книги интересная сводка по известым алгоритмам.
Сам автор Брюс Шнайер - можно сказать "икона" в information security. Ему удалось изобрести алгоритм Blowfish, который так и не был взломан. Это удивительно, учитывая, что он не является профессиональным математиком. Алгоритмы изобретенные математиками NSA были взломаны

[Flash-04]

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

клиентов в Active Directory? вы ничего не попутали? им там не место

[zVlad]

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

клиентов в Active Directory? вы ничего не попутали? им там не место

Вместо того чтобы придираться взял бы и сказал где хранится эта информация. Не в таблице же базы данных, надеюсь.

[Flash-04]

В Active Directory хранится информация о пользователях имеющих доступ в Enterprise network. Для того M$ её и создала. Кастомеры не являются пользователями сети, потому информация о них действительно хранится в БД. Что по вашему тут неправильного?