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

[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

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

[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$ её и создала. Кастомеры не являются пользователями сети, потому информация о них действительно хранится в БД. Что по вашему тут неправильного?

[zVlad]

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

MS создал недоразвитое решение. Как всегда. На МФ все "пользователи", и мой аккаунт - RACF Special, у которого все возможности по умолчанию и пользователи клиента хранятся в одном месте - базе данных RACF, или, если хотишь, Active Directory в теминологии MS. Это позволяет избежать проблему нашего друга, топикстартера. Аккунты RACF, в зависимости от того где они могут быть использоиваны - в каких приложениях -, могут иметь или не иметь разнообразные "сегменты". Например для работы в Юникс, или NetView. Если аккоунт не имеет сегмента Юникс, то Юникс ему недоступен. Простейшие аккаунты клиента не имеют никаких сегментов и существуют только для верификации пароля.
Понятно что скоммуниздить RACF базу данных невозможно. Но даже если скоммуниздить то восстановить пароли невозможно. Думаю не надо обьяснять почему. Тоже, полагаю, относится к Active Directory. Странно почему кастомеры, по Вашему, не могут быть там. Кстати, кастомеры нашего клиента точно имеют аккаунты в Active Directory.
Кроме Active Directory имеются разные там LDAP-ы. Думаю что ситуация топикстартера надумана.

[Mark]

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

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

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


Sent from my iPhone using Tapatalk

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

Вкратце - Transparent Database Encryption (TDE) implementation:
- Encrypted database storage setup including certificates/wallets configuration
- Data migration into encrypted storage/tablespace with zero downtime using online redefinition
- Routine maintenance procedures adjustments (startup/shutdown, backups. certificates rotation)
Если вас серьезно интересует proposal - пишите в личку
p.s. Это так же можно объеденить с внедрение Oracle Advanced Compression (ACO) чтоб ужать данные (в сренднем в 2-4 раза жмутся без performance degradation)
p.p.s. TDE and ACO требуют дополнительного лицензирования. Если у клиента не куплено то надо покупать

[Mark]

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

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

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

Если мы все еще об Oracle TDE то оно не поддерживает RSA. Только DES and AES:
https://docs.oracle.com/database/121/AS ... ASOAG10117

[Mark]

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

ну можно создать внешний домен для кастомеров - и используя directory services законнектить все к базе (Oracle EUS for example). но в принципе и хранение app users в базе это не криминал - просто хеш вместо plain text password - это как бы закон!

[valchkou]

согласен с некоторыми ораторами, простое работающее решение использовать vault + AES.
Простое не значит плохое или недостаточно безопасное!
Вопрос тут в другом, как защитить сам VAULT от несанкционированного доступа и от потери самого вольта.

Вариант без вольта тоже сработает, это установка сертификата на саму машину где запущена прога.
Но и тут есть подводные камни. Как управлять такими сертификатами?

Короче простого решения нет, если нет системы и процесса управления ключами/секретами/сертификатами.
Но если есть, то реализовать фичу просто.