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

[Flash-04]

Это называется security via obscurity и много раз было, что создатели именно так надеялись, что "никто не догадается" и таки догадывались.

[shadow7256]

пусть у вашего менеджера голова болит.

а у него особо не болит, менеджер слышал, что можно использовать RSA для шифрования и брякнул об этом клиенту, ну а клиент это Barclay банк тупорылый говорит ну зашибись пользуйте RSA. А какие у него ограничения, для чего он вообще нужен они и знать не знают. И менеджер щас говорит типа, ну вот клиент сказал чтобы мы пользовали RSA и точка. Пи...ц.

Вам надо знать плюсы и минусы всей этой кухни с шифрованием.

ну я сделал более менее research, просто я до этого уже имел дело и с RSA и с AES в моем коде, но там мы шифровали именно данные которые передавались между клиентом и сервером без всякой базы данных. Вот и спросил нормально ни будет пользовать AES для шифровки данных при вставке в базу данных.

Вообще всё это тянет на хороший project.

я согласен, так дело еще в том, что этот придурошный Barclay хочет, чтобы мы это все бесплатно сделали для них. И походу менеджеры согласны наши.

[kostik78]

пусть у вашего менеджера голова болит.

а у него особо не болит, менеджер слышал, что можно использовать RSA для шифрования и брякнул об этом клиенту, ну а клиент это Barclay банк тупорылый говорит ну зашибись пользуйте RSA. А какие у него ограничения, для чего он вообще нужен они и знать не знают. И менеджер щас говорит типа, ну вот клиент сказал чтобы мы пользовали RSA и точка. Пи...ц.

Вам надо знать плюсы и минусы всей этой кухни с шифрованием.

ну я сделал более менее research, просто я до этого уже имел дело и с RSA и с AES в моем коде, но там мы шифровали именно данные которые передавались между клиентом и сервером без всякой базы данных. Вот и спросил нормально ни будет пользовать AES для шифровки данных при вставке в базу данных.

Вообще всё это тянет на хороший project.

я согласен, так дело еще в том, что этот придурошный Barclay хочет, чтобы мы это все бесплатно сделали для них. И походу менеджеры согласны наши.

4к можно просто шифровать используя 8к (или больше) public + private key. Public key можно в репозитории/configuration management в открытом виде хранить, Private key попадает на сервер во время либо провиженинга либо с использований всяких vault с single use tokens. В облаках типа azure&aws все есть уже. Если это свой DC то можно замутить на основе hashicorp vault.

[shadow7256]

4к можно просто шифровать используя 8к (или больше) public + private key. Public key можно в репозитории/configuration management в открытом виде хранить, Private key попадает на сервер во время либо провиженинга либо с использований всяких vault с single use tokens. В облаках типа azure&aws все есть уже. Если это свой DC то можно замутить на основе hashicorp vault.

Объясните чем такие сложности будут лучше, чем просто использовать AES? Вот хоть один плюс назовите 4К это примерная цифра.. может быть и 3К.. а может быть и 6К, заранее неизвестно

[Palych]

Имеем колонку в SLQ Server типа varbinary. В ней хранится конфигурация "сервера" в двоичном виде. То есть это просто объект какого то класса в C# serialized into binary form. Это представление довольно легко перевести в удобочитаемый вид и увидеть что из себя представляет этот объект и какие данные он содержит. Длина данные примерно 4К.

Допустим кто-то прочитает эти данные из базы.
Их можно как-то использовать вне приложения?
Точнее - "снаружи" приложения.

[Palych]

Для ключей кстати придётся организовывать какой-нибудь Vault, продуктов много для этого.

Я бы вообще через environment variables выставлял все это, и нигде никакие пароли не валяются...

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

[shadow7256]

Имеем колонку в SLQ Server типа varbinary. В ней хранится конфигурация "сервера" в двоичном виде. То есть это просто объект какого то класса в C# serialized into binary form. Это представление довольно легко перевести в удобочитаемый вид и увидеть что из себя представляет этот объект и какие данные он содержит. Длина данные примерно 4К.

Допустим кто-то прочитает эти данные из базы.
Их можно как-то использовать вне приложения?
Точнее - "снаружи" приложения.

ну типа да. они этого и боятся, там находятся данные SMTP/POP3 серверов, к которым может обращатся наша программа. Этот сраный барклай же уже один раз взломали и украли кучу информации у них. Так вот теперь они говорят так "если кто то получит доступ к базе данных, то он сможет прочитать ваши данные и получить еще больше информации о других серверах". Как по мне так это такая чушь.. так сделайте так, чтобы доступ к базе не получил "кто то". Защитите базу данных и доступ к базе данных.

[shadow7256]

сырцы с ключами. знаете сколько их каждый день на Гитхабе находят?

думаете к то то будет выкладывать сорс код нашей программы на Гитхаб? ну хотя учитывая их дебилов вполне может быть

[kostik78]

4к можно просто шифровать используя 8к (или больше) public + private key. Public key можно в репозитории/configuration management в открытом виде хранить, Private key попадает на сервер во время либо провиженинга либо с использований всяких vault с single use tokens. В облаках типа azure&aws все есть уже. Если это свой DC то можно замутить на основе hashicorp vault.

Объясните чем такие сложности будут лучше, чем просто использовать AES? Вот хоть один плюс назовите 4К это примерная цифра.. может быть и 3К.. а может быть и 6К, заранее неизвестно

Вы же конфигурацию вроде криптуете ? Кто конфигурацию криптует - человек или программа? Если программа тогда да просто симитричный алгоритм с паролем через vault. Если человек тогда обычно задача не допустить утечки пароля для большого количества людей тогда public key для шифрования и private для дешифровки. Понятно о чем я говорю ?

Если длинна данных которые нужно криптовать не известна то public + private key в чистом виде не подойдёт ибо длинна ключа должна быть больше длинны криптованных данных.

[shadow7256]

Вы же конфигурацию вроде криптуете ?

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

Кто конфигурацию криптует - человек или программа?

наше приложение должно это делать

Если программа тогда да просто симитричный алгоритм с паролем через vault.

вроде при симметричном шифровании нужено иметь ключ + IV (вектор инициализации). Придется оба значения хранить в vault, я с этими vault ни разу дела не имел. Это какие то платные программы специальные для хранения ключей? C# программа сможет легко читать оттуда эти данные?

Если длинна данных которые нужно криптовать не известна то public + private key в чистом виде не подойдёт ибо длинна ключа должна быть больше длинны криптованных данных.

длина заранее неизвестна, если конфигурация сервера простая, то может и 1К быть.. а если сервер содержит много параметров, то может и больше чем 4К быть.

[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 что-то наколдовал, мы добавляли ключ/пароль - и все были довольны...