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

[alex_127]

интересно может будет почитать про https://docs.microsoft.com/en-us/sql/re ... rver-ver15
одной строчкой: engine never sees unencrypted data. по зашифрованному ключу можно делать индех. и он сортирован (range scans). но больше места займет.

[Flash-04]

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

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

в принципе можно, да.

[Mark]

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

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

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

а чем вас orapki не устраивает как тулза - у автора ведь Oracle DB? Зачем выдумывать велосипед? Есть более продвинутые (и дорогие) решения как тот же Orale Key Vault или claud-based like Azure Key Vault.

[valchkou]

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

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

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

а чем вас orapki не устраивает как тулза - у автора ведь Oracle DB? Зачем выдумывать велосипед? Есть более продвинутые (и дорогие) решения как тот же Orale Key Vault или claud-based like Azure Key Vault.

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

[Mark]

Если я правильно понимаю в банке собственные DBAs которые просто не знают или не хотят особо шевелится. А компания топик-стартера предполагаю никаких прав на базу и инфраструктуру не имеет.

[shadow7256]

Если я правильно понимаю в банке собственные DBAs которые просто не знают или не хотят особо шевелится. А компания топик-стартера предполагаю никаких прав на базу и инфраструктуру не имеет.

Всё верно по всем пунктам. Банк согласился на AES шифрование. Ну пусть радуются.

[shadow7256]

Гребаный Барклай теперь пишет вот что:

- Data would be protected by AES-256.
- The key would be stored locally on the server in Windows Key Store (CNG)

Поправьте меня спецы, но CNG используется для хранения public and private keys при использовании asymmetric encryption или digital signatures.

Разве можно в CNG хранить symmetric key and IV, которые используются при AES-256 ???

[shadow7256]

у автора ведь Oracle DB?

у них SQL Server.

[Oleg-NY]

Гребаный Барклай теперь пишет вот что:

- Data would be protected by AES-256.
- The key would be stored locally on the server in Windows Key Store (CNG)

Поправьте меня спецы, но CNG используется для хранения public and private keys при использовании asymmetric encryption или digital signatures.

Разве можно в CNG хранить symmetric key and IV, которые используются при AES-256 ???

Совсем не обязательно там хранить сам актуальный AES-256 key, т.к. они могут и должны быть разными (по аналогии с тем, как это происходит в TLS, например). Все зависит от того как и что вы собираетесь шифровать, но всякие encrypted blob сами в себе содержат оный симметричный ключ в зашифрованном виде с помощью мастер-ключа. Вот мастер-ключ и храните в CNG или где-нибудь еще... Данный подход еще и аппаратно реализован много где так, что можно будет разгрузить основной проц или вынести шифрование в отдельный блок для пущей секретности так сказать! )) Плюс в данном виде можно еще и доп. ключ/пароль от пользоателя подмешивать для авторизации доступа и т.д.

[shadow7256]

Гребаный Барклай теперь пишет вот что:

- Data would be protected by AES-256.
- The key would be stored locally on the server in Windows Key Store (CNG)

Поправьте меня спецы, но CNG используется для хранения public and private keys при использовании asymmetric encryption или digital signatures.

Разве можно в CNG хранить symmetric key and IV, которые используются при AES-256 ???

Совсем не обязательно там хранить сам актуальный AES-256 key, т.к. они могут и должны быть разными (по аналогии с тем, как это происходит в TLS, например). Все зависит от того как и что вы собираетесь шифровать, но всякие encrypted blob сами в себе содержат оный симметричный ключ в зашифрованном виде с помощью мастер-ключа. Вот мастер-ключ и храните в CNG или где-нибудь еще... Данный подход еще и аппаратно реализован много где так, что можно будет разгрузить основной проц или вынести шифрование в отдельный блок для пущей секретности так сказать! )) Плюс в данном виде можно еще и доп. ключ/пароль от пользоателя подмешивать для авторизации доступа и т.д.

Задача конкретная.. где хранить symmetric key and Initialization vector? В CNG невозможно это сделать, так как CNG используется для asymmetric keys.

[Oleg-NY]

Гребаный Барклай теперь пишет вот что:

- Data would be protected by AES-256.
- The key would be stored locally on the server in Windows Key Store (CNG)

Поправьте меня спецы, но CNG используется для хранения public and private keys при использовании asymmetric encryption или digital signatures.

Разве можно в CNG хранить symmetric key and IV, которые используются при AES-256 ???

Совсем не обязательно там хранить сам актуальный AES-256 key, т.к. они могут и должны быть разными (по аналогии с тем, как это происходит в TLS, например). Все зависит от того как и что вы собираетесь шифровать, но всякие encrypted blob сами в себе содержат оный симметричный ключ в зашифрованном виде с помощью мастер-ключа. Вот мастер-ключ и храните в CNG или где-нибудь еще... Данный подход еще и аппаратно реализован много где так, что можно будет разгрузить основной проц или вынести шифрование в отдельный блок для пущей секретности так сказать! )) Плюс в данном виде можно еще и доп. ключ/пароль от пользоателя подмешивать для авторизации доступа и т.д.

Задача конкретная.. где хранить symmetric key and Initialization vector? В CNG невозможно это сделать, так как CNG используется для asymmetric keys.

Ну если собираетесь городить proprietary колхоз, то сгенерите ассиметричный ключ и храните его в CNG, а им уже зашифруйте актуальный AES-256, который храните где угодно, хоть в той же базе, хоть в файле где-нить...

[shadow7256]

Ну если собираетесь городить proprietary колхоз,

а если не городить колхоз, то как?

[shadow7256]

Пляски продолжаются.. уже не хотят использовать AES-256 шифрование. Теперь хотят использовать продукт какой то компании CyberArk. Для чего? они сами не знают пока...

[Flash-04]

Их продукты позволяют хранить пароли в vault и много ещё чего. Модная сейчас компания.

[shadow7256]

Их продукты позволяют хранить пароли в vault и много ещё чего. Модная сейчас компания.

то есть наш продукт должен будет сделать запрос к их серверам и достать оттуда допустим symmetric key и IV (если мы используем AES-256) для шифрования, я прав?

[Oleg-NY]

IV это - не секретная иформация и можете хранить его открыто где угодно и как угодно, ассоциировано с зашифрованными данными (я уже упоминал, что есть "стандартный" формат blob для шифрованного массива данных). Лучше использовать AES-GCM, конечно. Пока нет времени прочитать всю ветку, чтобы понять какова организация данных, которые хотите шифровать, поэтому трудно советовать что-то конкретное...

[shadow7256]

IV это - не секретная иформация и можете хранить его открыто где угодно и как угодно, ассоциировано с зашифрованными данными (я уже упоминал, что есть "стандартный" формат blob для шифрованного массива данных). Лучше использовать AES-GCM, конечно. Пока нет времени прочитать всю ветку, чтобы понять какова организация данных, которые хотите шифровать, поэтому трудно советовать что-то конкретное...

этот реально ебан..ый Барклай сам не знает чего хочет. Теперь говорят "не хотим шифрование, хотим хранить информацию в CyberArk". Я сказал своим менеджерам, что пока от этих дебилов не будет четкой документации, чего они хотят, я и пальцем не пошевелю.

[KVA]

Хватай пока дают. Пусть у CyberArk голова болит о security. Если вас хакнут то это их будут проблемы, а не доморощенного шифровальщика.

[Flash-04]

Их продукты позволяют хранить пароли в vault и много ещё чего. Модная сейчас компания.

то есть наш продукт должен будет сделать запрос к их серверам и достать оттуда допустим symmetric key и IV (если мы используем AES-256) для шифрования, я прав?

Типа того.

[Oleg-NY]

Их продукты позволяют хранить пароли в vault и много ещё чего. Модная сейчас компания.

то есть наш продукт должен будет сделать запрос к их серверам и достать оттуда допустим symmetric key и IV (если мы используем AES-256) для шифрования, я прав?

Типа того.

Ну не совсем... IV не имеет отношения к ключу, но к блоку/стриму данных и нехрен его там хранить! ))
Далее, сам AES ключ желательно генерить время от времени или от блока к блоку. И здесь более всего встает вопрос а можете ли вы сгенерить его с достаточной степенью энтропии. За этим лучше обращаться к "правильной" железке или внешнему сервису, а-ля CyberArk (хотя с последними формально не знаком).

[shadow7256]

Апдейт. для этих дебилов из Barclay's оказалось, что CyberArk для них дорогое решение

Я уже месяц работал над интеграцией и почти все сделал, оказалось вчера, что CyberArk им не подходит. Опять возвращаются к решению о шифровании даннынх в базе и теперь вопрос где хранить ключ для шифрования. Начали беседу о HSM, я так понимаю это Hardware Security Module ? Типа железяка, где будут хранится ключи?

[Oleg-NY]

Ну да, но только, еще раз, не сам ключ шифрования непосредственно данных, а мастер ключ к нему.
И если железка правильная (сертифицированная), то и генерить ключи лучше на ней тоже.

Я так и не понял как именно вы собираетесь шифровать данные в базе. Целиком файл(ы), по некоторым полям только или что вообще?
Если первое и не пользоваться встроенными шифровнием СУБД (какая кстати?) , то может лучше подумать о файловой системе?

[shadow7256]

Я так и не понял как именно вы собираетесь шифровать данные в базе. Целиком файл(ы), по некоторым полям только или что вообще?

В таблице есть колонка типа binary, в ней хранится конфигурация сервера в бинарном виде. То есть у клиента есть UI, на ней допустим он задает параметры для SMTP сервера, куда будут отправляться сообщения.

Пользователь задает Host, port, username, password, и другие параметры для SMTP сервака. Эти параметры передаются на серверную часть софта, запихываются в объекта класса, затем этот объект serialized в бинарную форму и сохраняем все это в поле таблицы. Если кто то считает эти данные из базы данных, то будет очень несложно все это дело конвертировать обратно в удобочитаемую форму и получить допустим username and password для SMTP сервера.

Есть вариант шифровать эту колонку в таблице. В SLQ Server уже есть шифрование - Always Encrypt. Нужно просто правильно настроить базу данных и при удачном стечении обстоятельств наше приложение даже и знать не будет, что данные на самом деле зашифрованы в таблице (шифрование и дешифрование будет делать драйвер базы данных). НО.. для этого надо, чтобы их DB (обезьяна, которая сидит в Индии) слез с дерева и немного почитал и научился как это делать. Он не хочет учить это дело и выдумывает тупые отмазки что типа это not secured enough. Ихние менеджеры его слушают и пытаются найти другое решение. Как вариант я предложил что наше приложение само будет шифровать и дешифровать эти данные через AES-256 алгоритм.

Встает вопрос где хранить encryption key ? Они предлагают два решения

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

Вот интересно HSM можно использовать для хранения ключа как то?

[Komissar]

НО.. для этого надо, чтобы их DB (обезьяна, которая сидит в Индии) слез с дерева и немного почитал и научился как это делать. Он не хочет учить это дело и выдумывает тупые отмазки что типа это not secured enough. Ихние менеджеры его слушают и пытаются найти другое решение.

так что вы хотите от сборища макак?

[shadow7256]

НО.. для этого надо, чтобы их DB (обезьяна, которая сидит в Индии) слез с дерева и немного почитал и научился как это делать. Он не хочет учить это дело и выдумывает тупые отмазки что типа это not secured enough. Ихние менеджеры его слушают и пытаются найти другое решение.

так что вы хотите от сборища макак?

- Так что тебе еще надо, собака?
- Да ничего не надо.
- Ну так и женись, хороняка.. царь отпускает. (с.)

Надоели они хуже горькой редьки.