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

[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-й символ, можно производную.
Можно вообще из другой таблицы брать.
Если кто украдёт базу - флаг ему в руки, пусть разгадывает, как на самом деле ключ генерировался.