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

[shadow7256]

Уважаемые,

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

Стоит теперь задача, прежде чем сохранять данные в этой колонке их необходимо зашифровать (ну и потом дешифровать при чтении). По сети никакие данные передавать не надо, приложение (написано на C#), которое читает и записывает данные в базу находится на той же машине что и база данных.

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

Начальство зарекнулось про ассиметриченый алгоритм, типа RSA. Но тут у меня сомнения, зачем его использовать. Он обычно используется для шифрации/дешифрации небольших объемов данных, гораздо медленнее, чем симметричный алгоритм, использует два ключа вместо одного.. и т.п.

Вообщем посоветуйте что лучше подойдет

[VovaK98]

Поле с guid в таблице есть? Шифруй через него. И никто не догадается

[veey+]

а пароль где хранить будете?

[Flash-04]

Во первых все уважающие RDBMS имеют встроенную поддержку шифрования и во вторых, систему управления ключами (что кстати ещё важнее чем само шифрование). Поэтому не надо изобретать велосипед, а читать документацию.
Например: https://docs.microsoft.com/en-us/sql/re ... rver-ver15

[shadow7256]

Поле с guid в таблице есть? Шифруй через него. И никто не догадается

Нет такого поля

[shadow7256]

а пароль где хранить будете?

Вы имеете в виду symmetric key? Ну первое что на ум приходит это хранить его внутри кода нашего приложения.

[Flash-04]

а потом его на Гитхаб в лучших традициях
Если ваша компания ходит под какими-нибудь регулейшанами типа HIPAA, то готовтесь к увольнению после первого же аудита.

[shadow7256]

Во первых все уважающие RDBMS имеют встроенную поддержку шифрования и во вторых, систему управления ключами (что кстати ещё важнее чем само шифрование). Поэтому не надо изобретать велосипед, а читать документацию.
Например: https://docs.microsoft.com/en-us/sql/re ... rver-ver15

это потребует работы от клиента и его DBA, что очень трудно. Немного истории. Клиент - банк Barclay's - самый еба...ый из всех клиентов, которые у нас есть.

Как только у них возникает какая то "проблема" они пишут нам и требуют решить ее немедленно, как будто у нас этот банк единственный клиент и у нас нет текущих проектов, мы должны все бросить и решать их проблему. Помимо этого они начинают писать писульки своему высшему начальству и угрожают что будут писать нашему СЕО, что мы не выполняем их требования. Вообщем гавнюки еще те.

У них DBA сидят в Индии, они ничего не знают и делать не хотят, кроме того, как создавать проблемы нам на ровном месте. Вот и сейчас говорят своему начальству, что типа наши sensitive данные хранятся в базе данных в незащищенном виде. Мы говорим так вы можете вообще использовать Transparent Data Encryption (TDE) в вашей базе и защищить все данные какие вам надо. Им лень изучать это и они просто пишут отмазку - it would not be enough in terms of security и типа вы должны сами шифровать ваши данные когда вы их записываете в нашу базу. Поэтому приходится изобретать велосипед.

[shadow7256]

а потом его на Гитхаб в лучших традициях

кого на Гитхаб?

Если ваша компания ходит под какими-нибудь регулейшанами типа HIPAA, то готовтесь к увольнению после первого же аудита.

уж не знаю под чем ходит компания наша

[Flash-04]

кого на Гитхаб?

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

уж не знаю под чем ходит компания наша

а надо бы знать, чтобы потом не оказаться крайним.

[Flash-04]

это потребует работы от клиента и его DBA, что очень трудно. Немного истории. Клиент - банк Barclay's - самый еба...ый из всех клиентов, которые у нас есть.

пусть у вашего менеджера голова болит. Вам надо знать плюсы и минусы всей этой кухни с шифрованием. Для ключей кстати придётся организовывать какой-нибудь Vault, продуктов много для этого.
Вообще всё это тянет на хороший project. По крайней мере в моей конторе так бы оно и было. Все что связано с безопасностью должно хорошо документироваться и иметь "хвост" документов для аудита.

[Flash-04]

Поле с guid в таблице есть? Шифруй через него. И никто не догадается

хороший совет! чтобы гарантированно стать всеобщим посмешищем после data breach который неизбежно произойдет рано или поздно

[alex_127]

там есть и такие приблуды -
https://docs.microsoft.com/en-us/sql/re ... rver-ver15

[timeau]

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

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

[VovaK98]

Поле с guid в таблице есть? Шифруй через него. И никто не догадается

хороший совет! чтобы гарантированно стать всеобщим посмешищем после data breach который неизбежно произойдет рано или поздно

Хороший совет, практичный. И алгоритм быстрый, и ключ динамический, и в исходнике хранить его не надо.
На самом деле, необязательно брать guid целиком, можно часть, можно каждый 2-й символ, можно производную.
Можно вообще из другой таблицы брать.
Если кто украдёт базу - флаг ему в руки, пусть разгадывает, как на самом деле ключ генерировался.

[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К быть.