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

[kostik78]

Опять же если что то хорошего Вам насоветовать то надо знать структуру данных конфигурации. Как правило никто не криптует весь конфиг одним скопом - это глупо и реально создание видимости криптографии. Обычно внутри конфигурации какие то параметры или пароли нужно шифровать то бишь не больших размеров. Второй важный вопрос как конфигурация изменяеться. Например через UI или через change management system ну и так далее. Соотвественно варианты решения: public + private key для маленьких данных или комбинация public + private key + password для симитричного алгоритма. Так что просто так с нахрапу не вылет. Нужно смотреть что нужно защищать, как защищённые данные меняются и т.п.

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

[shadow7256]

Опять же если что то хорошего Вам насоветовать то надо знать структуру данных конфигурации. Как правило никто не криптует весь конфиг одним скопом - это глупо и реально создание видимости криптографии. Обычно внутри конфигурации какие то параметры или пароли нужно шифровать то бишь не больших размеров. Второй важный вопрос как конфигурация изменяеться. Например через UI или через change management system ну и так далее. Соотвественно варианты решения: public + private key для маленьких данных или комбинация public + private key + password для симитричного алгоритма. Так что просто так с нахрапу не вылет. Нужно смотреть что нужно защищать, как защищённые данные меняются и т.п.

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

Имя сервера, его протокол (SMTP. POP3, FTP, etc). еще несколько параметров они не шифруются и хранятся в таблице в простом виде. Шифруется именно та часть конфигурации, которая sensitive (Username, Password , какие то public/private certificates, Host, Timeout interval, etc).

я не пойму, чем хорошо public + private keys (asymmetric) в отличие от symmetric? В asymmetric столько ограничений, которых просто нет в symmetric, так нафига заморачиваться с этим asymmetric?

[kostik78]

Опять же если что то хорошего Вам насоветовать то надо знать структуру данных конфигурации. Как правило никто не криптует весь конфиг одним скопом - это глупо и реально создание видимости криптографии. Обычно внутри конфигурации какие то параметры или пароли нужно шифровать то бишь не больших размеров. Второй важный вопрос как конфигурация изменяеться. Например через UI или через change management system ну и так далее. Соотвественно варианты решения: public + private key для маленьких данных или комбинация public + private key + password для симитричного алгоритма. Так что просто так с нахрапу не вылет. Нужно смотреть что нужно защищать, как защищённые данные меняются и т.п.

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

Имя сервера, его протокол (SMTP. POP3, FTP, etc). еще несколько параметров они не шифруются и хранятся в таблице в простом виде. Шифруется именно та часть конфигурации, которая sensitive (Username, Password , какие то public/private certificates, Host, Timeout interval, etc).

я не пойму, чем хорошо public + private keys (asymmetric) в отличие от symmetric? В asymmetric столько ограничений, которых просто нет в symmetric, так нафига заморачиваться с этим asymmetric?

Public + private key используется для того чтобы не было необходимости говорить людям симметричный пароль. Например: пароли в конфигах хранятся в зашифрованном виде при этом данный конфиг обслуживается разными людьми (разные группы и т.п.) если использовать только симметричный алгоритм тогда пароль известен всем и все могут читать у друг друга пароли, секреты и т.п. (дикоиптовать и скомуниздить) что является биг NO-NO для любого аудита (можно конечно проблему решить через административные меры но тогда создаётся bottle neck на определенных людей).

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

Кстати в Вашем случаее данные гуляют по нетворку хотя Вы написал изначально что не гуляют

[timeau]

А как эти переменные выставлять?

Через внутренний закрытый GIT репозиторий. Там лежат файлы с этими паролями, которые считываются в момент deployment'a и тут же удаляются. То есть эти файлы лежат не вместе со всеми сорцами, а сами по себе. Если используются контейнеры, то вообще песня.
А вообще мож я чего не понимаю, сам с этим не работал вот вплотную (я сейчас занимаюсь как раз тем, чему ШБД учил), но не суть: у MSSQL на 200% есть возможность шифрования базы налету. У жены на вояцком проекте они так и делают. Создать отдельную базу (сервер?), который шифруется прямо из сокета. И усе.
В общем, вариантов, как грязи.

[Palych]

А как эти переменные выставлять?

Через внутренний закрытый GIT репозиторий.

Мы как раз так делали.

Там лежат файлы с этими паролями, которые считываются в момент deployment'a и тут же удаляются.

В момент деплоймента или при старте?
Я пытаюсь понять как переменные среды преодолеют "синдром Мюнхгаузена"...
Мы их использовали, но не потому что они добавляют безопасности, а для совместимости разных решений (java, php, perl,...)
Значения переменных можно подглядеть в /proc/..., так что они не более скрыты чем файл с доступом 600.

То есть эти файлы лежат не вместе со всеми сорцами, а сами по себе. Если используются контейнеры, то вообще песня.
А вообще мож я чего не понимаю, сам с этим не работал вот вплотную (я сейчас занимаюсь как раз тем, чему ШБД учил), но не суть: у MSSQL на 200% есть возможность шифрования базы налету.

Тут согласен. Мы Oracle использовали, там конкретные колонки по-моему шифровались. DBA что-то наколдовал, мы добавляли ключ/пароль - и все были довольны...

[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

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